Unsanctioned Web Tracking • Hacker News Board

Re: Unsanctioned Web Tracking

#31

Post by Sephr » Sat, Jul 18, 2015, 5:41 AM UTC

pdkl95 wrote: post #28

Sephr wrote: post #20

I agree that supercookies and header enrichment should be prevented whenever and however possible (e.g. header enrichment will be solved by requiring encryption à la Let's Encrypt), but fingerprinting is a lost battle that we should all give up on. We will never be able to solve fingerprinting without upheaving the entire web platform as we know it. So many web APIs are simply not possible without exposing some UA ca…

This defeatist attitude is dangerous, especially when the solution is simple : just stop browsers from leaking >= ~30 bits of entropy. Deprecate HTTP headers that leak entropy (like the user agent). Rewrite fields like If-Modified-Since so they can only express a value quantized into values no smaller than days. Remove JS APIs that leak information (like the ability to read CSS attributes). Impose stricter same-origi…

Panopticlick doesn't use everything available. WebGL alone adds an additional 5.11 bits of entropy[1]. Other things such as your local network address from WebRTC, core count, etc. all can add a lot more entropy for fingerprinting.

[1]: http://arxiv.org/pdf/1503.01408.pdf

Re: Unsanctioned Web Tracking

#32

Post by cpeterso » Sat, Jul 18, 2015, 6:36 AM UTC

Sephr wrote: post #20

I agree that supercookies and header enrichment should be prevented whenever and however possible (e.g. header enrichment will be solved by requiring encryption à la Let's Encrypt), but fingerprinting is a lost battle that we should all give up on. We will never be able to solve fingerprinting without upheaving the entire web platform as we know it. So many web APIs are simply not possible without exposing some UA ca…

An alternative to DNT header might be a "Do Track" header: the browser generates a unique user ID instead of saving server-generated cookies. Users could control which sites receive their ID, manage multiple IDs, or they could reset their ID (like clearing cookies). Sites that still insist on active fingerprinting could be penalized by (opinionated) browsers with scary icons in address bar (like mixed content warnings).

I think there is still value in minimizing passive fingerprinting because it allows servers that don't serve active content (e.g. third-party image servers) to track users.

Re: Unsanctioned Web Tracking

#33

Post by codezero » Sat, Jul 18, 2015, 7:26 AM UTC

teej wrote: post #21

codezero wrote: post #5

Earlier quoted context omitted.

This is sort of true but it depends. We set a first party domain specific cookie. We can't track a user across different domains, or customers. Technically we could correlate based on IP and activity times, but it's not the same as setting a super cookie that is shared between sites. You are still right, how is there user supposed to know if one tool is reputable and another isn't. Worse than that, one may be fine to…

We can't track a user across different domains, or customers. To be super clear- yes you can. You don't. That's very different. With full JS access on a site you have the ability to collect a lot of information. As another poster mentioned, it only takes 30 bits of entropy to identify all 3 billion internet users.

You're right. My bad. We don't. Not we can't.

Technically, though we can't, since we'd have to dedicate engineering time to making the changes necessary to do that kind of tracking, and we're not going to :P

Re: Unsanctioned Web Tracking

#34

Post by frik » Sat, Jul 18, 2015, 7:34 AM UTC

Browsers should (as default setting) disallow third party JS, problem solved!

Analytics and ad-network company could create on-premise products that can be installed on the website server, problem solved.

Win-Win.

Re: Unsanctioned Web Tracking

#35

Post by us0r » Sat, Jul 18, 2015, 9:39 AM UTC

MichaelCrawford wrote: post #11

The easiest way to spot web bugs is to use a very old build of Safari. There are many other ways but if you have an old Safari select Window -> Activity then leave it open as you browse a few different domains. You will see some 43 byte documents with huge long URLs full of query parameters, also one byte javascript sources. I block the ones I find in my hosts file: 127.0.0.1 www.hosted-pixel.com On some operating sy…

"Among the reasons I dont install any other mobile apps other than those I absolutely require - not even free ones"

This. People are up in arms over the web. If they only knew what each app in their pocket was sending.

Re: Unsanctioned Web Tracking

#36

Post by mhkool » Sat, Jul 18, 2015, 1:01 PM UTC

Tracking started with single site tracking and worked well with a simple cookie. There was no overhead and no bloat like heatmaps and 5-level nested scripts that display an invisible pixel. It was not evil except that users did not know that they were tracked.

Then the evil started with multi-site tracking. Trickery was required to implement cross-site tracking and the advertisers became too obsessed with 'knowing the user' that they overdid it. I would like to see proof that today's excessive tracking really pays off with higher click rates.

A lot of trickery uses javascript and there are only a few users who disable javascript since almost all sites uses it and sites get (seriously) crippled if javascript is disabled. I therefore am waiting for a browser vendor who recognises this problem and comes with a 'Javascript light' where only a small subset of javascript -- just enough to build great responsive websites -- is supported. Javascript light will not allow to generate heatmaps, invisible pixels and upload system information. Surely you will say 'web programmers need system information' but this can be provided in a different way, i.e. browsers can send a header with the information that they want to give.

Another evil are the social networks since they have their 'like' button on almost every website that you visit and hence know exactly what a user does 24 hours per day. Just like the 'do not track me' feature, the web needs a new 'no like buttons for me' feature.

Re: Unsanctioned Web Tracking

#37

Post by jfb » Sat, Jul 18, 2015, 2:28 PM UTC

Sephr wrote: post #20

I agree that supercookies and header enrichment should be prevented whenever and however possible (e.g. header enrichment will be solved by requiring encryption à la Let's Encrypt), but fingerprinting is a lost battle that we should all give up on. We will never be able to solve fingerprinting without upheaving the entire web platform as we know it. So many web APIs are simply not possible without exposing some UA ca…

I think it is entirely reasonable to treat fingerprinting as ipso facto user hostile; that it is critical to the continued success of certain business models is reason enough to force abandonment of those models.

If we decide that preventing fingerprinting is a good, then yeah, certain technologies will be out of bounds. So? This is exactly the way a society works.

Re: Unsanctioned Web Tracking

#38

Post by Jgrubb » Sat, Jul 18, 2015, 3:37 PM UTC

mhkool wrote: post #36

Tracking started with single site tracking and worked well with a simple cookie. There was no overhead and no bloat like heatmaps and 5-level nested scripts that display an invisible pixel. It was not evil except that users did not know that they were tracked. Then the evil started with multi-site tracking. Trickery was required to implement cross-site tracking and the advertisers became too obsessed with 'knowing th…

What features would this light version of Javascript support and what features would it not support. Obviously `new Image()` is out, as is any kind of cookie support right? So that means no ability to log in? I don't think any browser vendors would bother spending developer time on a project that would severely break pretty much every site out there.

Not to mention, you must realize that any and all methods that were available would eventually be exploited for tracking users in the absence of the usual methods.

This is a situation that is only going to be "fixed" with legislation and regulation.

Re: Unsanctioned Web Tracking

#39

Post by nly » Sat, Jul 18, 2015, 4:00 PM UTC

Sephr wrote: post #20

I agree that supercookies and header enrichment should be prevented whenever and however possible (e.g. header enrichment will be solved by requiring encryption à la Let's Encrypt), but fingerprinting is a lost battle that we should all give up on. We will never be able to solve fingerprinting without upheaving the entire web platform as we know it. So many web APIs are simply not possible without exposing some UA ca…

> header enrichment will be solved by requiring encryption à la Let's Encrypt

I doubt this is the case. How many bits can be manipulated in client TLS headers by a MITM without causing breakage? I find it hard to believe TLS leaves no room for malleability early on in the handshake.

Re: Unsanctioned Web Tracking

#40

Post by anon1385 » Sat, Jul 18, 2015, 4:05 PM UTC

jtuchsen wrote: post #19

[deleted] wrote: post #14

Earlier quoted context omitted.

[deleted]

Do you have an example of this working? I thought that browser venders we're having the :visited selector lie to you when you call getComputedStyle on them? Also, how would you workaround the need for JS? I understand that you can do something similiar with tracking pixels, but I'm under the impression that Ghostery blocks them.

>I thought that browser venders we're having the :visited selector lie to you when you call getComputedStyle on them?

It's possible to probe the users history even though getComputedStyle doesn't give it away anymore.

See page 6 of this article: http://www.contextis.com/documents/2/Browser_Timing_Attacks....

Obviously turning off Javascript prevents these types of things to some extent, but even then there are ways: https://www.nds.rub.de/media/nds/veroeffentlichungen/2014/07...

The web is just not designed with preventing information leaks in mind.