Online tracking: A 1-million-site measurement and analysis(webtransparency.cs.princeton.edu)
webtransparency.cs.princeton.edu
Online tracking: A 1-million-site measurement and analysis
https://webtransparency.cs.princeton.edu/webcensus/index.html
256 comments
What can be done by the browser vendors such as Mozilla, Google, and Microsoft?
To prevent fingerprinting, your browser has to disable all sorts of useful modern JavaScript API's (e.g., WebRTC) by default, prevent spurious HTTP requests (e.g., to prevent abusing @font-face to find out which fonts are installed), and pretend you are an American using the most popular web browser of the moment (i.e., hide the user's preferred language and claim en-US as your preference, and change the user agent string to blend in to the crowd).
This is all assuming people don't run any third party plugins like Flash.
Are browser vendors on track to figure out a solution to this problem that combines user friendliness with privacy? Or will anonymous browsing remain a privilege for those with the right amount of technical know-how?
The problem it seems is that simply disabling JavaScript is not an option for normal web browsing, and even a requirement for interacting with the web services used by organisations you have a relation with (e.g., the government, insurance companies, banks, etcetera).
To prevent fingerprinting, your browser has to disable all sorts of useful modern JavaScript API's (e.g., WebRTC) by default, prevent spurious HTTP requests (e.g., to prevent abusing @font-face to find out which fonts are installed), and pretend you are an American using the most popular web browser of the moment (i.e., hide the user's preferred language and claim en-US as your preference, and change the user agent string to blend in to the crowd).
This is all assuming people don't run any third party plugins like Flash.
Are browser vendors on track to figure out a solution to this problem that combines user friendliness with privacy? Or will anonymous browsing remain a privilege for those with the right amount of technical know-how?
The problem it seems is that simply disabling JavaScript is not an option for normal web browsing, and even a requirement for interacting with the web services used by organisations you have a relation with (e.g., the government, insurance companies, banks, etcetera).
Personally I think there are so many of these APIs that for the browser to try to prevent the ability to fingerprint is putting the genie back in the bottle.
But there is one powerful step browsers can take: put stronger privacy protections into private browsing mode, even at the expense of some functionality. Firefox has taken steps in this direction https://blog.mozilla.org/blog/2015/11/03/firefox-now-offers-...
Traditionally all browsers viewed private browsing mode as protecting against local adversaries and not trackers / network adversaries, and in my opinion this was a mistake.
But there is one powerful step browsers can take: put stronger privacy protections into private browsing mode, even at the expense of some functionality. Firefox has taken steps in this direction https://blog.mozilla.org/blog/2015/11/03/firefox-now-offers-...
Traditionally all browsers viewed private browsing mode as protecting against local adversaries and not trackers / network adversaries, and in my opinion this was a mistake.
Google has explicitly WontFix'd bugs on the subject of expanding incognito to be hardened against fingerprinting: https://bugs.chromium.org/p/chromium/issues/detail?id=142214...
Don't you think this sort of thing warrants a separate sort of browsing mode? A lot of people who use the likes of incognito mode just use it for e.g. browsing porn where they don't want the local history to be preserved.
Turning that mode into one that's highly hardened against fingerprinting would in practice ruin the browsing experience for those users. Just look at what the Tor browser needs to do with fixed preset resolutions, no JavaScript etc.
Don't you think this sort of thing warrants a separate sort of browsing mode? A lot of people who use the likes of incognito mode just use it for e.g. browsing porn where they don't want the local history to be preserved.
Turning that mode into one that's highly hardened against fingerprinting would in practice ruin the browsing experience for those users. Just look at what the Tor browser needs to do with fixed preset resolutions, no JavaScript etc.
> Google has explicitly WontFix'd bugs on the subject of expanding incognito to be hardened against fingerprinting
Obviously. Google is in the business of destroying your privacy: Advertising revenue is maximized when the consumer is/remains completely tracked and profiled at all times.
Other browser vendors which are not in the ad business could use this as an opportunity to differentiate themselves from Google:
Introduce a 3rd browsing mode which kills fingerprinting (with the "cost" of reduced user friendliness).
Obviously. Google is in the business of destroying your privacy: Advertising revenue is maximized when the consumer is/remains completely tracked and profiled at all times.
Other browser vendors which are not in the ad business could use this as an opportunity to differentiate themselves from Google:
Introduce a 3rd browsing mode which kills fingerprinting (with the "cost" of reduced user friendliness).
Google already has that info without these hacks.
In fact it is in googles best interest to remove these security holes so other advertisers lose whatever minor advantage they can get.
In fact it is in googles best interest to remove these security holes so other advertisers lose whatever minor advantage they can get.
Or just let the user decide at the start of a private session. Firefox already does this with tracking protection. If Mozilla decides to improve tracking protection at the cost of usability (such as hiding you preferred language), than offering that as a toggle-able option on that page might be sufficient to empower the user to decide for on his own.
> offering that as a toggle-able option on that page might be sufficient
Technically speaking yes.
From a marketing/communication standpoint, I would separate this "feature" clearly from the 2 known browsing experiences. It not only clearly communicates to the user that a different browsing experience is about to start. By selling it as "the third browsing mode", it definitely also adds more perceived value to the product.
Technically speaking yes.
From a marketing/communication standpoint, I would separate this "feature" clearly from the 2 known browsing experiences. It not only clearly communicates to the user that a different browsing experience is about to start. By selling it as "the third browsing mode", it definitely also adds more perceived value to the product.
> Don't you think this sort of thing warrants a separate sort of browsing mode? A lot of people who use the likes of incognito mode just use it for e.g. browsing porn where they don't want the local history to be preserved.
Think about it this way, would those using incognito mode for porn be OK with their normal browsing being peppered with ads claiming to "Improve your <fetish> with our range of <sexual implements>"?
Whilst I think incognito mode's warnings about not hiding data from network operators should remain (i.e. your boss can find out what sites you were visiting at work), that doesn't mean efforts to prevent it shouldn't be made.
Think about it this way, would those using incognito mode for porn be OK with their normal browsing being peppered with ads claiming to "Improve your <fetish> with our range of <sexual implements>"?
Whilst I think incognito mode's warnings about not hiding data from network operators should remain (i.e. your boss can find out what sites you were visiting at work), that doesn't mean efforts to prevent it shouldn't be made.
> there are so many of these APIs that for the browser to try to prevent the ability to fingerprint is putting the genie back in the bottle.
I disagree. If there were billions to be made from this new tech, secure browsing, then the browser vendors would be moving rapidly toward it. Certainly, more difficult technical challenges are overcome regularly.
Surveillance was implemented without users' knowledge and without public debate, presented as a fait accompli, and now the latest tactic is to say there's nothing that can be done about it. People accept that because they feel helpless, but I don't think we should be perpetuating this rhetoric of inevitiability. There's no technical reason it can't be done.
I disagree. If there were billions to be made from this new tech, secure browsing, then the browser vendors would be moving rapidly toward it. Certainly, more difficult technical challenges are overcome regularly.
Surveillance was implemented without users' knowledge and without public debate, presented as a fait accompli, and now the latest tactic is to say there's nothing that can be done about it. People accept that because they feel helpless, but I don't think we should be perpetuating this rhetoric of inevitiability. There's no technical reason it can't be done.
That's not effective, because very few people use private mode.
The browser vendors could start taking the idea of asking for permission seriously.
For WebRTC, browsers could block local addresses. uBlock Origin can do this on Firefox already.
For battery: browsers could treat it like location and ask for permission. Why does the average site need to know my battery status?
For fonts: browsers could standardize a list of system fonts available on each platform. It's 2016 already: web fonts are here, are widely supported, and no legitimate website should be relying on some oddball manually installed font.
This problem is hard to solve, but the Tor browser has it mostly solved. Other browsers could learn from it.
For WebRTC, browsers could block local addresses. uBlock Origin can do this on Firefox already.
For battery: browsers could treat it like location and ask for permission. Why does the average site need to know my battery status?
For fonts: browsers could standardize a list of system fonts available on each platform. It's 2016 already: web fonts are here, are widely supported, and no legitimate website should be relying on some oddball manually installed font.
This problem is hard to solve, but the Tor browser has it mostly solved. Other browsers could learn from it.
For WebRTC, this behavior is now default in Chrome since version 48. Please see the release notes here: https://groups.google.com/d/msg/discuss-webrtc/_5hL0HeBeEA/H...
Exactly - most sites don't need my exact location, or access to WebAudio or whatever. It should be a red flag for most sites, however most users won't know how to react in such a situation.
> browsers could standardize a list of system fonts available on each platform.
It would probably make sense to completely disable support for local fonts unless permitted by the user (for legacy websites that depend on it). All modern browsers support @font-face, and without @font-face you can always depend on the special keywords serif, sans-serif, and monospace; these will load the system's default font for that category.
It would probably make sense to completely disable support for local fonts unless permitted by the user (for legacy websites that depend on it). All modern browsers support @font-face, and without @font-face you can always depend on the special keywords serif, sans-serif, and monospace; these will load the system's default font for that category.
I hope there is another way to solve it, as I have installed web-fonts to my PC to improve page loading speed for some common fonts I keep seeing (the most recent being the Roboto font stack from google).
It would be a shame to have to keep re-downloading that every time.
It would be a shame to have to keep re-downloading that every time.
You don't have to. Fonts should be (and usually are) offered to the web browser with the instruction to cache them indefinitely. You will only have to re-download them when your cache is cleaned up (due to its size, private browsing, or manually cleaning it). Upcoming technology WOFF2 helps further compress them by a significant margin as well (I've seen up to 50% improvement in size over plain WOFF).
The problem is that the behaviour you are describing is also one of the ways a fingerprinter gets its data on your fonts; by specifying an @font-face declaration that first tries for a local font, and only loads a remote font if that is not found. Do this for a short-list of popular but distinct fonts (such as Roboto), and you have a nice amount of bits of identifying data to add to the stack.
Also, tricks like these exist (using rendering metrics to detect fonts):
http://www.lalit.org/lab/javascript-css-font-detect/
The problem is that the behaviour you are describing is also one of the ways a fingerprinter gets its data on your fonts; by specifying an @font-face declaration that first tries for a local font, and only loads a remote font if that is not found. Do this for a short-list of popular but distinct fonts (such as Roboto), and you have a nice amount of bits of identifying data to add to the stack.
Also, tricks like these exist (using rendering metrics to detect fonts):
http://www.lalit.org/lab/javascript-css-font-detect/
Browser caches are extremely unreliable and pretty small in the grand scheme of things.
On some mobile platforms the browser cache can be replaced entirely by some heavy pages!
Plus, even if we assumed "cached forever" actually worked for a significant amount of time, it still doesn't solve the problem that I am hoping to solve. I know many websites use the Roboto font. By installing it I no longer need to ever download that font again. It doesn't matter if it's the first time i'm seeing the site, if they use a CDN, if they link to the bold/light/regular version or their own packed font, etc...
I understand that it's a privacy issue, but I'm hoping there is a way to solve that privacy issue without removing that feature.
On some mobile platforms the browser cache can be replaced entirely by some heavy pages!
Plus, even if we assumed "cached forever" actually worked for a significant amount of time, it still doesn't solve the problem that I am hoping to solve. I know many websites use the Roboto font. By installing it I no longer need to ever download that font again. It doesn't matter if it's the first time i'm seeing the site, if they use a CDN, if they link to the bold/light/regular version or their own packed font, etc...
I understand that it's a privacy issue, but I'm hoping there is a way to solve that privacy issue without removing that feature.
I would go further and disable remote fonts as well since it's not crucial like images and is an attack vector that should have been avoided. The better solution would have been a shared set of web fonts distributed with browsers, just like certificates.
I don't see why fonts are any different from images.
Fonts are different in that they're not as crucial to the content as images. You cannot replace an image with an alternative text form while retaining the content, but you can display the content completely with WOFF missing.
I think the logical conclusion of that argument is to also disable all CSS. Fonts are styling for text, CSS is styling for markup. I think most the arguments against disabling CSS can be used against disabling fonts (barring that people do crazy shit with CSS most often now, so it complicates the issue).
Really, in the end, all input accepted from the remote side (including text/html) needs to be vetted and processed by security conscious routines. I don't personally have a reason to assume a font library is more likely to be exploitable than an HTML+CSS parser and layout engine. Based on complexity, I would actually assume the opposite, which is probably right, except we've already found and fixed a lot of the exploits for the HTML parser and layout engine.
Really, in the end, all input accepted from the remote side (including text/html) needs to be vetted and processed by security conscious routines. I don't personally have a reason to assume a font library is more likely to be exploitable than an HTML+CSS parser and layout engine. Based on complexity, I would actually assume the opposite, which is probably right, except we've already found and fixed a lot of the exploits for the HTML parser and layout engine.
I've considered what might be necessary to dispose of server-side CSS.
A set of standard page templates could do it. Clients could then choose their preferred client-side CSS to apply. Article, index page, image gallery, catalog entry, search result, etc.
Seems a finite set should cover most needs. Which ought be available from a few fairly standard sources (CMS, blogging engines, frameworks).
A set of standard page templates could do it. Clients could then choose their preferred client-side CSS to apply. Article, index page, image gallery, catalog entry, search result, etc.
Seems a finite set should cover most needs. Which ought be available from a few fairly standard sources (CMS, blogging engines, frameworks).
As I see it, the web is the most vibrant medium of expression and innovation we have today. While I don't doubt there would be gains in security to limiting it in many aspects, I question whether the specific level of security gain would be worth the loss of innovation and expression. I think there are many areas we could focus on instead that would increase security without the same level of negative consequences, so I espouse doing those first.
Not to mention I don't think it's a solution that's viable given economic principle and how much people value expression. We'd just be back to the equivalent of Flash sites again, with whatever takes over for flash (canvas?).
Not to mention I don't think it's a solution that's viable given economic principle and how much people value expression. We'd just be back to the equivalent of Flash sites again, with whatever takes over for flash (canvas?).
It's not just security, the other half is usability. The way popular web sites work is that they change stuff around regularly only to make it look different but change the behavior as well. This breaks stuff like existing functionality, key+mouse sequences to get stuff done, places you've learned to look at and navigate to quickly. Computers and modern appliances (including cars) are strangely affected by this constant desire to shift things around unnecessarily because someone told them they could sell it as it looks different now.
GitHub and gmail are prime examples for sites that broke a lot of things in the process.
Maybe what we need instead are real APIs and custom clients.
GitHub and gmail are prime examples for sites that broke a lot of things in the process.
Maybe what we need instead are real APIs and custom clients.
Consider the implications of what this means though. If sites are not free to innovate, things like Github and Gmail wouldn't exist. They only reason we aren't stuck with a Hotmail interface circa 2002 is because people were able to innovate on the web. To lock down CSS (or Javascript, there's no reason I can think of you would lock CSS and not Javascript) to a specific set of capabilities is both a statement that it is sufficient for all needs, and that we can decide by committee what is a good set of standards to lock into. I think both assertions are laughable false.
If we had locked down CSS five years ago, what CSS would be not be capable of using today? If we lock it down today, what would we be missing out on that would come five years from now?
Design by committee is horribly inefficient, and rarely takes into consideration the full needs of the users. What's more, it can't take into consideration future needs. Design by committee gets us XML. Adoption by iteration and evolution gets us JSON. XML has its place, but JSON is overwhelmingly more popular in certain contexts for a reason, it fits the domain better.
Lastly, iterating on Github and Gmail would not stop even if there was a complete lack of CSS and Javascript, it would just be more tedious as everything was done through a full page serve, just like the old days. That wouldn't prevent site redesigns along with missing or broken features, it would just make everything look shittier, perform slower, and use more server side resources.
That said, a sane standard for embedded interfaces, where choice is restricted, it needs to live a long time, and needs to have sane accessibility features would do well with better standards. I view that as a separate problem.
If we had locked down CSS five years ago, what CSS would be not be capable of using today? If we lock it down today, what would we be missing out on that would come five years from now?
Design by committee is horribly inefficient, and rarely takes into consideration the full needs of the users. What's more, it can't take into consideration future needs. Design by committee gets us XML. Adoption by iteration and evolution gets us JSON. XML has its place, but JSON is overwhelmingly more popular in certain contexts for a reason, it fits the domain better.
Lastly, iterating on Github and Gmail would not stop even if there was a complete lack of CSS and Javascript, it would just be more tedious as everything was done through a full page serve, just like the old days. That wouldn't prevent site redesigns along with missing or broken features, it would just make everything look shittier, perform slower, and use more server side resources.
That said, a sane standard for embedded interfaces, where choice is restricted, it needs to live a long time, and needs to have sane accessibility features would do well with better standards. I view that as a separate problem.
As cm3 notes, usability is as much if not more a concern than privacy and security. Though I'd not dislodge any of these three from a position of high primacy.
There's a risk / frequency trade off with all of these. Privacy can be quite possibly costly or fatal, though slightly more rare. Not so rare though that 20% of all Web users in a US Department of Commerce survey (see my recent comments history) report known credit card fraud. That's many tens of millions of affected users.
The security risks are similar but also extend to organisations which might stand to lose control over their own (validly) private information, or control over systems (see for example concerns over SCADA infrastructure, or industrial process control).
Usability and adaptability issues pose lower risks, but have a much larger affected field.
It goes well beyond the visually disabled, illiterate, and cognitively challenged. Anyone who's landed on a desktop site that's unusable on mobile has encountered a usability challenge. Google, Apple, Facebook, and Amazon are all rapidly pushing us, some kicking and screaming (I include myself) to an audible Web -- one in which the primary control and response interfaces are spoken.
What landing on a small set of templates does is provide for clearly parseable and understandable content. In a world where the goal isn't to read a full page but to extract and convey a useful item of information from it, wading verbally through megabytes of unparsable and nonexcludable content isn't particularly useful (and yes, figuring out how much a data reference is worth to the data-rerference intermediary is another question worth considering).
More generally, in my case, with only modest perceptual impairments (reading small, low-contrast type is among the earlier signs of your impending death), I've come to conclude for some years now that Web design isn't the solution, Web design is the problem. There are only so many ways you can present content that doesn't fuck with readability. I try, very hard, to ensure I'm not doing this on my own modest designs (look up "Edward Morbius's Motherfucking Web Page", a riff on a popular refrain, for my own principals in action).
My most common response when landing on a website is to sigh, roll my eyes, and dump it to something more readable. Firefox's Reader Mode. Pocket. Straight ASCII text. w3m.
And no, "novel graphic design" isn't conveying vast new amounts of information. I grew tired of hearing that argument 30 years ago, it's not got fresher since. Bloomberg, The New York Times, and the BBD are all experimenting with high-concept article formatting. In my experienct, without exception, it simply Gets In The Fucking Way.
My half-serious response to this is to create a new web browser embodying these and a few other principles. The working title is "the fuck your web design browser". FYWD for short.
Ninnies may opt to call it the Fine Young Western Dinosaurs browser as an alternative.
There's a risk / frequency trade off with all of these. Privacy can be quite possibly costly or fatal, though slightly more rare. Not so rare though that 20% of all Web users in a US Department of Commerce survey (see my recent comments history) report known credit card fraud. That's many tens of millions of affected users.
The security risks are similar but also extend to organisations which might stand to lose control over their own (validly) private information, or control over systems (see for example concerns over SCADA infrastructure, or industrial process control).
Usability and adaptability issues pose lower risks, but have a much larger affected field.
It goes well beyond the visually disabled, illiterate, and cognitively challenged. Anyone who's landed on a desktop site that's unusable on mobile has encountered a usability challenge. Google, Apple, Facebook, and Amazon are all rapidly pushing us, some kicking and screaming (I include myself) to an audible Web -- one in which the primary control and response interfaces are spoken.
What landing on a small set of templates does is provide for clearly parseable and understandable content. In a world where the goal isn't to read a full page but to extract and convey a useful item of information from it, wading verbally through megabytes of unparsable and nonexcludable content isn't particularly useful (and yes, figuring out how much a data reference is worth to the data-rerference intermediary is another question worth considering).
More generally, in my case, with only modest perceptual impairments (reading small, low-contrast type is among the earlier signs of your impending death), I've come to conclude for some years now that Web design isn't the solution, Web design is the problem. There are only so many ways you can present content that doesn't fuck with readability. I try, very hard, to ensure I'm not doing this on my own modest designs (look up "Edward Morbius's Motherfucking Web Page", a riff on a popular refrain, for my own principals in action).
My most common response when landing on a website is to sigh, roll my eyes, and dump it to something more readable. Firefox's Reader Mode. Pocket. Straight ASCII text. w3m.
And no, "novel graphic design" isn't conveying vast new amounts of information. I grew tired of hearing that argument 30 years ago, it's not got fresher since. Bloomberg, The New York Times, and the BBD are all experimenting with high-concept article formatting. In my experienct, without exception, it simply Gets In The Fucking Way.
My half-serious response to this is to create a new web browser embodying these and a few other principles. The working title is "the fuck your web design browser". FYWD for short.
Ninnies may opt to call it the Fine Young Western Dinosaurs browser as an alternative.
> My most common response when landing on a website is to sigh, roll my eyes, and dump it to something more readable. Firefox's Reader Mode. Pocket. Straight ASCII text. w3m.
> My half-serious response to this is to create a new web browser embodying these and a few other principles.
In all seriousness, I wonder if spoofing a mobile client (easily done through most browser developer console's or an extension) might immediately result in a more useful experience for you on the majority of sites. Given the viewing constraints of most mobile platforms, and the focus on mobile accessibility (it's supposed to account for over 50% of traffic now), I imagine many sites try to but some minimum level of effort in to at least make it usable.
> My half-serious response to this is to create a new web browser embodying these and a few other principles.
In all seriousness, I wonder if spoofing a mobile client (easily done through most browser developer console's or an extension) might immediately result in a more useful experience for you on the majority of sites. Given the viewing constraints of most mobile platforms, and the focus on mobile accessibility (it's supposed to account for over 50% of traffic now), I imagine many sites try to but some minimum level of effort in to at least make it usable.
I have this hope that Servo will lend itself to modularity and building a usable web client with it.
Of course you're right, and I didn't mention CSS but thought of it as another utilitarian piece.
I agree that the most complex parts are HTML+CSS+JS+DOM+GFX, but some parts cannot be reasonably disabled without breaking it completely.
I agree that the most complex parts are HTML+CSS+JS+DOM+GFX, but some parts cannot be reasonably disabled without breaking it completely.
Actually, that makes me wonder — if I spoof 5% battery charge will I get fewer annoying features on any sites?
You'll get more ads for chargers and laptop batteries.
Good idea.
> Why does the average site need to know my battery status?
I would go further and suggest that really no site needs to know it (I am sure there could be a few reasonable uses, but still). Which makes me wonder if we could strike back by abusing the WebRTC spec and fuzzing values like these, instead of simply blocking them.
I would go further and suggest that really no site needs to know it (I am sure there could be a few reasonable uses, but still). Which makes me wonder if we could strike back by abusing the WebRTC spec and fuzzing values like these, instead of simply blocking them.
> For WebRTC, browsers could block local addresses.
That would defeat a huge selling point of WebRTC, the ability to create in-browser p2p connections over the user's local network.
That would defeat a huge selling point of WebRTC, the ability to create in-browser p2p connections over the user's local network.
I'm not familiar with WebRTC. What's the use case there? I can't remember ever wanting to create an in-browser p2p connection on my local network. What would it be used for?
Please read the Chrome 48 release notes, WebRTC's default behavior has changed. https://groups.google.com/d/msg/discuss-webrtc/_5hL0HeBeEA/H...
But it still ignores the proxy settings and will use STUN to discover your "external IP". Thus users that think they are using a proxy end up not actually doing so.
WebRTC is a secure real-time protocol for audio, video, and data.
You'd want to use it any time you want a high-speed network connection with another user. For example, a multiplayer game or video teleconference.
You'd want to use it any time you want a high-speed network connection with another user. For example, a multiplayer game or video teleconference.
in-company hangouts, video conferencing, etc. Without p2p on local network that would have go outside the company and back in.
Others have pointed out this behavior has changed in Chrome 48. You don't get the local IP unless the page asks for access to the mic/camera which the user has to give permission for.
Others have pointed out this behavior has changed in Chrome 48. You don't get the local IP unless the page asks for access to the mic/camera which the user has to give permission for.
I think the answer isn't technical, but legal and cultural. Make it unacceptable in the court of public opinion for companies to misuse this data, and strengthen privacy laws.
These two things, of course, go hand-in-hand, but us techies tend to look, I think, for the technical solution because that's the place where it's easiest to see how we could have any sort of impact. The other stuff is a lot of talking to and listening to people, consensus-building, being persuasive, etc.
These two things, of course, go hand-in-hand, but us techies tend to look, I think, for the technical solution because that's the place where it's easiest to see how we could have any sort of impact. The other stuff is a lot of talking to and listening to people, consensus-building, being persuasive, etc.
Legislation and regulation are necessary, and they tend to help to keep the really big boys in check, but how can you actually tell if a company is actively engaged in compiling profiles on you or not? I can ask my browser to pass the Do-Not-Track header indicating my objection that practice, but why would a company specialised in tracking users respect that header?
I have tried to convince the Dutch banks I use (ING and ABN AMRO, i.e., big banks) to stop employing tracking beacons and third party tracking services on their secured internet banking environments, but the responses I get range from 'yeah we need those to improve your customer experience' to 'you are welcome to block these trackers yourself' (I already do, thank you very much).
I have tried to convince the Dutch banks I use (ING and ABN AMRO, i.e., big banks) to stop employing tracking beacons and third party tracking services on their secured internet banking environments, but the responses I get range from 'yeah we need those to improve your customer experience' to 'you are welcome to block these trackers yourself' (I already do, thank you very much).
How about using the permission system? You don't have to disable WebGL by default, but you can ask users for permission when it's needed (usually in a game).
Other stuff like GPS, camera, and microphone already require permission before being used.
Other stuff like GPS, camera, and microphone already require permission before being used.
What about time and date? I'm almost certain NetFlix uses this to detect geo-unblocking.
Netflix uses an up-to-date list of known VPN-endpoints in addition to a database of IP-ranges by country. They don't need to detect anything client-side. This list is constantly in flux though, so sometimes accessing Netflix via VPN works, sometimes it doesn't.
When everybody was running Windows on a smorgasbord of hardware / patchlevel / plugins / fonts, it was easy to fingerprint. Are we moving towards a more monolithic landscape where fingerprinting is less able to track individual users?
* If I have a fleet of Chromebooks running the same version of Chrome OS, will they all have the same fingerprint?
* Will, say, all iPhones 6 with the same hardware parts, running the same Mobile Safari and iOS version, have the same fingerprint?
Thank you!
* If I have a fleet of Chromebooks running the same version of Chrome OS, will they all have the same fingerprint?
* Will, say, all iPhones 6 with the same hardware parts, running the same Mobile Safari and iOS version, have the same fingerprint?
Thank you!
Why yes, some monoculture has made fingerprinting harder. Try [0] with a few of those devices.
0: https://panopticlick.eff.org/
0: https://panopticlick.eff.org/
Thanks for this research, really interesting to see.
I do want to state for the record that instinctiveads.com was testing augur.io and that's why we're listed there. We don't use them anymore but unfortunate timing, especially considering we're trying to be a better ad network than the rest.
Also I'd like to point out that one of the most pervasive tracking methods is done through form submissions. Anywhere you submit an email (login, purchase, etc) can be used as identification and first-party cookie matching.
I do want to state for the record that instinctiveads.com was testing augur.io and that's why we're listed there. We don't use them anymore but unfortunate timing, especially considering we're trying to be a better ad network than the rest.
Also I'd like to point out that one of the most pervasive tracking methods is done through form submissions. Anywhere you submit an email (login, purchase, etc) can be used as identification and first-party cookie matching.
Having the insight of of someone who works in online advertising would be interesting and informative. Is there anything you can share that we might find interesting?
I could talk about this for hours. Fundamentally, identity is important for the ad industry but it's not about your personal info, it's just a reliable ID that we're all after.
A reliable ID allows for storing your ad history and interests to show you better ads and less of the same. This is proven since it's all math and data science and we can see the increase in metrics with better targeting. By the way, clicks are not the most important metric either, there's much more that goes into an ad campaign. Ironically, reliable IDs also allow for storing any opt-out settings since it's just a value attached to that ID.
The email login I mentioned above is the most common way to track online, most of the big sites actually sell login data and fire tracking tags when you're logged in with the email address passed through (usually hashed but not always) so that providers can set their own cookies and recognize you again. Since emails are strongly unique, this is really effective.
This tech is also used to combat ad fraud (which is what we were using it for). Fraud is a massive problem since it's so easy to start up botnets and churn through millions of ad impressions quickly.
Unfortunately a lot of this new age of tracking is the result of politics, bad incentives, and a lack of regulation that's led to a wild west situation where these companies can do anything. Clearly the technical talent is capable (as seen in this research) but it's being put to the wrong use. The DNT (do not track) header was a compromise but lacked any real regulation to make it effective. 3rd party cookies were fine but unfairly demonized and the default blocking of them pushed the industry to these deeper tactics.
Ultimately this is a business process issue: if there was a standardized ID like IDFA but for browsers (or even better at the OS level) and privacy regulation that's actually enforced, that would be a good compromise. Sites and ad networks get a reliable ID and you get control over when and how that ID is refreshed.
EDIT - All this stuff used by independent ad companies is just a tiny fraction of the industry. This barely covers ISPs who have very refined tracking abilities that you really cant avoid since they control the traffic. Comcast/Verizon has the AOL ad network using this. And the 2 biggest ad companies are Google and Facebook, both of which don't need fingerprinting because they already know who you are from just being logged in.
A reliable ID allows for storing your ad history and interests to show you better ads and less of the same. This is proven since it's all math and data science and we can see the increase in metrics with better targeting. By the way, clicks are not the most important metric either, there's much more that goes into an ad campaign. Ironically, reliable IDs also allow for storing any opt-out settings since it's just a value attached to that ID.
The email login I mentioned above is the most common way to track online, most of the big sites actually sell login data and fire tracking tags when you're logged in with the email address passed through (usually hashed but not always) so that providers can set their own cookies and recognize you again. Since emails are strongly unique, this is really effective.
This tech is also used to combat ad fraud (which is what we were using it for). Fraud is a massive problem since it's so easy to start up botnets and churn through millions of ad impressions quickly.
Unfortunately a lot of this new age of tracking is the result of politics, bad incentives, and a lack of regulation that's led to a wild west situation where these companies can do anything. Clearly the technical talent is capable (as seen in this research) but it's being put to the wrong use. The DNT (do not track) header was a compromise but lacked any real regulation to make it effective. 3rd party cookies were fine but unfairly demonized and the default blocking of them pushed the industry to these deeper tactics.
Ultimately this is a business process issue: if there was a standardized ID like IDFA but for browsers (or even better at the OS level) and privacy regulation that's actually enforced, that would be a good compromise. Sites and ad networks get a reliable ID and you get control over when and how that ID is refreshed.
EDIT - All this stuff used by independent ad companies is just a tiny fraction of the industry. This barely covers ISPs who have very refined tracking abilities that you really cant avoid since they control the traffic. Comcast/Verizon has the AOL ad network using this. And the 2 biggest ad companies are Google and Facebook, both of which don't need fingerprinting because they already know who you are from just being logged in.
> if there was a standardized ID like IDFA but for browsers (or even better at the OS level) and privacy regulation that's actually enforced, that would be a good compromise. Sites and ad networks get a reliable ID and you get control over when and how that ID is refreshed.
To detect ad fraud, would the ID need to be the same on all sites? Instead of sites dropping cookies on clients, what if browsers generated their own random per-site IDs? Users and browsers would have more control over managing and clearing cookies and user IDs.
To detect ad fraud, would the ID need to be the same on all sites? Instead of sites dropping cookies on clients, what if browsers generated their own random per-site IDs? Users and browsers would have more control over managing and clearing cookies and user IDs.
Yes the ID would have to be the same, just like it is on mobile (Android Advertising ID, iOS IDFA) and would be best at the device level but browser would be a start.
If it's unique to every site then it's nothing new, networks can already set IDs today with 1st party cookies. It's being able to have a internet-wide ID that's valuable and is what 3rd party cookies allow(ed).
The ID itself doesn't matter, it's just random characters and mapped in various ways by networks. It's the reliability and consistency on a device level that's needed. Having something like this would make a massive difference - all the cookies/tracking junk would be obsolete, along with the hundreds of pixel sync tags, and would make everything faster, more accurate, more private and more secure.
If it's unique to every site then it's nothing new, networks can already set IDs today with 1st party cookies. It's being able to have a internet-wide ID that's valuable and is what 3rd party cookies allow(ed).
The ID itself doesn't matter, it's just random characters and mapped in various ways by networks. It's the reliability and consistency on a device level that's needed. Having something like this would make a massive difference - all the cookies/tracking junk would be obsolete, along with the hundreds of pixel sync tags, and would make everything faster, more accurate, more private and more secure.
Why would two browsers with the exact same user agent (ie same, version, same OS, same arch) yield two different renditions of an audio fingerprint?
They wouldn't.
But the point of fingerprinting is that practically no two "browsers" are the same:
[0] https://panopticlick.eff.org/
But the point of fingerprinting is that practically no two "browsers" are the same:
- browser software and exact version
- installed plugins
- size of browser window
- OS software and exact version (think of patches!)
- language
- time zone
- screen resolution
- ...
- (and all the stuff mentioned in the submitted article!)
[0] https://panopticlick.eff.org/
But is any of this stuff stable enough to ensure a fingerprint -> user correlation which doesn't break every time? It's not very much use if all it does is create a unique fingerprint for each refresh?
Yes; the things I've mentioned above don't change on page refresh.
If you'd find some things do change too often to be relied upon you could either take that into account, or simply don't use that specific fingerprinting technique.
If you'd find some things do change too often to be relied upon you could either take that into account, or simply don't use that specific fingerprinting technique.
That doesn't really answer the question, because most of the factors you listed should be irrelevant for _audio_ fingerprinting.
It does.
> They wouldn't.
> They wouldn't.
That's a pretty short answer, and it sounds wrong to me. Are you implying that browser version, OS type and version, and system architecture are all factors that matter for audio fingerprinting? If so, what would be the point of audio fingerprinting when you can just look at the user agent string?
Sorry, it seems I misunderstood your intention/question.
The `AudioContext` API exposes several details about the host which may depend on the hardware (sound card, sound chip), software stack (OS, on Linux e.g. PulseAudio vs. ALSA), sound driver and its versions, and connected periphery (speakers? headphones?).
Additionally, the audio API is used to generate a sound (which is muted before being played, but still generated before). Sound is hard, and so the browser vendors don't necessarily generate the "sound bits" themselves but ask the OS to so. Which might in fact ask its sound system to do so. Which might ask its sound driver...
Some of these properties are fairly common or likely to change often. But chances are that combined they give you more bits of information then say the simple user agent string (which is shared by thousands - if not more! - other browsers).
The `AudioContext` API exposes several details about the host which may depend on the hardware (sound card, sound chip), software stack (OS, on Linux e.g. PulseAudio vs. ALSA), sound driver and its versions, and connected periphery (speakers? headphones?).
Additionally, the audio API is used to generate a sound (which is muted before being played, but still generated before). Sound is hard, and so the browser vendors don't necessarily generate the "sound bits" themselves but ask the OS to so. Which might in fact ask its sound system to do so. Which might ask its sound driver...
Some of these properties are fairly common or likely to change often. But chances are that combined they give you more bits of information then say the simple user agent string (which is shared by thousands - if not more! - other browsers).
[deleted]
Will you post insight into the data you've collected? Obviously I don't care about IP addresses, etc, but it would be nice to know how many people have submitted data vs how many unique hashes have been collected for say the "Fingerprint using DynamicsCompressor", etc. I also haven't checked every page on the site, so the data might already be there (and I'm missing it)...
Yes, we'll definitely do an analysis on this and write it up.
If the sites can be detected, wouldn't it be possible to come up with a browser extension to at least let people know this is happening?
In your paper you say,
"When using the headless configuration, we are able to run up to 10 stateful browser instances on an Amazon EC2 “c4.2xlarge” virtual machine."
Also it seems like you ran the crawl only in the month of January this year, and crawled about 90 million pages. Were you able to do that on the single AWS instance, using Firefox via Selenium? What do you think the performance would have been just issuing raw requests?
Just interested because I'm currently building a crawler and am trying to decide if Selenium would be worth it performance wise.
"When using the headless configuration, we are able to run up to 10 stateful browser instances on an Amazon EC2 “c4.2xlarge” virtual machine."
Also it seems like you ran the crawl only in the month of January this year, and crawled about 90 million pages. Were you able to do that on the single AWS instance, using Firefox via Selenium? What do you think the performance would have been just issuing raw requests?
Just interested because I'm currently building a crawler and am trying to decide if Selenium would be worth it performance wise.
On iOS I use safari and disable access to location etc, also disable cookies, advertisementID, etc, etc. Then I feel quite save when using a VPN. Does that still hold?
Yes.
Changing common settings might in fact even make you stand out _more_.
Check the EFF's Panopticlick [0] to see how your specific configurations leaks identifying information.
[0] https://panopticlick.eff.org/
Changing common settings might in fact even make you stand out _more_.
Check the EFF's Panopticlick [0] to see how your specific configurations leaks identifying information.
[0] https://panopticlick.eff.org/
This week’s http://www.heise.de/artikel-archiv/ct/2016/11/144_kiosk states “Viele .. fingerprinting-verfarhen laufen auf Mobilgeräten ins Leere. … Zudem gibt es kein Mittel, mit dem man über gezielt gegen Fingerprinting über die Sensoreigenschaften vorgehen kan - weder unter iOS noch unter Android.” And then it concludes recommending Adblockers for Safari on iOS noting that it depends on the quality of the block-list. It also mentions that adblockers on iOS don’t work in Apps, other than in Android.
IOW most fingerprinting fail on mobile devices and that sensors, eg batteries, are one of the few remains for fingerprining on iOS. Do you disagree with Heise? Could you please substantiate your statements regarding iOS fingerprinting?
IOW most fingerprinting fail on mobile devices and that sensors, eg batteries, are one of the few remains for fingerprining on iOS. Do you disagree with Heise? Could you please substantiate your statements regarding iOS fingerprinting?
You're right that mobile devices are harder to fingerprint – too many people with the same screen size, operating system, browser version, timezone, and language/region settings.
However, mobile devices have a bunch of sensors, some of which can be accessed by JavaScript without permission, namely the ones you wouldn't expect to yield identifying information (e.g. accelerometer). The problem is that no two sensors are alike – they all introduce noise into the data which can be enough to fingerprint a device.
See here for a paper on the subject: https://crypto.stanford.edu/gyrophone/sensor_id.pdf
However, mobile devices have a bunch of sensors, some of which can be accessed by JavaScript without permission, namely the ones you wouldn't expect to yield identifying information (e.g. accelerometer). The problem is that no two sensors are alike – they all introduce noise into the data which can be enough to fingerprint a device.
See here for a paper on the subject: https://crypto.stanford.edu/gyrophone/sensor_id.pdf
nice Arvind!
This is much-needed research. Thank you for your work. Regarding the WebRTC tracking- would it be possible for WebRTC to work without exposing the local IP? I.e. is there any real reason that fingerprint needs to be there?
Other co-author here. Unfortunately there are good performance reasons for allowing WebRTC to access the local IP, see the lengthy discussion here: https://bugzilla.mozilla.org/show_bug.cgi?id=959893. One use case is allowing two peers behind the same NAT to communicate directly without leaving the local network.
The working group recommendation that we linked in the paper (https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handli...) addresses some of the concerns that arise from that (namely the concern that a user behind a VPN or proxy will have their real, public address exposed), but still recommends that a single private IP address be returned by default and without user permission.
However that's still quite identifying for some network configurations, e.g. a network which assigns non-RFC1918 IPs to users behind a NAT. Seems to me that putting access to the local IP address behind a permission would both remove the tracking risk and still allow the performance gains after the user grants permission.
The working group recommendation that we linked in the paper (https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handli...) addresses some of the concerns that arise from that (namely the concern that a user behind a VPN or proxy will have their real, public address exposed), but still recommends that a single private IP address be returned by default and without user permission.
However that's still quite identifying for some network configurations, e.g. a network which assigns non-RFC1918 IPs to users behind a NAT. Seems to me that putting access to the local IP address behind a permission would both remove the tracking risk and still allow the performance gains after the user grants permission.
Thanks for the response! If you're interested and it would be useful for your research, I have some really, really interesting privacy findings regarding Service Workers I'd be happy to share. I'm strongly in favor of an enhanced Open Web, but I'm not comfortable with the opaque nature in which tracking/privacy can be likewise enhanced with little user interaction or notification. Keep up the good work.
Feel free to email us at the addresses listed on the bottom of the linked site.
I am going to ask about a really basic question: what is fingerprinting?
I had to dig around, from the paper is sounds like a stateless form of tracking.
The audio example made sense:
1. the mic comes on, and it identifies a particular background noise.
2. I browse to another site, or a different page without a cookie.
3. The mic comes on again, matches the ambient noise and realizes I am the same person.
Is that what you mean? If this is the case, how can the "canvas fingerprinting" work since I had to browse to a new page and all the old pixels from the previous page are no longer there.
Anyway, if it is what I understand it to be, then it sounds very interesting. I bet some science fiction author wishes they had though to use it.
I had to dig around, from the paper is sounds like a stateless form of tracking.
The audio example made sense:
1. the mic comes on, and it identifies a particular background noise.
2. I browse to another site, or a different page without a cookie.
3. The mic comes on again, matches the ambient noise and realizes I am the same person.
Is that what you mean? If this is the case, how can the "canvas fingerprinting" work since I had to browse to a new page and all the old pixels from the previous page are no longer there.
Anyway, if it is what I understand it to be, then it sounds very interesting. I bet some science fiction author wishes they had though to use it.
I can see how you would be led to believe that interpretation. Looking at the "fingerprinting" webapp however, details that sound is NOT actually recorded-- only the uniqueness of your machine's audio processing stack. At least I hope that's the case. The idea of a microphone recording without permission upon visiting a website would cause quite a broo-ha-ha.
https://audiofingerprint.openwpm.com/
https://audiofingerprint.openwpm.com/
> "This page tests browser-fingerprinting using the AudioContext and Canvas API.
> Using the AudioContext API to fingerprint does not collect sound played or
> recorded by your machine - an AudioContext fingerprint is a property of your
> machine's audio stack itself. If you choose to see your fingerprint, we will
> collect the fingerprint along with a randomly assigned identifier, your IP
> Address, and your User-Agent and store it in a private database so that we can
> analyze the effectiveness of the technique. We will not release the raw data
> publicly. A cookie will be set in your browser to help in our analysis. We
> also test a form of fingerprinting using Flash if you have Flash enabled."Yes, no sound is recorded. Access to the user's mic isn't possible without a permission. If there are sections of the website or paper that seem to imply that, let me know and we'll clarify.
It seems strange that access to the audio stack isn't also behind the permission.
It does, and also as someone who has never heard of AudioContext before, I can't fathom why it would be necessary for a web application to generate an audio data stream that isn't output to speakers _AND_ _THEN_ analyze the result.
What is the typical use case for AudioContext?
The capabilities of AudioContext used in audio fingerprinting seem like they're beyond what is really necessary?
What is the typical use case for AudioContext?
The capabilities of AudioContext used in audio fingerprinting seem like they're beyond what is really necessary?
AudioContext is actually pretty cool. As far as I know, only Firefox supports it at the moment. But it allows you to work with audio streams in raw byteform, which means you can do advanced audio processing in client side javascript.
Presumably, an application would need to enumerate audio capabilities before even offering the option.
The front page [1] doesn't say either way, and I wondered the same thing when I read it. A few words or a link to an explanation would be helpful.
[1] https://webtransparency.cs.princeton.edu/webcensus/index.htm...
[1] https://webtransparency.cs.princeton.edu/webcensus/index.htm...
Thanks, I've added a clarification.
Wow, so are mic settings that different on different on, say, different iOS devices? If you and I have the same model iPhone with the same model iOS, is the audio stack that different?
Probably not - but basically, you add together your microphone stack with all the other data it can possibly find about your device, and that's your fingerprint.
Check out https://panopticlick.eff.org - this will attempt to fingerprint your browser and see if it's unique.
Check out https://panopticlick.eff.org - this will attempt to fingerprint your browser and see if it's unique.
If you'd like a lot more on this topic, check out https://33bits.org/sitemap/ and start clicking on the links.
I know iOS was just an example but just to clarify, the WebRTC spec isn't supported in-browser on iOS. To further clarify: it's not supported on iOS.
As a developer, you can take advantage of the spec only if you're building a native app. There's frameworks that you can use if you do. But within Safari or Chrome you have zero WebRTC support.
It's supported in modern versions of chrome on Android but won't be supported on iOS until apple does something about it.
As a developer, you can take advantage of the spec only if you're building a native app. There's frameworks that you can use if you do. But within Safari or Chrome you have zero WebRTC support.
It's supported in modern versions of chrome on Android but won't be supported on iOS until apple does something about it.
> But within Safari or Chrome you have zero WebRTC support.
Chrome is just a skin on Safari for iOS, because Apple doesn't allow third party browsers, right? I would think FF (or any other browser) wouldn't be able to on iOS either, given that constraint.
Chrome is just a skin on Safari for iOS, because Apple doesn't allow third party browsers, right? I would think FF (or any other browser) wouldn't be able to on iOS either, given that constraint.
> "how can the "canvas fingerprinting" work since I had to browse to a new page and all the old pixels from the previous page are no longer there"
The linked page answers this: "Differences in font rendering, smoothing, anti-aliasing, as well as other device features cause devices to draw the image differently."
Put differently, the function measureText(canvas full of text with various fonts and bizarre features with varying implementation) is a pretty good hashing function for a population of web users, because each of these web users have a pretty-unique [canvas rendering engine, underlying OS, installed fonts] combination.
Combine several of these techniques (webrtc, audio, list of plugins installed and their version, etc), and you go from a "pretty unique" to a "guaranteed unique" hash, which you can follow across the web.
The linked page answers this: "Differences in font rendering, smoothing, anti-aliasing, as well as other device features cause devices to draw the image differently."
Put differently, the function measureText(canvas full of text with various fonts and bizarre features with varying implementation) is a pretty good hashing function for a population of web users, because each of these web users have a pretty-unique [canvas rendering engine, underlying OS, installed fonts] combination.
Combine several of these techniques (webrtc, audio, list of plugins installed and their version, etc), and you go from a "pretty unique" to a "guaranteed unique" hash, which you can follow across the web.
Thanks for the explanation. I missed it because I never though these settings could be that unique.
Just imagine, if the audio stack exposes the volume level, that's roughly 7.5 bits of uniqueness to contribute to the 33 required to uniquely identity any person on Earth (not that you can expect it to be uniformly distributed, and thus fully usable).
that doesn't quite work since the volume level changes frequently.
Yes, it's a poor example in that respect. I meant it more as an explanation of how different attributes of a source all contribute a little but to providing a unique identifier, but you are correct that it's much less useful if the attribute is not static.
I'm going to answer the basic question: fingerprinting is about trying to identify your device as uniquely as possible using available APIs, in order to track you cross-site, without cookies.
To do that, you first try to identify API that have different results depending on the browser or the device, and then track their result. For example, the User agent have some identifying information. It's not unique for each person, but you can start having a bit of identifying information. Do that with multiple APIs (available fonts, installed plugins ...), and you start having enough identifying informations to uniquely identify some browsers, without having an actual ID provided by the browser.
To test your browser, you can visit https://panopticlick.eff.org/
To do that, you first try to identify API that have different results depending on the browser or the device, and then track their result. For example, the User agent have some identifying information. It's not unique for each person, but you can start having a bit of identifying information. Do that with multiple APIs (available fonts, installed plugins ...), and you start having enough identifying informations to uniquely identify some browsers, without having an actual ID provided by the browser.
To test your browser, you can visit https://panopticlick.eff.org/
I never understood panopticlick, even when I repeatedly visit it, it always tells me that
"Your browser fingerprint appears to be unique among the 135,054 tested so far."
Shouldn't it tell me that my browser is not unique during my 10th attempt considering it has recorded my previous attempts. This warning actually never changes, regardless of duration between consecutive attempts. That can only mean that the panopticlick is flawed or my browser signature is in constant flux (which would essentially make it useless from tracking perspective.)
"Your browser fingerprint appears to be unique among the 135,054 tested so far."
Shouldn't it tell me that my browser is not unique during my 10th attempt considering it has recorded my previous attempts. This warning actually never changes, regardless of duration between consecutive attempts. That can only mean that the panopticlick is flawed or my browser signature is in constant flux (which would essentially make it useless from tracking perspective.)
I thought the same thing, so I did a bit of digging.
Turns out they put a bunch of tracking cookies on your machine without asking you (it is mentioned in the about page though), which seem rather naughty for an organisation promoting online privacy.
When I removed all 4 of them, I get down to being "almost unique". I'm currently down to having the same fingerprint as 1 in 45132.3333333 browsers.
Turns out they put a bunch of tracking cookies on your machine without asking you (it is mentioned in the about page though), which seem rather naughty for an organisation promoting online privacy.
When I removed all 4 of them, I get down to being "almost unique". I'm currently down to having the same fingerprint as 1 in 45132.3333333 browsers.
This is confusing, my incorrect assumption was 1 out n browsers meant n = total numbers of browsers evaluated by panopticlick. Rather what they mean is 1 out of k, where k is determined by unique bits. There might be other factor such as entropy of each fingerprint.
Which API reveals my system fonts to a website?
Edit: The fingerprint test at https://panopticlick.eff.org/ shows my System Fonts
Edit: The fingerprint test at https://panopticlick.eff.org/ shows my System Fonts
I don't think you can enumerate them these days, but you can test for them by trying to use them in CSS (which font is used would affect the width of a span of text, use a wildly different fallback font and you can guess which is installed) or <canvas> (where you can inspect the actual pixels rendered).
Or use @font-face and detect calls to a remote URL — which happens when the named local font is missing:
@font-face {
font-family: "Roboto";
src: local("Roboto"), url("https://example.com/user-does-not-have-roboto") format("woff2");
}Flash provides an API for that.
Edit: Disable Flash or make it click-to-activate and https://panopticlick.eff.org/ shouldn't list your fonts anymore.
Edit: Disable Flash or make it click-to-activate and https://panopticlick.eff.org/ shouldn't list your fonts anymore.
You can't get installed fonts via javascript, but you can change the font of a known text and fingerprint the size to determine whether the font is installed or it defaulted to another font.
No. Microphone requires permission.
Your browser can leak a ton of information about your computer silently: window size, screen resolution, pixel density, time zone, language, installed fonts, installed plugins, operating system and version, browser version, plugins and versions, etc. There are good reasons for all of this data to be available to JavaScript for legitimate purposes. The AND of all of these datapoints, however, may be unique (or close), particularly if you have ever done something like install a novelty font. The EFF runs a website that fingerprints you and tells you how unique your fingerprint is:
[0] https://panopticlick.eff.org/tracker
Your browser can leak a ton of information about your computer silently: window size, screen resolution, pixel density, time zone, language, installed fonts, installed plugins, operating system and version, browser version, plugins and versions, etc. There are good reasons for all of this data to be available to JavaScript for legitimate purposes. The AND of all of these datapoints, however, may be unique (or close), particularly if you have ever done something like install a novelty font. The EFF runs a website that fingerprints you and tells you how unique your fingerprint is:
[0] https://panopticlick.eff.org/tracker
Canvas fingerprinting uses differences in rendering e.g. of fonts. Output a text, hash resulting pixel values. Depending on exact version of the font(s) installed, anti-aliasing settings, default font sizes, operating system... you get slightly different results. So you don't rely on information stored on the device, but on repeatable behavior that differs between devices.
I thought that was "Canvas-Font Fingerprinting"
But now I see that is just seeing which fonts are available.
Thanks for the explanation. Its just hard to believe devices are so different. I would think most versions of iOS would have roughly the same set of fonts etc.
But now I see that is just seeing which fonts are available.
Thanks for the explanation. Its just hard to believe devices are so different. I would think most versions of iOS would have roughly the same set of fonts etc.
Canvas fingerprinting by itself won't uniquely identify users. But the idea is that you can combine various different techniques, each one giving you more bits of uniqueness, until you have enough to do so. For example, say that canvas fingerprinting gives you one of 100 possibilities, and you combine it with other techniques that give you one of 10,000 possibilities, then combined (assuming they're not correlated) you get it to a million, letting you uniquely identify people with decent reliability from a decently large visitor pool.
What are some unexpected things that would differ between two iPhones of the same model running the same versions of the software stack?
Good question. I'm not particularly informed on this stuff, so take this with a grain of salt, but my understanding is that mobile devices in general and iPhones in particular are much harder to fingerprint reliably. Things like time zone, clock skew, and ping times might help differentiate users, but you probably can't get it down to a single person. I imagine there's still a use for fingerprinting which helps you differentiate groups of users even if you can't narrow it down to just one.
Actually, checking if a font is available does not require canvas (you can simply inject a piece of text into the page with a specific font stack set and check its width). Rather, what canvas is used for is to obtain the sub-pixel anti-aliasing of a given piece of text, which is different between browsers and OS even when the same font is present.
I would assume that iOS devices are quite hard to tell apart using most of these techniques, yes. But I also wouldn't be too surprised if there were something that works for them, some kind of cookie that isn't cleared by default or ...
Yup HSTS supercookies or some kinds of network fingerprinting will work to distinguish between two otherwise identical iOS devices.
what is fingerprinting?
I don't know the research definition, but fingerprinting is a technique to uniquely track a user across multiple sites without a tracking beacon.
The most basic form of fingerprinting is to use the browser-supplied headers (user agent, version, OS). Canvas fingerprinting works because identical browser versions across different machines may render slightly different, but consistent. IIUC, canvas fingerprinting doesn't rely on any pixels shown to the user or anything unique to the site, but if the same canvas is rendered exactly the same on two different sites, that's another indication that both visits were from the same user.
I don't think the AudioContext fingerprinting uses the actual microphone: it uses the browser's (and possibly OS's) audio engine to generate an audio stream, then fingerprints the resulting data stream.
I don't know the research definition, but fingerprinting is a technique to uniquely track a user across multiple sites without a tracking beacon.
The most basic form of fingerprinting is to use the browser-supplied headers (user agent, version, OS). Canvas fingerprinting works because identical browser versions across different machines may render slightly different, but consistent. IIUC, canvas fingerprinting doesn't rely on any pixels shown to the user or anything unique to the site, but if the same canvas is rendered exactly the same on two different sites, that's another indication that both visits were from the same user.
I don't think the AudioContext fingerprinting uses the actual microphone: it uses the browser's (and possibly OS's) audio engine to generate an audio stream, then fingerprints the resulting data stream.
As soon as I saw these APIs being added I immediately dropped into about:config and disabled them. How the hell do these people think this is a good idea to do without asking any permissions?
Put these in your user prefs.js file on Firefox:
user_pref("dom.battery.enabled", false);
user_pref("device.sensors.enabled", false);
user_pref("dom.vibrator.enabled", false);
user_pref("dom.enable_performance", false);
user_pref("dom.network.enabled", false);
user_pref("toolkit.metrics.ping.enabled", false);
user_pref("dom.gamepad.enabled", false);
Here's my full firefox config currently:
https://up1.ca/#nUSA1WtY13ECfmYC5c825w
Privacy on the web keeps getting harder and harder. Of course this should only be used in conjunction with maxed out ad blockers, anti-anti-adblockers, privacy badger and disconnect.
We need browsers to start asking permission. When you install an app on Android or iOS it says "here's what it's going to use, do you want this?". The mere presence of the popup would annoy people and prevent them from using these APIs.
Put these in your user prefs.js file on Firefox:
user_pref("dom.battery.enabled", false);
user_pref("device.sensors.enabled", false);
user_pref("dom.vibrator.enabled", false);
user_pref("dom.enable_performance", false);
user_pref("dom.network.enabled", false);
user_pref("toolkit.metrics.ping.enabled", false);
user_pref("dom.gamepad.enabled", false);
Here's my full firefox config currently:
https://up1.ca/#nUSA1WtY13ECfmYC5c825w
Privacy on the web keeps getting harder and harder. Of course this should only be used in conjunction with maxed out ad blockers, anti-anti-adblockers, privacy badger and disconnect.
We need browsers to start asking permission. When you install an app on Android or iOS it says "here's what it's going to use, do you want this?". The mere presence of the popup would annoy people and prevent them from using these APIs.
Thank you, user, for making your fingerprint hash more unique by disabling certain default features, given your user-agent string, thus opting into cat-facts.
Disabling them probably makes you significantly more unique than those that don't just because the vast majority of people never will disable them.
Of course, now a site could potentially fingerprint you by the set of APIs you have disabled!
fyi, related: Firefox addon "Privacy Settings" :
https://addons.mozilla.org/en-US/firefox/addon/privacy-setti...
It's great that mozilla decided to remove about:permissions. I do enjoy the fact that I now have to visit every website whose permissions I want to change instead of managing all permissions from a single location.
Google has a vested interest in information leakage. I have a suspicion that the Chromium project expresses a strategic desire to shape the direction of browser development away from stopping those leaks. The idea of signing into the browser with an identity is a core feature and in Google's branded version, Chrome, the big idea is that the user is signed into Google's services.
Google only pitches the idea of multiple identities in the context of sharing devices among several people: https://support.google.com/chrome/answer/2364824?hl=en and even then doesn't do much to surface the idea. https://www.google.com/search?hl=en&as_q=multiple+identities...
Google only pitches the idea of multiple identities in the context of sharing devices among several people: https://support.google.com/chrome/answer/2364824?hl=en and even then doesn't do much to surface the idea. https://www.google.com/search?hl=en&as_q=multiple+identities...
This is why Firefox is gaining momentum; they seem to be the only browser interested in user privacy. Users are definitely interested.
Indeed. i even use FF despite its terrible terrible "pinch to zoom" functionality - which works perfectly in other browsers (Safari, Chromium, Chrome).
Zooming is such a basic thing... i don't understand why they implement it in such a crappy way. Certainly doesn't attract users.
Zooming is such a basic thing... i don't understand why they implement it in such a crappy way. Certainly doesn't attract users.
Can you elaborate what's so bad about Firefox's pinch to zoom?
Take a look at this movement: https://up1.ca/#q07x8mFjrGtXR6ju1r3EQw
In Safari, this is what it does: https://up1.ca/#Lu0r_cI_v0vXvzpa9nUmEg So in Safari it lets me zoom all the way in and/or out with 1 smooth movement.
This is what the same movement does in Firefox: https://up1.ca/#SEKWNOm1BSQnkntxj_v53w In Firefox, if i want to zoom all the way in, i have to pinch in like 10 times (very annoying) and then to zoom out pinch out another 10 times...
In Safari, this is what it does: https://up1.ca/#Lu0r_cI_v0vXvzpa9nUmEg So in Safari it lets me zoom all the way in and/or out with 1 smooth movement.
This is what the same movement does in Firefox: https://up1.ca/#SEKWNOm1BSQnkntxj_v53w In Firefox, if i want to zoom all the way in, i have to pinch in like 10 times (very annoying) and then to zoom out pinch out another 10 times...
Google is already really good at tracking people, why would it introduce vectors that would help other vendors catch up? You would have to demonstrate that Google itself was using these vectors for tracking.
What Google vends isn't browsers. It vends advertising.
It's competitors for data? To see how is Microsoft's "sign in to the web" is playing one might be tempted to Bing with IE, but statistically the odds favor another browser and another search service combination.
It's competitors for data? To see how is Microsoft's "sign in to the web" is playing one might be tempted to Bing with IE, but statistically the odds favor another browser and another search service combination.
This is the kind of nonconsensual sureptitious user tracking that the EU privacy directive 2002/58/EC concerns itself with, not those redundant, stupid cookie consent overlays.
And there's already been an opinion to extend 2002/58/EC to fingerprinting[0]
[0]: http://ec.europa.eu/justice/data-protection/article-29/docum...
[0]: http://ec.europa.eu/justice/data-protection/article-29/docum...
If you consent to the way things have always been, do nothing!
So a regular site using, say, mixpanel doesn't need to show a warning?
If the cookies are purely technical (say, login cookies), no.
If the cookies are used for tracking, like Google Analytics, then yes, it needs to ask the user for consent.
And that’s not a warning, but actual "yes/no", and in the no case, it may not set a tracking cookie, or have set a tracking cookie already.
Most sites (except for a few dozen German and Dutch ones) just redirect you somewhere else, though, if you refuse to be tracked.
If the cookies are used for tracking, like Google Analytics, then yes, it needs to ask the user for consent.
And that’s not a warning, but actual "yes/no", and in the no case, it may not set a tracking cookie, or have set a tracking cookie already.
Most sites (except for a few dozen German and Dutch ones) just redirect you somewhere else, though, if you refuse to be tracked.
Something that is best left to the browser to handle... by allowing the user to enable/disable 3rd party cookies. Which we already have. But no, the EU has stupid notifications on basically every single website as a result since everyone uses third party analytics. Why? If you want your analytics to be believed by anyone who wants to advertise with you, invest in you, partner with you, or buy you, they'd damn well better be third party analytics.
The EU Commission and the regulatory agencies actually agree with you. The stupidity is 100% with the web devs and customers.
What do you mean with "The stupidity is 100% with the web devs and customers"?
The law requires user consent, in form of a click on a banner or scrolling the page, before setting any cookie.
The law requires user consent, in form of a click on a banner or scrolling the page, before setting any cookie.
Which law? The 2002/58/EC doesn't.
Not that one.
http://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:320...
Complete law: http://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX...
Paragraph 66 talks about cookies.
A later exception was made by the EU for session cookies.
Guidelines for webmasters:
http://ec.europa.eu/ipg/basics/legal/cookies/index_en.htm#se...
It has a sample banner which is similar to those which most users display.
Spanish official directives (with further protection because of a local law called LSSI): https://www.agpd.es/portalwebAGPD/canaldocumentacion/publica..., page 17. Also comes with a sample banner
Did you really think that everyone else was wrong or didn't read the law and is programming these banners as some sort of fad?
http://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:320...
Complete law: http://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX...
Paragraph 66 talks about cookies.
A later exception was made by the EU for session cookies.
Guidelines for webmasters:
http://ec.europa.eu/ipg/basics/legal/cookies/index_en.htm#se...
It has a sample banner which is similar to those which most users display.
Spanish official directives (with further protection because of a local law called LSSI): https://www.agpd.es/portalwebAGPD/canaldocumentacion/publica..., page 17. Also comes with a sample banner
Did you really think that everyone else was wrong or didn't read the law and is programming these banners as some sort of fad?
That's true. The implementation differs on the country, for example in the UK it is enough to just show the annoying banner. Here in Spain you cannot set any tracking cookie (i.e. Analytics) without explicit consent. Of course, governmental websites totally break this law: http://cfenollosa.com/blog/the-ignorant-eu-cookie-law.html
However, OP is right, governments spy on our webcams and analyze our traffic, and that's ok, but we need a stupid banner that overrides browser preferences to avoid all but session cookies. Duh.
However, OP is right, governments spy on our webcams and analyze our traffic, and that's ok, but we need a stupid banner that overrides browser preferences to avoid all but session cookies. Duh.
Yeah that's how I understood it. Sounds like the op who said EU directive isn't interested in regular use is wrong.
No, from my understanding cookies are allowed by default only if they are essential to the function of the site. If you only use the cookie to handle logins and sessions then you don't need the warning. I you use the cookie for tracking or analytics then you need the warning.
Note that you can use your webserver logs for analytics and that doesn't require the cookie banner.
Note that you can use your webserver logs for analytics and that doesn't require the cookie banner.
> Note that you can use your webserver logs for analytics and that doesn't require the cookie banner
In the EU, tracking user IPs actually requires consent. Even logging them does.
In the EU, tracking user IPs actually requires consent. Even logging them does.
If you can set cookies, the user has already expressed their consent by enabling the cookies in the browser. As long as cookies' existence is common knowledge (it is by now), there is no need to duplicate browser UI within every website.
This is the official stance of the ICO[1], the UK national authority: there was a need to educate users what cookies were when the directive was passed. No such need exists now. ICO itself briefly used consent overlays, but does not anymore (EDIT: Aaaaand they've apparently use them again; I'll try to find the policy release where they say this is not necessary.). Cookies not used for tracking of persons never needed any consent, as they have no privacy implications.
People who make their living creating cargo-cult UI designs, have predictably added cargo-cult law-compliance to their toolset. It is beyond stupid.
[1] https://ico.org.uk/
This is the official stance of the ICO[1], the UK national authority: there was a need to educate users what cookies were when the directive was passed. No such need exists now. ICO itself briefly used consent overlays, but does not anymore (EDIT: Aaaaand they've apparently use them again; I'll try to find the policy release where they say this is not necessary.). Cookies not used for tracking of persons never needed any consent, as they have no privacy implications.
People who make their living creating cargo-cult UI designs, have predictably added cargo-cult law-compliance to their toolset. It is beyond stupid.
[1] https://ico.org.uk/
> If you can set cookies, the user has already expressed their consent by enabling the cookies in the browser. As long as cookies' existence is common knowledge (it is by now), there is no need to duplicate browser UI within every website.
Wrong. If I disable cookies in my browser, I can't log in to websites anymore, so they need to be allowed. A whitelist would be very inconvenient. On top of that, it's not explicit allowance, it'd be implicit (i.e. opt-out instead of opt-in).
I don't know if British legislation is different, but this is illegal at least in the Netherlands.
Wrong. If I disable cookies in my browser, I can't log in to websites anymore, so they need to be allowed. A whitelist would be very inconvenient. On top of that, it's not explicit allowance, it'd be implicit (i.e. opt-out instead of opt-in).
I don't know if British legislation is different, but this is illegal at least in the Netherlands.
You can enable session cookies only, even in the current UIs. Ditto for third-party cookies. Duplicating UI in a website is a solution looking for a problem. The web devs can nag the 0.01% who don't have cookies enabled, and leave the 99.99% who have them enabled alone.
It has never been enforced that way to my knowledge, anywhere in the EU. Which law or court decision says that it is actually illegal?
It has never been enforced that way to my knowledge, anywhere in the EU. Which law or court decision says that it is actually illegal?
> session cookies
How does my browser know that one PHPSESSID is used for tracking, and another is a session? You probably mean until I close the browser, which would be never -- at least, I would never want to, but I do every few months for browser updates. (My laptop always goes in suspend/sleep mode.)
> Ditto for third-party cookies
I don't know what third-party cookies are anyway, and I bet my peers could not give me an accurate description either. We're all in the software business, be it game development or general software development or something.
Two gave a rough description but couldn't answer a question about whether embedded Like buttons would work if the user is logged into Facebook. Another just said "I don't know".
I'm not sure "the public is informed about all their options by now". The ones who really care generally use uBlock, ABP, Self-Destructing Cookies, Ghostery, etc., the rest just click "ok" because the sites do not inform them about these aforementioned possibilities: that wouldn't be in their interest.
> Duplicating UI in a website is a solution looking for a problem
Oh I agree it's an issue, I hate this cookie wall as much as anyone. I would love for there to be no need to ever see this wall.
> It has never been enforced that way to my knowledge, anywhere in the EU. Which law or court decision says that it is actually illegal?
I am not sure fines have been dealt, but the Dutch ACM ("authority for consumer and markets", literally translated) did give out warnings to non-compliant sites and they subsequently places cookie walls.
The law simply says no such cookies may be placed, it doesn't say "for a few months while users are unaware, and after that, oh well, have some fun picking your own privacy laws as you wish."
And yes, I know functional cookies and simple tracking is allowed if you don't invade a person's privacy. This means practically every major website knowingly tries to invade your privacy, because they have these walls in place. What do people say? "Fucking government does not understand the internet, look at all these walls." What should we be saying? "Wait why are they trying to create detailed profiles of me in the first place?"
How does my browser know that one PHPSESSID is used for tracking, and another is a session? You probably mean until I close the browser, which would be never -- at least, I would never want to, but I do every few months for browser updates. (My laptop always goes in suspend/sleep mode.)
> Ditto for third-party cookies
I don't know what third-party cookies are anyway, and I bet my peers could not give me an accurate description either. We're all in the software business, be it game development or general software development or something.
Two gave a rough description but couldn't answer a question about whether embedded Like buttons would work if the user is logged into Facebook. Another just said "I don't know".
I'm not sure "the public is informed about all their options by now". The ones who really care generally use uBlock, ABP, Self-Destructing Cookies, Ghostery, etc., the rest just click "ok" because the sites do not inform them about these aforementioned possibilities: that wouldn't be in their interest.
> Duplicating UI in a website is a solution looking for a problem
Oh I agree it's an issue, I hate this cookie wall as much as anyone. I would love for there to be no need to ever see this wall.
> It has never been enforced that way to my knowledge, anywhere in the EU. Which law or court decision says that it is actually illegal?
I am not sure fines have been dealt, but the Dutch ACM ("authority for consumer and markets", literally translated) did give out warnings to non-compliant sites and they subsequently places cookie walls.
The law simply says no such cookies may be placed, it doesn't say "for a few months while users are unaware, and after that, oh well, have some fun picking your own privacy laws as you wish."
And yes, I know functional cookies and simple tracking is allowed if you don't invade a person's privacy. This means practically every major website knowingly tries to invade your privacy, because they have these walls in place. What do people say? "Fucking government does not understand the internet, look at all these walls." What should we be saying? "Wait why are they trying to create detailed profiles of me in the first place?"
Although the emphasis on the actual abuse of newly-introduced APIs is much needed, it is probably important to note that they are not uniquely suited for fingerprinting, and that the existence of these properties is not necessarily a product of the ignorance of browser developers or standards bodies. For most part, these design decisions were made simply because the underlying features were badly needed to provide an attractive development platform - and introducing them did not make the existing browser fingerprinting potential substantially worse.
Conversely, going after that small set of APIs and ripping them out or slapping permission prompts in front of them is unlikely to meaningfully improve your privacy when visiting adversarial websites.
Few years back, we put together a less publicized paper that explored the fingerprintable "attack surface" of modern browsers:
https://www.chromium.org/Home/chromium-security/client-ident...
Overall, the picture is incredibly nuanced, and purely technical solutions to fingerprinting probably require breaking quite a few core properties of the web.
Conversely, going after that small set of APIs and ripping them out or slapping permission prompts in front of them is unlikely to meaningfully improve your privacy when visiting adversarial websites.
Few years back, we put together a less publicized paper that explored the fingerprintable "attack surface" of modern browsers:
https://www.chromium.org/Home/chromium-security/client-ident...
Overall, the picture is incredibly nuanced, and purely technical solutions to fingerprinting probably require breaking quite a few core properties of the web.
So... what we need is a browser, which says it supports these things but blocks or provides false data on request and looks as ordinary as possible for "regular" browser fingerprinting.
Is anyone aware of the existence of one?
Is anyone aware of the existence of one?
The problem here is Canvas fingerprinting - that's what I found the most surprising and interesting.
How do you prevent that, apart from working on 'fixing' browsers to create pixel-perfect renders across different browsers/platforms/configurations. Would that even be possible?
Edit:
> Tor Browser notifies the user for canvas read attempts and provides the option to return blank image data to prevent fingerprinting.
Huh. I guess that's one attempt, but being able to read pixel data out of a canvas is completely reasonable.
How do you prevent that, apart from working on 'fixing' browsers to create pixel-perfect renders across different browsers/platforms/configurations. Would that even be possible?
Edit:
> Tor Browser notifies the user for canvas read attempts and provides the option to return blank image data to prevent fingerprinting.
Huh. I guess that's one attempt, but being able to read pixel data out of a canvas is completely reasonable.
> […] but being able to read pixel data out of a canvas is completely reasonable.
Not for every website. Most websites don't need canvas at all. One option would be to ask users to activate canvas support for a website that does need it, so users can judge for themselves if the request is legitimate. This is how the geo-location API works after all.
I am not convinced that this will work very well though.
Not for every website. Most websites don't need canvas at all. One option would be to ask users to activate canvas support for a website that does need it, so users can judge for themselves if the request is legitimate. This is how the geo-location API works after all.
I am not convinced that this will work very well though.
Seems like just another vector to fingerprint that browser by :)
It is! But a disabled setting has a much lower entropy in terms of identifying bits than the hash generated with an active canvas.
It seems possible to add heuristics like 'the canvas element has requested more than X fonts within about Y seconds' and then treat that as a tracking script and do something like prompt the user, or return the default font from then on.
Disable canvas rendering from 3rd part domains?
Prompt to enable canvas support for each domain?
> apart from working on 'fixing' browsers to create pixel-
> perfect renders
Or use a pure software rendering implementation so it's always the same across platforms.
If the "fingerprint" really is a checksum/crypto hash, an ever so slight random element in rendering output could help. Of course, together with other techniques, it might just identify your somewhat obfuscating browser.
I think Tor Browser tries to do this for some types of fingerprinting.
The Tor Browser folks have done some excellent work to reduce the fingerprintability of the browser. See "Specific Fingerprinting Defenses in the Tor Browser" here: https://www.torproject.org/projects/torbrowser/design/#finge....
For Firefox and Chrome there are canvas fingerprint blockers [1] and [2]. These are heuristic based, so you'll likely see a bit of false positives. uBlock Origin includes an option to prevent the leakage of local IP addresses [3].
[1] https://addons.mozilla.org/en-US/firefox/addon/canvasblocker...
[2]https://chrome.google.com/webstore/detail/canvasfingerprintb...
[3]https://github.com/gorhill/uBlock/wiki/Prevent-WebRTC-from-l...
For Firefox and Chrome there are canvas fingerprint blockers [1] and [2]. These are heuristic based, so you'll likely see a bit of false positives. uBlock Origin includes an option to prevent the leakage of local IP addresses [3].
[1] https://addons.mozilla.org/en-US/firefox/addon/canvasblocker...
[2]https://chrome.google.com/webstore/detail/canvasfingerprintb...
[3]https://github.com/gorhill/uBlock/wiki/Prevent-WebRTC-from-l...
The Tor Browser does not send misinformation; it just blocks. A solution would probably be a browser where every version, on every platform reports the exact same things, always the same way.
> The Tor Browser does not send misinformation; it just blocks.
No, it doesn't. TB sends all kinds of misinformation, from the user agent string (always reports itself as being its base version of Firefox running on 32-bit Windows 7) to rounding javascript timing functions to reduce the precision.
> A solution would probably be a browser where every version, on every platform reports the exact same things, always the same way.
That's exactly what Tor Browser does.
No, it doesn't. TB sends all kinds of misinformation, from the user agent string (always reports itself as being its base version of Firefox running on 32-bit Windows 7) to rounding javascript timing functions to reduce the precision.
> A solution would probably be a browser where every version, on every platform reports the exact same things, always the same way.
That's exactly what Tor Browser does.
The last time I tried it this wasn't always the case; however, my information could easily be outdated, and in that case, I'm sorry.
Or a browser which randomly permutes canvas values.
That's not true, Tor Browser does sometimes lie, see what englehardt linked.
The things you block and don't block could also be used to help form a fingerprint.
I wish there was a Tor Browser without Tor but just things like fingerprinting fixes.
Colour me unsurprised. Disappointed though.
I'm glad I disabled WebRTC when I first discovered it could be used to expose local IP on a VPN.
These "extension" technologies should all be optional plugins. Preferably install on demand, but a simple, obvious way to disable would be acceptable. (ie more obvious than about:config)
Not a great deal can be done about font metrics other than my belief that websites shouldn't be able to ferret around my fonts to see what I have. Not like it's a critical need for any site.
I'm glad I disabled WebRTC when I first discovered it could be used to expose local IP on a VPN.
These "extension" technologies should all be optional plugins. Preferably install on demand, but a simple, obvious way to disable would be acceptable. (ie more obvious than about:config)
Not a great deal can be done about font metrics other than my belief that websites shouldn't be able to ferret around my fonts to see what I have. Not like it's a critical need for any site.
What would anyone do with your internal network IP?
Having these features as optional plugins means they are basically impossible to count on having in the basic web platform, meaning you're going to fight a losing battle to gain adoption for any applications that need them.
And the open web platform is the only platform right now that is enabling developers to create cross-platform applications outside of the restrictions of walled-garden app stores.
Having these features as optional plugins means they are basically impossible to count on having in the basic web platform, meaning you're going to fight a losing battle to gain adoption for any applications that need them.
And the open web platform is the only platform right now that is enabling developers to create cross-platform applications outside of the restrictions of walled-garden app stores.
Not just internal network IP, but also public IP. There were quite a few test sites popped up when the issue came to light.
> Having these features as optional plugins means they are basically impossible to count on having
Funny. Didn't seem to prevent flash, acrobat or others becoming extensively adopted. If I want browser video chat I can install WebRTC etc.
If the cost of having that universal platform is compromising everyone's privacy, on any site that wants to check, it's not a fair or acceptable trade.
Seems to me we have this ass backwards.
> Having these features as optional plugins means they are basically impossible to count on having
Funny. Didn't seem to prevent flash, acrobat or others becoming extensively adopted. If I want browser video chat I can install WebRTC etc.
If the cost of having that universal platform is compromising everyone's privacy, on any site that wants to check, it's not a fair or acceptable trade.
Seems to me we have this ass backwards.
You know every site you ever go to sees your public IP, right?
Seems to me you're just being paranoid.
Seems to me you're just being paranoid.
Not when connected to a VPN, they should see the vpn public IP. The issue was that WebRTC enabled snooping on ISP-provided IP whilst on a VPN.
See https://github.com/diafygi/webrtc-ips or https://www.purevpn.com/blog/disable-webrtc-in-chrome-and-fi...
See https://github.com/diafygi/webrtc-ips or https://www.purevpn.com/blog/disable-webrtc-in-chrome-and-fi...
With your internal IP I can guess the brand of your router, determine if you are a home user or on a corp network, guess how many other machines might be on your network.
I can also assume that your router lives at .1 or .254 or similar, and use your browser to pivot and brute force the password while you browse cat pictures.
I can also assume that your router lives at .1 or .254 or similar, and use your browser to pivot and brute force the password while you browse cat pictures.
If your VPN is configured correctly, your IP will not be exposed.
Not all of my devices make it possible to disable WebRTC, which makes defense in depth a necessity. Can you provide pointers to more information?
I don't experience webrtc leaks with Openvpn and this config: http://pastebin.com/raw/hiH1TZtS (I use IVPN, their client prevents webrtc leaks on windows by default, but had to manually configure openvpn on linux).
Of course, I keep webrtc disabled in Firefox anyway except when i need it, defense in depth like you said.
Of course, I keep webrtc disabled in Firefox anyway except when i need it, defense in depth like you said.
Neat, thanks.
> These "extension" technologies should all be optional plugins.
But then still whether you installed an extension would contribute a bit of information to your fingerprint.
But then still whether you installed an extension would contribute a bit of information to your fingerprint.
True enough, though I suspect not installed would be the majority case. I guess it should ask like browsers ask before location check.
NoScript is an all-or-nothing approach. Are there any JS-blockers that allow API-level blocks?
If you use Firefox or Iceweasel, you can disable most of those apis in about:config or user.js. For example, media.peerconnection.enabled = false, to disable WebRTC. dom.battery.enabled = false for battery, etc.
Yeah, but one may want to enable those on per-site basis. So you get both the fancy stuff (with a sites you trust) and no tracking material for the rest.
This would make absolute sense. Certain requests (like location) already trigger popups that ask you for permission. If it turns out other APIs can be equally revealing as far as privacy goes, it would make sense to present the same popup.
I mean, using a web app for the first time would be no different then installing a mobile app - I wouldn't be surprised if I had to give it a few permissions.
I mean, using a web app for the first time would be no different then installing a mobile app - I wouldn't be surprised if I had to give it a few permissions.
I was thinking the same thing. We need a permission system for websites. Preferably useable on a per-domain basis so I can disable those APIs on adnetworks' domains.
The (currently embryonic) Permissions API [1] looks like it's aimed at precisely this use case.
[1] https://developer.mozilla.org/en-US/docs/Web/API/Permissions...
[1] https://developer.mozilla.org/en-US/docs/Web/API/Permissions...
Thats what made Opera up to 12.xx great. “Edit site preferences…” menu let you tweak EVERY SINGLE option per domain.
If you disable a unique combination of APIs that combination becomes your fingerprint.
True, but the number of APIs is relatively small while having them enabled can allow for a much richer set of values, far more useful for fingerprinting.
Not if a large number of people all disable the same APIs
By disabling specific APIs, you would make your browser even more identifiable.
It would only work if many users have disabled exactly the same APIs as you and all other non-disabled APIs don't provide any information useful for fingerprinting.
It would only work if many users have disabled exactly the same APIs as you and all other non-disabled APIs don't provide any information useful for fingerprinting.
So, disable the same APIs as the TOR browser does.
Just like disabling is is identifying. It's less about identity and more about control.
If I could just feed it random data instead of fully disabling, that would also be fine.
If I could just feed it random data instead of fully disabling, that would also be fine.
It's kind of surprising that there isn't an extension to provide this functionality (at least in desktop browsers). All you'd have to do is monkey patch the methods that get called and throw up a confirm("are you sure you want to allow [X]")
Well, I just created a small POC:
http://plnkr.co/edit/hKvPpEZQGCSkCNKly5Z3?p=preview
It would need to remember your choice so you don't get prompted everytime, but that's a small/easy change to make.
http://plnkr.co/edit/hKvPpEZQGCSkCNKly5Z3?p=preview
It would need to remember your choice so you don't get prompted everytime, but that's a small/easy change to make.
I don't know of any. I would think it would be fairly easy to create a userscript or extension to stub built-in APIs (maybe using something like testdouble.js or sinon.js to override the default global objects that you are trying to "disable"). I'm not sure what issues you'd run into on various pages if you did that though (so it'd probably need a lot of iteration- and fixing bug reports).
It might be a fun project to start though. I've been really enjoying testdouble's API (and have started using that for my unit tests).
It might be a fun project to start though. I've been really enjoying testdouble's API (and have started using that for my unit tests).
All of this makes me wonder how some of these interfaces should be more closely guarded by the user agent.
Perhaps instead of a site probing for capabilities, they should instead publish a list of what the site/page can leverage and what it absolutely needs to work. Maybe meta tags in the head or something like the robots.txt. Browsers can then pull the list and present it to the end user for white-listing.
You could have a series of tags similar to noscript to decorate broken portions of sites if you wanted to advertise missing features to users and, based on what features they chose to enable/disable for the site, the browser would selectively render them.
Perhaps instead of a site probing for capabilities, they should instead publish a list of what the site/page can leverage and what it absolutely needs to work. Maybe meta tags in the head or something like the robots.txt. Browsers can then pull the list and present it to the end user for white-listing.
You could have a series of tags similar to noscript to decorate broken portions of sites if you wanted to advertise missing features to users and, based on what features they chose to enable/disable for the site, the browser would selectively render them.
Users don't want to do this though.
I mean, how many people are dealing with the hassle of noscript? That's probably most of the users that are going to do anything other than tell the browser to stop asking questions.
I mean, how many people are dealing with the hassle of noscript? That's probably most of the users that are going to do anything other than tell the browser to stop asking questions.
Users are familiar with managing permissions, they do it all of the time. Users have to manage location services and the camera in browser. iOS and Android also prompt for access to resources.
Why is it unrealistic to expect the same for other interfaces like audio, video, WebRTC, and other potentially exploitable functionality?
Why is it unrealistic to expect the same for other interfaces like audio, video, WebRTC, and other potentially exploitable functionality?
Most permission management most users do is click the "accept" button when installing an app without reading anything on the list. I don't see how that helps.
I'm not arguing against enabling users to manage the permissions.
I'm arguing it won't help a huge number of users because they will default to granting them.
I'm arguing it won't help a huge number of users because they will default to granting them.
So given this information, how can we poison the results that the trackers get?
There have been a couple plugins which try to address this question: Chameleon (https://github.com/ghostwords/chameleon), which is still in early stages, and FireGloves (https://fingerprint.pet-portal.eu/?menu=6), which was built by a research group (not sure it's still supported).
Also a great paper on this topic: http://research.microsoft.com/pubs/209989/tr1.pdf
Also a great paper on this topic: http://research.microsoft.com/pubs/209989/tr1.pdf
Just altering your own browser's fingerprint for each domain won't poison their data (it just makes you anonymous to them). Any data is good data as far as these trackers are concerned. You can devalue their data by collectively sending the same fingerprints, but there is no way to actively poison their databases.
You would need a way to change your fingerprint on every page load I guess?
Some methods of fingerprinting are probably used to distinct between real users and bots. Bots can use patched headless browsers that are masquaraded as desktop browsers (for example as latest Firefox or Chrome running on Windows). Subtle differences in font rendering or missing audio support can be useful to detect underlying libraries and platform. Hashing is used to hide exact matching algorithm from scammers.
There is a lot of people trying to earn on clicking ads with bots.
Edit: and by the way disabling JS is an effective method against most of the fingerprinting techniques.
There is a lot of people trying to earn on clicking ads with bots.
Edit: and by the way disabling JS is an effective method against most of the fingerprinting techniques.
As someone who has written code to detect bots, exactly this. We don't care about fingerprinting the user, we care about fingerprinting to verify the user agent you claim to be.
What annoys me the most is how many useless cycles these trackers use to track me.
WebRTC guys get around this by stating fingerprinting is game over, so don't even bother. They ignore that they are going against the explicitly defined networking (proxy) settings. Browsers are complicit in this. If the application asks "should I use a proxy", then ignores it, silently, wherever it wants, that's deceptive and broken.
There's still zero (0) use cases to have WebRTC data channels enabled in the background with no indicator.
If all these APIs are added, the web will turn into a bigger mess than it is. They can't prompt for permissions too much. So they'll skip that, like WebRTC does.
There's still zero (0) use cases to have WebRTC data channels enabled in the background with no indicator.
If all these APIs are added, the web will turn into a bigger mess than it is. They can't prompt for permissions too much. So they'll skip that, like WebRTC does.
Seems like browsers should ask the user's permission to use these html5 features. Then whitelist. For example, a site that does nothing with audio should be denied access to the audio stack.
[deleted]
I think it's time for HTML--, which would contain no active content at all and simply be a reflowable document display format.
There is an acceptable tradeoff between pseudo anonymous access through browsers vs non-anonymous access through native apps.
To interpret this research as reason for crippling web or browsers would be a giant mistake. Crippling browsers will only work against users, who will be then forced into installing apps by companies.
Two popular shopping companies in India exactly did this, they completely abandoned their websites and went native app only. This combined with large set of permission requested by apps lead to worse experience in terms of privacy for consumers. As the announcement for Instant Apps at Google I/O demonstrate, web as an open platform is in peril and its demise will be only hastened by blindly adopting these types of recommendations.
Essentially web as open platform will be destroyed in the name of perfect privacy. Only to be replaced by inescapable walled gardens. Rather consider that web allows a motivated user to employ evasion tactics, while still offering usability to those who are not interested in privacy. While with native apps where Apple needs a credit card on file to install, offer no such opportunity.
I am happy that Arvind (author of the paper) in another comment recommends a similar approach:
""" Personally I think there are so many of these APIs that for the browser to try to prevent the ability to fingerprint is putting the genie back in the bottle. But there is one powerful step browsers can take: put stronger privacy protections into private browsing mode, even at the expense of some functionality. Firefox has taken steps in this direction https://blog.mozilla.org/blog/2015/11/03/firefox-now-offers-.... Traditionally all browsers viewed private browsing mode as protecting against local adversaries and not trackers / network adversaries, and in my opinion this was a mistake. """
https://news.ycombinator.com/item?id=11730373
To interpret this research as reason for crippling web or browsers would be a giant mistake. Crippling browsers will only work against users, who will be then forced into installing apps by companies.
Two popular shopping companies in India exactly did this, they completely abandoned their websites and went native app only. This combined with large set of permission requested by apps lead to worse experience in terms of privacy for consumers. As the announcement for Instant Apps at Google I/O demonstrate, web as an open platform is in peril and its demise will be only hastened by blindly adopting these types of recommendations.
Essentially web as open platform will be destroyed in the name of perfect privacy. Only to be replaced by inescapable walled gardens. Rather consider that web allows a motivated user to employ evasion tactics, while still offering usability to those who are not interested in privacy. While with native apps where Apple needs a credit card on file to install, offer no such opportunity.
I am happy that Arvind (author of the paper) in another comment recommends a similar approach:
""" Personally I think there are so many of these APIs that for the browser to try to prevent the ability to fingerprint is putting the genie back in the bottle. But there is one powerful step browsers can take: put stronger privacy protections into private browsing mode, even at the expense of some functionality. Firefox has taken steps in this direction https://blog.mozilla.org/blog/2015/11/03/firefox-now-offers-.... Traditionally all browsers viewed private browsing mode as protecting against local adversaries and not trackers / network adversaries, and in my opinion this was a mistake. """
https://news.ycombinator.com/item?id=11730373
> Two popular shopping companies in India exactly did this, they completely abandoned their websites and went native app only. This combined with large set of permission requested by apps lead to worse experience in terms of privacy for consumers.
I'm surprised nobody has commented on your comment yet. I was in a meeting just this morning where my interlocutor assured me that over 70% of advertising in 10 years will be native apps since everything else is getting blocked or abandoned (and presenting it as an opportunity to do all the stuff you "can't do anymore" on browser).
I'm surprised nobody has commented on your comment yet. I was in a meeting just this morning where my interlocutor assured me that over 70% of advertising in 10 years will be native apps since everything else is getting blocked or abandoned (and presenting it as an opportunity to do all the stuff you "can't do anymore" on browser).
Over 3,000 top sites using the font technique, and from the description this sounds really wasteful (choosing and drawing in a variety of fonts for no reason other than to sniff out the user).
Each font is probably associated with a non-trivial caching scheme and other OS resources, not to mention the use of anti-aliasing in rendering, etc. So a web page, doing something you don’t even want, is able to cause the OS to devote maybe 100x more resources to fonts than it otherwise would?
A simple solution would be to set a hard limit, such as “4 fonts maximum”, for any web site; and, to completely disallow linked domains from using more.
Each font is probably associated with a non-trivial caching scheme and other OS resources, not to mention the use of anti-aliasing in rendering, etc. So a web page, doing something you don’t even want, is able to cause the OS to devote maybe 100x more resources to fonts than it otherwise would?
A simple solution would be to set a hard limit, such as “4 fonts maximum”, for any web site; and, to completely disallow linked domains from using more.
After reading this it makes me want to disable JavaScript entirely, along with cookies, and go back to text browsing. I've been using Ghostery on my phone, it's been pretty good.
I'd say that's pretty needless. I run ghostery and ABP simultaneously and they do a great job catching these trackers.
The downside of having no JS compared to accidentally a getting fingerprinted is a no brainer for me. Modern web is pretty useless without JS for me.
The downside of having no JS compared to accidentally a getting fingerprinted is a no brainer for me. Modern web is pretty useless without JS for me.
Whoa, what's the use case for exposing battery information?
Some application want access to the battery info as they might want to disable some functionality in case your battery runs low. It would be smarter if instead of giving exact battery level it will get a callback once the battery runs low.
The Great Suspender is an example of this. Auto-sleeps browser tabs when on battery.
https://chrome.google.com/webstore/detail/the-great-suspende...
https://chrome.google.com/webstore/detail/the-great-suspende...
Sharing the battery information with a browser extension seems reasonable, but are there any websites that actually use the battery information for legitimate user benefit?
Wait until you see WebUSB[1]. The use case is Chrome OS, not much more.
[1] https://news.ycombinator.com/item?id=11465924
[1] https://news.ycombinator.com/item?id=11465924
Web apps, "half native" web apps (Appcache + show on homescreen link) and ionic/cordova apps running in fullscreen mode.
E.g. a geocaching app could benefit by signaling the user if battery goes low (Ingress is a battery hog, for example!)
E.g. a geocaching app could benefit by signaling the user if battery goes low (Ingress is a battery hog, for example!)
Of course this is something you do. Throw it together with all of the other information you can clean from a browser (referrer, ip) and you can get a match with a very high confidence level.
Shops can do the same with baskets, you find that people are either identified by one very rare feature which reoccurs often or their little graph of 4-5 items which correlate 99% to them.
Shops can do the same with baskets, you find that people are either identified by one very rare feature which reoccurs often or their little graph of 4-5 items which correlate 99% to them.
All these things make the websites the new apps. Most probably we won't need to use many desktop applications a few years later.
That's the line Apple took with iOS shortly before it introduced the App store. Mozilla, Palm/HP, and even Microsoft with it's Win 8 Metro Apps tried to make websites the new apps. It has some short comings.
Web apps are definitely getting better, I haven't used an actual email client in 10 years, but they have a long way to go before they can replace dedicated clients entirely.
Web apps are definitely getting better, I haven't used an actual email client in 10 years, but they have a long way to go before they can replace dedicated clients entirely.
> Web apps are definitely getting better, ... but they have a long way to go before they can replace dedicated clients entirely.
And yet, just yesterday there was a great discussion on Virtual Desktop Infrastructures, where entire operating systems are accessed and operated virtually through just the browser [0].
The current top comment indicates that while there are some setup hoops to jump through to use a specific OS, the performance itself "works very well" [1]. Does this not qualify as a web app replacing a client entirely?
[0] https://news.ycombinator.com/item?id=11721466 [1] https://news.ycombinator.com/item?id=11722141
And yet, just yesterday there was a great discussion on Virtual Desktop Infrastructures, where entire operating systems are accessed and operated virtually through just the browser [0].
The current top comment indicates that while there are some setup hoops to jump through to use a specific OS, the performance itself "works very well" [1]. Does this not qualify as a web app replacing a client entirely?
[0] https://news.ycombinator.com/item?id=11721466 [1] https://news.ycombinator.com/item?id=11722141
> Does this not qualify as a web app replacing a client entirely?
If you can pull up a video stream from a surveillance camera in your house then you no longer need a home?
When you watch Daredevil on the Netflix App on your phone do you think that the actors are inside your phone performing live action for you?
What they're discussing is a web app that allows you to interact with a remote client. That client OS still exists and the UI/UX is still being rendered by a nonweb technology, the pixels rendered are just being streamed to your web browser instead of to a monitor and your inputs are being captured and transmitted to that client OS.
If you can pull up a video stream from a surveillance camera in your house then you no longer need a home?
When you watch Daredevil on the Netflix App on your phone do you think that the actors are inside your phone performing live action for you?
What they're discussing is a web app that allows you to interact with a remote client. That client OS still exists and the UI/UX is still being rendered by a nonweb technology, the pixels rendered are just being streamed to your web browser instead of to a monitor and your inputs are being captured and transmitted to that client OS.
That doesn't sound too far from Desktop Computing as a Service. It will be a sad day when I have to pay $9/month to be able to log into my desktop.
I mostly agree.
Ideally I'd like to have a minimal OS and file set on my local machine (for offline and poor connectivity scenarios), that automatically syncs with my own, encrypted cloud system, such that I can (at my own discretion) update the OS from controlled sources (e.g. git). But I don't think there is enough interest from others for such a system, and I'm occupied with enough other projects that I won't be able to set up such a system.
Ideally I'd like to have a minimal OS and file set on my local machine (for offline and poor connectivity scenarios), that automatically syncs with my own, encrypted cloud system, such that I can (at my own discretion) update the OS from controlled sources (e.g. git). But I don't think there is enough interest from others for such a system, and I'm occupied with enough other projects that I won't be able to set up such a system.
I think that it depends on your use-case. I use Google Photos to store my media files, Github to store application configuration & source code of my applications, Chrome to store bookmarks, passwords, Spotify to save & listen music etc. Even if I lost my computer now, I would easily setup my desktop environment again.
For me, I don't use Google Photos or Spotify, I have my own local copies and maintain my own backups.
I do use Github for some projects, but I also maintain local copies and maintain my own backups for all my projects.
If pinboard.in ever disappeared, it'd be like loosing an appendage! It might not be as bad as loosing an entire arm or leg, but its loss would be equivalent to at least a finger or two!
I do use Github for some projects, but I also maintain local copies and maintain my own backups for all my projects.
If pinboard.in ever disappeared, it'd be like loosing an appendage! It might not be as bad as loosing an entire arm or leg, but its loss would be equivalent to at least a finger or two!
It will probably have usage based pricing.
Full replacements will probably have to wait for mass adoption of WebAssembly, web workers and probably some other things as well.
Heck, what would be really interesting would be hardware acceleration for the final version of WebAssembly. That should (?) make it competitive with regular assembly.
Heck, what would be really interesting would be hardware acceleration for the final version of WebAssembly. That should (?) make it competitive with regular assembly.
> Web apps are definitely getting better, I haven't used an actual email client in 10 years
Oddly enough, just yesterday I started using an email client once more (emacs+gnus, for Gmail). It just felt so _nice_. And fast too!
Oddly enough, just yesterday I started using an email client once more (emacs+gnus, for Gmail). It just felt so _nice_. And fast too!
I'm not sure why this seems to be a controversial opinion. Webasm with good concurrency could mean well written webasm software actually running faster than poorly written desktop software unless there is hardware acceleration on the desktop side that can't be used on the web side.
If you want to see a live demo of all the ways your browser can fingerprint you, this is a great website: https://www.browserleaks.com/
Since the original web based ad campaigns were launched we have been tracked. Serious web analytics companies know these tactics already.
So what exactly is the research contribution being made here? What's new and interesting?
So what exactly is the research contribution being made here? What's new and interesting?
I think its similar to how Absolute Computrace rootkit identifies Android and Lenovo devices. Each hardware compoment has a unique ID, like your ethernet, bluetooth, even microphones and batteries.
Would it be more secure to use tor than traditional browser. The only drawback is the longer RTT.
Ahhh. Remember when this was just a Flash problem, and getting rid of Flash was going to rid the world of evil?
Spoiler: that didn't happen.
Spoiler: that didn't happen.
Things like this happened with flash but you had no control over them since flash was all or nothing and closed source.
I agree with that (technical person's) perspective, but that was not the mainline argument. Steve Jobs got on stage and said it was a hunk of battery wasting crap that invaded your privacy. I'm saying you can make that case regardless of your platform de jour.
Well, who would have guessed. Surprise surprise.
The web is such a shit technology.
The web is such a shit technology.
And how would Silverlight or Java applets or Flash or any other client side technology be better in this regard?
You have to expose capabilities and those capabilities can be used to create an unique fingerprint based on your device.
How would you design the stack so that this kind of thing is impossible? Feel free to use your favorite tech stack as a base.
You have to expose capabilities and those capabilities can be used to create an unique fingerprint based on your device.
How would you design the stack so that this kind of thing is impossible? Feel free to use your favorite tech stack as a base.
Simple: Seperate documents, interactivity, and programs.
If I browse the web, I usually want documents.
Sometimes I also want interactivity, like in comment forms, which could be a seperated widget which could only interact in limited ways, and only with the page and the server it connects to.
And then there would be programs, which could access even local files – but would have an installation process like browser extensions.
Giving documents access that normally just programs do is stupid, as we have seen in Word Macro-based malware, PDF-based malware, Browser-based malware (the pdf.js exploit, for example), and so on.
If I browse the web, I usually want documents.
Sometimes I also want interactivity, like in comment forms, which could be a seperated widget which could only interact in limited ways, and only with the page and the server it connects to.
And then there would be programs, which could access even local files – but would have an installation process like browser extensions.
Giving documents access that normally just programs do is stupid, as we have seen in Word Macro-based malware, PDF-based malware, Browser-based malware (the pdf.js exploit, for example), and so on.
How about not developing applications in the browser?
Its about linked documents. Not angular-17 MVVM async session persistence in indexdb with websql and asm.js rendering webgl for a spinning teapot.
OK. So you get your 'document only' internet. Where do we put all the other stuff? I have a bunch of 'non-document' websites that are essential to me now.
What happens under your new regime? Someone reimplements them all as native apps?
The point I'm making is just because your internet is document-only please don't assume mine or other people's are.
What happens under your new regime? Someone reimplements them all as native apps?
The point I'm making is just because your internet is document-only please don't assume mine or other people's are.
Because it is so, it must be so.
Every web app is written in perl/php, therefore we will keep using perl/php. - What will you do, rewrite the apps? </..
internet != web.
This cludge of in-browser tech everyone is pursuing already comes with so much suffering for the developer. But the enthusiasm to embrace garbage like religion is just unbelievable. (yeah js everything, spotify lol)
I think the current webapp tech stack is not doing our generation justice. Yes google has very strong interests in maintaining status quo since it dominates it and so do many other giants. But good, user friendly and maintainable software looks different.
Why not break the completely misused model of documents for apps ? there is no document semantics in 1000x <div> elements riddled with js callbacks.
But dont let my cynicism annoy you, its the resignation talking. Imagine what cool tech we would have if something was started in the 90s (no, not java applets) and was all grown up now.
But every big company is now a walled garden provider. Just think about UI toolkits, would spotify be in Chromeframe otherwise?.
Every web app is written in perl/php, therefore we will keep using perl/php. - What will you do, rewrite the apps? </..
internet != web.
This cludge of in-browser tech everyone is pursuing already comes with so much suffering for the developer. But the enthusiasm to embrace garbage like religion is just unbelievable. (yeah js everything, spotify lol)
I think the current webapp tech stack is not doing our generation justice. Yes google has very strong interests in maintaining status quo since it dominates it and so do many other giants. But good, user friendly and maintainable software looks different.
Why not break the completely misused model of documents for apps ? there is no document semantics in 1000x <div> elements riddled with js callbacks.
But dont let my cynicism annoy you, its the resignation talking. Imagine what cool tech we would have if something was started in the 90s (no, not java applets) and was all grown up now.
But every big company is now a walled garden provider. Just think about UI toolkits, would spotify be in Chromeframe otherwise?.
"The web" is such a shit technology?
No one denies that the web as we know it is kind of a clusterfuck of things duct taped together, but to say it's "a shit technology" is maybe giving too little credit.
No one denies that the web as we know it is kind of a clusterfuck of things duct taped together, but to say it's "a shit technology" is maybe giving too little credit.
The tool we built to do this research is open-source https://github.com/citp/OpenWPM/ We'd love to work with outside developers to improve it and do new things with it. We've also released the raw data from our study.