Re: some links on private browsing mode text

Sorry I couldn’t join…

There are various aspects to private browsing mode, and only some are amenable to standardization (though it’s fine to cover some of the rest in a “things to think about” advisory manner). Notably
* what happens locally on your UA (cookie cache initialization and management, local storage, user-interface, history retention, and so on)
* what does your UA communicate (HTTP headers, cookies sent, any indication of being in PBM, etc.)
* on-network behavior (how strongly is HTTPS suggested/enforced to protect you from network spoofing? what about CDNs, proxies, etc.?)
* server reaction/behavior (if any, if aware, and so on)
* server suggestion (this site covers sensitive topics such as medical advice, spousal abuse, etc., and you may wish to be private while here; though there are abuse possibilities)
* can a user return to a specific private session
?


I think we should work on teasing these apart.

As you know, the idea of a signal was discussed several years ago at TPAC, and the feeling was that a single bit may not be enough, as it leaves it unclear what the relationship of consecutive HTTP requests might be, for example. Since Amazon has joined W3C, the focused question “how would you like to handle a ‘private purchase’ (e.g. of a birthday gift for a spouse)?” might we worth having.

It’s not hard to hypothesize a well-known resource or HTTP header that suggests that a site is private, but we’d need to deal with the abuse possibilities.


> On Dec 6, 2018, at 18:06 , Nick Doty <npdoty@ischool.berkeley.edu> wrote:
> 
> Nice chatting briefly today with you all regarding private browsing modes and what it could be useful to standardize.
> 
> In terms of providing some existing resources for use in Pete’s drafting, I referred to this text sketch from Mark Nottingham, from 2016:
> https://gist.github.com/mnot/96440a5ca74fcf328d23
> 
> I think the approach of describing different kinds of controls — site data controls, local data controls, network data controls — based on the threat model and response they provide is useful because we might not always see a singular private browsing modal option, and it could be useful feedback for designers of new features to consider the impacts of different kinds of controls. For example, I don’t think any prominent browsers are currently applying network anonymity features in their respective private browsing modes (though Opera is including a VPN with some anonymizing features), but it’s useful to consider how local/private IP addresses can be revealed through Web features, specifically because some users are going to use anonymizing proxies. There might both be a common definition of private browsing mode features and still utility in separating out different kinds of controls that apply to different threats for reference elsewhere.
> 
> I hope Mark will be able to join us for a future call, or he might have opinions to share on this text on-list. 
> 
> 
> Also, we also had a useful talk/discussion with researchers who had reviewed the common user confusion regarding explanations of private browsing modes back in September.
> 
> Minutes: https://www.w3.org/2018/09/10-privacy-minutes.html
> Paper from WWW 2018: https://www.blaseur.com/papers/www18privatebrowsing.pdf
> Reviewing that discussion reminds me that there was some consideration of standardizing terminology of private browsing modes to try to help address that user confusion, or even to reduce stigma regarding the use of (“shared device mode” rather than “private browsing”).
> 
> And regarding signaling to the page, there has also been the suggestion that sites may want to know that a user is in private browsing mode to provide advice to the user or change their functionality to help them with the threat model of a local attacker — that online services that help survivors of domestic violence, for example, might want to detect use of that mode and help explain how to clear browser history and other local data.
> 
> —Nick

David Singer
Manager, Software Standards, Apple Inc.

Received on Friday, 7 December 2018 18:49:32 UTC