Intent to Experiment: Digital Goods API v2.0

225 views
Skip to first unread message

Glen Robertson

unread,
Oct 8, 2021, 3:37:18 AM10/8/21
to blink-dev, Rouslan Solomakhin, Matt Giuca, Stephen McGruer


Contact emails

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


Explainer

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


Specification

None yet. Have a spec mentor and aiming to do this by M96 stable.


Design docs


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

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

go/dgapi2 (internal)


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 Chrome, 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 recommends making a Chrome-specific API. Other issues addressed.


TAG review status

Issues addressed


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)


WebKit: No signal (https://lists.webkit.org/pipermail/webkit-dev/2021-October/032001.html)

 

Microsoft: Initial discussions, no public signal yet (has been requested).


Samsung: Initial discussions, no public signal yet (has been requested).


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

44/61 responses of "extremely likely" to continue to use the feature from v1.0 OT

36/61 responses of slightly-to-extremely easy to use the feature (and 12 neutral) from v1.0 OT


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 have significantly reduced the API surface for v2.0, and would like to know if it is still acceptable for developers.

- We would also 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.



Reason this experiment is being extended

An origin trial ran from M88 to M95 and found some areas of developer friction and new features needed (see bugs labeled https://bugs.chromium.org/p/chromium/issues/list?q=label%3ADGAPI). We also found potential fraud issues in the v1.0 API.

The v2.0 API fixes several of the developer issues raised, and fixes the known fraud issues. However, this is a significant change to the API surface. We would like to know if the updated API is still acceptable for developers.



Ongoing technical constraints

None


Debuggability

We have had several requests from developers to make the API easier to debug, but it is difficult due to the interaction with a backing service based in an app/store context. We are looking for suggestions on how we might improve the debuggability of the API.


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

No

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. The JS<->mojo interface (Blink code) is tested but the backing app/store context is unavailable in WPT.


Flag name

DigitalGoods


Requires code in //chrome?

False


Tracking bug

https://crbug.com/1248319


Launch bug

https://crbug.com/1250123


Estimated milestones

OriginTrial desktop last

99

OriginTrial desktop first

96


OriginTrial android last

99

OriginTrial android first

96




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 (DGAPI v1.0): https://groups.google.com/a/chromium.org/g/blink-dev/c/syI9_M9dANY/m/3lt-QGMHAgAJ

Intent to Continue Experimenting (DGAPI v1.0):

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



This intent message was generated by Chrome Platform Status.


Matt Menke

unread,
Oct 8, 2021, 5:18:30 PM10/8/21
to blink-dev, Glen Robertson, Rouslan Solomakhin, Matt Giuca, Stephen McGruer
Skimming over the explainer, I can't determine whether this leaks data cross-site or not.  Are these digital products that the API manages exposed across sites, restricted to same-origin frame, restricted to same-origin 1P contexts, or what?

Glen Robertson

unread,
Oct 11, 2021, 11:03:24 PM10/11/21
to Matt Menke, blink-dev, Rouslan Solomakhin, Matt Giuca, Stephen McGruer
In Chrome, the feature is controlled by the "payment" feature policy, and is therefore unavailable except in top-level context or when explicitly delegated to subframes (we are planning to disallow delegation too). Digital products managed by the API are specific to an origin.
IIUC we don't usually specify how user agents should do security controls but I've added these as suggestions in the explainer.

Matt Menke

unread,
Oct 11, 2021, 11:13:53 PM10/11/21
to Glen Robertson, blink-dev, Rouslan Solomakhin, Matt Giuca, Stephen McGruer
All intent emails - including experiment, are reviewed for potential privacy and security issues.  If this is keyed on frame origin, delegating to cross-origin iframes is a cross-site tracking vector.  If cross-origin iframes have access to it, but keyed on top frame origin rather than iframe origin, it's not a privacy issue (though haven't thought about security considerations).  Disallowing delegation, or otherwise addressing the cross-site tracking issue would be needed to launch, so it's good to be aware of it now, rather than only learning that this is an issue when trying to ship.

Glen Robertson

unread,
Oct 12, 2021, 12:46:07 AM10/12/21
to Matt Menke, blink-dev, Rouslan Solomakhin, Matt Giuca, Stephen McGruer
Yes, we are planning to disallow delegation before shipping. This was discussed in the privacy review on the launch bug.

--
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/CAEK7mvpq1krCWQfTc_hi1mRSW9rwznRScDWa4dyUQPGPYt2jtQ%40mail.gmail.com.

Yoav Weiss

unread,
Oct 14, 2021, 4:40:11 AM10/14/21
to Glen Robertson, Matt Menke, blink-dev, Rouslan Solomakhin, Matt Giuca, Stephen McGruer
Is it possible to disallow delegation for the OT as well?

Glen Robertson

unread,
Oct 14, 2021, 7:02:48 PM10/14/21
to Yoav Weiss, Matt Menke, blink-dev, Rouslan Solomakhin, Matt Giuca, Stephen McGruer
Probably not before the OT starts, but yes before the OT finishes. I am adding a metric to see if there's any attempted usage of the API in this way currently, so we will need to get that out, then wait a milestone to see the result. That approach was OK'd by privacy review.
Also note that this isn't a change from the v1 API.

Glen Robertson

unread,
Oct 15, 2021, 2:48:23 AM10/15/21
to Yoav Weiss, Matt Menke, blink-dev, Rouslan Solomakhin, Matt Giuca, Stephen McGruer
Actually, we could disable cross-origin usage and measure attempted usage at the same time (in M96 with merge, in time for v2.0 OT start).
Sounds like this would be preferred by Blink Owners? I'll check with others on the team.

Yoav Weiss

unread,
Oct 15, 2021, 2:56:22 AM10/15/21
to Glen Robertson, Matt Menke, blink-dev, Rouslan Solomakhin, Matt Giuca, Stephen McGruer
That'd be significantly better from my perspective, thanks! :)

Glen Robertson

unread,
Oct 18, 2021, 1:29:23 AM10/18/21
to Yoav Weiss, Matt Menke, blink-dev, Rouslan Solomakhin, Matt Giuca, Stephen McGruer
We now intend to disable cross-origin usage of the DGAPI along with the v2.0 OT (I'm working on a CL, still needs to be landed and merged to M96).

Glen Robertson

unread,
Oct 18, 2021, 1:30:33 AM10/18/21
to Yoav Weiss, Matt Menke, blink-dev, Rouslan Solomakhin, Matt Giuca, Stephen McGruer

Yoav Weiss

unread,
Oct 18, 2021, 1:30:52 AM10/18/21
to Glen Robertson, Matt Menke, blink-dev, Rouslan Solomakhin, Matt Giuca, Stephen McGruer
That's great to hear! 
LGTM to experiment M96-M99 (inclusive)

Glen Robertson

unread,
Oct 18, 2021, 1:46:18 AM10/18/21
to Yoav Weiss, Matt Menke, blink-dev, Rouslan Solomakhin, Matt Giuca, Stephen McGruer

Glen Robertson

unread,
Feb 7, 2022, 7:24:46 PMFeb 7
to Yoav Weiss, Matt Menke, blink-dev, Rouslan Solomakhin, Matt Giuca, Stephen McGruer
We are now shipping this API in M100, but want to avoid a gap for users yet to update from M99.

Could we have approval to extend the OT end date (currently 2022-03-22, one week before M100 release) to 2022-05-22, without changing the end milestone? This should allow time for M100 to roll out before the OT is disabled.

Thanks

Chris Harrelson

unread,
Feb 7, 2022, 7:28:58 PMFeb 7
to Glen Robertson, Yoav Weiss, Matt Menke, blink-dev, Rouslan Solomakhin, Matt Giuca, Stephen McGruer

Glen Robertson

unread,
Feb 7, 2022, 7:38:39 PMFeb 7
to Chris Harrelson, Yoav Weiss, Matt Menke, blink-dev, Rouslan Solomakhin, Matt Giuca, Stephen McGruer
Thanks!
Reply all
Reply to author
Forward
0 new messages