Create 2024-10-23-minutes.md

meetings/2024-10-23-minutes.md

@@ -0,0 +1,192 @@
+# TAG Privacy TF Minutes - Wed 23 October 2024
+
+Present: Dan, Don, Pete, Jeffrey, Wendy, Nick
+Regrets: Tara, Christine, Robin
+
+## Formal Objection Proposed Changes
+
+https://lists.w3.org/Archives/Public/public-review-comments/2024Sep/0013.html
+
+Jeffrey: *had a conversation with the objector at TPAC - all linked from https://github.com/w3ctag/privacy-principles/issues/431*
+
+Dan: Overall goal is to minimize the things we need to talk about in context.
+
+### https://github.com/w3ctag/privacy-principles/pull/443 *moves principles to top* 
+
+Pete: is it purely copy-paste move?
+
+Jeffrey: this is supposed to just move things ... And I also numbered the principles.
+
+*we agree to merge this*
+
+### https://github.com/w3ctag/privacy-principles/pull/432 true intent
+
+Pete: fine with drop true
+
+Don: fine with dropping "true" but not *processing consented to*...
+
+Jeffrey: completion trouble one way, privacy trouble the other way...
+
+Peter: drop everything after the comma?
+
+*we massage the text*
+
+Nick: I think we should keep "intent to consent"... I'm ok with dropping the rest of the sentence. 
+
+Don: happiest with removing the word *true* and not changing the end of the sentence.
+
+Jeffrey: Ok I'll do that.
+
+### https://github.com/w3ctag/privacy-principles/pull/433 Say who should enforcement mechanism
+
+*we agree to merge*
+
+### https://github.com/w3ctag/privacy-principles/pull/434 Explain an implication of the vulnerability section.
+
+*adds a sentence saying someone should do something*
+
+Pete: I'm fine with it though it sounds redundant.
+
+Dan: let's merge it.
+
+*no objections so we merge*
+
+### https://github.com/w3ctag/privacy-principles/pull/435 
+
+Jeffrey: this emphasises 
+
+*merged*
+
+### https://github.com/w3ctag/privacy-principles/pull/436 Discuss sites that users pay for with data.
+
+Jeffrey: some discussions on this one... We could adopt Don's text:
+
+> some sites offer an informed, free and fair exchange of appropriate user information for original content they create or pay for the creation of, and denying access to users who choose not to participate in such an exchange is not retaliation.
+
+Don: if the objector wants us to acknowledge other ...
+
+*general happiness with Don's text*
+
+### https://github.com/w3ctag/privacy-principles/pull/437 Explain how a "3 visits free" model can be compatible with the identity principle.
+
+Peter: we've already got text...
+
+Nick: we could design a mechanism where you don't have to 
+
+Dan: this doesn't addresses cases like a library computer ... multiple users.
+
+Don: imagine it's a school principal checking a school computer... the principal sees the the machine ...
+
+Nick: they could also keep track of which web sites you visit.
+
+Wendy: is this also intended to address "privacy pass" etc...
+
+Don: even clearing info ...
+
+Jeffrey: admins have more access...
+
+Nick: when we talked about this - I shared that we don't want to encourage this approach. The goal is to say "there could be mechanisms like this" ... but would still enable some kind of token-based system...
+
+*lack of consensus to merge this*
+
+### https://github.com/w3ctag/privacy-principles/pull/438 renaming ancillary
+
+Nick: thas has come up multiple times... I came up with "ancillary" but many people think it is a pejorative... so they get upset.  So we could just describe it as "supporting" rather than ancillary.
+
+Pete: distinction - supporting user goals vs. web site goals APIs... 
+
+Dan: who was the feedback from?
+
+Nick: webperf people and anti-fraud people...
+
+Dan: I like ancillary
+
+Wendy: I like ancillary...  maybe adding some more text in the intro ... to make it clear that ancillary data can be 'needed'. 
+
+Pete: the web falls apart if you remove DOM apis in a way that it doesn't if you remove the [perf] APIs...
+
+Jeffrey: I'll do it as a separate PR...
+
+Dan: maybe circle back to the people you talked to...
+
+### https://github.com/w3ctag/privacy-principles/pull/439 Add payment as an example ancillary API.
+
+Pete: confusing a timing API vs a "I want to buy a book" API seems confusing... 
+
+Dan: payment seems essentials for some sites...
+
+Nick: what about pay for site access?
+
+Pete: timing APIs seem categorically different from payment...
+
+Jeffrey: a micropayment API might be ancillary... Web payments API is not ancillary so we don't have to list it here.
+
+Wendy: find it confusing
+
+*no consensus to merge*
+
+### https://github.com/w3ctag/privacy-principles/pull/440 Mention tradeoffs inherent in building designed-for-purpose APIs. 
+
+Jeffrey: this reminds people to look at the design principles...
+
+Pete: seems it doesn't add much but no objection
+
+Nick: also think it doesn't add much but also find it's useful.  Not a big change.
+
+Don: looks fine to me.
+
+*agree to merge*
+
+### https://github.com/w3ctag/privacy-principles/pull/430 Remove redundant line
+
+Jeffrey: removes redundant text...  Editorial.
+
+*consensus to merge*
+
+### https://github.com/w3ctag/privacy-principles/pull/441 Mention local regulations in de-identified data section.
+
+Jeffrey: the objector wants us to mention regulations. I don't think it changes anything and it doesn't hurt.
+
+Pete: I would like to not have this... might be some bad juridsciction that has a bad definition of de-identified.
+
+Don: I agree with Pete - if you run it it through a weak de-identification system is it OK? We don't have to cover the regulatory side.
+
+Jeffrey: the regulation may go beyond what we've said... .. so calling it out - potentially useful.
+
+Nick: we do something similar with "fiduciary." 
+
+Jeffrey: we could say "more specific requirements"
+
+Pete: don't like it but if it resolve the objection it's OK
+
+Don: same
+
+Pete: what about user agents? *pete to send new PR*
+
+Wendy: should we say "these regulations should not set a ceiling for de-identification privacy" ... *wendy to suggest tweaks in PR*
+
+Dom: I would be more excited about it...
+
+Nick: in general we haven't used this doc to comment on insufficienty of regulation...
+
+*agree to ask Robin to review and merge if it's happy with it*
+
+### https://github.com/w3ctag/privacy-principles/pull/442 Say users can say whether pieces of information are sensitive. 
+
+Pete: do you mean "adjust"...
+
+Jeffrey: yes that was intentional... some that are not usually sensitive might be sensitive to certain people... 
+
+Pete: I would like to not make this change... 
+
+Jeffrey: i don't think this implies...  when you post your location to a public web site you're declaring that it's not sensitive to you...
+
+Don: big difference between making a statement of fact about yourself and having something about you "processed". 
+
+Nick: maybe the example we should think about - non-standard system fonts - by default we need to consider it's sensitive... 
+
+*some wordsmithing*
+
+Pete: i don't think this sentence is necessary ... if it helps to get it through the process then we can continue to refine but rather just drop it...
+
+*we assign Pete & Don to noodle if there is good text here*