Meeting minutes
<wseltzer> Draft agenda:
<Michael_L> +present
<weiler> preset+
Wendy: Hi folks, my apologies for the late agenda
… thought I had sent it out before the holiday weekend
Wendy: our agenda for today
… curation and introductions; concluding slides for the Kittecn Cluster discussion from Michael Lysack
… introduction to Sand Piper from Mark Lee
… and if we get there dashboard hightlights
… and a question from Arnaud on FLoC origin trial
… and to open the queue
… and any other business
… Aran, you wanted to suggest and item
<Zakim> AramZS, you wanted to add agenda item - review of detailed use case template
Aram: I just wanted to note, after our previous conversation from two meetings ago, I put together a detailed use case document
… addressing some concerns, and making things sortable
… won't go into detail now but wanted to add to the agenda
<AramZS> Here is the PR: https://
Wendy: If you have a link
… thank you
Agenda-curation, introductions
Wendy: Busy agenda, let's get started
… Do we have any introductions, new participants?
Concluding slides for Kitten Cluster [from Michael Lysak] https://github.com/carbondmp/Kitten_Cluster/blob/main/README.md
Wendy: Let's hear more about Kitten Cluster. Michael, are you all set to show the remaining slides?
Michael_L: can everyone see screnn?
s/screen
Michael_L: I wanted to wrap up with the first "snake", the biggest issue to be discussed, addressed, revealed
… it's the half-baked bread problem
… If you have baked bread, you have a lot of dough to make more bread at another time
… If you are not competent at baking bread
… and you want to cook something for yourself
… go somewhere, an hour, and you have frozen dough
… you can do nothing, find something else to eat, with dough in freezer
… or take dough out quickly and microwave it
… but you cook it in microwaving it, and you have a worse situation
… than if you put in no effort
… you either finish task correctly, or not do it
… because middle state is worse
… so let's look at the overarching privacy definiting
s/definition
… not sure if anyone is supporting it, but just for an example
[reads definition]
… "the guaranteed kill of all tracking"
… sounds private on the face of it
… a legitimate definition that someone might have of privacy
… so question is could there be a consequence like the 'half-baked bread' problem
… Example
… on right, tracking methods used by almost any adtech company
… everyone who tracks uses more than one method
… for redundancy
… on left are methods that can only be implemented by browsers
… they can track you across the web and have the same or more tracking
… half baked bread problem is that the privacy proposals, with elimination of cross-site tracking [and others]
… would result in all tracking metchanisms on the right to disappear
… but not the tracking on the left
… a user's info could be sold to whoever can track it
… if it's not sold
… programmatic will only exist when tracking methods exist
… we're not lawyers, just looking at the technical problem
… but it's a clear tech problem
… if we only work on the tracking methods on the right, we have not solved the overarching privacy problem
… We have told them we created a more private Internet
… but only some company types can execute tracking; so it's half-baked bread
… we should move forward with privacy work, but question is when we should put them on
… perhaps not put all the tracking on at same time unless there are solutions
… one, we have a technical prevention to left side
… and release at same time
… or, we could have an auditing method
… perhaps release at same time to prevent it from happening
… or, the overarching privacy definition is impossible
… so perhaps we implement safeguards
… there is this weird dependency that ties multiple (five at least) proposals together
… before we release these we should consider if we are making things worse
… We have an ethical obligation to consider
… as everyone who works in dev knows, the prototype usually ends up in production
… So the half-baked privacy issue
… which is highlighted in the Kitten Cluster
… we don't want to slow down discussions
… and not put in one or another proposal, but now we have one place
… So in conclusion, Kitten Cluster provides privacy definitions
… is it privacy according to itself
… overarching proposal unity analysis [red/bllue background example]
… and contrary proposal analysis
… This will help us with all the proposal
… make sure it's positive for the web and doesn't break anything
… Happy to take questions now that we did not get to last week
<joshua_koran> @weiler - I believe his point is we should not make the web worse by trying to release "half baked bread" - rather than boiling the ocean
<wseltzer> https://
Wendy: A repository is now available, at link I put into the minutes
… do you want issues raised there?
Michael_L: I would definitely like folks to contribute if they are willing
… I researched and refined privacy definitions
… for folks with made definitions, I would like folks to submit those
… and definitely like comments
… and to take questions now
Wendy: Any questions or comments
… we had some good discussion last time
<joshua_koran> sorry phone just died
<joshua_koran> my question is related to the point raised by weiler
<joshua_koran> should we wait until we have perfect complete solution before releasing improvements (say seatbelts for autos
<joshua_koran> must wait until we have airbags
Michael_L: I see Sam had a question
… Joshua had something related to Sam's question
… Sam you were saying perfect is enemy of the good
… but we should not release something that is worse than not releasing anything at all
… saying we should wait to make sure it makes the web better
… and block tracking only for certain company types, but not others, and same info is still release
… you are right we should not wait for a perfect solutions, but we should create a positive for privacy
Aram: I think that your explanation starts with the assumption that the current status quo is sufficient
… and better we delay and not make something half-way there
… because the current stuff is good
… But if you frame it as the current stuff is not good, or unethical
… then the core argument is disputed
… we should get some effort and progress than wait
… and agree not everyone will agree
… for something perceived as inherently bad
… this is detailed and I appreciated your perspectie
… but I don't see this as a neutral perspective
Michael_L: I am not saying this is not acceptable; we are in high water
… let's not throw food out window, or throw someone overboard
Aram: I think it really depends on what you see as "throwing out the food"
… if all the food is poisonous, better to throw it all out now
… than continue to poison ourselves
… I see your perspective
… trying to get to the perfect is inherently conflicting with some of participants view as current state being urgently broken
Michael_L: I understand where you are coming from, but I disagree; the data is still on a server and being sold to everyone
… worried that some of perspective you mentioned, is that some of companies will benefit
… I respect the view on privacy
… whoever's suspicion's are correct, and let's assume the best
… hopefully will be revealed and we can make the best decisions
Sam: Apologize with leaving only hints of question not asked
… I appreciate, Michael, your encouragement to look at ecosystem effects
… that's something engineers should be doing
… Telling someone not to release until the whole thing is done
… I have seen it used as stop energy
… hope it's not being used here
… in the privacy IG
… looking at finger printing surface
… we ask them to mitigate as it comes through
… engineering reason because technical debt is hard to repay
… something to be learned from that
… pleased to see us chipping off bits of the problem
Michael_L: you make a good point, Sam
… if PING only works from one definition of privacy, such as finger printing, then it's better for it to get started
… So if W3 is going to do that...I agree, tech debt is a problem
… we moved this to a different repository so as not distract from current work and not arrest engery
… but also don't want to run off a cliff
… best way to stop tech debt is to clearly define what we are doing
… it will be easier to figure out which direction we are going
Wendy: Thanks, Robin
Robin: Quickly, not getting into rest of details
… I would like to challenge the assumption that we would like to not prefer parts of ecosystem over the others
… It's clear that it puts AdTech intermediaries at the top, then @ and publishers
<jrosewell> Consensus is important across w3c. Agreeing the problem seems a good place to start.
Robin: it should be users, publishers, advertisers, and then intermediaries
<jrosewell> Who speaks on behalf of users / people at W3C?
Robin: any attempt to progress since system is toxic to users and publishers
Michael_L: users don't benefit from 'half-baked bread' problem
… smaller publishers that make money from programmatic
… will be hurt because all will go to browser-based tracking
… you are right that we have to think about users
… we have to think about publishers and the smaller publishers will be hurt by this
Robin: There are multiple fallacies
… is it the same thing to be tracked by 300 vs a few companies
… operating under assumption that subscription publishers don't need advertising
… those subscriptions come from advertising; couldn't be further from truth
… no world where subscription publishers are shielded from advertising
… we all rely on same ecosystem, which is why we need it to work better today
… we cannot guarantee trust in ecosystem and to protect users from third-parties
… anything we can do is progress
<jrosewell> Any publisher can choose their suppliers.
Michael_L: I understand you are more trustful of the current browser methods
… blocking pipes doesn't stop flow into pool
… you are right that even subscription companies still need a thriving advertising ecosystem
<jrosewell> Michael's point was also about small publishers. They have fewer options compared to NYT and others
Michael_L: but my concern is that small publishers will be really hurt
… Would love for W3C to do survey with small publishers
<jrosewell> https://
Michael_L: would be something great we could do
Robin: as someone who talks to small publishers, they are eager to have their audiences not stolen by third parties
… it's still audiences
Michael_L: agree that's a concern for small publishers who don't want their audiences to be stolen
Wendy: Thanks, Michael for giving us this framework for discussion
… hope people will go more into the issues
Sand Piper [from Mark Lee] https://github.com/carbondmp/sandpiper
Wendy: and use this where it can be helpful
… Move on next to discussion of Sand Piper
… Mark, please go ahead
<jrosewell> Would be good to get Sam and PING to establish input from a wider group of wen stakeholders on privacy to support w3c understanding.
Mark: going off of that
… this is less philosophical, and more of a technical question
… we believe that cookies are not inherently bad
… a different statement
… say that is that cookies store state for a stateless protocol
<arnaud_blanchard> @robin what do you think of publishers getting erased from reporting because they do not have enough traffic ? this is obviously a clear disadvantage based on size, and one that i'm sure smaller publishers won't celebrate as an improvement
Mark: they support businesses of all sizes
… and they have been used since the beginning
… But there are some problems
… they are an easy target; unconrolled; problem since the beginning
… even cookies bypass entirely; data leaks, IP matching, finger printing
… there is stuff and other ways of doing things
… We wanted to understand more about users want
… an interesting article
… on a 2020 research study that was done; really enlightening
… users want some online targeting
… they want benefits
… but their spontaneous concern is the use of the data
… once they see what can be done; which is right
Mark: recognition that users pay with intention and data for other services
… but it's not necessarily the way that they want it
… Good article to read
… what they want is personalization, with transparency and control
… Leaning on what was said before with users, publishers, etc. order
… Users want ability to exert control over who has access to data [reads rest of slide]
… Publishers want transparency and control
… I took step of doing an initial Kitten
… there is data; approach definition of privacy within context of proposal
… more around concept of control over who has access to storage over non-breaking method
… Overview - see world with cookies or equivalent that won't break other stuff outside of adtech
… but make it privacy-compliant way
… make use of existing certificate infrastructure, and use existing secure methods
… not break Internet and support Open Web
… balance needs of user, publisher and advertiser
… zoom out a bit
… think about adtech, but think about total effect on other apps and tech outside our purview
… why?
… what HTTP was from get-go, as a stateless protocol
… some of proposals want JS to be only way to store and retrieve state
… forces JS to do a bunch of things
<robin> arnaud_blanchard: that can be a concern, but it's going to remain a very abstract conversation unless you 1) put numbers on the scale you're talking about and 2) put a definition on publishers
Mark: to emulate behavior done in HTTP request response
… we want to find a way that is transparent, clear, and compliant with privacy
… but easier way to do it
… We looked at how we can do something
… what it came down to is extending the HTTP protocol to define first and third-party sandboxes
<robin> arnaud_blanchard: in work I've done with publishers at the really small end of the spectrum, for publishers in the news/opinion space they seem to get much better results with sponsorships than with open market
Mark: trust by leveraging certificates
… SSL certs are backbone
… of how it wors
… Certs are the de facto method of ensuring this is browser
s/valid
… if we have browsers on this, would support ability for users to override and to have fine grain control
… takes it from hiding in the ethers and to be visible
… they can see what is going on
… these sandboxes declare how data can be shared across contexts
… whether first or third party
… allows data movement to be checked
… being declared; we can override it, extend into other discussions
… since we are using public-private pairs
… not fully fleshed out
… but most important part is it is backwards compatible with the least amount of change
… that still moves us forward toward our goal
… can do this with HTTP headers and the sandboxes
… we have the start of this [chart]
… browser makes calls, gets cookies from storage and returns it
… we are saying instead of making complicated
… within cert itself, the action baked into that cert, as part of hand shake
… we allow publishers to declare that against the cert
… it opens up that context
… or browser sandbox
… Doesn't break other concepts; domain is still equal to its other world
… like a first party set type structure
… where it goes
… allow my first party sandbox and domains within it
… nothing has to be done; through load balancers and web servers
… come back with, I'm allowing this third party sandbox; and I am publishers X, tying back to @
… have storage be available for x and y
… communicate invite in as first party and all have to follow rules as I am owner of this sandbox
… all have same context, how web works now
… not changing expected behavior
… [chart]
… as a publishers, i have this analytics things
… I can set in my context
… gives us ability to do this nice and simple and transparent
… This can also work for outside of our world
… Defeat purpose of CDNs
… let's say JQuery was...in CDN, can invite third-party into your sandbox
… and allow caching in my shared context
… definite that very clearly within those headers
… Just to keep it clear and simple
… our view is cookies are not nec bad; users want transparency and control
… we tried to balance this; make sure it's backwards compatible
… give users and publishers to override these settings; browsers can say no
… define who is allowed to use data in their context
… we have publicly exposed the repo on Sand Piper
… this might be good on its own, or with first party sets
… Want to open up to questions
<jrosewell_> Importantly this proposal is the first that could support data sharing based on data controller / processor arrangements highlighted by others
<wseltzer> https://
<wseltzer> https://
<Zakim> kleber, you wanted to point out Chrome's partitioned cookies proposal https://
Kleber: hello, thank you
<kleber> https://
Kleber: this is Michael Kleber from Chrome
… First, I would like to point out a proposal called CHIPS
… you may not familiar with it
… about a way to maintain partitioned cookie states
… uses cookie read and methodology
… third party cookies not global; single third party sees a different cookie jar
… sounds similar to some of the use cases you mentioned
Mark: I would love to take a look
Kleber: You mentioned our first party sets work
<kleber> https://
Kleber: when we were working on first party sets, there was a proposal to use HTTP ehaders
… link in chat is an insightful comment from @
… he is on certificate browser forum
… explains why reusing cert data has been problemmatic in past and why it's not a good way to use that infrastructure
… I'll stop there
Mark: I appreciate that and will take a look at all of those
kris_Chapman: This is not a direct comment to your presentation, but more of a plea for folks
… here at Salesforce, we're not adtech, but we are concerned about privacy use cases beyond advertising
… for those of us worried, we need to raise these issues
… A, we talk about them here, and not in PING or Privacy CG
… where we might have fuller exposure
… I am concerned where we are at in the timeline, we are losing time by not engaging and filing issues on the current proposals
… and talking things here while the clock is ticking down
<Zakim> AramZS, you wanted to note that this is a browser feature that is opposed to principles stated by Safari and Mozilla and would be extremely easy to block and t/f unlikely to be implemented in a state close to the one proposed.
kris_Chapman: if folks have use cases you are worried about, encourage you to post
… that's it, thanks
Mark: Good points, absolutely
AramZS: I will +1 to Kris
… the things most likely to be implemented we should return to discussing, especially where we see they are in conflict in theiBG
… see additional queuing going on
… this proposal is in conflict with stated positions of Mozilla and Safari
… I cannot speak for them
… but considering they have a variety of other proposals, seems unlikely they will tend to it
<jrosewell_> Web browsers need to pause to enable unintended consequences to be sorted out and broader thinking to be developed.
AramZS: feel like this would be better to discuss as an issue rather than a new thing
… if people want to discuss issues; but seems unlikely to be adopted
<jrosewell_> Positions of private companies are interesting but shouldn't colour thinking in standards work. Otherwise 2 companies control the agenda and work.
Mark: To your point, it could be adopted as an issue
… presented as a separate proposal because it has other issues and be less impactful way to implement close to what we are trying to get to without a lot of work
… we can definitely bring it into other conversations
Michael_L: A general question on Kris' point; I was raising questions on some of these points, and was told to go elsewhere
… concerned that questions being raised are being dropped
… use cases...go where?
… what is instruction for where things belong?
Wendy: Sure, that sounds like a W3C level question
… I will go back to the way this group and other of our groups are operating
… This group is a discussion forum and information gathering point
… All of these proposals have been welcome discussions to help others where to focus their attention, how to raise questions
… and they tend to move to CGs, or WGs for further development
… in that case, when it is in a CG, following the rule that the chairs and editors want for how it would proceed
… if we chartered a W3C Working Group, that would follow the Process Doc
… if we took something to a chartered WG, all of this discussion helps us to define the scope; what fit in that group and what should be discussed elsewhere
<jrosewell_> I agree with Michael L. Experienced W3C operatives encourage bouncing issues from forum to forum.
Wendy: and W3C in determining what to make a Recommendation, would listen to the AC, TAG, horizontal review groups including PING, Security, Accessibility and i18N, the public and wide
review
… all of those inputs would have their chance at consideration
… the immediate where is discussion happening, is governed by the rule of each of the groups that it is in
Kris: Just respond
… I have submitted issues and gotten feedback of 'this is not the right proposal'
… but generalized, found there is some direction given as to where to raise it
<AramZS> Can we prioritize FLoC at the top of next week's list since the origin trial is ending by the meeting following the next one?
Kris: frankly, it's sort of like that saying that 'God answer all prayers, and sometimes the answer is No"
… I would say I have a very different view of what is @
.,..versus John W.
<wseltzer> [yes, will put FLoC on the next agenda]
s/trackingtracking
… I would not ask John to change what Apple is doing
… we can discuss and raise our POV here
… but for active progress, the browsers are in the weeds already
… it's pretty much what they are engaged in
… they have been working on this stuff at least a year or more
… and I don't think it will get derailed
… would ike to see us put energy into what is progressing, rather than halting or reconsidering
… I just don't think that will be successful
<jrosewell_> But John W. works for a web browser so his position is more "important" than other w3c members. That's wrong for a body that states the web is for everyone
<AramZS> +1 again to Kris
Robert: thanks, Wendy
… thanks for this proposal
… I really like proposals which are thinking about the multi-domains
<robin> it's a pretty good idea when suggesting a browser feature to put it in user story form such that "As a user I want to…"
Robert: publishers running on network and in multiple domains
… I don't get into all the techniques
… but I appreciate that this is on the agenda
… although people don't like policies
… it is important to talk about the needs of publishers worldwide
<jrosewell_> Both people and authors (publishers) come before browser vendors in w3c priority constituents.
Robert: If you build the world wide web publishing network, that would not help
… should continue to be an open discussion
… From Axel-Springer, we own many assets and domains
… this needs to be respected, important to us
Wendy: thanks, Robert
… hope you are getting your needs into use cases.
… Mark, any summary?
Mark: Will take in the discussion, look at where it may go into other issues
… but we wanted to show backwards compatibility; love to get positive, negative feedback or anything in between
Wendy; Thank you both for presentations; see next week to put FLoC on the agenda
… and look at use cases and pull requests
… thanks and see you next week
<wseltzer> [adjourned]