(remove in M108, to be clear - just restating from the
Chromestatus entry as Yoav asked about the timeline)
On Wed, Sept 21, 2022, 9:00 a.m. Rouslan Solomakhin
<[email protected]> wrote:
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?
On Wed, Sep 21, 2022 at 1:42 AM Yoav Weiss
<[email protected]> wrote:
What did you have in mind in terms of a deprecation
timeline? Are you planning to pipe that through
CountDeprecation
<https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/frame/deprecation/deprecation.h;l=41?q=deprecation.h&ss=chromium>
to
ensure deprecation reporting?
On Tue, Sep 20, 2022 at 4:26 PM Rouslan Solomakhin
<[email protected]> wrote:
> 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.
On Tue, Sep 20, 2022 at 5:20 AM Yoav Weiss
<[email protected]> wrote:
On Thu, Sep 15, 2022 at 9:03 PM Rouslan
Solomakhin <[email protected]> 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?
Happy to discuss further.
Cheers,
Rouslan
On Wed, Sep 14, 2022 at 12:23 PM Mike Taylor
<[email protected]> wrote:
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
On 9/14/22 8:55 AM, Chris Harrelson wrote:
LGTM1
On Wed, Sep 14, 2022 at 8:05 AM Rouslan
Solomakhin <[email protected]> wrote:
Contact emails
[email protected],
[email protected]
Summary
PaymentInstruments
<https://w3c.github.io/payment-handler/#paymentinstruments-interface>
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
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPayments>
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
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?
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
<https://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
[email protected].
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
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMMzaWGzus%3DU48U06m-gk7_2G6Wnhn59UJXLi9xW9uz5%2BEWQuA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
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 [email protected].
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
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8_gN61x4ijCz_Dz433Lf8B-Vbi0rrtKjUFnXJ1Lw__SQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
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
[email protected].
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
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMMzaWH6hkEcc3yx0%3DhP%2Bup7gHw1KeS5KW_hi0YbU9t7oi1yVA%40mail.gmail.com?utm_medium=email&utm_source=footer>.