Re: [PING] ad hoc private browsing mode call - summary

> While not wanting to dwell too much on the specific examples here, I think it would be valuable for whatever document PING eventually produces to contain real examples that map back to a posited threat model. That can give specification authors inspiration for their own privacy challenges, on the one hand, and makes the threat model more concretely understandable on the other.

I see.  Well, I think the original examples serve that purpose then, no?  Presenting different trade offs on a capability / privacy tradeoff curve?  Beyond the previous timer resolution, Web Audio and Web GL examples, enabling / disabling canvas read-back, resolution / accuracy of values returned by APIs like device memory, system concurrency, battery life and enumerable media devices, performance / accuracy of SVG related endpoints used for certain types of font enumeration attempts, etc etc etc.

I don't (at least in this email ;) ) mean to endorse any one of the above examples.  But they all seem like places where
 1) many vendors deviate from the standard for privacy preserving reasons
 2) it would be good for web compatibility reasons if the range of these deviations was reduced, as much as possible
 3) since thats basically describing what standardization is all about, lets make that part of the standardization process too
 4) Let's call them “alternate routes through the standard” instead of “deviations”, and we can indicate that by whatever this document ends up being called (if folks agree to it).

"Private Browsing mode" is confusing and already-overloaded term, so that might have been a bad choice for this effort.  Pranjal had several suggestions like “heightened privacy mode”, or “increased privacy” mode.  With the implication that, vendors might take these alt paths through the standards when in their respective “Private Browsing” / “Incognito” mode, or maybe all the time (TBB, Brave, etc)

> Defining a common term is a great thing to do, and giving specification authors the ability to have an explicit conditional when writing algorithms is great too. I fear, though, that you're not going to get away from a million permission dials, or handwavey recommendations, if you don't define the term in a way that embeds it with purpose. That is, if we can say that a browser's privacy mode has specific goals, and aims to defend users against specific kinds of threats, then we can do a better job as authors and designers when making recommendations.
> 
> For instance, it seems fairly well agreed-upon that browsers' privacy modes ought to defend against after-the-fact inspection of the user's behavior while in that mode. To that end, we generally don't store history locally, we don't alter autofill databases locally, we build alternative storage mechanisms that don't touch the disk, etc. That goal of privacy with regard to the local device drives implementation decisions that it would be good to discuss, and good to point authors to. Defining those overarching goals seems like work that would be well worth doing.

I take your point here Mike, and you put it clearer than I do, as usual :).  The common goal in these changes is to increase the privacy of browsing on the web _between the server(s) and the client_, and at a high level aiming for the goal of websites not being able to identify the user without the user’s intent.  Not all vendors have this goal, and among the vendors with this goal i'm sure there are differences at the edges, but many vendors are demonstrably pursuing this goal, and so standardizing as much of those efforts, among the parties pursing them, as possible seems valuable.

And, I would also welcome any further discussion to solidify / codify this goal, with any parties that are interested.  I only mean that I don’t think that difference is a blocking point for the larger goal here.

And, last, Mike, just thanks again for the comments above, I think they're extremely helpful in thinking through / tightening up the ideas in the doc.  Much appreciated!

Pete

Received on Friday, 22 February 2019 19:22:32 UTC