Delivery-Date: Fri, 28 Aug 2015 23:05:55 -0400
Return-Path: <tor-talk-bounces@lists.torproject.org>
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on moria.seul.org
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,
	T_RP_MATCHES_RCVD autolearn=ham version=3.3.1
X-Original-To: archiver@seul.org
Delivered-To: archiver@seul.org
Received: from eugeni.torproject.org (eugeni.torproject.org [38.229.72.13])
	(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by khazad-dum.seul.org (Postfix) with ESMTPS id 148111E04F0;
	Fri, 28 Aug 2015 23:05:53 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id BA1F63729A;
	Sat, 29 Aug 2015 03:05:47 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id E82A037297
 for <tor-talk@lists.torproject.org>; Sat, 29 Aug 2015 03:05:43 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at 
Received: from eugeni.torproject.org ([127.0.0.1])
 by localhost (eugeni.torproject.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id hP6F4h45CeEA for <tor-talk@lists.torproject.org>;
 Sat, 29 Aug 2015 03:05:43 +0000 (UTC)
Received: from turtles.fscked.org (turtles.fscked.org [76.73.17.194])
 by eugeni.torproject.org (Postfix) with ESMTP id B45693727A
 for <tor-talk@lists.torproject.org>; Sat, 29 Aug 2015 03:05:43 +0000 (UTC)
Date: Fri, 28 Aug 2015 20:05:17 -0700
From: Mike Perry <mikeperry@torproject.org>
To: tor-talk@lists.torproject.org
Message-ID: <20150829030517.GH5822@torproject.org>
References: <20150828230041.747D340496@smtp03.mail.de>
 <20150829020151.GG5822@torproject.org>
 <55E1163E.3050506@freedom.press>
MIME-Version: 1.0
In-Reply-To: <55E1163E.3050506@freedom.press>
Subject: Re: [tor-talk] Privacy Badger
X-BeenThere: tor-talk@lists.torproject.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tor-talk@lists.torproject.org
List-Id: "all discussion about theory, design,
 and development of Onion Routing" <tor-talk.lists.torproject.org>
List-Unsubscribe: <https://lists.torproject.org/cgi-bin/mailman/options/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=unsubscribe>
List-Archive: <http://lists.torproject.org/pipermail/tor-talk/>
List-Post: <mailto:tor-talk@lists.torproject.org>
List-Help: <mailto:tor-talk-request@lists.torproject.org?subject=help>
List-Subscribe: <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1954547375802724151=="
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>


--===============1954547375802724151==
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="+QwZB9vYiNIzNXIj"
Content-Disposition: inline


--+QwZB9vYiNIzNXIj
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Garrett Robinson:
> On 8/28/15 7:01 PM, Mike Perry wrote:
> > sg.info@email-postfach.info:
> >> Hi guys and girls,
> >> are there security issues using the privacy badger from eff.org with t=
he tor browser ?=20
> >> Or: Is there are a need to use privacy badger or is this utility dispe=
nsable ?
> >=20
> > The filters in use by Privacy Badger are fingerprintable - it is
> > possible for sites to determine that you have it installed.
>=20
> Since Privacy Badger uses a learning heuristic based on the sites you
> visit, it actually might possible for it to leak information about your
> browsing history too.

Yikes! I didn't know this. This is especially bad, especially if Privacy
Badger has custom storage mechanisms for this that aren't cleared
regularly (which you touch on below). It may also result in browsing
history leaking to disk, which wouldn't normally happen in the default
Tor Browser.

I'm now actually curious if these types of filter addons aren't already
being exploited for these and related weaknesses/shortcomings.

If any academics are interested in a good publication (Gunes Acar - are
you listening? :), it would be *very* interesting to run a crawl to see
if any websites have begun to behave adversarially against addons like
Adblock, Privacy Badger, Ghostery, etc. After all, it is easy for sites
to determine if an adblocker has blocked an ad load, and then proceed to
load an ad from an alternate URL, domain name, or even another ad
network that may not be covered by the default filters.

This may not be likely for less popular addons such as Privacy Badger
yet, but for extremely popular adblockers such as AdBlock, I bet this
behavior is already happening somewhere in the wild right now.

> In general, does Tor Browser persist the state saved by extensions
> across restarts, or is that wiped along with the history and cookies and
> everything else?

Because of the current privilege level and capabilities of extensions
(basically the same as the browser C++ code), we cannot ensure that
extensions are well behaved in this way.

However, when the user clicks "New Identity" in the Torbutton menu, we
do emit "browser:purge-session-history", "last-pb-context-exited", and
clear all cookies (which emits another event that triggers various bits
of the browser to clear state, according to spec). We also manually
clear a bunch of related state in the browser:
https://www.torproject.org/projects/torbrowser/design/#new-identity

Firefox extensions are encouraged to obey these events to clear their
stored state, but this is only by convention[1]. Many do not do this.
In fact, a while ago we found issues with NoScript where it was storing
state in prefs that got written to disk, and were not reset by these
events.


As for session restarts, that is enforced only by preventing the browser
=66rom storing disk records on a per-mechanism basis:
https://www.torproject.org/projects/torbrowser/design/#disk-avoidance

Again, because of their full privilege level and capabilities, addons
can store their own state however they wish. Custom/ad-hoc storage
mechanisms (such as using special preference names as value storage, or
writing raw data to files on disk) will not be covered by our changes.


I'm now curious about how Privacy Badger stores its state...


1. https://developer.mozilla.org/EN/docs/Supporting_per-window_private_brow=
sing

--=20
Mike Perry

--+QwZB9vYiNIzNXIj
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJV4SFtAAoJEEEC+JXS8eGGCjQQAKvc+LwMne35TmqJHkLruYi4
ps2kYGo52lcUKNm5EsjEVTPxSJpTWrSfhyPW3xxMAFgAm0gI4rLTH0R2IwVBy9m4
PCKmMMJwrcFFE2urTSoAirutJX/pQUPjJZezQTpXOWpVy9nSjsQ9LKdcONHnv2Ke
1m5CqtQQKfbo0sPHfzMRR8SSKuYhOEtoGTeozN7KAzJBxjPxWp6worszyGqTu3rH
JIiBiqUdMjFWotKj1UXPCzdq0oog9MwAbDYm+0Xqkc+q/h3BNmEICuflU7PmHwT0
4ORQLjGadytyejdUXCiZhh55uxkD3r+H+CrQM+2iQaUOj0zUbGhF3fOXFEgV01Xb
rVL1hGHko1PTHFHM3lAEGnsF4ElKjkVL/BFCHTauXae41Rx23JcEQfoAFZI4upIA
K/mHEtGLPTrsO7c0ss71+2FwfihyNQMciaWoewxnXRrbdIB9hrTI7OxZrbZgtpOm
teJVYSY0nFt4zr3xO1YdH4FuuvOslH208nQ+lyXEf8BCtiC5EExBPZJeSwI7hvJB
R+gBVy34q4/H0ckaXtlaNuNThEyy0m9jxlJOnm6+6D27RzddYU2J0J7Y1WH/8O1v
3vSh0fG0EwTvd8285BX0XfXv3EUVmMln/J0hBwT5x1d5Qtik/LZmsDc6fuVQc6et
IxfEzoP0X4vc1UBdvstu
=vDG+
-----END PGP SIGNATURE-----

--+QwZB9vYiNIzNXIj--

--===============1954547375802724151==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

--===============1954547375802724151==--

