<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.
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
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/90%/95%/ Present: weiler wseltzer pes pranjal christine jnovak craig mnot npdoty No ScribeNick specified. Guessing ScribeNick: christine Inferring Scribes: christine WARNING: No "Topic:" lines found. WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 15 Jan 2019 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.)[End of scribe.perl diagnostic output]