Re: [blink-dev] Intent to Ship: Origin Isolation By Default / Deprecate document.domain on stable

['Eiji Kitamura' via blink-dev]

@Maud Nalpas  is taking over the DevRel work.

On Sat, May 27, 2023 at 12:21 AM Rick Byers  wrote:

> Thanks for the update Daniel. Still LGTM. Good luck!
>
> On Fri, May 26, 2023 at 10:25 AM Daniel Vogelheim 
> wrote:
>
>> Hello all, it's been a while... The bug reports should now be resolved,
>> and we'd like to have another go at this in the M115 milestone. That is:
>> Remain at 50% on beta; starting with 115 ramp up on stable to 1% / 10% /
>> 50% / 100%, every 14d. Let's hope it sticks this time.
>>
>> Daniel
>>
>> On Fri, Mar 31, 2023 at 3:54 PM Daniel Vogelheim 
>> wrote:
>>
>>> Hello all, I'm afraid I have to delay this a bit more. :(
>>>
>>> We have a bug report (tracked in crbug.com/1429587) that breaks
>>> existing apps. The important thing here is that it does not break
>>> document.domain setting and subsequent cross-origin access, but that
>>> instead -- if the conditions are just right; or arguably just wrong -- the
>>> app can get into a state where same-origin accesses are mistakenly blocked.
>>> Apparently an app can get into a state where frames within the same page
>>> are inconsistently assigned to agent clusters (i.e., frames in the same
>>> origin end up in different processes), and thus subsequent accesses within
>>> that origin may fail.
>>>
>>> My plan right now is to leave this on at 50% beta, but to not proceed to
>>> any stable releases at any percentage. I'll update this thread when I have
>>> a better handle on the bug and can suggest a good way to proceed.
>>>
>>> On Fri, Jan 20, 2023 at 5:12 PM Eiji Kitamura 
>>> wrote:
>>>
>>>> FYI, the enterprise bit has been added to the article.
>>>> https://developer.chrome.com/blog/immutable-document-domain/
>>>>
>>>> On Tue, Jan 17, 2023 at 1:21 AM Brandon Heenan 
>>>> wrote:
>>>>
>>>>> We'll make the update in the enterprise release notes too. Thanks for
>>>>> keeping us in the loop
>>>>>
>>>>> On Mon, Jan 16, 2023 at 9:46 AM Rick Byers 
>>>>> wrote:
>>>>>
>>>>>> Thanks so much Eiji!
>>>>>>
>>>>>> On Mon, Jan 16, 2023 at 3:06 AM Eiji Kitamura 
>>>>>> wrote:
>>>>>>
>>>>>>> I've updated the blog post
>>>>>>> <https://developer.chrome.com/blog/immutable-document-domain/> stating
>>>>>>> Chrome 111 is where we ship the feature, but looks like it's rolling out
>>>>>>> through 111 and 112?
>>>>>>> I'll update the blog post to mention
>>>>>>> `OriginAgentClusterDefaultEnabled` enterprise policy.
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Jan 14, 2023 at 1:37 AM Rick Byers 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Thanks for the update Daniel, good luck!
>>>>>>>>
>>>>>>>> In case others, like me, have missed or forgotten the long history
>>>>>>>> of this difficult deprecation and what it means for web developers, 
>>>>>>>> this blog
>>>>>>>> post is a good summary
>>>>>>>> <https://developer.chrome.com/blog/immutable-document-domain/>.
>>>>>>>> One critical thing it doesn't mention, but probably should, is that 
>>>>>>>> the OriginAgentClusterDefaultEnabled
>>>>>>>> enterprise policy
>>>>>>>> <https://chromeenterprise.google/policies/#OriginAgentClusterDefaultEnabled>
>>>>>>>> can also be used to revert the default on managed devices (though it 
>>>>>>>> looks
>>>>>>>> like the launching milestone needs to be updated there too).
>>>>>>>>
>>>>>>>> Rick
>>>>>>>>
>>>>>>>> On Fri, Jan 13, 2023 at 9:53 AM 'Daniel Vogelheim' via blink-dev <
>>>>>>>> blink-dev@chromium.org> wrote:
>>>>>>>>
>>>>>>>>> Hello all,
>>>>>>>>>
>>>>>>>>> We've now handled the bugs we've discovered, and I would like to
>>>>>>>>> make another attempt at launching. I'll follow the plan that was 
>>

Re: [blink-dev] Intent to Ship: Origin Isolation By Default / Deprecate document.domain on stable

['Eiji Kitamura' via blink-dev]

I've updated the blog
<https://developer.chrome.com/blog/immutable-document-domain/> so that it's
clear that this change is not happening in Chrome 112.
Has the new milestone been determined yet?

On Mon, Apr 3, 2023 at 11:27 PM Marijke Hoste  wrote:

> Thanks for the update indeed!
>
> On the Enterprise-side, we've mentioned this in the past 7 versions of the
> Enterprise Release Notes, so Admins are aware this is coming and have had
> sufficient notification. We don't think that it's necessary to update them
> of the (potential) delays.
>
> On Fri, Mar 31, 2023 at 10:17 AM Mike Taylor 
> wrote:
>
>> Thanks for the update Daniel, and good luck on fixing the bug. :)
>> On 3/31/23 9:54 AM, Daniel Vogelheim wrote:
>>
>> Hello all, I'm afraid I have to delay this a bit more. :(
>>
>> We have a bug report (tracked in crbug.com/1429587) that breaks existing
>> apps. The important thing here is that it does not break document.domain
>> setting and subsequent cross-origin access, but that instead -- if the
>> conditions are just right; or arguably just wrong -- the app can get into a
>> state where same-origin accesses are mistakenly blocked. Apparently an app
>> can get into a state where frames within the same page are inconsistently
>> assigned to agent clusters (i.e., frames in the same origin end up in
>> different processes), and thus subsequent accesses within that origin may
>> fail.
>>
>> My plan right now is to leave this on at 50% beta, but to not proceed to
>> any stable releases at any percentage. I'll update this thread when I have
>> a better handle on the bug and can suggest a good way to proceed.
>>
>> On Fri, Jan 20, 2023 at 5:12 PM Eiji Kitamura  wrote:
>>
>>> FYI, the enterprise bit has been added to the article.
>>> https://developer.chrome.com/blog/immutable-document-domain/
>>>
>>> On Tue, Jan 17, 2023 at 1:21 AM Brandon Heenan 
>>> wrote:
>>>
>>>> We'll make the update in the enterprise release notes too. Thanks for
>>>> keeping us in the loop
>>>>
>>>> On Mon, Jan 16, 2023 at 9:46 AM Rick Byers  wrote:
>>>>
>>>>> Thanks so much Eiji!
>>>>>
>>>>> On Mon, Jan 16, 2023 at 3:06 AM Eiji Kitamura 
>>>>> wrote:
>>>>>
>>>>>> I've updated the blog post
>>>>>> <https://developer.chrome.com/blog/immutable-document-domain/> stating
>>>>>> Chrome 111 is where we ship the feature, but looks like it's rolling out
>>>>>> through 111 and 112?
>>>>>> I'll update the blog post to mention
>>>>>> `OriginAgentClusterDefaultEnabled` enterprise policy.
>>>>>>
>>>>>>
>>>>>> On Sat, Jan 14, 2023 at 1:37 AM Rick Byers 
>>>>>> wrote:
>>>>>>
>>>>>>> Thanks for the update Daniel, good luck!
>>>>>>>
>>>>>>> In case others, like me, have missed or forgotten the long history
>>>>>>> of this difficult deprecation and what it means for web developers, 
>>>>>>> this blog
>>>>>>> post is a good summary
>>>>>>> <https://developer.chrome.com/blog/immutable-document-domain/>. One
>>>>>>> critical thing it doesn't mention, but probably should, is that the 
>>>>>>> OriginAgentClusterDefaultEnabled
>>>>>>> enterprise policy
>>>>>>> <https://chromeenterprise.google/policies/#OriginAgentClusterDefaultEnabled>
>>>>>>> can also be used to revert the default on managed devices (though it 
>>>>>>> looks
>>>>>>> like the launching milestone needs to be updated there too).
>>>>>>>
>>>>>>> Rick
>>>>>>>
>>>>>>> On Fri, Jan 13, 2023 at 9:53 AM 'Daniel Vogelheim' via blink-dev <
>>>>>>> blink-dev@chromium.org> wrote:
>>>>>>>
>>>>>>>> Hello all,
>>>>>>>>
>>>>>>>> We've now handled the bugs we've discovered, and I would like to
>>>>>>>> make another attempt at launching. I'll follow the plan that was 
>>>>>>>> approved
>>>>>>>> here, but two milestones later: Launch to 50% beta in M111 (or late 
>>>>>>>> M110,
>&

Re: [blink-dev] Intent to Ship: Origin Isolation By Default / Deprecate document.domain on stable

['Eiji Kitamura' via blink-dev]

FYI, the enterprise bit has been added to the article.
https://developer.chrome.com/blog/immutable-document-domain/

On Tue, Jan 17, 2023 at 1:21 AM Brandon Heenan  wrote:

> We'll make the update in the enterprise release notes too. Thanks for
> keeping us in the loop
>
> On Mon, Jan 16, 2023 at 9:46 AM Rick Byers  wrote:
>
>> Thanks so much Eiji!
>>
>> On Mon, Jan 16, 2023 at 3:06 AM Eiji Kitamura  wrote:
>>
>>> I've updated the blog post
>>> <https://developer.chrome.com/blog/immutable-document-domain/> stating
>>> Chrome 111 is where we ship the feature, but looks like it's rolling out
>>> through 111 and 112?
>>> I'll update the blog post to mention `OriginAgentClusterDefaultEnabled`
>>> enterprise policy.
>>>
>>>
>>> On Sat, Jan 14, 2023 at 1:37 AM Rick Byers  wrote:
>>>
>>>> Thanks for the update Daniel, good luck!
>>>>
>>>> In case others, like me, have missed or forgotten the long history of
>>>> this difficult deprecation and what it means for web developers, this blog
>>>> post is a good summary
>>>> <https://developer.chrome.com/blog/immutable-document-domain/>. One
>>>> critical thing it doesn't mention, but probably should, is that the 
>>>> OriginAgentClusterDefaultEnabled
>>>> enterprise policy
>>>> <https://chromeenterprise.google/policies/#OriginAgentClusterDefaultEnabled>
>>>> can also be used to revert the default on managed devices (though it looks
>>>> like the launching milestone needs to be updated there too).
>>>>
>>>> Rick
>>>>
>>>> On Fri, Jan 13, 2023 at 9:53 AM 'Daniel Vogelheim' via blink-dev <
>>>> blink-dev@chromium.org> wrote:
>>>>
>>>>> Hello all,
>>>>>
>>>>> We've now handled the bugs we've discovered, and I would like to make
>>>>> another attempt at launching. I'll follow the plan that was approved here,
>>>>> but two milestones later: Launch to 50% beta in M111 (or late M110, if I
>>>>> can still catch a bit of that release cycle), and then ramp on stable once
>>>>> M112 is out.
>>>>>
>>>>>
>>>>> On Wed, Dec 14, 2022 at 6:36 PM Daniel Vogelheim 
>>>>> wrote:
>>>>>
>>>>>> Hello all,
>>>>>>
>>>>>> An update: Unfortunately we have discovered a bug with this feature,
>>>>>> just as I was getting ready to enable it. The bug also affects pages that
>>>>>> have not even set document.domain. Since I have now missed a substantial
>>>>>> portion of the 109 beta cycle I'd like to delay the roll out once more, 
>>>>>> and
>>>>>> shift it by one milestone (or two; depending on when everything is 
>>>>>> fixed).
>>>>>>
>>>>>> On the positive side: Recently the last of the previously identified
>>>>>> big document.domain users, that together accounted for about 50% of
>>>>>> remaining usage, has dropped their usage. So current usage is lower than
>>>>>> previously reported. See the usage dip around late November at
>>>>>> deprecate.it (1st graph).
>>>>>>
>>>>>> On Thu, Nov 10, 2022 at 5:42 PM Mike Taylor 
>>>>>> wrote:
>>>>>>
>>>>>>> LGTM3
>>>>>>>
>>>>>>> On 11/10/22 11:18 AM, Chris Harrelson wrote:
>>>>>>>
>>>>>>> LGTM2
>>>>>>>
>>>>>>> On Thu, Nov 10, 2022, 4:19 AM Yoav Weiss 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> LGTM1 to roll this out to 50% of Beta/Dev/Canary for either M108 or
>>>>>>>> M109, and carefully roll this out for M110, once it hits stable.
>>>>>>>>
>>>>>>>> On Wed, Nov 9, 2022 at 7:05 PM Daniel Vogelheim <
>>>>>>>> vogelh...@google.com> wrote:
>>>>>>>>
>>>>>>>>> On Wed, Nov 9, 2022 at 6:10 PM Mike Taylor 
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> On 10/27/22 11:49 PM, 'Daniel Vogelheim' via blink-dev wrote:
>>>>>>>>>>
>>>>>>>>>> Hello al

Re: [blink-dev] Intent to Ship: Origin Isolation By Default / Deprecate document.domain on stable

['Eiji Kitamura' via blink-dev]

; Thus,
>>>>>>> we have marked this intent as a deprecation.
>>>>>>> Note that this proposal is about the default. Both modes -
>>>>>>> site-keyed or origin-keyed agent clusters - remain available to any 
>>>>>>> site,
>>>>>>> but origin-keyed agent clusters change from opt-in to opt-out. The 
>>>>>>> current
>>>>>>> behaviour remains available by setting "Origin-Agent-Cluster: ?0".
>>>>>>> Blink component Blink>SecurityFeature
>>>>>>> TAG review https://github.com/w3ctag/design-reviews/issues/564
>>>>>>> Risks: Interoperability and Compatibility
>>>>>>>
>>>>>>> There are compatibility risks, which we have reduced with outreach
>>>>>>> and warnings, and we want to mitigate further by launching at 50% of 
>>>>>>> beta
>>>>>>> first. An extended discussion of the risk (including attempts at
>>>>>>> quantitative assessment) can be found in the original intent to ship
>>>>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/_oRc19PjpFo/>
>>>>>>> .
>>>>>>>
>>>>>>> Gecko: Standards position request
>>>>>>> <https://github.com/mozilla/standards-positions/issues/601>.
>>>>>>> ("Worth prototyping")
>>>>>>>
>>>>>>> WebKit:
>>>>>>> https://lists.webkit.org/pipermail/webkit-dev/2021-December/032067.html
>>>>>>> (No signals.)
>>>>>>>
>>>>>>> Web developers: No signals.
>>>>>>>
>>>>>>> Activation - Deprecation plan
>>>>>>> M109: Enable "Origin Agent Cluster by Default" for 50% of page loads
>>>>>>> on beta, dev, and canary.
>>>>>>>
>>>>>>> M110: Enable "Origin Agent Cluster by Default" on stable.
>>>>>>>   Security This change should be security-positive, since setting
>>>>>>> document.domain will not have any impact on the origin of the document 
>>>>>>> any
>>>>>>> more.
>>>>>>> Debuggability A deprecation warning has been added to DevTools
>>>>>>> console and to the issues panel in M98. This warning will file a
>>>>>>> deprecation report as well using the Reporting API, if so configured.
>>>>>>> Will this feature be supported on all six Blink platforms (Windows,
>>>>>>> Mac, Linux, Chrome OS, Android, and Android WebView)? Yes
>>>>>>> Is this feature fully tested by web-platform-tests
>>>>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>
>>>>>>> ? This is covered by Origin-keyed Agent Cluster tests
>>>>>>> <https://wpt.live/html/browsers/origin/origin-keyed-agent-clusters/>
>>>>>>> .
>>>>>>> Tracking bug https://crbug.com/1139851
>>>>>>> Launch bug https://crbug.com/1246823
>>>>>>> Link to entry on the Chrome Platform Status
>>>>>>> https://chromestatus.com/feature/5428079583297536 (document.domain
>>>>>>> setter deprecation)
>>>>>>> https://chromestatus.com/features/5683766104162304 (Origin-keyed
>>>>>>> agent clusters)
>>>>>>> --
>>>>>>> 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/CALG6KPNEMgvrOehp5%2Bf48yQ62pY3xqXqATPNxWZ6aYQ%2BXeHHAg%40mail.gmail.com
>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPNEMgvrOehp5%2Bf48yQ62pY3xqXqATPNxWZ6aYQ%2BXeHHAg%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 blink-dev+unsubscr...@chromium.org.
>>>>> To view this discussion on the web visit
>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfW0vt%2BzXxGf_f7YBF2Lq1K1y5F_VJMtK6whuSiQX9_t3g%40mail.gmail.com
>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfW0vt%2BzXxGf_f7YBF2Lq1K1y5F_VJMtK6whuSiQX9_t3g%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 blink-dev+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPPFMpseckt22K5bd%2BRsctwWihiwCdSA9vvCTZw_tOtT5A%40mail.gmail.com
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPPFMpseckt22K5bd%2BRsctwWihiwCdSA9vvCTZw_tOtT5A%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
Eiji Kitamura / えーじ | Developer Advocate | @agektmr
<https://twitter.com/agektmr> | Office Location: Tokyo Shibuya

-- 
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/CAOW%3Dx-CvRNWCvcEkpyFDzfQaaSNokVK9DKoFRxe5XyKft1na_w%40mail.gmail.com.

Re: [blink-dev] Intent to Deprecate: The "basic-card" method of PaymentRequest API

[Eiji Kitamura]

;>>> completely broken' from
>>>>>>>>>>>>>>>>>> that perspective (assuming buying a thing is the main user 
>>>>>>>>>>>>>>>>>> journey).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> However, such a site would also be broken on Firefox and
>>>>>>>>>>>>>>>>>> Safari today (unless serving user-agent specific code), and 
>>>>>>>>>>>>>>>>>> sites also tend
>>>>>>>>>>>>>>>>>> to not rely on just one approach to get paid. Sites will 
>>>>>>>>>>>>>>>>>> almost definitely
>>>>>>>>>>>>>>>>>> have a fallback mechanism, and it will likely be invisible 
>>>>>>>>>>>>>>>>>> to the user. For
>>>>>>>>>>>>>>>>>> example:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 1. Site checks `if (window.PaymentRequest)` - passes in
>>>>>>>>>>>>>>>>>> Chrome and Safari, fails in Firefox.
>>>>>>>>>>>>>>>>>> 2. Site calls `new
>>>>>>>>>>>>>>>>>> PaymentRequest([basic-card-data]).canMakePayment()` (or 
>>>>>>>>>>>>>>>>>> `show()` directly)
>>>>>>>>>>>>>>>>>> - passes in Chrome today, fails/throws in Safari.
>>>>>>>>>>>>>>>>>> 3. If either of #1 or #2 failed, render a fallback
>>>>>>>>>>>>>>>>>> payment information collection flow such as a HTML form.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> TL;DR - we expect very few to no sites to break due to
>>>>>>>>>>>>>>>>>> this removal, unless they're doing user-agent specific 
>>>>>>>>>>>>>>>>>> branching with no
>>>>>>>>>>>>>>>>>> fallback mechanisms for 'what if basic-card fails'.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Thu, 9 Sept 2021 at 08:03, Yoav Weiss <
>>>>>>>>>>>>>>>>>> yoav...@chromium.org> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Can you clarify what breakage may look like for sites
>>>>>>>>>>>>>>>>>>> that may rely on it?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Tuesday, September 7, 2021 at 2:34:46 PM UTC+2
>>>>>>>>>>>>>>>>>>> Stephen McGruer wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> > Any usecounter stats you can share?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Unfortunately no usecounters for two reasons:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 1) Payment APIs in general have very low usage when
>>>>>>>>>>>>>>>>>>>> compared to 'page loads', because the most popular sites 
>>>>>>>>>>>>>>>>>>>> on the web aren't
>>>>>>>>>>>>>>>>>>>> merchants and so don't use them. For example, 
>>>>>>>>>>>>>>>>>>>> PaymentRequest.show
>>>>>>>>>>>>>>>>>>>> is at 0.001
>>>>>>>>>>>>>>>>>>>> <https://chromestatus.com/metrics/feature/timeline/popularity/2895>.
>>>>>>>>>>>>>>>>>>>> They're still very important, so we have to measure usage 
>>>>>>>>>>>>>>>>>>>> other ways :)
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 2) In particular for basic-card, it's actually just a
>>>>>>>>>>>>>>>>>>>> method-type of PaymentRequest, so our top-level 
>>>>>>>>>>>>>>>>>>>> usecounters don't show it.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> We have internal stats that I can't share publicly due
>>>>>>>>>>>>>>>>>>>> to sensitivity (Googlers, feel free to ping me for a 
>>>>>>>>>>>>>>>>>>>> link), but I can share
>>>>>>>>>>>>>>>>>>>> that of transactions using PaymentRequest, basic-card is 
>>>>>>>>>>>>>>>>>>>> ~2% of all
>>>>>>>>>>>>>>>>>>>> transactions and <1% of completed transactions. So it's a 
>>>>>>>>>>>>>>>>>>>> very niche
>>>>>>>>>>>>>>>>>>>> feature that also performs poorly.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Max has also done an analysis of the top 10 sites from
>>>>>>>>>>>>>>>>>>>> UKM data that use basic-card. For 4, he couldn't get to 
>>>>>>>>>>>>>>>>>>>> the payments page
>>>>>>>>>>>>>>>>>>>> or couldn't get it to trigger basic-card at all (possibly 
>>>>>>>>>>>>>>>>>>>> geographically
>>>>>>>>>>>>>>>>>>>> gated), but for the remaining 6 he confirmed that all 6 
>>>>>>>>>>>>>>>>>>>> function properly
>>>>>>>>>>>>>>>>>>>> in a version of Chrome that has basic-card disabled 
>>>>>>>>>>>>>>>>>>>> (falling back to the
>>>>>>>>>>>>>>>>>>>> same behavior they use for Firefox + Safari).
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Mon, 6 Sept 2021 at 03:26, Yoav Weiss <
>>>>>>>>>>>>>>>>>>>> yoav...@chromium.org> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On Fri, Sep 3, 2021 at 4:25 PM Liquan (Max) Gu <
>>>>>>>>>>>>>>>>>>>>> ma...@chromium.org> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Contact emails ma...@chromium.org,
>>>>>>>>>>>>>>>>>>>>>> paymen...@chromium.org
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Specification
>>>>>>>>>>>>>>>>>>>>>> https://www.w3.org/TR/payment-method-basic-card/
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Summary
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Deprecate the "basic-card" payment method from
>>>>>>>>>>>>>>>>>>>>>> PaymentRequest API.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Blink component Blink>Payments
>>>>>>>>>>>>>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPayments>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Motivation
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> * Its usage is low and declining, underperforms other
>>>>>>>>>>>>>>>>>>>>>> payment methods in time-to-checkout and completion rate 
>>>>>>>>>>>>>>>>>>>>>> and does not have
>>>>>>>>>>>>>>>>>>>>>> improvement potential.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Any usecounter stats you can share?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> * W3C's interest in it has waned. 6 participants
>>>>>>>>>>>>>>>>>>>>>> supported the deprecation and no objection[1], and W3C 
>>>>>>>>>>>>>>>>>>>>>> has deprecated the
>>>>>>>>>>>>>>>>>>>>>> spec[2]. [1]
>>>>>>>>>>>>>>>>>>>>>> https://lists.w3.org/Archives/Public/public-payments-wg/2021Aug/0038.html
>>>>>>>>>>>>>>>>>>>>>> [2]
>>>>>>>>>>>>>>>>>>>>>> https://github.com/w3c/payment-method-basic-card/pull/90/files
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Interoperability and Compatibility
>>>>>>>>>>>>>>>>>>>>>> * Chrome is the only implementer of basic-card, so
>>>>>>>>>>>>>>>>>>>>>> the basic-card removal from Chrome will increase 
>>>>>>>>>>>>>>>>>>>>>> interoperability.
>>>>>>>>>>>>>>>>>>>>>> * Since no other browser implements basic-card, web
>>>>>>>>>>>>>>>>>>>>>> developers already need workarounds to support other 
>>>>>>>>>>>>>>>>>>>>>> browsers.
>>>>>>>>>>>>>>>>>>>>>> * Whether basic-card is supported can be detected via
>>>>>>>>>>>>>>>>>>>>>> canMakePayment
>>>>>>>>>>>>>>>>>>>>>> <https://w3c.github.io/payment-request/#canmakepayment-method>.
>>>>>>>>>>>>>>>>>>>>>> Web developers normally use this to decide whether to 
>>>>>>>>>>>>>>>>>>>>>> fallback to
>>>>>>>>>>>>>>>>>>>>>> other methods.
>>>>>>>>>>>>>>>>>>>>>> * We have checked the few top sites via UKM - they
>>>>>>>>>>>>>>>>>>>>>> all appear to work with basic-card disabled because they 
>>>>>>>>>>>>>>>>>>>>>> fallback to other
>>>>>>>>>>>>>>>>>>>>>> methods to get payment info.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Tracking bug https://crbug.com/1209835
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Estimated milestones M96
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Link to entry on the Chrome Platform Status
>>>>>>>>>>>>>>>>>>>>>> https://chromestatus.com/feature/573005107056
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 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+...@chromium.org.
>>>>>>>>>>>>>>>>>>>>>> To view this discussion on the web visit
>>>>>>>>>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEWPi2sswphwqEnCGgwwNOr_F5j8V%3Dc5ZQ7Kz6h2gK%2Bki2A6aw%40mail.gmail.com
>>>>>>>>>>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEWPi2sswphwqEnCGgwwNOr_F5j8V%3Dc5ZQ7Kz6h2gK%2Bki2A6aw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>>>>>>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> You received this message because you are subscribed to
>>>>>>>>>>>>>>>>>>>>> the Google Groups "payments-dev" group.
>>>>>>>>>>>>>>>>>>>>> To unsubscribe from this group and stop receiving
>>>>>>>>>>>>>>>>>>>>> emails from it, send an email to
>>>>>>>>>>>>>>>>>>>>> payments-dev...@chromium.org.
>>>>>>>>>>>>>>>>>>>>> To view this discussion on the web visit
>>>>>>>>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/payments-dev/CAL5BFfUaHsXJEEwN3JO2MSGw9WHsVt5nszPPscKh9mBrRt5U1g%40mail.gmail.com
>>>>>>>>>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/payments-dev/CAL5BFfUaHsXJEEwN3JO2MSGw9WHsVt5nszPPscKh9mBrRt5U1g%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 blink-dev+...@chromium.org.
>>>>>>>>>>>>>>>>>> To view this discussion on the web visit
>>>>>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3MafMcTV1GOHS62bHd%2BK%2BH1ftH0pBZL_1k77GWJqK8o9Uvg%40mail.gmail.com
>>>>>>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3MafMcTV1GOHS62bHd%2BK%2BH1ftH0pBZL_1k77GWJqK8o9Uvg%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 blink-dev+...@chromium.org.
>>>>>>>>>>>>>>>>>> To view this discussion on the web visit
>>>>>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/25df3c17-3cf3-695a-451f-ef1007581d53%40gmail.com
>>>>>>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/25df3c17-3cf3-695a-451f-ef1007581d53%40gmail.com?utm_medium=email&utm_source=footer>
>>>>>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> You received this message because you are subscribed to
>>>>>>>>>>>>>>>>> the Google Groups "payments-dev" group.
>>>>>>>>>>>>>>>>> To unsubscribe from this group and stop receiving emails
>>>>>>>>>>>>>>>>> from it, send an email to payments-dev...@chromium.org.
>>>>>>>>>>>>>>>>> To view this discussion on the web visit
>>>>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/payments-dev/CAKXHy%3De-AdXxo8CtZrSk-iPN05KmJ0_FWHOw5duyBXFGR58oGA%40mail.gmail.com
>>>>>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/payments-dev/CAKXHy%3De-AdXxo8CtZrSk-iPN05KmJ0_FWHOw5duyBXFGR58oGA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>

-- 
Eiji Kitamura : agek...@google.com
Google - Developer Advocate

-- 
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/CAOW%3Dx-AV9cWYQtQy_bfDZkLXgq6aWnO31H1mm5EAC%2Ba3skZE_g%40mail.gmail.com.

[blink-dev] Re: Intent to Ship: COEP for shared worker

[Eiji Kitamura]

It's positive. For example, emscripten uses SharedArrayBuffer to use
pthread by enabling cross-origin isolation by sending COEP and COOP. I
consider this is a signal that developers accept this restriction.
https://emscripten.org/docs/porting/pthreads.html



2021年9月9日(木) 20:30 Yoav Weiss :

>
>
> On Tuesday, September 7, 2021 at 3:00:48 PM UTC+2 Yifan Luo wrote:
>
>> Contact emails
>> l...@chromium.org, arthursonzo...@chromium.org
>>
>> Explainer
>> https://docs.google.com/document/d/1mpIKhBhsx4deZXu3C2bnie5LSbzumjD1m6uhJx-hPQA/edit?usp=sharing
>>
>> Specificationhttps://wicg.github.io/cross-origin-embedder-policy/
>>
>> Summary
>>
>> Enforce Cross-Origin-Embedder-Policy in SharedWorker.
>> Cross-Origin-Embedder-Policy HTTP header prevents documents and workers
>> from loading cross-origin resources without an explicit opt-in, either with
>> CORS or CORP. This was previously shipped for: Document, DedicatedWorker,
>> and ServiceWorker. Now we want to bring support for SharedWorker.
>>
>>
>> Blink componentBlink>SecurityFeature>COEP
>> 
>>
>> Search tagscoep ,
>> sharedworker , coop
>> 
>>
>> TAG reviewThe previous COEP launch did not have a TAG review. This
>> intent just implements what was postponed in the previous intent. However
>> this was discussed more broadly with COOP/COEP and crossOriginIsolation
>> here: https://github.com/w3ctag/design-reviews/issues/471
>>
>
> I agree that discussion seems sufficient to cover the same mechanisms in
> Shared Workers.
>
>
>>
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> This implements an existing part of the HTML specification. It was
>> written by Mozilla and Chrome. Mozilla is also working on supporting it for
>> SharedWorker. Webkit is implementing COEP and will support workers.
>> However, SharedWorker isn't supported by webkit.
>>
>>
>> Gecko: In development (
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1613912) Mozilla and Chrome
>> wrote the specification a year ago. Mozilla is implementing it above too.
>>
>
> I'm cautious about using that as evidence for a positive position. Can you
> ask for signals? https://bit.ly/blink-signals
>
>
>> WebKit: N/A Webkit is implementing COEP and will support workers:
>> https://github.com/WebKit/WebKit/commit/e6c7e17d32fa0dd802337c7f0d2c63b0703b782a
>>  However
>> SharedWorker do not exist in Webkit.
>>
>> Web developers: No signals
>>
>
> Do we have signals about COEP in general that could be applied here?
> Adding Eiji who may have something
>
>
>>
>> Ergonomics
>>
>> This will often be used together with documents using COOP+COEP. This
>> isn't implemented, but supporting COEP allows Chrome to put the
>> SharedWorker in the COOP+COEP process. This can potentially improve
>> performance.
>>
>>
>> Activation
>>
>> This doesn't affect existing websites, since it requires using the COEP
>> header. It can be hard for some developers to add an HTTP header when they
>> don't own their server. For instance with https://github.io It is not
>> polyfillable. Site owners can use the "report-only" feature to test what
>> would break before actually enabling this feature.
>>
>>
>> Security
>>
>> When a COEP header is used, it restricts the set of resources the
>> SharedWorker can fetch. In detail, it requires the resources an explicit
>> opt-in: CORS or CORP to be embedded cross-origin. In the future, this will
>> gate the crossOriginIsolated capability, but this isn't implemented here.
>> Since this mostly new restrictions, without new extra capabilities. The
>> security risk should be low.
>>
>>
>> Debuggability
>>
>> Contrary to Document where devtool reflects the current COEP state in the
>> application > frame panel, there isn't such a thing for workers. We should
>> think about it in the future. Otherwise existing COEP/Devtools mechanisms
>> are still available. Resources blocked by COEP display a Devtools issue in
>> the console and in the network panel.
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?Yes
>>
>> Flag nameCOEPForSharedWorker
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://crbug.com/1245550
>>
>> Launch bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1247200
>>
>> Estimated milestones
>> DevTrial on desktop 94
>> DevTrial on iOS 94
>> DevTrial on Webview 94
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5698074912489472
>>
>> This intent message was generated by Chrome Platform Status
>> .
>>
>> --
>> Yifan
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To uns