Hi everyone, thanks for discussing
Origin Keys at this morning/afternoon/evening's API Owners meeting.
I took a few notes. Present: Myself, Chris Wilson, Brad Lassey, Daniel Bratell, Manuel Rego Casasnovas, Alex Russell, Yoav Weiss, Mike West
Brad Lassey was "crashing" the meeting having similar needs to my team (developing APIs to replace third-party cookies).
- Alex: This just seems like high risk (we can do all these exemptions from the base OT rules, but we haven’t done them all in combination).
- Brad: Doing APIs to replace third-party cookies.
- We’ll have functional APIs and proven their utility, but might not have other browsers on board.
- We might change the API later.
- “We’re going to fulfill these use cases, we don’t necessarily know if this will be the final form.”
- Mike: “Large entities are less likely to change based on our desire to change.” The incentive only exists if we can make a credible claim that we’re going to remove it.
- Alex: Sees it as a mechanism for limiting growth of an API (like sockets) because we don’t really want people using it.
- Talking about two distinct use cases: 1. API that we’re not sure of its interface. 2. API that’s shipped but we want to keep its usage low.
- 2 is: Things that we don’t plan to change, we aren’t trying to learn if we need it or the design, just gating the usage of the API.
- Mike: Not clear that there's concrete value [in doing an origin key vs just shipping]. We get an email address, but that isn’t really value.
- Why not ship it, then a reverse origin trial to deprecate the old one?
- Brad: Being in an "origin key" is signalling that the API might change.
- Suggestion that we restrict origin keys to a small set of interested partners.
- Matt: Entering dangerous territory in terms of control over the platform. mkwst agrees.
- Matt: Brad, are you wanting to hold back from shipping because a) you are not confident within your team that the API is correct, or b) you think that external decision makers (e.g., other browser vendors) may be unhappy with your design and want to change it, and you want to leave that option open?
- Matt: One key difference to vendor prefix (in an FAQ) is that it can’t be included in third-party libraries because it would require the host to register a key.
- Mike: Third-party origin trials may change this
- Brad: Possibly fine since that only affects libraries hosted on a 3P origin.
- [Note: Updated this section in the FAQ after this discussion.]
Now some follow-up thoughts from me.
I think basically the temperature of the room was that you're trying to tell API builders, (paraphrasing) "don't ship and pretend you aren't shipped, because you want the safety of a warm blanket. Just ship once your API is as polished as you think you can make it. Before that point, it isn't ready for an origin key. After that point, it doesn't need one."
I appreciate the notion that we should just be able to ship our API once we are internally comfortable with its state, and have gone through a period of public consultation including TAG review, etc. That may be a viable alternative to an origin key. However, upon consideration, I think this would not really help us ship sooner, rather it would generally result in us extending origin trials for longer. That's something we are OK with doing, but I want to discuss the reasoning for it and be fully up front about it.
Emails are still useful: Mike made the point that having people's email addresses doesn't really mean much for our prospects of deprecating an old API. If the usage is above the threshold, we can send them all the emails we like, but they have no incentive to act on them. They can "call our bluff" and we then have to decide whether we're bluffing, or whether we're actually going to remove an API that is heavily used. While I agree there's a "game of chicken" possibility, it doesn't mean that there's no utility in being able to contact developers. The above paints a "worst case scenario" picture, which is good to keep in mind, but there's still a plausible scenario where an API is over the usage threshold, we email all the developers, and a sufficiently high number of them respond by upgrading their API calls, thereby shifting the usage below the deprecation threshold. If we think there's a chance we'll want to modify a shipped API, we stand a much better chance of succeeding if we have all the developers' email addresses.
Known unknowns: I'll use Digital Goods as an example here. We're currently trying to consider how our API will map onto competitor's platform APIs, and whether the current design is sufficient. We're not intending to implement it for our competitors, but we anticipate trouble progressing through the standards track if the API we've designed is incompatible with non-Google platforms. We don't want this research to delay the launch of this feature, so we're doing it in parallel, but it's going to take awhile (budgeting ~1 quarter of work). Until this work is done, we're not comfortable shipping this API. We think backwards-incompatible changes may be required. But we want to get it into the hands of developers before then. An origin trial lets us do that, but it's got a soft time limit (3 milestones), after which time we'll have to apply for an extension. Maybe that's fine, because we have specific questions we'll still want answered. But it seems a little unfit for purpose, because we aren't using the OT to answer those questions, we're just extending it to keep things working while we do design work behind the scenes.
I think this is a pretty common scenario for APIs that wrap around other OS and platform APIs. We can design an API that fits our implementation, but only later discover it doesn't abstract well over a competitor's implementation. Having developers give us feedback doesn't help discover those issues; we need other vendors to implement it, or to do that investigation ourselves.
Outstanding spec work: Lastly, one of the proposals I made in the doc was that an origin key would not require web platform tests or a published spec, as it's still a Chromium-specific API. Spec work is important when shipping a finalized API, but again, we don't want to block getting our API into developers' hands on us having written a spec (which is not developer-facing documentation, it's documentation to allow other vendors to interop with our feature). If we were not able to use an origin key, but instead just shipped the API, we'd have to block that on writing specs.
The common theme here is that if we don't have origin keys, as a middle state in between origin trials and shipping, then when we meet the origin key conditions, we have to choose between a) extending the origin trial, and b) shipping. But if we are not yet internally confident that our API can properly abstract over other platforms, or if we have not yet published a spec or web platform tests, then we would choose to extend the origin trial over shipping, even though we are not blocked on experimental feedback from developers. We are blocked on our own work that still needs to be done (but it would not be acceptable to turn down the origin trial). That state is more or less what my origin key proposal is for.
If API owners are happy with us (a) getting the "gapless" exemption, where appropriate, and (b) repeatedly extending the origin trial, without specific experimental questions, until we have done the internal research / spec work required to ship, then I think we can do without origin keys. My proposal was essentially an attempt to formalize that behaviour, rather than having to apply for all of these exemptions and extensions when they come up.