User from user's agent, and expanding third parties

[jwrosewell]

Started to separate out "users" from "user's agent".

Expanding third party to consider all parties that are not first party origins.

---

Preview | Diff

[joshuakoran]

I think there are two good points being clarified in the edits:

• Distinguishing identification of a particular user from identification of a particular person's user agent across different sessions or interactions with different origins (aka publisher domains)
• Given end user's perspective, ensuring fingerprinting is addressed regardless of whether it is attempted across different origins or not

I think the distinctions raised in these suggested edits are worth clarifying in the document.

[jyasskin]

This PR seems to mix stylistic rewordings like this paragraph, with changes in meaning like "or other party" in the first paragraph and "user"->"user agent" in the fingerprinting section. That makes it hard to review.

[jwrosewell]

Perhaps we could arrange time, either in a side meeting, or at a future meeting to discuss this? Personally I find document collaboration via GitHub to be more complex than other document collaboration tools such as those provided by Google or Microsoft.

In the meantime here is some background and related issues.

PR Background

The PR is made against the "revise-2" branch of the master document. This PR introduces the following for reviewer consideration in addition to the changes already included in "revise-2".

1. Differentiate between "user" and "user agent". For example; a fingerprint can relate to a person, or a user agent. The harms, benefits and risks we are concerned about vary accordingly.

2. There are three different entities that might benefit or harm people’s privacy.

a) First-parties – web site authors who are readily identifiable via the domain name displayed in the address bar.
b) First-parties’ suppliers – organisations first-parties rely upon that are not identified in the address bar.
c) User agent vendors – organisations that make or control the web browser

People can be harmed by any one or all three of the above. Afterall some user agent vendors have received the largest fines in relation to privacy violations.

The document would benefit from recognising each group and the role they play in the specific issues of security and privacy. This was originally raised as an issue which includes some background.

Related Issues

These related issues are important. @torgo closed an issue related to people's ability to trust supply chains with this statement “We have already established that the statement "supply chains can be trusted" (on its own) is false.” But unfortunately, did not provide me with any references to justify that that statement is false. Such information should be included in the document and be provided from an authoritative source. We can look at other industries they all have supply chains people can trust. Why should the web be different? As a minimum the document should be expanded to consider the conditions that do or do not enable a supply chain to be trust.

Referenced RFC 6973 entertains the possibility and certainly does not exclude it.

I believe the onus in a consensus driven governance model is for the proposer to convince others. As a new member I am keen to understand the facts and feel these issues have been closed without discussion or clarity in the document. I've been advised to progress resolution via text changes to the document and I'm doing so here.

Policy

The more general issue relates to W3C policy. This document infers policy. It does not seem to be the role of a standards body to make decisions that restrict people’s choice. That is a role of law makers.

Whilst these documents are supposed to advise they do prescribe rules akin to laws. According to the W3C Process if a proposal is to be successful it will at some point need to pass horizontal review. It's unlikely the AC or the Director would approve a standard that were deficient.

Rightly proposers become familiar with those documents that will be used to assess their proposal at the onset. Reviewer's frequently reference these documents. Whilst these documents may not be formally classified as laws, they appear to be use as such in practice.

[torgo]

I think "origin" is fine since "parties" are origins in the web.

[jwrosewell]

Other parties include the user agent vendor that I don't believe would be classified as origins. Consider a feature where the user agent vendor is capturing personal information. Considerations related to privacy would at least include;

a) consent obtained for use of that information;
b) transparency to assure the user that the consent preferences were respected; and
c) security issues associated with the way that data is stored and deleted, among others.

Considering security and privacy beyond protocols and origins is an important theme I would like to see developed in PING and this document. What mitigations can be applied that do not relate entirely to technical standards? For example; accepting terms of service and default settings at the point of user agent setup or upgrade will enable implementors to consider solutions that are not restricted to permission pop ups that are annoying, or defaults that are so restrictive they impair functionality, or expose user agent vendors to competition issues by gaining consent across vertically integrated services at the point of account setup which is impossible for other players in the market to achieve.

I hope we can all agree that a situation where acceptable privacy can only be achieved by a very small number of implementors would not be compatible with the W3C antitrust policy or the mission and purpose of the W3C.

[torgo]

The point that the user agent (vendor) is a party outside of "origins" - that effectively has "root" - is a good one. Another example is "geolocation" where information is sent out out band to the browser maker as part of the API.

[torgo]

Also not necessary as origin implies party

[hober]

Could you rebase? I don't think this change is necessary given the current text.

[hober]

Maybe s/on the same origin or across origins/on origins/, like in #90?

[hober]

Also, there's some grammar weirdness in the original text too ("sensor also reveals" should probably be "sensors can reveal". Can you fix this while you're in here? Thanks!

[jwrosewell]

Fixed "sensors can reveal" comment in latest commit.

[hober]

While I think your new question may be one worth asking in the questionnaire, I'd rather it be spun off into a separate PR that adds this question, instead of one which replaces the first-/third-party question. Among other things, this new question is significantly narrower than the original.

[hober]

Maybe pursue removing or modifying the first-/third-party question in a separate PR as well.

[jwrosewell]

There are two key changes in this pull request.

1. Recognising the full range of parties involved in the web.
2. Resolving first and third-party bias.

Before splitting the second change into another pull request I’m keen to gauge wider views on this and have been encouraged to raise these issues via specific text changes.

If smaller participants on the web are denied the ability to “band together” to deliver services that only larger participants can deliver due to their scale, then we have to consider the W3C’s antitrust policy. What work has been done on this document to verify it does not unconsciously steer specifications towards this outcome? Whilst I recognise that the subject of competition and antitrust may not be one other people feel willing or able to engage with that does not resolve the matter.

There are other considerations related to people’s trust choices and trusting supply chains. The document, and reviewers of issues, have categorically stated that people can not trust supply chains. I’ve not seen the evidence for this from any authoritative sources. As a minimum the document should reference such sources for new readers like myself. Perhaps approaching the problem from the perspective of the conditions under which a person can or can not trust a supply chain would add a much needed dimension to the document?

[torgo]

I don't think this is the right forum to have that debate. We're trying to craft some guidelines here, not open up a debate about the nature of the web. Can I suggest that we go with Tess's suggestion and split this out into a new question?

[jwrosewell]

Following discussion in the IWA BG where there was broad support to discuss the subject further, and considering the opportunity at TPAC to hold a debate on these matters, I have proposed a session for October. The output of that session will help inform the future of these definitions and how they apply to the questionairre and the work of the TAG and PING.

It is clear that the current definitions or interpretations of parties is too simplistic to solve the myriad of challanges we are all working on.

[jwrosewell]

A TPAC break session proposal has been added following the Improving Web Advertising Business Group today and discussion on the session there.

[hadleybeeman]

Hi @jwrosewell — we're just checking on this. It looks like there are a bunch of review comments that have come in. Are you still working on these edits?

[jwrosewell]

Yes. I've a number of relates issues and changes that I expect to file this week.

[jwrosewell]

Update. I'm awaiting further input which I expect to recieve next week at which point I will post again.

[jwrosewell]

Following Texas vs Google and the material in relation to privacy fixing this PR is taking longer to progress than I'd envisaged.

"Google actively coordinates with its competitors when it comes to privacy," the suit says. "Of course, effective competition is concerned about both price and quality, and the fact that Google coordinates with its competitors on the quality metric of privacy - one might call it privacy fixing - underscores Google's selective promotion of privacy concerns only when doing so facilitates its efforts to exclude competition".

I expect to return to it early in the New Year.

[plinss]

Closing this. Timed out with no contributions.