<weiler> present=

Update from pes:

Status from last priv mode call: general agreement on having doc for standard "priv browsing mode"

Ques: should this be advertised explicitly (like DNT) or better to be passivelty learnable based on how endpoints behave

Adv for publishing: could give guidance on expectations for what priv browsing mode might be

Common subset of behaviors across browsers

Webdev could target things for PrivBrowMode

No document yet, is planning

weiler: this group likely in support of notion of publishing this; we can start it within PING

(No objections from group)

Text writers?

moneill; pes;

<moneill> +q

moneill: I argue against broadcasting this mode; I don't think there should be a header signal -- encourages sites to go out of that mode on the site

(e.g.. Boston Globe)

<npdoty> those existing examples are cases where there isn’t a header signal, but the sites are already choosing to detect and respond

moneill: no inhibiting of tracking in that case

novak: I think plan is not to standardize PrivMode behavior itself
... more to say "there is a thing called PrivBrow -- browsers may change what they do in that mode"
... from last call: sites already have detection for this today; given the set of tradeoffs...browsers will change behavior of APIs..shouldn't sites know that so they can respond accordingly

moneill: but what if they do not respond appropriately? I would like to see "privacy mode" be a thing people could use (e.g., time-limited cookies)

novak: when I say "sites respond", I don't mean changing cookie policy, etc. Maybe this should be called "API breakage mode"

Browser is changing from usual mode, trying to communicate this

pes: sounds right, need some discussion of what the goals are for API

<wseltzer> +1 to punt on the signaling of mode

pes: we can likely punt this

<npdoty> +1 to documenting the arguments and moving on

<weiler> a?

pes: we are not trying to define what browsers do in PrivBrowMode
... goal: all browsers have this mode; users have privacy goals; browsers may do this differently
... browsers could have common subset of behaviors; web developers could break fewer things in that mode

weiler: might want to wait on any kind of signal -- first need to look at the space

<Zakim> npdoty, you wanted to look at interaction with controls that aren’t all-or-nothing private mode

npdoty: I agree that the signal is not the most important bit
... are we talking about singular mode? Might not be binary -- in mode or out of it.

But there may be other modes: in mode all the time; container mode; change according to user's threat model

Users might want privacy from network, or on device, or from specific site...

There is going to be a lot of interaction with other specs to take into account

<moneill> +q

User might want different controls at different times -- see mnot's document

Not one mode for all privacy

moneill: too many things being rolled into one concept. Difference between knowing devices-specific activity & web tracking is large.
... we might try to get consensus about what we are talking about

<npdoty> draft doc from mnot, regarding site data controls, local data controls and network data controls https://gist.github.com/mnot/96440a5ca74fcf328d23

weiler: what do you think about different modes?

(for pes)

pes: splitting it out makes it hard to standardize; would like to punt on the flag for now

<npdoty> Firefox Containers is not binary, for what it’s worth, and the binary modes of other browsers all do different things from one another

<pes> +q

runnegar: pes said currently implementations are binary now -- people from public interest community might be interested in testing these ideas in the wild

There was a DuckDuckGo study recently

<wseltzer> https://spreadprivacy.com/google-filter-bubble-study/

Pes: goal is not to say "this is what browsers should do in PBM" -- it is to say that browsers have a mode and here is how one should respond to it

<wseltzer> ^ DuckDuckGo study

<pes> +q

weiler: we need not include public interest community testing in the doc; they can play with it anyhow
... restating scope: want to document roughly what PBM is, without standardizing it, so other specs can suggest how they could operate differently when browser in is that mode which may be different.

We are not mandating a signal, not ruling it out but not leading on that either.

moneill: so, write down what we have at the moment, what browsers do (by and large)?

pes: no -- not what I think, that's documented.
... my goal: browsers want to protect privacy in different ways, but there isn't much commonality
... want doc -- saying users want privacy, some modes break standards/functionality to provide this

<moneill> +q

pes: so can we find a way to address this

weiler: so, maybe we need to see this written down?

(for clarity)

moneill: I am opposed to the idea that users have to initiate/take effort to go into private mode
... but there are special characteristics of the mode, which someone might decide they want is "extra" beyond baseline

<npdoty> whether it’s a mode or not, it might be useful for specs to be able to handle behavior when data is ephemeral or cross-origin communication is limited

moneill: such as prematurely-aged cookies. Am worried that this sets things up as "privacy as exception"

wseltzer: on my Internet, privacy is not expected! But want to allow this as possibility for users, what they can attain.

(not expected as default)

Philosophical discussion (cultural differences, etc) not likely to be resolved here, don't need to to progress this effort

weiler: want to encourage folks to go and write

pes: I am happy to write up first version of this; this is not first effort, from what I can tell
... any links that I can use?

(mnot link in IRC)

moneill: would be good to have doc to use to start debate

<scribe> New folks?

Bennett: I wanted to listen; planning to attend more regularly

Org? From EFF, developer on Privacy Badger

Hannah: with CDT, working with Joe Hall, new to calls, planning to be regular attendee

Steve E: from Mozilla, seemed like interesting topic, will figure out how to contribute

weiler: next call is Dec 20. Often we do privacy reviews on calls, as group; everybody here welcome to participate

<Zakim> christine, you wanted to discuss scheduling a call for people in different time zone (e.g. Mark N)

Let us know how we can help you!

runnegar: would like mnot to also participate but timezone was impossible; can we find a good time?

Mike/Pete/Jason might like to talk to mnot early on; good time is AU time..

Christine can help coordinate this

Plan: have a call and then start writing

Also might want to try to include Hadley (UK time)

So...we will convene on Dec 20 as large group

scribe: meeting adjourned

<weiler> rrsagent+ draft mintues

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/to punt/to punt on the signaling of mode/
Present: plh weiler npdoty tara moneill christine pranjal jnovak brentz SergeyKanzhelev DavidC PeteSnyder wseltzer pes BennettCyphers StevenEnglehardt Arthur runnegar Hannah
No ScribeNick specified.  Guessing ScribeNick: tara
Inferring Scribes: tara

WARNING: No "Topic:" lines found.


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 06 Dec 2018
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)