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

Establish out-of-browser function accessibility #47

Closed
wants to merge 1 commit into from

Conversation

AramZS
Copy link
Contributor

@AramZS AramZS commented Dec 5, 2022

Intended to address: objections that were concerned that specifications that establish non-browser functionality and risk mitigation might be limited only to browser manufacturers.

See #44 to help with understanding this issue.

Intended to address: objections that were concerned that specifications that establish non-browser functionality and risk mitigation might be limited only to browser manufacturers.
@AramZS AramZS added the comment-response We are attempting to realize issues raised by others. These PRs/Issues do not represent the chairs. label Dec 5, 2022
@@ -272,6 +272,8 @@ <h2>Success Criteria</h2>
<p>There should be testing plans for each specification, starting from the earliest drafts.</p>

<p>Normative specifications which have user-facing features should contain a section on accessibility that describes the benefits and impacts, including ways specification features can be used to address them, and recommendations for maximizing accessibility in implementations.</p>

<p>Non-browser-based functionality in any feature should be clearly established in such a way that any entity who can fill that role in the ecosystem is permitted to do so.</p>

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am worried that this wording may be broader than intended. For example, the IPA proposal requires two helper servers that are trusted by the User Agent to be non-colluding. Does the phrase "any entity who can fill that role in the ecosystem is permitted to do so" impinge on the UA's ability to exercise judgement on the trustworthiness of entities that assert they can fill that "helper" role?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It does seem like it may open that as a possibility. However, some have taken the position that specifications should require UAs to not be able to be discriminatory in the selection of entities that fill roles like IPA helper servers as long as they meet the technical requirements of the spec.

Personally, I'm not sure that makes sense or follows how specs have worked in the past generally, but it might be useful to speak to why the capacity to exercise judgement of entities is important.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll confess that I didn't understand this paragraph, but the added context helps a great deal.

I disagree with this as stated. The functioning of any system that operates on personal information should have some path whereby the affected persons can exercise a measure of control. There are various ways to accomplish this, but saying that if the data leaves the user agent, then the user agent cannot have any say in how that data is handled will mean that user agents will be forced to refuse to let any such information leave the user agent. Otherwise, they will be unable to fulfill their obligation to protect user data.

This requirement would likely foreclose on any system for centralized aggregation, which generally depend on having some system that is trusted to some limited extent to operate on information provided by user agents. That information would not leave the user agent if it the user agent had no way to control what happens to it.

As to the underlying requirement, I don't understand why this is a concern with the charter. Why is it that this constraint cannot be debated in the proposed working group?

@AramZS
Copy link
Contributor Author

AramZS commented Jan 31, 2023

I am relaying a comment from a member who has raised formal objections. I do not intend to imply support or opposition to this statement, but just to make their objection on this available for discussion with the member's permission:

The text change continues to differentiate browser from non-browser. This is discriminatory in any established business process and is an abuse of standards setting to favour certain participants.

@michaelkleber
Copy link

The anonymous objection makes no sense in the context of web standards. The proposed direction of change, with the goal of removing the ability of a browser to exercise its judgement about entities outside itself, would preclude the use of core web infrastructure like Certificate Authorities. We should not waste our time on charter objections that boil down to "the web should not exist."

@eriktaubeneck
Copy link

For clarity, my intention both in the threat model and in the IPA proposal was to consider the use of private computation (potentially enabled by a helper party network) to provide a computation environment which is essentially an extension of the browser, but which can do such computation over inputs from many clients.

As browser vendors have the responsibility of implementing the standards we set (and, ultimately deciding to adopt such standards), my intention (and, as I understand it, the intention of my co-authors on both documents) is that browser vendors would also be responsible for exercising judgement about what entities outside itself meet the stated requirements in these proposals (and eventual standards). As far as I know, the standards process would not make judgements about specific entities meeting the requirements of a standard, just as it would not make judgements about a specific implementation meeting a specification. (This is not to say that individual members participating in the standards process may provide such feedback about implementations meeting or not-meeting the spec, but rather that it's not, in my experience, scoped in the charter of a CG or WG.)

@martinthomson
Copy link
Contributor

I agree with @eriktaubeneck on the procedural technicality aspects. I do think that as part of the work here we need to assure ourselves (collectively) of the feasibility of any such system.

The nature of the constraints on the private computation component probably will dictate our collective involvement at some level, if only because the system as a whole depends on those constraints. For instance, if a browser were to decide that it would make private information accessible to without restrictions to certain parties, then we might need to conclude that the practical realization of the system doesn't achieve our privacy goals, even if it were otherwise robust.

@benjaminsavage
Copy link
Contributor

If I were to "Steel-man" the complaint, here's how I'd interpret it:

  • None of us want to wind up in a situation where the browser ONLY approves one set of helper parties who can charge exorbitantly high prices.
  • None of us want to wind up in a situation where the browser vendor demands some kind of favors / preferential-treatment from the helper party in exchange for approval to operate a helper node.

But those aren't the only concerns. There are also legitimate privacy concerns:

  • None of us want to wind up in a situation where untrustworthy or incompetent parties are able to operate helper nodes. This could lead to two bad-quality helper nodes colluding, and user-privacy being compromised.

So what we need is a set of fair and objective requirements on helper parties. These requirements should ideally lead to a good number of qualified parties - such that there is healthy competition that brings down prices for advertisers and publishers. But it should be a rigorous enough bar, that the browser vendors can confidently tell the people who use their products "We have confidence in these helper parties - and your privacy will be preserved."

@npdoty
Copy link

npdoty commented Feb 6, 2023

Is it just that the specification shouldn't hard-code the parties? (That certainly seems true of every W3C specification!)

I don't know how a spec could permit or prohibit some party from implementing some functionality, or force interaction with that implementer.

@AramZS AramZS closed this Feb 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
comment-response We are attempting to realize issues raised by others. These PRs/Issues do not represent the chairs.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants