Proposal: Origin Keys extension to the Origin Trials process

54 views
Skip to first unread message

Matt Giuca

unread,
Oct 15, 2020, 1:37:49 AM10/15/20
to blink-api-ow...@chromium.org, Ben Wells, Alex Russell, Dominick Ng
Hi Blink API owners,

I would like to propose a modification to the Origin Trials process for use with some APIs, which we're calling "Origin Keys". This process is to allow us to give customers a stronger guarantee about the availability of an API, but still retain the ability to contact users by managing access through a token.

Full details are in this doc:


I'm aware this is a fairly large change to the process, so I'd like this to be the start of a discussion.

However, we do have a pressing need for some of these features for an upcoming API launch, Digital Goods. We had this API slated for Origin Trial in M87, but we pulled it at the last minute because we realised that the automatic shutoff of the Origin Trials system may (however unlikely) result in apps having their sole source of payments being shut off with no warning. We aren't going to see any real-world usage of this API until we remove that potential shutoff.

So, I'd like to propose that we use this as an opportunity to have an Origin-Keys-like system without opening the floodgates right away. We want to ship Digital Goods in M88 with an Origin Trial with the following exceptions:
  1. A "no downtime" guarantee between the end of the trial and shipping. This should be uncontroversial as it has been done for several Origin Trials before.
  2. No automatic cutoff if the feature usage goes above a certain threshold. This means we can guarantee sites that their payments won't be cut off suddenly.
In the case of Digital Goods, it is highly unlikely that usage will go above the "bake-in" threshold, since it will only be available to TWAs installed via the Play Store, not on the general web. So I think this is a good API to experiment with loosening restrictions without any real danger of it being baked into the web.

In summary:
  1. We would like to run a modified Origin Trial for Digital Goods in M88 with the above restrictions removed. That would serve as a starting point for the wider Origin Keys discussion.
  2. Let's start a discussion around the Origin Keys proposal.
Thanks

Matt

Chris Harrelson

unread,
Oct 16, 2020, 8:28:02 PM10/16/20
to Matt Giuca, blink-api-owners-discuss, Ben Wells, Alex Russell, Dominick Ng
Hi Matt,

On Wed, Oct 14, 2020 at 10:37 PM Matt Giuca <mgi...@chromium.org> wrote:
Hi Blink API owners,

I would like to propose a modification to the Origin Trials process for use with some APIs, which we're calling "Origin Keys". This process is to allow us to give customers a stronger guarantee about the availability of an API, but still retain the ability to contact users by managing access through a token.

Full details are in this doc:


Would you mind adding comment access for at least the API owners, and maybe chromium accounts? That'd make it easier to ask questions on the doc.

I'm aware this is a fairly large change to the process, so I'd like this to be the start of a discussion.

However, we do have a pressing need for some of these features for an upcoming API launch, Digital Goods. We had this API slated for Origin Trial in M87, but we pulled it at the last minute because we realised that the automatic shutoff of the Origin Trials system may (however unlikely) result in apps having their sole source of payments being shut off with no warning. We aren't going to see any real-world usage of this API until we remove that potential shutoff.

So, I'd like to propose that we use this as an opportunity to have an Origin-Keys-like system without opening the floodgates right away. We want to ship Digital Goods in M88 with an Origin Trial with the following exceptions:
  1. A "no downtime" guarantee between the end of the trial and shipping. This should be uncontroversial as it has been done for several Origin Trials before.
  2. No automatic cutoff if the feature usage goes above a certain threshold. This means we can guarantee sites that their payments won't be cut off suddenly.

The automatic shutoff due to the end of an OT is negotiable, as mentioned recently on blink-dev (this was a policy change). It just requires evidence of engagement. You can ask in advance if it helps to avoid the risk of uncertainty.

I think the limits of percent of web traffic are also likely negotiable on a case by case basis, if the API owners can be convinced it's not going to be problematic.
 
Chris

Matt Giuca

unread,
Oct 18, 2020, 7:33:32 PM10/18/20
to Chris Harrelson, blink-api-owners-discuss, Ben Wells, Alex Russell, Dominick Ng
Hi Chris,

Thanks for your reply.

On Sat, 17 Oct 2020 at 11:28, Chris Harrelson <chri...@chromium.org> wrote:
Hi Matt,

On Wed, Oct 14, 2020 at 10:37 PM Matt Giuca <mgi...@chromium.org> wrote:
Hi Blink API owners,

I would like to propose a modification to the Origin Trials process for use with some APIs, which we're calling "Origin Keys". This process is to allow us to give customers a stronger guarantee about the availability of an API, but still retain the ability to contact users by managing access through a token.

Full details are in this doc:


Would you mind adding comment access for at least the API owners, and maybe chromium accounts? That'd make it easier to ask questions on the doc.

OK, I've added comment access to blink-api-owners and you (since I'm not sure if a mailing list actually works). I can't open it up to comment on Chromium accounts without revoking view access to the world, and I'd rather leave it world-viewable.

I was hoping to have the bulk of the discussion over email, since last time I made a (Google-internal) doc about this topic, I got into dozens of thorny conversations in the tiny sidebar of the doc, and it was really difficult to have those discussions. I would rather that people keep comments to small easily-answerable questions or corrections, and ask policy or philosophical questions over email, so we have more space to discuss.
 

I'm aware this is a fairly large change to the process, so I'd like this to be the start of a discussion.

However, we do have a pressing need for some of these features for an upcoming API launch, Digital Goods. We had this API slated for Origin Trial in M87, but we pulled it at the last minute because we realised that the automatic shutoff of the Origin Trials system may (however unlikely) result in apps having their sole source of payments being shut off with no warning. We aren't going to see any real-world usage of this API until we remove that potential shutoff.

So, I'd like to propose that we use this as an opportunity to have an Origin-Keys-like system without opening the floodgates right away. We want to ship Digital Goods in M88 with an Origin Trial with the following exceptions:
  1. A "no downtime" guarantee between the end of the trial and shipping. This should be uncontroversial as it has been done for several Origin Trials before.
  2. No automatic cutoff if the feature usage goes above a certain threshold. This means we can guarantee sites that their payments won't be cut off suddenly.

The automatic shutoff due to the end of an OT is negotiable, as mentioned recently on blink-dev (this was a policy change). It just requires evidence of engagement. You can ask in advance if it helps to avoid the risk of uncertainty.

OK, well, can I ask in advance now? (i.e., this is my ask.)

> It just requires evidence of engagement.

This is the tricky part -- do you need evidence that people are interested in using it (we have a lot of partners lined up), or evidence of actual usage? Understandably, developers are reluctant to put a payment flow into production without knowing that we aren't going to shut it off. So there's a bit of a cyclic dependency here. I'm happy to get a statement of interest from partners, though I'm not sure I can make it public.

Mike West

unread,
Oct 19, 2020, 3:04:14 AM10/19/20
to Matt Giuca, Chris Harrelson, blink-api-owners-discuss, Ben Wells, Alex Russell, Dominick Ng

Given the way we arrived at that change, it's not clear to me that we have a good answer for this kind of a priori decision: the core of the policy is that we allow for a shift directly from OT into the shipping API in cases where the OT successfully proved that the API solved the problem it aimed to solve. Pointing to evidence that developers engaged with the API and that it satisfied their needs seems like an essential piece of that proof.

I think what we could say today would be:

1.  This is a problem we think we should give developers tools to solve.
2.  If the OT proves that the digital goods API solves the problem reasonably well for developers in its current shape, then it seems reasonable to me to ship it without a gap.

There is some predication in #2: if the API doesn't solve the problem, we shouldn't ship it, and if it doesn't solve the problem without modification, we shouldn't ship it. Are those caveats good enough for your partners, Matt?

I think the limits of percent of web traffic are also likely negotiable on a case by case basis, if the API owners can be convinced it's not going to be problematic.

Matt Giuca

unread,
Oct 23, 2020, 12:36:55 AM10/23/20
to Mike West, Chris Harrelson, blink-api-owners-discuss, Ben Wells, Alex Russell, Dominick Ng
Hi Mike,

On Mon, 19 Oct 2020 at 18:04, Mike West <mk...@chromium.org> wrote:
On Mon, Oct 19, 2020 at 1:33 AM Matt Giuca <mgi...@chromium.org> wrote:
Hi Chris,

Thanks for your reply.

On Sat, 17 Oct 2020 at 11:28, Chris Harrelson <chri...@chromium.org> wrote:
Hi Matt,

On Wed, Oct 14, 2020 at 10:37 PM Matt Giuca <mgi...@chromium.org> wrote:
Hi Blink API owners,

I would like to propose a modification to the Origin Trials process for use with some APIs, which we're calling "Origin Keys". This process is to allow us to give customers a stronger guarantee about the availability of an API, but still retain the ability to contact users by managing access through a token.

Full details are in this doc:


Would you mind adding comment access for at least the API owners, and maybe chromium accounts? That'd make it easier to ask questions on the doc.

OK, I've added comment access to blink-api-owners and you (since I'm not sure if a mailing list actually works). I can't open it up to comment on Chromium accounts without revoking view access to the world, and I'd rather leave it world-viewable.

I was hoping to have the bulk of the discussion over email, since last time I made a (Google-internal) doc about this topic, I got into dozens of thorny conversations in the tiny sidebar of the doc, and it was really difficult to have those discussions. I would rather that people keep comments to small easily-answerable questions or corrections, and ask policy or philosophical questions over email, so we have more space to discuss.
 

I'm aware this is a fairly large change to the process, so I'd like this to be the start of a discussion.

However, we do have a pressing need for some of these features for an upcoming API launch, Digital Goods. We had this API slated for Origin Trial in M87, but we pulled it at the last minute because we realised that the automatic shutoff of the Origin Trials system may (however unlikely) result in apps having their sole source of payments being shut off with no warning. We aren't going to see any real-world usage of this API until we remove that potential shutoff.

So, I'd like to propose that we use this as an opportunity to have an Origin-Keys-like system without opening the floodgates right away. We want to ship Digital Goods in M88 with an Origin Trial with the following exceptions:
  1. A "no downtime" guarantee between the end of the trial and shipping. This should be uncontroversial as it has been done for several Origin Trials before.
  2. No automatic cutoff if the feature usage goes above a certain threshold. This means we can guarantee sites that their payments won't be cut off suddenly.

The automatic shutoff due to the end of an OT is negotiable, as mentioned recently on blink-dev (this was a policy change). It just requires evidence of engagement. You can ask in advance if it helps to avoid the risk of uncertainty.

OK, well, can I ask in advance now? (i.e., this is my ask.)

> It just requires evidence of engagement.

This is the tricky part -- do you need evidence that people are interested in using it (we have a lot of partners lined up), or evidence of actual usage? Understandably, developers are reluctant to put a payment flow into production without knowing that we aren't going to shut it off. So there's a bit of a cyclic dependency here. I'm happy to get a statement of interest from partners, though I'm not sure I can make it public.


OK thanks that's great context. I updated my doc to point to that statement.

Given the way we arrived at that change, it's not clear to me that we have a good answer for this kind of a priori decision: the core of the policy is that we allow for a shift directly from OT into the shipping API in cases where the OT successfully proved that the API solved the problem it aimed to solve. Pointing to evidence that developers engaged with the API and that it satisfied their needs seems like an essential piece of that proof.

Right, yeah it makes sense that this be part of the I2S process, not the I2E. That means we don't change anything about the I2E now (and don't need a priori evidence), but we do make a public pledge to our developers that we will ask for this policy in the I2S.

Now when it comes time to ship, if we have developers engaged with the API and depending upon it, then we should be able to make the case for gapless release in the I2S. If not, then there shouldn't be much problem dropping it. There's a middle-ground case where a small number of developers are using it but not enough to justify support; in which case I think we could ask for an extension of the OT just to give them some time to find alternatives.
 

I think what we could say today would be:

1.  This is a problem we think we should give developers tools to solve.
2.  If the OT proves that the digital goods API solves the problem reasonably well for developers in its current shape, then it seems reasonable to me to ship it without a gap.

There is some predication in #2: if the API doesn't solve the problem, we shouldn't ship it, and if it doesn't solve the problem without modification, we shouldn't ship it. Are those caveats good enough for your partners, Matt?

Yep.

I would also like us to be able to ship a V2 origin trial the very same release after stopping the V1, so that developers who are actively using it can put in an if statement and be supported continually. I don't think that's controversial, though. We did it for Badging.
 

I think the limits of percent of web traffic are also likely negotiable on a case by case basis, if the API owners can be convinced it's not going to be problematic.


Thanks for that precedent as well. I think we can make a similar justification, and based on what Alex said there, I think it's reasonable that we periodically (say once per month) monitor usage manually to make sure it isn't out of hand, but we don't have an automatic cutoff.

I noticed there that they ask for a 5% cutoff, rather than unlimited. On the one hand, it makes sense because if it goes past 5% of page loads then something is really wrong. On the other hand, if our API (or any API) went past 5% of page loads (which, to be clear, I have no expectation that it would go anywhere near that), it would be a catastrophe to instantly cut all of those sites off. I think I would be more comfortable having unlimited, and just monitoring it.


-mike

Matt Giuca

unread,
Nov 13, 2020, 1:41:23 AM11/13/20
to Mike West, Chris Harrelson, blink-api-owners-discuss, Ben Wells, Alex Russell, Dominick Ng
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?
    • Brad: The latter.
  • 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.

Reply all
Reply to author
Forward
0 new messages