<AramZS> It isn't a w3c document right?

<kleber> Right

<AramZS> Can we link the PING document into the minutes please?

<kleber> PING draft privacy threat model: https://w3cping.github.io/privacy-threat-model/

<kleber> @ jrosewell I think "first party good, third party bad" is deeply mischaracterizing the PING threat model doc

wseltzer:W3C Business Groups and Community Groups are discussion and incubation fora.
Only Working Groups can produce W3C Recommendations.
Working and Interest Groups can be chartered to produce consensus documents.

jrosewell: anyone can propose a group?

wseltzer: the membership reviews charters, and votes

jrosewell: If we need a formally chartered group to put these issuse into a formal review, let's start that chartering discussion

AramZS: I've given feedback to the document
... there's a question of mode
... we've been having dicussioncs
... I don't think we're going to reach a conclusion "this standard is wrong"
... rather, a set of guidelines for evaluation
... a way we can enter conversations on proposals where they're occurring
... In the context of this group, there's disagreement as to what we'd consider success
... I don't think the division is a bad thing

<joshua_koran> +1 Aram - the goal of the doc was to help proposal authors to explain why their change to the web is a net benefit, with full understanding of positive/negative impacts to various stakeholders

AramZS: we're not going to come to single criterion for proposals
... so perhaps it makes sense to propose a different group that's focused on modifying proposed standards
... in this group, digging into reasoning behind reactions to proposals

jrosewell: thanks for your contributions Aram
... the document isn't aiming to say good/bad, but force proposer to think through issues

AramZS: useful to bring out different viewpoints, not as a filter for standards
... if you want a filter, need a different group, to the extent any group can
... the Apple and Firefox documents aren't W3C documents, they're opinions of private organizations
... W3C can't define privacy and force private companies to use its definition
... but rather to present thinking and explanation

wbaker_: Verizon believes W3C is a magical place where we can talk about interop and what's being built and what's coming next
... natural prioritization, those who are building code are building the future, and we're here to learn about that future
... what gets built is what matters
... the legalistic tradeoffs aren't what brings us here

<Chapell> sorry

<apascoe> microphone didn't work.

<Chapell> will dial in you can't here me

apascoe: we talked about success criteria, and don't think it's the most useful path

apascoe: I'm much more interested in the details of fleshing out the proposals and how they fit with advertising use cases

<AramZS> Yes, I think we can handle the conversation about this purely via PR process atm

apascoe: can we table this discussion?

Chapell: understand the frustration among people who want to get into the substance of discussion
... disconnect
... some people see the function of the group is to give feedback on proposals
... others think it's to come to consensus

<jrosewell> apascoe : shouldn't we settle questions around the location and control of cohorts conceptually before we implement anything?

Chapell: define the problems we're trying to solve

https://www.w3.org/2020/05/WebAdvBackgrounder.pdf

<joshua_koran> If I undestood Alan's point, the question to the group is whether this is trying to agree on what would improve web advertising OR it is just heads up notice from developers' companies as to what they will unilaterally decide

<AramZS> I mean... @wseltzer can you note for the record so we're sure? This is not a standards writing group, correct? Also: Is there a Private Ads WG yet?

<dialtone> 36 minutes gone on this topic :(

wseltzer: pointing to slide 6 ^
... can suggest other group options for consensus documents

<AramZS> Ok, cool. Thanks, that is what I thought

<apascoe> jrosewell: we haven't moved into any implementation because the specifications are not fully specified. working abstractly and conceptually is not typically that useful when initially discussing engineering ideas.

<Chapell> @joshua_koran, yes.... what is the harm to just stating that this BG is for the marketplace to provide input and learn more about what Chrome is creating?

<AramZS> I mean... also Chrome is not the only one creating this technology, just to be clear

jrosewell: can we have a side discussion on next steps?

wseltzer: sure, I'll put a call on the mailing list

Issue digests [dialtone]: group ideas on how to gather issue digests?

<AramZS> Perhaps we want to vote on agenda items in the future?

Simulate reporting options for publisher and advertisers

<lukwlodarczyk> <#

<wbaker_> +1 @kleber

arnaud_blanchard: we had a good discussion on github
... want to get more empirical
... see some analysis on tradeoff between privacy and other consdierations

<Chapell> @AramZS, are other browsers also creating this technology? I thought Chrome was the only browser considering Turtledove, Sparrow, etc?

arnaud_blanchard: we provided some scripts
... to simulate thresholding and differential privacy
... we'd like to get some feedback on those
... how we could bring that forward for advertisers and publishers

<AramZS> Both Firefox and Apple are creating relevant privacy preserving ad-related technology. Some good examples: isLoggedIn and attribution proposals

arnaud_blanchard: for them to use these simulations and see the effect on their day-to-day operations
... and provide feedback
... scripts are linked in the github issue

<kris_chapman> @Chapell, yes, other browsers are doing similar things

<Chapell> @AramZS, are those being discussed within this BG?

arnaud_blanchard: with a blogpost-style discussion
... you can adapt them to any data-set to simulate results

<AramZS> They have been in the past @Chapell

charlieharrison: I took a brief look through the scripts for differential privacy

<kleber> @Chapell TURTLEDOVE+SPARROW moved into WICG on the basis of Marcos from Firefox also saying it sounded like something that warranted further exploration: https://discourse.wicg.io/t/advertising-to-interest-groups-without-tracking/4565/17

charlieharrison: general approach seems ok, though I didn't do a full code review

<Chapell> @kris_chapman, my understanding is that the other browsers have created those technologies and discussed them in other w3c groups but not this one

charlieharrison: Stress that the privacy parameters make a big difference
... would be interesting for people to tweak the epsilon, effective sensitivity
... that are currently hardcoded in the scripts
... getting a sense of privacy-utility tradeoff

<AramZS> Oh yes, please can we see those?

charlieharrison: Secondly, Google has some open-source tools to produce differentially private releases of data
... might be interesting to look at that software.

<btsavage> can you please link to those?

charlieharrison: I'll share a link

<piwanczak> Charlie could you please link it in the chag?

arnaud_blanchard: one factor that matters, how easy is it to use for non-technical users

<alextcone> Charlie, is this what you are referencing? https://developers.googleblog.com/2019/09/enabling-developers-and-organizations.html

arnaud_blanchard: we're trying to share with less technical participants

charlieharrison: not sure how easy they are, but could be used as backend to a frontend

<charlieharrison> Alex: yes that's the one

<jrosewell> @kleber, @chapell : Yet FLoC (https://discourse.wicg.io/t/proposal-federated-learning-of-cohorts-floc/4473) moved to extensive coding without such an endorsement (https://chromium-review.googlesource.com/c/chromium/src/+/2240873). Presents the impression of a "done deal" compared to other proposals.

bleparmentier: thanks charlieharrison. We chose the defaults from reviewing various explainers
... that suggested 1 as the highest acceptable
... Definitely encourage people to experiment.
... delta-F aimed to be conservative
... think it will help people to see what might be reported, consider the tradeoffs in actual reports

<kleber> Regarding values for epsilon, I'll note that in https://github.com/csharrison/aggregate-reporting-api/issues/12 charlieharrison responded to your question by saying "The numbers that are referenced in that paper could be seen as a reasonable starting point for experimentation, though we are also exploring larger values too."

charlieharrison: in discussion of epsilon, suggested to start conservatively, but didn't want to draw a line in the sand
... start seeing what high privacy levels would look like for this data
... re Sensitivity, I talk about protecting a record vs protecting a user's entire contribution
... there's a relaxation of full DP, where we talk about protecting a single sensitive event
... distinct from whether the user did anything at all
... if full contribution protection leads to too much noise, we can talk about record-level privacy
... could think about protecting sensitive events
... as you bring closer to one, gets nearer to record-level privacy
... happy to follow up on list

wseltzer: thanks for that tool

btsavage: maybe we should be more considerate of ideas where from formal DP perspective is greater than 1

<bleparmentier> +1

btsavage: e.g. private click measurement, analyzed from DP perspective, has infinite epsilon,
... though I think we'd agree it has good privacy property
... so DP isn't the only privacy measure

charlieharrison: agree with btsavage
... DP is only one privacy measurement, often the worst-case scenario
... we're thinking abuot dividing the concept of cross-site linking
... into a set that is measurable by DP
... and the very worst threats we want to prevent
... iterating on threats in PING document
... also looking for other ways to measure privacy benefits of API

bleparmentier: that's why we proposed mechanism that's not DP, but we think offers privacy benefit
... not so protective that it provides no useful information
... we can have very private mechanism that aren't DP but work well
... something actionable

kleber: Agree DP is a useful tool for measuring some things; not for measuring others

<btsavage> charlieharrison can you link to the doc you mentioned where you analyze the various risks?

kleber: the SPARROW discussion didn't primarily focus on DP
... but rather specifically on ways that information about a specific user could be transferred
... across sites
... Whether or not DP is the right tool, we do need to look at practical threats

charlieharrison: when it comes to data that can be linked to an individual, in any proposal
... it's important whether there's any plausible deniability
... 2 mechanisms: limiting the information and its identifying-ness
... e.g. used in the event-level API, thresholding
... that doesn't add deniability
... Noise is crucial if we want to achieve deniability, let user say "I wasn't on that sensitive site"
... else you could imagine ways that a small number of users could be tracked with 100% accuracy
... DP is giving you reassurance of plausible deniability
... "no, actually that was noise"
... that's a strong property, making identity-joining harder
... DP's qualitative difference

bleparmentier: SPARROW v2 gives way to change easily the way you identify individual user
... difficult to pull off
... but trying to forbid this kind of attack means there's no actionable reporting because the noise is too high
... important to consider actual and theoretical threats
... theoretical comfort could kill the utility of reporting
... don't think this small residual threat should drive the proposal

wseltzer: I have a few actions, including to follow up on the issues with our connections to this call.

[adjourned]