Some thoughts forming here, feedback appreciated: https://gist.github.com/mnot/96440a5ca74fcf328d23

A few thoughts:

Some issues that may or may not be worth mentioning:

• blocking of content, and various motivations for doing so (e.g., privacy, perfomance, visual annoyance)
• some of the distinction in terms of what is and isn't cleared by Clear Site Data have to do with what sites can store and retrieve without user interaction. For example, we don't want to clear saved passwords and (I think) form autofill history by default, both because users would miss those more, and because they can't be used like a cookie.

I think the "network data controls" section is particularly vague; it could definitely use examples.

I think there are a few places where the terms "(site/local/network) data controls" are crossed (e.g., at the end of the Site Data Controls section, and maybe in the Appendix).

I wonder whether the "Should my feature..." section should differentiate better between the password case and the cookie case I mentioned above.

Also, in the same section, what sort of interaction with user data controls should features that aren't compatible with Privileged Contexts define?

I think content blocking is out of scope for this document, based on the definition of 'user data'.

User interaction as a way to distinguish types of data is useful; will try to work it in.

Thanks!

See w3c/presentation-api#275.

FYI @mnot some discussion here at the web payment wg f2f, in the response to the response to the security & privacy self-review, on desirable behavior when the user is in "incognito mode". Underscores the potential need for some kind of standard definition of what a browser private mode is...

discussed at the Stockholm f2f... adding @torgo to this.

The Web Payment API's review feedback for our question on incognito mode, and follow-up discussion.

https://lists.w3.org/Archives/Public/public-payments-wg/2016Jul/att-0013/WebpaymentsAPISecurityandPrivacyChecklist.pdf

3.14 How should this specification work in the context of a user agent’s "incognito" mode?

We anticipate that user agents will offer users the ability to grant specific web sites persistent permission to access payment information. This will facilitate user experiences such as “one click” product ordering and automated micropayments.

Recommendation

When operating in an “incognito” mode, we would expect the Payment Request API to remain available; however, we recommend that any such persistent permission be ignored in such a mode (otherwise, websites with such persistent permission would be able to identify users via their payment details). The user agent would still make stored user information available -- similar to how the web browser assists in filling out form information even when incognito; however, such information would be inaccessible to the merchant web site until submitted by the user. Assistance is expected, automation is not.

When operating in incognito mode, it is probably also advisable to take additional steps, possibly at the expense of usability, to frustrate attempts to determine whether the user has registered payment apps that support specific payment methods. For example, always prompting the user when a payment request is made, even if there are no matching payment apps available, may serve such a purpose. Note, however, that this would need careful consideration, as web sites might determine from such behavior that the user is browsing in an incognito context.

When the Payment Request API is invoked in an incognito context, we suggest that any web-based payment apps also be invoked in an incognito context. This will generally prevent such sites from accessing any previously-stored information; this, in turn, will require users to either log in to the payment app or re-enter payment instrument details.

The Payment Request API specification should thus include discussion on browser behavior in incognito mode.

From: http://www.w3.org/2016/07/07-wpwg-minutes#item07

3.14 How should this specification work in the context of a user agent’s "incognito" mode? AdamR: We think the api should work in incognito mode ... but since we've talked about the ability to grant permission to get a 1-click experience ... obviously that has some privacy implications especially in incognito mode ... the recommendation is that the stored information be available but to suggest user confirmation (e.g., that you will be unmasked from incognito mode) [Review of existing incognito mode] NickS: Apple Pay - We don't disclose information to the site that payment methods are available when in incognito mode zkoch: I think the best model we have here is autofill...you still have the information you had, but we don't save NEW information ... I think what NickS says is about third party apps...and I agree we need to think hard about incognito mode adamR: Sites should not be able to easily know that a user is operating in incognito mode ... there may also be ways to figure out what's going on (e.g., time required for a promise to return) ... we also recommend that the web payment app operates in incognito mode as well ... we recommend that text be brought into the payment request API spec ... in some form <ShaneM> is there a generic term for "incognito mode" that is used in the W3C specs (I don't know) danielappelquist: There is no standard definition of a private browsing mode ... we wonder whether there should be such a definition <ShaneM> hey wendy - have your groupps define that for us, would you? 3.16 Does this specification have a "Security Considerations" and "Privacy Considerations" section? AdamR: We think all the docs should have privacy/security considerations sections ... we do call out that the PMI spec should point to the security section of the URI spec ... so we need to augment privacy/security sections of the docs larger <dka> TAG open issue on private modes: https://github.com/w3ctag/spec-reviews/issues/101 (just FYI)

And here's the actual question in the security questionnaire: https://w3ctag.github.io/security-questionnaire/#incognito

So... wondering if we can rephrase this question or drop it? What is it really asking?

Discussed at Tokyo F2F. @dbaron agreed to do some additional polling of browser vendors to ask about what would be useful here.

Discussed at the F2F in Boston: https://pad.w3ctag.org/p/2017-02-08-minutes.md

Action: @dbaron to research specs that would like dependencies on or a different behaviour in a privacy mode; @hadleybeeman to prepare draft blog post and return to the TAG for review.

Discussed in Tokyo F2F with special guest @tagawa. Notes here: https://pad.w3ctag.org/p/2017-04-28-minutes.md

Some agreement that we should continue work on a document - need to figure out where that could live. Hadley to report back on 5-16.

@hadleybeeman working on a blog post.

👍 Let me know if you need any input or proofreading for that.

Would be happy to help, and incorporate the suggested (not yet 'proposed') way to signal to servers "hey, I am trying to be somewhat private here!"

Likewise happy to help / give feedback / context / etc.

Noticed probably an issue, accept-language header request in private mode with tracking protection enabled is sending information about users preferred languages.

While in w3ctag drafts "Browsers in private mode MUST NOT emit any of the following request header fields: Accept, Accept-Language," etc.

Seems like Accept should perhaps have its defaults rather than be missing. For example, browsers currently send different Accept headers when loading the toplevel page vs. when loading images or videos.

Discussed at London f2f.

(Is this the right thread?) In connection with Private Browsing Mode, we have suggested

• that it not be confused with an attempt to be anonymous (which is different and harder)
• that users think servers know and might respect the request (they don't)
• that users think that they're private on the network (using plain http and not https should be warned about, perhaps)
• that sites might like to be able to say "this is sensitive, you might like to be in a private context" (e.g. health-care, spousal abuse help, and so on)
• that people should be able to keep their 'personae' separate (work, home+family, hobbies) and not have work-related ads bleed into their home life, or hobby-related-ads show at work, hence the proposal for the persona header

Just updating this at our TAG face-to-face in Paris, since the topic came up in multiple places at TPAC last week.

At WebAppSec's meeting on Tuesday, @wanderview stated that Web Platform WG had wanted a normative private browsing spec to reference when designing their own features. It looks like W3C and WebAppSec are looking at creating a privacy working group. (pinging @wseltzer @mikewest to fill in any gaps there)

Also, PiNG met on Friday, and discussed whether private browsing is best addressed with normative specs (which would need a working group. Options include rechartering/expanding WebAppSec or creating that privacy working group) or non-normative notes and requirements, which could be done from an interest group or community group. @samuelweiler and @snyderp were going to investigate those.

To all tagged here, please let us know if/how we can help!

@samuelweiler sorry to pull on your patience again, but whats the best way forward here. Can you point me in the right direction? (promise I'll kick the training wheels off soon)

Also of interest https://github.com/w3ctag/private-mode

Discussed during telecon on 15.01.19. We're not standardising it this week.

Breakout session for the f2f.

Hi all,

@lknik is working on text for a possible new TAG finding on this topic. Given that, I'd like to close this issue. Interested parties are encouraged to raise issues on his document once he has a draft up.