[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-talk] google analytics says it can track across separate domains

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

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

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:

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

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:

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

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