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 created using Dia: "Should I encrypt my email?"
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.
Seems even better for spammers and advertisers of the world since they wouldn't even have to send mail nor store it, they could just write mail server software to trivially generate it on demand, and they would instantly know who's opening their mail.
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")
But taking a photo is always doable. This is a standard argument. If you can't trust the recipient to preserve privacy then there isn't a technological way to defeat this kind of information leak.
Actual authentication is really difficult for anything.
For a more exhaustive system, one might store a DNSSEC result proving the key was valid. Though from my limited search, it seems DNSSEC does not sign a time-stamp.
That's an interesting idea. Unfortunately it makes Google a trusted third party. And a printout of that email would be easy to fake.
It would be nice if the report was signed by Google and timestamped (e.g. RFC 3161).
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.
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.
Email is one of the last widely used open communication protocols, and it is sad that people are so resistant to its evolution because that is exactly what is accelerating its demise in favor of proprietary software.
I agree that SSL in transit and GPG could stand to be improved, but they do exist.
> No server identity verification.
What do you want that SPF+DKIM doesn't cover?
> No delivery confirmation.
Good? That sounds like asking for abuse. And in any event, it's no different than inline remote images (which of course are blocked for the same reason that delivery confirmation is a bad idea). Unless you just mean being sure that the message got to the target server, in which case I agree that the best we can do is delivering it directly to the target MX and see that it confirmed that it received the message.
> No push standard.
Temporarily true, pending JMAP (which I suppose strengthens your point about needing innovation).
> No concept of groups or other ways to categories and manage access between users in a domain.
Not quite sure what this means. Do you want something like shared mailboxes and tags?
> Every provider has their own implementation of threaded conversations.
True, though in a message-centric format I'm not sure that it's a bug.
> No major provider supports non-ASCII addresses.
Not a bug in email, only arbitrary restrictions by certain providers. Also opens you up to unicode normalization attacks (phishing is easier if you can fake characters).
> Servers can't even agree on simple message formatting.
I'm not sure what formatting servers even care about (email is just some blobs of text strung together), but I can't really refute this without knowing what you refer to more specifically.
> Most things that make email actually useful are outside the spec and tacked on by each individual provider.
Email is useful because it lets us send arbitrary stuff (usually a text body and zero or more attachments) between federated providers. It's a simple-ish protocol that is stable and just works.
EDIT: In summary, I vastly prefer email as it is: A simple protocol that can include arbitrary information, which allows people to extend it however they want. Of course, this means that extensions are arbitrary and at best non-required, but that keeps it flexible and back-compatible.
Simple tools that do one thing well are almost always best.
What we need is a way to make E2E encryption easy and straightforward, like Signal or Wire, where it's easy, automatic and default enabled.
Hard to separate pending tasks from just conversations.
Hard to split conversations into separate threads when two topics diverge.
Leaving a conversation isn't just your decision: you have to both reply all and hope that no one else replies all using a previous email in the thread.
In a corporate email, inability to prevent mass emails from other employees. Hard to do for personal email too.
EDIT: I'm a huge fan, e.g., of the "travel bundles" Inbox creates. It's a giant win in usability for the use case of getting confirmation emails of booked trips. But you can see how it's a battle uphill that Inbox fights against the protocol, as the AI isn't always able to bundle all relevant information together, or extract key pieces of info from the email bodies.
Emails aren't tasks.
In any case, Outlook allows for assigning tasks to emails and organize them.
> Hard to split conversations into separate threads when two topics diverge.
An UI/UX design issue.
If the subject is no longer the same, one could provide an UI feature that allows them to be viewed separately.
> Leaving a conversation isn't just your decision: you have to both reply all and hope that no one else replies all using a previous email in the thread.
Leaving a conversation is my decision. I just stop replying and create a rule to delete all further emails using the same topic from the group of senders.
> In a corporate email, inability to prevent mass emails from other employees. Hard to do for personal email too.
In some emails clients, specially corporate ones, it is possible to customize how send, reply and reply-all work, either via group policies or custom plugins.
GMail has not wanted to, which is quite different from being able to.
Your use of email must be vastly different from mine then. Corporate email is pretty much a way for other people to add stuff to one's TO-DO list.
> If the subject is no longer the same, one could provide an UI feature that allows them to be viewed separately.
Many times an email conversation forks into two topics, each of which is only relevant to some of the people in the recipient's list.
Jira is for ToDo list.
So each people is free to organize on their own email client as they want to see their email threads, provided the UI provides aggregation by topic.
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.
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.
Apparently it isn't so easy. They send you a link, which you click. Then the message opens in a web page.
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!
Self-destructive and encrypted messaging is something many, many email users have wanted for years. And people who absolutely require these features (such as hospitals) have long-ago come up with similar solutions.
But "your message will self-destruct in a week" is a flawed promise because a bad actor can snap a photo of your email, apply a zany photo filter, get it printed on 11x13" photo paper, buy a colorful frame for it, and hang it on the wall of their home for visitors to artistically enjoy for years. It's not meaningfully gone unless all copies of it are gone, and this feature won't ensure that.
"Request expiration," like I alluded to in my earlier message, makes a promise that's closer to reality. A feature like that that's honored by default will help when both sides want messages gone, without overpromising. Importantly, it doesn't involve trying to take away the recipient's power over data they possess, or fiddling with the open email ecosystem too much. Trying to take away users' control over their data is a tendency that has more bad potential outcomes than good, and so is breaking the remaining openness of email.
(There're also some potential practical issues. It's more of a pain to keep documentation you were harassed over this kind of email, for instance, though since the feature is badly broken it's still possible. It breaks recipients' very-long-standing expectations about how things work, too. Folks mentioned all that when Facebook talked about support for unsending messages recently.)
The less-bad possibility is that Google just said, "well, folks enjoy Snapchat and such" and sort of didn't go that deep into the weeds. The bad-bad case is what mtgx said, that they're conscious of the bugs but consider them features.
"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.
There was an article posted recently that complained about how Netflix lets people create multiple accounts using dot variations of the same Gmail address, and plenty of people pointed out how it made no sense to blame Gmail for Netflix failing to verify email addresses: https://news.ycombinator.com/item?id=16781959
It's not as if simply making a typo and entering the wrong email address doesn't happen, either.
Also the relevant standards leave it up to the email host how to handle dots, so it's not even non-standard.
I guess spam and spam filters also have an ecological impact even if spams don't end up in our inbox.
And there are false positives too. Because of spam, we are likely to miss a legitimate message one day or another.
And I regularly see phishing on my professional inbox.
So spam is still an issue even if it is hidden, for several reasons.
Google is allowing you to hide emails from its public interface after a specific amount of time.
The headline "Google is allowing you to hide emails from its public interface after a specific amount of time" implies that this is just a change to an existing interface and would only work for recipients who use gmail.
Google, please don't mess with email standards.
Anyway, I dont know anyone relevant to me who is using gmail. Most of them are tehnical and they all stopped using gmail years ago, also more and more people are moving to self hosted solutions.
If I'm responding to e-mail from their users, I expect at least my initial response will get through. You really don't need any fancy crap like DKIM/SPF/nice IP addresses database/AI/bayes/etc. in this case to make the decision if e-mail is legitimate.
All my responses contain randomly generated ID of the message I'm responding to that nobody else than the sender and the intended recipient (me) can know. If it matches one of the e-mails their user sent me, say within a reasonable timeframe, and it's a first response or so, it is almost certainly genuine.
It just shows how little they give a crap about their own users, if they don't make such a simple check to make sure that their users can get responses to all sent emails.
Instead of making e-mail work, they're inventing bullshit like this new "expiring email" thing and making redesigns nobody asks for.
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
also, when a company finds itself under investigation in court, the judge can order a temporary halt to the ongoing process of timely email deletion so that a fair discovery process can occur.
i believe there are existing penalties for abusing the email system if evidence disappears. that wouldn't change.
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.
Why break delivery when you can break sending?
just store the contents locally, and replace the body with some URL that the user has to click..
then, when non-gmail users have been desensitized to clicking links in emails 'because gmail', and get viruses constantly, sell them gmail as a way to have email without risk of viruses.
Yes, there is a flag that means "for your eyes only", see RFC  and GPG esoteric options .
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.
You receive and email. You assume that it’ll get stored in your inbox forever.
I almost want to say it’s a bug, not a feature. And I’m pretty open to software changes even if it’s a pain to get used to. But changing something as fundamental as the nature of emails in this regard gives rise to something other than an email.
Mind you, this is a better case than for Gmail users who will probably see the content inline with their mail, only for it to disappear later.
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.
https://www.lexology.com/library/detail.aspx?g=30282c16-31e3... (HTML version)
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.
A few more privacy scandals break, and if Apple had an end-to-end encryption story that sounds roughly like: “If you’re using Apple products and services, you probably don’t need to think too much about the techy parts.” I could easily see Apple cementing their position for anyone even remotely concerned about privacy.
Apple the computer company. Apple the media company. Apple the smartphone conpany. Apple the consumer privacy and protection company? I could see it.
* On the device? Oops--device broke, guess my emails are gone forever
* In the "cloud"? -- Oops, can't guarantee encryption
Who generated the keys and how do you build trust?
For both of these, you can trust Apple do do the right thing, but that's putting all your eggs into that basket, similar to iMessage.
you're right its not an unsolved problem, its an unsolvable problem.
There is little point in encrypting mails between apple users, if the keys are kept on the apple servers. What would it achieve after all? Apple, and by extension every nation of importance would still have access.
the only reward you'd get from that is getting locked into the apple ecosphere even stronger, because now you won't be able to read your mail archive anymore unless you use an apple device.
And you obviously can kiss search goodbye. There is no way to search encrypted data after all, unless you decrypt it.
Got any data to back that up? I do, and so do a lot of my friends and colleagues.
Of course, hopefully PGP, and not some custom, private API like iMessage.
Of course, no one uses it or even realizes it's there because S/MIME is terrible.
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.
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 a trial lawyer, but I suspect that it's not a great defence strategy to deny basic matters of fact.
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.
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".
- Might it be possible?
- Could it be argued?
- Are the courts and laws up to speed on such things?
For example, how would this play in a FISA court? Special case? Yes; not plain vanilla law.
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."
Disclosure: Googler, but not on GMail.
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.