Create 2022-03-09-minutes.md

meetings/2022-03-09-minutes.md

@@ -0,0 +1,179 @@
+# TAG Privacy TF Call 
+
+Wed, 9 March 2022
+
+Present: Dan, Don, Wendy, Jeffrey, Sam, Robin, Nick, Christine, Amy
+Regrets: Pete
+
+## Minutes
+
+### Outcomes from Last Week / Jeffrey's List of Outstanding items
+
+**Jeffrey's annotated list from [last week's minutes](https://github.com/w3ctag/privacy-principles/blob/main/meetings/2022-03-02-minutes.md#summary)**
+
+* Data minimization (collection, exposure, and retention) (https://github.com/w3ctag/privacy-principles/issues/23)
+* no party should have access to a significant chunk of someone’s browsing history (TODO)
+* Purpose limitation (TODO)
+* Informed, meaningful consent (https://w3ctag.github.io/privacy-principles/#consent-principles)
+* User rights on un-owned devices (https://github.com/w3ctag/privacy-principles/issues/2)
+* User participation: access, correction, deletion (https://w3ctag.github.io/privacy-principles/#data-rights, https://github.com/w3ctag/privacy-principles/pull/136)
+* Ability to have anonymous and ephemeral interactions (https://github.com/w3ctag/privacy-principles/issues/120 ?)
+* Data security: encrypted, confidential, authenticated (https://w3ctag.github.io/ethical-web-principles/#privacy?)
+* Don’t try to distinguish personal data from non-personal: it’s all likely to be personal somehow (TODO)
+* Identity separation (https://w3ctag.github.io/privacy-principles/#identity)
+* Accountability: compliance & visibility (https://w3ctag.github.io/privacy-principles/#transparency)
+* Make identification and personalization visible (TODO)
+* Automation and delegation of privacy work (https://github.com/w3ctag/privacy-principles/issues/81), including to parents/guardians (https://w3ctag.github.io/privacy-principles/#guardians-and-owners)
+* Being let alone: quiet, free from interruption, ending communications (https://w3ctag.github.io/privacy-principles/#principles-for-notifications-and-interruptions)
+* Really Good Reason principle for exemptions (https://github.com/w3ctag/privacy-principles/issues/137)
+* Privacy from whom: not just the service, but from other users, friends and family, or from governments (TODO)
+* Collective privacy (https://github.com/w3ctag/privacy-principles/pull/130)
+* Beneficial misrepresentations (TODO) 
+
+### [expanding section on data rights](https://github.com/w3ctag/privacy-principles/pull/136)
+
+Nick: I took advice to add examples, and got comments from Jeffrey on the PR that I've tried to address
+
+Jeffrey: I'm happy with updates
+
+Robin: looks great, made a few small comments, nothing blocking.
+
+Nick: most open question was whether we should include the text right to be forgotten and maybe later we have to deal with other implications, or if we'd rather not have it
+
+Robin: I'd rather this document not have to decide whether people using privacy rights to remove themselves from search engines is a good or a bad practice, or whether companies having courts to arbitrate these things is good or bad. Preference to stay away, but not a hard core preferece.
+
+Christine: [..] the term right to be forgotten because it implies a human characteristic to machinery. Really it's about a right to have data deleted or removed from searching. I prefer that we be more precise than use the emotive language, but I understand that's what the EU calls it. I'd have to look at the text closely.. I can't say right now if we can avoid using it. If we use right to be forgotten we should be clear it's not literally a right to be forgotten.
+
+Nick: the current text has it as "sometimes described as a right to be forgotten" but it's not necessary for the point that we have to include that. The data right we're talking about is the right to erase data about oneself. Which will still lead to potentially complicated questions about other rights or how to implement it, like many privacy things, implementing is more difficult. 
+
+Robin: to be clear, on the EU thing, GDPR cals it right to erasure and only mentions it as right to be forgotten as the colloquial phrase that might be attached
+
+Jeffrey: interesting phrasing - right to erase data about oneself, and the next paragraph implies it's data you've put in the system, but it's much broader, it's the controversial right to be forgotten. I think we will imply reasonable things if we delete the right to be forgotten part, but we may want to refine this later and talk about when do you get to delete data someone else has entered. If someone else has entered your contact info it's reasonable to delete that, but news articles are much more controversial. We could leave it ambiguous.
+
+Nick: I intentionally had that exmaple, the most common and important implementation is you should be able to erase data you entered. That's functionality that mostly doesn't exist that needs to exist. But there are subsequent more complicated decisions.
+
+Dan: suggest adding the word colloquially, or striking the phrase. If even the GDPR legislation doesn't actually call it right to be forgotten then maybe it's not a good idea for us to be promoting the imprecise newsy phrase.
+
+Nick: Yeah, hearing we could just delete that clause. We're maybe still going to have the complicated questions come up anyway, but don't need to be in the definition.
+
+Robin: sounds good to me
+
+Nick: I can take that. Otherwise good to merge?
+
+### [notifications](https://github.com/w3ctag/privacy-principles/pull/132)
+
+Jeffrey: [on quality metric] it reflects what we're [Chrome] doing - not always showing the permission request. If you have a history of interacting with the page then it will pop up the notification request otherwise it gets minimized in the URL bar.  We don't disallow sites from requesting permissions but make it less *interrupty*.
+
+Dan: I changed the wording to "unlikely to have sufficient knowledge" in place of "on first visit" and included an example. Leaves mitigations up to the user agent. Qualifies the idea of quality metric.. tries to indicate what the problem currently is where people are being asked for notification permissions the minute theya rrive at a site, while trying to define that more abstractly
+
+Jeffrey: instead of warning about malicious use, what we're more likely to do is demote the request. Interrupt user less. Possible we attach a warning once the user opens it up again, but more likely we'd hide it or make it less visible.
+
+Nick: is this guidance on one particular spec - web notifications - or is there more general advice?
+
+Dan: it should be about interruptive UI, that's what it says at the top. Notifications and interruptions. Notifications are a kind of general topic, not just push  notifications, but about any kind of interruptive UI that browser is responsible for. Push notifications have a special place because they show up outisde of the browser context, in the devices ntifications tray, and can put alerts on the users home screen etc. But there are other kinds of interruptive UI that this may apply to as well
+
+Nick: sounds good. Wasn't sure if the current text made it clear it's general
+
+Dan: if you think there should be additional wording in the first paragraph, that makes it more clear then make a suggestion
+
+Jeffrey: I think this is not sufficiently general, but it's good enough thta we should merge it and improve it in a subsequent PR. There's interrupty UI when a page asks for you to sign up for their email list by poppoing something up in the middle. Other things inside the webpage that dont involve browsers at all but are still bad practice.
+
+Dan: I'll make a note on slack when I think it's ready to merge
+
+### [collective](https://github.com/w3ctag/privacy-principles/pull/130)
+
+Robin: haven't finished updates
+
+### [Add section on principles for vulnerable people](https://github.com/w3ctag/privacy-principles/pull/114)
+
+Nick: I thought Tess was trying to draft that section?
+
+Dan: discussion 2 weeks ago.. Tess was going to work on it
+
+### [Discuss appropriate use of data to prevent abuse.](https://github.com/w3ctag/privacy-principles/pull/105)
+
+Jeffrey: controversial, and possible we should subsume it into [137](https://github.com/w3ctag/privacy-principles/issues/137). Pete said he has concerns. And conerns bout appropriate use of data to prevent abuse.
+
+Pete's comments: 
+
+> Heres some points I wanted to raise though around Jeffrey’s great list.
+> 
+> * I appreciate the idea, but im still concerned with any kind of “Really Good Reason principle exception” text.  Everyone collecting data thinks (or at least says) their use is important and good and vital.  I think “escape hatch” text (without at least very tight constraints around it) will bottom out in having a PING-or-TAG-like body decide whether each use is “really good”, in which case we’re back where we started.
+> 
+> * This might be part of “Don’t try to distinguish personal data from non-personal: it’s all likely to be personal somehow” or “purpose limitation” (or some other point) but I think its important to capture a principal of data collection only being appropriate when its “predictable and consented to”. We had text around this in the (prior?) “Unwanted Profiling” section, and I just wanted to make sure that concept wasn’t lost in the reorg
+
+Dan: Not sure if relevant - interesting to me that for instance there have been a lot of people in UK gov recently calling for backdoors to crypto and decrying the need for end to end crypto, but now we're suddenly in a war and Russia has been clsoing off access to things like facebook and twitter, people are now saying oh great we have Tor and vpns and we can enable people to get to the news sources they need.. there's no irony, people are not understanding [it's the same encryption]. If you're a social network in Russia and you get hit by an order to expose the private messages of peple that were speaking positively about Ukraine so that those people can be thrown in jail, the company that provides that service might be compelled to think that such a reason is good and vital. Just as much as exposing abuse, child predation, all this kind of stuff. It really brings to mind a little bit of we need to be really careful. I'm sympathetic to x's view.
+
+Christine: Jeffrey I appreciate that you were using shorthand and didn't mean it literally, but I want to make sure we're careful not to talk about overriding privacy. I think it needs to be a little bit more.. we need to make sure we're more sophisticated. Sometimes the privacy mitigations or outcomes may need to be adapted but it's not one or the other. I also agree with Pete and Dan about the dangers of saying well if you've got a good reason that's okay.
+
+Wendy: Similarly the nuane that I was trying to convey was .. opposite shading, We're not talking about absolutes. In cases where people are seeking an excepiton it needs to be justified and privacy should be the default. Rather than the positive if you've got a really good reason you can run over privacy. I think it's more we recognise there are many different principles that need to be balanced and sometimes the reasoning can justify what seems like a less privacy sensitive response
+
+Nick: I want to figure out what we're potentially doing in response to this good conversation. There are some things in the document already saying this document is just about privacy and you're going to have to look elsewhere for this decision about balaning. Few architectural principles are absolute, privacy can come into tension, something in the very first paragraph about not addressing balancing different principles if they come into conflict. Maybe I'd like to update those to use Wendy's suggestion about recommendations coming into conflict not th eprinciples into conflict. Do we need to elabroate, or are we saying this really good reason idea .. a paragraph saying recommendations can come into conflict and we won't address that, and nothing else in the document? Or we need to have reasoning on either collection of data for anti abuse because we think that is another way of protecting privacy, or the right to be forgotten reasons where we think misinformation or somethign requires some collection or use of data.
+
+Robin: All good points. What degree are we running up against tensions between individual and collective decision making? A lot of what we're saying here is .. one thing is that privacy is rules about the flow of information, about people or impacts people, and if we say that who gets to decide those rules? By bodies such as this one and a whoel bunch of others, that might in some cases say it's fine for data to be shared, or fine to prevent the sharing of data under such circumstanecs> those decision making bodies and situations will require balancing tests, and the result of that is still privacy, because we said privacy is those rules even if data gets shared. At the same time, if we're saying it's okay for a group to make these decisions, maybe tomorrow the IAB takes over browsers and gets to say broadcasting data to 300 thid parties is actually okay because the social benefits outweigh the potential individual harms or something liek that. I don't know how to resolve or properly document that tension. I don't think we can completely exclude it because we say privacy is about rules. I want to enable the PAT CG for instance to say it's okay for a tiny fraction of a bit to leak for attribution pruposes becuase this is purpose constrained under these conditions. That's the tension we're up against and I'm not sure how to address it
+
+Dan: is there a way to slice this by not giving a general get out clause? Pete's concern is about a general get out clause of it's okay to ignore anything ihere if you have a really good reason. Vs trying to narrowly address the specific issue of preventing abuse?
+
+Jeffrey: we need this less if we don't talk about the right to be forgotten. Adding the generalistic exception si why I filed this issue, becuase I wanted ot refer to it in comenting on the right to be forgotten. Without that I think the stuff we already have is enough, saying stuff gets balanced elsewhere. We should still go through the how do you balance the privacy considerations section. Not perfect. I do disagree with Pete's implication that it's bad if PING and TAG have to discuss privacy in the future. This document is not going to free the authorititative bodies from having discusisons and arbirating disagreemnts, but will eliminate some discussions by lettin gpeople answer the questions themselves and provide some ground rules. We can't plan to get rid of them entirely.
+
+Dan: proposing to mulch this PR?
+
+Jeffrey: no. 137 the issue, it's plausible to say this document is sufficient. But we still have 105 about how to balance and that's important.
+
+Jeffrey: Nick endorsed Wendy's comment about conflicting conseuqnences rather than conflicting principles. Current text in the PR accomplishes that. Sometimes the most obvious response to one privacy principle is in tension with another. Not exactly about responses, but it does talk about what response do we have 
+
+Robin: I'm not sure I got the tradeoff that you propose
+
+Jeffrey: the original text said sometimes one privacy principle is in tension with another privacy principle. Wendy suggested we talk about responses to principles, rather than the principles being in tension, so here's a sentence that tries to accomplish that. How do people feel about it?
+
+Nick: not sure everyone is going to like "the most obvious response". I think I know what you mean - there are different ways to implement, different responses to a priniple, and sometimes there's going to be one that's in conflict with the responses to another principle. I don't know if most obvious is always going to be how those people describe that
+
+Jeffrey: often privacy reviewers are presented with a proposal but that is not the best proposal, but the best from someone's perspective. We need to talk about that one as not the ultimate response, but the one you got first..
+
+Nick: Wendy had comments about use of... ??
+
+Christine: does the note cover what you were trying to say in the first sentence?
+
+Robin: isn't that two different things? Blanacing principles and balancing privacy vs other things. I don't think it's trying to be the same thing.
+
+Christine: I see what you mean. Concerned about talking about balancing privacy principles. Generally are meant to work together. Offhand I can't think where you'd have to balance privacy principles. 
+
+Robin: Example - seeking consent can decrease autonomy
+
+Jeffrey: three examples at the bottom of this section that try to illustrate where different privacy principles come into tension
+
+Robin: maybe we can start from what Christine was saying ot shift this and say that privacy principles are designed to work together and in cases when they come into tension yada yada that people try to iterate on the solution
+
+Christine: you go to.. what is the spirit? to protect the users privacy. So you choose the solution that is likely to offer the best protection
+
+Jeffrey: which user?
+
+Christine: generally works on the basis that you treat each individual at this point in time. Privacy is very individualistic. If you're using the service it's you.
+
+Robin: we return to the tension with collective needs that says i fyou're protecting the privacy of the person who will want to harass others, you might be protecting the privacy of the wrong user
+
+Dan: [suggesting we look at the wording in ethical principles]
+
+>Thus in applying these principles, there are benefits and tradeoffs that may need to be carefully balanced. When faced with principles which appear to be in conflict with one another, it is important to consider the context in which a particular technology is being applied, the expected audience(s) for the technology, who the technology benefits and who it may disadvantage, and any power dynamics involved (see also the priority of constituencies).
+
+Christine: I understand
+
+Robin: it's a good first step to say peopel come first. 
+
+Christine: certainly peopel who are being attacked come before the attacker
+
+Dan: We can't make all deicsions for people. We grappled with an issue on EWP this week where people were asking us for a roadmap for how do you decide when principles are in conflict, how do you resolve the conflict. We said this is not in scope for our document to tell people. Because it's so contextual. There's a point of diminishing return about the level of specificity we can provide here. We're not giving people an algorithm about how to get better privacy. It's a set of principles. People need to at some point apply critical thinking and contextualise those principles to the user groups that they're addressing, or to the problem space they're addressing.
+
+Wendy: Important discussion. Jeffrey and Christine are highlithing ways the document may be read in ways we do not intend. If we're too absolute we're going to get dismissed by those building commercial products and may have needs that come into conflict with some of the absolute privacy. Christine is pointing out if we say there is a gap in privacy others will try to drive a truck through that gap. I'm not sure how much we can find a consensus on iin this document. Being aware of potential misreadings and trying to set some guardrails and keeping people in the sapce of reasonable approaches to privacy... 
+
+Robin: consensus I'm hearing is people need to be responsible..
+
+Dan: something like that
+
+Jeffrey: i can take another stab at this section, I will need help at some point.
+
+Robin: I think we're converging, thanks for iterating
+
+Nick: appreciate that sometimes there appears to be a tradeoff but look for designs that don't have those conflicts. And change the title, we're not balancing principles because it's often conflicts of responses rather than principles
+
+Dan: simple language is something we need to help make the document more accessible