Meeting minutes
Reminder of anti-trust and competition guidance
Nick: Thanks everyone for joining today's call. As a reminder of W3C antitrust and competition guidance
(...we share that when we have guests in particular)
Criteo review
Ian: we started a member review for Payment Requests and Payment Identifiers.
… we got an objection from Criteo, which I've been discussing with them
<nicktr> ian: For Payment Request and Payment Method Identfiers, we had two formal objections during member review, including one from Criteo; see the public documentation.
<nicktr> ...we have addressed some of the concerns in editorial changes
<nicktr> ...but there were some elements that we couldn't reach consensus
<nicktr> ...including a topic that might be better addressed in a cross-Consortium fashion
<nicktr> ...In the end, we put forward a call for consensus with a proposal to make no changes to address the remaining issue
<nicktr> ...we have extended the CfC until tomorrow so that Criteo could address the group directly
Nick: I'd like to invite colleagues from Criteo to talk through the concern.
Josh: Thanks everyone for coming today to hear our concerns directly.
… I hope an interactive conversation will get us to a better outcome.
… Ian laid out the perspectives he heard, and I tend to agree with most of them.
… e.g., discussions of competition in other fora within W3C is a good thing, and that should not limit discussion here if there are particulars in this document that would raise concerns.
… the summary of the outstanding concern we have is that standards can give rise to competition issues,
… otherwise w3c would not have its antitrust guidelines.
… the current specification does not yet acknowledge that implementers must not self-preference their own solutions in an anti-competitive manner.
… we acknowledge that w3c cannot control what other organizations can do
… our ask is not for that, but that the spec include text that would raise awareness.
… some specifics:
… section 14.5 says that browsers can rely on other considerations to do whatever they like
… various statements in the specification are not about user choice or to facilitating transactions between merchants and users
… we should not leave spec open-ended to whatever browser wants to do
… we want to chat about this to see if we can come to some alignment even if we don't enumerate every possible behavior
… we want to make sure spec does not lead implementers to violate existing w3c policy
… suppose I control the user agent and also offer my own payment solution, I could put my solution at the top and even filter out other competitors
Nick_TR: Any questions or comments?
Josh: Do people disagree? Is anything I said controversial?
Nick_S: I don't know that it's controversial. But I would disagree strongly with the proposed change. I don't believe it's appropriate for a standard to have normative language about what implementers must do in reference to laws that are themselves not defined in the standard.
… the W3C antitrust and competition guidance is not referenced in any standard today.
… it exists as part of our organizations all working together.
… my second concern is: how do you determine that conduct violates antitrust and competition guidelines?
… e.g., in some countries, it's a regulatory requirement that some payment methods be placed above others; in other countries it's not.
… I see the concerns but do not support the language as proposed because I don't believe it's appropriate for a technical specification.
Josh: We are not wedded to how the concern is addressed; we are open to any method to address the concern.
… in other standards bodies, there is a pre-amble before each meeting (or referenced in other documents) that the work is not meant to be done in a cartel; we are here to generate open standards to facilitate interactions.
… I don't think addressing an anti-competitive concern should be controversial; how do we ensure that the current spec is not supporting illegal activity.
… regarding the point "how would we judge that conduct violates local law or this spec?" I would submit that that is not our job.
...It's not the role of a standards body to judge the behavior. The standards body produces "neutral" technology that makes things easier ... we just want to be sure we are making the web a better place
… there are some principles within W3C that guide decisions (e.g., privacy). I also think that decentralization is an important principle.
Nick_S: I understand your position. W3C standards in some countries could be illegal (e.g., if algorithms related to crypto were illegal). We don't speak to that in the standards. That's one of my fundamental objections here. You are taking a concept that is beyond the expertise of the participants on this call and insert references to legal language that is inherently non-normative.
… there is no single global definition of anti-trust.
… we have to be careful here; there is no precedent in W3C standards to speak to this topic.
… it would be like the encrypted media extension spec saying "don't facilitate piracy"; it does not.
… what's the difference in this case?
… if we want to ensure that users have choice, are there ways to express that without making references to legal matters?
… it's a nuanced issue because there are multiple layers of choice here.
… the merchant may have a preference
… the implementer may have a payment method
… the user has preferences
… there are many stakeholders here.
… can we find language that addresses that issue but in different ways? I think if we do it in this standard it will open a box that I don't think should be in W3C's remit.
Josh: You make some good points, Nick_S.
… our hope is to address the concern; don't need to pursue
the proposed revised language to this proposal as it was written. Note, we are not asking the W3C to become experts in local regulations or to define a universal standard for competition law. Instead, we are focused on ensuring this spec will not violate current W3C antitrust policies.
… we have also talked about priority of constituencies, for example. Ensuring we do not have implementers place their commercial interests ahead of users or web authors, in this case merchants.
… but there is a difference between this spec and the other examples that were cited (piracy, use of cryptography)
… in the other cases, neither one of those is part of an extant policy of W3C.
… in the case of antitrust, there is W3C policy in this space.
...One approach could be to include a reference to the antitrust guidance to handle this objection. Without some fix, ambiguous language could be used to violate W3C policy.
Nick_S: My understanding is that the antitrust policy is for participants in the standards creation, not for implementers.
… that policy is primarily to address interactions among participants while creating the standards
… it's not clear that you can reference it in the standard.
wseltzer: Thank you, Nick_S. And thanks everyone for participating here. W3C has different types of policies with different origins
… this one (antitrust and competition guidance) was written to govern the behavior of participants in w3c venues
… while the same principles might apply to implementers and those using the technologies,
… we don't currently have references to this policy in our specs for implementers.
… that is why Ian proposed that this is a consortium-wide discussion.
Nick: I am hearing that referencing the antitrust policy in ways it was not designed for should not be done by the WG, but should be first addressed in the AB or wherever.
David: I think I partially agree with Nick_S's suggestion that this is out of scope of the technical specification.
… perhaps in this instance, we could make reference that implementers of the standard need to be aware that there are obligations that need to be met. But the standard does not dictate how things are done.
Josh: There's a nuance here that I'm seeing. We're not saying that each spec needs to add a ton of language asking people to become experts in local laws. Nor are we asking the W3C to police the activities of implementers in the marketplace, which we agree would be out of scope. We are only asking the W3C not promote specifications that would violate existing W3C policies.
… here's an analogy: if I were to propose a spec that required someone to pay a royalty, that would be rejected as inconsistent with W3C's patent policy. That's what we are saying here, too.
… we are saying that there is an existing W3C policy, and that this specification introduces ambiguities that could allow someone to violate that policy.
...I don't think the intent of the specification was to allow disintermediation. Could we clean up the language such that an implementer could not simply say "I'm just following the spec."
Nick_S: I'd really like to see if we can find an approach without legal language. Here's an example that's tricky, for example if a payment service provider is compromised.
… browser engines have revoked entire certificate authorities because either they've been compromised or issued bad certs. Browsers have unilaterally revoked them.
… one might want to make the argument that that was anti-competitive. But those actions were taken because the security interests of the user are so paramount that we have to do that and can't allow the behavior to continue.
… you can imagine a scenario where a payment provide is acting in ways detrimental to the user, and implementers may need to take actions on the user's behalf.
… the challenge is how to define that.
Josh: I agree with you, Nick_S. In the spec already written, there are already enumerations of calling out to the user that there are security issues. But the problem is that there is nebulous language in the spec that could include "my own business reasons" and we don't think that's in the spirt of the specification.
… we do not need to mention anticompetitive policy. We can bound the spec where it is currently unbounded.
smcgruer_[EST]: Thanks Nick_S; I share many of your perspectives.
… in terms of nebulous language: tricky especially where normative.
… there's a delicate balance. Need, for example, to allow browser to react to not-yet-extant security concerns.
… I took a look at points in the spec.
(Stephen reviews 3.3.6, 3.3.12, 3.3.16.5, 3.3.18)
smcgruer_[EST]: Of these, the most nebulous is 3.3.18; but it's tricky because it involves user experience.
josh: Also 14.5
smcgruer_[EST]: That one is non-normative.
Josh: We are not saying you need to list every security concern.
… if you are saying that we can limit browser to stepping in ONLY for security and privacy, that would eliminate the ambiguity.
smcgruer_[EST]: I am sympathetic to that statement. Not sure whether trying to constrain the spec in that way could create problems
Josh: Perhaps rather than "when the user agent wishes" and instead something in the neighborhood of "when the user is protecting people for security or privacy"
… eliminate the open-ended discretion.
Ian: I think speaking about "security and privacy" does not remove ambiguities in those domains themselves.
Josh: Yes, but even with those ambiguities, if we could limit the cases to "security and privacy" that would be a step forward.
smcgruer_[EST]: I would be interested in the broader w3c perspective on whether every exit condition in every API needs enumerated conditions.
Josh: I too would be interested in the feedback from the W3C members, but if we had to wait for such feedback, this would delay the current spec rather than moving forward.
Ian: Is "protect the user" too open-ended?
Josh: Yes. There are many areas to protect the user that aren't about security and privacy. We should list out any specific issues we are trying to address. If we want to protect people from climate change, that should be mentioned rather than leaving this open-ended.
(Ian was referring to "Optionally, if the user agent wishes to disallow the call to show() to protect the user, ")
Next steps
Nick: People who have concrete suggestions may send them to the mailing list.
… otherwise we have a CfC that closes tomorrow (14 January).
… thank you everyone for coming together today
… we really appreciated the presentation