clarify charter scope #6
Conversation
Addressing patcg#3, clarify that features may include both client and server implementation, but are client-facing in some way.
AramZS
added
the
call-for-consensus
|
Particular stakeholders who have brought up the language of how we speak about specific features and specifically the inclusion/differentiation between client and server, before, I would appreciate your review: @martinthomson @darobin |
charter.html
Outdated
| <p>The Community Group may consider designs that allow user agents for the same | ||
| user — including non-browser agents, like Operating Systems — to | ||
| collaborate in providing advertising features. | ||
| <p>The Community Group will incubate new web platform features to support web advertising and provide users with privacy with a strong technical basis. Features may be designed for implementation by user agents — including non-browser agents like operating systems or mobile apps that use web technologies — and by servers providing client-facing functionality.</p> |
There was a problem hiding this comment.
The reformatting here means that this is not consistent with the original or adjacent text, but the reordering and expansion is mostly OK. I'm not sure what "servers providing client-facing functionality" really means. Is it web servers? Or are we talking about including partially-trusted MPC nodes?
There was a problem hiding this comment.
My intention (which was just to reflect what I was hearing from the group, I don't have strong feelings on the scope myself) was to capture proposals of functionality that involved user agents of different types and the servers they interacted with (web servers, reporting servers, etc.) but to exclude proposals about privacy through policy decisions or enforcement among ad servers or proposals about purely server-to-server communication.
The sense I got was that there may be privacy-useful things that can be done in those categories, but that this group would prefer they be taken up at non-w3c fora (like IETF, maybe, or advertising-industry venues). The existing text says only user-agent features, which seemed like it ruled out any server functionality at all which didn't seem to match the proposals being discussed.
charter.html
Outdated
| primarily non-technical should be proposed elsewhere. | ||
|
|
||
|
|
||
| <p>Features that support advertising but provide privacy by means that are primarily non-technical and features that are server-to-server without a user-facing component should be proposed elsewhere.</p> |
There was a problem hiding this comment.
This is a good place for two sentences. Also, I don't think that the server part is useful here.
If we decide that we need to standardize some MPC components that are somewhat trusted (i.e., trusted not to collude), that is an implementation detail that I don't see being ruled out by the charter. If this is designed to avoid mechanisms that are "behind the scenes" mechanisms, then I think we already have ample basis to reject those that are not relevant.
There was a problem hiding this comment.
I agree, I don't think we need the server to server part here.
editorial separation of sentences
|
It does not appear we have consensus on these changes. At this time I'm going to close this PR for now. |
Addressing #3, clarify that features may include both client and server implementation, but are client-facing in some way.