4 ms·

Has anyone ever considered just giving 3rd party javascript less access to things? That may fix the fingerprinting problem too. I do have some appreciation fo

Has anyone ever considered just giving 3rd party javascript less access to things? That may fix the fingerprinting problem too. I do have some appreciation for how badly it would break a lot of the web applications though, but it seems like it might work.

the8472 7y ago
Iframes already provide that capability for web authors. Their sandbox and csp attributes allow you to enforce quite a lot of things. Users or extension authors can't do much other than blocking those scripts or restricting what the whole page can do because it's difficult to attribute actions to a specific script.
deburo 7y ago
Javascript coming from a different origin? What about CDNs in that case?
- Crosseye_Jack 7y ago
  If you have something like CloudFront in front of your site you can actually make a subdirectory be served from a different origin. To the browser they actually come from the same "place", its just AWS is sitting in the middle. I'm sure its the same with Fastly (Don't use that feature as their shared ssl offering is like and extra $100 p/m) and with cloudflare. EDIT: What I mean is example.com/api/hello could hit your back end, but example.com/js/script.js hits S3 (or another static hosting service) instead of hitting your real origin. So even though to the browser it would appear that /js/script.js is coming from example.com it could actually be coming from anywhere else. BUT the cookie origin would take over. So if script.js was a tracker. the cookie it set on the browser would be example.com and not "AnotherSite.com" which had the same tracking script. But if the script can make the same fingerprint from both domains then that's not so much of and issue. But thats going back to other methods of fingerprinting.
  - necovek 7y ago
    Don't get me wrong, but this way of serving content has been common since, well, apache 1.2 days and mod_proxy ReverseProxy: CDNs did not bring anything new in that respect. Basically, you are confusing some terminology and not really making any point: in your example, there is only one origin, that of example.com. Yes, servers can forward any data they wish to other web sites (like AnotherSite.com). What is the point?
    - KptMarchewa 7y ago
      You're using external service.
      - necovek 7y ago
        Sure, and a service that is able to scale much better, has a fatter pipe, allows configuration through a web UI... But in this context, how does this matter? "Origin" is a client/browser side concept, and however you serve your website internally, it appears as one web site. Basically, I replied to a comment bringing CDNs into discussion where they are totally irrelevant. Origin checks can't protect you against servers forwarding your data to a privacy-invading site (eg Google), and a server can do that simply by being a reverse proxy to another site.
cameronbrown 7y ago
It'd be really easy to circumvent. Proxying Google Analytics through your own origin would become standard practice.
- tinus_hn 7y ago
  Then it wouldn’t be able to be used to track you across the web.
  - cameronbrown 7y ago
    Until all your data ends up being re-associated with you in some way across multiple websites. Nothing stopping these sites from sharing data if it ends up mutually beneficial.
    - yjftsjthsd-h 7y ago
      Intentionally sharing data that identifies users would hit GDPR pretty quickly, no?
      - cameronbrown 7y ago
        Yep, but it's completely invisible to users so that could be tough to prove without a data breach. And there's massive profit motive to get away with this. Right now Google still keeps these websites in check with regards to Analytics/Ads data usage, remove the middleman and things are going to get much worse. GDPR only safeguards your data from the honest. What we need is a technological solution.
- joes223 7y ago
  It wouldn't because that's a drastically more complex solution.
  - gberger 7y ago
    If you already have a web server serving your content, setting up a proxy to GA is trivial.
bhauer 7y ago
Anyone using NoScript or similar is, in a fashion, doing that. I can confirm that it's generally more pleasant dealing with the web when a lot of third-party script is being blocked.
ddiss 7y ago
The trend of shipping apps that run their own localhost server, coupled with javascript, is particularly worrisome for privacy. E.g. https://ddiss.github.io/is-netflix-running/ https://ddiss.github.io/is-netflix-running/ .
JohnFen 7y ago
That would be nice. In my opinion (since I already don't allow JS to run in my browser), it would be even nicer if browsers stopped giving webservers any information about my machine, operating system, or the browser.
erikpukinskis 7y ago
I have PolicyControl installed in Chrome and by default I block most 3rd party content. When things don’t work I either disable it for the site or click away. Sometimes I fiddle with it out of curiosity to see what the site relies on. As a side effect it gives me a sense of what sites are professionally built and which are not.

the8472 7y ago

Iframes already provide that capability for web authors. Their sandbox and csp attributes allow you to enforce quite a lot of things. Users or extension authors can't do much other than blocking those scripts or restricting what the whole page can do because it's difficult to attribute actions to a specific script.

deburo 7y ago

Javascript coming from a different origin? What about CDNs in that case?

Crosseye_Jack 7y ago
If you have something like CloudFront in front of your site you can actually make a subdirectory be served from a different origin. To the browser they actually come from the same "place", its just AWS is sitting in the middle. I'm sure its the same with Fastly (Don't use that feature as their shared ssl offering is like and extra $100 p/m) and with cloudflare. EDIT: What I mean is example.com/api/hello could hit your back end, but example.com/js/script.js hits S3 (or another static hosting service) instead of hitting your real origin. So even though to the browser it would appear that /js/script.js is coming from example.com it could actually be coming from anywhere else. BUT the cookie origin would take over. So if script.js was a tracker. the cookie it set on the browser would be example.com and not "AnotherSite.com" which had the same tracking script. But if the script can make the same fingerprint from both domains then that's not so much of and issue. But thats going back to other methods of fingerprinting.
- necovek 7y ago
  Don't get me wrong, but this way of serving content has been common since, well, apache 1.2 days and mod_proxy ReverseProxy: CDNs did not bring anything new in that respect. Basically, you are confusing some terminology and not really making any point: in your example, there is only one origin, that of example.com. Yes, servers can forward any data they wish to other web sites (like AnotherSite.com). What is the point?
  - KptMarchewa 7y ago
    You're using external service.
    - necovek 7y ago
      Sure, and a service that is able to scale much better, has a fatter pipe, allows configuration through a web UI... But in this context, how does this matter? "Origin" is a client/browser side concept, and however you serve your website internally, it appears as one web site. Basically, I replied to a comment bringing CDNs into discussion where they are totally irrelevant. Origin checks can't protect you against servers forwarding your data to a privacy-invading site (eg Google), and a server can do that simply by being a reverse proxy to another site.

cameronbrown 7y ago

It'd be really easy to circumvent. Proxying Google Analytics through your own origin would become standard practice.

tinus_hn 7y ago
Then it wouldn’t be able to be used to track you across the web.
- cameronbrown 7y ago
  Until all your data ends up being re-associated with you in some way across multiple websites. Nothing stopping these sites from sharing data if it ends up mutually beneficial.
  - yjftsjthsd-h 7y ago
    Intentionally sharing data that identifies users would hit GDPR pretty quickly, no?
    - cameronbrown 7y ago
      Yep, but it's completely invisible to users so that could be tough to prove without a data breach. And there's massive profit motive to get away with this. Right now Google still keeps these websites in check with regards to Analytics/Ads data usage, remove the middleman and things are going to get much worse. GDPR only safeguards your data from the honest. What we need is a technological solution.
joes223 7y ago
It wouldn't because that's a drastically more complex solution.
- gberger 7y ago
  If you already have a web server serving your content, setting up a proxy to GA is trivial.

bhauer 7y ago

Anyone using NoScript or similar is, in a fashion, doing that. I can confirm that it's generally more pleasant dealing with the web when a lot of third-party script is being blocked.

ddiss 7y ago

The trend of shipping apps that run their own localhost server, coupled with javascript, is particularly worrisome for privacy. E.g. https://ddiss.github.io/is-netflix-running/ https://ddiss.github.io/is-netflix-running/ .

JohnFen 7y ago

That would be nice. In my opinion (since I already don't allow JS to run in my browser), it would be even nicer if browsers stopped giving webservers any information about my machine, operating system, or the browser.

erikpukinskis 7y ago

I have PolicyControl installed in Chrome and by default I block most 3rd party content. When things don’t work I either disable it for the site or click away. Sometimes I fiddle with it out of curiosity to see what the site relies on. As a side effect it gives me a sense of what sites are professionally built and which are not.