Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Charter scope and guaranteeing availability of input data #16

Closed
jwrosewell opened this issue Apr 4, 2022 · 8 comments
Closed

Charter scope and guaranteeing availability of input data #16

jwrosewell opened this issue Apr 4, 2022 · 8 comments

Comments

@jwrosewell
Copy link

The W3C should limit its work on browser standards to modular web features and not restrict the application of such features for specific industries. To do otherwise is to alter the W3C’s founder’s design principles of a web for all that is designed with simplicity, modularity, evolvability and decentralization. Our work must not concentrate control over innovation and the economics of the web into the hands of the smallest, third priority constituent (behind users and publishers), even if web browser will understandably be the stakeholder group with the most influence in these forums.

There is much I agree with in Manu Sporny’s 2017 analysis of Payments, which predates my involved in the W3C. I encourage everyone to read this analysis prior to the meeting to avoid repeating the same set of problems here. As we progress a charter for W3C membership approval we should be mindful of these views are not yet included in the debate so far.

To address these issues this group charter should be limited in scope to;

a) the creation of proposals and charters for other groups to develop modular web features where they do not exist today; and
b) the creation of proposals to improve privacy (whether for advertising or any other digital content matching systems) using modular web features only; and
c) ensure the availability of the input data needed for such decentralized processing such that evolvable, innovative, new competing solutions can emerge.

This direction will ensure that web authors (both publishers and advertisers) will have choice, while we improve privacy for individuals.
We have seen recent examples of such choice.

  1. Some publishers have chosen to adopt Seller Defined Audiences (SDA) and limit possibilities for advertisers concerning measurement, reporting, and attribution. That is the choice of the publisher. The advertisers will attribute value based on results they can achieve with this new information as well as the elimination of other data. The market will decide how SDA evolves alongside alternative solutions.
  2. Some publishers have decided to require individuals to disclose their directly identifiable personal data (“identity”) in order to access their content. Other publishers require not only this but direct payment from users as well. This too is a publisher choice. Those users who are comfortable and have the necessary means are free to engage with such publishers.

In both cases the offerings inadvertently favour the larger publishers with existing brand presence. To ensure a vibrant web that supports smaller publishers and new entrants, we need additional solutions too. Given these smaller publishers and new entrants are yet to be represented directly in the debate, we should to the best of our ability ensure their interests are considered by the charter.

Updating the charter in this way enables those proposing Topics, FLEDGE, IPA, and others to be developed under the umbrella of the W3C without splintering the web. For example; if a publisher who supports SDA wished to use FLEDGE or IPA to handle attribution alongside SDA that would be their choice. If a publisher wished to use some alternative approach based on laws and economics as well as technology, such as SWAN.community, then they would be free to do so. Of course, their visitors must also consent to the accessing on an ad-funded basis, just as they must consent to disclosing their identity and submitting direct payments to more established publishers.

If we were to ensure the design principles above are included in this chart, then web browsers could focus their engineering on only new modular web features (if any) required these use cases. For the wider industry the “distraction tax” associated with so many “web browser mandated” proposals will be reduced. In short, we will be supporting competitive digital markets that are enhancing privacy for people accessing ad-funded web content and leaving opportunities open to evolve even better solutions.

@npdoty
Copy link

npdoty commented Apr 4, 2022

What is "input data" and what guarantee would we be providing about its availability?

Is this about information to be used as an input to the standardization process? Or is this about guaranteeing access to data about the user to entities that want it?

@ekr
Copy link
Contributor

ekr commented Apr 4, 2022

I also don't understand the proposal here, so perhaps it could be provided as a PR?

To take the concrete example that @jwrosewell provides, I don't expect this group to do anything to stop publishers from using SWAN.community. What privacy mechanisms browsers might adopt that would impact SWAN is a question for other WGs, such as PrivacyCG. I take the topic of this group to be to design technical mechanisms that improve advertising but do not involve the kinds of tracking mechanisms now in use.

@jwrosewell
Copy link
Author

jwrosewell commented Apr 5, 2022

@npdoty

What is "input data" and what guarantee would we be providing about its availability?

The issue is about guaranteeing access to data to all parties that that wish to implement a standard develop by the group, or any other competing solution or standard. It is about providing the same user consent mechanism to all parties that wish to access said input data to provide their service. Of importance is that web browser vendors are not the exclusive controllers and processors of the data needed to implement solutions like TOPICS, FLEDGE or IPA.

@jwrosewell
Copy link
Author

@ekr

I also don't understand the proposal here, so perhaps it could be provided as a PR?

I would be happy to make a PR if there is an acceptance of the principle beforehand.

What privacy mechanisms browsers might adopt that would impact SWAN is a question for other WGs, such as PrivacyCG.

This dual group approach is the classic W3C browser vendor playbook. We’ll have a group over there that is going to remove or alter something that impacts many web participants. Then we’ll create another group over here which is going to handle the solutions to the problems created by the other group. We’ll then bat participants between them. These items are related and would be sensibly addressed together before advancing PAT WG.

I take the topic of this group to be to design technical mechanisms that improve advertising but do not involve the kinds of tracking mechanisms now in use.

You imply SWAN.community utilises tracking mechanisms that are now in use. Correct? Or a misunderstanding on my part?

For the avoid of doubt SWAN.community uses laws, economics, and engineering to significantly increase privacy control and transparency, and identify and eliminate bad actors. Current mechanisms have no engineering to recognise lawful data sharing, do not incentivise good behaviour via economics, nor do they utilise contract law to provide the user visibility of B2B supply chains. SWAN.community is utterly different to today.

@ekr
Copy link
Contributor

ekr commented Apr 5, 2022

Several points:

  1. Absent a PR, I do not understand the principle you are proposing.
  2. I understand that you would like a significantly different group structure than we have today, but I don't agree.
  3. SWAN currently uses a combination of first party cookies with redirect tracking. Whether browsers limit the use of these technologies is not a topic for this group.

@benjaminsavage
Copy link
Contributor

c) ensure the availability of the input data needed for such decentralized processing such that evolvable, innovative, new competing solutions can emerge.

@jwrosewell - let me see if I understand what you mean by this statement. Please feel free to correct me if I've misunderstood it:

Context

  1. You've noted the general trend across user-agents to limit access to data which can be used to link user identity across domains (e.g. removal of 3rd party cookies).
  2. You've noted various proposals (e.g. Topics, FLEDGE, IPA) for new APIs intended to support certain ads use-cases (e.g. aggregate conversion measurement) via novel mechanisms that would only be possible through the addition of new capabilities to user-agents.
  3. You've proposed SWAN, which would require to function access to data which browser vendors seem poised to remove (i.e. redirect tracking)

Interpretation

  • You do not want to see user-agents introduce new APIs to support specific ads use-cases (e.g. aggregate conversion measurement) via mechanisms which cannot be replicated by entities other than the user agent.
  • You would like to see user-agents continue to provide access to data which can be used to link user identity across domains. You describe APIs which provide this basic building block as "modular".
  • You believe that with continued access to such data, there can be a variety of different approaches to supporting ads use-cases. You describe these as "competing solutions". You believe that such approaches can employ approaches such as the collection of consent in order to "protect the privacy" of individuals.

Summary

In summary, you would like to see this group standardise APIs which provide access to granular data:

  • which can be used to link user identity across domains,
  • so that a rich variety of different approaches can be built on top of that data
  • to support many ads use-cases,
  • by many entities, not just browsers,
  • and that this belongs under the umbrella of "private advertising technology" because such approaches can employ approaches like "notice and choice" to protect user privacy.

Is that a correct summary of what you mean?

jwrosewell added a commit to jwrosewell/patwg-charter that referenced this issue Apr 7, 2022
…patcg#5, patcg#6, patcg#8, and patcg#16.

Solutions has been used to avoid steering the group towards specific outcomes. This relates to [patcg#5]( patcg#5).

Privacy needs to be defined and used consistently throughout and relates to [patcg#6]( patcg#6). The PR does not address this but capitalizes the term and suggests a section to achieve this is added.

The Scope has been modified to avoid excluding solutions that address the problem the group seeks to resolve utilising a combination of different disciplines and to avoid solutions that only web browsers can implement. This relates to [patcg#8]( patcg#8).

Regarding access to data. References the patent policy and applies access to input data under FRAND terms and principles. This will address the issue concerning data access and aligns with the existing precedent associated with those that have something that is needed to make the specification working making all those things available to others. See the new chapter on Data Policy following Patent Policy. This relates to [patcg#16]( patcg#16).

The Success Criteria are not clear and need further work.

Included several other changes in the PR to better align the document with the W3C Process which we identified during our review. For example the call out of specific sections of the W3C Process are removed as these are not needed and emphasis some elements over others. The W3C Antitrust Guidelines are now referenced as these don’t form part of the W3C Process.

This PR is a start to move the charter in a better direction rather than a finished charter.

My colleagues advise that reviewers from Apple, Facebook, Google, and Microsoft, might wish to contact their colleagues Per Hellstrom, Tim Lamb, Oliver Bethell, and Greg Sivinski respectively for their views on the modifications.
@jwrosewell
Copy link
Author

@benjaminsavage Thank you for summarising. With a few important amendments you're correct.

Amendments follow.

You've noted the general trend across user-agents to limit access to data which can be used to link user identity across domains...

There is a trend to remove data that can be used for many purposes other than user identity as well. For example; IP addresses, information about user agents, third party cookies for data transfer that does not include user identity. If we consider harms to be a) big impact for a small number of people; or b) a small impact on a large number of people; then I've not seen any evidence to support such far reaching changes.

You would like to see user-agents continue to provide access to data which can be used to link user identity across domains.

Change the sentence to the following so that users are included, that the data use is consented to, and domains as a privacy boundary are removed.

"You would like to see user-agents provide access to data between multiple data controllers and processors where user's have provided consent for the use."

You believe that with continued access to such data, there can be a variety of different approaches to supporting ads use-cases.

Data collected in the manner envisaged is not generally available today as it is highly "siloed". So the pedant in me would drop the word "continued".

and that this belongs under the umbrella of "private advertising technology" because such approaches can employ approaches like "notice and choice" to protect user privacy.

"Notice and choice" alone would not be enough. A mechanism to ensure fairness and transparency would also be needed. SWAN requires an audit feature that extends beyond the browser and across the B2B supply chain providing people evidence of harm. BTW Had SWAN been available in the Lloyd vs Google case Lloyd would likely have won because Lloyd would have had evidence of actual harm rather than theoretical harm.

In relation to the modular building blocks I have provided a suggestion to alter First Party Sets to achieve a modular building block that would support the direction outlined.

@jwrosewell
Copy link
Author

#30 replaces this issue and incorporates comments from the June meeting.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants