Privacy Interest Group Teleconference -- 26 Oct 2018

<weiler> meeting: Privacy Interest Group F2F at TPAC 2018

<Judy-Zhu> would you like to copy the agenda link here? thanks so much

<tara> https://docs.google.com/document/d/1aYGCfXkY5pOtyOFR8bWvrobYNSDhCxQ43SdfJ5OQFAs/edit#

<inserted> scribenick: jnovak

<tara> (Agenda)

tara: Agenda. Been bashing for some time. If there are missing items that need to be juggled around, let's figure it out
... no objections, going to first item

<wseltzer> #

weiler: Given the wide spread of people in the room, as we add features to web, question of "should we add the feature to the web"

<wseltzer> Permissions Workshop agenda

weiler: nick doty wrote up some notes on this that are on the permissions ws list.
... those notes will go into questionnaire
... browsers want freedom in UI, will take input but will make their own decisions
... discussions of prompting.
... file picker as an implicit permission
... installation as a metric -- casual visiting versus installing
... engagement as a metric - shot that down
... point 3: what's changed in the last five-ish years. there had been a permissions workshop in 2014.
... one of the changes was the rise in ad blocking
... led to an interesting conversation between the folks in advertising and others
... discussion of an advertising identifier; user could change. idea was that ad id would mitigate fingerprinting needs
... other thing that has changed in the last five years is users have less trust in the web
... some of that is cambridge analytica
... point 4: users don't understand the risk -- and we don't either
... Don't think have to go into that here.
... VR/AR/XR was a particularly interesting set of risk -- full camera data of room you're in
... that group has done some privacy analysis. the person doing that may show up here today.
... follow up items out of workshop are somewhat limitied
... write up on new permissions and should we add them
... suggestion of research around browser UI
... most of the other stuff got shipped off elsewhere -- changes to OAUTH
... those are the high level notes

<Zakim> glazou, you wanted to ask about permissions

<weiler> acl gla

glazou: question: did you discuss the permissions model? complex applications request permissions, up to 18. model goes into separate details. is it possible to explain to the user? single dialog is too small / too complex

moneill: yes, that was brought up

weiler: there was discussion of how to avoid asking; understood that there is annoyance with the prompting
... discussion of how to avoid anti-patterns like prompting immediately
... don't prompt for camera the moment you land on the site, but, instead, prompting when there's a user action

<mkwst> jnovak: One takeaway from the workshop is that the timing and duration of a permission should be inversely proportional to the power of the permission.

<mkwst> glazou: That might work for the web, but does not work for web extensions.

<mkwst> ... Extensions can access everything, don't depend on loading a webpage.

thanks mike for scribing while I was talking

weiler: think that users go through a different process to install app or extension
... is that a different enough process that you can scare users

<wseltzer> [Nick's Adding another permission? A guide, https://lists.w3.org/Archives/Public/public-2018-permissions-ws/2018Oct/0000.html]

moneill: weakness in the permissions API. seems like nothing happening there.
... device and sensors group thinks that there needs to be a general way to ask for permission
... stuck in a no-mans-land
... there's limitation in the permissions API and way they are used in geolocation, notification, etc.
... hard for sites to declare who they are and why they need the data. requirement of gdpr
... general idea of ability to revoke permissions
... if can give permission via API, there should be a way to revoke API.
... way to specify permissions for a duration period of time

weiler: mkwst want to talk about permissions API?

mkwst: there is a permissions API. it is limited. Firefox shipped it then clawed it back. Chrome has an implementation behind a flag. don't have knowledge of why the decision to pull it back was made.
... should be more powerful than it currently is

weiler: couple of sticking points: having the site be able to request that the user be asked supports some of the anti-patterns; also doesn't support some of the browser models where things might change (permissions might time out)

moneill: there is a promise in the permissions API

<mkwst> jnovak: Two additional points regarding the workshop:

<mkwst> ... 1. In the discussion around what's changed, some folks pointed to the regulatory landscape. Also a change in the advertising industry expressed by folks in the room. They want an advertising ID.

<mkwst> ... I have feelings about it, think it's a bad idea.

<mkwst> ... 2. "Browsers, can you please provide native UI for all the regulatory dialogs you see on the web."

<mkwst> ... In that conversation, ad folks made the statement that "If browsers supported this kind of UI, then we'd support the user's decisions."

<mkwst> ... They'd honor a one-time request, they'd honor decisions wrapped up in choice of user agent (Brave).

<mkwst> ... That discussion drove the notion around user research.

<mkwst> ... Third-party web content driving browser UI. Are there risks there?

mkwst: this goes back to something that mike talked about yesterday, also in the dnt meeting.
... traditionally been a distrust of content from websites
... when websites ask for a thing and name themselves in a way that users understand, the principle there is totally reasonable, the practicality is more difficult.
... websites lie about everything all the time
... onbeforeunload used to say things before you leave a website; now hardcoded -- every limitation was abused.
... native browser UI more trusted by users
... makes it difficult to have a website express its desire for a capability
... not impossible but more difficult

pes: one issue that came up in webappsec is what to do about private browsing mode, should that get a different set of permissions?
... everyone ships a private/incognito mode
... should websites have different functionality

dsinger: on asking for permission, ask users for permission at the time that they're trying to do something -- but asking them at the time that they are doing something, so, notionally should be at a time when they are doing so.
... regarding user ids: there has been an idea where users want to separate out work self from personal self, or personal self from gift-shopping self. don't show gift related ads while at work or vice-versa
... aspects of privacy that are not anonymity and secrecy
... aspects of privacy that are respecting context

moneill: to follow up on what mkwst was saying regarding the user facing aspects
... sites having text and specifying who they are -- aspect of the lying is that websites are declaring something. once someone has said something there's a legal context
... suggestion that if a site specifies the reason for collecting data, then, that is recorded somewhere in the UA
... similar way with DNT and TPWG have a well-known resource where that's stored as a JSON resource
... gives user the ability to remember why they granted permission
... might be a way to isolate the user agent trustworthy issues

ack weiler:

weiler: one of the conversations we didn't have but should more of is "how can sites fail more gently"
... accept the no and do something useful still
... ran into a web conferencing application and if it didn't get camera access, wouldn't load
... want to find some way to encourage sites more generally to behave better

dsinger: have floated an alternative before -- if you give me access to this data, I agree to these rules
... regulators have a hard time regulating privacy but not broken promises

glazou: if you think that websites are going to avoid failing because ask for it
... going to be hard to argue for
... if a website asks for camera, want a stream of bytes
... if the user says no give a placeholder
... that way no website is ever going to fail

weiler: instead of failing give them something fake

<mkwst> jnovak: I agree with the point that if the user says "no", we should return a stream of 0 bytes.

<wseltzer> jnovak: agree that if user says no, don't return broken api but string of 0s

<mkwst> ... That's what iOS does. We return an empty array of contacts, etc.

<mkwst> ... Graceful failure.

<mkwst> weiler: Do browsers need to reimplement things to do that?

mkwst: yes, browsers would have to do something
... there was a conversation earlier about this notion of can store information int he browser about what they are storing and why and if that is a good decision or not
... for that to work need to distinguish between revokable and not revokable permissions
... revoking access to contacts doesn't really matter as have all my contacts
... versus camera where the ongoing data is broken
... need to distinguish between the way we grant permission and the proportion of the power of the permissions

<mkwst> jnovak: I think we're assuming the answer to the question "Who are we building privacy features for and why?"

<mkwst> ... Regulators have been a focus.

<mkwst> ... Regulatory enforcement is important and powerful.

<mkwst> ... But time consuming, uncertain, etc.

<mkwst> ... When building privacy features, should, instead of having the framework be "We should build this so regulators can enforce", should we instead focus on what we can do if/when regulators can't/won't step in.

<mkwst> moneill: Need to do both. We don't have the ability to stop things completely with technical measures.

<mkwst> ... Regulator might take time to get to it, but people know that the recording can take place.

<mkwst> ... Affects attacker's behaviog.

<mkwst> jnovak: Sure. Both.

<mkwst> ... But the question is the emphasis.

<mkwst> ... If we focus on the regulator, we're conceding too much.

<mkwst> ... The past ~5 years have shown that having that as a backstop is a very soft backstop.

<mkwst> weiler: See also: spam phone calls.

<mkwst> moneill: If I've made a promise, and it's easily detectable that I've broken it, that gives me pause.

<mkwst> wseltzer: Someone should have the tools to improve that privacy protection in the future. There are lots of things that I can't protect against myself.

<mkwst> ... Need to put levers into the ecosystem for regulators, researches, browser vendors to help protect.

<Zakim> wseltzer, you wanted to say another dimension is individual vs epidemiological protection

pes: encouraging sites to behave better in case of no; know that when users opt-in to private browsing or a privacy browser, having some force of numbers when private browsing mode is stronger forces sites to be better
... more people in a private mode forces sites to be better

weiler: having sites say "turn off private browser"

pes: better than users thinking they're private and not

weiler: think that we're done with this. should run with the "empty frame buffer idea"

dsinger: need a companion document to the questionnaire of what to do when a user says no

weiler: to the extent that we consider it a working group problem, a standards problem, should be in the questionnaire

mkwst: every browser has the ability to change their interface
... don't need it to be a standard
... chooses are better than buttons
... a chooser of "white noise"

weiler: maybe we should have someone tasked to collect the different ideas?
... do like the idea of a document to collect the ideas

<mkwst> jnovak: ~Two things to be done.

<mkwst> ... 1. Compile a list of things we'd like folks to be able to null out.

<mkwst> ... 2. File issues against those specs.

<mkwst> ... 3. File bugs against all the browsers to make that behavior reality.

<mkwst> ... Need ownership for each.

<mkwst> dsinger: Not just your own privacy. Camera permission includes the folks sitting behind you.

<mkwst> jnovak: I'll take an action to put something in the questionnaire regarding this as a mitigation.

tara: connected to this is "what we've seen in other meetings"

Items from other TPAC meetings

moneill: WebAppSec and Device/Sensors -- Permissions API -- another thing that came up was this session resumption fingerprinting in TLS 1.3
... someone pointed out that the clear site header might be a fix

mkwst: doesn't effect 1.3 but effects 1.2 because session tickets are one time use in 1.3
... not clear what clear site data would do given you have to connect to site
... probably not going to send the clear site data header
... in chrome, include the TLS data in network cache
... if site chooses to clear network data, then yes
... doesn't solve the attack
... attacker would need to clear the data

moneill: unless it could be done by the top level site

mkwst: it is origin based. don't allow other origins
... to clear data

<Zakim> jnovak, you wanted to comment on regulatory support

<mkwst> jnovak: In terms of things in other working groups:

<mkwst> ... Decentralized Identifier: New URL type that's globally unique, etc.

<mkwst> ... URIs called "DID".

<mkwst> ... Contain an authentication mechanism, key material, and service discovery.

<mkwst> ... Used in verifiable claims.

<mkwst> ... Use cases around identity management, access control.

<mkwst> ... Of interest to this group particularly, given the verifiable claims meeting a bit ago.

<mkwst> ... Workshop in December.

<mkwst> ... Aiming to charter a working group in February.

<mkwst> Client Hints: jnovak, mkwst, weiler, pes, etc. attended.

<mkwst> ... Good discussion.

<mkwst> ... Landed on "Can we split out the Client Hint channel from the hints themselves?"

<mkwst> ... Might be things to add to the specification

<mkwst> ... Note that UAs can lie.

<mkwst> ... Maybe not respect Feature Policy delegation to third-parties.

<mkwst> ... Hallway chat afterwards: does Feature Policy have HSTS-like supercookie risk?

<mkwst> ...DNT: dsinger, weiler, wseltzer, moneill, mkwst, etc attended.

<mkwst> ... Charter expired.

<mkwst> ... CR will be published as a Note.

<mkwst> ... Laws may require DNT? May require some signal.

<mkwst> ... ePrivacy text is under work.

<mkwst> ... Includes carveouts.

<mkwst> ... Browsers intervening.

<mkwst> ... Not creating a community group, as that might block progress in other venues.

<mkwst> ... Investigate paths forward. Right place to continue might be PING, Improving Web Advertising BG.

<mkwst> ... Should we pull DNT from browsers? Fingerprinting risk?

<mkwst> ... Strong opinions on both sides.

<mkwst> moneill: The ePrivacy text you mentioned around advertising carveouts is just a proposal, and won't last a millisecond in Parliment.

pes: won't keep discussing private browsing
... standards are referring to private browsing modes
... but without discussing / defining it
... seems like PING is the right group for that
... happy to lead up that effort

pranjal: in webappsec there was a discussion of tracking protection
... would PING as a group "own" tracking protection
... is this the right group or somewhere else

wseltzer: have a meeting with immersive
... earlier stages from gaming, GPU, maybe the web and network breakout?
... network operators trying to get hints from applications about their network usage
... network operators would really like web implementors to do some communication with the network about what they want out of their transport
... not clear if implementors are interested in that pathway
... has clear privacy implications
... what hints can be relied on safely
... concerns about that information being shared
... that work might be headed towards an interest group charter

moneill: what is going to happen with permissions API
... is that going to be taken on by webappsec
... is there a plan to look into it

mkwst: nothing has happened since tuesday

wseltzer: early stage effort -- ML on the web community group is meeting
... curious to see what they're thinking
... all sorts of privacy considerations

<wseltzer> Machine Learning for the Web Community Group Charter

Working well with other WGs

<mkwst> jnovak: 1. What are the goals of PING?

<mkwst> ... 2. How do we achieve those goals?

<mkwst> ... 3. How do we achieve those goals in other WGs?

<mkwst> ... "How can we make W3C as well-known for privacy as it is for a11y?"

<mkwst> ... Meeting with immersive web because they ran into us in the hallways.

<mkwst> ... Maybe we're being too reactive in our relationship with other WGs?

<mkwst> ... After the permissions workshop, we could have seen it coming, and engaged more proactively.

<mkwst> ... WoT is another example.

<mkwst> ... Haven't followed up with them effectively after initial outreach.

<mkwst> ... More proactive engagement with other working groups? "We see you're working on security/privacy! Can we attend your meeting? Can you attend ours?"

<mkwst> ... Waiting until there's a document feels like it might be too late.

<mkwst> moneill: Reactive mode makes it feel like a thankless task to go talk about privacy.

<mkwst> ... Puts us into a "badguy" role.

<mkwst> ... Should shift it into a positive role in the hopes of being helpful for privacy.

<mkwst> ... I'm interested in WebAppSec. CSP, how it could help privacy.

<mkwst> ... More proactive work, less criticism.

<mkwst> pes: From hallway meetings, folks want feedback, but it feels one-off.

<mkwst> ... Set of principles. Set of criteria to apply to their own work.

<mkwst> ... For example, "Fingerprintablility should never increase".

<mkwst> glazou: A model that worked well is the A11Y guidelines.

<mkwst> ... It's a document you can read, governments rely on it, and you can validate something.

<mkwst> ... It's a set of rules you can apply to give a certificate to a website, specification, etc.

<mkwst> ... That model works really well.

<mkwst> ... Ideal for horizontal review within the W3C.

<mkwst> dsinger: If you ask people about web a11y, they say "Go to the W3C."

<mkwst> ... I'd like the same to be true for privacy. We should be the center of excellence.

<mkwst> jnovak: What do we need to do for that to occur?

<mkwst> ... 1. No one from MS or Mozilla is here.

<mkwst> ... 2. We need to build out the documentation we're discussing.

<mkwst> ... 3. We need to rework how we work with other WGs.

<mkwst> ... Immersive Web security and privacy repository. I wrote an issue in it for the first time yesterday.

<mkwst> ... I don't think the person working on it has ever worked with PING.

<mkwst> ... Talked with @@ yesterday evening, about the questionnaire.

<mkwst> ... The TAG wants that filled out during design review.

<mkwst> ... TAG says folks should consult with PING early.

<mkwst> ... How do we work with folks before they hit the TAG, or shortly thereafter.

<mkwst> moneill: Can we come up with a tool that scans websites to validate privacy things?

<mkwst> wseltzer: We have some hooks in the process:

<mkwst> ... FPWD is sent out broadly. Can follow up on that with outreach to this group.

<mkwst> ... Rechartering is a time to reach out to groups for explicit relationships.

<mkwst> ... Might feed into a dashboard of new groups, new drafts.

<mkwst> ... Reach out to them before they explicitly ask for wide review.

<mkwst> tara: I can coordinate that with y'all.

<mkwst> ... What's the right way to do that given the amount of work and visibility we have?

<mkwst> ... Process question. Getting that going goes a long way towards making us more effective.

<Zakim> mkwst, you wanted to say something about browser's process.

<wseltzer> mkwst: chromium's process

mkwst: wseltzer talked about w3c process
... will talk about chromium's process
... generally speaking chromium and other browsers have moved to incubation process to prove reasonable before bringing to standards
... starting in incubation group
... means that what browsers ship maybe haven't gone through FPWD

<wseltzer> https://github.com/wicg

mkwst: instead gone through enough incubation to see they are the right solution, then, start shipping broadly or through origin trials
... entirely possibly that chrome is shipping things that have not touched a working group
... means that we have to be paying attention in WICG
... involving TAG in that process
... Chrome ships via intents -- send out an intent to implement to blink dev
... explainer document with problem that trying to solve and a proposal of what trying to solve

<wseltzer> https://github.com/w3ctag/design-reviews

mkwst: having conversations at the same time
... then have a TAG review
... have something that you think are willing to send to the TAG, you file a bug against W3c tag review repository

<wseltzer> TAG design review requests

mkwst: intent to ship: have a proposal, here's the feedback from other browsers, TAG

<wseltzer> TAG issue template

mkwst: blink API owners decide whether or not to ship
... means that at least for Chrome, the TAG is a good chokepoint for this kind of review
... blink review process means that the TAG will have seen

<wseltzer> [[note that TAG review template includes " - [ ] I have read and filled out the [Self-Review Questionnare on Security and Privacy](https://www.w3.org/TR/security-privacy-questionnaire/). The [assessment is here](url).

<wseltzer> ]]

mkwst: if you want to be hooked into the process, waiting until something in a WG is explicitly too late
... would be nice to be involved earlier
... chrome mechanism is to actively push things to the TAG
... this is probably a good thing

dsigner: tag shouldn't be reviewing for privacy but architecture

weiler: are they doing the same thing for accessibility?

wseltzer: no

tara: clear thing to have a discussion with the tAG
... takes action to go talk to TAG about hooking into their process

mkwst: to be more proactive, watching the TAG design review repo is a good way to catch that

weiler: to what extent are other browsers doing that

mkwst: samsung generally ships through the blink intent process

pes: brave generally is removing functionality from chromium
... if folks want to talk about what Brave is doing, not necessarily against doing so in a formal channel
... matter of finding the hours not organizational opposition per se

mkwst: not to say that chrome is good and other things are bad, but rather, there are things that don't ship through WGs; TAG is a good chokepoint

weiler: had been having some of these same thoughts around center of excellence around security as well; know that diverging as well
... does security review at the TAG review stage for blink be helpful?

mkwst: yes. more is better
... not sure TAG is best situated for sec and privacy review

weiler: getting folks involved sooner good?

mkwst: Chrome has an internal security/privacy process for things we ship; security process is more public -- have a team that looks at the intents to implement and intents to ship and make sure that give the former a thumbs up / down review

weiler: how often does thumbs down get listened to?

mkwst: hard to ship things where security and privacy haven't signed off
... if external web platform process flags something as particularly interesting, then, goes through an internal process
... if there are particular risks from legal etc. then have internal review too
... multilevel process depending on how interesting a thing is
... high order bit is that sec and privacy teams have rotation to review intents and feed those intents into reviews
... don't have a good way to feed those concerns back to TAG
... but do try to file issues against spec and or talk to author
... but author is often a google person trying to ship in chrome
... periodically the case that mozilla will create intents
... twitter bot that does a good job that collects various vendors
... apple and microsoft also have dashboards
... this bot will tweet when those dashboards flip

<wseltzer> IntentToShip Twitter bot

mkwst: if you are interested in this sort of thing, then, following that twitterbot is a reasonable thing to do
... it would be nice if we had a process that wasn't a bot

general discussion about how it would be nice to take the logic and implement it into a thing that isn't a bot but could instead work with w3c systems

wseltzer: sounds like a thing for strategy
... at what point in the process can we afford to engage?
... reason to get more folks into the room to give things a quick glance
... say yes, no, crazy feature, etc.
... for those features that appear to become likely to become parts of the platform, sooner we can give them solid input, the greater the ability to impact their development
... if we can gather people who can give those inputs early, strongly support that
... sounds like a good task
... to build a better collective dashboard
... add a privacy annotation to the things that matter

<Zakim> jnovak, you wanted to discuss recruiting

<wseltzer> ACTION: jnovak to recruit Mozilla and Microsoft folks

<trackbot> Created ACTION-18 - Recruit mozilla and microsoft folks [on Jason Novak - due 2018-11-02].

jnovak takes action to go get mozilla and microsoft here

<tara> on break until 11...

<tara> (30 min)

<pes> tara: DNS-over-HTTPS

DNS-over-HTTPS

<scribe> scribe: pes

UNKNOWN_SPEAKER: coming up in ICAN, bringing to PING for broader feedback
... s/ICAN/IEFT/g
... (background) DNS is currently plaintext DNS || TCP
... this is bad for privacy
... ISPs have been found embedding MACs / identifiers in queries (see 2018 NDSS workshop on DSN privacy)
... current areas of current dev: DNS over {TLS,HTTPS}
... see dnsprivacy.org for stats
... DNS over TLS: proposed 2016, updated 2018. Implementers incdue Cloudflare, quad9, cleanbrowsing. Android pie uses today
... DNS over HTTPS: RFC in 2018. Moz + Cloudflare did experiemnt. Found it slower in common case, worst case is better over HTTPS

<scribe> … (cont) Chrome: working on implementing behind a flag

UNKNOWN_SPEAKER: why DoH if DoT? Easier to deploy, more HTTPS infastructure, HTTP(2) improvements make it cost lower than one might thing
... s/thing/think/g
... DoT requires a fixed port, DoH doesn’t (DoH is mixed in with other HTTPS traffic, harder to identify / block)
... folks interested in DoH optimizations over HTTP server push, under consideration still
... DoH downsides: few players (vs standard DNS), allow user selected resolvers?, users opted into DoH?
... where from here? ICANN is considering DoT and DoH further. What does TPAC/W3C/PING think?

weiler: DoH is nice vs DoT bc of censorship evasion (kinda like domain fronting)
... nameserver discovery is a possible problem, split view DNS, other things are not quite worked out for DoH
... main privacy issue: consolidation
... and diff resolver than system uses

mkwst: Mozilla already used thier own DNS resolver, Chrome uses default

jnovak: diff issues 1. DNS versus DoT + DoH, 2. consolidation of DNS in general, 3. Firefox preferencing CF

weiler: first two are more important

mkwst: ChromeOS has its own DNS resolver, implementing DoH currently
... ChromeOS gives user option to change other DNS servers too

weiler: Neat that CF commits to not logging

moneill: How does DoH handle keys / connections (performance implications?)

mkwst: I dont think there is any diff from normal HTTPS

<tara> For illustrative purposes: https://developers.cloudflare.com/1.1.1.1/commitment-to-privacy/

jnovak: DoH has headers, so it adds new privacy risks that don’t exist over existing DNS

<weiler> https://tools.ietf.org/html/rfc8484#section-8

mkwst: check out the spec https://tools.ietf.org/html/rfc8484#section-8 for the details

tara: https://developers.cloudflare.com/1.1.1.1/commitment-to-privacy/ lists commitments for logging etc from CF

weiler: how concerns is mkwst about additional logging from DoH?

mkwst: DoH seems like a good privacy improvement vs ISP run DNS

<jnovak> https://mailarchive.ietf.org/arch/msg/doh/vHjITrOMhWSdrozGFe4-eGNMEJc

jnovak: IETF suggests seeing above to mitigate fingerprinting of DoH

<jnovak> * Set their Agent to 'DoH client', no matter what browser/library

<jnovak> * Do not pass non-essential HTTP headers (like language)

<jnovak> * Do not allow the DoH server to set cookies

<jnovak> * Ponder TLS sessions resumption data settings

<jnovak> * Think about all other ways in which HTTP can be tracked (HSTS?)

moneill: who (users?) configures DoH?

mkwst: users almost never configure DNS, defaults predominate

<tara> lunch break until 1:30

<tara> getting restarted after lunch...

<jnovak> scribe: jason

<jnovak> scribe: jnovak

(one day I'll learn my IRC nick)

Accept-CH

pes: goal of this discussion is to discuss headers that may have privacy implications and better understand them
... one of them is client-hints; talked about them on Wednesday. Other is partially motivated by privacy mode stuff -- what folks are doing with referer headers -- can we reach common ground? figure out where things stand at least

weiler: there's a handful here that know what you're talking about?
... and others that don't

pes: two that would be most useful to discuss are accept-ch and referer headers
... brave mucks with referer a lot, Firefox some, others ???

moneill: constrained by policy

mkwst: referer policy

<mkwst> jnovak: We've talked a bit about `Accept-CH`, let's have a conversation about `Referrer` first.

<mkwst> ... Do we all know what it is?

<mkwst> ... [crickets]

<mkwst> ... Different browsers handle it in different ways.

<mkwst> pes: Brave's policy for referrer headers:

<mkwst> ... We spoof the origin. We always say it's whatever's being requested.

<mkwst> ... Firefox drops the path in various cases.

<mkwst> jnovak: So if I visit B from A, the `referrer` header contains `B`.

<mkwst> pes: Yes.

<mkwst> ... Firefox sends the origin of the actual referer, but not the path.

safari - https://webkit.org/blog/8311/intelligent-tracking-prevention-2-0/ - In ITP 2.0, the referrer, if there is one, is downgraded to just the page’s origin for third party requests to domains that have been classified as possible trackers by ITP and have not received user interaction.

<mkwst> moneill_: Google Analytics uses the referrer header to identify traffic sources in terms of types.

<mkwst> ... Change the `referrer` header, you lose that.

<mkwst> pes: Not our users' concern.

mkwst: chrome does what the referer policy says it does
... follow the referer information that the site says to follow
... what do you do for origin headers and same site cookies and requests to do same site or cross site requests

pes: good question, need to follow up

mkwst: there are security impacts to making the changes
... same-site cookies is in IETF HTTP WG
... Origin-Policy on github
... correction: Origin done through fetch wg

<mkwst> s/Origin Policy/Sec-Metadata/

(Scribe misheard)

moneill: want to stop tracking, but don't want to kill commerce
... are there ways to handle tracker categorization
... not passing on referer header but in some other way

<weiler> scribenick: jnovak

<weiler> scribenick: mkwst

<jnovak> pes: there are a bunch of compromises that can be struck here

<jnovak> mkwst: for clarity, every search engine sets a referer policy that restricts it to the origin

<jnovak> ^^ in response to pes previously saying that search engines passing search term is bad

jnovak: Are there more pieces of that header that are helpful to discuss?

pes: In places where we have a signal from the user, is there anything beyond referrer policy that's worth enforcing?

moneill_: I don't see any point in the path, myself.
... Difference between same-site and cross-site.

<jnovak> mkwst: referer policy calls out that user controls should override whatever a page specifies, which means that part of the brave policy are within spec, but the piece where you are moving from third party to first party are not in spec but had discussions around forging the header around same origin resources because possible for any page on the origin to cause a page to be loaded. discussion about allowing a page to forge its referrer header for any same

<jnovak> origin page. haven't talked about forging so looks like another origin making the request. don't know if there are any security implications to this -- there are pages that do weak ACLs on referer.

<jnovak> mkwst: thinks dropping the header entirely is safer than forging

<jnovak> ... say that only because dropping the header is entirely supported by browsers

<jnovak> ... forging refer can result in failing open

<jnovak> ... on weak ACLS

<jnovak> ... failing close is also bad as likely that it will also break certain pages.

<jnovak> ... needs to all be taken into account

<jnovak> pes: is there a place where we can document the interventions?

<jnovak> mkwst: the intervention page; WebAppSec

<jnovak> ... referer policy is currently at CR, maybe can add to the privacy considerations or have a normative note

<jnovak> iclelland: is there a reason it doesn't refer to document.referer?

<jnovak> mkwst: document.referer is in HTML

<jnovak> iclelland: don't match in Brave

<jnovak> mkwst: think that there is a referer set to the document and then exposed to the web

<jnovak> mkwst: lots of discussion on what the default referer policy should be. would point you to what the default policy should be written by Brian Smith. More along the lines of what brave is doing.

<jnovak> ... will see if can dig it up and paste it into IRC

https://briansmith.org/referrer-01

<jnovak> pes: think that having a place that is more up to date may be helpful

jnovak: Two ways to hear what you're suggesting:
... 1. Here's how each browser implements `referer` interventions. Comparison table, etc.

2. Submit interventions to the interventions repo.

3. What sites break?

pes: 2, 3. 1 is easy to discover.

<jnovak> mkwst: read the referer policy spec, make sure it has what you want in it what you want to do as a browser to the referer header. If it doesn't say that, then, good place to have that converastion would be webappsec

<jnovak> ... can imagine that making changes to the privacy considerations section would be helpful

<jnovak> pes: mkwst - what are client hints?

<jnovak> mkwst: client hints are a way to send data to the server to help with content negotiation. chrome implements a number of them to help decide what content to send to user

<jnovak> ... viewport width; dpi to help send right set of images to user

<jnovak> ... network status to reveal what content to send

<jnovak> ... maybe if user is on 2g different than on wifi

<jnovak> ... all controlled by Accept-CH header

<jnovak> ... all off by default

<jnovak> ... website can opt-in to receive them by setting header on response

<jnovak> ... website sends headers it wants to receive

<jnovak> ... browser can decide what to send on response

<jnovak> ... browser sends those on response

<jnovak> ... gated on feature policy for third parties

<jnovak> ... so if I go to example.com and it includes advertiser.com, advertiser.com does not get the same set of hints by default

<jnovak> ... example.com has the ability to delegate to third parties that are included and to exclude them by feature policy

<jnovak> tara: this is on the agenda as there was a call re: this and there was a concern re: fingerprinting risk and a concern that additional attributes ask what happens if we go down this path. should we step back?

<jnovak> pes: in wednesday, claim was that net-zero implication because these values are already exposed via JS but others trying to reduce impact of JS implementation

<jnovak> moneill: made point that because available through JS should also be available by request header. if a third party has to execute javascript that's work that has to be done versus feature policy delegation and header

<jnovak> mkwst: think that (1) overestimating the difficult of running javascript; (2) first party can run javascript and will modify URLs to send information via get params or paths

<jnovak> ... claim is that this is happening and this is worse because cannot cache resources

<jnovak> ... sending up information about each client and sending up URLs for each

<jnovak> moneill: might be acceptable for a first party to do so but not a third?

<jnovak> mkwst: use feature policy for delegation so third party doesn't get access to it

<jnovak> ... means a couple of things: 1. because these declarations are both explicit and made by the first party, easily crawlable and collectable by regulators; first party can be held accountable

<jnovak> moneill: when you say cheap, how do you avoid turnaround

<jnovak> mkwst: don't mean cheap in number of requests but rather that the parties concerned about are sending js all day every day.

<jnovak> pes: if you could get to a world where JS deprecated and all headers, better. but, how do we make that happen?

<jnovak> mkwst: would phrase differently: if we turn off the JS api for a thing (viewport) then don't think would be sending via client-hints

<jnovak> ... assumption in client-hints that data is accessible. in a world where turning off JS mechanism then wouldn't send client hints

<tara> jnovak: argument: could one day turn off viewport JS API b/c Accept-CH is better for data minimization

<tara> mkwst: if you could find way to turn of JS for a context, you would also disallow CH in that context also

<tara> jnovak: you did not mean: in future world, deliver some data avoid to both JS + CH exclusively through CH?

<tara> mkwst: no

<tara> mkwst: explicitly not looking to add things not currently available through JS

<tara> pes: there are two distinct things: client headers + values

<tara> mkwst: infra vs content

<tara> mkwst: would have to define how pieces interact w/JS

<jnovak> pes: to broaden scope of conversation

<jnovak> ... what does the group think about where you have the same fingerprinting data exposing it in more places

<jnovak> ... you have the same information available and add it to another channel

<jnovak> jnovak: there is risk that you have to mitigate the fingerprinting risk in more places

<jnovak> moneill: firefox not partitioning cookies, doing something different from safari

<jnovak> mkwst: safari has also removed partitioned cookies from top of tree

<jnovak> moneill: if third party cookies are being blocked, then, sending down JS to collect fingerprinting information is more difficult because no cookies

<jnovak> mkwst: if you have cookies, don't need fingerprrint

<jnovak> jnovak: fingerprinting sometimes used to correlate across sessions, e.g. private browsing and not-private browsing

<jnovak> pes: the duplication question is one to document in standards

<jnovak> tara: guidance document?

<jnovak> ... have the fingerprinting guidance, maybe this would go along with that

<jnovak> ... might be useful practices

<jnovak> ... at least documenting the state of play

jnovak: That might be a pull request against Nick's fingerprinting document that says:
... "When you mitigate fingerprinting surface that appears in two places, mitigate it in both."
... For the `referer` conversation:
... For each browser that's implementing something, we should document the behavior. Perhaps in the interventions repository.
... Also document what breaks.
... In the research group?

<jnovak> mkwst: think that the client hints infrastructure can be used to reduce the HTTP header fingerprinting surface by removing things from HTTP headers and make them opt-in in CH

<jnovak> ... e.g. useragent header

<jnovak> ... variety of headers could imagine moving to this model

<jnovak> ... e.g. accept languages

<jnovak> ... even from a strict privacy perspective, can be a force to move things in a direction that PING wants

https://github.com/mikewest/ua-client-hints

<jnovak> pes: how do you all imagine this? registry?

<jnovak> mkwst: right now it is through IETF, which creates registry. can imagine that a registry is a reasonable way to manage going forward

<jnovak> ... not sure that registries are the right answer but it is an answer

<jnovak> iclelland: should client hints be the sort of specification that refers to some future spec of what private browsing means

<jnovak> mkwst: nice slide into separate topic.

<jnovak> ... obvious to suggest that different features should behave differently in private browsing mode, and client hints might be one of them

<jnovak> pes: header layer or JS execution layer?

<jnovak> ... seems much easier to have a standard saying "these values are not present in this case" than a standard that says "in this case, these other standards may behave differently"

<jnovak> mkwst: use the permanent message field registry and have a field in that registry that says client hints

Permanent Message Header Fields

user friendly prompts

<jnovak> tara: this came out of the permissions workshop

<weiler> scribe: weiler

jnovak: Sam mentioned this earlier... at w/s we had a conversation re: users' trust of content in browser chrome
... let to conversation where martin thomson and I were arguing that users trust browser chrome more.
... others in room said we should commission research to support this.
... gets risky, since websites can provide scary language in browser UI.
... seemed weird to not have indepedent web-wide research line this. someone asked if w3c should be coordinating this sort of research

tara: which brings us to: how would that work? and who would pay for it? and is it in scope for w3c?

wendy: how is it paid for is a key question. if this were deemed useful, collectively, for the web, to ahve this done in a vendor neutral way (read: w3c), then would w3c be able to get sponsorship to commission research
... that was the level of the conversaion

moneill: discussion of w/s?

wendy: no

mkwst: UX patterns of browsers are distinct. unclear to me how to design a survey that gave info that was genercially useful (v. useful within the patterns of indiv browsers)

jrossi: I want to add some questions. @@ re: privacy here in france.
... how users use certain tools.
... we have some researching how activists in someone countries are using tools.
... if there is need for research on a specific topic, this might be something this group might be interesting.
... I would be interested in putting a proposal fwd. Our question: what exactly do you want us to look at?

wendy: user studies are often contextual - vary by kind of users. as gloabl org, want to hear from users around world in different contexts.

mkwst: chrome team is interested in user research. we have had success in security space - looking at how users eval the UX we have, what iconography we should use.
... the security UX team has published good papers.
... it sounds like we're asking how users distingusish
... between content from web author v. browsers and how do they sort trust. hard to ask in a generic way
... @@

tara: have to explore if question is answerable.
... is a research Q in its own right

moneill: doorhangers.... @2

jnovak: this is a bad example. a feature w/ no user mediattion would be a better example.

mkwst: e.g. geolocation. chrome is moving to a model where all permissions are pushed through the first party, since it's hard for user to understand composed nature of sites.
... e.g. if you're on A and site B asks.... things that have changed
... B can only ask if feature policy allows it. and permission goes to A.
... B does not get its permission everywhere on web; only within A.
... permission is being granted to first party, which can delegate.

<iclelland> Chrome’s permission delegation design: https://docs.google.com/document/d/1x5QejvpyQ71LPWhMLsaM1lWCfSsBsSQ8Dap9kJ6uLv0/edit

<scribe> scribe: wseltzer

<jnovak> scribe: jnovak

mkwst: chrome team has done research, think that users can understand the omniboc

<wseltzer> mkwst: chrome team has made some explicit decision about what we think users understand

mkwst: reluctant to talk about things other than example.com in browser UI

moneill: how do you explain third parties?

mkwst: difficult to. storage access api is interesting, makes the most sense when requested by third parties, can only make sense when clicking on a thing created by a third party
... want you to make a decision about this other entity than the first party
... makes total sense in the context of that api
... not clear how you could do it differently
... hard to ask users otherwise

moneill: what happens if there are lots of entities that want storage access

<tara> jnovak: what does this mean? From UX standpoint: I am on newspaper.com, click widget 1, get prompt, make decision, click "share thing 2"

mkwst: geolocation can be prompted for by third parties
... my knowledge is that those prompts aren't deduped
... suspect each browser is going to handle how multiple requests pile up
... firefox has various cards, overlay each other
... maybe chrome does so too
... neither of those are necessarily helpful

moneill: some indication that a bunch of prompts and can go somewhere else

<mkwst> jnovak: Isn't that a failure mode?

<mkwst> pes: We're a bit off topic. Should we commission research?

<mkwst> jnovak: I'd suggest that if we're presenting users with 300 prompts at the same time, we don't need research to know that we failed.

<mkwst> ... We're not the people with the expertise to do the research.

<mkwst> ... This is a UX question. We should find UX researchers to do it.

<mkwst> ... Should we find those people to talk to about running a cross-browser survey?

<mkwst> pes: I'd love that research to exist.

<mkwst> wseltzer: When we identify questions to which multiple people say "We'd love emperical evidence to answer that question!"

<mkwst> ... W3C can facilitate.

<mkwst> ... Questions of funding/sponsorship can come as a second step.

<mkwst> ... First step is to come up with questions we think are valuable.

<mkwst> jnovak: I agree.

<mkwst> ... In this meeting we've come up with several things we want to see exist.

<mkwst> ... Privacy browsing document, etc.

<mkwst> ... In terms of priorities, where does this question of permission UX fit?

<mkwst> pes: We all do research in our own companies. Perhaps we can have a shared repository for that work?

<mkwst> wseltzer: Regarding priorities: one way of judging is to ask what we can do better as a group than individually.

<Zakim> wseltzer, you wanted to discuss prioritization

<mkwst> jrossi: In the research community, funding is a question, but we get funding from various sources.

<mkwst> ... What's difficult is to have a clear understanding of what browser vendors are interested in,

<mkwst> ... We do research. Sometimes it's not read.

<mkwst> ... I have some ideas for research around trust, similar problems.

<mkwst> ... Pretty certain that if there's a clear place (on the W3C website?) saying "We're interested in X.", that could create a bridge between your questions and our research.

<mkwst> jnovak: This gets back to what we talked about in last TPAC.

<mkwst> ... We should bring in researchers to talk to PING so we can start a virtuous cycle between the groups.

<mkwst> ... "We're interested in X", "we're researching Y", and so on.

<mkwst> tara: Private browsing mode research is a good example of how this can work.

<mkwst> ... Want to give relevance to the folks doing web privacy research.

<mkwst> ... Expertise. Would be good to align interests.

<mkwst> jnovak: Did we reach out to INRIA about fingerprinting research?

<mkwst> tara: Will look.

<mkwst> jnovak: We should have a PING github org.

<mkwst> ... With multiple repositories that we can put under it.

jnovak: including a research repo

tara: maybe including publicly available research that we each are doing
... in our own orgs
... to share
... at least a way to coordinate

jrossi: would add that can be helpful in terms of getting funding for research, there is an interest from business and W3C and ...
... when we arrive asking for funding saying W3C and its members care, that's a useful tool.

tara: have 10 min before joint session, can steal topics from the future

<mkwst> jnovak: How hard would it be to have a `w3cping` org?

<mkwst> wseltzer: Trying to create it now.

<mkwst> ... Hard to link between PING and other W3C orgs with that setup.

<mkwst> jnovak: It's already hard. Questionnaire is being edited out of my personal repository right now because there's no way to fork inside `w3c` org.

<mkwst> ... Immersive Web has several repositories in their org. Makes things simpler.

<mkwst> weiler: Travis CI checks for licensing, etc?

<mkwst> [shrugs]

<mkwst> wseltzer: It apparently wasn't hard, because it now exists.

https://github.com/w3cping

jasonanovak

<pranjal__> jumde

<stevelee> SteveALee

<tara_> we are in joint session (Immersive Web)

the questionnaire is now out of my personal github account, huzzah! https://github.com/w3cping/security-questionnaire/

<tara> npdoty - you found the WebEx link without any problem, or not?

<npdoty> it took me a couple of tries, but I figured it out

<tara> (checking if we need to correct anything)

<npdoty> the page also had another webex link on it that seemed more prominent, and it has a different password. i sent christine email

<tara> Thanks!

<mkwst> scribe: mkwst

Questionnaire

jnovak: Questionnaire is a doc that mkwst started a while ago.
... TAG took up ownership and active editing in ~Feb.
... We did a series of edits in a small group earlier in the year.
... Talking through the whole document, step by step.
... Sent out pull requests for PING review.
... Waiting for those to be merged in. Have more edits waiting in the wings once those get merged.
... Questions themselves should be agreed-upon at this point.
... From a process standpoint, it would have been helpful to get additional comments from folks.
... Now that we're in a repo of our own, we can make edits as we wish and merge them in as they want.
... I'm serving as editor on the TAG document.

<npdoty> thanks for the overview of the current status

weiler: Now that this is forked into our own repo, do we think we're going to get the merges processed?

jnovak: I expect the TAG to maintain their doc. We'll make edits to our document, and send PRs to the TAG.

weiler: Will those edits get in?

jnovak: Great process question.

weiler: How much did you go through the old docs?

jnovak: Went through all of them.

<npdoty> are we ready to obsolete those other documents soon?

weiler: I can force updates to the other document.
... (the TAG document)

npdoty: are we ready to obsolete those other documents soon?

weiler: See above. I can make that happen.

tara: Should any of this week's discussions be fed back into the questionnaire?

<weiler> jnovak: hold off on obsoleting until our pull requests are merged into the tag doc.

jnovak: Yes. Client Hints discussion, for instance, was productive.
... Permissions workshop as well.

<wseltzer> jnovak++

jnovak: Verifiable Claims group's feedback as well.

<wseltzer> [thanks for all your work on the questionnaire!]

jnovak: Helped validate some of the choices we made in edits to the questionnaire.

npdoty: Thanks, jnovak!

<scribe> ... Ongoing process: are we comfy with the idea that we're not publishing a finished version of this document, and will continue to edit over time?

weiler: Is this a living document?

npdoty: That's what I'm asking about.

dsinger: I hope that every time a review is done, we find ways to improve the document.

weiler: The VC folks had comments for us in their answers.

dsinger: The questionnaire should also make us think.

jnovak: We should move it to versioned, published URL.

weiler: Do we care about that?

jnovak: Yes, because we otherwise can't tie answers to the version of the questionnaire folks were answering.
... Other things W3C publishes uses dated URLs.

dsinger: I want a link for every github version.

christine: I agree with jnovak that we need a clear way to know what the state of the questionnaire was at the point they answered it.

jnovak: If we treat `master` as "current", you can imagine a set of URLs with commit hashes as snapshots.

npdoty: We will have issues where folks say "I don't like question 13!". We need to know what question 13 was at the time they made that comment.

jnovak: Right. I don't expect many changes per day. Perhaps a date in the URL is fine.
... Doesn't need to be a commit hash.

(https://fetch.spec.whatwg.org/commit-snapshots/daca6a824c0c6c5e22b7f7eb70001f36c1732cb1/ is an example of the WHATWG's snapshotting mechanism)

dsinger: Do we need to talk to the TAG about moving it to our repo?

<weiler> ACTION: weiler to sort out how to create versioned copies of the questionaire

<trackbot> Created ACTION-19 - Sort out how to create versioned copies of the questionaire [on Samuel Weiler - due 2018-11-02].

jnovak: We've created a new org, so we can have multiple repositories.
... We can move those additional things into distinct repositories.

weiler: Do we want to publish the questionnaire, or do we want the TAG to do it?

dsinger: We should talk to the TAG.

jnovak: I think the document should with with TAG at the moment.
... Can reevaluate it periodically.
... In an ideal world, we'll have more diversity of viewpoints.
... It'll be harder to edit because we need more folks to have an opportunity to weigh in.
... We'll need time to process and weigh changes.

npdoty: jnovak is taking on an editor role. Are you committing to make those changes when questions come up?

jnovak: Short answer: as things come in, I'm happy to work with PING to make sure things get addressed. I can work with TAG to get it into their doc.
... But folks can send pull requests, etc. I don't need to type all the text.

<npdoty> +1

jnovak: But I'll commit to "making it turn". Others will contribute.
... Someone creates an issue, I'll move it forward.
... But I'm not going to write PRs for everything.

<jnovak> scribe: jnovak

weiler: so nick and christine, should bring you up to speed, tara, do you want to do so?

tara: had a general discussion about how we can fit ourselves more effectively into the process of working with other groups given that we want to be involved at the right stage, which may be earlier than we've been seeing some thigns
... want to put our effort towards those things most relevant
... don't want to be last minute speedbump
... talking about how to do so.
... some of it was around interactions with the tag and how they are part of the review process
... they are in the formalized review process

weiler: was specific to chrome's process before they ship

tara: two things. there's no guaranteed choke point
... there are things the TAG are getting in review that have privacy impact

<npdoty> yeah, that's not a W3C formal process, right? just that Chrome as a browser team is making sure that review happens in their feature development?

tara: Chrome will do a lot of work well ahead of TAG review
... intent to ship component
... Chrome will get feedback from other browsers and TAG about whether this should move forward
... that may be a chokepoint
... incubator type model
... question of where we feed into that
... lot of work before it bubbles up to a working group
... there's a reasonable point for us to be involved as an IG
... interacting with TAG's point of view and process was valuable, may be other things that we can do
... design respository
... has a note for self to talk to Mike about better process
... Chrome is one player though

weiler: W3C needs to fix this generally for other horizontal efforts

<pranjal> https://twitter.com/intenttoship

npdoty: been following, loosely, the WICG discourse

<npdoty> https://discourse.wicg.io/

https://github.com/wicg

scribe: not clear if any formal process
... definitely the case where a lot of "would be great if could do X, but often npdoty comes along and tries to say "here are the potential privacy implications and things to be aware of" not "bad idea", but maybe people hear "bad idea" in some cases
... early ideas, even before intent to ship
... unclear if that's an area where we want to reach out

<npdoty> to be clear, npdoty comes along and tries to say "here are the potential privacy implications and things to be aware of" not "bad idea", but maybe people hear "bad idea" in some cases

(we'll see if that gets parsed properly)

mkwest: there's a spreadsheet bit.ly/blinkintents
... list of all the things that match on a certain regex
... about 1600 lines in the spreadsheet
... moderate volume --- 10x a week?
... don't know about other vendors
... they have different processes, sometimes more opaque

<mkwst> (The shortlink goes to https://docs.google.com/spreadsheets/d/1pvXEMD5pRioognaqEzglS-4ZBSQ_YmzL8Fiz7yt4Bb4/edit#gid=0, FWIW)

<npdoty> 10 a week is a lot, but it could be the source we use to find which 1 to follow up on

tara: at least some of this is a conversation between myself and midwest.

mkwest: don't know a way for you not to look at everything
... folks don't always understand the risks they're creating
... folks who are helping them should be experts in area
... and say "there are not issues" or "here is a subtle issue"
... have internal rotations in the Chrome team that rotate the responsibility of looking at these on a week by week basis. maybe that is something that PING could adopt?
... have experts and have them rotate throuhg?
... also publish rotation results on the security-dev mailing list
... so if you only want to look at a summary on a quasi-weekly basis
... do a good job at publishing thoughts on intents that week

tara: thanks. that gives more context on how you are using it

mkwest: no magic bullets.

<mkwst> https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/2H3ZiI_INm0 is the summary thread

weiler: first message right now in security-dev list is the intent thread triage report?

mkwst: that's it
... most recent is this week's
... so more or less on track
... focus is more security than privacy. but worthwhile for more folks to pay more attention.
... try to be open to ensure more eyes on it.

<npdoty> +1

mkwst: good for PING to look at intent to ship but important to look at other browsers too.

tara: yes, agreed should not be chrome specific

<npdoty> do we have equivalent processes for other browsers?

mkwst: Chrome is not the web

<npdoty> :hands-raised:

jnovak: so action item is co-chairs to go investigate how to hook into browsers' feature development process and inject earlier?
... and side-benefit of recruiting is to get hooks into other browsers (Microsoft and Mozilla)

christine: happy to look into it, not entire sure what the blink process is, happy to figure it out

<mkwst> https://www.chromium.org/blink/launching-features <-- the blink launch process.

<christine> thanks

weiler: I will take an action item to talk with Ralph who is the architecture and technology function lead and acting director; he has within his job description, horizontal review description stuff generally, so should be interested in this for that.
... will see if can get movement internally

<mkwst> In particular, the "Intent to Implement", "Intent to Ship", and etc. mails might be useful points for y'all to triage and interject your opinions.

dsinger: talking about whole horizontal review is working is a good next step
... CR call is too late
... true for accessibility too

tara: logistically speaking, how does this happen?

<npdoty> yeah, we're definitely not alone in that problem

dsinger: I'll file an issue in the AB github repo

tara: private browsing mode. seems like we want to do a document

weiler: hadley cares
... have you talked to her

tara: happy to have everyone in the discussion who wants to be

weiler: who is going to drive it?

jnovak: Didn't pes express interest? (Yes, he's not here, it's not fair, but we can ask him)

weiler: we will own this and invite hadley to be involved
... in particular pes will invite her

pes = Pete Snyder from Brave

discussion about privacy work group -- are there privacy standards that need to be discussed

mkwst: should the WebAppSec group recharter for Privacy docs
... can this group (PING) publish those docs?
... is WebAppSec the right venue?
... or is a working group for privacy better?

<npdoty> were there examples of normative, privacy standards documents?

mkwst: don't know enough about process questions or its desires.
... thinks there's room in webappsec, but, wary of increasing scope of WebAppSec
... issues that have security issues usually have privacy issues or vice versa

npdoty: were there examples of normative, privacy standards documents?

mkwest: don't know if there were specifics questions; pes may have had referer policy or private browsing in mind
... public key cache?
... thinking of examples pes gave earlier in the week
... can imagine normative stuff out of this group or others

weiler: which brings us to the fact this group needs to be rechartered.
... only process barrier other than adding it to the charter is that anyone who makes normative documents needs to join the IG, making IPR commitments

<npdoty> I had been thinking that private browsing mode stuff was less likely to be normative, but I haven't heard every recent conversation about it

dsinger: need to be a working group to publish normative documents

mkwst: IGs are supposed to publish requirements and notes; WGs publish specs and normative documents

weiler: tackle it when we need to

dsinger: let's get a document together that requires publishing a normative document and then we can solve that

mkwst: think that WebAppSec scope covers publishing docs like this
... look at webappsec's charter and see if there are things with normative force that wouldn't be covered by current scope
... if that's the case, then raise it

weiler: I'll follow up with pes to see what he has in mind

<weiler> ACTION: weiler followup w/ PES re: potential normative privacy specs and whether they fit into webappsec scope

<trackbot> Created ACTION-20 - Followup w/ pes re: potential normative privacy specs and whether they fit into webappsec scope [on Samuel Weiler - due 2018-11-02].

<christine> apologies - will need to step out from the call

npdoty: don't want to make it hard to join PING per dsinger's point; mostly we are at the point where we are discussing proposals in things that don't have IPR commitments
... that would be a way to go -- you have a privacy idea? go discuss at PING and at some point it will get dispatched to a WG

tara: going to be more discussions coordinated via Sam and chairs

<npdoty> https://www.w3.org/2011/07/privacy-ig-charter.html

weiler: is there anything else people want in this charter next time around?
... is there anything else that we want in this charter?
... if there is add to list

tara: jnovak mentioned in passing, what are the goals of PING?
... spelled out in a mission, mission in the charter
... do we have the right set of goals in mission

<scribe> ACTION: jnovak to look at mission in charter

<trackbot> Created ACTION-21 - Look at mission in charter [on Jason Novak - due 2018-11-02].

wseltzer: since we are non-normative and we have the option to use the charter to express more of our goals and hopes that we want other people to know about the group, less important that the scope is precisely tailored to lawyers that these charters are aimed to vis-a-vis IP commitments
... want to tell people to make the web a better place for user privacy

tara: locus of expertise

wseltzer: it feels like PING has been picking up interest and excitment
... is there something that we want to say to the AC?
... might be fine to communicate that around the charter communications

jnovak: so is the action for the membership to review charter and provide comments by {Date}?

wseltzer: Nov 15th

tara: chairs will send out for membership on mailinglist

<npdoty> current charter is kind of tentative in the goals for the group (or at least I was when I wrote this a long time ago), but I think we can more confidently say that we are doing those things now

dsinger: something that looks like we are kicking it up a notch. need more people, activity, direction

<npdoty> "may provide a locus of expertise" => "provides expert review and analysis of broad standards across many groups"

dsinger: need to be both where things are happening and where people think that the work is going
... put charter in github repo and work on it there?

<scribe> ACTION: wseltzer to get charter in github repo and work on it there

<trackbot> Created ACTION-22 - Get charter in github repo and work on it there [on Wendy Seltzer - due 2018-11-02].

npdoty: can someone please provide an update on the web security interest group?

weiler: lost both chairs.
... had a different model for security reviews that didn't involve IG so role of IG a bit fuzzy
... be incubator for new ideas
... dream currently is incubation
... wavering about what to do about that
... one answer is to kill it
... or let it die

npdoty: if it doesn't have a chair and it doesn't have activity, could combine these groups

weiler: could

jnovak: don't think that security or privacy benefits from combining

weiler: fair but don't have chairs

npdoty: just noticing that we are seeing mingling of expertise
... agree that don't want to break what's working in privacy area

<npdoty> charters are ending on the same date?

dsinger: let's expose to AC but need a plan before we do

wseltzer: what we do have is the effective WebAppSec doing the substantive normative security specifications
... not that we have abandoned security but the security interest group wasn't an effective place for additional work
... is there something else that the membership needs a place for
... let the community figure it out?
... try to invigorate something

<npdoty> or security reviews to catch security issues in early design of web features?

<christine> I am back on call

weiler: what would help track stuff? put issues in new github org?

https://github.com/w3cping/administrivia/

jnovak: file issues against that github repo that are administrative

- DRAFT -

Privacy Interest Group Teleconference

26 Oct 2018

Attendees

Contents

Items from other TPAC meetings

Working well with other WGs

DNS-over-HTTPS

Accept-CH

user friendly prompts

Questionnaire

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output