Google has been letting app developers read users’ Gmail(forbes.com)
forbes.com
Google has been letting app developers read users’ Gmail
https://www.forbes.com/sites/janetwburns/2018/07/02/google-has-been-letting-app-developers-read-users-gmail-unsurprisingly/#453a83404ddd
106 comments
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.
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.
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".
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?
How is offering the worst case hypothetical of what the 3rd party might do with your data _more honest_ than refraining from hypothesizing?
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.
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.
Because it turns out that the hypothetical case wasn’t so hypothetical after all.
[deleted]
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."
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."
[deleted]
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.
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.
Sure. I'm not saying it should be left out. Just that nobody should expect that users have read the privacy policy.
GDPR turns that should into must and has no "obvious" clause.
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
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
> 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.
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.
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.
[deleted]
> 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.
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.
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.
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.
The new permission would mean the app is allowed to send contacts or emails read from database over the network.
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.
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.
> 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.
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.
> 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.
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 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.
I mean, I have installed a third party gmail client. So the app can read my email. And that means the developers of the app have access to my email. Which is why I think very carefully before install third party gmail clients!
That's...how this works. Right?
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.
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.
The article started from the WSJ, who's been running a long campaign against Google as part of Murdoch's empire.
How about sandboxing apps with access to sensitive private information from network access? I don't want my email to leave my desktop / mobile phone / Google's server, is it really that hard to have that as an option?
> I don't want my email to leave my desktop / mobile phone / Google's server, is it really that hard to have that as an option?
That option exists. It's called not adding a third party app to your Gmail and clicking its consent button.
That option exists. It's called not adding a third party app to your Gmail and clicking its consent button.
That's a rather poor option. Mac App Store and Android for example offers much better sandboxing options.
Absolutely. Even better, just not use GMail until they start taking data protection seriously.
Every other email provider also provides API access to email, typically via IMAP or POP. Your suggestion then is (instead of simply not authorizing third parties to have access to your email) to not use email at all?
There is quite a bit of friction when setting up IMAP/POP access to an email provider. If I go to the trouble of setting up IMAP/POP, it's likely I know what I am doing. To the best of my understanding, the article is about 1-click permission granting / data leak.
How could gmail take it more seriously? They even encrypt the links between their datacenters.
> is it really that hard to have that as an option?
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.
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.
Can you explain how that sandboxing would work? Can the malicious app not just transcode/encrypt email, and transmit it back to their server? How would that be detected?
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.
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.
Sandboxing. There is no network access, other than access to Google IMAP/SMTP servers. The app must operate locally on the device, full stop. What desktop apps have been doing since forever [I hope!].
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.
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.
> There is no network access, other than access to Google IMAP server.
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 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.
No need to sandbox, some android objects have permission and capability control.
It is just not propagated (and enforced enough) so you get all kinds of confused deputy problems.
If it were, you could have separate permissions for combining mail provider with network streams.
If it were, you could have separate permissions for combining mail provider with network streams.
[deleted]
There's a difference between IMAP software on your machine, and a third party company that does who knows what with your email.
I think there is a meaningful distinction between "I'm using a client running locally on my machine, distributed from known locations, and it wouldn't be too hard for someone to spot if it was exfiltrating my data to third party servers" and "I'm using a service running on someone else's servers, effectively shipping my emails through them as a middleman, with no insight to what's going on behind the scenes."
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.
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 funny how everyone is saying “of course this is how it works” while on every fourth amendment article all you read is how protected cloud content is and how its totally reasonable to have an expectation of privacy in that data.
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.
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.
Your cloud content is as protected as you choose it to be. That's a feature, not a bug.
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.
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.
> It’s rapidly becoming clear that once you give your data to third parties in unencrypted form, all bets are off.
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.
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.
mtgx(1)
This reads like a FUD hit piece. Anyone have any actual data/evidence on what's going on?
WSJ started this article, who is owned by News Corp. News Corp occasionally does anti Google and Facebook pieces. See:
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)
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)
Who doesn’t occasionally do anti-Google pieces? I’d be more skeptical if they didn’t!
That said, this does smell like a hit job.
That said, this does smell like a hit job.
Listened to a short podcast (9 minutes) with the author of The Wall Street Journal piece, and my impression was this was done as an investigative piece to see if they could find any bad actors using the system Gmail. they weren't able to find any specific actors, but they spelled out how the system was used and potentially how it could be abused.
Podcast: https://pca.st/9jFw
Podcast: https://pca.st/9jFw
Yeah, it's not clear from the article how this is much different from "Google lets app developers look at all your photos" and "Google lets apps keep track of your location". Like uh, ok, obviously. The author even admits it's "unsurprising", so what's the point of the article? It may not be a morally good practice but it's an extremely common one and hardly newsworthy. I get that there's some tie trying to be made between this and Cambridge Analytica but it seems like a huge stretch.
There isn't anything going on with the exception of ignorance on the part of the WSJ, Forbes and The Verge. You're explicitly granting a third party app access to your email. If I decide to use Outlook for iOS or Android I'm granting Microsoft permission to access my Apple email or Gmail.
I found an article on Macrumors[0] that specifically points out a company for doing so. Not sure if this Forbes article was referring to them.
[0]: https://www.macrumors.com/2018/07/02/third-party-email-apps-...
[0]: https://www.macrumors.com/2018/07/02/third-party-email-apps-...
I'm not sure what the point here is? Aren't they just basically just reporting that Gmail offers a nicer API to read email than IMAP and App Developers have been misusing it (maybe)?
Yeah, this article is apparently blaming Google for the crime of...having APIs. Everything described here would also be possible with IMAP.
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-...
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-...
The sad thing is that the technically literate might come across as "this is overhyped", because in a way it is (in that it focuses on one company), when the real sentiment is "this is what gets you alarmed now? This problem is rampant all over the place and we've been harping on it for years".
Serious question... why does this story have 100+ upvotes (so far) when virtually all the comments seem to indicate this is FUD and how API's are designed to work?
I often find stories upvoted for the comments alone. I've upvoted poor articles with great rebuttals.
It's a surprise that giving one's username and password to these plugins abdicates one's privacy?
What's more surprising is the ability to earn a living by pinning one-sentence opinions to synopses of other writers' articles.
What's more surprising is the ability to earn a living by pinning one-sentence opinions to synopses of other writers' articles.
Why are people saying "this is obvious"? I'm a gmail user and I don't find it obvious. I just checked and I've never granted third-party access, but I would have make the mistaken assumption that Google would never allow an app to request permission to read my email.
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.
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.
The part that you're missing is that you can't just "click through" a permissions request since it explicitly would include the line "This app can read all your emails". https://1.bp.blogspot.com/-DiGeWx5UEVQ/WzswMQ9VV1I/AAAAAAAAx...
Thanks for the image.
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-...
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-...
Wow, when users explicitly authorize an app to access their email accounts, the app can access their email accounts.
What's next? Scientists discover that the sky is blue?
What's next? Scientists discover that the sky is blue?
While I think this is ridiculous. My general take is you gave consent with the login page, it's not the API providers fault they misused it. You should have been more careful about who you trust.
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.
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.
It would be fantastic if they kept an audit log and showed you just what an app pulled down via the API. They actually might (or at least the means to do so) since they provide a pretty good level of auditing for their paying apps/drive customers.
What if there were a permission to "read and withdraw from your bank account"? If 1% of the users are cleaned after absent mindedly agreeing to 10+ permissions on a random app, would that not be the API provider fault?
NO!!
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.
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.
This is not about API vs. not API. It's about hiding critical APIs among benign APIs and training users to click "Accept" on a regular basis. This is a dark pattern if there ever was one, perhaps the darkest of all. It's about the company formerly led by Eric "If you have something that you don't want anyone to know, maybe you shouldn't be doing it in the first place" Schmidt.
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.
https://www.howardforums.com/showthread.php/1865181-A-Massiv...
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...
It could be a runtime permission, you have to ask for it every time unless user explicitly changes that setting.
Secure Element should be handled with exactly such a permission.
Secure Element should be handled with exactly such a permission.
It’s been axiomatic for a while that if you care about privacy and security, a generally paranoid outlook is helpful where telecommunications are concerned. Just assume that unless it’s e2e encrypted and you trust the recipient to be as paranoid, that someone else is reading your communications. Assume that if it has a microphone and an internet connection someone else could use it to listen in. Assume 5-Eyes partners archive absolutely everything and may someday have a smart enough system to really use the data. Assume FB and Google and your ISP are spying on you and building profiles of you.
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.
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.
Sarcasm
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.
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.
This seems fairly similar to the Cambridge Analytica revelation—it seems they’re reporting on access specifically granted to these apps by the user, but the data is not technically restricted from access the way you might expect when humans are involved. That is, the person isn’t authorized on access beyond having the app credentials. Does anyone else understand this? Does that sound correct?
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.
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.
The Google oauth page does say that the third party will be able to read, delete your mail. It will boil down to user's assumptions if said third party consists of humans :) Then they will be obviously able to read it. That's why I never provide access to my gmail.
these apps appear to be doing exactly what they claim to be doing, or at least the articles don't make a claim otherwise and (at least for extensions, google has a strict policy about do-only-on-thing - i just got flagged and thankfully reinstated). CA was quite different - the app appeared to be doing one thing, but was actually doing a very different thing. and from my experience, facebook permissions are so broad as to be useless (which allowed me to make a kinda cool app but is scary)
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
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
Ebates does this apparently.
> 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
> 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
[deleted]
SMTP had been letting servers talk to each other in cleartext forever. How many email providers send to each other over a secure connection? Certainly not all.
Almost all nowadays as Gmail rejects insecure input. On other servers unsecured mail input gets big spam scores.
Perhaps some internal ones take plaintext from local machines, but inter server is almost always TLS.
Perhaps some internal ones take plaintext from local machines, but inter server is almost always TLS.
Are we talking gmail-integrated apps or say a browser plugin? it doesn't really specify. I know browser plugins have stolen gmail emails in the past.
The article is about apps using the Gmail API and Gmail Add-ons, both of which using Gmail OAuth. Browser plugins have the same privacy issues, but it's hard to attribute any blame to Gmail there.
Wait, are you saying if I install a third party app, like you know a third party email client, and give it explicit access to my Gmail account I'm giving it the ability to read my emails? The horror.
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.
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.
Apple iOS does not have permission for apps to access emails at all, if I'm not mistaken.
I don't understand a legitimate use case where an app needs to have an access to a user's inbox. I understand, when you need to send email, access contacts, but not inbox.
WSJ reported this first, as linked to by Forbes.
https://www.wsj.com/articles/techs-dirty-secret-the-app-deve...
Non paywall link: http://archive.is/CZFiG
https://www.wsj.com/articles/techs-dirty-secret-the-app-deve...
Non paywall link: http://archive.is/CZFiG
Don't be evil.
The greatest trick the Devil ever pulled was convincing the world he didn't exist.
The greatest trick the Devil ever pulled was convincing the world he didn't exist.
tell me again why anyone ever thought an email “client” that’s running on someone else’s server was a good idea?
Well, ready to be amazed every day. It's pretty clear that one cant trust cloud providers with these sorts of things, especially when their business model depends on it...
I'm just as pissed off about reading contacts as someone reading emails. For some reason, about 10 years ago, apps started to get permission to read local contacts, and then just upload them to third parties and use that information. When did we let all this happen.
Security is almost never a priority no matter how easy would it be to fix such leaks...
I'm also not sure what is the point. Does this article means those third-party app can access our email without consent?
https://news.ycombinator.com/item?id=17443056