Create 2023-09-06-minutes.md

meetings/2023-09-06-minutes.md

@@ -0,0 +1,111 @@
+# TAG Privacy Task Force Call - 6 September 2023
+
+Present: Wendy, Amy, Dan, Don, Nick (& Forest), Jeffery, Christine, Robin
+Regrets: Sam
+
+## https://github.com/w3ctag/privacy-principles/pull/324
+
+Amy: I think it's fine.
+
+Dan: we unconsolidated some of the consolidations and wanted to make sure Amy was fine with that.
+
+Pete: Defining minimization - seems backwards - user agents should send as little data as necessary to achieve user goals.
+
+Jeffrey: there are two principles. ONe is about data transfer, one is for designing apis. You have to design apis to support that
+
+Pete: web apis should be designed to minimize data sites need to request.. doesn't seem to do that for me..
+
+Dan: I think it does. From the perspective of web api design that come up for design review and we want to be able to point those people at something. it may need additional wording.. otherwise we don't have something to point spec designers at that says they need to design for data minimization
+
+Amy: I think there's a high-level principle about data minimization.... There's a high level principle. And these are implementation details...
+
+Dan: uas and other actors should minimize the amount of personal data they transfer is the first one. Web apis should be designed to... that's the thing that helps us make reviews better because we can say hey web api designer to design your api such that it adheres to this principle. And then UAs should share [...] wishes and interests. 
+
+Amy: i agree but we can point API designers when it's one principle that covers all caes... 
+
+Dan: Nick suggesteds the principles should be on one actor
+
+Nick: it seemed likely to get confused that a principle starting with sites and UAs would get missed as something that spec authors should do, and having that as a princple seems valuable
+
+Dan: that resonates with me. It gives people explicit instructions.
+
+Pete: that's not my concern, targeting towards the author vs the UA. Just seems awkward to me to say that you have to minimize the amount of information that sites need to reuqest. Is this an aesthetic concern or a substnative one? Is another way of saying the same principle - web apis should only return the minimal amount of information needed? What is it to minimize the amount sites need to request?
+
+Nick: a common situation that the api is designed to return the entire address book, or ... we say don't do that, just request the one thing
+
+Pete: seems like good advice. But that we should say apis should only return to a site the information needed to carry out the user's goals
+
+Nick: that is what the earlier text said but it got shortened
+
+Jeffrey: how does the browser know what the user's goal is? The site has to tell it. The user wants me to have all this data and the site only wants a tiny piece of that, the site needs to communicate that, so the site can accurately represent the user's goals to the browser
+
+Pete: I  don't disagree but I don't see how that hooks into this
+
+Jeffrey: when the site is representing the users goals to the browser the web api is designed so that the site requests data that matches what the site says the user needs> We often design apis that make the site request too much data, more than the site wants or the user needs the site to have, and so this is trying to say don't design it that way so the site can request the minimal amount of data.
+
+Nick: previous version was longer, maybe we should revert to it
+
+Dan: I'm happy with that
+
+Don: the site's representation of the user's goal may not be correct.. users do visit a certain % of sites they didn't intend to. The site may claim the user wants to share a bunch of information with me when actually the user clicked on something by mistake
+
+Jeffrey: web api design can't help with lying sites, but we can allow the honest sites to request what they need
+
+Don: we need to make sure that we can't 100% trust that what the site says about the user's goals and the user's actual goals are the same
+
+Pete: do we consider ancilliary data as personal data in this document?
+
+Nick: yes
+
+Pete: good
+
+Jeffrey: it may be amibiguous
+
+[merged]
+
+## https://github.com/w3ctag/privacy-principles/pull/325
+
+Jeffrey: Yoav's comments are on the original version of the text, not this PR - I need to sit down with him to address those comments, but we can merge the PR without dealing with that yet
+
+[working through editorial suggestions]
+
+[merged]
+
+## https://github.com/w3ctag/privacy-principles/pull/334
+
+Jeffrey: merge conflict...
+
+Jeffrey: the change to definition of automation asymmetry would require other changes as it collides with another
+
+Robin: I agree that the definition in the consent section could be worked on. I do think it's closer than this one though. I'd suggest we make an issue to improve the definition of automation asymmetry but don't make this change
+
+Jeffrey: that works for me
+
+Robin: [makes issue]()
+
+[discussion of editorial changes]
+
+
+Jeffrey: can we remove the bit about FIPS?
+
+Pete: agree
+
+Robin: experience with lawyers and lawmakers think this is fine and a good framework.. 
+
+Dan: can it be compressed to half the size?
+
+Don: I think there are going to be some readers skimming this document so if we have extra mentions of FIPs as being inadequate (or inappropriate) that's not going to be wasted. Looking at some of the day to day privacy compliance stuff, from the point of view of someone who is doing privacy compliance as a checklist task then avoiding doing that on the basis of FIPs is a huge win
+
+Robin: FIPS are the state of the art outside of computer research labs, and they're very bad
+
+Jeffrey: suggest keeping a lot of the discussion and make it an example. But don't want to block this PR on that discussion
+
+Robin: I've created issue #347 to compress the discussion
+
+Nick: I think the FIPS are fine, the text should say implementation is bad...
+
+[ready to merge when git conflicts are resolved]
+
+
+
+