Meeting minutes
Intro
jyasskin: This is a joint effort between TAG and PING, currently open for wide review
dka: favourite part of the document - data minimization
… I'm excited about this because it's a finding I wrote when I was an elected member of the TAG in 2008-9
… It was rejected by the other TAG members because they didn't think privacy was in scope
… It reaches back to papers written in the 1970s
… it's about minimizing the data that you need when you call an api, when you make a response, so that you don't expose data that could be exfiltrated by attackers etc
… This came up a lot in the discussion of the geolocation api
… it has roots
… I'm glad to see it codified in a place which is a TAG document so we can refer to it more normatively
jyasskin: favourite section - device owners and administrators
… lots of devices have owners that are different people from their users
… browsers are picked usually by the device owner, but we have some obligations to the users
… so now we have a section to point to to say that
… protecting web users from abusive behaviours is Nick Doty's favourite section
Don: contexts is favourite section
… what makes me happy about this is we're proceeding on the basis of what the user understands about what they're interacting with and not about some details that the user might not be aware of
… this is a really positive step forward
Q&A
jyasskin: what does everyone think?
DKA: I can talk about how we convened the task force
… the TAG is an elected leadership body in W3C. Members of the TAG are elected by the W3C Members
… a couple of people are appointed by the Team
… The normal work of the TAG is reviewing other peopels work, and producing documents like design principles, ethical web principles - foundational documents that help us all do our work
… we ask everyone who is writing new apis and techologies for the web to take a look at
… In order to add horsepower to the TAG to do something additional like the privacy principles, we use Task Forces
… it gives the TAG the ability to bring in a bunch of people who are going to work together well and to set the rules of the task force
… However, the power the TF has is to recommend to the TAG that this become a TAG document
… the TF does the work on behalf of the TAG, then the TAG reviews it and decides whether to adopt it
… eventually the tF will spin down
… We're keen to get feedback and understand how you would use this document
… if you're confused about it, we want to know that
… We want to add clarity
… We want it to be useable
<jyasskin> ack
DKA: The point is that people use it during their process of api design and designing new features for the web, that they evaluate what they're doing against these principles and have them in mind
psnyder: there are still some areas with disagreement or uncertainty about what the document should say
… useful to get feedback around those areas
… what should it say about what's appropriate for apis to collect that isn't directly tied to an individual but is still personal data
… ancilliary data - should it be acceptable? Under what consent? For what purposes? what granularity? Various dimensions
… some extreme positions and a bunch in the middle. Would be useful to hear from more stakeholders
tomayac: we see "opt in" as one of the principle
… what can we say about opt in for hard things? To a lay person, eg. requeststorageaccessfor - how does someone respond in an educated manner?
… Things that are objectively hard to explain, but you want to give users a chance to opt in or out
jyasskin: I don't think there are specific suggestions for particular cases
… it says you do need to explain to users what's going on
… just popping up a screen that users don't understand is not sufficient to get real consent
DKA: if you've got a popup that says "would you like to enable requeststorageaccessfor for the following origin" that is not okay
… but a good example is something like web bluetooth's permission approach
… it gives you a visual indication, this is the indiciation that you're going to be shairng with this url
… you're going to be sending this information that' sin front of you to amazon.com, are you okay with that?
… that's more understandable
… it's about encouraging people to think about prompts in terms of user understandability and the actual user need that the capability in question is performing
… rather than the underlying technology
tomayac: trying to abstract as much as possible?
DKA: I think that would be consistent with TAG feedback you'd get in thata case
btsavage: a sectoin that says "groups and various forms of institutions should ... collectively"
… how do you see this being aplicable to a web spec author? what does it mean in context of the web?
jyasskin: in some cases working through w3c accomplishes this
… w3c groups can make informed decisions where users don't have the time or attention to get informed
… this is also a request to call otu to civil society groups and get their feedback during the standards process
btsavage: this is about participation in the creation of standards, not about apis that are intended to be used by gropus?
jyasskin: right
… it's also advice to websites
… asking a user for consent, then making a bunch of unilateral decisions about how your'e using data is not great
… when web authors are making that decision there should be involvement by wider groups
… there's not a whole lot of api design advice in this section
<mt> I have to say, the text on screen and the words that Jeffrey are saying don't really match very well.
jyasskin: I don't know of cases where an api would be designed to support this principle
sysrqb: Matt Finkel from Apple(?)
… curious if the task force can say... there's no enforcement mechanism. How is it going to be used outside of best effort by WGs?
… eg. within PING we do privacy horizontal reviews
… in a lot of cases problems that are described in this document are raised and they wind up being footnotes within a spec
… that it's a known issue
… and that's it
DKA: the TAG is part of horizontal review. we encourage all specs that are intended for the web platform to go through that process
… we've done so for whatwg specs and other places too
… tag has no formal authority to stop things from happening
… however it's a strong signal that something needs to be re-thought
… we have a good track record of being able to influence the design of upcoming specs
… this is intended to help both PING and the TAG so we have something to reference
… privacy is part of what we look at in the TAG
… we see that as being additive to what PING provides
… we also want to be able to refer to a document that says why something is contravening a privacy principle
… this is why we wrote the web platform design principles in the first place
… so we can reference something
… it's not a stick we can hit people in, but hopefully it's encouragement - people want to ge ta positive review
… and in responding to the TAG's feedback it helps to level things up gradually
kleber: Michael Kleber from Chrome
… How dow you think about places where there is large gap between the principles in the document and things about the way the web already works?
… The thing Don shows about contexts not being defined by the owner but by how people think about contexts being different
… which surely is not the same thing as contexts being defined by registerable domain, which a lot of apis inherantly depend on
… I'm asking in the context of trying to remove 3p cookies from the web, so it's obviously possible to change something that has been a deep part of the design of the web for decades
… but it's also an enormous task
… Would love to hear how you're thinking about that, and whether there are more such enormous tasks to make the web and principles here coincide
jyasskin: the thinga bout contexts where we say something there are context boundaries inside of a site
… and another section that says UAs dont' perfectly understand contexts
… they enforce context boundaries in certain places
… if they learn about one that's more preciese, they should also enforce that, but we don't expect perfection
… that becomes a thing we'd like site authors to do, to respect users understanding inside of sites
… don't go up to the boundary of what a UA can enforce
… I don't remember an example, but there might be bits that do imply that in the long run we should make mroe architectural changes to the web and try to take another step forward
kleber: if there are huge philosophical changes to the underpinning of the web that are implied by this I'd love to see them called out explicitly if it's not immediatley obvious
jyasskin: I think we would have tried to be intentional about that. It's supposed to be both aspirational and practical
reillyg: I think this came up in a previous question.. som eprivacy principles apply to site authors, some to UAs, some to specs
… I think the document is great but also feel like it is likely aspirational in terms of the awys it asks for the broader world to change
… I'm curious whether there's been work to get .. areas where there are proposed regulations in the world that would force site authors or browser authors to contradcit some of these principles
… curious how the tf has struggled with that emerging issue
… and how the w3c may have a role to play in trying to prevent those kinds of isuses from having a future by pointing to these principles as a gold standard of how the ecosystem could work
DKA: one thing we've tried in the document is to differentiate between where a principle is requiring something of a UA vs of a site vs a spec developer, or applicable to those different domains
… you're right to say that many parts of the doc are aspiratioal
… it's an aspiration worth having
… I also know that the document is nto directly seeking to influence regulation or legislation, however regulators do look at what standards groups such as w3c do
… there is a possibility that it could be influential in those discussions
<jyasskin> w3ctag/
DKA: if we don't start from somewhere we won't know if we can influence
… we won't know if we can level up the web in these ways
… it's a loose answer, but I hoep it helps to understand the mindset behind it
wanderview: Ben Kelly, Google
… outside of the principles doc. is it in scope for TAG to track the current state of privacy on the web?
… things have been changing over the years
… browsers have pushed on thigns, more browsers have adopted things. Seems valuable to track how good of a job we're doing. To build trust in the web
… Or do you rely on external privacy researchers to do that? Feels like a bit of a judgement call
DKA: it's not in scope for the task force
… we had to keep the scope clear
… it is in scope for the TAG to be interested in that topic
… we don't have a current work item
… I kind of feel like it's in the PING wheelhouse to be tracking the general topic of web privacy
… I do think that it must involve other civil society groups and research orgs
… I wowuld see that as more of a PING thing..
psnyder: what's the role of this doc in horizontal reviews?
… two roles
… one is to more closely align the approaches that PING and TAG are doing when they're doing their reviews, and other groups doing privacy reviews
… to make sure we're using consistent advice and standards
… and within PING, to increase the predictability of reviews wer'e doing
… we can't remove the possiblities altogether, but to decrease how often groups are surprised by something we consider a seriosu privacy concern that they hadn't anticipated
… those aren't the only goals of the doc, but two ways it helps with horizontal review
gendler: Max Gendler, NewsCorp (?)
… questions on non-retaliation
… an open issue on a complex scenario not written about
… is there an intention to expand that? or is it out of scope?
… if it is in scope could you briefly describe what you intend to write about?
jyasskin: when someone opts for greater privacy protection, the website shouldn't take away unrelated features in order to allow privacy invasion
… some websites use people's data in order to fund themselves
… if that's essential to the operation of the website it's reasonable to ask people to pay in some way to read a website
… I've seen websites make that trade explicit, give us data or subscribe
… that' snot necessarily retaliation - we don't want to say that's out of bounds
… but we haven't discussed what the constraints should be
… we'd welcome text to describe that in more detail
DKA: we also have a genearl feedback point from TAG when we're reveiwing other peoples work that we want to make sure that if the UA they choose, they've chosen to turn off a particular API or chosen a UA that doesn't implement a certain api, it should be very difficult for the website to say "works best in Netscape Navigator 7.3"
… that's the antipattern
… it's a kind of retaliation to say you can't use this browser on this site
bmay: the users of the web, UAs and site owners... any thought given to writing companion pieces that were addressing each of these groups
… and what the privacy expectations for each of them might be
… so other groups understand what obligations they may have to each other and what the expectations are
jyasskin: I don't think there would be companion docs, this should target everyone
… but I recently filed an issue that a lot of our principles.. we've got a summary, but it doesn't say who the principle is primarily targeted at
… we've been trying to keep each principle targeted at one or two of the audiences
… but we need to write that down in each principle
bmay: thinking from the perspective of users and site owners
… at the end of the day, it's their relationship which really matters
… if I as a user have a document I could look at that says we expect developer son the web to abide by in terms of respecting privacy
… and for developers, this is what users expect you to do
… that might be helpful
… the principles are useful but mayb ea little nuanced for some communities
jyasskin: that's interesting
spanicker: from google chrome
… there are certain big privacy changes happening, anti-tracking is one
… a lot changing, lots browsers are doing
… to what extent do you consider this as a key audience?
… to what extent should I be thinking of this as a resource for reasoning about eg. trading off privacy with user safety?
… these are big topics
… is that in the purview of this thing, or do we need another effort?
jyasskin: the people driving the big privacy changes, should they be reading this?
spanicker: should it be a resource in decison making or thinking through things?
jyasskin: yes. And also we've been informed by the big privacy changes
psnyder: there's been disagremenet about whether this doc should be very narrow, or broader to what privacy means on the web at large
… there are lots of opinions
… would be totally expectation to make this about expectation on users
… users don't have any representations in the w3c
… would be inappropriate to say what users ought to be doing on the web in this document
bmay: my intent is not to define the expectations of users, but for users, about what they can expect form interactions on the web
… not necessarily in this document
… a companion document may be more appropriate
… since users are a major constituency and we're talking about their privacy, we should give them perspective
psnyder: that would be useful
jyasskin: that seems like something the privacy wg can take up, not something the tf is going to
charlieharrison: there are a lot of principles here. Valuable, but also worry about the difficultly of applying these to specific specifications
… it's a lot of things to keep in your head at once
… what has the TAG thought about process changes, eg. incorporating in the S&P questionnaire
… other ways to force us to look at this?
DKA: hmm
… I do think it needs to be integreated in the the P&S questionnaire in a way that doesn't make the questionnaire 3x as long as it currently is
… channeling Nick Doty for a second. Nick would say any shortened version of this list is necessarily not going to be as accurate
… I agree with that, and also understand and sympathetic to the point about not wanting to read the encyclopaedia before I start my work
… maybe we need a demystifier, or something that guides..
… which principles to be interested in
charlieharrison: any sort of narrowing of focus for specific sub areas is great
… it's hard to keep in my head focussing things ... we don't want to make the S&P questionnaire longer, but we also want people to think more about all of these things. We should figure out where we stand
DKA: there should be one point of entry in the review process for security and privacy
<Zakim> robin, you wanted to present your favorite section
DKA: a jumpin goff point, the first port of call should be the questionnaire. That would be my starting point, but we haven't discussed it. Good feedback.
robin: /waves
… my favourite part is the focus on user agents
… a lot of us take this for granted in browsers, but it was worth writing down in the context of privacy
… one aspect that I personally am very interested in is to consider uas as being fiduciaries
… agents to whom you delegate
… when you delegate to an agent, you're entrusting them with a lot of power over your life
… and they have a lot of expertise which you don't have
… this puts them in a position of power wrt to you
… there are legal frameworks so they cannot abuse that power
… I think it's important to approach browsers with the same mindset
… if browsers start to abuse the extremely high levle of trust we put in them, it breaks the web and is bad for users
<Zakim> mt, you wanted to talk about establishing a guide document (this one, say) while shortening/focusing the questionnaire
mt: Martin Thompson, Mozilla
… about the S&P questionnaire
… this document represents something of a contribution in this space that helps with that
… it's also very abstract and complicated
… I don't think it serves the purpose of a guide we might expect to have
… I think we have a much better understanding of security
… and we can produce more cogent and precise guides for that
… but privacy is more difficult
… I'd like to see some work to guide material that accomopanies or is part of this
… in ietf we've built up a culture of security, rooted in the idea we have a guide
… we have a requirement that people write security considerations, but we don't give them a long qustionnaire
… we provide material so people can understand the sorts of things they might need to accomplish what is acceptable
… I'd like to see this sort of process here
… if you ever consider this done...
DKA: the idea is that this document is done quite soon
mt: but there is follow on work. I'd encourage keeping the taskforce open or look at work in PING to continue this valuable work
DKA: that's good feedback
… comes undre the heading of ensuring this is used
philippp: Philipp, Google chrome
… protecting users from abusive behaviour
… about pooling information
… historically ?? are useful for shairng.. but also are a cross site tracking vector
… anything else to help people band together to protect themselves form abuse, especially for smaller publishers
… this section is here so you know you're on solid ground for inventing those things
DKA: yeah
… it's the starting point
<mt> mt: to ask about Michael Champion's feedback on the document
bmay: may have overlooked it - is there any part that addresses the consequences of decisions, or considering the consequences on privacy
… eg. 3p cookies being withdrawn - which I think has a positiv eimpact on user privacy, but also unintended consequence of having first parties gather much more information than they previously did
… is that something the document intends to address?
jyasskin: unintended consequences?
bmay: and prioritising review of unintended consequences as part of the privacy review
<philippp> rhiaro: s/??/identifiers like IP address and email addresses/
jyasskin: I don't think we address unintended consequences. We have a section about looking like there' sa tradeoff
<mt> I am reminded of the known knowns, known unknowns, and unknown unknowns taxonomy here
jyasskin: when they beomce known consequences, how do you think about when there is one good thing and one bad thing
… a lot of privacy experts experience is if you think a bit harder about your problem space you can often find a way to get both good things
… but that's not always the result
<Zakim> mt, you wanted to ask about Michael Champion's feedback on the document
mt: you received extensive feedback from Michael Champion on this. I share sentiments on readability and accessibility of this doc
… there's a lot here that I like but it's hard going
… what have you put in to look at addressing that feedback
robin: we've received several such feedback
… it's been difficult to figure out a good path towards addressing it
… one part is t's written in a style that is not readable, that is largely my fault
… we have been trying to address with good old fashioned editing
… we can make progress
… the other part of the feedback is people saying there's a lot of concepts in here and it seems like privacy is hard
… I'm not entirely sure what we can do
… it relates slightly to.. in part to previous comment about boiling things down to a section that can be repeated
… oen of the cultural differences between privacy and security spaces is that in security, a lot of the original experts were already computer people
… and so moving from that to a shorter list, distilling things, was easier
… in the privacy space, computer people tend to be clueless about how privacy works
… so there's more work to bridge that gap so that we can ultimatley.. and I agree with you that's where we want to get - boil it down to simpler lists and principles
… I invite input and feedback on this. Struggling to figure out ways of building upu that understanding and culture outside of the privacy community
… and much more broadly in the web community without making it as difficult and as much to read
… either we don't do it well and we're not saying enough
… or we bring all the improtant concepts, and.. it's a lot
Matt G: from chromeOS
… reading through, it's apparent that it seems to conflate advice for UAs and sites or people collecting data
… I would say it's probably more than hafl of the recommendations apply to sites?
… so if you don't want to remove advice for sites, separating it out to two major sections would make it a lot easier for people implementing UA features
… that might mitigate the problem of being too much
… and teasing apart.. example in section 2.9... says system designer shsould.. then gives examples of only things services can do
<charlieharrison> +1 to separate out site guidance
<bmay> robin: I think that is true, but I'm also getting asked for an email address by most websites I visit.
<charlieharrison> this goes to what we discussed earlier about focused guides
DKA: if you see things that could be more clearly stated and we're conflating concepts, please raise an issue on the document!
… one of the feedback points we've heard, which is actionable, is to take that list at the bottom and bring it up to the top? and and split it up into lists that are applicable to each particular persona who might be reading the doc
… definitely something we can do
bmay: thanks everyone who worked on this to date
… Recommend to everyone who is nterested in the subject to get involved. We're in a position where people are losing confidnec ein the web, if we can make the web trustworthy again that would be best for everyone
reillyg: in the beginning of the document it says it's expanding on the privacy from the EWP
… the title of that is "security and privacy are essential"
… is the next task to do this for security
DKA: maybe
jyasskin: I think there's less confusion about security
… there's more consensus
… I think we're missing a threat model for the web. Security people agree and haven't written it down
… that's a webappsec working item
<chaals> [+1 we think we understand security better than privacy]
jyasskin: Thanks all for coming, please send patches
RRSAgent please make minutes
<chaals> [I think people who know and care distrust the Web, but that's because it's an IT system and they are generally seen as not being trustworthy]
<chaals> [normal people talk about how much they no longer trust their phones. And who trusts a modern electric car?]