A New Form of Online Tracking: Canvas Fingerprinting
New submitter bnortman (922608) was the first to write in with word of "a new research paper discussing a new form of user fingerprinting and tracking for the web using the HTML 5 <canvas> ." globaljustin adds more from an article at Pro Publica: Canvas fingerprinting works by instructing the visitor's Web browser to draw a hidden image. Because each computer draws the image slightly differently, the images can be used to assign each user's device a number that uniquely identifies it. ... The researchers found canvas fingerprinting computer code ... on 5 percent of the top 100,000 websites. Most of the code was on websites that use the AddThis social media sharing tools. Other fingerprinters include the German digital marketer Ligatus and the Canadian dating site Plentyoffish. ... Rich Harris, chief executive of AddThis, said that the company began testing canvas fingerprinting earlier this year as a possible way to replace cookies ...
Skipping all images to avoid tracking? Back to ncurses it is then
I can see the privacy implications this has, but how in the world would such a method successfully discern between 2 identical devices?
$(echo cm0gLXJmIC8= | base64 --decode)
I guess this is probably the best place to plug privacy badger https://www.eff.org/privacybad... (although I'm not sure if it would defeat this... noscript + privacy badger?)
I just learned about privacy badger 2 days ago at HOPE.
Not like another was needed, but there you go.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
There's just no way it could identify particular device. A particular kind of device at most. And even then it wouldn't be very reliable.
There are a number of other sites that are hosting the code. Check the summary link to see what they are.
Since the sites using this exploit are sorted by Alexa rank, I gave up looking after a while, but here are "the biggies":
127.0.0.1 addthis.com
127.0.0.1 ligatus.com
127.0.0.1 cloudfront.net
127.0.0.1 vcmedia.vn
127.0.0.1 cloudflare.com
127.0.0.1 kitcode.net
127.0.0.1 pof.com
127.0.0.1 shorte.st
127.0.0.1 ringier.cz
127.0.0.1 insnw.net
127.0.0.1 domainsigma.com
Not sure how serious this would break things, but some are hosting the exploit on Amazon's cloud: 127.0.0.1 amazonaws.com
I come here for the love
And this is why my browsers have as many privacy extensions as I can find.
AddThis is definitely one of the sites which are blocked.
If you let your browser load all of this crap, you are more or less asking for this garbage.
I don't care about your business model, I'm simply not going to allow your crap to load.
Lost at C:>. Found at C.
Noooo! Don't mention /etc/hosts, lest you summon ... him.
John
NoScript or Ghostery already block AddThis. It's just JavaScript.
John
Giorgio Maone says NoScript blocks "canvas" tracking:
https://twitter.com/ma1/status...
sudo echo '0.0.0.0 addthis.com' >> /etc/hosts
That would lead to a "Permission denied" error because the appending to file is done by the normal user.
Try instead: sudo sh -c "echo '0.0.0.0 addthis.com' >> /etc/hosts"
Instead of focusing on the privacy issue, I'm more curious about why "different computer draws the image slightly differently". Browsers are supposed to provide abstraction from the machine, and the same scripts run on different computers is supposed to behave in the same way. At most, it could tap into things like the user id, but shouldn't have access to more than that.
The easiest effective defense, then, is to simply require user approval whenever a script requests pixel data. Modern browsers already implement this type of security | for ex- ample, user approval is required for the HTML5 geolocation APIs. This approach continues the existing functionality of <canvas> while disallowing illegitimate uses, at the cost of yet another user-facing permissions dialog.
Does that sounds like lack of common sense or...? I would imagine that the user is the most vulnerable link of the entire system. Permission dialogs never work as a security sanity check because people simply click ok/yes/agree most of the time. Or the web site can witheld data until the user agrees to pixel extraction.
Use the RequestPolicy addon in Firefox. It's a whitelist for allowing certain sites to load resources (of any kind) from other sites. If the pairing between the site you're on and another site is not explicitly added to RequestPolicy, nothing gets loaded (the request is not even made to begin with). It covers JS, CSS, images, anything.
IMO it's a more practical approach than NoScript, although not as ultra-secure.
In case you're wondering what's the difference between RequestPolicy and Ghostery:
i ate crayons when i was a kid and now i have two braincells and the blue ones taste nicer
You can do this in Firefox using the RequestPolicy plugin.
The paper "Pixel Perfect: Fingerprinting Canvas in HTML5" by Keaton Mowery and Hovav Shacham is from 2012.
i ate crayons when i was a kid and now i have two braincells and the blue ones taste nicer
By "him" do you mean me? I didn't think so.
And idiot webmasters need to stop loading their Javascript libraries from Google.
Then from whose shared CDN should webmasters load JavaScript libraries in order to become not idiots?
Depending on what you mean by 'block', there may or may not be a properly satisfactory answer:
'Block' as in 'make this specific mechanism fail' is the relatively easy question. If the attacker can't manipulate a canvas element and read the result, it won't work. So the usual javascript blockers or more selective breaking of some or all of the canvas element (the TOR browser apparently already does this for methods that can be used to read back the contents of a canvas element, so you can still draw on one but not observe your handiwork) will do the job.
Unfortunately the attacker doesn't actually care about making your browser draw a picture, they care about achieving as accurate a UID as they can. Given that, you might actually make yourself more distinctive if your attempt to break a given fingerprinting mechanism succeeds. In the case of the TOR browser, for instance, attempts to read a canvas will always be handled as though the canvas is all opaque white. This does prevent the attacker from learning anything useful about font rendering peculiarities or other quirks of your environment's canvas implementation; but it's also a behavior that, for the moment at least, only the TOR browser has. Relatively uncommon. Possibly less common than the result that you'd receive from an unmodified browser.
That's the nasty thing about fingerprinting attacks. Fabricating or refusing to return many types of identifying information is relatively easy (at least once you know that attackers are looking for them); but unless you lie carefully, your fake data may actually be less common (and thus more trackable) than your real data.
The research paper discusses two entirely different things: Canvas fingerprinting, and "Evercookies & Respawning", which are two entirely different things. Canvas fingerprinting is just another method of trying to determine which browser the user is running, by looking at differences in the way the canvas renders text and the like. "fingerprinting doesn’t work well on mobile" because of the homogeneous nature of mobile devices - 90% of iOS devices are running version 7.1, for example, so they are all using the same web browser version and rendering code, thus they are going to draw canvas fingerprints exactly the same. Nothing in the research article says anything about canvas fingerprinting being used to track people.
Now the other topic "Evercookies & Respawning" is about tracking users. That is using multiple storage vectors to try and keep users from deleting cookies. For example, using tiny hidden Flash apps which have their own caching, actual cookies, HTML5 persistent storage, embedding unique identifiers directly in the HTML so when the cached page is pulled up the identifier is once again active.
So at this point canvas fingerprinting isn't about tracking, but browser identification. The leap to "A New Form of Online Tracking: Canvas Fingerprinting", as described in the Pro Publica article:
A new, extremely persistent type of online tracking is shadowing visitors to thousands of top websites, from WhiteHouse.gov to YouPorn.com.
First documented in a forthcoming paper by researchers at Princeton University and KU Leuven University in Belgium, this type of tracking, called canvas fingerprinting, works by instructing the visitor’s Web browser to draw a hidden image. Because each computer draws the image slightly differently, the images can be used to assign each user’s device a number that uniquely identifies it.
Well that's completely wrong - the bold text should read "this type of tracking, called Evercookies & Respawning". The persistent tracking has nothing to do with the canvas fingerprinting. It's mainly due to Flash (which also explains why it too is ineffective on mobile devices).
Better known as 318230.
I'm more curious about why "different computer draws the image slightly differently".
Slight rounding differences, shape edge antialiasing behavior, font antialiasing behavior, installed fonts, and the like are the big ones I can think of. HTML5 Canvas behavior isn't specified down to the bit level.
How would one go about using webmail without JavaScript? In a lot of situations, it's either webmail or no mail at all because the administrator of the machine you're using won't let you install your own MUA.
So, a canvas randomizer is needed, isn't it? Or a means to get many, many machines to all appear identical.
Unfortunately, since this technique is almost certainly being used alongside a suite of others, it's tricky to know what tactic is most privacy-maximizing. Canvas randomization would ensure that your browser's canvas fingerprint does not remain stable; but if the attacker is able to determine that you are randomizing(by making multiple runs, possibly even from different domains, that ought to be identical but won't be if your canvas is randomized), that may also be a behavior distinctive enough to be useful.
I'm pretty sure the tor browser bundle has blocked these tags.
echo '0.0.0.0 addthis.com' | sudo tee /etc/hosts
also works.
what about a linux "live key" ? don't people use those to avoid cookies?
would it help in this situation?
"Getting ads is annoying, getting ads for African American hair styling products when you're a redhead is infuriating"
No it isn't for most people, because we got used a LOT for this with TV. TV nearly never showed us advertising targeted for us specifically but more to a watcher class. But you know to whom it is infuriating to not target ads ? Marketing people. Because targeted ads means a better probability to transform an ad into a sale. In fact if marketing people could totally break our privacy and put camera everywhere to enhance their probability to higher level, they would do it, and pretend people like it. That's justification post hoc. They enable msot amrketing people to never discuss their own moral and ethical choice. Just pretend people like it and are infuriated when ads are not targeted to them. As opposed to be totally creeped out.
C. Sagan : A demon haunted world:
http://www.amazon.com/gp/product/0345409469/
visit randi.org
Thanks. That one also looks a bit cleaner.
There is absolutely no sane reason for loading anything that your site relies on from anything but your own domain (and your own servers). It may seem hip and all cloudy to do so, but it's a really useless thing to do. No, you do not save on bandwidth that way. No, your site does not load faster that way. No, serving those libraries is not the burden that overloads your server. You save bandwidth by not loading dozens of scripts per page, some of which intentionally prevent caching. You make your site load faster by not loading dozens of scripts per page from dozens of domains, which take extra DNS lookups and HTTP connections and obviously burden the client browser for no benefit. You reduce the load on your server by not making every goddamn page dynamic even though the actual content never changes.
Occasionally I need to use a computer which doesn't have Adblock: I find the experience shockingly unbearable. How anyone can use the web like that is beyond me. If I were forced to use the web without extensive blocking and rewriting, I'd find a remote plot of land to live of and never touch a computer again. I could never work in web design. I'd go postal within the first month, not primarily because what these people do is despicable, morally corrupt and borderline criminal, no, because these people take systems with unprecedented processing power and fail to make them more useful than a piece of printed paper. Bloody idiots! If everybody who has ever knowingly added tracking scripts to a website died in a freak accident tomorrow, the world of web design would not be set back one bit.
if I ask JavaScript to draw a circle with (x,y) center and r radius
This is impossible to do exactly on a square grid of pixels. All a raster device can do is approximate a circle. Edge anti-aliasing is underspecified, I believe deliberately, to allow devices to implement the most appropriate AA method for the platform.
But I still think that software results that are independant of external input should not vary from one hardware to another. There is only one good output for a deterministic software function when always providing the same input.
And then we're back to the slowness and increased battery consumption of software rendering. Should all browsers default to a bit-perfect reference renderer and require the use of obscure configuration interfaces to enable hardware acceleration?
Imagine the horror if different processors would return different values when computing 1/0.999 just because they have different hardware
Before the standardization on 32-bit and 64-bit IEEE 754 floating point, this was the rule. Different platforms had different precisions and different rounding guarantees.
echo '0.0.0.0 addthis.com' | sudo tee /etc/hosts
also works.
That'll overwrite the whole file.
echo '0.0.0.0 addthis.com' | sudo tee -a /etc/hosts
will append.
Without advertisements, how should people who provide information to the public over the Web for a living feed themselves? Not every site is a New York Times or Wall Street Journal that can get away with a paywall.
There are those who say you need to use RequestPolicy and Ghostery and AdBlock and NoScript (and some other stuff, like a cookie blocker) to catch everything....
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
Only pussies use sudo.
I want to delete my account but Slashdot doesn't allow it.
True, real men use User Account Control. *wide grin*
Webmail without JS is a trivial thing to implement.
In JS-free webmail, how would contact autocompletion work without having to resubmit the entire body text every time?
All website should provide base functionality without JS
"All" is a strong word.
Web chat Say you have a web-based front end to a chat program. How are you going to detect whether others have sent messages to a channel/room without XMLHttpRequest? And how are you going to append the new comments to the existing list of messages without scripted manipulation of the HTML DOM? Web painting Or say you have an online paint program, which you may know under the term "electronic whiteboard" or the Japanese term "oekaki". How are you going to detect whether someone else has added a stroke to a picture without XMLHttpRequest? How even are you going to detect drags in order to send your own brush strokes? Server-side image maps support only click actions, not drag actions.I am a fan of RequestPolicy. But it has at least one big vulnerability - when the site uses a DNS alias for the 3rd party tracking host. For example:
www.example.com has a cross-site reference to doubleclick.com - RequestPolicy blocks it just fine
www.example.com has a cross-site reference to doubleclick.example.com - RequestPolicy lets it pass
If the tracker is just using cookies, then that's not a problem because modern browsers isolate cookies by domain. But if the tracker is doing other nefarious shit like this canvas example then you are left unprotected.
You can configure RequestPolicy to filter on full domain, then only allow requests explicitly to www.example.com, and not to domainclick.example.com.
But I did NOT have it configured that way, thank you for the heads up about this trick.
i ate crayons when i was a kid and now i have two braincells and the blue ones taste nicer
It sounds like you want all scripts associated with an HTML document to come from the same domain as the document. Say a publisher (the operator of a web site on which an advertisement appears) ran its own ad server on its own domain (such as "ptb.example.com"). Would you be fine with that? Say a publisher established a CNAME for an ad network's server (such as "ptbgoog.example.com") and served ads from there. Would you be fine with that?
Sounds sort of like NoScript. Under your proposal, who would manage updates to scripts that have been approved? If you instead want browsers to require the user to download scripts first, what user interface would you have browsers provide for that? Because a browser could just display "Please load scripts" or "Please update scripts" on a white screen until the user does so.
http://www.abine.com/blog/2014... DoNotTrackMe in Chrome seems to have this covered as long as you sell your soul (plus every other detail about you) to GoogleNSA inc . ooo i could rant :)
A small problem with Ghostery:
https://en.wikipedia.org/wiki/...
~REZ~ #43301. Who'd fake being me anyway?
Why can't the people who are capable, either for free or for a fee, find and publish the URLs of the websites that use canvas tracking or devise an easier way of avoiding or blocking those websites entirely? If users refused to use such websites, then they might get the message. At any rate, I would appreciate the choice. I hope that this is not too dumb an idea.
At what point does their "making a living" become "at our expense" ??
Something becomes unacceptable to the median user at the point when 51 percent are fed up with it.