Google has been letting app developers read users’ Gmail
forbes.com
forbes.com
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.
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".
How is offering the worst case hypothetical of what the 3rd party might do with your data _more honest_ than refraining from hypothesizing?
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.
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."
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.
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:
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 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.
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.
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.
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.
The new permission would mean the app is allowed to send contacts or emails read from database over the network.
I'm a little confused honestly; how is the headline not just a fancy way of saying "Google supports third party email clients"? Or even "Google supports IMAP"? Wouldn't the real scandal be if they didn't?
There's always a tension between freedom and security here, but I'm honestly not at all okay with the balance this article seems to be advocating.
Google itself has reported major privacy /security bugs in third party integrations.
That option exists. It's called not adding a third party app to your Gmail and clicking its consent button.
Okay, so now you have a third party email app that...can't send and receive email? It's not that it's hard, it's that it's basically precluded by the nature of what we're trying to achieve. I installed a third party email app so that it could talk to the network. That's what email apps do! :)
The solution for you, I think, is to just not use anything but the official gmail app while on a trusted device and network. Very sensible! But not a good option for everyone.
Also, depending on the email client and its purpose, siphoning the email to the server might as well be a valid use case. e.g., I can think of an app which manages my email by smartly figuring out which email is important and/or urgent. For the app to achieve this, having access to the email body is critical and a valid use case.
This is about peace of mind. As a user, I would appreciate the option of "lock data to device" and knowing that my data stays on my device no matter what apps I install, no matter what permissions they ask for, no matter what they fine print says, no matter how good at securing their servers they are. I'm OK to have some apps not working anymore. You only leak data once, but there are thousands of apps to choose from.
Unless I explicitly take the action to "unlock data on device", which hopefully is accompanied by messaging about the high potential risks to privacy, "are you really sure" kind of UI experience.
Make data protection a BigDeal[TM].
Ninja edit: added SMTP on the list of whitelisted servers.
If it can't fetch arbitrary images from the internet, it can't render HTML email which (even if you don't want it) is a feature many people require. Even worse, if it can't talk to Google's SMTP servers, then it can't send email, which again is a feature most people require from an email client. (I mean, it's one of the two fundamental features of an email client, so...)
But if you can do either of those, you can exfiltrate data. And since data to arbitrary third parties is fundamentally what an email client does, that's probably unavoidable. :)
(And keep in mind that when dealing with third party email clients, it's very much a one click experience to configure them to both send and receive email.)
> What desktop apps have been doing since forever [I hope!].
That's never been a technical restriction placed on desktop apps. Historically they've had no restrictions, and more recently with app store sandboxes they don't have that kind of restriction. The most restrictive sandbox mode applied to desktop apps that I know of (the OS X app store sandbox) is designed around allowing apps to talk to the network freely, but restricting their access to local resources, the exact opposite of what you want.
> Make data protection a BigDeal
I endorse this goal, but I don't think this is an avenue that leads to a solution.
If it were, you could have separate permissions for combining mail provider with network streams.
I'm technically aware enough that I haven't used any of these services, since it seems to have bad idea written all over it. But I'm not surprised that the average user wouldn't be that technically aware - I just never was able to convince people I knew that it was something worth being concerned about.
So rather than scorn for the users who never thought about this before, I think it's great that people are starting to be more aware of the compromises we've made in the name of convenience. There are other ways to build these sorts of systems, and many of them would be less prone to abuse.
It’s rapidly becoming clear that once you give your data to third parties in unencrypted form, all bets are off. Any assumption that the data is private or protected or otherwise not subject to abuse is an unreasonable one. And that fact is intrinsic to the cloud (and the biggest weakness of cloud computing as a concept—at lesst, with putting logic in the cloud as opposed to treating it as dumb storage). Cloud computing is fundamentally incompatible with peivacy.
If you choose not to share it with third parties (e.g. via additional app permissions)... then it's private and secure.
If you choose to share it with third parties... then it's only as private and secure as you deem those third parties to be.
I suppose cloud servers can be hacked by malicious actors, but so can your local machine, and chances are that Google is able to better defend its network than you are.
Wait, what did you expect? You're giving someone access to all your information, what were you expecting?
If you give someone the code to access your school locker, that person has access to your school locker. Seriously, a 9th grader understands this.
> Cloud computing is fundamentally incompatible with peivacy.
You're fundamentally wrong.
https://www.theguardian.com/media/2018/may/04/google-faceboo...
And: https://www.recode.net/2017/6/26/15878518/yelp-oracle-news-c...
(Disclaimer: I'm a Google employee, but also an avid WSJ reader)
That said, this does smell like a hit job.
Podcast: https://pca.st/9jFw
[0]: https://www.macrumors.com/2018/07/02/third-party-email-apps-...
The actual news story that this is based on (which, for some reason, is completely ignored by this article), is that there are several third-party mail clients engaging in questionable behavior[1]. This is not limited to Gmail, but any of the services that the apps are compatible with, including such classic standbys as IMAP and POP3.
[1] https://www.macrumors.com/2018/07/02/third-party-email-apps-...
What's more surprising is the ability to earn a living by pinning one-sentence opinions to synopses of other writers' articles.
They were very clear when they introduced ads based on your email that only a machine would read it. But by opening up access to third parties, they can no longer guarantee that. So this betrays their users and the expectations they have encouraged.
It would have been so easy for me to click through a permissions request, as I would have assumed any permissions were pretty weak - use OAUTH to log in, maybe get my gender or age etc.
If you've had cause to use some app that relies on email analysis then maybe you knew about this, but I'm guessing the vast majority of gmail users are like me, and have no idea an app could request the permission to read their email, and thus provide access to employees at third parties.
The fact that this is being downplayed is disappointing, because it's not dissimilar to Facebook's behaviour in allowing third parties to read messages.
I thought Google were different; I was wrong.
Guess that switch to iCloud mail I was thinking about is now a priority.
This shows how ridiculously irresponsible Google's decision is - to allow such a huge permission to be given via a single click in the same way as much less important permissions - and even worse, mixed in with other requests.
Alternatives they could have considered:
1. Don't do this at all - keep emails private and in your control. This is the sane solution. Make the user set up any apps with IMAP access as per a mail client. The friction here would make it much harder for the user to be deceived.
2. Allow it via the app permissions, but have a completely new approval screen for it to highlight just how important this is. The screen should have have a suitable graphic for a warning (stripes etc.) and say "WARNING - you about to...", following by a multi-click path to get around it. Then require a re-entry of password and TFA. Similar to Safari's certificate warnings when visiting websites [1].
3. Build an infrastructure whereby an app can access information without it leaving Google. A sort of sandbox/walled garden where the only ways in and out are strict APIs. So a company would be able to extract summary data, but not individual mails. Don't know if this is possible; depends on the use case. Would only be partially effective.
https://www.digicert.com/blog/safari-11-introduces-improved-...
What's next? Scientists discover that the sky is blue?
But with that said, I often considered it to be a good idea to allow users to see what data is accessed by apps.
I'm working on an app that as a service to the customer allows them to see exactly which records each authorized app accesses. And also flags access that includes fields that are considered personal via GDPR.
It's a way to be able to account for which users you gave access to a specific customer's data to. I kind of like the feature and all it involves is a logging operation that gets imported into the database with an app ID, date and document ID and true/false if any of the field's were sensitive. Though I suppose if our use case had a lot of read heavy clients it could be a problem to manage all the data.
No more so than if I gave the app my password directly.
If you give someone the keys to your apartment and they rob you it is the thief's fault and your fault for trusting them. Not the landlord for making a copy of your key when you requested it.
As a user I want API access to my data. As do a lot of people. I am going to be pissed if people like you cause everyone to stop offering APIs because they think people are two irresponsible to be trusted with access to their own data.
APIs provide us data freedom. They are a good thing.
The villain here is pretty clear to me is the company that is abusing your trust by withdrawing your money not the company providing the API.
It is educating people that is broken not that APIs. I don't know when we got to be so trusting that we "absentmindedly" give 10 companies access to our data by clicking straight through a permission dialog that clearly says what I am doing. But absentmindedness is not a good reason to put padding on everything and force everyone to wear kneepads.
It's about an ecosystem that requires you to hand out a copy of the key to your apartment to strangers in exchange of minor services on a regular basis, and makes it really easy to do so.
I haven't used Android in a while, but here's a quick search that fits my Android experience of yesteryear. Almost every app I installed asked for this overreaching kind of permissions. Transcript with a little easter egg.
Glympse
needs access to
* Identity
* Calendar
* Contacts
* Location
* SMS
* Phone
* Photos/Media/Files
* First Born
* Wi-fi connection
information
ACCEPT
https://www.howardforums.com/showthread.php/1865181-A-Massiv...
Secure Element should be handled with exactly such a permission.
I’m not sure what else to say, but aside from people who have a stake in Google, or take skepticism to illogical extremes, this news can’t be surprising.
Man I really learned something about what to do about this horrible issue of APIs.
I really hate articles like this that don't have a point or provide a solution. "Be scared of this please okay thanks bye" hit piece garbage.
If I am correct, we’re going to be facing a long list of shocking APIs. I also wonder why the article doesn’t mention SOX, which might provide some liability for public companies looking at PII.
wouldn't be surprised if there are bad apples in this ecosystem too - google can't take their policies too far or it will turn into a walled garden, but for the most part it's just users choosing convenience over sanity
> Connect with Google
> When you connect your Google accounts, Ebates automatically matches email receipts and displays them in your Cash Back Activity.
And then the permissions required are:
* View/Send/Delete Email
Perhaps some internal ones take plaintext from local machines, but inter server is almost always TLS.
This isn't journalism. It's an ignorant hit piece by a paper owned by Murdoch. Forbes and The Verge should also be ashamed of just regurgitating the WSJ BS and not doing their due diligence.
https://www.wsj.com/articles/techs-dirty-secret-the-app-deve...
Non paywall link: http://archive.is/CZFiG
The greatest trick the Devil ever pulled was convincing the world he didn't exist.