-
Notifications
You must be signed in to change notification settings - Fork 12
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
Comments
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? |
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. |
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. |
I would be happy to make a PR if there is an acceptance of the principle beforehand.
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.
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. |
Several points:
|
@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
Interpretation
SummaryIn summary, you would like to see this group standardise APIs which provide access to granular data:
Is that a correct summary of what you mean? |
…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.
@benjaminsavage Thank you for summarising. With a few important amendments you're correct. Amendments follow.
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.
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."
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".
"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. |
#30 replaces this issue and incorporates comments from the June meeting. |
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.
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.
The text was updated successfully, but these errors were encountered: