No boundaries for Facebook data: third-party trackers abuse Facebook Login

https://freedom-to-tinker.com/2018/04/18/no-boundaries-for-facebook-data-third-party-trackers-abuse-facebook-login/

by randomwalker • 8 years ago

601 117 8 years ago

IBM4• 8 years ago

I can't wait for PWAs to be the future of apps. /s

Apple should take the new Firefox Facebook extension and apply it by default to Safari. But also do Google and every other major ad-tech company. Not sure if this can be done without breaking the web though. Also not sure how different Firefox's extension is from Safari's Intelligent Tracking Prevention. It's possible they already do this.

908087• 8 years ago

Not sure if this can be done without breaking the web though.

If that's the case, the web is already broken.

Spearchucker• 8 years ago

They have a place but PWAs are no panacea. There are still things I want physical control of, like anything I need client-side encryption for. Fighting one extreme with another has been human nature, but isn't prudent.

underwater9• 8 years ago

PWAs will do nothing to address this problem.

IBM4• 8 years ago

I was being sarcastic but I realize now that I was probably getting upvotes from both camps.

nozzlegear• 8 years ago

I can't wait for PWAs to be the future of apps. /s

Genuine question, I don't do much mobile development: aren't native apps able to collect just as much information as a web app/site? Except with a mobile app you can't just open a Dev console and see what requests are being made?

Again not trying to troll, I just don't know if I'm missing something here.

cpeterso• 8 years ago

The difference, as I understand it, is that third-party code would not be able to snoop on user data in Facebook's native app. In this paper, the third-party JS is able to get itself loaded on the same page as the Facebook user data.

IBM4• 8 years ago

A native app could leak/abuse information like a web app, but in general the surface area is way smaller for that to happen on iOS (which is what I'm most familiar with). Everything is sandboxed and Apple strictly controls how apps behave in iOS with the types of APIs that are available and the design of those APIs (there's a reason why Google is desperate to have you sign-in when you use their apps on iOS). And when something is being abused Apple can do something about it [1]. You could put some third party "analytics" framework in your app that happens to be a bad actor (or compromised) that sucks up data in some way, but at least Apple can remove misbehaving apps because they control the App Store.

So there might be technical reasons why native apps are more privacy preserving than web apps, but I think that pales in comparison to having an actor that actually follows the principles of Privacy By Design running the platform [2]. If the platform owner doesn't actually want to vet what goes in their stores beyond "machine learning" [3], had a useless permission model until recently, or does dark pattern bullshit [4], I doubt there's much of a difference between native vs web apps.

At the end of the day the only thing that matters is incentives, and that informs how these actors will behave.

[1] https://www.theverge.com/2013/3/21/4133288/apple-to-finally-...

[2] https://en.wikipedia.org/wiki/Privacy_by_design

[3] https://gizmodo.com/google-boots-fake-ad-blockers-from-chrom...

[4] https://qz.com/1131515/google-collects-android-users-locatio...

pornel• 8 years ago

Native apps have the same problem. There are "SDKs" for analytics, social sharing, and "monetization" that are native equivalents of putting <script> in your app.

the_snooze• 8 years ago

Are there any usable solutions for end-users besides wholesale blocking of ad/analytics/tracker services? With all this, it seems pretty reasonable to assume all third-party elements on the web are hostile.

kevin_thibedeau• 8 years ago

NoScript + self destructing cookies.

the8472• 8 years ago

All solutions break things to some extent by design. So "usable" would be quite subjective.

ve55• 8 years ago

Those sound like the perfect usable solutions. Do not run code on your machine (Javascript) unless you want it to be ran. The only good way to do that if you use a modern browser is using extensions to help you do it. It's definitely true that most third-party Javascript is not good for you, and just tracks you in malicious ways, slowing down your browser and putting your data at risk.

watsocd• 8 years ago

Never use the "Login with Facebook" or any other 3rd party login method. Create a separate account on the site if you need to log in.

underwater9• 8 years ago

If a script running on the page wants to scrape your data then creating a new account isn’t going to protect you. In fact it’s probably worse, because the malicious script can sniff your login details.

albemuth• 8 years ago

There's a few sites I continue to log in with facebook, I just make sure to use an incognito window and close it when I'm done.

scrupulusalbion• 8 years ago

it seems pretty reasonable to assume all third-party elements on the web are hostile.

The trouble is that a lot of good and bad JS/CSS/content is gotten from third-party sites. Some websites are simply useless unless your browser loads third-party JS (e.g. Bootstrap). The ability to load third-party code/content is built into HTML and web developers naturally take advantage of that capability.

paulie_a• 8 years ago

Then it is time to stop using those websites.

acqq• 8 years ago

Some websites are simply useless unless your browser loads third-party JS

These sites are definitely making the problem much bigger, typically not even caring.

The developer a site actually gives instead of a user an access to the user's data to any other entity from which the developer "just references the scripts or fonts or whatever" to shorten his development time.

A huge problem. The article that we comment to shows very specific examples.

andrewaylett• 8 years ago

Firefox's multi-account containers (and/or first-party isolation) would go some way towards helping, in that Facebook's cookies wouldn't be available to tabs not opened in that container. That helps with the "embed an iframe to steal data" case, but not with the "user logged into a site that includes malicious third-party JS" case.

Privacy Badger assumes that third-party scripts used by more than one first party are potential trackers and blocks them by default, except common CDNs which just get cookies blocked. It's pretty usable: doesn't break nearly as much stuff as NoScript et al, and unlike an ad-blocker only blocks ads that track.

cortesi• 8 years ago

I have a project that's relevant here - netograph.io captures low-level data on website behaviour, then indexes the data in various ways for querying. Right now, it ingests a sizeable fraction of links on social media live. Here's my data for the api.behavioraldata.com domain, which is the first tracker they mention:

https://netograph.io/datasets/social/domain/api.behavioralen...

It's interesting that Netograph has seen this exclusively on .pl domains, and that it hasn't cropped up again in the last month. You can do similar digging through the dataset for all the other trackers they list.

dstjean• 8 years ago

Quite interesting!

It would be great if we could filter the lists (eg. I just want to see html and js)

underwater9• 8 years ago

The underlying issue is executing arbitrary third-party JavaScript on your website.

It’s unfortunate that browsers and standards organisations haven’t done more to promote safer methods of third party integration. The state of the art is still injecting script tags into the document. Given that the web is powered by embeds, ads, and analytics, there should be better sandboxing tools.

politician• 8 years ago

The underlying issue is executing arbitrary third-party JavaScript on your website's visitors' browsers.

Fixed that for you, but I agree with the sentiment: it's a real problem that browser vendors are disincentivized to address.

jopsen• 8 years ago

How is Mozilla discentivized from fixing that?

Sure, you can't break everything tomorrow...

lllr_finger2• 8 years ago

AMP achieved this, for better or worse - the only script allowed on the page is AMP common library and approved plugins. I wonder if the Google CDN was removed from the equation if it would have been more embraced.

JoshMnem• 8 years ago

AMP causes many other problems, so it isn't really a solution.

uMatrix is one way to block third-party scripts, but it requires some knowledge to use.

underwater9• 8 years ago

It hasn’t solved it at all. Google have whitelisted a set of first and third party scripts. They routinely add more through a non scalable process that seems to rely on a preexisting relationship with the company.

The analytics tag allows for arbitrary logging endpoints to be used, but that solves one very specific use case.

I believe that they’re going to allow worker scripts in the future, but again, that I don’t believe that will solve every case, and will be AMP specific.

plmn• 8 years ago

Sandboxing tools aren't the answer. The browser itself was supposed to be a sandboxing tool. The answer is to avoid this part:

executing ... JavaScript on your website.

reaperducer• 8 years ago

I find it interesting and appropriate that the toggle for activating Javascript is under the "Security" tab in Safari.

samkone• 8 years ago

Duh ... hasn't this been going on for years now. Tealium cited in the article uses this as one of their pain source of data collection

lllr_finger2• 8 years ago

I consider Tealium doubly in the wrong here since the appeal to some orgs is that their tag manager allows BizDev/AdOps types to include scripts on sites without answering to product owners and developers.

tylerhou• 8 years ago

The title might make it sound like JavaScript trackers have collected data which allow them to login to your Facebook account; maybe "'Login with Facebook' data hijacked by JavaScript trackers"?

btown• 8 years ago

The linked article https://freedom-to-tinker.com/2018/04/18/no-boundaries-for-f... provides much more detail and links to source code, such as https://gist.github.com/englehardt/db3ecea255ccd6aa2b0cb73ca...

It's important to recognize that this is not an exploit or high-tech exfiltration: it's extremely well-documented in https://developers.facebook.com/docs/reference/javascript/FB... and https://developers.facebook.com/docs/javascript/reference/FB... - the Facebook library even assumes that potentially multiple scripts may be checking repeatedly, and caches accordingly. Facebook is incentivized to make it as easy as possible to integrate their login across the internet, and that entails removing any requirements such as server-side processing that would discourage every tag from including this code.

Seeing this and being surprised is like watching a teen movie where the gossiper invites the entire school to listen in on the phone line while the protagonist is (unwisely) sharing a secret with them, and thinking as you watch, "that's totally out of character for the gossiper - even though they want to collect people's information themselves, there's no way they would invite other people to listen in as they're in the process of receiving that information."

Semirhage• 8 years ago

Doesn’t that depend on who’s surprised? My parents would be shocked by this, people working in the software industry should be less shocked. I bet that a poll of 100 randomly selected people asking, “What does documentation mean in the context of software?” would discover that few knew the answer. Never mind actually reading the docs, or understanding their implications.

Facebook goes to some trouble to ensure that only a small minority of people grasp the implications of how they’re monetizing their users.

JumpCrisscross6• 8 years ago

It's important to recognize that this is not an exploit or high-tech exfiltration: it's extremely well-documented

This argument was used last time [1]. It didn't work then and it's a silly excuse now.

Users gave Facebook their "name, email address, age range, gender, locale, and profile photo" [2]. Some of them marked those data private (i.e. only for friends). Those data were shared, without the users' informed consent, with third parties through the log-in function.

Documenting a breach doesn't unmake it a breach. And a breach can be a breach without involving any technical exploits. This was a breach.

Seeing this and being surprised is like watching a teen movie where the gossiper...

People didn't realize Facebook was selling their secrets. That may strike you as naïve. But it's this asymmetry, between specialists (e.g. Facebook employees and technologists at large) and non-specialists (i.e. most of Facebook's users), that drives the need for regulation.

An analogy can be found in lemon laws [3]. We protect consumers from specialists (e.g. car salespersons) taking advantage of the customers' reasonable ignorance of cars. Facebook is selling the world lemons and mocking them for buying.

[1] https://www.cbsnews.com/news/facebook-cambridge-analytica-wa...

[2] https://techcrunch.com/2018/04/18/login-with-facebook-data-h...

[3] https://en.wikipedia.org/wiki/Lemon_law

734786710934• 8 years ago

People didn't realize Facebook was selling their secrets.

Facebook doesn't sell data, it sells ads.

underwater9• 8 years ago

You’re either misunderstanding or misrepresenting what is happening here.

The website or app implements Facebook Login. When a user visits that they can choose to share their profile information with that app. Through poor security or malicious action that app leaks that information to third parties.

You can’t control data on systems you don’t own. So Facebook’s options are either (a) limit how platform apps use data via non-technical/legal methods (b) better educate users on the implications of sharing their data with external apps, or (c) refuse to share any user data with external apps.

We’ve seen the first option fail with the Cambridge Analytica scandal. Educating users consistently fails. And before Facebook built a platform, they were accused of building a walled garden.

ubernostrum• 8 years ago

The "not an exploit", I think, means something like "this is not, from Facebook's perspective, a malicious or unauthorized use of their platform and services".

In other words, it's not taking advantage of some accidental bug Facebook never intended to have; it's Facebook's system working as Facebook designed it to work.

Now, from the perspective of an individual person whose personal information was collected and distributed in this fashion, it certainly is unexpected and likely unwanted. But calling it a "breach" or "exploit" of Facebook implicitly covers for Facebook by implying that Facebook is a victim of some type of attack here. Facebook was not a victim of an attack.

ape4• 8 years ago

That why I lied to Facebook about all the profile info.

anonymouz• 8 years ago

So... a user using the "Login with Facebook" functionality on some website is supposed to have read the developer docs of Facebook, to be aware that some of his Facebook profile data will end up being shared with some random third-party tracker/ad-ware?

The GDPR really can't come to soon. I hope it'll finally smite these crappy companies.

dperfect2• 8 years ago

From a privacy standpoint, third-party scripts intercepting data is essentially no different from the "trusted" site explicitly sharing data with third parties. In both cases, the site using "Login with Facebook" is responsible for the data they gather/share, and that includes data gathered by any scripts they choose to embed on their site.

End users might not understand the technical details, but one should assume that if you're giving company X access to your data, company X could potentially share that data with companies Y and Z. Company X's privacy policy should cover their use (and sharing) of the data in either case, and if they didn't anticipate companies Y and Z intercepting data when this is clearly documented as a possibility in Facebook's docs, then I agree - company X should be held accountable.

vageli• 8 years ago

It's ridiculous to expect average people to have even a passing familiarity with Facebook developer documentation.

dang2• 8 years ago

Ok, since that's the original source, we've switched the thread from https://news.ycombinator.com/item?id=16871054 to this one, which was posted earlier. Thanks!

IBM4• 8 years ago

Why not just change the URL? That one had over 200 upvotes, this one will probably just fade off the front page in a few hours.

nashashmi• 8 years ago

First time I have seen that happen. The comment posting timing has been reset unfortunately.

thisisit• 8 years ago

It's important to recognize that this is not an exploit or high-tech exfiltration: it's extremely well-documented in https://developers.facebook.com/docs/reference/javascript/FB.... and https://developers.facebook.com/docs/javascript/reference/FB.... - the Facebook library even assumes that potentially multiple scripts may be checking repeatedly, and caches accordingly. Facebook is incentivized to make it as easy as possible to integrate their login across the internet, and that entails removing any requirements such as server-side processing that would discourage every tag from including this code.

Maybe I am reading this wrong but if Facebook makes an assumption which is inherently unsafe and publishes it. And then someone utilizes the unsafe assumption to siphon data, the ball is still in Facebook's court. They have to ensure that scripts cannot do this.

Sure, this might make it difficult for anyone trying to develop using Facebook library. But that is still better than asking people to read T&C and ensuring data is not leaked.

fjsolwmv• 8 years ago

That's a bizarre analogy that doesn't add anything more than the description of Facebook you already gave. Is their a teen movie cliche I'm unaware of?

AznHisoka2• 8 years ago

People aren't even aware that there are browser extensions that track every single website, keystroke, and click already. The companies that do this then sell your data for thousands a month.

I'm talking about big players like SimilarWeb and JumpShot. Clickstream companies.

nathancahill• 8 years ago

Isn't this the revenue model of eBates too?

arciini• 8 years ago

As far as I know, eBates doesn't directly sell the websites you visit. Instead, it makes money from the fees paid by "affiliates". For example, eBates is an affiliate of Macy's. That means when you buy something on Macy's with eBates installed, Macy's assumes that eBates is helping to get the user onto eBates. Macy's pays eBates, and eBates pays a part of it to yourself.

As far as I know, it only sends URLs of your visits to its affiliates, but not for other sites

ensignro23402• 8 years ago

This so much! As I've been watching people freak out over FB, I've been wondering - if people didn't even bother to read the pop-up, bulleted lists of information they were sharing with the apps they were connecting to FB, then how are they gonna feel about the similar, bulleted lists of information they're sharing with browser extensions? I mean, I assume they don't read those either.

[for the record, I know there are other issues w/ FB, but A LOT of the fallout seems to be related to the apps users were connecting to their profiles.]

tomaskafka• 8 years ago

And let's talk about antivirus companies that sell clickstream data while claiming 'tracking protection'.

One of many: https://www.businesswire.com/news/home/20150527005372/en/Mar...

EGreg4• 8 years ago

Here is the only real solution:

Have a browser which intercepts requests and encrypts all of them with your public keys, which can only be used to decrypt stuff on the client side.

Wesites would have to start indicating that they understand this new contract and that their servers won’t understand ANYTHING.

It could be a new protocol like https but called something else such as shttp:// or encrypted://

All apps would be client side and in Javascript. Yes, servers will be relegated to dumb boxes like in SAFE network. The business model can no longer be about capturing your data unless you share the data with another participant in what is essentially your web based VPN.

Any encrypted:// site can only load other encrypted:// resources so it can’t send any info to the server via postMessage etc.

There would be no cookies. Sessions would be kept on the client side, as they should be. Using sessionStorage.

Business logic done on servers now would be pushed to the edges, or could be further secured by validators that you allow into your VPNs and group activities.

People would share keys to group activities.

I am talking about somethig that breaks the current Web. No more cookies. No more AJAX the way you know it. Files are loaded from static bundles loaded ahead of time, before the website can learn custom information about your user agent.

ta457482468• 8 years ago

When the net/web was first rolling out (or my first exposure to it), I recall thinking, "This is it, universal communication, no more politics/propaganda/dark-ages-of-information-is-over etc".

Then we got Google, Facebook and the cadre of TLA's and criminal orgs turning it into a panopticon and a tool to manipulate people.

I think no matter what technology or tool we create, it'll be abused because that's the society we've created - one that encourages and rewards this behaviour when performed by a small group of very greedy, very misanthropic people.

JumpCrisscross6• 8 years ago

Under GDPR, would the sites that used this insecure Log-in Button from Facebook be liable for losing their data? (I assume they could then sue Facebook to re-imburse them for their fines, et cetera.)

pizzaknife• 8 years ago

Reading a sentence or 2 about the abstract concept of exposing yourself to arguably unknown agents is hilariously so specific in terms of the breadth of information you're agreeing to divulge... its not appreciated? Maybe my tinfoil hat truly fits perfectly but if you read the grant dialogue, its extremely clear insofar as "sign in with FB to take this super rad personality quiz! and all we need is everything" really meant it? Im jaded i guess

textmode• 8 years ago

According to a recent article[1], once an advertiser/attacker has collected a large quantity of email addresses, she can "import [them] as contacts" on Facebook, thereby revealing which Facebook profiles they are associated with, if any.

The article was written by a gentleman who wrote some early code for Facebook to do this which was later the subject of a Microsoft patent.

Would it be fair to say that once a user submits an email address to a website, that website can locate the users Facebook profile, if one exists. No "Facebook Login" required.

1. https://www.washingtonpost.com/opinions/your-facebook-data-i...

Also, the curious reader may find these interesting, regarding the ease with which an attacker/website could learn a Facebook user's private friends list:

https://www.telegraph.co.uk/technology/2018/04/17/facebook-q...

https://gizmodo.com/how-facebook-figures-out-everyone-youve-...

https://nakedsecurity.sophos.com/2013/06/23/facebook-issues-...

https://www.facebook.com/notes/facebook-security/important-m...

Finally, I have read that a major dating website has now removed Facebook Login.

drpancake• 8 years ago

Is this not the same as integrating 'Login with Facebook' and sharing my user's profile data with a third party service using server-side API requests? A practice that I'm sure is rife.

The third party JS scripts simply cut out the middleman, but as a side effect the sharing is detectable.

known• 8 years ago

FB should comply with https://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Sec...

spullara• 8 years ago

What is hilarious about all this is that Facebook sharing any of this data with anyone is against their interests.

geocar• 8 years ago

ntvk1 is nativka http://nativka.ru , now http://natimatica.com/

EGreg4• 8 years ago

Our Qbix Platform has a solution to this using the existing modern web:

https://encrypted.google.com/patents/US20120110469

We did not continue the patent application process to the end, so you’re free to use it.

ivanhoe• 8 years ago

If I remember correctly you can't request access to any non-public user info without submitting your app first for manual approval by Facebook's staff. So, if there are FB apps out there tracking extra user info, Facebook must have reviewed and approved them, so they are obviously OK with such usage. So it's not an exploit of the platform, it's FB's core business...

1sttimeposter• 8 years ago

Why do we not assume that the site owner has the responsibility to protect how data is intercepted on their site? If said site owner allows their web page user to type their email into a form, a malicious script on the page can still intercept that data. FB assures the transportation of the data to the web page and once the transmission is triggered, up to its delivery, then the onus is on a site owner to govern the data. Furthermore, as an end user you have to be diligent in what you do online. If you come across a site that asks you to type information or log in with FB, you have to determine whether you trust the site enough and that you feel comfortable taking the risk of exchanging your information for the service at hand. Let’s not lose site of reality and remove emotional bias from this conversation.

daveheq• 8 years ago

I don't use Facebook to login with anything, so I guess I have nothing to worry about.

hackbinary• 8 years ago

I have never trusted Facebook login. It just always seemed 'wrong' to me. It always gave me a creepy feeling.

Ajedi32• 8 years ago

How much of this is intentional on the part of the first-party site?

The article says:

The following could indicate the first party’s awareness of the Facebook data access:
1) third-party initiates the Facebook login process instead of passively waiting for the login to happen; 2) third-party includes the unique App ID of the website it is embedded on. The seven scripts listed above neither initiate the login process, nor contain the app ID of the websites.
Still, it is very hard to be certain about the exact relationship between the first parties and third parties.

But I can certainly imagine a situation where a site owner would inject a third-party analytics script into their site and have no problem with it including information from Facebook logins as part of the analytics data it collects.

After all, as a site owner why wouldn't I want my analytics dashboard (provided by a third-party) to include information like "percentage of visitors between the age of 18-25"? That seems like a useful thing to know, and the users who granted my site access to that info did so explicitly via a Facebook permissions prompt, so what's the issue?

The issue, of course, being that my site's user's data is now being handled by a third party. But I obviously had no problem with that when I decided to use a third-party analytics company in the first place; why would that change now?

No boundaries for Facebook data: third-party trackers abuse Facebook Login

Related Stories