Context:

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.

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

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 IFTTT to my Gmail to automate some aspect thereof I can reasonably expect it to have access to my emails.

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.

The Facebook integration with Spotify allowed you to send messages and receive from within Spotify. Could you think of a way to implement this without giving the Spotify client access to those messages?

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

Even if I wanted to use Spotify's messaging client, I'd imagine a layman's expectation would be that Spotify needed access to send and receive it's own messages - it's not that obvious it needs to be able to read that email to your boss you wrote three years ago.

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.

At various stages of Spotify's life, Facebook login was required to use the service. I'm a long-time user, and I've learned about the messages feature from HN. It wasn't really even advertised in the UI, and not the reason I - or many other people - connected Facebook to it.

Ok, but were you ever asked if you wanted to grant permissions for that? Did you ever see the UI I linked?

Or is your claim that you gave only permission for profile and friends but the Spotify client had messaging permission as well?

I can't recall having any idea that Spotify would have access to my messages.

>At various stages of Spotify's life, Facebook login was required to use the service.

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.

Well you're disagreeing with a proven fact, so yeah... When Spotify released in 2011 Facebook was absolutely required. They removed that requirement a year later or so.

i can’t tell if this is snark, but as an app developer, i have considered facebook login as a means for a relatively frictionless user experience, not as a way for me to gain access to a users facebook account.

But security-wise, it is the same.

Not at all. FUD. If you're going to make a statement like that at least come with some facts. There is a massive difference between me getting login permission TO MY OWN APP, and accessing a users facebook account, or masquerading as them on other apps.

...until Facebook mishandles their end, for example, the API.

Which they have been shown to about a dozen times over this month.

I think you have either misunderstood the reports, misunderstand the API, or misunderstand how to integrate it. There is literally no way for me to accidentally steal a users data. You may not like facebook, but accusing me of putting my users data in jeopardy is just fucking cheeky.

Social logins is - and was, back then - a thing people are used to.

as a spotify user since they only used facebook login, i wasn’t even aware of this messaging feature. blind consent is not consent

but how will a user discover the new app will allow him/her to send messages from within Spotify before installation? If the user only discovers afterward, then there is no valid informed consent...

Correct me if I'm wrong, but I believe the circumstances under which Spotify would have permission to read your messages are

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.

This is a bit more like app situation on Android - if I download an SMS app, of course I’d expect it to read my contacts and read write my messages.

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.

What is now a long time ago, Google indexed the web properly. At that time it was an unparalleled feat of engineering. They solved scalability. They also managed to do this without sliding into "portal" territory and won their search dominance fair and square.

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.

Your comment is wrong in so many ways. React, Cassandra, OoenCompute, PyTorch, GraphQL: where did these come from? Facebook.

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.

HN is of two minds on quite a bunch of things, really. I'm chalking it up to different people coming and going―but it's weird, even if amusing, to see the comment section gravitate to opposite viewpoints on different occasions.

Maybe there's a daily cycle of various worldviews prevailing in the comments―I guess here's a toy project for data scientists.

More than days, I'd expect it's a matter of time zones and schedules. Someone in the USA might have a different opinion on these topics than someone in Europe and also be online at different times.

Defending Facebook in any capacity is currently outside HN's Overton Window.

I remember seeing a few comments similar to yours back then (and I agree with you).

If your addon works entirely locally, you only need to be "verified as non-malicious software", but if there is any network component then you need the "full assessment" from an independent 3rd-party auditor:

> 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

Good news for IFTT, who presumably can afford to pay this (and could use the results elsewhere).

Bad news for smaller players.

The low-end of that range is the ballpark for the low-end of the range of security assessments; the $75,000 high-end is very high; a more realistic range would be $15,000-$30,000 for typical SAAS-type functionality.

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.

Both are true simultaneously:

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

These costs definitely seem high. As a reference point - to get through the Salesforce AppExchange security review process, believe the cost is $2,700. It’s an extremely rigorous security testing as one might imagine with corporate CRM data.

Is that ran by SalesForce? If so, could they be subsidising it?

Yes AppExchange is run by Salesforce and they likely do subsidize the security review. They also take a percentage of revenues from direct AppExchange installs(believe 15-25%) after listing. SF wants third party devs building out functionality and the ecosystem. Google seems to be taking a different approach...

Seems like a business opportunity for somebody to create a compliant API that allows other people to write software that accesses gmail data in a limited fashion.

I'd say that this is nearly impossible.

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.

Their TOS explicitly forbids doing that.

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

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.

Smaller companies might have smaller blast radii, but that's cold comfort for the 4,999 people whose data would be lost in a breach. I don't think allowing small companies to externalize security risks is a good plan; neither, apparently, does Google.

I agree on principle that no company should be allowed to externalize security risks.

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.

Which is why an early part of the discussion, before the engagement starts, what the architecture of the application is and what technology it is built out of and where it is hosted.

In a competent code-assisted penetration test, nobody is going to charge $10k to test endpoints for SQLI when the application doesn't use SQL.

I sure hope they can afford it. When I asked them how I could integrate my side project with them, they quoted me $10k per year.

The missing detail here is the policy requires a third party audit which is expected to cost ~$100k.

Most small startups won't think that's worth it.

This case is different. IFFT is entirely about you explicitly giving it access to individual services of your choosing, in order to make them interoperable via the scripts you explicitly create there. It's kind of obvious IFFT can see your e-mails if you connect it to add a script triggered on "When new mail matching XYZ arrives".

Do you really have control if you're making a choice you don't understand?

Yes, having a choice gives you more control than having that choice made for you.

What's funny is many of these IFTTT integrations appear to have been written by the Google Gmail team themselves.

Like this one, for example: https://ifttt.com/applets/jMfVncBv-press-a-button-to-quickly...

That's not an integration, just a task/applet.

It's hard to look at it in a way that doesn't seem like Google/Gmail is highly involved: https://ifttt.com/gmail

Here's IFTTT's statement:

https://help.ifttt.com/hc/en-us/articles/360020249393-Import...

A little odd statement. I am in no doubt that it would require "massive back-end & infrastructure changes" as they point out, but this is the business model for IFTTT. They integrate these services as doing it yourself is a pain in the ass.

Yeah, it read as "we've managed to outsource the work and just reap the profits, and now Google wants us to work again? Nope!"

I run a company that, among other things, provides a service for GMail users that depends on mailbox access. We did have to jump through a few hoops to retain our status with Google recently but I'm scratching my head to think of exactly what IFFT is talking about in this post.

And now I will have to write my own thing with imap suport, find a place to host it, integrate with Dropbox's API etc. Thanks, Google. I think I'm seriously moving out.

When you register an account in Facebook it tells you to connect your Google account to check for the confirmation email. There's no button that says 'no thanks', it kind of makes you think it's the only way to go forward. I don't want to know what kind of information they scoop out, but I guess, all that they can. It's incredible. But here, IFTTT is the problem... I'm pretty sure they don't care about your emails.

More info on the reddit threads:

- Main one: https://www.reddit.com/r/ifttt/comments/b3umeo/gmail_is_bein...

- Alternatives: https://www.reddit.com/r/ifttt/comments/b3zv1z/alternative_t...

I got the exact same email but substitute IFTTT for Gmvault, which I use to make backups of my emails.

Yeah, there's an issue with a few comments already: https://github.com/gaubert/gmvault/issues/335

Will IFTTT update to comply?

Also, does this prevent sending emails to my Gmail, as opposed to reading? That was what I used the most.

No, IFTTT doesn't intend to update to comply. See: https://help.ifttt.com/hc/en-us/articles/360020249393-Import...

They’ll comply if their users demand it. Time will tell

Gmail is just another email address. So no problem sending emails to your Gmail.

I'm not sure how much user security will come out of the new Gmail policies. A lot of companies will just start asking for username/password for IMAP access. Now the user is more vulnerable than if the developer was allowed OAuth access. Unless they plan to break that somehow as well.

So IMAP is the next on the kill list. RIP email.

Data privacy offers a good reason for both Google and Facebook to close the few gates that still offered access for 3rd party apps to their walled garden.

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.

IMAP still works though right?

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.

Disclaimer: Worked someplace that does something similar to IFTTT, but not IFTTT.

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.

otoh I've worked on a platform that does exactly this with flawless reliability. Yes it's a heavy lift, but not impossible.

Please define 'at scale' - I use IMAP + SMTP to download all of my personal emails, I avoid REST because it's Google-led. Are you saying my ~5K/mo emails or my employers ~100K/mo emails are "scale"?

Your personal use case is fine. I’m referring to when 100k+ customers are using it on your platform.

FastMail has been championing a new standard (JMAP) for mail messaging; hopefully it gets traction.

What is at scale mean? every account has its own connection There is nothing inherently scalable in the imap vs rest layer

It’s not about performance scaling (although you do have to contend with those issues, as you’re network and not CPU bound), but about data integrity workload management. Each time a customer submits a ticket because you couldn’t catch an edge case when IMAP polling, that’s someone digging through logs to understand why, and determine if a patch provides ongoing resolution (or if nothing can be done other than an apology). That’s not scalable past a certain point.

Hence, (hopefully well supported and documented) REST interfaces.

I think this is mostly a grass is greener scenario : you'll end up debugging that REST interface, and no two email providers supports the same REST interface. At least IMAP is reasonably well supported.

Apple's Shortcuts, too.

Claiming that IFTTT and Apple Shortcuts have not complied with Google's privacy policy. That's rich.

Seems to be the same issue for Gmail backup tools, eg:

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.

Although it doesn't necessarily cater for the home market, Zapier is suitable replacement for many use cases IMO.

What's different between the way that Zapier connects to Gmail versus how IFTTT does it? Both appear to use the same mechanism, so I guess that Zapier will get blocked soon too?

Not if Zapier paid for the audit and passed.

They will provide you a zapiermail.com email address to forward emails to - https://zapier.com/apps/email

Integromat might also works as an alternative.

Automate.io too can work for this! I guess they've passed this and Gmail Triggers and Actions are working fine.

https://automate.io/integration/gmail

I use Zapier to do some basic email parsing / echoing important and interesting things into slack and SMS. Instead of giving API access to Gmail content I filter + forward the emails to an address they provide.

Going to really miss IFTTT... auto-responding using Gmail Filters and Canned Responses only works for a few hours before it stops auto-responding.

You mean that the app I explicitly want to be able to manipulate the data I have given it access to will no longer be able to do so? Hm.

Yep, users made it clear that they can't be trusted to make such decisions, so now the apps have to comply with new requirements, including security audits by 3rd parties.

Which is totally sensible. Nobody believes end-users are qualified to assess the security risks of the applications they're opting into. It's a little like being angry at how expensive it is to inspect and qualify an airliner before allowing people to book flights on it.

What are end-users qualified to assess? Should we be able to choose what we want to eat if we aren't qualified nutritionists? People that aren't experts will certainly make poor decisions sometimes, or think they are choosing healthy food when it really isn't. Where do you draw the line?

I think Google actually has taken more or less the right stance here. I'm not entirely sure that most people understand the difference between "click this button to make my app work" and "click this button to make my app work, and oh by the way you are also agreeing to let us sell your data to a marketing firm". Clarifications like the below are good for the vast majority of users (your opinion about Google's own business model aside):

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

There should be a requirement to publish an easily-understandable description of what the app does with its Gmail access. Pay $x per year to an auditor who verifies the description.

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.

I could definitely get on board with that. My only concern is that the expense if paying a professional auditor might make startups and individuals and open source projects unable to compete, but there could be solutions to those problems.

That's basically (a subset of) GDPR, except here implement by Google to protect themselves from another CA scandal.

If your a company you draw the line somewhere near where your lawyers and accountants tell you to, on behalf of shareholders.

> Nobody believes end-users are qualified to assess the security risks of the applications they're opting into

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?

So what is the policy update and can IFTTT comply without breaking functionality?

an independent 3rd-party auditor:

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

It's unfortunate that I could get most of the functionality I need if IFTTT offered a way to confirm Gmail's request to add trigger@ifttt as a forwarding address.

Maybe the goal is to remove IFTTT and build the features into GMAIL

The goal is to not let a Cambridge Analytica scandal happen to Google.

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.

If This Then That: https://ifttt.com. It's a popular personal automation service.

Google reports straight to NSA cia anyways all messages. Do people listening at all what Snowden revealed ?

No. GMail gave people the option of giving full access to their Gmail's mails with the user's consent. This was discovered and made up to be a scandal (people who shouldn't be able to can read your Gmail) which it wasn't. GMail then decided that the API is too dangerous to allow any 3rd party to use it, because once you grant access to someone, your GMail's security is bound to the 3rd party's security.

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.

Presumably the poster is just copy/pasting an email and isn't Google.

Correct. My apologies as I should have prefaced it with a description indicating it was an email from Google.

Maybe they want to get in front of a possible backlash, like what happened to Facebook when it was revealed that 3rd parties you used to send messages through... had access to the messages! (gasp)

IFTTT asks for a lot of access. Most people aren’t able to make an informed decision re what that means.

AFAIK, what you do with your own data via IFTTT is entirely up to you. Is there any evidence or indication IFTTT is misusing, or could miuse it? Of course it asks for a lot of permissions -- the idea is that you can use it to replace APIs for everything.

> Is there any evidence or indication IFTTT is misusing, or could miuse it? Of course it asks for a lot of permissions -- the idea is that you can use it to replace APIs for everything.

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.

IMHO, giving an additional third party access to your main email account which is usually the key to your entire online identify seemed like a major increase in security risks. I think Google's concern is less that IFTTT is going to hack you and more that IFTTT may not be securely handling this data and may be hacked.

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.

The litmus test appears to be requirements that Google says IFTTT does not currently meet:

> These apps haven’t yet complied with our updated data privacy requirements announced on October 8, 2018