Hacker News Reader

Comment by joefkelley | Hacker News Reader

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.

View on HN

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

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.

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

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.

Oh wow you are totally right. It had never occurred to me that Spotify requiring Facebook to use the service was a means for them to gain access to your Facebook account.

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

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.

No no, if you added social login to your app it's because you're evil. You want to monetize your users, selling their data like it's 2014. You're literally Cambridge Analytica. /s

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.

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.

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

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

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.

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.

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

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.

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.

I'm sure these are all fine pieces of software, and good on facebook for giving their smart people useful busywork to distract them from asking themselves the hard questions, but did any of these make possible the as of yet impossible and propel them to their current status?

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.

I noticed that also, especially when it comes to Google, maybe less with Facebook. Criticizing anything Google and you will get downvoted. I think it's a reflection of how many Googlers are on here.

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.

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.

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

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

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.

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.

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.

> ...explicitly installed by users who gave these apps access. But somehow people were mad anyway...

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.

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

> maybe users shouldn't be given the option to make choices they don't understand?

Not sure if this is meant ironically… but no, they definitely should not.

Beware of he who would deny you access to information^W control over your own tools, for in his heart he dreams himself your master

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.

Reply on news.ycombinator.com