Private Browsing instrumentation

[Ehsan Akhgari]

Hi everyone,

For those who don’t know me, I’m a Principal Engineer at Mozilla, and the
module owner of Private Browsing in Firefox. I’m also responsible for the
original design and implementation of the feature many years ago.

Introduction

=========

TL;DR: Historically, we have considered the fact that the user may have
used a private window as sensitive data, preventing us from collecting data
such as how much usage PBM receives in Firefox. Going forward, we'd like to
modify this policy and will no longer do things to conceal, from ourselves
or from local adversaries, the fact that the user was in private browsing.
Of course, the user’s browsing history and any indicators revealing what
websites they’ve visited in a private window will remain sensitive data and
won’t be subject to our data collection.

This is a complex topic that I’ve been involved with for a few years now,
and it has taken me some time to change my own viewpoint here as we have
discovered more aspects of the issue and have had more time to reflect on
the various aspects of it, so I’d like to spend some time to describe the
background, what we’re changing, and why we’re making this change now.

Background

=========

Historically[1], the threat model we have had for private browsing focused
on a local adversary - someone with direct access to Firefox. We wanted to
prevent that local adversary from learning about the user’s activity while
in private browsing. The initial design of private browsing mode (PBM)
therefore concentrated on isolating that mode from regular browsing.
Overtime, we’ve added anti-tracking features to private browsing that also
protect against online adversaries. The landscape of our anti-tracking
features is now slowly expanding outside of private browsing mode.

Because of this initial focus on the local adversary, our policy has been
to avoid leaving data on the device that would reveal the users’ activity
while in private browsing, specifically the type of activity that leaks
details about a user’s browsing. So for example we avoid storing users’
history and cookies during private browsing sessions. We interpreted this
policy to also include avoiding leaving data on the device that would
reveal that private browsing was used.

We write different types of data to disk in Firefox. Some of this data
clearly would cross the lines in terms of revealing something about user’s
browsing, e.g. the URL of a page they have visited. In such cases it has
been very easy to decide we should not write that data to disk during a
private session. In other cases we have data that is much less clearly
revealing. This announcement is about one particular type of data: data
which reveals whether a user has used any private windows in a session at
all (obviously without revealing anything about what the user has done in
the said window). Many years ago we made a decision to consider this class
of data as sensitive for private browsing, and have since went above and
beyond to ensure that Firefox won’t leave any trace on the disk to reveal
whether the user has used a private window in a session.

It’s worth mentioning that this decision originally wasn’t made because we
had a clear threat model around the discovery of a user having used a
private window, but rather due to the general principle of going for the
more conservative choice at the time, I believe.

Because our telemetry system writes data to disk prior to sending that data
to our servers, we have tried to avoid directly instrumenting private
browsing in order to not leave that data on disk. However, our telemetry
has historically included data from the users’ private browsing sessions.
It does this by aggregating together data across private and non-private
sessions. What it has NOT deliberately included is information that would
segment the user’s activity based on private browsing or reveal that the
users was in private browsing at all. This would violate the policy
mentioned above. We have not therefore instrumented private browsing
directly and do not know with confidence to what extent this feature is
used today. So we might for example know that a user had ten tabs open in a
day but we don’t know if any of those tabs were opened in private browsing.

Problems with this approach

=====================

We have encountered several problem that result from special-casing private
browsing instrumentation in this way:


1.

This policy is confusing to anybody who isn’t steeped in the design
considerations for private browsing. While that by itself isn’t sufficient
to motivate changing the policy, the practical result of this confusion is
uneven compliance from the teams responsible for instrumenting the browser.
In some cases our telemetry aggregates private and non-private sessions, as
described above. In some cases it only includes activity from non-private
sessions.


That confusion also creates challenges for our product management,
marketing, and business teams. Mozilla as an organization is working to
make more informed data driven decisions about the direction of our
product. To the extent that there is confusion about the policy and about
what our data does and does not cover, that may result in the wrong
decisions. So for example, as a result of this confusion, we recently
determined that our active DAU (daily active users) number - the number we
are using to measure the topline health of our desktop product - is
inaccurate and is undercounting our users by an unknown margin.

Also, I would like to mention here that in the past few years, several
different teams have raised this problem to me on a number of different
occasions and have reached out to ask me (as the module owner for Private
Browsing) to consider changing our policy here. I’ve repeatedly turned
down these requests, sticking to the old historic decision we made back in
the day here.


1.

Resulting from this confusion, special-casing private browsing
measurement while we more fully instrument the browser has proven to be a
brittle approach. We have found, despite our intention, that the fact of
the user’s private browsing usage can be inferred to some extent from
telemetry and from information available on disk. Essentially, we are
already unintentionally leaking information about private browsing usage.


When some measurements include private and non-private sessions while
others only include non-private sessions, the difference between the two
approaches allows us to infer information about users’ private browsing.
While we can fix this on a case-by-case basis as we identify instances of
non-compliance, our expectation is that this leakage will continue so long
as we continue to special case PBM instrumentation.

This means that our policy with regards to the instrumentation of whether a
private window has been used isn’t enforceable in practical terms.


1.

Over the years, nobody has managed to put forth a convincing threat
model that actually requires us to avoid instrumenting the usage of a
private window. Every scenario we have looked at has been making contrived
assumptions about what the local attacker is willing/able to do (e.g. they
have full access to the user’s computer over an extended period of time,
but they are unable to install any spying software on their machine). In
other words, it has always been unclear what we gain from persevering in
maintaining this part of our policies around private browsing.

2.

Finally, even when we have clarity and consistency regarding this
policy, this still results in a large gap in knowledge about our own user
base. Privacy is a key part of our mission and our business strategy and we
think it is a key reason users come to Firefox. But we don’t actually
know and we have no insight into the usage patterns of PBM. This makes it
difficult for us to know whether we are actually being successful and for
us to make informed resource decisions for private and security features
like the Facebook Container[2], Firefox Monitor[3], and our upcoming
series of anti-tracking features[4]. It also makes it hard to argue for
more investment in privacy features as we typically lack important data to
demonstrate that people find one of our largest existing privacy features
useful.


Change to the policy

================

As a policy, we are going to stop special-casing private browsing
measurement and plan to instrument it directly. This means that going
forward, we will no longer avoid instrumenting the fact that the user has
used a private window in a session. This is a minor change that will allow
us to know the fact of whether private browsing is used. It does not
include changes to the key properties of private browsing - that the user’s
browsing activity is hidden from the local adversary, and the anti-tracking
features that come with it. We do not collect user browsing history in
regular mode or in private browsing, so that property will be maintained
and private browsing history will still not be available to local
adversaries. As always, users will be able to turn off our data collection
through the existing controls exposed in Preferences.

If you read this far, thanks for your attention. I hope this change
enables us to measure private browsing more effectively and enable Mozilla
to bring more features and improvements to this area in the years ahead!

Cheers,

Ehsan


[1] https://wiki.mozilla.org/Private_Browsing

[2] https://addons.mozilla.org/en-US/firefox/addon/facebook-container/

[3]
https://blog.mozilla.org/futurereleases/2018/06/25/testing-firefox-monitor-a-new-security-tool/

[4]
https://blog.mozilla.org/futurereleases/2018/08/30/changing-our-approach-to-anti-tracking/

[Georg Link]

Hi Ehsan,

+1
The change sounds reasonable and your account of failures and benefits is
convincing.

I am a regular user of the private window and have no concerns regarding
the change affecting my use cases.

Best,
Georg

> _______________________________________________
> governance mailing list
> gover...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/governance
>

[lcr...@mozilla.com]

Thank you for the thoughtful, thorough, and proactive notification!

[Rubén Martín]

Ehsan, thanks for this information and congratulations for explaining
the background, implications and how the decision was made. For me this
is a clear example of good communication.

Did we run this rationale in advance with other community groups and
experts just in case we are missing anything? (or should this email be
considered that? :P)

Thanks.

El 14/09/18 a las 17:47, Ehsan Akhgari via governance escribió:

> _______________________________________________
> governance mailing list
> gover...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/governance

--
Rubén Martín [Nukeador]
Mozilla Reps Mentor
http://www.mozilla-hispano.org
http://twitter.com/mozilla_hispano
http://facebook.com/mozillahispano

[Ehsan Akhgari]

Hi Rubén,

On Fri, Sep 21, 2018 at 11:34 AM Rubén Martín <nuke...@mozilla-hispano.org>
wrote:

> Ehsan, thanks for this information and congratulations for explaining
> the background, implications and how the decision was made. For me this
> is a clear example of good communication.
>

Thanks!

> Did we run this rationale in advance with other community groups and
> experts just in case we are missing anything? (or should this email be
> considered that? :P)
>

No, I wasn't aware of any other community groups to consult before deciding
to go ahead with the change, since we hadn't done that in the past. But I
considered it important to document the background and reasons for this
decision and to communicate it publicly and the best forum I was aware of
for doing that was this mailing list, hence the current thread. :-) I
hope this email has managed to serve that purpose.

Cheers,
Ehsan

--
Ehsan