Hacker News Reader

Comment by pygy_ | Hacker News Reader

Several people mention Ghostery[0] against trackers. It offers only partial protection. It is possible to fingerprint a browser without any custom tracking data.

https://panopticlick.eff.org/ <-- check how unique your browser is.

Instead of a script to embed, these firms could provide an API to identify users from the server side. The scripts that captures the profile would be served by the sites themselves rather than from third party services.

Toast.

A possible solution would be anonymize the browser fingerprint, at least in private mode, ie lie about the details of the system.

Google, Mozilla, Opera, can you hear me?

[0] http://www.ghostery.com/

View on HN

Not only does panopticlick say my browser is unique, but it said that last time I visited it, several months ago.

Maybe it's forgotten. Maybe it lies. Maybe every time I rev Firefox Nightly I change identity.

What is true is that every time I leave an email address, it's tagged with the name of the site where I left it.

> Maybe every time I rev Firefox Nightly I change identity.

Indeed; the user agent is part of the fingerprint.

You said it yourself: everytime your Firefox build is updated, you change identity.

Considering the development model used by most modern web browsers, I'm pretty certain those who do this type of fingerprinting in the real world will long ago have adjusted their matching algorithms to be aware of this. I doubt they even care if they get a fully unique fingerprint, they probably just define some percentage of matching as being "close enough to a likely match" to report you as being someone they have seen before.

Just mentioning this lest anyone get the wrong idea that setting your browser to update frequently might be a defense.

Identity matching algorithms use a fuzzy match to identify users because the only way to get an exact match is with by storing an identifier on the user's machine, or in memory for the duration of the browsing session. A lot of factors can change and it may not significantly alter the weight of the match.

One of the most effective methods of fingerprinting people is to enumerate the fonts they have installed on their machines (via flash). You don't even need the browser version number to uniquely identify most - the only solution is to disable flash.

As chrome sandboxes flash, I wonder how much hassle it would be to only allow a small subset of fonts through?

Most browsers have "run plugins on click" options, very useful in general.

The gmail + trick can be defeated, though. If you own a domain, you can use arbitrary addresses and it becomes more reliable.

I use Google Apps (possibly not a good idea but soo convenient :/) with a catchall. I didn't catch any offender so far...

However (off topic), spammers are spoofing addresses as if they were coming from my domain. I receive two to three dozens automatic replies from mail servers (this address does not exist...).

I've properly set up DKIM and SPF records, making it obvious that these mails are spoofed, but I'm afraid my domain will end up on grey/black lists... Anyone out here familiar with this kind of issue?

I think a lot of sites have caught on to the + trick, though, because more are more disallow the + character in the email validator.

I wish they wouldn't..

https://en.wikipedia.org/wiki/Email_address#Valid_email_addr...

More like laziness. They probably only allow something like:

  ^[a-z0-9_.]+@(?:[a-z0-9-]+\.)+\.[a-z0-9]+$

In my experience it's been ignorance rather than laziness. I suppose you could argue that the root cause of the ignorance is laziness. If someone is writing a validator, they probably ought to check what constitutes valid input.

It's not a sign of catching on, but of using an old email validation pattern from the days of Matt's Script Archive (seemingly). It's the sign of a website that has used cargo-code programmers. You're probably just seeing it more because you're trying to use plus-addressing more often (confirmation bias), but it's been this way for years and years. It's actually better now than it used to be.

fastmail.fm lets you set up wildcard mx records -- so if your email is user@example.com, you can get email at company1@user.example.doc, company2@user.example.com, etc. instead of user+company1@example.com. I imagine other email providers do this too.

Hmm, that's a useful tactic as I'm seeing + addresses becoming much less effective due to the reasons I gave above.

Yes, I have my own domain and have been doing this for years. It generally works as expected, and so far I've had at least four unique addresses that were leaked to spammers. One of them was the address I used for newegg.

If you do go this route, I'd recommend using a whitelisting approach. I do get a lot of spam sent to random addresses at my domain.

I've also had personal information leaked through NewEgg. For me it was my name and my parents email address when I got them to buy me a video card when I was 16. Eventually they got an email addressed to my full name and their email about car insurance rates or some random spam. I would really think NewEgg would be better than that.

The + trick is becoming well known with spammers anyway. I registered with one site as "something+else@example.com" having never used the "something@example.com" address anywhere and within a few days I was getting spam to "something@example.com" and "something+else@example.com". Whoever got that list of emails was clever enough to know to try removing the + portion.

Obviously you can never give out the "something@example.com" address and then assume that everything that goes to that address must be spam, but I've had legitimate contact from companies who have had to email me by removing the + portion because their internal email system wouldn't allow addresses with a + in them.

They're getting a little wise, but that didn't stop me from receiving spam to "else@example.com" a few weeks ago.

I've been using catch all's for years. I get 100+ bounced spam emails a day from people spoofing my domains (also have DKIM + SPF). AFAIK none of my domains have ever ended up on blacklists and no one has had trouble receiving legit email from me.

Good to know, thanks.

It does indeed use version information, not just the browser's but also of every installed plugin including Flash. So a single rev is going to give a new fingerprint. Plus, far fewer people are checking it as when it first launched, making those who do check it from time to time even more unique.

But note that a constantly changing fingerprint doesn't make it useless for tracking - if a site can keep any kind of cookie to persist between browser updates, it could add the updated signature. Then when you purge cookies and persistent storage, a site can re-add the cookie to keep on identifying you if your signature hasn't changed.

You'd have to purge all persistant storage at the same time as an update to avoid this, and even then (or if you never had persistent data to begin with) your IP or even geographical location will likely be enough to identify you again.

"Maybe every time I rev Firefox Nightly I change identity."

Unless the nightlies have a different behavior than the releases, the patch level is not reported anymore. The changes went into 16.0.2 which was released on 10/26/2012. initial report on b.m.o[1] reads as follows:

  Steps to reproduce:

  1) Load http://www.delorie.com:81/some/url.txt

  Actual results:

  The User-Agent header exposes the security patch level as either a minor version
  number or as an alpha/beta/pre indicator. This data is exposed twice: in the 
  Gecko version and in the application version.

  While it is of value to expose this data to e.g. AMO, exposing it to all sites
  makes the browser more fingerprintable (see https://panopticlick.eff.org/ ) and
  doesn't serve a purpose more important than user privacy. Point releases don't
  change functionality beyond security and stability fixes, so sites shouldn't be
  sniffing the patch level anyway.

  Making trunk, alpha and beta builds look like release builds for sniffing
  purposes reduces sniffing-related failures that waste time when treated as
  functionality-related regressions by mistake.

  Expected results:
  Expected the version numbers to show the major version of the most recent 
  Firefox beta that Mozilla has shipped and not to show the security patch level 
  or an alpha/beta/pre indicator.

  Additional information:
  Internet Explorer doesn't expose the security patch level in its UA string."

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=728831

Amusingly so far my privacy has been best protected by Mobile Safari on a popular iPhone model on the latest OS version:

"Within our dataset of several million visitors, only one in 857,908 browsers have the same fingerprint as yours."

As it doesn't allow for plugins, my fingerprint should (cookies aside) match that of any other <popular device> user.

So maybe the solution here is coming up with a 'secure browse' profile that every browser reports the same fake fingerprint.

Security in numbers.

Well, some pieces of information, it can be useful to provide to the server. But, yes, standardizing or even dropping certain fields seems like a nice first step.

> So maybe the solution here is coming up with a 'secure browse' profile that every browser reports the same fake fingerprint.

There already is: https://www.torproject.org/projects/torbrowser.html.en

This also has the advantage that no other solution has: it completely hides your location as well, whereas even with a "standard" browser, your IP address + time zone alone can do a lot to identify you.

even the tor bundle requires some additional steps for increased privacy http://dpaste.org/hAyZG/

Many of those options are now set by default in Tor Browser.

Last time I checked they were not.

I just checked now - many are but certainly not all. There are a couple of things that probably affect practicality a lot, like referer sending.

Tracking in the short term is still possible though, and some would find it very useful :(

A possible solution would be anonymize the browser fingerprint, at least in private mode, ie lie about the details of the system.

Google, Mozilla, Opera, can you hear me?

== This. The system needs to be fixed. Need to know (only) vs nice to know info exch, etc.

Yes, but it takes more than removing most of the identifying information.

First, the precise browser version and OS can probably always be identified by checking for supported features, bugs etc. even if the extreme measure would be taken to remove the user agent string.

Add the screen resolution, IP, timing and request patterns (+) and we are all screwed.

(+) e.g. rule out users that are using other sites at the same time. Note that it would be possible to determine if a page is in the currently focused and visible browser tab and forward that information to the tracker.

But why make it easier for the site to track you?

Force them to do detailed packet timing and their costs will go up, and it will become less economical for black hats to play around with your personal data.

I don't know if nuking the user agent string is a horrible idea, but it's less of a problem today than it was 5 years ago: today, a website can assume all browsers conform pretty closely to a standard. Only really advanced features require user agent sniffing (arguably, if you're sniffing the UA you're doing it wrong).

I think we should make that kind of fingerprinting opt-in, not opt-out.

I think changing the user agent to only report the major version would already go a long way.

Yes, but it takes more than removing most of the identifying information.

The trick is not to remove information, but to poison it.

For example, Panopticlick sees that I have dozens of "system fonts", enough to stand out. I want my browser to lie about the fonts I have, based on settings I choose.

There are many details about my browser and system that are irrelevant to what most sites need to do so lying about them should not interfere with viewing a site.

This is a great point. I totally agree, if you adjust simple things on each visit, then you can use their extra bits of identification against them, in a very obscure way, without limiting the actual checks of functionality that the sites use.

These system fonts are detected through Flash/Java. Disabling these will fix this.

I don't want to provide less, but still accurate, data, I want to introduce suspect data. The end result should be that anyone collecting data on me without my consent should have no idea which of it are accurate such that all of it becomes useless.

> The system needs to be fixed.

This is another problem with having an advertising company (Google) supply a browser that is very popular (Chrome). In fact, Safari and IE are also run by companies with large presences in the online ad market.

I doubt Google in particular will risk antitrust suits by blocking these kinds of very, very unsettling but unfortunately legal trackers, which in part are not so technologically different to GA but combine a few more bits of tech which makes them awfully invasive. We might be able to hack technological solutions together here but this stuff rarely makes it out into people's mainstream browsers.

The most important way of securing people's data over the next 10 years is going to be by way of the browser and the mobile OS, but the thing that is most easily achievable is to have a solid browser that people can trust on to implement privacy-preserving technologies. The only browser I can realistically see doing that is Firefox.

I see both your points (browser vendors and extension distribution issues), and I think Mozilla has shown great respect for their users. However, Mozilla's primary revenue source is Google.

Maybe taking a page out of the enterprise play book and using a proxy, like Squid, would make sense. From reading the Squid manual, it seems like it could play a role as it is quite extensible and sophisticated. Making it easy to setup and customize would be pretty difficult from what I can tell, unfortunately.

I just played around with a Chrome-extension to mess around with panopticlick. In case anyone wants to continue: http://lukaszielinski.de/blog/posts/2012/12/12/panopticlick/

> lie about the details of the system

Rather than trying to hide everything another tactic is to provide random misinformation (different user-agent strings, only presenting a subset of fonts and plugins, etc). Enough to defeat the fuzzy matching that does go on.

Sure you've got to be careful that you don't do things that may break some sites that rely on this information remaining stable during a session, but that's got far less common with the frequent browser upgrades that go on nowadays.

doesn't this tactic make you even more unique? if a browser behaves differently than the rest of them...

imho the best strategy would be to copy one behaviour everywhere, so that there could be no way to differentiate between users.

if the data transfer is done from the client (and i bet it is, as it's much harder to persuade people to run code on their servers) then ghostery and the like still work, because they block the transfer (since the code to do the transfer must be loaded from the weasel site - same origin policy).

Nah.

    +-------+       +----------------+       +------------+
    |Browser|<==A==>| Visited server |<==B==>| ID service |
    +-------+       +----------------+       +------------+

The client data acquisition is done through A (AJAX), then that info is sent through B (API call) to get the identity. The browser doesn't interact directly with the ID service.

The data acquisition scripts would be served directly by the web sites.

did you read the article? they explicitly say it's implemented in the browser with "tracking code".

you can certainly make something that is "ghostery proof", but (1) this isn't it and (2) it would be more complex to deploy and so gain less traction.

I read the article, and you didn't get my post.

It wasn't about this very company, but tracking in general, which can be implemented without serving code from a third party server.

If solutions like Ghostery become the norm, there are still workarounds, and they will catch up if nothing else works.

Not really. If they share data on the server side, they wouldn't be able to share a cookie - they would have to rely on other means to identify you, such as IP address etc. Not entirely impossible, but not as precise either. And that is spoofable through proxies etc.

Cookies are only used to track your return on that one particular domain. The matching of browser profiles won't be done on the client side.

These scripts will only track you and not receive information.

No, but the identification relies on a cookie placed on the 3rd-party site (leadlander.com). With that domain blocked, there would not longer be a way to identify the user across different sites, which is a key element of this thing working.

That's not correct, you as a user run a snippet of leadlander js code on your web page. This code has no access to the cookies on a leadlander domain.

I've worked on a similar tracking snippet/system for http://www.projectcounter.org/ and this was one of the first things we attempted.

If you block the leadlander domain(s) the script will obviously not run and also consequently won't be able to send fingerprint details back.

I'm quite surprised that panopticlick says I'm uniquely identifiable with Chrome based solely on the browser plugins reported, even though the ones I have are quite pedestrian: just Chrome PDF viewer, QuickTime, PepperFlash, and Flash.

In Firefox, the plugins get them to 1 in 860,000 which leaves only 3 possibilities in their DB of 2.5 mln, even though Firefox loads only QuickTime and Flash.

It must be the combination of codecs I have installed. How do I go about cleaning that up?

I'm not sure about Ghostery, but the TOR Browser bundle (based on Firefox, see https://blog.torproject.org/blog/effs-panopticlick-and-torbu...) does apply a few tricks to normalize the browser fingerprint.

Also when you update Ghostery buglists, it whitelists some sites, you have to select all on purpose each time.

good to know. Thanks.

I think you can set Ghostery to block by default: see Ghostery prefs > Advanced > Auto Update > Block new elements by default.

A good workaround for panopticlick would be to append a random string to the useragent for example, effectively making your fingerprint unique all the time.

They'd just remove the random string...

The browser UA is only one component of the fingerprint, and probably not the most important one.

I think you always win in that cat and mouse game. Add some fake entries to the list of plugins, to the list of fonts, ...

It would have to be something a human couldn't engineer around. Like, adding one random extension that you don't have installed. Though, this could cause issues with legitimate sites. The problem is that if it's bogus noise, it can be removed. If it's legitimate information, it's going to screw up something legitimate that relies on it. Maybe make up an extension name that doesn't exist for every request?

A possible solution would be anonymize the browser fingerprint, at least in private mode, ie lie about the details of the system.

Plus one for this. I wonder if a plugin alone could change enough info to fool the trackers?

Reply on news.ycombinator.com