Google is testing expiring emails in the new Gmail(techcrunch.com)
techcrunch.com
Google is testing expiring emails in the new Gmail
https://techcrunch.com/2018/04/13/google-is-testing-self-destructing-emails-in-new-gmail/
249 comments
That's because Push-IMAP was abandoned a long time ago and isn't even part of the standard. Every provider out there (Microsoft with Exchange ActiveSync, Apple's MobileMe and iCloud push, Yahoo, and others) has their own push mechanism.
FastMail itself is using something non-standard, and saying it is open source and "being standardized" means nothing. See https://xkcd.com/927.
FastMail itself is using something non-standard, and saying it is open source and "being standardized" means nothing. See https://xkcd.com/927.
At least they're trying to be as transparent as possible, and working with the ietf certainly gives it some additional legitimacy. Google as usual just goes the "we're big enough, so accept it or go fuck yourself" way. They're the new Microsoft of the 90s, only much worse.
(Editor of the JMAP spec here.) We at FastMail are using standard IMAP/POP/SMTP, which we offer to all our customers to access their email. In addition, we have invested a large amount of time and resources in R&D to design a next-generation client-server sync protocol based on our deep experience with email. While we could just use this ourselves, we believe an open internet built on standards is healthiest for everyone in the long run. That's why, once we felt we had a solid foundation, we took this work to the IETF where a working group was formed. The spec has evolved considerably since then based on the feedback of many other experts in email from both the open-source and commercial world of email vendors.
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.
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.
I'd long ago deleted my Facebook account, but the #deletefacebook push did strengthen my resolve enough to finally move my Gmail over to Fastmail. No regrets.
> to Fastmail
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...
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...
Gmail is a for profit unit of Google. They'll do what they best think they can monetise.
Given the surfeit of standards compliant email available, switching to another provider is trivial
Given the surfeit of standards compliant email available, switching to another provider is trivial
> They refuse to support IMAP push, instead saving push for the Gmail API
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.
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.
"On the recipient’s side, the person was using the existing version of Gmail and received a link to view the confidential email. The recipient had to log into their Google account once again to view the content."
IMO this is an open invitation to phishers.
IMO this is an open invitation to phishers.
Oh, so Gmail is finally moving away from email. Guess it was a question of time.
If anything it sounds closer in outline to djb's proposed Internet Mail 2000 (https://en.wikipedia.org/wiki/Internet_Mail_2000) in which initial storage is the responsibility of the sender, not the recipient, thereby making spam much more expensive.
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.
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.
> djb's proposed Internet Mail 2000 (https://en.wikipedia.org/wiki/Internet_Mail_2000) in which initial storage is the responsibility of the sender
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.
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.
No, that won't happen, because the consequences are severe: they're instantly, globally, permanently and publicly blacklisted as a spam server.
That's interesting - I hadn't thought about greylisting like that; but I suppose that's one way to look at it. The sender needs to queue the mail, which effectively means "take responsibility for initial storage".
I agree about phishers. My bank does this for their "secure email". The first time I got one of their "secure emails", I first assumed it was a phishing attempt for my bank credentials.
Possibly.
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.
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.
This comment is a bit old now, but I want to clarify some things that I completely skittered over and just didn't explain adequately.
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.
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.
I think the genie's out of the bottle on that one, I can already do the same with a million other services.
Well, this gives a plausible reason for having to log back into an account you're already logged into. And normalizes the behavior.
So the next time you get an email from "google", you won't think twice about why you have to log back in.
So the next time you get an email from "google", you won't think twice about why you have to log back in.
Yeah, but I think the battle is lost. All users should always double-check why they need to enter credentials on any page from any website. I think that the simple act of logging into a site to use it has already "normalized" the need to re-enter credentials to a point beyond saving.
It just encourages and exposes a wider range of people to an attack vector. No one should be actively _training_ people to open random links in an email.
Seems annoying. No one would rely on this to keep actual sensitive info private, since you can just screen shot it.
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.
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.
> No one would rely on this to keep actual sensitive info private, since you can just screen shot it.
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")
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")
Why do people keep bringing up screenshots as some kind of evidence of something that was said? I can easily go into an email, bring up the source code, edit the email body to have some racist tirade, then screenshot the edited email and use that as “evidence” against a person.
Nobody is actually doing that. You are confusing evidence against someone versus "I better make a copy of this for myself before it stops working".
Then why not just copy and paste the text....
You'd have to go to some special measure to copy and paste the text because they disable the standard, easy copy/paste functionality.
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.
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.
You should be able to copy by disabling JavaScript
The typical way to avoid this particular problem is only to load the content via JavaScript while copy/paste are presumed disabled.
What's to stop you from removing the event listeners disabling copy and paste through the console/dev tools?
You could use that CSS rendered font someone made a while ago to make it into an uncopyable text.
This whole argument about copying is rather silly, at some point the text must be transmitted in a human readable form. At which point it can be recorded either electronically, or in the most difficult case by writing down manually what must be copied. Everything else is a question of degrees.
If you happen to be on corporate computer, access to developer tools can be disabled via group policies.
Screenshot to an OCR reader defeats that really quickly.
You can just use a browser dev tool like the chrome inspector to copy the text. I don't know what the big deal is.
The same holds for forwarding or storing email. Both can be forged, but both give some form of preserving email.
Actual authentication is really difficult for anything.
Actual authentication is really difficult for anything.
email often has DKIM headers, which are fantastic for non-repudiation
Why? You can rotate your DKIM keys daily and there is nothing that'd prove that you used any particular key at a given time.
To some extend, the fact that gmail accepted a message indicates the email passed DKIM inspection.
Only if it had strict DMARC policy (reject) at the time of sending. But it's not possible to reliably check old values from the past. No policy or quarantine policy makes the email go to spam, that's all.
Gmail stores the DKIM check result in the header of the email.
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.
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.
> Gmail stores the DKIM check result in the header of the email.
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).
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).
> 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.
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!
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!
Many companies keep copies of emails received. If the email has sensitive info, it's going to be kept around even if you "delete" it from your inbox. That's what this works around. Now the archived copy will be worthless because it only contains a link to the real content.
I seriously doubt this is true if either party is using an enterprise gmail account (you know, the ones that render the bcc list on the recipient side without prompting the sender?)
>since you can just screen shot it.
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.
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.
How does this stop google from indexing the emails?
I think we have different distopias in mind. :-)
I think we have different distopias in mind. :-)
This is only possible if one believes in the capacity to control client security on the other side. There’s also the problem that something viewable by the recipient’s eyeballs is also photographable by the recipient’s camera.
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.
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.
Email is doomed either way. The standard is indefinitely stuck in "IE6" mode, where there's few if any improvements, updates, or fixes. Everyone time anyone suggests significant improvements one of the big players (Google, Microsoft, Yahoo!, etc) says no and it stalls.
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#...
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#...
Not having improvements is a feature.
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.
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 does not work fine. There is no standard for encryption or any other information security mechanism. No server identity verification. No delivery confirmation. No push standard. No concept of groups or other ways to categories and manage access between users in a domain. Every provider has their own implementation of threaded conversations. No major provider supports non-ASCII addresses. Servers can't even agree on simple message formatting. Most things that make email actually useful are outside the spec and tacked on by each individual provider.
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.
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.
> There is no standard for encryption or any other information security mechanism.
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.
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.
Email does work fine. We have a similar solution for encryption: PGP. If you do the encryption yourself instead of relying on your email client to handle it, it works fine. Type your text, encrypt it, then put it in an email; get a response, decrypt it, and read it — it's easy, and it works. People who say PGP is too hard to use are usually relying on a plugin for their email client, or some other unreliable, "encryption magic" tool that tries to hide how PGP works behind an incompatible abstraction.
Simple tools that do one thing well are almost always best.
Simple tools that do one thing well are almost always best.
That is absolutely not the way to get people to use it. Very few people can be bothered to muck about with PGP manually. The few geeks who want it or need it are already doing that.
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.
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.
Did I say that was the way to get people to use it? No. I said it's the way to make it work. I want it to work when people need it, not to get more people to encrypt their shopping lists.
The more people encrypt their everyday communication, the easier it is for your confidential emails to hide in the noise.
That's what autocrypt (https://autocrypt.org/) is going to solve. Automatic opportunistic encryption using existing standards.
It works fine for some definition of "fine".
What's wrong with it?
That come to mind:
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.
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.
Those are email client specific issues.
How would you solve them in the client, that GMail hasn't been able to?
> Hard to separate pending tasks from just conversations.
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.
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.
> Emails aren't tasks.
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.
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.
I use email for exchanging messages with other people.
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.
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.
It seems like it would be worth all the effort if there were a fork that solved every authentication and encryption problem, and also addressed some less important things like: hey, maybe don’t use the Microsoft Word rendering engine for html.
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.
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 more things were as stable as email. It just works. It has worked perfectly for 20 years. Email I received 10 years ago is easily readable today. Email I send today will be readable for the next decade and more. In other words, it's a feature, not a bug.
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.
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.
Dont fix what aint broken ;) Email is not doomed. Actually it is getting more and more relevant, this picture might shed some light:
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.
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.
> immediately when it leaves it, it is probably just a mime header which I will gladely ignore
Apparently it isn't so easy. They send you a link, which you click. Then the message opens in a web page.
Apparently it isn't so easy. They send you a link, which you click. Then the message opens in a web page.
In which case the response will be "I can't read your mail, please resend in plain text".
Exactly. Or wget on smtp server side, recrafting it into email attachement (removing all remote links) and sending it to the user. Link like this is another way of privacy violation from google and I wont tolerate it.
#abandongmail
#abandongmail
Everything I read in the article made me cringe.
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.
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.
The same happened with GTalk, first completely standard XMPP service then some extensions to it, then abandoning. Embrace, extend...
The really bad-news thing for me here is Google decided it's good for business to try DRM for email, doing their best to take away (recipient) user control and talking about it as a feature. (They've _gone along_ with crummy ideas, of course, but _promoting_ DRM for email's a whole 'nother thing.)
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.
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.
Not many people are paying attention, but this is just another move from Google to make email = Gmail.
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.
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.
> Not many people are paying attention, but this is just another move from Google to make email = Gmail.
Agree with that.
And sad and weird. There are plenty of ways to do well in business without eroding the open nature of email!
Agree with that.
And sad and weird. There are plenty of ways to do well in business without eroding the open nature of email!
A counter argument is that email wasn't really designed with the security considerations that we have today. So while I agree with both of you, this is an eventual and necessary evolution 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.
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.
I mean, lots of security improvements that make promises that they can keep. I'm not saying they have to do my pet idea; I'd have zero complaints if they announced they were pushing 2FA to more people, or a dozen other things.
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.
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.
Nobody wants self-deleting emails. If you don't want someone to keep what you send them, possibly forever, don't send it to them.
Relevant blog post on another upcoming Gmail feature:
"Email is your electronic memory": https://blog.fastmail.com/2018/02/14/email-is-your-electroni...
"Email is your electronic memory": https://blog.fastmail.com/2018/02/14/email-is-your-electroni...
Please, let's not "disrupt" the email: it's so beautiful because it's so standard. For example, google's dot rules already ([email protected] = [email protected]) make no sense and break many applications: they need to stop.
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 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?
> it's so beautiful because it's so standard
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.
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.
Paypal still sends me someone else's email because they signed up with [email protected] whereas I signed up with [email protected]. Apparently there's some way to make an account there where the email is considered secondary and they just never verify it.
That's a problem with PayPal, not Gmail. You can't register "myemail" if someone else has already registered "my.email", so PayPal must not have verified the address (unless you accidentally clicked the verification link yourself).
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
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
Well, it's Google that behaves in non-standard way. Let's say that the user verified the email by mistake: the error and misunderstanding is created by google nonstandard particles, not PayPal.
Not at all. Imagine if "myemail" and "my.email" were different accounts: that would result in much more confusion and mis-addressed emails.
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.
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.
email was killed by spam, current email is sadly a walking zombie that's getting eaten by maggots
I have very little problem with spam; server-side filtering and client-side filtering make it nearly a non-issue for me.
Email was no more killed by spam than online discussion threads were.
Spam is still an issue. When you set up a new mail server, you are likely to be filtered by big providers because they will consider you as spam.
I've personally had issues with Microsoft and a local provider. This makes self hosting or running a small email provider hazardous, which is problematic. I never had issues with Google and Yahoo though.
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.
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.
Tell that to my coworkers! ;-) When our mail server goes down, people start calling within a minute.
Honest headline:
Google is allowing you to hide emails from its public interface after a specific amount of time.
Google is allowing you to hide emails from its public interface after a specific amount of time.
Did you read the article? That's not what they're doing. They're replacing the contents with a link that eventually stops working. Nothing is being changed in the recipient's e-mail interface.
Did you read the OP's post? They're replacing the contents with a link that eventually stops working for you. Nothing is being changed in Google's backend, so the original message can be preserved for as long as they desire.
The e-mail does not get hidden. The recipient can still see the e-mail after the expiration time. The backend has been changed, as this link feature would require a new backend.
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.
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.
I wonder how "destroyed" an email is is when the NSA/FBI wants to read it a year later. Google has no incentive to actually protect the content of "self-destructing" or any other type of emails, so it's dishonest for them to pretend to provide a private email service.
Pretty sure Gmail isn't being used for ad targeting anymore
https://mobile.nytimes.com/2017/06/23/technology/gmail-ads.h...
Oh, I didn't know that. I edited my original comment.
Is it because the NSA pays enough to rentabilize gmail?
I took out the part about ads
sometimes I just forget that ads actually exist... (except for junk mail and billboards)
In my eyes this is clearly not meant as a way to prevent malicious intentional data exfiltration; what it does is force users who want to retain and forward the data to do so in a way that leaves no doubt about their intentions, so that they can be more easily sued.
No. No. No.
Google, please don't mess with email standards.
Google, please don't mess with email standards.
Waaaay too late on that. Just try setting up your own server and sending to a Gmail address.
They're going further: this would likely be incompatible with email services from other providers such as fastmail.
I do that all the time without any problems. What issues have you seen with it?
marked as SPAM. I get that a lot
DKIM sign emails and fix reverse resolving. Had that problem too, I was highly pissed off that DKIM signed emails were still regarded as spam, even if there is no way to forge them until I fixed reverse resolve.
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.
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.
Not good at all. This should happen only if one of your servers has been compromised and spits out spam that gets logged by Google.
Does unmarking your email as spam by the recipient work? If not that would be an indication it's intentional.
Most of the big providers are shit, I wish I could shame them, but alas, I can not.
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.
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.
Interesting. I can't say that I ever get that, and I email Gmail a ton. I'm curious if Google outlines how to prevent getting considered SPAM or not. It could be that I've had my domain for >5 years as well.
An email server discriminating about what messages to accept is not breaking anything about the protocol or standards.
How are they messing with the standards?
Apparently it's against the email standard to send an expiring link as part of a message.
Well, this is finally the nudge that broke the camel's back, to leave Gmail.
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.
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.
I feel like people are missing what I think the core reason for this feature, to limit what is available to opposing attorneys during discovery.
For anyone in the Northern District of California at least, that's a pretty awful use case, for the reasons I mention above. You open yourself up to being culpable for the strongest hypothetical against you (versus just dealing with the magnitude of the worst thing that you actually did).
Unless you locally encrypt your content before shipping it to Google or any other mail server, you can never be sure that your e-mail is "self destructing".
This is a dog and pony show.
This is a dog and pony show.
Even then it is not "self-destructing", you need to ship an exe that works only after it asks your server over the internet.
Assuming gmail and g-suite share technology, I doubt any enterprise customers would be comfortable with the content of the email actually being purged. I'd guess there is some backdoor for corporate compliance and auditing reasons.
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.
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.
wait. why wouldn't at least some corporate customers be interested in this sort of thing?
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."
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."
Then a Judge says that policy is designed to hamper the police and security services based on "reasons" contempt of court and sends a CEO to jail for a month.
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
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
yes, right. that's fine. they could make the expiration time 7 years and a day.
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.
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.
Some companies may want this feature.
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.
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.
The idea sounds nice, but I would actually like it if any of the big ones like Microsoft or Google could make an implementation for end-to-end encryption using a standard like PGP or S/MIME.
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.
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.
So Google is finally admitting they are not at an actual email provider, but creating their own closed wall service.
Glad I’ve moved to fastmail.
Glad I’ve moved to fastmail.
What I'm struck by is how many people don't see value in this. If you work with sensitive data, this is valuable. A business may already trust google, but they want to send emails (even internally) that expire. I'd like it if it just expired the attachments - that's normally where sensitive data lives.
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.
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.
There is no value in it because it is a false promise. If you give someone access to data, you have lost control over it, especially if it is by email - because not everyone uses Gmail. Many of those who do do not use the web client, and email clients are ultimately controlled by end users, even web based ones.
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.
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's no way to stop someone from copying the message if they really want to. That doesn't mean a system that prevents the recipient from accidentally leaking the message has no use.
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.
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.
Though there is undoubtedly value in such a feature, it is upsetting because it further concentrates power. Presumably Google, and likely powerful people in organizations that use gmail, will still have access to the expired documents, but low level employees will not. The information asymmetry leads to real power asymmetry. </tinfoil>
That’s a bad move. It’s already hard to teach users not to sign in via suspicious link, so adding a legitimate case will be just confusing.
"In the compose screen, there’s a tiny lock icon called “confidential mode”. It says that the recipient won’t be able to forward email content, copy and paste, download or print the email."
I can see how they could prevent this happening for the average user, but do they really have some way actually stop this?
I can see how they could prevent this happening for the average user, but do they really have some way actually stop this?
I mean .. nothing stops you from taking a picture of your screen
The way I see it, it could be useful for internal emails you don't want inadvertently shared with the outside.
The way I see it, it could be useful for internal emails you don't want inadvertently shared with the outside.
Hopefully no service will go so far as to blank the screen when a lens is detected by the webcam...
1) not everything has a webcam 2) most people I know cover them on laptos with ducktape anyway
can't wait till this is used as an excuse to break SMTP compatability.
First they came for my XMPP,
and I did nothing because I didn't use Jabber,
Then they came for my RSS,
and I did nothing because I didn't read newsfeeds,
...
> 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.
> 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.
So what? We'll all just have to install a newer version of one of the many existing browser extensions that saves all our email.
About 2 years ago I received a quote in my yahoo email that on the bottom said "this email will vanish from your mailbox within 48 hours". And sure it did! I wonder how the author did that. He wasn't working for yahoo or anything like that; it was a quote not related to technology in any way.
I'm still puzzled by this one. Anyone?
I'm still puzzled by this one. Anyone?
I don't think there is any way to do that unless yahoo was in on it.
Someone possibly already building a service to undelete "expired" email.
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.
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.
What a bunch of hype garbage this is. If you send something in plaintext to a server it's already game over.
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.
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.
Except in info-sec there's different degrees of information disclosure. You seem to be focused on mitigating disclosure to government, Google, or a rogue employee of either one but the scope is significantly larger and more diverse than that.
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.
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.
There's a big difference between "self-destructing gmail" and "self-destructing email".
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.
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.
> So unless they break delivery
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.
win win!
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.
win win!
Not sending the content is breaking delivery (of email). I mean, sure, replace the headers and mail body with a link to your gopher site or something. But at that point, you're not really delivering email anymore.
Isn't that how protonmail works for non protonmail users ?
Yeah, and it's not really email either. Facebook started doing something similar for its "email notifications" a good while back. At one point, they sent the comment body in the email notification alerting you to a new comment - so you didn't have to use the (Web) app just to read a couple of lines of text. So they used to have email integration. These days they've settled for email annoyance.
Only if the PM sender “encrypts” the message with a password.
> At least the pgp spec has (had?) an "eyes only" flag that,
Yes, there is a flag that means "for your eyes only", see RFC [0] and GPG esoteric options [1].
[0]: https://tools.ietf.org/html/rfc4880#section-5.9
[1]: https://www.gnupg.org/documentation/manuals/gnupg/GPG-Esoter...
Yes, there is a flag that means "for your eyes only", see RFC [0] and GPG esoteric options [1].
[0]: https://tools.ietf.org/html/rfc4880#section-5.9
[1]: https://www.gnupg.org/documentation/manuals/gnupg/GPG-Esoter...
As a user of mail software, I don’t want the client determining what to show or not show against my wishes.
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.
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.
Seriously, this breaks the current definition of email that has been ingrained in every single person who has ever made an email account.
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.
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.
100%. What a crock this is. I would be required to do offline backups multiple times a day to keep a record. I deal with annoying tenants. Who would love their emails to disappear.
As long as I can always override the feature on the receiving end then fine. I have an incredibly bad memory and I want my email account to listen to me, not someone else.
Outside of Gmail, they just won't be emailing you the content to begin with. It's another way to keep the data on Google's servers, you'll just get a link in the email to them.
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.
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.
I got bit by working with a design shop that used Basecamp then closed up shop. Since then I download all attachments and email them to myself for easy finding later.
Google wasn't even deleting data in Google Talk when I had specifically enabled the Off-the-Record feature. It just didn't show the previous chats between me and my friends, but it was still saving everything for itself.
So why would I believe Google now?
So why would I believe Google now?
[deleted]
It's not being hyped, you are just over-reacting because it doesn't meet the use case you'd prefer. It's not a security feature and it's not about privacy. Clearly, like PGP of yore which had view-only messages, one can simply copy (perhaps screencap in this case) the message and then do whatever.
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.
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.
>> 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.
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.
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.
In fact, it can lead to worse outcomes than if you simply did nothing. In Apple v Samsung, the judge instructed the jury to assume that relevant evidence was destroyed and that said evidence would have been "favorable to Apple"—as a direct consequence of Samsung's email system, which as a rule only kept messages for 14 days.
https://www.nutter.com/pp/publication-Apple-v-Samsung-Electr...
https://www.lexology.com/library/detail.aspx?g=30282c16-31e3... (HTML version)
https://www.nutter.com/pp/publication-Apple-v-Samsung-Electr...
https://www.lexology.com/library/detail.aspx?g=30282c16-31e3... (HTML version)
I feel like client-side email encryption is a missed opportunity for Apple. Easy encrypted email would fit nicely into their narrative of “we can offer privacy features that Google can’t, because we sell you stuff”
Encryption doesn't work unless both sides use it.
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.
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.
iOS? Plus, I know folks who use mail.app. I also bet they could figure out how to instrument Safari with browser-side encryption for their cloud users.
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.
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.
Where do you keep the keys?
* 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.
* 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.
On device with the key exportable and optionally escrowed to iCloud. Key management isn't exactly an unsolved problem.
> Key management isn't exactly an unsolved problem
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.
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.
Would be interesting if they built something like SMS/iMessage, where within the ecosystem emails were encrypted but when sent outside they weren't.
Of course, hopefully PGP, and not some custom, private API like iMessage.
Of course, hopefully PGP, and not some custom, private API like iMessage.
If you're looking for an "open ecosystem" option, Mail on both iOS and Mac (as well as a bunch of clients elsewhere, including Outlook and Thunderbird) supports S/MIME encryption and signing out of the box.
Of course, no one uses it or even realizes it's there because S/MIME is terrible.
Of course, no one uses it or even realizes it's there because S/MIME is terrible.
Actually, with let’s encrypt and friends, maybe it is finally time for s/mime (with cert pinning, web of trust for the paranoid)
Apple already does this[0]. However, this relies on users creating and managing certificates and keys, which is not an easy thing for most users.
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...
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...
They already have, it's called iMessage ;)
This isn't for cases when you don't trust the recipient. This is for plausible deniability for both of you. If someone is monitoring your email, they will get the link to the content but they won't be able to read it.
[deleted]
You should checkout https://privnote.com/#
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.
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.
You're really overestimating what happens in actual jury trials. When I served on a jury, a lawyer presented photographs of evidence as evidence. Like, I'm talking paper printouts of photos that were taken on a cell phone. Juries aren't full of engineers, as a general rule. If the average person on Reddit will see a screen shot of a text message and assume the conversation happened, why wouldn't an average juror? The only burden of proof is if a lawyer can convince the jury a conversation happened.
[deleted]
The underlying mechanism there is generally that the other party doesn't contest that the printout is in fact of a picture from their phone, or that the screenshot from Reddit is in fact of something they wrote.
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 a trial lawyer, but I suspect that it's not a great defence strategy to deny basic matters of fact.
My understanding is that judges will lean towards admitting the evidence, and if the lawyers want to bring forth experts or witnesses to undermine the evidence they are welcome to. So a screenshot of a conversation might be admitted, and the opposing lawyer would have to argue or bring forth witnesses arguing that the screenshot was faked.
"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."
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.
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.
Los pollos.
Not touching the legal bits, but the comparison between privnote and GMail's thing actually help me zero in what bugs me about GMail's.
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.
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.
Not going to comment on the legal side of things, but I'd recommend PrivateBin over PrivNote. The former is open-source, and can easily be self-hosted, which should obviously be of interest to the privacy-minded folks here.
Not everyone is worried that NSA is tracking them live: virtually all are more worried about wife or dirty laundry being made public. Or an email sent at 2am after 14 beers...6 years ago.
This solves quite a few problems. Then, Google can start on other problems, like PGP.
This solves quite a few problems. Then, Google can start on other problems, like PGP.
I kind of agree. Although, it doesn't really solve anything. Look at Snapchat--your naughty photos can still be saved no matter what you do.
The point here is not to stop malicious recipients from saving the data. The point is to stop sensitive stuff from showing up in discovery in a lawsuit 3 years from now because a recipient didn't know to delete it.
Or double encryption with one key held by Google on an HSM enforced time-out so the email does self destruct.
[deleted]
Not only that but Google scans your mail to serve ads, would it now say it doesn't scan your "burn after reading" emails? I wouldn't trust them to.
They stopped doing that in 2017.
https://blog.google/products/gmail/g-suite-gains-traction-in...
https://blog.google/products/gmail/g-suite-gains-traction-in...
They no longer do this for ads. They still scan your gmail for reasons that are probably more profitable to them (e.g. any of the comments in this thread about inbox’s AI stuff).
When your garbage goes out on the curb it's perfectly legal for anyone - including law enforcement - to sort thought it.
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?
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?
> When your garbage goes out on the curb
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".
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".
Ah. But some random # could be incinerated and the bag substituted and filled with dog feces. Now the good stuff wouldn't be so good :)
Bullshit. The "garbage on the curb" situation is due to the fact a court ruled that once you dispose of garbage "in a public place", there is no reasonable expectation of privacy. Destroying email is exactly the opposite - there is an extremely strong expectation of privacy.
Easy big fella / fellette. Notice the use of the phrase "I have to wonder..." The point being:
- 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.
- 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.
Sorry, but you clearly have no idea what you are talking about. What you are saying just sounds like a parrot repeating something without a thought.
Personal attacks are a bannable offence, regardless of how ignorant another comment may be. Please don't post like that here.
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.
https://news.ycombinator.com/newsguidelines.html
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.
https://news.ycombinator.com/newsguidelines.html
This would be great... if taking (and faking) screenshots wasn't possible.
So it isn't encrypted? That doesn't seem substantially more secure.
Contact [email protected] for all your cyber problems name it whats app, Facebook snap chat anything you can think off,he is the perfect person you need when it comes to that .He will surely help you.
I wish Dropbox would do something like this as well -- let me specify that files in a certain directory will auto-delete themselves after a set period of time, or immediately after being retrieved.
This is how the end of e-mail as we know it looks like. Self destructing messages, expired attachments, disabled forwarding. Heck, they took the mail out of the e-mail.
Looks like privacy is making a big come back and fuk all these companies that gives free service in exchange to use your personal info
A better solution could be to convert the email into an image with "VOID" watermark all over the image after its expiration.
smells like “embrace, extend, and extinguish”
If you can take a picture with your phone or a screenshot of the email, what's the point?
Great. So now I have forward every email I get to some non-google email as a backup.
Not possible with POP3 I guess.
Yes possible with anything. Instead of sending the content of the message they send an expiring link which is transparent when viewed in GMail.
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.
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.
Sounds like a shitty way to do it. I know that principle, otherd have tried it.
Wouldn't self destructing emails only work if both sides use Gmail?
No, the article covers this.
The recipient receives a link instead to the content.
The recipient receives a link instead to the content.
Too bad they have to distort the truth then. They're sending an email with a link to some other non-email content. Much like when someone sends any other sort of hosted-content URL like a Google Doc or Dropbox sharing link.
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."
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."
But the link requires you to have a google account, and every google account is also a gmail account...
Actually, you can sign up for an account without GMail:
https://accounts.google.com/SignUpWithoutGmail
Disclosure: Googler, but not on GMail.
https://accounts.google.com/SignUpWithoutGmail
Disclosure: Googler, but not on GMail.
Learn something new every day... Thanks.
That’s not how email works. That’s not how any of this works.
This is terrible for forensic evidence. Many an illegal activity is captured and busted because of email records — just think of the Enron dataset for example.
As to how bad I find this is: It's more than enough to close the account.
If in the receiver end I can't disable this, this is it.
If in the receiver end I can't disable this, this is it.
[deleted]
Uhmm... screenshot the mail; self-destruction circumvented.
It wouldn't prevent humans from remembering the mails, too.
But screenshots are easily faked, and IMHO might (and should) not hold up in court. This is the equivalent of hearsay.
But screenshots are easily faked, and IMHO might (and should) not hold up in court. This is the equivalent of hearsay.
It’s interesting you call it hearsay, because this would neatly fit into some of the exceptions to the rules AGAINST 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.
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.
If it was a high-profile case and the screenshot was evidence of a crime, I’m assuming they have people that could weigh in as an expert on doctoring images?
How would you differentiate between a screenshot of an email in gmail and a screenshot of an email in gmail where someone had inspected the source and changed the text before screenshotting?
Good point. If it was the only evidence and didn’t connect with anything else it would not be substantial proof. I would think it could add to a story but not be definitive proof? You are describing the defense against the screenshot which could be backed up by “expert” testimony. Here is something I found on e-mails being edited in outlook even: https://community.spiceworks.com/topic/1135234-can-i-protect... (questionable source)
> It says that the recipient won’t be able to forward email content, copy and paste, download or print the email.
DRM for email? that worked so great for the media industry... No thanks.
DRM for email? that worked so great for the media industry... No thanks.
This is a feature available to enterprises in Exchange server and it works quite well, especially for messages with sensitive content.
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.
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.
Seems like people will figure out the screenshot approach pretty quickly here.
But what if it uses Widevine and HDCP? /s
Sorry, they hi-jack your whole system... and they alter the screen frequency/display so that even a camera can't take a picture.
Well, realistically, unless Microsoft goes along with it and builds the same implementation into Outlook, this ain't going anywhere. Business runs on Outlook, and Office 365 is the other huge part of Microsoft's revenue, outside Azure.
So from now and on, it's called g-mail, and not e-mail, and they are not compatible.
Also this seems to be a stupid idea, as who'd believe self-destructing or expiring emails would actually be ever deleted from g-servers...
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.