Tell HN: Google removing Gmail access from IFTTT
Hello,
Although you don’t need to take any action, we wanted to let you know that the following third-party apps will no longer be able to access some data in your Google Account, including your Gmail content. This change will go into effect starting March 31, 2019.
IFTTT
We are making this change as part of ongoing efforts to make sure your data is protected and private. These apps haven’t yet complied with our updated data privacy requirements announced on October 8, 2018
You can always view, manage and remove apps you’ve given access to your account by visiting your Google Account.
Thanks, The Google Accounts team
126 comments
[ 2.9 ms ] story [ 209 ms ] threadBut this announcement just sounds like the phrase from Empire " I have altered the deal. Pray I don't alter it any further."
I have not heard of anything.
IFTTT recipes have really made my life nicer through automating certain things, which includes gmail interactions. It'll be a bummer if support cannot continue.
I understand Google's changing of the rules, but am surprised IFTTT hasn't been in front of this change.
> These apps haven’t yet complied with our updated data privacy requirements announced on October 8, 2018
I would only give IFTTT access to a secondary email address that recieves specific types of emails, possibly automatically forwarded by Gmail's filtering rules.
In ~July 2018 there was some outcry because Google was "letting third parties read your emails" (e.g. https://www.cbsnews.com/news/google-reportedly-allows-third-...). Of course, these were all explicitly installed by users who gave these apps access. But somehow people were mad anyway - maybe users shouldn't be given the option to make choices they don't understand?
Anyway, as the message mentions, Google announced new requirements for these apps on October 8: https://cloud.google.com/blog/products/g-suite/elevating-use...
Apparently, IFTTT (which does personal automation, integrating with many third parties), does not comply with the new policy.
ala brexit!
> The assessment fee is paid by the developer and may range from $15,000 to $75,000 (or more) depending on the size and complexity of the application. This fee is due whether or not your app passes the assessment
Bad news for smaller players.
This is simply what professional security assessment costs. There's a lot of competition and a diversity of firms, and this is the range the rates float in.
It doesn't make sense that small companies should be allowed to circumvent the requirement when what they're doing is just as sensitive as apps from large companies.
* professional security is needed, and this is what it costs
* the cost is more of a barrier to smaller companies (and hence provides an advantage to larger companies)
It seems like an inherent tension; I'm not sure how to get around it.
We talk about two different data sets here: * The actual User data. * Data from third persons, including, but not limited to their e-mail address.
While a user can agree that their own data should be processed by a third party, the problem is that he cannot consent for other people.
And in my understanding (INAL), every part of the software where those third person information is transferred or processed needs to be part of that full assessment.
A limited API that does not give out any third persons data would have to somehow filter out all the information of all third partys.
If they really are small companies then (in most cases) what they're doing isn't as sensitive, because the value of the assets under protection is lower. It would be completely reasonable to say that companies with less than 5,000 users only need to be assessed for vulnerability to automated attacks and not targeted attacks.
If you're a company the size of Facebook and you're accidentally sending password reset tokens to your analytics partners then that's a disaster. But I don't know that it's worth shutting down hundreds of startups with a couple dozen users each over the sort of potential security weaknesses that, while not ideal, realistically aren't going to result in anyone having their private data exposed.
Where I disagree is that for a small company that doesn't use SQL, being forced to pay someone $10,000 to spend an extra week testing every single endpoint for SQL injections isn't going to mitigate any potential vulnerabilities, nor would being allowed to opt out of that requirement externalize any risk.
And if we're going going to say that companies shouldn't be allowed to externalize risk then that requires some baseline understanding of what risk actually is. And at the end of the day, it's impossible to separate risk from the value of the assets under protection, as Bruce Schneier has been saying for 20+ years.
Yah, and we know that 99% of folks just next - next - next when installing everything on their phone, laptop, console.
So many apps want access to stuff that isn't obvious (e.g. games that want to access your photos, emails, and msgs) though most people skip the alerts when installing.
Not sure if this is meant ironically… but no, they definitely should not.
It's interesting to see the difference in attitude on HN towards Google and Facebook. Many readers on HN shared the media's outcry when it was "revealed" that Netflix and Spotify were given read/write access to users' messages if they had authorized those Messenger plugins/platforms. I'm not attacking your position--I wholeheartedly agree with it--it just seems like there's a double standard on HN when it comes to certain tech companies.
If I connect my Facebook to my Spotify so that I can log in with one account and maybe share music with friends, I don't expect Spotify to have access to my private messages.
Obviously context is important, but I'm not seeing the double standard.
1) if you use their Messenger app plugin
2) if you had connected to Messenger through Spotify's desktop app. I believe this feature has been deprecated for a few years now, though.
Even if you sign up for Spotify using your Facebook account or connect your Facebook account to Spotify that does not give them access to your Messenger messages. It is my understanding that it required the user to opt into specifically connecting Messenger for that circumstance to occur.
What’s more, users explicitly opted in, giving Spotify permission to do so. [1] No reasonable person would use Spotify to send and receive messages after explicitly granting the client permissions and then claim “but I don’t expect Spotify to have access to my private messages”
[1] - https://stackoverflow.com/questions/17561784/django-social-a...
Which they have been shown to about a dozen times over this month.
Or is your claim that you gave only permission for profile and friends but the Spotify client had messaging permission as well?
I disagree. I have perused various trials for Spotify and other services over the years and never once had to resort to using a Federated ID/login.
Of course as a technician with knowledge of how OAuth and web APIs work, the implication that it really needs access to all messages seems a lot more reasonable - but I don't think this view is necessarily valid in a larger context.
Implementing more fine-grained permissions is absolutely possible. See e.g. Telegram: Even though Telegram bots appear as mostly ordinary users, they by default cannot access the messages of the channels they joined - they can only access commands that users were explicitly sending to them. You need a special permission to have a bot actually be able to access a channel like a human user would.
If I download a calculator, it has no business reading location, call logs, messages, contacts, full filesystem. That would make me outraged, even if I did technically click through permissions.
Maybe there's a daily cycle of various worldviews prevailing in the comments―I guess here's a toy project for data scientists.
FB never did anything but being at the right place at the right time and were pretty nefarious from the very start. If any innovation can be claimed to have come out of FB, it's new ways of large scale psychological manipulation.
I suspect it's the memory of those early Google years that make some more lenient towards Google, although at this point, they really shouldn't be.
Facebook has had to pull off their own feats of engineering. It is a fact whether you like their product or not.
I work for FB. I am leaving for my own personal reasons. It is not a perfect company. Your comment, however, is wrong and I am calling it out as such.
Because as things appear, FB was a myspace for grown-ups at a time when there was a need for such a service, that is, the right time and the right place, and technology-wise there was nothing extraordinary about the service itself.
> It is a fact whether you like their product or not.
I like their product just fine. I just wish more of them held their privacy in higher regard.
Most small startups won't think that's worth it.
https://automate.io/integration/gmail
It's strange that IFTTT would use some non-standard interface and that's why I'm asking.
I don't think I can keep using gmail if IMAP breaks.
You do not want to use IMAP for integrations at scale. You run into all sorts of weird issues retrieving and deduplicating messages. It’s a terrible black box to troubleshoot. The Gmail REST interface was a huge improvement over IMAP. If you can get access to the REST interface, you want to use it.
While IMAP is a legacy compatibility mode, I would not call it a “standard” interface for this purpose.
FastMail has been championing a new standard (JMAP) for mail messaging; hopefully it gets traction.
Hence, (hopefully well supported and documented) REST interfaces.
Also, does this prevent sending emails to my Gmail, as opposed to reading? That was what I used the most.
"3rd-party apps accessing these APIs must use the data to provide user-facing features and may not transfer or sell the data for other purposes such as targeting ads, market research, email campaign tracking, and other unrelated purposes. (Note: Gmail users’ email content is not used for ads personalization.)
As an example, consolidating data from a user’s email for their direct benefit, such as expense tracking, is a permitted use case. Consolidating the expense data for market research that benefits a third party is not permitted.
We have also clarified that human review of email data must be strictly limited." [0]
[0] https://cloud.google.com/blog/products/g-suite/elevating-use...
As long as the [I agree] section says "We send all your email to market researchers for money", then it's fair game to publish.
Maybe not. Probably not. But I sure know I don't want to lose any freedom. Can this be mitigated with custom-generated API keys?
> The assessment fee is paid by the developer and may range from $15,000 to $75,000 (or more) depending on the size and complexity of the application. This fee is due whether or not your app passes the assessment
(snipped from above)
Like this one, for example: https://ifttt.com/applets/jMfVncBv-press-a-button-to-quickly...
The sensible thing to do was to make the scope of access more clear while granting access to the 3rd party as well as making sure the 3rd party is following security best practices.
I don't see how this is Google's fault.
If users all choose to share their emails with a third party service, and that third party service leaks/abuses the mail, Google will get blamed.
Google doesn't want that, so now stops you choosing to share mail with all except the biggest companies.
https://help.ifttt.com/hc/en-us/articles/360020249393-Import...
- Main one: https://www.reddit.com/r/ifttt/comments/b3umeo/gmail_is_bein...
- Alternatives: https://www.reddit.com/r/ifttt/comments/b3zv1z/alternative_t...
Claiming that IFTTT and Apple Shortcuts have not complied with Google's privacy policy. That's rich.
And I don't think I can blame them. This kind of access provided very little benefits for them, but it has turned out to be a big PR problem.
https://github.com/jay0lee/got-your-back/issues/195
Frustrating, given Google's own takeout tool doesn't work on larger inboxes! This is basically going to destroy the tools that were papering over gmails cracks.