Electronic Privacy
Cees Binkhorst
ceesbink at XS4ALL.NL
Sun Jan 31 10:22:43 CET 2010
REPLY TO: D66 at nic.surfnet.nl
Een (ik zou haast zeggen VERPLICHTE) test om te zien hoe
identificeerbaar je browser (en daardoor jij) bent, door de gegevens die
je browser kan geven.
Gecombineert met geolocation en IP-adres geef je onderhand iedereen waar
je op een webpagina kijkt, haast je huisadres.
Overigens maakt het bij UPC uit met welke PC en operating-systeem je
inlogt ;)
Zelfde PC ander OS, dan ook ander IP-adres en idem andere PC, ander
IP-adres.
Groet / Cees
https://panopticlick.eff.org/
ZONDER JAVASCRIPT: 1 op 749 browsers (9,55 bits of info)
Browser bits of identifying one in 749 browsers
Characteristic information have this value
User Agent 6.21 73.91 details mijn browser
HTTP_ACCEPT 4.13 17.47 details mijn browser
Headers
Browser 2.52 5.73 no javascript
Plugin Details
Time Zone 2.5 5.67 no javascript
Screen Size 2.5 5.67 no javascript
and Color Depth
System Fonts 2.51 5.68 no javascript
Are Cookies 0.25 1.19 Yes
Enabled?
Limited 2.5 5.67 no javascript
supercookie test
MET JAVASCRIPT: 1 op 1 browsers (18,62 bits of info)
Your browser fingerprint appears to be unique among the 405,456 tested
so far.
Frequently asked questions about Panopticlick
Q: Why does your browser remain unique, even if you reload the page?
A: As noted in the panopticlick privacy policy, the site uses a 3-month
persistent cookie to try to prevent double-counting of browsers.
Now, you may ask, what about people who block cookies? If you block
cookies and hit reload, your browser will be multi-counted in the live
data at panopticlick.eff.org, which means that the numbers will be
overly optimistic about how non-rare your broswer is.
We plan to do some analysis on the dataset to correct out these
effects. One strategy would be to assume that the average number of
reloads for a cookie-accepting user is the same as that for a
cookie-blocking user. Another would be to use the encrypted IP addresses
and fuzzy timestamps we have to try to recognise and discount cookieless
reloads.
Once we've run these analyses, we'll publish public data on the
overall uniqueness rates we've seen.
Q: How many people are unique?
A: About 85% and falling, as the dataset gets larger. But that's a
rough estimate before doing the count corrections discussed in the
previous answer.
Q: Why is there so much information in the font list?
A: Note that the font list includes not only a set of fonts, but an
ordering of those fonts which is presumably related to the inode walk
order as implicitly reported by Flash. In the browsers we tested before
launch, this ordering appeared to be stable, so we thought it was
acceptable to not sort the font list before using it. If it turns out
that some browsers have non-stable font list orderings, we may have to
renormalise our data, either for those browsers or all browsers, which
would presumably decrease uniqueness levels substantially.
One corollary here is that Flash, Java and other plugins that
report fontlists could decrease their fingerprintability by sorting the
fontlist before returning it to client side scripts.
The constant ordering property didn't seem to hold for plugin lists
-- the order of navigator.plugins seems to vary on a given browser, so
we sort them before fingerprinting.
Q: Why don't you include browser characteristic x in the fingerprint?
A: There are a lot of things that could potentially be added to the
fingerprints that Panopticlick uses. Some of them are documented on the
excellent website browserspy, others are being suggested by other sources.
In general, there are three possible reasons why we didn't include
something:
1. we thought about that characteristic, but decided that it
changed too often in a given browser to make a stable fingerprint
ingredient;
2. we didn't know about it or didn't have time to implement it;
3. browsers ask the user for permission before the feature operates.
Examples of things that we didn't think were stable enough
included: geolocation, IP addresses (either yours or your gateway's) as
detected using Flash or Java, and the CSS history detection hack.
Examples of things that we'd like to have implemented, but either
didn't know about or didn't have time to implement: other supercookies
(Flash, Silverlight, HTML 5 databases, DOM globalStorage), ActiveX CPU
detection, CSS font detection tricks (in cases where Flash and Java
don't report fonts), detection of more plugins in Internet Explorer, and
lots of Silverlight stuff.
Examples of things that require user permission include Google
Gears supercookies and the fancy geolocation feature in recent browsers
(which are also non-constant).
A final, overall point:
The quality of data that we get from this project is definitely
decreased as a result of the fact that the design of the website
encourages people to play with their browser configurations. A lot of
people are doing things like turning off javascript, entering private
browsing mode, or deleting cookies just to see what effects those
actions have on uniqueness.
That's great from an educational point of view, but it's probably going
to add a lot of noise to our data that we'll only be able to correct for
partially. We'd have gotten better data by putting these tests in an
invisible corner of a high-traffic website, but that simply isn't the
EFF way when it comes to running an experiment like this: we wanted to
make sure people knew they were participating, and let them know — even
approximately — how rare/unique they were.
**********
Dit bericht is verzonden via de informele D66 discussielijst (D66 at nic.surfnet.nl).
Aanmelden: stuur een email naar LISTSERV at nic.surfnet.nl met in het tekstveld alleen: SUBSCRIBE D66 uwvoornaam uwachternaam
Afmelden: stuur een email naar LISTSERV at nic.surfnet.nl met in het tekstveld alleen: SIGNOFF D66
Het on-line archief is te vinden op: http://listserv.surfnet.nl/archives/d66.html
**********
More information about the D66
mailing list