diff --git a/meetings/2023-11-15-minutes.md b/meetings/2023-11-15-minutes.md new file mode 100644 index 00000000..5155effb --- /dev/null +++ b/meetings/2023-11-15-minutes.md @@ -0,0 +1,90 @@ +# TAG Privacy TF Minutes - Wed, 15 November 2023 + +Present: Dan, Don, Nick, Jeffrey +Regrets: Pete, Amy, Wendy + +## [device admins](https://github.com/w3ctag/privacy-principles/pull/368) + +Jeffrey: removes assumption that admins are admins to the whole device... we may not be able to enforce... but still worth saying it. Most admins want the UA to have an implementation of the thing they want to do - but ... + +Don: most admins won't modify the core UA code, so a notice to users that the UA is administered will be useful (even though an administrator with enough time and skill could remove it) + +Nick: I still think it's useful ... however it's not a guarantee. + +Dan: I feel it could be stronger... + +Jeffrey: merge and then continue to edit? + +...even when disclosure to administrator is reasonable, user must be made aware + +*some editing ensues* + +*looks good, merging.* + +## [Ancillary Data](https://github.com/w3ctag/privacy-principles/pull/361) + +Nick: I think I still have some open items in here... I don't know the particular benefit over the existing text... Exhausted. + +(Asking Pete for asynchronous review, as some of us thought that was the next step.) + +Jeffrey: We could ask the TAG to pick among multiple versions... we can make this as good as we can make it before giving it to them... I think I would be fine with not changing the text at all.. but Pete doesn't like the heuristics - reasonable objection. There was request to the web perf folks for more percise text. This is what came back. + +Nick: I think the TAG is the next stop anyway, so that seems reasonable; what does the TAG chair think? + +Dan: seems clearer than last time I read through this section. don't prefer the "disagreement/lack of consensus" sections. + +Jeffrey: [Web Perf group starting to employ the proposed text]( https://docs.google.com/document/d/1hsAx_VLCKyr2I0u22vdDvo-9liF8CxAo5VC2jcOEqQw/edit#heading=h.7zk49ci3rj0f), and mitigating additional data with differential privacy + +Dan: I think this wording is clearer. + +Nick: my substantive concern... distinguishing between novel and non-novel is a harmful pattern... + +Jeffrey: I made some chanegs in that direction... Happy to keep re-wording in that direction... + +Don: Is it about novel vs. non-novel or intended vs unintended? [The Mozilla anti-tracking policy refers to "unintended identification techniques"]( https://wiki.mozilla.org/Security/Anti_tracking_policy#3._Tracking_via_unintended_identification_techniques). There are some APIs where the user has control - others where the control isn't exposed to the user... Whether or not a user actually changes those controls, the theoretical "is this something you could turn off" might be a better dividing line. + +Nick: we couldn't get agreement on "users should be able to turn these off"... + +Jeffrey: (eg) even if you can't turn off geoloc .. + +... most of their stuff is "you got a DOM event about this image loading and when did that happen?" "when did you get animation frames and did you miss any of them?" you can't turn that off as a user and that's the kind of thing they are summarizing most of the time. + +Dan: we can encourage API developers to fix their issues for subsequent versions and notify them that they will be asked about it for future TAG review... + +## https://github.com/w3ctag/privacy-principles/pull/369 + +Jeffrey: Robin should review it... + +## RFC 2119 language? + +Nick: sometimes we say must and sometimes should... do we mean to use 2119 terms? + +Jeffrey: I have been thinking ... almost all of this is appropriately shoould. Places that we say must we should double check. Worth checking. + +*nick to open an issue and we can do a review* + +## data minimization https://github.com/w3ctag/privacy-principles/issues/370 + +Nick: Yoav opened an issue... + +*issue of sensitive data vs non-sensitve data* + +Jeffrey: don't know what we can do about considering the general agreement that all data might be sensitive. + +Nick: we have wording "don't assume that data isn't sensitive" - we do explain how to determine if data is sensitive. We also explain that data min is important because we don't know... how sensitive. + +Jeffrey: we say "don't send info that doesn't meet the user's goals"... Yoav is pointing out that web perf often needs data apart from data that directly meets user's goals... + +Don: as soon as we have parties that can infer one piece of data from another, trying to tag as sensitive/non-sensitive is not going to work. Machine learning could reconstruct sensitive data points from non-sensitive ones, and if a data point is both sensitive and valuable, parties have an incentive to improve ML. + +Jeffrey: when we talk about "send only data that serves user needs" then perf folks will say "this data is necessary to serve a user need of performance..." There is an argument to serve a user need... + +Don: some of this make assumptions of the composition of a site as the user sees it as first and third parties together... *troubleshooting performance problem where you don't know which 3rd party code is going to be on the page at the time you design the page* + +Nicl: I understand the concern about the get-out ... that's the actual decision we want users and their agents to be making... How much benefit do I get out of [the extra data]? Big benefit then OK. Not so big than maybe not. Let the agent decide... The reason that minimization is important beyond the user's interest is the justification... there can be risks of data being exposed / misused / over-collected and that can be beyond the particular decision that the user is trying to make about whether they want to take a particular action. + +Jeffrey to propose some text in Slack to explain that we believe the motivation is described as best we can, for review by Dan and others. + +We may meet next Wednesday for those who are available. + +[adjourned]