Hi Rubén, On Fri, Sep 21, 2018 at 11:34 AM Rubén Martín <nukea...@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 > > El 14/09/18 a las 17:47, Ehsan Akhgari via governance escribió: > > 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/ > > _______________________________________________ > > governance mailing list > > governance@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 _______________________________________________ governance mailing list governance@lists.mozilla.org https://lists.mozilla.org/listinfo/governance
