Intent to Experiment: Digital Goods API

[Matt Giuca]

Contact emails

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

Explainer

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

Design docs

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

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

TAG review

None yet.

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.

Link to “Intent to Prototype” blink-dev discussion

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

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: Negative (https://github.com/WICG/digital-goods/issues/5) A Firefox developer expressed skepticism that this was healthy, saying that it could be done with a REST API instead (note that this would exclude Play Billing as a backend).

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): Experiment ends

Reason this experiment is being extended

N/A

Ongoing technical constraints

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?

None yet.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5339955595313152

[Chris Harrelson]

LGTM

--
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/CAHqYdcatXRwJ4tvh%3DRkJ0jg3Z_so2ikfYYLg5GFfuZEuSLGthw%40mail.gmail.com.

[Matt Giuca]

Hello,

This trial was scheduled to start in M87, but unfortunately we hit a last-minute issue. We realised that there was no way for developers to determine whether they were subject to Play Billing policy, other than by feature-detecting the presence of the Digital Goods API. Since in an origin trial, it can be disabled at any time, this is not a good indicator of whether you are subject to Play Billing policy (note that if the API goes away, you would still be subject to the policy). So we need to rethink this aspect, and possibly provide a different mechanism for determining whether you are subject to policy.

We are disabling the API in M87 and pushing the trial start date back to M88.

Thanks and apologies to anybody who was keen to test this out. Please note that you can use the #enable-experimental-web-platform-features flag to test this on your own devices.

Regards

Matt

[Matt Giuca]

Hi all,

I started a parallel discussion on blink-api-owners-discuss about "Origin Keys" but also a discussion about Origin Trials policy around Digital Goods. Apologies that there are now two threads on this. Here is a status update:

1. Per my previous message, we would like to commence the Digital Goods origin trial in M88, and intend to re-land the code to enable it in the coming days.
2. As discussed on that thread, we would like to promise our devs that there will be no planned downtime of the feature if it goes to stable without changes.
3. Also, we would like to promise our devs that there will be no usage threshold at which the API cuts out. We do not expect the usage will be anywhere near that threshold (since it will only be available to sites installed through the Play Store, not the open web), but we want to make a guarantee to developers.

The second and third points I am discussing on the blink-api-owners-discuss thread, so if you have an opinion about them, please respond there instead of forking the discussion here.

[Morgaine]

This feels radically worse off for the web than, say, Media Feeds, which used a declarative, visible model for letting the page declare additional content. https://wicg.github.io/media-feeds/

There should absolutely be some sort of tie-in to https://developers.google.com/search/docs/guides/intro-structured-data . The JS-centric API present, copied out of Android, is not web friendly. This work should not go forward as is.

I'm no one, with no say, but this is really harmful to see. I like the use cases, it seems like a good idea, but porting an imperative platform on to the web like this is harmful.

[Rouslan Solomakhin]

Could you please elaborate on the use cases that would be better served by structured data? I'm wondering what kind of harm could be coming from an API being imperative, if I understand the comment correctly.

[Matt Giuca]

Hi Morgaine,

I think this is a misunderstanding of what the Digital Goods API is for. It isn't an API for the page to declare additional content for use by the user agent. It's an API for the page to fetch additional content from the back-end store, for its own uses.

More concretely, say you are selling a "premium upgrade" for $5.99. We aren't making an API that lets the site declare that they are selling a premium upgrade for $5.99. We are making an API for the JavaScript / client logic in the web app to query "what am I selling?" and receive back the details "you are selling a premium upgrade for $5.99". This allows the site to present an in-app UI allowing the user to buy items.

Why would a site need to look up info about itself? Basically so that it can have a single point of control. If you're selling goods through, say, the Google Play Store, you can manage all the products through the Play console, change prices or set international pricing, and the in-app store UI will reflect those changes, without having to maintain a separate copy of the data for the front-end app.

The above is our goal. I don't see how a declarative model like Media Feeds helps us achieve that goal.

> The JS-centric API present, copied out of Android, is not web friendly.

I'll object to the "copied out of Android". We have gone to great lengths to design a generic and minimal API that can be adapted by various backend stores. We've chosen generic names (not just using Android names), we've designed the API using best Web API practices (e.g., using promises rather than callback listeners), and chosen a minimal subset of the API that's truly needed to build a basic functioning in-app purchase flow, rather than just exposing the entire Android API.

Part of what we want to learn during the origin trial is are there changes we need to make to the API to avoid further Play Billing biases and make it more adaptable to other stores.