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.
On Mon, Oct 11, 2021 at 11:03 PM Glen Robertson <glen...@chromium.org> wrote: > 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 > <https://bugs.chromium.org/p/chromium/issues/detail?id=1257010> 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 > <https://github.com/WICG/digital-goods/blob/main/explainer.md#security-and-privacy-considerations> > . > > On Sat, 9 Oct 2021 at 02:40, Matt Menke <mme...@google.com> wrote: > >> 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? >> >> On Friday, October 8, 2021 at 3:37:18 AM UTC-4 Glen Robertson wrote: >> >>> >>> Contact emails >>> >>> >>> *mgi...@chromium.org, gle...@chromium.org, rou...@chromium.org*Explainer >>> >>> >>> *https://github.com/WICG/digital-goods/blob/master/explainer.md >>> <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://github.com/WICG/digital-goods/blob/master/explainer.md>https://docs.google.com/document/d/1Jbt2Mzt-xg1cWVlFScBQsoX_pE8Kg1gYpulxUSV8FM0/edit >>> <https://docs.google.com/document/d/1Jbt2Mzt-xg1cWVlFScBQsoX_pE8Kg1gYpulxUSV8FM0/edit>go/dgapi2 >>> <https://goto.google.com/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 >>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPayments>*Search >>> tags >>> >>> >>> *payments <https://chromestatus.com/features#tags:payments>, billing >>> <https://chromestatus.com/features#tags:billing>*TAG review >>> >>> >>> *https://github.com/w3ctag/design-reviews/issues/571 >>> <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 >>> <https://github.com/mozilla/standards-positions/issues/349>)WebKit: No >>> signal >>> (https://lists.webkit.org/pipermail/webkit-dev/2021-October/032001.html >>> <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 >>> <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 >>> OT36/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 >>> <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 >>> <https://github.com/WICG/digital-goods/issues/33> 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)? >>> >>> >>> >>> *NoNo, Android and Chrome OS only (the two platforms where we have Play >>> Store integration).*Is this feature fully tested by web-platform-tests >>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>> ? >>> >>> >>> *No. The JS<->mojo interface (Blink code) is tested >>> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/wpt_internal/digital-goods/> >>> but the backing app/store context is unavailable in WPT.*Flag name >>> >>> >>> *DigitalGoods*Requires code in //chrome? >>> >>> >>> *False*Tracking bug >>> >>> >>> *https://crbug.com/1248319 <https://crbug.com/1248319>*Launch bug >>> >>> >>> *https://crbug.com/1250123 <https://crbug.com/1250123>*Estimated >>> milestones >>> >>> >>> >>> >>> >>> *OriginTrial desktop last99OriginTrial desktop first96OriginTrial >>> android last99OriginTrial android first96*Link to entry on the Chrome >>> Platform Status >>> >>> >>> *https://chromestatus.com/feature/5339955595313152 >>> <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 >>> <https://www.chromestatus.com/>. >>> >>> -- 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+unsubscr...@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.
