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

On Wed, Sep 21, 2022 at 5:16 PM Mike Taylor <[email protected]> wrote:

> LGTM2, thanks.
>
> On 9/21/22 10:59 AM, Rouslan Solomakhin wrote:
>
> 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.
>
> On Wed, Sep 21, 2022 at 10:52 AM Mike Taylor <[email protected]>
> wrote:
>
>> 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.
>>
>> On 9/21/22 9:10 AM, Stephen Mcgruer wrote:
>>
>> (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>
>>>>>>> .
>>>>>>>
>>>>>>
>>
> --
> 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/a32ca941-66c4-6267-f34b-0ea67c968153%40chromium.org
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a32ca941-66c4-6267-f34b-0ea67c968153%40chromium.org?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/CAARdPYfNRTvmt7HM%3D7b5BUnMvuvZCTUTMwT03dkuFW%2Bgjutv7A%40mail.gmail.com.

Reply via email to