Intent to Experiment: Digital Goods API v2.0

[Glen Robertson]

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]

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]

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]

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]

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]

Is it possible to disallow delegation for the OT as well?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPV%2BSg_%3D%3DywYCB%2B6ZsaXAndHpX9c_c_mBtU47KBEmX6Qm1J6vA%40mail.gmail.com.

[Glen Robertson]

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]

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]

That'd be significantly better from my perspective, thanks! :)

[Glen Robertson]

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]

This is being tracked on https://bugs.chromium.org/p/chromium/issues/detail?id=1257010

[Yoav Weiss]

That's great to hear! 

LGTM to experiment M96-M99 (inclusive)

[Glen Robertson]

Thanks!

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUmYkZGF%2BYcnArrcvgTAkpYmWD2ztRcDtp9HvUW__jvWg%40mail.gmail.com.

[Glen Robertson]

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]

LGTM

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPV%2BSg8bdfvThMvE_tQUGVroLLQOx91zM%2BQsTAzGhLN_qDZS_w%40mail.gmail.com.

[Glen Robertson]

Thanks!