Privacy Interest Group Teleconference -- 15 Jan 2019

<weiler> christine: did people see news re: GoDaddy and Navigation TIming?

<mnot> I don't have a W3C login any more, apparently

<mnot> ... so I can't use the webbed.

<mnot> webex.

GoDaddy - https://www.techrepublic.com/article/godaddy-injecting-site-breaking-javascript-into-customer-websites-heres-a-fix/

Mark, Sam is sending link

<mnot> thx

craig s is also present as call in

Pete is going over his draft (see email)

<weiler> pes: goals of doc: recognize that there are modes intended to give more private, to give other spec authors something to link to

this is an ad hoc PING meeting about private browsing

<weiler> ... and give spec authors a way to suggest more privacy-preserving behavior.

(handing over to Sam)

<weiler> .... so when user gives a signal that they want more privacy, here is a direction to go.

<weiler> ... third goal is some commonality in how DOM is modified in these modes.

<weiler> ... fourth goal is to have somethign to add to questionaire, to give a more actionable "have you thought about how functionality could be changed in the face of an affirmative signal from human"

<weiler> mnot: the doc seems reasonabe, but not actionable. what's group's thinking re: my old proposal?

<weiler> pes: I'm new. tell me the history? my understanding is that past efforts tried to standardize what browsers do in these modes, and so this is targetted more at spec authors than browsers authors

<mnot> https://gist.github.com/mnot/96440a5ca74fcf328d23

<weiler> mnot: I agree - defining one form of the mode is probably too ambitious.

<weiler> pes: I'll look at this. if it seems to overlap... what do you think?

<weiler> mnot: roughly the same track. read it. email.

<weiler> christine: mark, would you walk us through your thinking in that doc?

<weiler> mnot: @@ then-active browser vendors had discussion - concluded there was enough differentiation and experimentation that it would not be useful to std'ize private mode, but we could try to create hooks for specs to point to.

<weiler> ... if broswer has a mode that touches the hook, treat data in a particular way.. e.g. site-related data - e.g. cookies. and local data control.

<weiler> .... caching, history. and network data controls - fingerprinting surface area

<weiler> ... framework more for spec authors than browsers

<weiler> npdoty: I think the breaking this up into three groups, as mark did, is promising. single privacy concept is harder. different threat model split is more actionable.

<weiler> mnot: one think I like about this is that we don't strong buy-in from browser vendors. this is more achievable.

<weiler> pes: I feel less excited re: specific threat model. moving target - hard to codify. those are more likely to be bespoke conversations per standard.

<weiler> npdoty: i'm suggesting this as less of a moving target than "all of privacy".

<weiler> ... some classification of threats, even if not specific....

<weiler> jnovak: 2-3 pieces: 1) there is an important piece not being fully communicated - some browsers will only be in private mode (e.g. Tor browser bundle). that makes this proposal slightly different.

<weiler> ... I'm trying to stay away from "mode" and "signal". good to target toward spec authors - to create something @2.

<weiler> ... I worry - and don't have a way out - do we risk undermining privacy by default byt saying there is this private mode?

<weiler> ... Maybe mitigate that given browsers always in private mode.... we should make sure we guard agasint undermining privacy by default

<weiler> pes: I appreciate jnovak's point. poltically and practically, that's a losing battle. easy out is "other vendors may do differently" is the current situation - which is to no one's benefit.

<weiler> ... anything is better than staus quo of saying "other vendors may do differently"

<weiler> jnovak: problem is that private mode as distinct from normal mode... do we instead need, instead of "mode", a new section of specs saying "here's how to implement this in the most privacy-friendly way"

<pes> pes+

<weiler> ... e.g. set your return value for "real name" to "j smith"

<weiler> pes: that would capture 95% of my goals for this doc.

<weiler> jnovak: anyone else want to share?

<weiler> christine: say "if you want to implement this in the most privacy-respecting way, here's how"... what are challenges in that?

<weiler> wseltzer: are there multiple points of baseline definition? "most privacy preserving", "acceptable in regular practice", @4, and "anti-privacy general practice".

<weiler> ... there's a danger that as we adopt a baseline that would be acceptable if anyone did it, it becomes "no privacy at all"

<weiler> pranjal: it might take spec authors some time to get their specs publushed, and that concerns me.

<pranjal> jnovak: Outsource the hightened privacy section to spec authors

Jason - I think you raise an interesting point - spec authors have deep subject matter expertise - e.g. Web Audio

we flag possible privacy issues and mitigations that may impact value of spec

weird distribution - they have knowledge of feature, we of privacy

if we told spec authors what they should consider for privacy in spec ... we cannot become as knowledgeable to enable functionality while privacy nobs

Pete: also political aspect - take the call last week - feature already implemented, make a standard - the mechanisms PING has to improve privacy are minor in that setting

could nudge - here is how you can do, and do more privacy

sam - are others willing to sign on as a co-author and move text along?

Nick cannot co-author, but questions

yes from pranjal

nick - not sure if what feasible for recommendations, curious what it is and how we can do it?

pete - have a privacy standard implementation - public broadcast of common set

nick - really helpful, I like that idea, did not understand from document

how different from a progressive approach? what would we say different for users in private mode?

pete - web authors build sites assuming features exist and functionality, but a web that did not assume would be a better one

jason - I think I thing that would help (I can't sign up to be co-author, but edits and commentary and informal assistance) .. help move document along and address the questions - a concrete example, here is a site that calls an API that if in private browsing mode, don't want in stock .. instead this is what it would want it to be

read name api example was helpful, but a concrete example would be helpful

to focus discussion and what document is

christine agrees

nick - hypothetical is useful, but a real example of an API that have demonstrated restricted mode or functionality ... not really follow hypothetical..

give specific examples when we can

pete - I can write 2 - resolution for timers and canvas readback

APIs that frequently have modified behaviour

jason - both good examples

pete - I can write those up, temperature of the room

should we make the document more formal?

jason - there is a doc that is valuable - next step get examples out then revisit what we want the document to be - 2 options: here are settings for browser in private mode or here are privacy default settings

wendy - great to have locus for discussion - put in Github and invite pull requests as a way to contribute would be helpful ...

christine agrees with jason

Pete will send examples over email list and then we will set up a call and decide best approach (also while looking at Mark's document)

christine - okay with me

Sam saying put in Github now

jason - thank you Pete for driving the conversation, leading on this

- DRAFT -

Privacy Interest Group Teleconference

15 Jan 2019

Attendees

Contents

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output