On Thu 2024-02-22 10:08:10 -0800, Bron Gondwana wrote:
> On Wed, Feb 21, 2024, at 09:29, Alexey Melnikov wrote:
>> On 21/02/2024 17:05, Bron Gondwana via Datatracker wrote:
>>> I do have some concerns about the implementability (particularly, as already
>>> called out in another review, the "strip things which aren't secure enough when
>>> quoting for reply" which will likely make users feel there's something wrong
>>> with their client).
>
>> What do you mean by "implementability"? This is not going to be that
>> hard to implement, it might just be surprising to users.
>
> That's enough that high-usage clients won't implement it, because the
> support load becomes too high.
>
>> Would showing a warning to the user be a better thing instead?
>
> I'm not sure that there is a better thing; maybe the user needs to be
> offered a choice. Probably: "always include", "always exclude", or
> "always ask (default)".
>
> I think just a "this is going unencrypted: remove text that came in
> encrypted?" non-blocking prompt.
I think offering such a prompt to the user is within the bounds of the
behavior described in the document ("the composing MUA SHOULD strip the
quoted text from the original message"), though I'm always reluctant to
offer users choices that they might not have enough information to
understand and are likely to click through without reading.
That said, your proposed prompt is more readable than the overwhelming
majority of user prompts i've seen related to e2e-encrypted mail, and it
does seem like it might avoid some of the support load that unilateral
text stripping in this circumstance might inflict on the vendor.
Would you care to suggest text for the document that would encourage MUA
implementers to consider this kind of prompt?
Would it make sense to change:
In this circumstance, the composing MUA SHOULD strip the quoted text
from the original message.
to:
In this circumstance, the composing MUA SHOULD strip the quoted text
from the original message, unless the user indicates that they are
deliberately including previously confidential content in a
non-confidential message.
I'm proposing this change in
https://gitlab.com/dkg/e2e-mail-guidance/-/merge_requests/12 -- i'd be
happy to see suggestions for improvement.
A proper UX design (probably outside the scope of IETF work) for such a
prompt might look like a prompt that would block sending, but not
editing. That way user has to resolve the prompt before they click
"send" and they can't send confidential text in the clear by ignoring
the prompt. It should provide an indication to the user of what text is
going to be stripped. And the "always include" or "always exclude"
choices shouldn't be offered directly in the interface unless the prompt
has been presented to the user several times within a relatively short
timeframe.
--dkg
Attachment:
signature.asc
Description: PGP signature
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
