An alternative approach for scoping #56
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is a bit of a departure from previous attempts at resolving this issue. As I understand it, the core concern is that the scope of the working group needs to be fully within the scope of the W3C. There are two relevant aspects to this that need explanation:: 1. The functionality we build might depend on capabilities provided by entities that are not primarily "web" entities. For instance, we have agreed that measurement will need some sort of *private computation*. For this, I have added a paragraph that explicitly states that the working group will coordinate with other entities (IETF most likely) to ensure that those parts that need specification get specified properly. 2. The functionality we build might be better if the specification were implemented by non-web entities. Here, there is ongoing discussion about what operating systems might do, or what capabilities might be built into connected TVs or point of sale devices in order to provide better value for measurement (attribution, reach, frequency, etc...). I am suggesting that we include any text for the latter. There are obvious synergistic benefits to be had if the systems we are talking about are implemented more widely than just the web. However, functionally speaking, that is not something the W3C group can put into a charter. That doesn't mean that what we do here won't matter or that it has no chance of affecting change in those non-web systems. I believe that those synergistic benefits will encourage those who aim to support advertising in those systems to find ways to work with what we do for the web. The web can be very influential. A worked example might help. When we did Web Push, we added a feature that was not previously part of any pre-existing push messaging system. Messages in Web Push are encrypted toward the recipient in a way that ensures that the push service cannot decrypt them. This is now a standard feature of Google's FCM service, as used in most Android devices. In that case, there was no network effect advantage to incentivize the use of encryption, but the work we did for the web showed how it was possible. Google was under no obligation to provide this capability, but the benefits for user security and privacy were clearly justification enough. Having the feature deployed on the web probably helped address any concerns about viability. Finally, we are also not bound by charter NOT to talk about how the systems we build affect others. I would contend that the charter explicitly requires that we consider the broader effect of choices we make, if only through its reference to ethical considerations. While we make decisions for the web, those decisions have a wider impact and we have an obligation to try to understand and consider the implications of that. That does not need to be reflected in charter text though, if only because it would be outside the remit of the organization..
charter.html
Outdated
| </p> | ||
| The Working Group will produce specifications that are implemented by | ||
| user agents. The implementation of specifications in user agents | ||
| might depend on functionality provided by other entities. In these |
There was a problem hiding this comment.
Suggested change
| might depend on functionality provided by other entities. In these | |
| might depend on functionality provided by other entities or interoperate with non-web functionality. In these |
I agree that we functionally cannot include scope in the charter which is outside the remit of the W3C, however I do believe it is worth calling out that these specs may interop with things like operating systems (there are a number of examples of such APIs already providing some interop between "apps" and web, on both iOS and Android.)
Including this (along side the call out to functionality provided by other entities) makes it explicit that it can be a discussion point without adding it to the scope of the WG.
There was a problem hiding this comment.
I don't think "or interoperate with non-web functionality" adds much to the sentence. How about "might interoperate with or depend on functionality provided by other entities"?
hober
approved these changes
Feb 23, 2023
charter.html
Outdated
| </p> | ||
| The Working Group will produce specifications that are implemented by | ||
| user agents. The implementation of specifications in user agents | ||
| might depend on functionality provided by other entities. In these |
There was a problem hiding this comment.
I don't think "or interoperate with non-web functionality" adds much to the sentence. How about "might interoperate with or depend on functionality provided by other entities"?
|
lgtm as well 👍 |
csharrison
approved these changes
Feb 27, 2023
AramZS
added
the
call-for-consensus
eriktaubeneck
approved these changes
Feb 27, 2023
This was referenced Mar 20, 2023
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a bit of a departure from previous attempts at resolving this issue.
As I understand it, the core concern is that the scope of the working group needs to be fully within the scope of the W3C. There are two relevant aspects to this that need explanation::
The functionality we build might depend on capabilities provided by entities that are not primarily "web" entities. For instance, we have agreed that measurement will need some sort of private computation. For this, I have added a paragraph that explicitly states that the working group will coordinate with other entities (IETF most likely) to ensure that those parts that need specification get specified properly.
The functionality we build might be better if the specification were implemented by non-web entities. Here, there is ongoing discussion about what operating systems might do, or what capabilities might be built into connected TVs or point of sale devices in order to provide better value for measurement (attribution, reach, frequency, etc...).
I am suggesting that we NOT include any text for the latter.
There are obvious synergistic benefits to be had if the systems we are talking about are implemented more widely than just the web. However, functionally speaking, that is not something the W3C group can put into a charter.
That doesn't mean that what we do here won't matter or that it has no chance of affecting change in those non-web systems. I believe that those synergistic benefits will encourage those who aim to support advertising in those systems to find ways to work with what we do for the web. The web can be very influential.
A worked example might help. When we did Web Push, we added a feature that was not previously part of any pre-existing push messaging system. Messages in Web Push are encrypted toward the recipient in a way that ensures that the push service cannot decrypt them. This is now a standard feature of Google's FCM service, as used in most Android devices. In that case, there was no network effect advantage to incentivize the use of encryption, but the work we did for the web showed how it was possible. Google was under no obligation to provide this capability, but the benefits for user security and privacy were clearly justification enough. Having the feature deployed on the web probably helped address any concerns about viability.
Finally, we are also not bound by charter NOT to talk about how the systems we build affect others. I would contend that the charter explicitly requires that we consider the broader effect of choices we make, if only through its reference to ethical considerations. While we make decisions for the web, those decisions have a wider impact and we have an obligation to try to understand and consider the implications of that. That does not need to be reflected in charter text though, if only because it would be outside the remit of the organization.
Closes #50.
Closes #49.
More context in #44.
cc @hober, @AramZS, @seanturner.