“Implementer” definition unreasonably favors some participants and redefines consensus

[cwilso]

I have significant concerns that this operational agreement seems to redefine "consensus" as a very specific version of implementer agreement, and explicitly favors some browser vendors. This definition counter-intuitively seems to devalue consensus among browser-shippers who use the same engine; any browser companies who use the same engine may count as a separate implementer for one vote of support, but if multiple browsers using the same engine agree on a feature that would be implemented in that engine (and presumably would share code in that engine, whether it's shared with others or not), then only one implementer would count (because the other is “just shipping someone else's code”, I guess?). In short, the opinion of a "browser vendor" (which in this context, I would define as an entity that is knowingly making privacy decisions on behalf of its users) gets devalued, simply because they agree with another "browser vendor" who happens to share code.

I've thought through many of my concerns about this charter, and believe they largely track back to this devaluation. It certainly makes sense to prioritize the CG's focus on proposals that multiple entities-that-make-privacy-decisions-for-their-users support; I support the desire to focus the group's time and energy on proposals that can garner cross-industry, multi-vendor support. However, using as a gating factor that multiple independent code authors have to be signed up seems wildly misplaced.

As a real-world example, let's presume Brave, Samsung, Edge, and Chrome all supported a particular privacy-supporting API and thought it would be useful. Obviously, if that code can be shared in Blink, they would all prefer not to have multiple implementations. Despite having an obviously cross-vendor support, that would not pass the bar defined here, unless either Apple or Mozilla agreed to support the API as well. In fact, for any feature, you would really need to have support from two of: 1) Apple 2) Mozilla 3) any Chromium browser/committer. However, one of your statements of support MUST be Apple or Mozilla. (Obviously, if there were Webkit or Gecko engine browsers in the CG that weren’t Apple/Mozilla, this might be different. I don't think there are, but may be mistaken.)

In my opinion, this violates a constraint on Community Group Operational Agreements - per https://www.w3.org/community/about/agreements/#cgroups, CGs “must not unreasonably favor or discriminate against any group participant or their employer.”

Additionally, this leads back to a high-level concern: any decisions made in incubation are still subject to change when migrated to a standards-track effort, and having an explicitly different version of "consensus" is more likely to cause disagreements and objections at that migration transition. (It's possible this would be less so if transitioning to the WHATWG, although as this operational agreement notes the WHATWG doesn't define "implementer" this way today.) . Of course, even using any browser vendor support is not entirely compatible with the W3C's Process and voting mechanism, but at least it would be closer and more inclusive of positive support from different organizations.

Personally, I don't think this support bar needed to be explicit; the chairs can evaluate support, and clearly multiple entities supporting a proposal should move that along. However, if you want a more explicit version, in order to resolve this issue I believe the definition of “implementer” should essentially be that of a “browser vendor” - that is, support counts if it is expressed explicitly by separate browser vendors (i.e. Blink doesn’t get multiple “votes” just because they ship an engine that Brave, et al use; but if Brave expresses explicit support for a feature that Google explicitly supports as well, that meets the bar). You might wish to make it explicit that multiple browsers shipped by one company cannot be counted separately (e.g. Firefox and Firefox Reality don’t count twice).

[dbaron]

So while I'd like to think further about what I'd be comfortable doing to address this issue (and, really, other folks from Mozilla are likely to be more involved than I am), I'd like to explain a criterion that led me towards some aspects of the current wording:

One aspect of the W3C's process is that Candidate Recommendations require demonstrating implementation experience, and one of the aspects of implementation experience (and one of the most frequently quoted), is:

are there independent interoperable implementations of the current specification?

We've long considered this an important aspect of demonstrating that specifications can be interoperably implemented, which is important for allowing multiple implementations of the Web's standard technologies by verifying that multiple distinct teams are capable of implementing the same standard independently. So I certainly don't want to have a definition of "implementation" that allows multiple companies to ship the same code, and have that one piece of code count as demonstrating that the specification is interoperably implementable. Perhaps "implementer" is different enough from "implementation" that we could draw a clear distinction between them, but I'm not sure, and I think if so it would be a difficult distinction to draw clearly.

Beyond that, I think it's may be valuable to have definitions earlier in the process align with those later in the process. That is, is it a good idea to move a specification out of incubation when it doesn't have the support needed to pass through later stages of the process? Maybe sometimes it is, but I think alignment here can often be a good thing.

[cwilso]

The CR stage in an as-yet-to-be-defined WG is a long way off from the CG's bar to choose to spend any time on a feature incubation. The whole point of spending time on an incubation would be to explore it enough to gather support.

I would not want the "bar for moving an incubation to a WG to work on" to be "support from two of Apple, Mozilla, or any Chromium committer." Is that still a good bar for CR? Probably, just because it's a test of interoperability of specification, but as a barrier to incubation I have to object.

[erik-anderson]

Microsoft, when helping draft the CG charter, pushed for building clarity around what constitutes an "implementer" since we have already-- and will continue to-- ship privacy-focused features written and shipped independently from Blink. We felt the text as written was a reasonable compromise that would enable us to move forward on ideas that already have very broad consensus. At the same time, we share some of Chris's reservations that it will be hard to predict who would be willing to develop and ship an implementation as the idea evolves.

Our hope is that this group will be able to discuss and iterate on new ideas, even when there is not yet support from another implementer, in the hopes of building the required support. At the same time, the focus on broader implementer interest before moving a proposal to the Work Item phase will be hard to reason about at such an early stage since the current determination of what counts as an implementer is dependent on if an entity will, now or in the future, actually develop an independent implementation. We believe reasonably engaged Chairs will be able to discern what has broader support to help prioritize the group's time and energy.

What do folks think about deferring determining multi-implementer support to a later stage than adding a Work Item? For instance, we could track along with each Work Item the current set of vendors that support iterating on the proposal and the potential number of implementations. This could be used as a signal for group priorities and to help provide a clear signal about if a Work Item is not on a path to have multiple implementations.

[hober]

@erik-anderson wrote:

Our hope is that this group will be able to discuss and iterate on new ideas, even when there is not yet support from another implementer, in the hopes of building the required support.

I share that hope, and I believe the current charter's Proposal phase is when we can do precisely that.

@erik-anderson wrote:

Microsoft, when helping draft the CG charter, pushed for building clarity around what constitutes an "implementer" since we have already-- and will continue to-- ship privacy-focused features written and shipped independently from Blink. We felt the text as written was a reasonable compromise that would enable us to move forward on ideas that already have very broad consensus.

When you and I first talked through this issue, I had started with the position that the status quo of WHATWG is all that we should aim for here. Thank you for sharing all of your thoughts on this! I think we ended up in a much better place than where we started, and I attribute that primarily to your & Microsoft's engagement. If this goes well, we can take what we've learned back to WHATWG, and encourage them to firm up their policy along these lines.

@dbaron wrote:

One aspect of the W3C's process is that Candidate Recommendations require demonstrating implementation experience, and one of the aspects of implementation experience (and one of the most frequently quoted), is:

are there independent interoperable implementations of the current specification?

We've long considered this an important aspect of demonstrating that specifications can be interoperably implemented, which is important for allowing multiple implementations of the Web's standard technologies by verifying that multiple distinct teams are capable of implementing the same standard independently.

Yes, exactly! The fact that the web platform is independently, interoperably implemented is perhaps its most unique characteristic among modern platforms, and one of the major sources of the web's unique resiliency. It's our responsibility as folks defining web platform features to uphold this. This is the principle at the core of this charter.

@dbaron wrote:

I think it's may be valuable to have definitions earlier in the process align with those later in the process. That is, is it a good idea to move a specification out of incubation when it doesn't have the support needed to pass through later stages of the process? Maybe sometimes it is, but I think alignment here can often be a good thing.

I agree. And since lots of the things people want to work on in this CG—e.g. the Storage Access API, client-side storage partitioning, and the like—will likely end up as pull requests on a number of WHATWG specs, I think it's a good thing that we're aligned with WHATWG's multi-implementer rule.

@cwilso wrote:

I have significant concerns that this operational agreement seems to redefine "consensus" as a very specific version of implementer agreement, and[…] seems to devalue consensus among browser-shippers who use the same engine[…]

For things implemented within browser engines, the charter upholds the principle that each engine counts equally, and that you need support from more than one of them. This is how we "demonstrate that specifications can be [independently,] interoperably implement[able]" in browser engines, in @dbaron's words. For things shipped by implementers outside of browser engines, the charter upholds the equivalent principle. Again, this is to ensure that our work is independently, interoperably implementable. This is what it means to do our job as stewards of the web platform responsibly.

@cwilso wrote:

It certainly makes sense to prioritize the CG's focus on proposals that multiple entities-that-make-privacy-decisions-for-their-users support; I support the desire to focus the group's time and energy on proposals that can garner cross-industry, multi-vendor support. However, using as a gating factor that multiple independent code authors have to be signed up seems wildly misplaced.

It's not a gating factor for Proposals (which eventually produce explainers). So I think this concern is fundamentally misplaced. Plenty of useful work can happen on Proposals that have yet to reach the multi-implementer bar in place for Work Items.

It is a gating factor for Work Items (Community Group Reports), which are typically documents produced with ReSpec or Bikeshed that aren't on the standards track but can look very spec-like. This is a good thing, an improvement on earlier incubation models like the one used by WICG. This CG will not produce things that look like specs which lack multi-implementer buy-in, because producing things that look like specs that only have single-implementer buy-in is irresponsible and leads to confusion among web developers.

@cwilso wrote:

In my opinion, this violates a constraint on Community Group Operational Agreements - per https://www.w3.org/community/about/agreements/#cgroups, CGs “must not unreasonably favor or discriminate against any group participant or their employer.”

In my opinion, it does not but rather it upholds this constraint better than other CGs have done in the past.

Also, note this charter requirement:

It is the Chairs’ responsibility to ensure that the decision process is fair and does not unreasonably favor or discriminate against any Community Group Participant or organization.

@cwilso wrote:

in order to resolve this issue I believe the definition of “implementer” should essentially be that of a “browser vendor” - that is, support counts if it is expressed explicitly by separate browser vendors (i.e. Blink doesn’t get multiple “votes” just because they ship an engine that Brave, et al use; but if Brave expresses explicit support for a feature that Google explicitly supports as well, that meets the bar).

This would considerably, perhaps fatally, weaken the CG's commitment to produce work that is independently, interoperably implementable. I would oppose such a change. As @dbaron said:

I certainly don't want to have a definition of "implementation" that allows multiple companies to ship the same code, and have that one piece of code count as demonstrating that the specification is interoperably implementable.

Indeed.

@erik-anderson wrote:

We believe reasonably engaged Chairs will be able to discern what has broader support to help prioritize the group's time and energy.

I certainly hope so! That said, I think it's best to have a clear rule instead of a squishy "chairs discern" rule. The latter leaves the chairs more open to aggressive lobbying for proposals that don't actually have multi-implementer support.

@erik-anderson wrote:

What do folks think about deferring determining multi-implementer support to a later stage than adding a Work Item?

I think it would be a mistake to move it any later in the process than when the editor starts writing a ReSpec or Bikeshed document in earnest.

@erik-anderson wrote:

For instance, we could track along with each Work Item the current set of vendors that support iterating on the proposal and the potential number of implementations.

It's a good idea to track this info!

[pes10k]

I can at least offer Brave's experience / perspective here. We're in Blink (of course), and we have a long list of things we remove from Blink for privacy reasons (possibly out of date at this point), and an even longer list of things we're shipping, but are looking to remove (and haven't yet b/c of limited engineering time, web compat concerns, etc).

Ideally there would be some solution where Brave's "vote" was independent of what we were shipping, especially because of the "we'd like to remove but are worried about web compat" cases.

Is there there possibility of the "implemented, and supports" category, independent of "implemented"?

[cwilso]

@snyderp that was precisely my point. I definitely value and think Brave's position should be impactful to decision-making, independent of Chrome's, regardless of if the same code is used for part or all of a particular feature.

1. This is not the status quo of the WHATWG. The WHATWG values implementation experience, but does not define implementer. It defines Steering Group eligibility, in a form that is much more draconian and less complex than this. (Essentially, top-to-bottom engine owners - so, really, I think today only Google, Apple and Mozilla would qualify.)

2. in this response, you have pivoted hard to "interoperable implementation" as the goal here. In incubation, that is barely relevant - you are not producing standards, nor even necessarily consensus; you are producing well-documented explorations that must be taken up by a consensus-driven process to turn into an interoperable standard.

I agree, enabling and encouraging interoperable implementation must be a goal of Standards. However, that is still ensured by the WG process, and does not seem so relevant to me as way to prioritize in a group that has many active involved participants. Many of these active involved participants will be turned into second-class participants in terms of prioritizing the work of the group they participate in by this definition.

[hober]

I can at least offer Brave's experience / perspective here. We're in Blink (of course), and we have a long list of things we remove from Blink for privacy reasons (possibly out of date at this point), and an even longer list of things we're shipping, but are looking to remove (and haven't yet b/c of limited engineering time, web compat concerns, etc).

Ideally there would be some solution where Brave's "vote" was independent of what we were shipping, especially because of the "we'd like to remove but are worried about web compat" cases.

Is there there possibility of the "implemented, and supports" category, independent of "implemented"?

Let me try restating this to see if I have you right. You'd like the ability to not count as an implementer for some features that you ship but don't support and plan to remove? That sounds totally reasonable to me, and we should probably capture this in the charter somehow.

[pes10k]

yep! @hober and @cwilso said it better than I could.

[cwilso]

The flip side of that, which is the core of my point, is that I think you SHOULD have the ability to count when it is a feature you consciously choose to support shipping in your browser (even if you didn't write the code).

I don't think anyone had proposed that other engine users should count as active votes in support of a feature (that would be like "Google gets an automatic +4 for Edge, Brave, Samsung, Opera" or something, which would be ludicrous). The charter doesn't mention anything about votes against, does it?

[travisleithead]

I think it's best to have a clear rule instead of a squishy "chairs discern" rule. The latter leaves the chairs more open to aggressive lobbying for proposals that don't actually have multi-implementer support.

I think I would still prefer the squishy chairs discern outcome over the current clear rule:

1. Even with the rule in place, the separate implementations definition as given by example in the charter may still invite lobbying and chair judgement calls on the premise that the expectation of shipping to a shared engine may or may not match what ultimately gets shipped after the Proposal is clarified into a Work Item. (Basing a decision on a future prediction doesn't seem very clear to me.)

   If both implementers indicate that they do not expect to share an implementation (they do not
   expect to land their implementations in Shrug), the feature counts as having two implementers
   supporting it. If both implementers expect they’d share an implementation in Shrug, it counts as having one implementer supporting it.

2. The rule could seem useful now, but it is not future-proof, and not something I'd like to see adopted more widely. The browser engine landscape will surely continue to change over time. If the future holds more engines then the rule may allow minimally-involved implementers to create standards that won't really get broad adoption. Conversely, a future with less engines increases the probability of stalemate in making progress. In either case, I don't believe adopting this rule more broadly would always lead to the best outcomes.

[pes10k]

Sorry, i realize my "shucks you all are doing great" painted with too broad a brush, and didn't say exactly what was agreed with (thanks for the nudge @TanviHacks).

Here is my position, in order of what I expect will be least to most controversal:

1. Brave would like the ability to arbitrarily not count as an implementor, independent of whats shipped (cases include something we think is bad, but have to grit our teeth and except for webcompat, something we plan to remove / modify, but haven't yet)
2. Brave would like to count as an implementor on things we ship when we do the implementation work.
3. Brave would like others in Blink world to count as supporting / implementors when they use Brave's implementation, even if thats not shared upstream in Chromium.
4. Brave would like to count as a supporting implementation for things that are implemented by others in Blink world, that Brave intentionally ships

Is the underlying issue here what the threshold is for implementation? Even though MS and Brave (and others) are both in Blink, none of us ship the same version of Blink (either because of patching or different decisions in compile flags).

On the other extreme (at least last time I checked), Gecko and Blink use the same underlying libraries for much WebRTC functionality, but seems like its not controversial that that should count as two implementations. (even if thats not / no longer the case on WebRTC, its easy to imagine other such cases).

Is it correct to say that whats really being argued about here is

1. What the threshold is for a unique implementation? (the bar should probably more more than diff compiler-time options, probably less than unique clean room implementations)
2. What is the threshold for "important enough" a browser to count? (the bar should be below the "big four", but above something held together with glue and prayers in Pete's personal browser)

If these questions are already answered elsewhere in W3C docs, the apologies for the above. But I hope this at least clarifies Brave's position

[cwilso]

Thanks Pete, that is clarifying. I think the point of contention here is that with the charter today, I believe your #3 AND #4 are not true. In essence, only the entity actually planning on writing code to support a feature would count. The definition in place here is very strictly indexing on "entity who will write code", not "browser-shipper with independent views that may share code for a feature." That's been the root of our dissent - although that may make sense for final interop proof (see below), it's not a useful delineation for early incubation. Support from multiple parties with independent views, who consciously ship platforms to users, is useful at this stage to guide prioritization, imo.

The W3C does not define implementations in the same manner, exactly; there's a common misconception that there's a requirement for two independent interoperable implementations. In fact, the Process document says in https://w3c.github.io/w3process/#implementation-experience: "While no exhaustive list of requirements is provided here, when assessing that there is adequate implementation experience the Director will consider (though not be limited to): ... are there independent interoperable implementations of the current specification?"

In fact, "Pete's personal browser" (hereafter called PPB :P ) could be used to prove that interop, and inasmuch as (even though it's not really affecting a ton of users) it can be used to test the spec as a catalyst for interop, that's not wrong.

[pes10k]

Thank @cwilso . One more nugget to add then. A big part of "implementation" (here, shipping and supporting) is understanding how it interacts with other features in the platform. Brave makes lots of changes across the platform (compared to Blink), and so understanding how the same features (and maybe even the same code) work when combined with other changes, seems like it'd be useful to consider.

E.g. knowing a feature works well in Chrome, but doesn't work well in Brave, bc of privacy modifications that Brave has made elsewhere in Blink, seems like it'd be important to include. And, the inverse, knowing that a new feature is compatible with other privacy modifications also seems useful.

If the above is captured by requirements / charter text elsewhere, then please ignore. But one of Brave's goals in standards work is to make sure new functionality doesn't make it difficult to make webcompat friendly modifications elsewhere.

[cwilso]

I know there's an upcoming Privacy CG call. Happy to participate, or have other higher-bandwidth discussion if that would help. I filed a PR as a proposal to fix this issue, since it seems to be languishing, as Google would like to participate in the Privacy CG.