Hacker News Reader

Comment by PantaloonFlames | Hacker News Reader

If you install an add-in, or an app, and it wants to read any of your stuff managed by google (emails, drive contents, calendar, etc) the app must request user consent. This user experience is well known and understood. The user must sign in and then also grant consent specifically to the app in question. If the user grants consent for the app to “read email” then the app will be able to read your inbox.

The article is saying that _humans_ employed with the 3rd party app development company are also able to see your email.

Users might reasonably conclude that When they grant consent, the app – the 3rd party computer software – would be able to read their email, but no human would be able to read their email. Well it turns out, once the app has consent, the app, if its designers make it so, could read your email and then save your email elsewhere. And then humans could read the contents of that email elsewhere.

View on HN

There is a difference between "the app can read email", i.e. this piece of software that runs on my computer / my phone / in a Google datacenter can read emails, and "the app can read email", i.e. the app siphons your email off into a third party server, with no privacy or data protection safeguards.

This user experience is well known and understood in the desktop world. Leave it to internet adtech companies to disrespect user's expecations for privacy and personal data protection.

Google could be more honest and label the permission "this app will make your email public for all intents and purposes".

> Google could be more honest and label the permission "this app will make your email public for all intents and purposes".

How is offering the worst case hypothetical of what the 3rd party might do with your data _more honest_ than refraining from hypothesizing?

Because it turns out that the hypothetical case wasn’t so hypothetical after all.

Because that's what's happening. Having an app with both "read email" and "network access" is basically saying "this app will siphon your email to an unvetted and likely unsecure third party location". You wouldn't want your bank account info treated the same, would you.

Would it be that hard to raise the user's awareness right then and there? Bonus points for offering a sandboxing mode, where the app can only access certain network locations, like Google IMAP servers, and only Google IMAP servers. Extra bonus points for auditing traffic from sandoxed apps to catch them if they try something fishy.

That’s not the same as making your emails public, ie posting them in a world readable archive.

Right. Outlook 2010 can read my email. Doesn’t mean I expect random engineers at Microsoft to be able to read my email.

> Doesn’t mean I expect random engineers at Microsoft to be able to read my email.

The basic problem is that unlike with SMS, where what gets displayed is what you sent, with email what gets displayed to the user is probably best described as being vaguely 'inspired' by what the sender wrote. Email clients need to make tons of decisions on things like typography, threading, displaying metadata, handling attachments, sanitizing user input, unicode and emojis, phishing, etc.

Even within major email clients like Gmail, threads and messages regularly don't parse correctly. When a user reports that something is broken, or when an exception gets raised by the app because something doesn't parse properly, then it's not unreasonable for a developer to use that as fixture data to try to fix the issue, as long as this is explained in the privacy policy. In fact if you care about making / using good products, this is exactly what should happen.

E.g. in our privacy policy it says, "If you let us know that an email thread isn't being parsed correctly, we may retrieve and store that specific thread for testing and debugging purposes."

A privacy policy that nobody ever reads is a poor place to put that. If you want informed consent, when they report an email thread parsing error specifically ask if including contents is ok.

> A privacy policy that nobody ever reads is a poor place to put that.

Leaving that out of the privacy policy would be legally and ethically problematic. You should also tell people at the point where data gets used (unless it’s obvious), but everything your site does needs to be in the privacy policy.

GDPR turns that should into must and has no "obvious" clause.

http://www.privacy-regulation.eu/en/recital-32-GDPR.htm

https://privacylawblog.fieldfisher.com/2016/the-ambiguity-of...

Sure. I'm not saying it should be left out. Just that nobody should expect that users have read the privacy policy.

What if the program reading it is Insider Trading Tip Detector?

That’s why every app has a privacy policy. Technology can only limit access and use cases so much, beyond that you need to rely on regular old legal agreements to provide further guarantees.

This works fine for HIPAA, FERPA, etc., and it works fine for email. No need for anything new, beyond more OAuth scopes.

Edit: I created tickets for more Gmail API scopes. If this is something you care about, star the tickets or whatever:

https://issuetracker.google.com/issues/111096405

https://issuetracker.google.com/issues/111084656

HIPPA is a standard negotiated by a lot of interested parties and approved by Congress with compliance monitored by regulators. Privacy policies are made up by one side, with compliance up to the same side. If both of those things work "fine", I'd consider it a miracle. Facebook has a privacy policy, for example, and I don't think that worked out quite as well as HIPPA does at your average hospital.

> That’s why every app has a privacy policy

Privacy policies are not effective. Users don't have time to read all the privacy policies or to shop for apps that provide real privacy, if one exists. Users don't have the expertise to understand the systems, the policies, or the implications of surrendering their information.

The evidence seems strong that it is beyond most users. Usually in those situations there is regulation, as there is now in the EU. For example, banks can't charge variable interest rates that escalate to 50% and say 'it was in the agreement'. Airlines can't sell you a ticket to Oslo and then fly you to Rome, and say 'change of flight plan was in the agreement'.

> Technology can only limit access and use cases so much

If it was in Google's interests, I bet they could find a way.

> Users might reasonably conclude that When they grant consent, the app – the 3rd party computer software – would be able to read their email, but no human would be able to read their email.

Users can reasonably conclude that, because of the very poor state of user privacy knowledge, but they are still incorrect. It's rare the third party that can add something useful to a web application which doesn't also necessitate the same privileges that would allow data exfoliation, and which isn't usually added by the first party developer fairly quickly.

Education is needed here.

data exfoliation lol

Ugh, phone autocorrect has been killing me lately. ;)

I don't think most users reasonably conclude that and I'm not sure education is required to tell them this which they likely already know. I believe the issue is they don't care. They happily give a third party access to their email. I don't think education makes a difference here nor should it to those that don't value their privacy as much as some of us do.

> the 3rd party computer software – would be able to read their email, but no human would be able to read their email

I wouldn't assume that. Software is written by humans so ultimately if data is out of Google's hands, then there is no control over who gets to read it.

> Well it turns out, once the app has consent, the app, if its designers make it so, could read your email and then save your email elsewhere

Does that really qualify as an "it turns out"? Every technical person who saw this would understand that this was an obvious capability. No one was surprised. Be serious: were you surprised?

Note also that the article points out that this kind of storage is likely a violation of the developer's contract with Google, which contains the standard privacy requirements.

If I am giving an app explicit permission to read my email then I would expect to be asked if I give it permission to send/write/save my email. If the user isn't asked that question then why would they think the app can do that. Full disclosure >> I am a technical person.

How do you propose to enforce such a restriction? This is the halting problem. If the app can read it, it can copy it.

Not true. There can be capabilities connected to the data stream and objects used to read emails and both platform and Play Store can reject typical invalid use. (Just like with intents giving temporary permissions.) It would also patch some confused deputy bugs.

Make that part of API 29 or such to not break apps.

Very sneaky use can be partly detected too, but then we're talking specifically malicious apps.

It sounds like you're trying to reinvent something like Perl's "taint" bit, but for privacy specifically? No one does that. It really didn't even work as much of a security barrier for Perl CGI scripts in 1996...

The app can post your data to anywhere it has access to. This is commonly known as data exfiltration. The common way to prevent that is to run the app in a secure sandbox. Most OS don't provide such capability in a usable way.

How do you run an email app in a secure sandbox to prevent data exfiltration? The app's primary purpose is to send and receive data.

Android has capability control tied to certain kinds of specific objects such as intents and binder connections. This could be extended to streams and providers (like the one used to read email) and objects created from such streams. Would require some internal API change and to document the change in permissions.

The new permission would mean the app is allowed to send contacts or emails read from database over the network.

Yes, that's how software works? I mean, once you've given software access to your data. You can't statically verify what software is going to do. Users shouldn't trust random third party developers with their data.

Reply on news.ycombinator.com