-
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
Establish out-of-browser function accessibility #47
Conversation
Intended to address: objections that were concerned that specifications that establish non-browser functionality and risk mitigation might be limited only to browser manufacturers.
@@ -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> |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
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 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." |
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.) |
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. |
If I were to "Steel-man" the complaint, here's how I'd interpret it:
But those aren't the only concerns. There are also legitimate privacy concerns:
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." |
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. |
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.