Create 2023-10-25-minutes.md

meetings/2023-10-25-minutes.md

@@ -0,0 +1,179 @@
+# Privacy TF Minutes - Wed, 25 Oct 2023
+
+* Present: Jeffrey, Don, Robin, Amy, Nick
+* Regrets: Wendy, Dan, Christine, Pete
+* Scribe: Amy
+
+## [PRs](https://github.com/w3ctag/privacy-principles/pulls?q=is%3Aopen+is%3Apr+sort%3Acreated-asc)
+
+None are ready to discuss. We closed https://github.com/w3ctag/privacy-principles/pull/321 because its components were all merged.
+
+## [Issue triage](https://github.com/w3ctag/privacy-principles/issues?q=is%3Aopen+is%3Aissue+no%3Aassignee+-label%3Abackburner)
+
+### [Wide Review #217](https://github.com/w3ctag/privacy-principles/issues/217)
+
+Robin: I think we've reached out to everyone
+
+Jeffrey: Have we asked ad agencies?
+
+Robin: Don sent a message to Web ads group, is that everyone?
+
+Don: yes it's a big group, and have reached out to people so they don't miss it[]
+
+[update issue to clarify ad people have been contacted and close]
+
+Robin: I'll close this issue.
+
+### [#220 ancilliary data](https://github.com/w3ctag/privacy-principles/issues/220)
+
+[assign Jeffrey and Pete]
+
+### [#271 Environment Integrity](https://github.com/w3ctag/privacy-principles/issues/271)
+
+Robin: worth doing, willing to take a stab at it
+
+Jeffrey: I shouldn't
+
+### [#272 opt-out/preference registries](https://github.com/w3ctag/privacy-principles/issues/272)
+
+Robin: didn't I make a PR? #294 it's approved, closing
+
+### [#276 supercookies](https://github.com/w3ctag/privacy-principles/issues/276)
+
+Jeffrey: we did something..
+
+Robin: we no longer talk about supercookies
+
+Jeffrey: Removed by PR 340
+
+### [#277 Header enrichment?](https://github.com/w3ctag/privacy-principles/issues/277)
+
+Robin: we no longer talk about this
+
+Nick: did we move these somewhere else?
+
+Robin: the terms aren't in the draft
+
+Jeffrey: PR 340
+
+Nick: I'll open an issue on the threat model, so it's not forgotten
+
+### Copy editing
+
+Robin: for a number of those we can say they have been copyedited.... eg. stuff in C-F, and material before section 1 might not need more than a glance over
+
+Jeffrey: propose we close C-F [#319](https://github.com/w3ctag/privacy-principles/issues/319), 3 are auto generated and acknowledgements looks fine
+
+Robin: [closes]
+
+Jeffrey: propose Robin takes [#301](https://github.com/w3ctag/privacy-principles/issues/301) and I'll take [#308](https://github.com/w3ctag/privacy-principles/issues/308) and #317
+
+Robin: do we believe B needs copyediting?
+
+Jeffrey: did we talk about removing B?
+
+Robin: could be in the threat model document
+
+Jeffrey: and it's too vague and an RFC already
+
+Nick: also got that feedback
+
+Robin: all the references to 6973 are in that section
+
+Jeffrey: we may be able to cite from some sections which cite this section
+
+Nick: are there any?
+
+Jeffrey: a couple used to...  Surveillence and disclosure and correlation are mentioned from elsewhere
+
+Robin: [updates #318]
+
+Jeffrey: #341 is about removing, close copy editing issue
+
+Nick: it's used as definition for things in intro, which is appropriate place to cite RFC6973
+
+Robin: feel like sections before section 1 have been copyedited multiple times over #297
+
+Jeffrey: could benefit from another once over, probably a small task
+
+Robin: I'll do #297
+
+Don: can take #306
+
+### [#357 Breadth of consultation](https://github.com/w3ctag/privacy-principles/issues/357)
+
+Robin: reply about wide cross section of users including advertising industry
+
+Nick: and say we're still accepting comments, and will solicit more from the Advisory Committee, which includes different sectors of industry
+
+### [#330 definition for abuse](https://github.com/w3ctag/privacy-principles/issues/330)
+
+Leave for someone who isn't here
+
+### [#329 purpose limitation principle](https://github.com/w3ctag/privacy-principles/issues/329)
+
+Nick: suggestion is discuss purpose limitation. If you concent to processing for one thing it's supposed to only be used for that thing and not other things. We implicitly talk about that in things like consent, but maybe we should be explicit
+
+Jeffrey: we should explicitly say that
+
+Nick: can do but not soon (in a week or two)
+
+### [#343 javascript one](https://github.com/w3ctag/privacy-principles/issues/343)
+
+Robin: takes that
+
+### [#335 markup examples](https://github.com/w3ctag/privacy-principles/issues/335)
+
+assigned to Jeffrey
+
+### [#345 vulnerability](https://github.com/w3ctag/privacy-principles/issues/345)
+
+Jeffrey: might be wrong in how I was reading these... when I was doing slides for tpac the sections basically say the same thing. Suspect there's more to say about vulnerability so maybe the answer is write something about vulnerability that isn't just about not retaliating? what's there seems redundant
+
+Robin: feels like they shouldn't be merged, but if they're similar should be made different
+
+Jeffrey: could remove the principle and leave the text? Maybe it's just the principles that collide
+
+Robin: makes sense. Then vulnerability would have to move somewhere else. Under section 1 somewhere?
+
+Jeffrey: and guardians also doesn't have a principle. Fine moving these two sections into section 1
+
+Jeffrey: Updated https://github.com/w3ctag/privacy-principles/issues/345, and I can do this text movement.
+
+### [#351 collective privacy](https://github.com/w3ctag/privacy-principles/issues/351)
+
+Robin: Nick suggested a change... can you do it? Text looks good to me :rocket:
+
+Nick: okay
+
+### [#352 features for responsive design](https://github.com/w3ctag/privacy-principles/issues/352)
+
+Robin: sounds like it belongs in fingerprinting guidence.. I endorse Nick's wisdom
+
+Jeffrey: yes
+
+Nick: can open
+
+### [#353 device owners](https://github.com/w3ctag/privacy-principles/issues/353)
+
+Jeffrey: came up at tpac. In chrome you can log in with a corporate account which gives that corporation some control over that profile, but you might be on your own device and they don't get control over the device. These are two different considerations. not sure we should go into that much detail in thie privacy principles document
+
+Robin: maybe noting that they are distinct...? agree we don't need a full discussion of nuances
+
+Jeffrey: it's not like a UA owner, administering the profile but nothing about ownership
+
+Nick: prefer not to introduce the concept of a software owner
+
+Don: so many levels at which this stuff gets administered.. you can have a personally owned machine that has a management agent from the company you're doing a contract for, and a browser profile you're logged into -- the combinatorial explosion of who owns and adminsters the device, who administers the vpn or security software or whatever on the device, how the user agent is administered and managed would make this section long and unusably complicated if we tried to address all the possible combinations.
+
+Nick: maybe we should mention administration? seems like a generic and common category. Sometimes there's someone who administers some part ofyour configuration.
+
+Don: maybe owners and administrators?
+
+Nick: yeah
+
+Jeffrey: yeah, if we can do this in one sentence it's worth doing. We already say owners and administrators. The question is the two levels of administrators.. only worth one sentence. I'll do it.
+
+### [#360 Transparency](https://github.com/w3ctag/privacy-principles/issues/360)
+
+We'll ask one of the absent people to take this.