present=
Michael_Vinson: Comscore
jrosewell:[James followed up by email to request insertion of this text]
I’ve been a member of the W3C and this group for nearly 4 months. When we discussed the purpose of this group some weeks back there were broadly two distinct views.
1. Onward communicates information from other W3C groups and browser vendors.
2. The group advances standards and changes to the web to improve the web advertising ecosystem and liaise with other W3C groups.
The mission statement for the group, on the W3C web site, covers both views.
https://www.w3.org/community/web-adv/
It even allows for new groups to be created. Many participants paid substantial fees to be part of this specific group. There is no doubt the group does have a mandate within the W3C to identify standards and changes.
Some have expressed the view the success criteria not relevant. I’d like to settle their future in this item.
Therefore, some method of evaluating competing proposals within the group, and in time across the W3C, is required. For example, last week the debate raised the following questions;
a) which party or parties can access different types of data;
b) who controls the logic associated with the construction of cohorts; and
c) what does a “level playing field” look like?
The proposed success criteria provide a method of identifying how various proposals impact different stakeholder interests, without applying judgment as to whether these impacts are a net improvement. By asking proposal authors to acknowledge
these impacts, my hope is that this will help us more rapidly advance the conversation so that we can stay focused on the net improvement to web advertising, the title of the group.
Participants in this group have pointed to the HTML Design Principles as defining the order of constituents.
https://dev.w3.org/html5/html-design-principles/#priority-of-constituencies
These read as;
“In case of conflict, consider users over authors over implementors over specifiers over theoretical purity”.
This means the W3C prioritise constituents in order as.
1. People and societies (users)
2. Publishers, advertisers, and their supply chain (authors)
3. Browser vendors (implementors)
4. Specification writers (specifiers)
5. Theoretical purity
People and societies are placed at the heart of the success criteria followed by publishers, advertisers and their supply chains, then browser vendors.
My company, 51Degrees, is not an ad tech business. We do provide web focused technologies and data. Perhaps we are a supply chain vendor whose customers include publishers, brands and ad tech as well as finance, insurance, travel, technology
and retail organizations.
We’ve become concerned with the way some companies are interpreting the meaning of privacy in a self-serving way, breaking established standards of interoperability, and using the W3C to present an impression of legitimacy to the outside
world. If is for this reason I signed a letter to the W3C AB raising concerns over W3C governance and people’s trust choices. A small group meet with the AB on 6th August with an agenda to agree the extent of these issues and how to work towards a method of
addressing them.
Last week, when I asked for more input into the success criteria, I received in the IRC links to Mozilla, Apple and a PING draft document.
Mozilla: https://wiki.mozilla.org/Security/Anti_tracking_policy
WebKit: https://webkit.org/tracking-prevention-policy/
Ping: https://w3cping.github.io/privacy-threat-model/
I was familiar with Mozilla and Apple’s documents but hadn’t considered consulting them in the construction of the success criteria or since joining the W3C. I have now re-read them.
Apple’s tracking prevention policy is incompatible with the purpose of the W3C. Under “unintended consequences” it explicitly discriminates against 11 use cases and the stakeholders who operate in these sectors. The W3C do not, and should
not, prioritise one concern over another in this way.
Mozilla’s, and any other companies that use the same rationale, are similarly incompatible with the W3C’s mission. Hopefully all W3C members and participants here today support the concept of One Web. Thus, we should not pursue any “standards” that would make some web sites work on some browsers, while other browsers will not.
If Google are similarly progressing down this route then it is more important than ever that the W3C implement a set of policies covering the full set of stakeholder needs and wants.
Turning the PING document. It is in the same unofficial draft state as the success criteria. It lists High-level threats which overlap with the harms considered in success criteria. It does not currently consider the benefits of a feature
against the threat it poses. Identical to the success criteria it references the Security and Privacy Self-Questionnaire.
https://www.w3.org/TR/security-privacy-questionnaire/#threats
For those not familiar with Security and Privacy document it provides a series of questions that a specification author (the middle group in the list of constituents) should answer before submitting a proposal.
All W3C values, not just privacy and security, should be assessed in the same way. It is for this reason, following advice from Brad Lassey, I split out the issues of interoperability, choice, accessibility and accountability into a
second document. Therefore, when I talk about success criteria I mean both documents.
https://github.com/w3c/web-advertising/blob/master/success-criteria.md
https://github.com/w3c/web-advertising/blob/master/interoperability-choice-accessibility-accountability-questionairre.md
Generally, across the W3C there is a myopic view of privacy. The Security and Privacy documents adopt an approach of the “first party” is good, and the “third party” is bad, without any explanation as to why first-parties can never harm
people. They don’t address key privacy issues, such as providing enhanced auditability. I have not once seen any document focused on accountability, which would help inform people of any actual harms suffered, no matter whether the party was a first party
or a third party, such as a browser.
For all these reasons the success criteria documents are more important than ever. Internet Advertising Bureau Europe have recognised this within their Taskforce.
More contributors continue to come forward with further thoughts.
One deserves particular recognition from an anonymous contributor who advised the issues we’re discussing here are the same as those associated with land ownership in Britain over 500 years ago. Here’s a link to the subject.
https://en.wikipedia.org/wiki/Tragedy_of_the_commons
https://www.thelandmagazine.org.uk/articles/short-history-enclosure-britain
It’s a very interesting history lesson for those with the time to read it. I’ll leave it for you to decide which parties we’re all analogous to and whether the outcomes we now influence will be judged good or bad 100 years from now.
I have not incorporated it into the documents.
Anyway we now have two questions.
1. I had original thought writing down the principles we could collectively use to evaluate many proposals was both in keeping with W3C precedent and good governance. However, I’m confused as I’ve been told that some participants
don’t want to follow this route. Some members like Verizon have said the purpose of this group is merely to receive advanced warning from Google. That’s not how Google advertised joining the W3C and this group when asking for engagement. So if not via the
success criteria, how do we compare so many alternative proposals?
2. Many of the contributions I have been able to resolve with the contributors one to one. If we do progress these documents how do we settle the mismatched contributions received to date? Ideally, I’d like to setup a meeting
to do this with Aram and others. This would be a subgroup similar to the one arranged the other week on SPARROW.
<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
<AramZS> Perhaps we want to vote on agenda items in the future?
<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]
This is scribe.perl Revision of Date Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/matters/is what matters/ Succeeded: s/bleparmentier/btsavage/ Present: jeff_burkett_Gannett jrosewell wbaker_ ErikAnderson shigeki mlerra wseltzer Chapell kris_chapman lbasdevant btsavage Paul_Bannister br-rtbhouse Mike_Pisula ajknox arnaud_blanchard marguin kleber seanbedford bleparmentier AramZS tkershaw dmdabbs joelmeyer dialtone mjv joshua_koran imeyers pl_mrcy blassey hober cwilso hong cpn dkwestbr Regrets: Karen AlanBird No ScribeNick specified. Guessing ScribeNick: wseltzer Inferring Scribes: wseltzer Agenda: https://lists.w3.org/Archives/Public/public-web-adv/2020Jul/0030.html WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 People with action items: WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]