18 Aug 2021
Present: Tess, Christine, Jonathan, Pete, Robin, Sam, Wendy, Jeffrey
Scribe: Robin
Chair: Jeffrey
JY: This overlaps with #26, you talked about this last week. Is there more?
RB: We generally agreed that this seemed like a good idea.
JY: We had a question in Google about whether we should use "data controller" to define this, but we weren't sure.
CR: We spent time on terminology in general.
JY: Ready to merge?
PS: Is this talk later or controversial forever?
JY: It's talk later.
RB: We should try to get to the consensus thing.
TO: We should probably leave it unmerged for now.
JY: I think this is good?
RB: Yeah.
Tess to merge #17.
TO: Merged!
CR: First sentence: Change “control” to “express a preference for what processing is done to their data”.
RB: Agreed.
CR: Second sentence: “uses” would seem more relevant in this context than “purposes”, or perhaps “uses and/or purposes”.
RB: I'm trying to parse out what use is if it's not processing/means or purpose.
CR: Consent is to the means of the purposes.
RB: I think we agree, it's a question of mapping the definitions.
JY: I think it makes sense but we'll need to define use or figure out the definition.
WS: Do we really want to define opt-in/out in this way?
CR: We need to consider that, yes.
Group — let's see what we all think next week.
CR: great site for dark patterns
CR : Also thought about tiers, interesting approach. But should vulnerable people have to opt out, that is a problem. Also there are issues about choosing to opt out.
RB: Yes, vulnerable people should be out automatically, though it incentivises not knowing. And choice is problematic.
JY: The names optin/out are problematic, we should change that.
CR: Permissions are important, we should bring them in.
JY: You're right that we should try, not sure how but yes.
RB: Agreed.
JY: Similar to privacy goals vs how browser can enforce them.
CR: The document suggests that users will be recognised but users might not expect that their whole behaviour is kept.
RB: I think there's a third thing which is profiling.
CR: Yes, but I think that there is a fine line between behaviour and profiling, we have to be careful about that.
RB: Agreed.
JY: I'm nervous about blanket saying "do not expect tracking of previous interactions", also recommending content is a form of profiling.
CR: Users might expect maintenance of state for different purposes (cart, identity) but not others. But I agree we might need to revisit the section. This opens the question of whether we need a section on same-site tracking.
JY: I think yes.
CR: We might want to have recommendations for this section, we don't have them now. Nick's work does have some best practices for "unwanted same-site" and for tracking.
JY: Right, we can't just subsume this into the identity section, fingerprinting belongs here.
RB: I wonder how far we can go with guidance but it would be interesting to grapple with it.
CR: There is something already in the @@?
JY: I can take a stab at some of that, I'd appreciate someone else taking a stab at same-site.
PS: I can dot that.
WS: While reading the doc from the perspective of somebody controlling data rather than the user, a solve might be as simple as "pseudonymous with respect to the first party"
RB: That works for me!
JY: Pseudonymous data and pseudonymous for a party (which may be the first) might be usefully distinguished.
RB: Agreed, ongoing rewrite.
JY: We might not have anything new?
CR: Section of document that pulled out privacy issues from the IETF document. It's been a while since that doc was created, we might want to define and describe them in W3C space. The doc talks about stored data compromise — I think we could expand that to data compromise at large, including in transit.
JY: SGTM. I will PR.
RB: Nothing new since the meeting, it's all stuff I have to do.