Intent to Deprecate and Remove: PaymentInstruments

[Rouslan Solomakhin]

Contact emails

rou...@chromium.org, smcg...@chromium.org

Summary

PaymentInstruments is the Web API that backs non-JIT install of payment apps (see https://w3c.github.io/payment-handler/). It was designed with the assumption that the browser would store the actual payment instrument details, which has not turned out to be true, and has some privacy leaks. It also has not shipped on any other browser, not have we seen any interest from other browser vendors. As such, we are interested in deprecating and removing the API.

Blink component

Blink>Payments

Motivation

The PaymentInstruments.set() method allows an attacker website to store arbitrary data, which can later be retrieved via PaymentInstruments.get() potentially in a third-party context. For example, the user visits https://tracker.example, which generates and stores a UUID for that user via PaymentInstruments.set(key, UUID). Later, the user visits https://site.example, which opens an iframe for https://tracker.example. That iframe calls PaymentInstruments.get(key) and can retrieve the UUID, thus allowing https://tracker.example to know which user it is. Given the lack of uptake in PaymentInstruments.set(), versus the more common JIT-install path, as well as the overly powerful nature of the API, we propose to remove PaymentInstruments entirely. (PaymentInstruments was designed with the belief that the browser would know about individual payment methods (e.g., credit cards) rather than payment apps, hence the need to store/retrieve arbitrary information.)

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Gecko: Does not implement the Payment Handler API.
WebKit: Does not implement the Payment Handler API.
Web developers: No signals

Other signals:  Metrics of API usage show little to no uptake (< 0.00010 % page loads)

PaymentInstruments - https://chromestatus.com/metrics/feature/timeline/popularity/4229
PaymentInstruments.clear - https://chromestatus.com/metrics/feature/timeline/popularity/4230
PaymentInstruments.delete - https://chromestatus.com/metrics/feature/timeline/popularity/4231
PaymentInstruments.get - https://chromestatus.com/metrics/feature/timeline/popularity/4232
PaymentInstruments.has - https://chromestatus.com/metrics/feature/timeline/popularity/4233
PaymentInstruments.keys - https://chromestatus.com/metrics/feature/timeline/popularity/4234
PaymentInstruments.set - https://chromestatus.com/metrics/feature/timeline/popularity/4235

WebView application risks

Payment Handler API is not implemented in WebView.

Debuggability

Standard DevTools debugging.

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

Yes - https://wpt.fyi/results/payment-handler/payment-instruments.https.html

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1327265

Launch bug

https://crbug.com/1363633

Estimated milestones

Would like to remove in M108.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5099285054488576

This intent message was generated by Chrome Platform Status.

[Chris Harrelson]

LGTM1

--
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/CAMMzaWGzus%3DU48U06m-gk7_2G6Wnhn59UJXLi9xW9uz5%2BEWQuA%40mail.gmail.com.

[Mike Taylor]

Hi Rouslan,

Usage is indeed low - do we have any reason to believe there are consumers of this API who have disabled telemetry, i.e. maybe in enterprise contexts? And do we know how these few sites who are using the API... are using the API? Does any real-world usage show up in HTTP Archive?

thanks,
Mike

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

[Rouslan Solomakhin]

Hi Mike,

>  do we have any reason to believe there are consumers of this API who have disabled telemetry, i.e. maybe in enterprise contexts?

We don't have any indications that this could be happening.

> do we know how these few sites who are using the API... are using the API? Does any real-world usage show up in HTTP Archive?

Found 2 websites in HTTP Archive:

1. A payment app website that also uses a JIT install for payment handlers.
2. A payment app website that installs a payment handler when you visit their home page, but the code looks more like a demo because of hard-coded strings.

Happy to discuss further.

Cheers,

Rouslan

[Yoav Weiss]

On Thu, Sep 15, 2022 at 9:03 PM Rouslan Solomakhin <rou...@chromium.org> wrote:

Hi Mike,

>  do we have any reason to believe there are consumers of this API who have disabled telemetry, i.e. maybe in enterprise contexts?

We don't have any indications that this could be happening.

> do we know how these few sites who are using the API... are using the API? Does any real-world usage show up in HTTP Archive?

Found 2 websites in HTTP Archive:

1. A payment app website that also uses a JIT install for payment handlers.
2. A payment app website that installs a payment handler when you visit their home page, but the code looks more like a demo because of hard-coded strings.

Would we expect those uses to break? Are they feature detecting the API before using it?

 

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

[Rouslan Solomakhin]

> Would we expect those uses to break? Are they feature detecting the API before using it?

Partially (for both questions!). In examining the site logic we have found that:

Good news:

1. These websites will correctly fall back to JIT install of payment handlers in the absence of PaymentInstruments. That does not use the PaymentInstruments API and will continue to work as before.
2. The websites are feature-detecting the parent PaymentManager interface, registration.paymentManager, which is currently implemented only in Blink.

Bad news:

1. Once the websites detect the presence of registration.paymentManager, they assume that it has all of the fields present, including registration.paymentManager.instruments. If we remove this instruments field, then there will be some JavaScript errors on these websites. As far as we can tell, these errors are limited in impact and do not affect overall site functionality.

[Yoav Weiss]

What did you have in mind in terms of a deprecation timeline? Are you planning to pipe that through CountDeprecation to ensure deprecation reporting?

[Rouslan Solomakhin]

Due to the low uptake (< 0.00010 % page loads), we were planning to remove PaymentInstruments API without deprecation reporting, but I am happy to adjust our plans if necessary. What would you recommend?

[Stephen Mcgruer]

(remove in M108, to be clear - just restating from the Chromestatus entry as Yoav asked about the timeline)

[Mike Taylor]

Thanks for all the research Rouslan. The risk seems pretty low (despite the few known instances of breakage - trying to directly contact those sites would be good), but unless there's a compelling reason to remove it ASAP, a few milestones of deprecation reports could surface this to environments where telemetry disabled.

[Rouslan Solomakhin]

Sounds like a good plan. In that case, I am requesting to:

1. Print a deprecation warning in M108 - M110.
2. Remove in M111.

I will also directly contact the sites that are known to be using the PaymentInstruments API.

[Mike Taylor]

LGTM2, thanks.

[Philip Jägenstedt]

LGTM3, seems best to have a deprecation period unless the code is causing trouble.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a32ca941-66c4-6267-f34b-0ea67c968153%40chromium.org.