Live data from Hacker News

Google is testing expiring emails in the new Gmail

techcrunch.com

221–230 of 250 posts

Re: Google is testing expiring emails in the new Gmail

#221

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 crippl…

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.

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.

Re: Google is testing expiring emails in the new Gmail

#222
post #205

Earlier quoted context omitted.

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.

Re: Google is testing expiring emails in the new Gmail

#223
post #222
post #205

Earlier quoted context omitted.

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.

Re: Google is testing expiring emails in the new Gmail

#224
post #195
post #155

Gmail intentionally deviates from the IMAP spec, forcing email clients to either become Gmail clients or work poorly with Gmail. They refuse to support IMAP push, instead saving push for the Gmail API. Recently they introduced AMP for Email, which happens to work via emails that only Gmail can read. Now they introduce another feature which happens to work via emails that only Gmail can read. I think it's pretty clear…

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 .

(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.

Re: Google is testing expiring emails in the new Gmail

#225
post #9

Please, let's not "disrupt" the email: it's so beautiful because it's so standard. For example, google's dot rules already (ko.me@gmail.com = kome@gmail.com) 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?

email was killed by spam, current email is sadly a walking zombie that's getting eaten by maggots

Tell that to my coworkers! ;-) When our mail server goes down, people start calling within a minute.

Re: Google is testing expiring emails in the new Gmail

#227
post #110
post #87

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.

Sounds like a shitty way to do it. I know that principle, otherd have tried it.

Re: Google is testing expiring emails in the new Gmail

#228
post #216

Earlier quoted context omitted.

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.

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

Re: Google is testing expiring emails in the new Gmail

#229
post #193

Earlier quoted context omitted.

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.

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 agre…

> 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.

Re: Google is testing expiring emails in the new Gmail

#230

Earlier quoted context omitted.

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, "encryp…

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.

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.
Post reply on HN