On 05/17/2014 11:13 PM, Robert J. Hansen wrote: > A lot of users would object. "I don't want Enigmail to keep track > of whom I'm corresponding with and what technologies they're using! > It's a violation of privacy! How do I know what you're doing with > that information you're collecting?" > > And I hasten to add -- it's a pretty reasonable objection.
It's absolutely not a reasonable objection. If you really want to appease those users, then lobby on the list for an option to disable that information collection, but don't lobby against measures to increase convenience and (thus) security for rational users in order to placate fools. IINM, PGP/MIME masks more metadata than the other options, and so it would be preferable for more mail to be sent using that, from a privacy and security perspective. OTOH, I can't conceive of any security risks imposed by maintaining such a simple list of contacts. In my proposal, it's just a simple blacklist, a list of contacts, nothing more; not even the particular clients seen being used by the contacts. I suppose that you could argue that in the case of a user deleting all local copies of messages from a contact, you retain an additional record of the user having communicated with the address of the contact if they're in the black list, and so if the user's machine were apprehended and had forensic analysis performed on it, you could say that that's a potential problem, the additional data retention. But I'm willing to bet that Thunderbird's own "collected addresses" functionality does that already. > Just to be clear: I don't know of any MUA that can handle/decrypt > PGP-encrypted mail but *can't* handle/decrypt PGP/MIME-structured > encrypted mail. All the PGP/MIME problems i've seen reported have > to do with failing to read PGP/MIME-signed (but not encrypted) > messages. Oh, I didn't know that, but it's interesting, in that it would allow for another heuristic to be added in terms of Enigmail being more proactive about deciding the encryption scheme to use: if the message isn't set to be signed anyway, then there's simply _zero_ reason not to go with PGP/MIME, right? That cuts out a whole bunch of cases right off the bat.. thoughts, anyone? > * just because you've never been sent an e-mail from that user via > a PGP/MIME-broken MUA doesn't necessarily mean that they never read > mail on such a MUA. Sending is not receiving. Okay, so how do you personally determine whether or not to send someone a message in PGP/MIME, then? What it does mean is that the user will at least have some way to decrypt and read the message on one of their devices, somehow, without needing to install and configure any new software. If, given the recipient's personal mail routine, it's a huge nuisance, the user could respond requesting that the sender make a rule for them that unsets the PGP/MIME option for future emails. In any case, IINM, automatedly or not, it's the only data we have to go on, save for exceptional cases like, say, people who live together and incidentally see each others' screens and know what each others' setups are or something like that. > * you'd need to enumerate which versions of which MUAs (with which > plugins) are PGP/MIME-broken and keep that list up-to-date somehow. > How does that interact with, say, webmail implementations? I'm not terribly well informed, but I'm under the impression that it's only a few stubborn versions of outlook that choke on PGP/MIME, and that the latest versions of MS' MUAs even do fine with it, so I don't think it would need to be a dynamically maintained list that would ever get any additions to it. I can't imagine that any new mail encryption packages in the future would not put the effort in to support the obvious optimal encryption scheme (PGP/MIME). This strikes me as being like saying that you'd need to enumerate which browsers don't support addEventListener so you can serve them a version of pages that use attachEvent instead. > * some messages don't have any clear indication of what MUA they > used. That's a point. > * someone who used a PGP/MIME-broken MUA 6 years ago may not still > be using that MUA. should six-year-old mail still be relevant? > Figuring out what sort of cutoffs are reasonable is non-trivial. I'd say that if the user ever sent mail indicating a PGP/MIME-enabled MUA, then they should be put on a white list, because it means that they have the means to read mail. If for whatever reason, that's not the way they'd like to get mail in the future, they can request to have a rule set for them, and if there was a problem with that initial message, they can request a resend. Ultimately, I'm pretty biased, because it seems to me that PGP/MIME conceals more metadata, and metadata collection is a collective issue. Both sender and receiver are stakeholders, and ultimately, even people who aren't a party to the communication are, too, because the government makes inferences at the edges of the social network maps that it builds. When you're not the only stakeholder in a matter, it's sort of bad etiquette to be using software which doesn't support modern standards. Much like the fact that old-IE's prevalence is a real social problem makes the use of old-IE socially irresponsible, so too, I think, does the fact that mass government surveillance is a social problem make using outdated encryption software rude. As developers of a prevalent mail encryption package, we have the power to give significantly consequential nudges of the GPG user base towards a critical mass of modern mail encryption standards supporting software adoption, and I think we have a social and political responsibility to do that. In that regard, the points of inconvenience you mention are actually a feature, not a bug. > * Imagine a user who has 300,000 message in their mail archive. > You wouldn't want search all of those each time. so you'd want to > keep some sort of state for each user that could be updated when > new mail from that user was discovered by thunderbird. That's what I had in mind. > This doesn't necessarily just mean when new mail is fetched -- > thunderbird could suddenly get access to an old mailbox, or a new > folder could be published. how would you synchronize this cached > state? Not sure what you mean by this, on syncing cached state. Sorry. Anyway, with the system in place now, what thought process does sending user Bob go through in his head when he's presented the modal scheme selection prompt? "Hmm, gee... I guess I remember reading somewhere that PGP/MIME is ideal if the user's mail client can render it, but.. wait, is that for decryption, or only processing signed mail, or... oh, that's right. It isn't a nebulous unenumerated set of clients that don't accept PGP/MIME, it's just some versions of one or more of the MS MUAs. [So what the question of 'should I use PGP/MIME for this message or not?' really comes down to is 'is my recipient prone to read mail on a MS MUA?', and it's quite uncommon for people to be familiar with their email contacts' software diets, and so the only really reasonable way to respond to that modal, even as things are today, is by using the data at your disposal, i.e. the headers of the messages you've previously received from that contact. But that's unreasonably tedious, and so I'm proposing that we simply automate the only rationally-grounded way of answering that modal prompt.] Oh well, I guess better safe than sorry, and I don't want to give my contact friction when opening my message, so let's nix the PGP/MIME." That's unfortunate, because it results in a more surveilled world for all of us. Cheers :) _______________________________________________ enigmail-users mailing list [email protected] https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
