Thus spake Joe Btfsplk (joebtfsplk@xxxxxxx): > >>>A few months ago, someone raised the question of TBB or any included > >>>addon not blocking web beacons / trackers and perhaps something like > >>>Ghostery should be included in TBB (I think). I asked about beacons > >>>(web bugs) compromising anonymity (not to mention privacy). Can't > >>>find the post, but I believe either Mike or Roger replied that it > >>>shouldn't be an issue because web beacons, like Google Analytics, > >>>can't track from site to site. Hope I've got the essence of the > >>>reply correct. > >>Yes, that is correct. We consider the ability to link user activity > >>across different url bar domains a violation of our design requirements > >>(https://www.torproject.org/projects/torbrowser/design/#privacy), and > >>any ability to do so is a major bug. > >> > >>Unfortunately, there are a couple such bugs we're already currently > >>aware of: > >>https://trac.torproject.org/projects/tor/query?keywords=~tbb-linkability > >> > >>We'll fix them, eventually. Help is always appreciated, though. > >Oh, I should also mention > >https://www.torproject.org/projects/torbrowser/design/#identifier-linkability > >as the laundry list of linkability mechanisms we've already at least > >partially fixed. > Thanks. Then thinking about the cross domain tracking ability of > web beacons (or that they could) must have changed since this was > last discussed. At that time, as memory serves, regarding beacons > in general & idea of using Ghostery or something similar in > function, it was said to be a non issue for Tor users.:-) > > The design document draft, dated Dec 28, 2011 doesn't seem to > mention web beacons. Other than in a non specific way, the document > doesn't seem to address how to handle them. They aren't cookies, > so don't fall under cookie control (in current or future browser > designs). Yet, they can track across domains. A lot of users (Tor > & non Tor) don't understand this nor are even aware of them. If you prevent the associated identifier transmission and fingerprinting issues, "web beacons" do not link your activity on one url to another. If we prevent identifier transmission and fingerpritning, web beacons will see both visits, but they do not know it is the same user on both visits. The reason we don't care that they can still see both visits is because the urls you visit can and do simply sell their logs to third parties already. If a site tries to deploy web beacons, you should assume they are also selling your data to whoever is buying, regardless of what the browser actually does. > Presumably, as they are loaded w/ pages, even w/ disk cache turned > off, they can still be stored in memory cache & still track users, > unless memory cache is disabled. True? Not exactly. In Tor Browser, cache is isolated by url bar domain, meaning that the cached copy of a web beacon that was loaded under one url bar is actually *not* used when the same web beacon is loaded under a different url bar. Though in interest of full disclosure, you'll notice that one of the "tbb-linkability" tagged bugs is an issue with this cache isolation specifically for images: https://trac.torproject.org/projects/tor/ticket/5742 Tracking scripts are correctly isolated in the cache, however (which is more important, as many tracking scripts *do* embed unique identifiers to get cached and used when the user clears cookies). > Is there a reason that using Ghostery, or similar technology, > couldn't or shouldn't be used until / if a design change in Tor / > TBB prevents web beacons from being loaded w/ pages? > Perhaps the downside of using an addon like Ghostery out weighs the > benefits for TBB users? I'm not married to it, but haven't seen > many other similar solutions for beacons. Disable ALL image > loading... Two reasons come to mind: 1. Ghostery subscriptions and user blocks can be fingerprintable themselves. 2. We'd rather devote the effort to fixing the root technical issues rather than figuring out how to audit and safely configure Ghostery. > It does have options not to auto update blocking elements, if > updating during * critical * Tor sessions was an issue. Other than > that, I'm not an expert. I think the concept of web beacons is > extremely deceitful for any browser & should under consideration by > Congress to be banned, as are evercookies. In the mean time... what > about looking into Ghostery, etc., at least w/ suggested settings > until something better is devised by Tor Project? Never wish for regulation, especially when problems can be solved by technology instead: https://en.wikipedia.org/wiki/Regulatory_capture The EFF and the policy crowd may disagree. But frankly, they're wrong. > Re: Flash LSO cookies in Windows. The Dec 28, 2011 design document > mentions, > >Flash cookies... > > >*...Implementation Status:* We are currently having difficulties > ><https://trac.torproject.org/projects/tor/ticket/3974> causing > >Flash player to use this settings file on Windows, so Flash > >remains difficult to enable. > > > If you can't get Flash to use a settings file - for now - maybe next > best thing is education. I'm thinking there should be a prominent > file in TBB, containing a number of IMPORTANT changes that users > should make; name it something like "you better make these changes > or you may die.html," that opens w/ a new browser install. The > storage settings for Flash are fairly straight forward, w/ a little > explanation, even though users must go to Adobe's site to change > them (tricky, huh?). Even I could write / "borrow" instructions on > how to change settings in Windows Flash manager, for better privacy. > Cookies & disk storage can be prevented totally, but if you del the > "settings" cookie, all Flash settings revert to default. Well, that's also not the only issue with Flash. Flash has tons of fingerprinting and proxybypass issues hidden in its binary blob. We really need a full sandboxing technology to make it safe to uniformly enable. I think Steve Jobs was right on this one. Flash needs to be replaced with open technologies. -- Mike Perry
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-talk mailing list tor-talk@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk