I think it's pretty clear what's going on here.
By the way, FastMail's work at the protocol level - http://jmap.io/ - is open source, and being standardized by the IETF.
FastMail itself is using something non-standard, and saying it is open source and "being standardized" means nothing. See https://xkcd.com/927.
The spec is now nearly complete and we expect standards-track RFCs to be published later this year. Adoption will then happen slowly over time, as it did with IMAP. Smaller, more nimble companies are likely to move first and then larger companies following later. IMAP took many years to get widespread adoption; I hope we can make the move to JMAP a bit faster, but these things always take time (often measured in years!) to develop, test and release.
I love XKCD as much as the next guy, and of course it's kind-of right, but also too cynical: the only other alternative is to not make an effort at all, and accept the status quo is the best you can hope for. We'd like to do better than that. If we fail, at least we know we tried.
While Fastmail at this moment look much better than other mail services, nobody know what Fastmail (or any other service) could do with your correspondence tomorrow.
There is cool sample flowchart[0] created using Dia[1]: "Should I encrypt my email?"[2]
[0] http://dia-installer.de/shapes/Flowchart/index.html.en
[1] https://en.wikipedia.org/wiki/Dia_(software)
[2] http://dia-installer.de/shapes/Flowchart/images/Flowchart.pn...
Given the surfeit of standards compliant email available, switching to another provider is trivial
What are you talking about ? The IDLE command is completely supported and I'm using it in my mail client with no issues at all.
IMO this is an open invitation to phishers.
This implementation, however - especially centralized tracking & policy enforcement, and HTTP as the delivery substrate instead of some properly designed protocol - typify everything I dislike about Google's product design choices. And if the open invitation to phishing wasn't bad enough, expiring messages sound to me like a built-for-purpose gaslighting tool.
The current ad-hoc approach of "type this URL in" that's used in various places could be extended in this case to "click this link, or alternatively go to this short address and type this short code in".
This would actually work because the short URLs would be per-recipient-account - they wouldn't need to be "globally" unique!
Alas, we live in a denialist dystopia, not a self-acknowledging one, so the above will probably never happen - per-recipient short URLs rely firmly on a global social graph that can predict with a high degree of accuracy who is highly unlikely to click on who else's link.
Google has one of these, but nobody's supposed to realize how much of an oracle it is.
So, we've just upgraded to "for security, please click this 10000-character-long URL" emails being sent from Google itself.
The phishers are laughing.
It isn't a case of "not clicking on someone else's link", it's a case of never receiving someone else's link.
As it is, clueless people will forward their links in attempts to let others read their messages. Of course this won't work (I don't expect so anyway).
But, if person A and person B both receive the same short code, which would (obviously/presumably, in such a scheme) unlock different messages for both, that would be a very confusing user experience.
Given the "enterprise security" standpoint this (somewhat) confusing feature seems to be marketed toward, I can see this being the exact kind of situation that enterprises would never want happening (the resulting executive paranoia would undermine the perceived security of the system).
And so this folds into the global social graph thing I was talking about.
So the next time you get an email from "google", you won't think twice about why you have to log back in.
On the other hand, part of the point of Gmail is that it makes your emails easily searchable, so you can quickly dig up info from old mail rather than have to make a note of said info in some sepearate program/notebook/whatever. But if emails are going to randomly be disappearing, it could really cripple that utility.
It's more of a "please don't forward this" feature than a "you can't forward this" feature. It's the same with DRM features in Outlook. It stops people from accidentally leaking information, but it doesn't stop people who intentionally want to leak information.
In an ideal world telling the recipient not to spread this information (either by just asking or some kind of work policy) should be enough but sometimes having a small technical barrier is needed.
Also when information is leaked at a later time it can show intent on the leaker (vs saying something like "oops I fat-fingered the recipients when I forwarded that email to my personal account")
Actual authentication is really difficult for anything.
It's slightly off-topic, but I've found since I switched to notmuch that offline search is much faster than online search. I can dig through my trove of gigabytes of email in fractions of a second: queries feel as though they're instantaneous.
This is a case where free software has caught up to & exceeded Google. It's pretty wonderful!
The benefit with automated rention policies embeded in content is that it's less easy for the information to be weaponized ex post. I.e. Now that a couple has broken up, a vindictive partner doesn't have a full log of their communications that they can use to blackmail their partner. Basically it tips the balance back towards conversation and less dystopian log by making people who are attempting to log everything incur a cost rather than have them freeride on the logging system.
I think we have different distopias in mind. :-)
Moreover, I worry about the new Gmail feature that undermine the open platform of email. Email is just about the last unwalled comms platform we have, and I really worry for its safety if gmail thinks it can start differentiating network effects on gmail vs network effects on email.
I switched my vanity domain over to Fastmail a while back. I haven’t had any regrets. New features like this make me even more glad.
If email gets a "HTML5"-like major refresh at some point then I'd be proven wrong but that hasn't happened yet in my lifetime. Microsoft in particular between Outlook.com, 365, and Exchange/Outlook Desktop are a major hindrance to any advancement.
See: https://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol#...
Yes, please leave email the way it is, because it works fine. It’s one of the few things that does.
The only feature I want is end to end encryption. Google will never make encryption easy on their own because they’ve got perverse incentives not to.
But that would require all the transfer agents, delivery agents, and user agents to agree on the new spec, implement it in some standard/predictable backwards compatible way, and then support a legacy mode for the next 5-10 years.
I wish people who want to "advance" the standard went off and used something else. Go use allo or hangouts or whatever new locked-down app google is pushing this week. I suspect there will always be people who are content with email.
https://imgs.xkcd.com/comics/chat_systems.png
All the chat programs are making all the communication pain in the neck and the only way of communicating that you can rely to are old school phone calls, sms and email.
There is also other side, with email you actually think what you are writting as you don't want to flood someone, with chatting it is all about smileys or everybody would be still using irc, I still need to see chat program catching the amount of irc features (actually I would bet Telegram is just front end for irc servers in backend).
And just to mention this gmail feature, it is just nonsense, it will work in their cough spy.. cough ..ing... email system, immediately when it leaves it, it is probably just a mime header which I will gladely ignore. And self respecting techie shouldn't use the gmail (and should be proud not to use it ;) ) anyway.
It's pretty obvious Google is moving the facebook way. This will evolve into a proprietary messaging system, basic mail gets demoted to a third-class service, and people get locked into yet another non-standard ecosystem controlled by one company.
The only difference is that facebook was blatant about it, and google's taking the boiling frog approach.
And they do it even though, as you note, there are tons of ways to really do confidentiality much better. The Signal protocol has worked great for chat, to name another example. The problem with that for Google, I guess, is that end-to-end security is more in line with the Apple model of smarts living on the user's device, not the Google model that requires the server to read and understand all of every user's content. (I say that as someone on Android, Linux, and so on. I'm not super invested in Apple or their ecosystem.)
Also, this idea is salvageable. You could have "request expiration," etc. and maybe you honor by default but don't suggest you enforce it. And managed work environments can try any DRMish stuff they like (though it will still be unreliable!), because the boss is the customer and if they want to make it a pain for the user to do certain things they can. But as it stands now, false sense of security for the average user, and an entirely valid feeling for those parsing the details that companies like Google are more than happy to erode user control.
I would love to see this idea ridiculed for how broken it is. Maybe it will even inspire less broken privacy features from competitors.
It's trying to turn email into a proprietary thing that only works between Gmail addresses. All the Inbox "AI-enhanced" nonsense was also part of this plan, and I'm glad it hasn't caught on because of that.
The only thing that would make me accept Gmail turning email into a less open format is if they enabled end-to-end encryption similar to ProtonMail that wasn't a pain to use like PGP is. At least then there would be a good reason for killing the old format and breaking compatibility with other providers.
Ideally, it would still be a format that other email providers could at least adopt later on, and then the email services could remain compatible with each other. But providing end-to-end encryption at all would be a big deal on its own.
But this or the AI stuff are a joke in comparison. And we know Google doesn't care anymore about end-to-end encryption (now that it has become Pentagon's bestie), as it has already killed its own End-to-End project.
Agree with that.
And sad and weird. There are plenty of ways to do well in business without eroding the open nature of email!
"Email is your electronic memory": https://blog.fastmail.com/2018/02/14/email-is-your-electroni...
I like innovation, but to innovate email wouldn't be better to innovate in a slow and consensual way using RFC after RFC, at least in the case of email?
I think it's really the opposite, every provider tends to introduce new/unique/nonstandards but they (mostly) interact at a minimum with eachother.
Re: gmail DOT and + notation, those have been in common use on that platform for over a decade.
>I like innovation, but to innovate email wouldn't be better to innovate in a slow and consensual way using RFC after RFC, at least in the case of email?
RFC to what body? To the best of my knowledge the entire thing is just a happenstance of what happens to work in every client/server combination.
Google is allowing you to hide emails from its public interface after a specific amount of time.
Google, please don't mess with email standards.
And it will play havoc in GSuite, where there are needs and requirements for various entities to maintain business records. (Maybe these deleted emails remain visible to administrators? Still leaves employees without control over the messages sent to them, including and especially abusive ones.)
Anyway, feels like more asymmetry in what was designed as a symmetric model -- like much of the Net.
This is a dog and pony show.
I also don't see any reason you couldn't build a bot that grabs these for you to keep via the gmail add on api.
they'd have a standard, non-selective, purely time-based expiration policy which would be defensible in the face of a government investigation.
"Your honor, we made no attempt to hide specific details about this matter. Our policy has always been to destroy all messages that are greater than 90 days old."
A retention period in line with SEC requirements (7 years I believe) might fly but 90 days is to short -also how would you discipline some one for abuse of the email system if the evidence disappears
Others would not because the regulators (like the SEC) have said that companies can't delete communication data (email/chat) prior to regulated windows. most companies want to delete as soon as possible after that window has expired which is it's own challenge.
I suppose I wanted to point out that not being able to read a message and fully purging it are not the same thing and gsuite likely alienates the enterprise if they cannot comply with regulation.
If they can add features like the temporary "confidential" mail as what Google is implementaing in Gmail, that would be a nice extra. But if we can't even do the basics right, why implement such features that can only be used between your own users?
Because when you try to use PGP these days using different implementation like Thunderbird/Enigmail to Outlook/GPGOL or vice versa, half of the times the e-mail are unreadable, not able to be decrypted or some other mysterious problem.
Glad I’ve moved to fastmail.
I don't even need to prevent printing etc.
I'd also love a setting, email over 1 year old, you have to jump through some extra hoops to access it.
Only if you have complete end-to-end control over all the devices that everyone uses, including their brain, can you stop people from copying data.
If I have a file that I want to limit access to, I would never dream of sending it via e-mail. Some hosted document service which only shows parts of the file would be far preferable.
There are plenty of scenarios where the sender may be confident that the recipient will not intentionally betray their trust but may not want to leave long-term traces behind (say, forwarding confidential documents to a family member). Rather than reminding them not to forward the email and to delete it ASAP, you could just use this feature instead.
Just because something doesn't can't cover all scenarios doesn't mean it's useless. Firefox's Private Browsing can't hide your activity from a determined eavesdropper, for example, but there are still plenty of ways in which it's useful.
I can see how they could prevent this happening for the average user, but do they really have some way actually stop this?
The way I see it, it could be useful for internal emails you don't want inadvertently shared with the outside.
> the company is now evolving beyond the simple POP3/IMAP/SMTP protocols
Seems almost as though Google has learned the "Adopt, adapt, decomoditise" mantra so beloved by Microsoft in days of yore.
I'm still puzzled by this one. Anyone?
Automatic local snapshots that you control!
Sort of like deleted tweets that suddenly everyone have elevated interest in and can read forever.
In fact the more "deleted" the tweet (or email) is - the more attention it will get.
If Google was serious about privacy it would pgp-encrypt everything so only the client, client-side can decrypt it, just like what protonmail does.
pfff, 'self destructing emails', what a heaping pile of razzle dazzle no-ops that is -- this is more likely subliminal advertisement for the new mission impossible movie.
The biggest benefit of this is removing the email from archives, so weeks, months, or years later if the account gets compromised the gains are lower. For example an email with the subject "HIV Test Results" has a far different value with and without a body included.
A more down-to-earth example is I just sent my wife a W-2 via email for our taxes. I asked her to delete the email after downloading the document. But instead I could have just set an expiration on the contents and poof it is gone.
Even with the first, Google supports forwarding all mail to an arbitrary email address, which means the "Gmail" becomes a text-file stored on a dovecot server (or other regular mail server) somewhere.
So unless they break delivery (you can forward only some subset of emails) - there's no way for the sender to have any better guarantee than "please delete after reading".
At least the pgp spec has (had?) an "eyes only" flag that, while it didn't guarantee anything, at least meant compliant software would try hard to not leave a plain text copy on the filesystem.
I’m organizing mail sent to me. 10k text files. The last thing I want is to debug why search isn’t finding the message because some vendor 4 years ago flagged their invoice with an expiration date.
This is not a function that as a receiver of email I want. So they can make a new protocol that I don’t use instead of overloading email.
Also, it’s a bit scary for some of the slippery slope possibilities. Will my filesystem do the same? The last thing I want is DRM checking every file.
Stuff on my machines is my data. If you don’t want me to have it, don’t send it to me. Etc etc.
So why would I believe Google now?
This is an augmentation to what postini had, and now in core G Suite, of defined retention periods for email. Now, users can make one-off decisions on a per-email basis.
It's like the secret discussion/chat system that uber uses, I can't find the name, that guarantees protection against legal discovery by encrypting the chat and making sure it is ephemeral.
There are valid (maybe not morally, but legally) reasons to have defined retention periods and this is a nice addition to that.
It does bring Google into the Apple privacy-is-our-business sphere in that cooperating parties that solely use gmail have much better assurance that they don't leave traces behind.
Wickr, but while it guarantees protection from discovery, it doesn't guarantee freedom from implication. It is not legal to use such services to hide illegal activity, which is what Judge Alsup clearly laid out in the case. How would you know if illegal information was being traded? Because Uber management implied that employees should use Wickr if they were going to talk about anything illegal, which, uh, isn't something you want to do.
Apple supporting it won't help apple users one bit, because nobody else uses an actual application to check mails anymore. It's mostly web mail clients everywhere, and they obviously can't use encryption.
I was playing around with using my own CA to issue certificates for internal stuff. I created a personal certificate for myself and imported it to my keychain - without doing anything, Apple Mail was digitally signing my messages. On the other side, however, people saw digital signatures that couldn't be verified and got confused by that.
[0] https://support.apple.com/en-ca/guide/mail/sign-encrypt-mess...
Basically if I send you a message using it, I have deniability. Screen shot all you want, I can simply say I never sent it. If we do go to court over something sent -- you will end up showing a screen shot or a copy and pasted text file. Those will be tough to support in court. Have fun going after an Uruguay tech company for deleted data.
This is different with standard email. A subpoena sent to gmail will reveal ip addresses (sender and receiver), what time it was sent, the fact that you logged in with account 9328439, the fact I logged in with account 298238, someone from google testifying it was sent and read, on and on.
I don't know what google is trying to do -- but what privnote did is really useful and an obvious win.
I'm not so sure about that. If you leave enough incriminating evidence in the note itself, it wouldn't take too much to convince the jury or judge. For example, if you write something that only you had knowledge of in the note, then it can be used as evidence to convince the jury that you wrote it.
This site is a good idea but should be viewed as part of an overall strategy.
From these screenshots, Google calls the note an email, integrates it with their email client, and removes some normal email controls for forwarding, etc. That violates people's expectations of email, in terms of recipients' control of their data and vendor neutrality. Those are things I don't want changed about email!
One approach is to decouple ephemeral messages from email or GMail like privnote, which avoids confusion or lock-in. You still should make precise promises, though; I think "disappearing message" is a bad way to say "we delete our copy." Seems 100% feasible but then it's just Google Privnote.
Another option is to keep it integrated but tweak it to try not to mess up email, by making the feature "expiration request" or something, and maybe many clients comply by default but don't force it, except possibly when account owner != user (work networks). That helps cooperating parties without being either vendor-specific or DRM-y. I can even imagine vendors working together on that, especially with handling of user data in focus right now. Senders can try to figure out if your recipient contacts/domains claim support for the feature so you don't try to use it when it's clearly meaningless.
A fear is that Google considers it a feature to mess with the email ecosystem by adding vendor-specific stuff, or that Google'll talk about security a lot and just happen to propose lots more solutions involving more Google lock-in. I'd like to see what comes out of Google I/O to get more of a sense.
This solves quite a few problems. Then, Google can start on other problems, like PGP.
https://blog.google/products/gmail/g-suite-gains-traction-in...
I have to wonder if the same concept would / could be applied to such emails? The email might be gone from my account and yours, but it's still in a digital landfill somewhere. Free to be reviewed, sans warrants, etc. Perhaps?
Hmm, there could be a business opportunity for the USPS. They could sell 'stamped' trash bags, good for transport to the town dump, which could only be collected by authorized carriers, namely the regular trash collectors.
Pawing through those bags would be tampering with mail, a federal crime IIRC ( ah, here we go: https://about.usps.com/securing-the-mail/mailtampering.htm )
Probably not a market hit, though, no one really cares. Not to mention the bags would highlight "the good stuff".
If you post a reply to a wrong comment, please explain how it's wrong while remaining civil. Then we all learn something, and you don't damage the community.
You can save the message contents with effort, that's not really the threat model this is feature is addressing. But neither POP nor OfflineIMAP will help you by default.
The recipient receives a link instead to the content.
As a matter of principle, I should retrieve the email via IMAP and later, while reading it offline, compose a short reply, "you forgot to attach a real message, please try again."
If in the receiver end I can't disable this, this is it.
But screenshots are easily faked, and IMHO might (and should) not hold up in court. This is the equivalent of hearsay.
Records of a Regularly Conducted Activity. A record of an act, event, condition, opinion, or diagnosis if:
(A) the record was made at or near the time by — or from information transmitted by — someone with knowledge;
(B) the record was kept in the course of a regularly conducted activity of a business, organization, occupation, or calling, whether or not for profit;
(C) making the record was a regular practice of that activity;
(D) all these conditions are shown by the testimony of the custodian or another qualified witness, or by a certification that complies with Rule 902(11) or (12) or with a statute permitting certification; and
(E) the opponent does not show that the source of information or the method or circumstances of preparation indicate a lack of trustworthiness.
DRM for email? that worked so great for the media industry... No thanks.
The key difference is that emails are typically intended for those the message has been sent to and not for broad distribution - they can contain sensitive content that would cause harm if broadly distributed (e.g. server names, passwords, financial data, etc.)
Media on the other hand, is intended for broad distribution but only after you've purchased a 'license' to use it.
