Intent to Continue Experimenting: Digital Goods API

103 views
Skip to first unread message

Glen Robertson

unread,
May 6, 2021, 11:30:38 AMMay 6
to blink-dev, Matt Giuca, rou...@chromium.org

Contact emails

mgi...@chromium.org, gle...@chromium.org, rou...@chromium.org


Explainer

https://github.com/WICG/digital-goods/blob/master/explainer.md


Specification

None


Design docs

https://github.com/WICG/digital-goods/blob/master/explainer.md

https://docs.google.com/document/d/1Jbt2Mzt-xg1cWVlFScBQsoX_pE8Kg1gYpulxUSV8FM0/edit


Summary

An API for querying and managing digital products to facilitate in-app purchases from web applications, in conjunction with the Payment Request API (which is used to make the actual purchases). The API would be linked to a digital distribution service connected to via the user agent. In Chromium, this is specifically a web API wrapper around the Android Play Billing API.


Blink component

Blink>Payments


Search tags

payments, billing


TAG review

https://github.com/w3ctag/design-reviews/issues/571


TAG review status

In progress


Risks

Interoperability and Compatibility

Similar to Payment Request: this API is used to talk to specific store backends, and so its usage is tailored to the specific store. The reason it's a proposed web standard is so that the same code (which is specific to one store) is portable across browsers.

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/349). Awaiting feedback.

WebKit: No signal

Web developers: Positive (https://discourse.wicg.io/t/proposal-web-payments-digital-product-management-api/4350)

Ergonomics

Used in tandem with the Payment Request API.

Goals for experimentation

- General API design. Determine whether developers need to access more data that would be exposed through the Play Billing API but is not exposed through our web API.

- Specifically, we would like to know whether the API is suitable for abstracting over other non-Play stores. While running an experiment with the current implementation won't tell us this, it will set up real-world clients and we can then try their sites on other implementations.

Experimental timeline

- M87 (2020-11-17): Experiment begins

- M90 (2021-04-13): Original experiment end date

- M93 (2021-08-31): Extended experiment end date


Reason this experiment is being extended

An origin trial ran from M87 to M90 and found some areas of developer friction and new features needed (see bugs labeled DGAPI). We haven't yet had time to fix all the issues and update the API. We are planning to update the API and run a next phase of the experiment with a v2 API soon. We would like to avoid stopping the experiment in between the phases to avoid unnecessarily disrupting current users of the API while we work on the next iteration.


Ongoing technical constraints

None


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

No, Android and Chrome OS only (the two platforms where we have Play Store integration).


Is this feature fully tested by web-platform-tests?

No


Flag name

None


Tracking bug

https://crbug.com/1061503


Launch bug

https://crbug.com/1017947


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5339955595313152


Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/vkS3k30lWNs

Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/syI9_M9dANY/m/3lt-QGMHAgAJ

This intent message was generated by Chrome Platform Status.

Alex Russell

unread,
May 6, 2021, 3:34:30 PMMay 6
to blink-dev, Glen Robertson, Matt Giuca, Rouslan Solomakhin
Hey all,

Met today at API OWNERS to discuss. I don't think folks are necessarily opposed to extending this, but a few things jump out:

  • 8 milestones as at the far end of how long we'd like any OT to run
  • Given that, it would be helpful to summarize both a plan for what the new API will look like as well as lessons learned to date
I know that some of that is captured in the DGAPI bugs linked, but it would help if there were a summary document that described the developer feedback to date, the changes you'll be making to the API to compensate, and the plan for (hopefully) validating the new API works as developers expect quickly, then launching or sunsetting.

Thanks

Matt Giuca

unread,
May 7, 2021, 3:37:34 AMMay 7
to Alex Russell, blink-dev, Glen Robertson, Rouslan Solomakhin
Hi Alex,

Thanks for the notes from your meeting. I think we can create a summary of the proposed design changes (however, note that it's somewhat undecided at this stage, what specific changes will need to be made). I don't want to block the extension of the origin trial on having a design proposal, since that could jeopardize customers' ability to use the API.

Does the 8-milestone run include the planned future "V2 API" origin trial, (i.e. if we run this for another 3 milestones, we'll only have 2 milestones left to do a V2 origin trial)? Or do you mean 8 milestones without making changes to the API.

I think the latter would be pretty reasonable, but as I'm sure I've said before, I'm not too comfortable having a hard deadline on having to ship a new API or losing it. Having hard deadlines for shipping features, especially one this complex, generally results in rushed and buggy experiences. If we, say, get to M95 and have a working implementation for V2, but discover a bug at the last minute, I want to be able to have no hesitation to punt the release for an additional milestone (I don't want us to feel compelled to push it out the door because of an arbitrary 8-milestone limit).

I'll note that I raised this issue for this specific API in a general discussion with Blink API Owners in November 2020 (email). Relevant quotes from myself from that email:

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.
...
If API owners are happy with us ... 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.

Now I didn't get a response to that email at the time. The context was that we were asking for a formal "origin keys" system, and in that meeting, I was told that it wouldn't be necessary because origin trials are suitable for that purpose. Per my final paragraph there, it may not be that origin trials are suitable for this purpose, if in practice API owners are going to block origin trial extensions.

To be clear, we aren't intending to extend this indefinitely. I am hoping we can have this API shipped some time this year. But I am flagging that we can't guarantee that we'll have the necessary changes made by a specific milestone, and I don't want to be hard-bound to make those changes by a specific date.

Thanks

Matt

Yoav Weiss

unread,
May 7, 2021, 5:44:45 AMMay 7
to Matt Giuca, Alex Russell, blink-dev, Glen Robertson, Rouslan Solomakhin
Hey Matt,

The main goals for the duration restrictions that Alex mentioned is to avoid cases where Origin Trials are being used as a "soft launch" mechanism and to avoid prematurely baking in the feature into the platform.
Significant changes to the API shape (as the ones you allude to with the V2 API) would provide some assurances against bake in, and from my perspective would "restart the clock".

However, that doesn't mean that breaking the API every X milestones would enable y'all to have it in OT forevermore. We also want to see that the OT is being used to provide us with meaningful feedback. I believe that's the reason Alex asked for a summary of lessons learned, as well as a plan to eventually ship this.



On Fri, May 7, 2021 at 9:37 AM Matt Giuca <mgi...@chromium.org> wrote:
Hi Alex,

Thanks for the notes from your meeting. I think we can create a summary of the proposed design changes (however, note that it's somewhat undecided at this stage, what specific changes will need to be made). I don't want to block the extension of the origin trial on having a design proposal, since that could jeopardize customers' ability to use the API.

Does the 8-milestone run include the planned future "V2 API" origin trial, (i.e. if we run this for another 3 milestones, we'll only have 2 milestones left to do a V2 origin trial)? Or do you mean 8 milestones without making changes to the API.

I think the latter would be pretty reasonable, but as I'm sure I've said before, I'm not too comfortable having a hard deadline on having to ship a new API or losing it. Having hard deadlines for shipping features, especially one this complex, generally results in rushed and buggy experiences. If we, say, get to M95 and have a working implementation for V2, but discover a bug at the last minute, I want to be able to have no hesitation to punt the release for an additional milestone (I don't want us to feel compelled to push it out the door because of an arbitrary 8-milestone limit).

We definitely don't want you or other feature teams to rush to ship features that are not ready. What I'd generally recommend is for you to have a rough plan for exiting the experimentation phase, and to come back to the API owners if e.g. last minute extensions are needed.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHqYdcYbiwZYA6atQ%3DsN6nkaT6M-7avGhOBdwjA373PG%3DCq2cg%40mail.gmail.com.

Glen Robertson

unread,
May 10, 2021, 12:43:53 AMMay 10
to Aer Berkopec, Yoav Weiss, berkop...@gmail.com, Matt Giuca, Alex Russell, blink-dev, Rouslan Solomakhin
Sorry, I made a mistake in my original email in this thread: we actually delayed the start of the OT so I had the milestones wrong.
Corrected milestones follow:

Experimental timeline
- M88(Android)/M89(Desktop): First experiment milestone
- M90: Original final experiment milestone
- M93: Extended final experiment milestone

On Fri, 7 May 2021 at 23:19, Aer Berkopec <aerber...@gmail.com> wrote:


Yoav Weiss

unread,
May 10, 2021, 1:30:58 AMMay 10
to Glen Robertson, Aer Berkopec, berkop...@gmail.com, Matt Giuca, Alex Russell, blink-dev, Rouslan Solomakhin
In that case, we're talking about 6 milestones all in all? That sounds perfectly reasonable.

Matt Giuca

unread,
May 10, 2021, 4:35:52 AMMay 10
to Yoav Weiss, Glen Robertson, Aer Berkopec, berkop...@gmail.com, Alex Russell, blink-dev, Rouslan Solomakhin
Thanks for the explanation, Yoav.

Yes, we are talking about 6 milestones total (note: 5 milestones on Chrome OS, which is where a lot of our customers are targeting, since we missed the first milestone there).

As said above, we are anticipating a V2 origin trial at some point in the future. We think we'll have a pretty solid design by the end of the quarter (that's roughly corresponding to the start of M94) but we simply can't promise that V2 will be implemented by then. When we get to M94, I think it is likely that we'll need to further extend the existing origin trial, but we should have a much better picture of the work required by then. Another possibility is that we ship all or part of the current API to general availability (if it is determined that the new changes are additions, rather than changes, to the existing API).

Sorry if this is vague, but I am trying to keep our options open and make sure that we aren't making promises we can't keep. My point above stands, that I don't want to set hard engineering deadlines which, if we don't meet them, will result in the disappearance of the API for our customers. We are not trying to keep this API in origin trial forever, but we need time to work towards a solution.

Matt

Yoav Weiss

unread,
May 10, 2021, 6:54:37 AMMay 10
to Matt Giuca, Glen Robertson, Aer Berkopec, berkop...@gmail.com, Alex Russell, blink-dev, Rouslan Solomakhin
On Mon, May 10, 2021 at 10:35 AM Matt Giuca <mgi...@chromium.org> wrote:
Thanks for the explanation, Yoav.

Yes, we are talking about 6 milestones total (note: 5 milestones on Chrome OS, which is where a lot of our customers are targeting, since we missed the first milestone there).

As said above, we are anticipating a V2 origin trial at some point in the future. We think we'll have a pretty solid design by the end of the quarter (that's roughly corresponding to the start of M94) but we simply can't promise that V2 will be implemented by then. When we get to M94, I think it is likely that we'll need to further extend the existing origin trial, but we should have a much better picture of the work required by then. Another possibility is that we ship all or part of the current API to general availability (if it is determined that the new changes are additions, rather than changes, to the existing API).

Ideally, at that point you would have well-documented learnings from the OT that you could use to justify either a decision to ship some parts of the API, or change it towards a second OT.
 

Sorry if this is vague, but I am trying to keep our options open and make sure that we aren't making promises we can't keep. My point above stands, that I don't want to set hard engineering deadlines which, if we don't meet them, will result in the disappearance of the API for our customers. We are not trying to keep this API in origin trial forever, but we need time to work towards a solution.

The above SGTM!

Alex Russell

unread,
May 13, 2021, 3:24:47 PMMay 13
to blink-dev, Yoav Weiss, Glen Robertson, aerber...@gmail.com, berkop...@gmail.com, Alex Russell, blink-dev, Rouslan Solomakhin, Matt Giuca
SGTM too; LGTM!

 

Matt

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Matt Giuca

unread,
May 13, 2021, 8:24:24 PMMay 13
to Alex Russell, blink-dev, Yoav Weiss, Glen Robertson, aerber...@gmail.com, berkop...@gmail.com, Rouslan Solomakhin
Thanks Alex and Yoav.

SGTM too; LGTM!

 

Matt

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
Reply all
Reply to author
Forward
0 new messages