No boundaries for Facebook data: third-party trackers abuse Facebook Login | Hacker News Reader

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

freedom-to-tinker.com

601 pointsrandomwalker117 comments

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

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.

> 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

> People didn't realize Facebook was selling their secrets.

Facebook doesn't sell data, it sells ads.

> Facebook doesn't sell data, it sells ads

That sounds like selling data but with extra steps.

They basically provide the data for free so you can buy more ads.

When you say Facebook is "selling data", I think most people would understand it to mean that advertisers can go to Facebook and buy a list of people who eat at McDonalds. That's very different from the opaque ad targeting Facebook actually sells.

There is a connection between the ad targeting information and the eventual anonymous click through though. You only need to connect that click to a real identity via either self disclosure (newsletter signup, social login, etc) or pushing your metadata through third party data brokers.

In the end you have a click associated with an advertising campaign linked to a real life (or even pseudo) identity.

Are you implying that this is a problem that arises specifically from Facebook's targeted advertising? I genuinely don't think that's the case.

It doesn't really matter if ads are served to everyone or if they are shown only to a targeted demographic - either way, only people who are interested will click on them. Also, I think it is safe to say that, roughly, it is only the efficiency of clicks per ad-view that will increase if one uses targeted advertising.

So, if the act of clicking a targeted advertisement does not in itself somehow "transfer" any more identifying data than a click on a regular ad would, which I don't think it does, then what's the problem?

Facebook is incentivised to collect and collate product data because it can then sell targeted ads for those humans. As long as the most cost effective path to those targets is through Facebook, and the aggregate target volume is high enough they will make money. Distributing the login data is just advertising.

That argument goes both ways: When you say Facebook is "selling ads", I think most people would understand it to mean that advertisers can buy ads like in a paper magazine. That's very different from the tracking and targeting ads Facebook actually sells.

“Hey, I heard you’re opening a baby store. Did you know John and Mary are expecting? Here’s their phone number, you should call them up.” vs. “Hey, I heard you’re opening a baby store. If I know anyone who is expecting I can let them know.”

But really your second example ends with "But when they do come inside you'll know I sent them and you can ask them their name yourself."

Same knowledge as your first example (names, expecting). I do admit you only get the information from people who come into the store.

They’re vastly different. John and Mary can choose exactly who they want to reveal information to.

Not on the modern web.

How so?

Signals. Searching for specific things, emails you're receiving in Gmail, videos you watch online etc.

Given Target was able to figure out someone was expecting based on behavior in their store, back in 2011 [1], even though they dont have a loyalty program, imagine what can be done with so many trackers that are on the web datamining your behavior from one website to another.

[1] https://mobile.nytimes.com/2012/02/19/magazine/shopping-habi...

But what signals can third party domains get if third party cookies are disabled?

Is fingerprinting so good that cookies are now irrelevant? I mean most mobile devices have the same screen sizes etc.

Fingerprint coupled with IP tracking is pretty good.

> emails you're receiving in Gmail

I'm sorry but if you care about privacy, you shouldn't be using Gmail.

The original assertion that advertising and data sharing are equivalent. But even in your examples the information is still fire-walled.

Google can know that you're expecting, because of a congratulation email. Facebook can know you're expecting, because of a life event. Arbitrary companies can't know who their baby store ad is being shown to.

You can argue that Google and Facebook are too big, and data being shared between YouTube, Gmail, Google Adwords, etc. is suboptimal. But that's still better than a company that will freely sell a database of information to be resold, mixed, etc. forevermore.

Right. "You can ask them their name yourself"

That doesn't mean they are going to give you their name.

And if they choose to give you their name, it's their right and responsibility.

It's important to remember, because someone might propose a law against a social network selling data. It could be heralded as finally giving users privacy. And Zuckerberg will be very happy that this PR mess has gone away

According to this article (as well as the Cambridge Analytica stuff) it doesn't sell data, it just gives it away.

Well it’s more like an exchange, because in the process they gain the ability to suck up virtually every piece of data you post in the external website because you basically hold them your key.

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.

It's almost like it's a problem that cannot be solved without outside intervention.

Are you suggesting regulation could have helped in this situation? Do you believe the problem is with Facebook sharing data (which they did with the user's permission) with an app? Or with an app failing to secure the data? Or with a third-party taking user data without permission?

> Are you suggesting regulation could have helped in this situation?

Facebook doesn't give a shit about its users. And for that I don't blame them. They're fighters. When they went public, so many assumed they were dead for lacking a mobile presence. Time and again, they've been called out as moribund and time and again they've won. That takes--and develops--thick skin.

That thick skin is now a hard head obstructing their view of the truth. When they drop the ball, it is never their fault. Someone is mis-defining a term, users aren't reading fine print, lawmakers are being mean, et cetera. The onus is put on us, the public, to determine how our rights can be balanced with their business model. As if their business is a given.

If Facebook were liable for repeatedly losing our data, for repeatedly refusing to tell users what it does with what they give them, for constantly lying about what it's doing and going to do, this would stop. Or Facebook would stop.

Neither users nor advertisers can unilaterally disengage. Not in meaningful numbers. Facebook is too powerful. The only solution is for it to be broken up.

Do you believe in the rule of law, or do you expect everyone to take the "moral high ground" (however you want to define that) all the time just because they should? Pick one or the other, but not both. Hint: one of the two is a fair and practical approach; the other is a pipe dream built from excessive virtue signaling.

Should Facebook be 100% held responsible to the law? Of course.

Should some laws be updated/created to help fill gaps where we might need more privacy? Possibly.

Should Facebook be held to some nebulous moral standard of what some people want but don't have the will power or public support to codify into law? Absolutely not.

Too powerful? If people actually cared more about privacy, then either the law would get changed (which is happening in some places), or Facebook would lose market share and be forced to make changes from market forces alone. No need for governments to arbitrarily pick winners and losers.

>Do you believe in the rule of law

Facebook Ireland Ltd. Does.

> Pick one or the other why not both?

> Facebook would lose market share and be forced to make changes from market forces alone

"Market failure is a situation in which the allocation of goods and services is not efficient" [1]. They are known failure modes that free markets suffer, and must be defended, from. Laissez-faire doesn't work.

[1] https://en.wikipedia.org/wiki/Market_failure

Found the Facebook employee.

All three options failing? So basically the very premise of Facebook is broken if we wish to uphold this value.

I'm not sure you can see this as a persistent failure in terms of FB (and similar) fighting against an unstoppable tide of ignorance. It's far more easier to see Facebook (and similarly Google with Android, for a very long time) sabotaging the effort from the start.

A user absolutely can choose what they share with Facebook, but Facebook makes no effort to tell you why you should edit the defaults. Instead, you have to click an edit button, and look at a list of checkboxes, and understand what each thing means, and double and triple check that this doesn't override your personal privacy preferences or have some other unintended side-effects. The default expectation from Facebook (and similar) is biased heavily against the user, purely by virtue of it being opt out.

It depends on users not being educated well enough, and giving them a good reason to care less about being more judicious with their profile.

Actually some apps wont allow you to login if you change any of the checkboxes.

> 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

Under GDPR, as a data controller, you cant share data with another organisation without ensuring that they follow the same rules that you have set out for processing data. This may get interesting in Europe.

> Through poor security or malicious action that app leaks that information to third parties.

It's neither poor security or malicious action. Web site isolation rules by design give full privileges to any third party script the website includes. If a website uses facebook login, all third party scripts can access the facebook user name.

> And before Facebook built a platform, they were accused of building a walled garden.

That's not any kind of argument for the privacy-diluting practices of Facebook. If Facebook were a totally closed environment that shared your data with nobody, that's a problem for Facebook and the private companies who would prefer to exploit that information, not for the users, who at this point would very much prefer Facebook to be a "walled", but but in actuality a "regulated", garden.

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.

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

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.

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.

If you print out FB’s T&C’s, plus all of the layers of embedded links within links, it’s 87,000+ words. That is designed to be unreadable and incomprehensible, it’s an attempt to baffle. Even stupid people, illiterate people, and just plain lazy people don’t deserve to be taken advantage of.

If you want to talk about what people “should” know, there’s s reasonable man statute, and it definitely doesn’t include what you’re describing.

I agree with you on that. I'm just pointing out that the data isn't being shared with "some random third-party tracker/ad-ware" (it's either a conscious decision or a serious security mistake to include third-party scripts on your site). This particular method of "leaking data" shouldn't be treated any differently from direct, deliberate information sharing because it's not some kind of unanticipated "hack" as the story might sound.

"These scripts are embedded on a total of 434 of the top 1 million sites, including fiverr.com, bhphotovideo.com, and mongodb.com. … We believe the websites embedding these scripts are likely unaware of this particular data access [5]."

From an end user point of view - I don't think it's reasonable for a bhphotovideo.com user logging in with Facebook to assume their Facebook data is being sent to ntvk1.ru

I suspect it's not even really reasonable to expect the website owner at some of those "434 of the top million sites" to be technical enough to understand the privacy implications for their users of running both "Log in with Facebook" and 3rd party ad serving on their sites at the same time.

and mongodb.com

To be fair everyone expects MongoDB to leak data like a sieve.

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

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!

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.

This way is fairer to the original submitter, and it's a big enough story that it's unlikely to suffer in terms of rank or time on the front page.

I’m ok with this, the new article is unquestionably a better source.

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

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.

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?

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.

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

How is Mozilla discentivized from fixing that?

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

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.

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.

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.

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.

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

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.

Isn't this the revenue model of eBates too?

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

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

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

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

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

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.

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.

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.

Quite interesting!

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

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.

NoScript + self destructing cookies.

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

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.

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.

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.

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.

Same here, I always use an incognito window for facebook.

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

Then it is time to stop using those websites.

Every time this subject has come up on this site, and someone has mentioned to use the extension NoScript, they've been down voted to oblivion.

Maybe because uMatrix is much better at the job than NoScript? :)

But yeah, there seems to be a lot of animosity towards the idea of blocking javascript here. Maybe because there is a lot of webdevelopers visiting this site, and they instinctively react when someone is trying to take their toys away.

#notallwebdevelopers. Progressive enhancement is a reliability mechanism, not a throwback.

Yep, I wrote NoScript, but I actually meant script blocking. :)

For some time now, I've used ublock origin, which I find better overall than umatrix.

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

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.

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?

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

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.

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

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.

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.

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.

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

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.

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

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

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

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

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

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.

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

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

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.

PWAs will do nothing to address this problem.

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

Sarcasm never works with a substantial number of people. And on the internet it escapes even more people, even if using emojis ;-P

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

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.

True, but a native app can read (and inject scripts into) the DOM of any website in a WebView component within the app. The app can also read all cookies that are created from within the WebView (not cookies from Safari). Think how many apps use native "in app" webviews, e.g. reddit, facebook, etc.

Now think about login pages, oauth flows, etc...

There are lots of opportunities to slurp data from a native app.

No but if an app uses a Facebook login flow with the native Facebook SDK any third party analytics that the app developer has integrated should be able to do the same thing, at least in the case of Objective-C where powerful runtime meta programming exists. I'm not sure about Android, but maybe Java reflections could achieve it too?

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

It's way easier for the developer of the app to steal data in the native app.

Trick user to open FB or any site. Open the requested site in the built-in browser. Let user login to the site, and then scrap all the information. Apple and Google can't stop that.

You can't do that in the browser.

> 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

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.

Reply on news.ycombinator.com