51–60 of 272 posts
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.
Coauthor here. I lead the research team at Princeton working to uncover online tracking. Happy to answer questions. 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.
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 wha…
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.
Malware filtering is needed.
Earlier quoted context omitted.
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.
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?
I think Tor Browser tries to do this for some types of fingerprinting.
Earlier quoted context omitted.
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-ie…
NoScript is an all-or-nothing approach. Are there any JS-blockers that allow API-level blocks?
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.
Earlier quoted context omitted.
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/ > "This page tests b…
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?
Check out https://panopticlick.eff.org - this will attempt to fingerprint your browser and see if it's unique.
Whoa, what's the use case for exposing battery information?
E.g. a geocaching app could benefit by signaling the user if battery goes low (Ingress is a battery hog, for example!)
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. """