[tor-talk] Vidalia+Tor separtely from TBB`s Firefox

[Mike Perry]

Thus spake Joe Btfsplk (joebtfsplk at gmx.com):

> On 1/13/2012 4:10 PM, Mike Perry wrote:
> >Thus spake Greg Kalitnikoff (kalitnikoff at privatdemail.net):
> >
> >>P.S. Also reading https://www.torproject.org/projects/torbrowser/design/
> >>I found this: "Filter-based addons such as AdBlock Plus, Request Policy,
> >>Ghostery, Priv3, and Sharemenot are to be avoided." But here
> >>https://lists.torproject.org/pipermail/tor-talk/2011-November/022052.html
> >>we see Andrew Lewman`s "In my world, I'd replace noscript with
> >>requestpolicy". I`m a bit confused :-/
> >There should be no need to use filters to address 3rd party linkability
> >with a proper implementation of the requirements in
> >https://www.torproject.org/projects/torbrowser/design/#privacy
> >
> >To my knowledge, the only remaining 3rd party direct linkability risk
> >is through HTTP Keepalive (Section 3.5.6), but this linkability is
> >limited to a 20 second window.
> >
> >There is a risk of first party linkability through redirects (Section
> >3.5.7). This one will be harder to solve, but it is more noticable
> >attack.
> >
> >There are also fingerprinting risks involving time that need to be
> >addressed (3.6.6 and 3.6.7), but the verdict is not in as to exactly
> >how much info these provide in practice. Regardless, we should also
> >have some level of mitigation in place for Tor Browser 2.3.x.
> >
> >It is my opinion that these remaining threats do not justify the need
> >for filters, and that we should focus on eliminating these few
> >remaining issues rather than trying to design a filter mechanism that
> >isn't full of fail.
> >
> I'm unclear.  How does Tor ( in TBB) prevent trackers (beacons, web 
> bugs) from gathering & transmitting data, once these are loaded w/ web 
> pages?  If there something in Tor that prevents these from phoning 
> home?  If so, how?  It's been mentioned about the discussion from
> https://www.torproject.org/projects/torbrowser/design/#privacy

These beacons can record your visit on one site, but they are not
able to store identifiers in the browser that would allow them to
determine it is the same you when you visit another site.

This removes the linkability property that gives 3rd parties
omniscience over browsing activity.

> Side note - In TBB, the preference "network.http.sendRefererHeader" 
> comes w/ default setting to send referer header info (I believe that 
> wasn't always the case).  With this default setting, doesn't that allow 
> websites to identify the site you just came from if you click a link?

Yes, I believe that at best, blocking referrers only prevents
accidental info leakage. There are too many direct channels between
page elements to expect to stop all transmission. In fact, if you look
at Google+ +1 buttons, they already encode the referer url directly in
the GET request, probably because of the lack of referrers in
http->https scheme transmissions.

See http://archives.seul.org/or/dev/Jun-2011/msg00105.html,
http://archives.seul.org/or/dev/Jul-2011/msg00019.html and the rest of
that thread for more detailed discussion.

> And haven't I read that all ads aren't necessarily JUST ads?

I guess you mean they could be malware? Again, we should persue a
general approach of least priviledge and hardening. You face the same
risk from exit nodes, after all.

I'd love to see Seatbelt, AppArmor, and SELinux policies created for
TBB, though.


-- 
Mike Perry
Exterminate all dogma.
Permit no exceptions.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20120116/8625c7fd/attachment.pgp>