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

[Yoav Weiss]

On Wed, Sep 29, 2021 at 7:50 AM Eiji Kitamura  wrote:

> I'll be working on it.
>

That's great! Thanks Eiji! :)


>
> On Wed, Sep 29, 2021 at 2:48 PM Yoav Weiss  wrote:
>
>> Thanks for fixing up the documentation.
>>
>> LGTM1 to run a 4 milestone deprecation and then remove. I wonder if it'd
>> also make sense to write a dedicated announcement blog post, to inform
>> folks that don't follow blink-dev of these changes.
>>
>> On Tue, Sep 28, 2021 at 7:29 PM Liquan (Max) Gu  wrote:
>>
>>> Yoav, MDN (PR
>>> ) and
>>> web.dev (PR ) have
>>> taken down the basic-card content.
>>>
>>> Is it enough to get our approval for deprecating basic-card?
>>>
>>> On Thu, Sep 23, 2021 at 9:12 PM Patrick Guerrero 
>>> wrote:
>>>

 https://www.google.com/adsense/new/u/0/pub-4013500751301578/payments/?place=USER_MANAGEMENT

 On Wednesday, September 22, 2021 at 11:59:57 AM UTC-6 Liquan (Max) Gu
 wrote:

> Yep! We are working  with @Joe
> Medley on updating the MDN documentation.
>
> On Tue, Sep 21, 2021 at 2:32 AM Yoav Weiss 
> wrote:
>
>>
>>
>> On Mon, Sep 20, 2021 at 9:16 PM Liquan (Max) Gu 
>> wrote:
>>
>>> Rouslan has sent a bunch of emails to the owners of the
>>> documentation:
>>>
>>>- Samsung:
>>>   - Samsung is removing their doc referencing “basic-card”.
>>>   They will keep us posted.
>>>- web.dev:
>>>   - Eiji is updating web.dev with a PR
>>>    (preview
>>>   
>>> 
>>>   ).
>>>- whatwebcando 
>>>   - Rouslan has requested Adam to remove it. No response yet.
>>>- MDN
>>>
>>> 
>>>:
>>>   - Rouslan filed https://github.com/mdn/content/issues/8828 where
>>>   the owner is looking for someone with bandwidth to update
>>>
>>>
>> Would the team be able to write an initial draft and work with the
>> relevant tech writers? Fixing up MDN seems critical for this deprecation 
>> to
>> be successful.
>>
>>
>>>
>>>- Adyen
>>>
>>> 
>>>:
>>>   - They are reaching out to the owner to update the article,
>>>   or will connect Rouslan Solomakhin with the article author. 
>>> (meeting
>>>   note
>>>   
>>> 
>>>   ).
>>>
>>>
>>>
>>> On Mon, Sep 20, 2021 at 3:06 PM Yoav Weiss 
>>> wrote:
>>>
 Thanks! Any word on PRs to MDN and other existing documentation?

 On Mon, Sep 20, 2021 at 8:48 PM Liquan (Max) Gu 
 wrote:

> Hi folks,
>
> Thanks for your patience. We ended up adding the timeline and
> alternatives to
> https://www.chromestatus.com/feature/573005107056. Eiji is in
> the process of writing a blog post that will be published at
> https://web.dev/payment-request-basic-card-deprecation which is
> about the deprecation. I will add the web.dev article to Chrome
> status once the article is ready. On the console warning front, I am 
> in the
> process of adding basic-card deprecation to the Reporting API
> ,
> which will print a warning that links to the chrome status as below.
>
> [image: Screen Shot 2021-09-20 at 14.02.52.png]
>
> Does the whole thing look good to you? Please let us know. Thanks!
>
> On Fri, Sep 17, 2021 at 7:06 AM Mike West 
> wrote:
>
>> Technically, yes. Deprecation warnings should only land when
>> we're _actually_ going to deprecate a thing, and have a reasonable 
>> schedule
>> to point to.
>>
>> Here, though, I think we have agreement that the deprecation
>> itself is reasonable, and agreement on a schedule. We're only 
>> blocking on
>> documentation of alternatives and developer awareness, both of which
>> deprecation warnings support. So, I'd LGTM CLs that added warnings 
>> if you
>> wanted to send them my way.
>>
>> -mike
>>
>>
>> On Thu, Sep 16, 2021 at 9:17 PM Rouslan Solomakhin <
>> rou...@chromium.org> wrote:
>>
>>> HI Mike,
>>>
>>> We've been working on 

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

[Eiji Kitamura]

I'll be working on it.

On Wed, Sep 29, 2021 at 2:48 PM Yoav Weiss  wrote:

> Thanks for fixing up the documentation.
>
> LGTM1 to run a 4 milestone deprecation and then remove. I wonder if it'd
> also make sense to write a dedicated announcement blog post, to inform
> folks that don't follow blink-dev of these changes.
>
> On Tue, Sep 28, 2021 at 7:29 PM Liquan (Max) Gu  wrote:
>
>> Yoav, MDN (PR
>> ) and
>> web.dev (PR ) have
>> taken down the basic-card content.
>>
>> Is it enough to get our approval for deprecating basic-card?
>>
>> On Thu, Sep 23, 2021 at 9:12 PM Patrick Guerrero 
>> wrote:
>>
>>>
>>> https://www.google.com/adsense/new/u/0/pub-4013500751301578/payments/?place=USER_MANAGEMENT
>>>
>>> On Wednesday, September 22, 2021 at 11:59:57 AM UTC-6 Liquan (Max) Gu
>>> wrote:
>>>
 Yep! We are working  with @Joe
 Medley on updating the MDN documentation.

 On Tue, Sep 21, 2021 at 2:32 AM Yoav Weiss 
 wrote:

>
>
> On Mon, Sep 20, 2021 at 9:16 PM Liquan (Max) Gu 
> wrote:
>
>> Rouslan has sent a bunch of emails to the owners of the documentation:
>>
>>- Samsung:
>>   - Samsung is removing their doc referencing “basic-card”. They
>>   will keep us posted.
>>- web.dev:
>>   - Eiji is updating web.dev with a PR
>>    (preview
>>   
>> 
>>   ).
>>- whatwebcando 
>>   - Rouslan has requested Adam to remove it. No response yet.
>>- MDN
>>
>>:
>>   - Rouslan filed https://github.com/mdn/content/issues/8828 where
>>   the owner is looking for someone with bandwidth to update
>>
>>
> Would the team be able to write an initial draft and work with the
> relevant tech writers? Fixing up MDN seems critical for this deprecation 
> to
> be successful.
>
>
>>
>>- Adyen
>>
>> 
>>:
>>   - They are reaching out to the owner to update the article, or
>>   will connect Rouslan Solomakhin with the article author. (meeting
>>   note
>>   
>> 
>>   ).
>>
>>
>>
>> On Mon, Sep 20, 2021 at 3:06 PM Yoav Weiss 
>> wrote:
>>
>>> Thanks! Any word on PRs to MDN and other existing documentation?
>>>
>>> On Mon, Sep 20, 2021 at 8:48 PM Liquan (Max) Gu 
>>> wrote:
>>>
 Hi folks,

 Thanks for your patience. We ended up adding the timeline and
 alternatives to
 https://www.chromestatus.com/feature/573005107056. Eiji is in
 the process of writing a blog post that will be published at
 https://web.dev/payment-request-basic-card-deprecation which is
 about the deprecation. I will add the web.dev article to Chrome
 status once the article is ready. On the console warning front, I am 
 in the
 process of adding basic-card deprecation to the Reporting API
 ,
 which will print a warning that links to the chrome status as below.

 [image: Screen Shot 2021-09-20 at 14.02.52.png]

 Does the whole thing look good to you? Please let us know. Thanks!

 On Fri, Sep 17, 2021 at 7:06 AM Mike West 
 wrote:

> Technically, yes. Deprecation warnings should only land when we're
> _actually_ going to deprecate a thing, and have a reasonable schedule 
> to
> point to.
>
> Here, though, I think we have agreement that the deprecation
> itself is reasonable, and agreement on a schedule. We're only 
> blocking on
> documentation of alternatives and developer awareness, both of which
> deprecation warnings support. So, I'd LGTM CLs that added warnings if 
> you
> wanted to send them my way.
>
> -mike
>
>
> On Thu, Sep 16, 2021 at 9:17 PM Rouslan Solomakhin <
> rou...@chromium.org> wrote:
>
>> HI Mike,
>>
>> We've been working on updating our docs and reaching out to
>> external documentation owners as well. We will respond back to this 
>> email
>> thread once we have significant progress to report :-D
>>
>> By the way, do we need to 

[blink-dev] Intent to Implement and Ship: Add support for Promise to Blobs in clipboard item

['Anupam Snigdha' via blink-dev]

Contact emails
sni...@microsoft.com, 
m...@chromium.org


Explainer
https://www.w3.org/TR/clipboard-apis/#typedefdef-clipboarditemdata


Specification
https://www.w3.org/TR/clipboard-apis/#typedefdef-clipboarditemdata


Summary

Add promise support to `ClipboardItem` object. This helps the web author to 
call async clipboard write method without having to provide the Blob data 
synchronously. Authors can choose to resolve the promise later when the Blob 
data is available.


Blink component
Blink>DataTransfer

TAG review
N/A. The spec is in Working Draft state and has already been shipped by Apple.

TAG review status
Not applicable

Risks
None. Currently the API takes in a Blob type and the promise to a Blob would 
resolve implicitly which wouldn't require any changes nor would it break any 
existing sites.

Interoperability and Compatibility

Gecko: In Development(https://bugzilla.mozilla.org/show_bug.cgi?id=1619947)

WebKit: Shipped

Web developers: Positive 
(https://bugs.chromium.org/p/chromium/issues/detail?id=1014310). This is also a 
highly requested feature by MS Office products.

Debuggability

The async clipboard APIs have basic tooling support as described in 
this
 doc.

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

Flag name
None.

Requires code in //chrome?
False

Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1014310

Estimated milestones

96


Link to entry on the Chrome Platform Status
https://www.chromestatus.com/feature/5733949474078720

This intent message was generated by Chrome Platform 
Status.

-- 
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/SN6PR00MB0397C14B0F073635A96B475ACFA99%40SN6PR00MB0397.namprd00.prod.outlook.com.

Re: [blink-dev] Intent to Ship: WebTransport

[Emily Stark]

I want to note that there are some pretty big open questions in
https://github.com/w3c/webtransport/issues/349. I think we might want to
have more restrictions on the allowed types of certificates than the spec
currently outlines, and introducing those restrictions after shipping the
feature would carry compatibility risks.

On Sun, Sep 26, 2021 at 9:55 PM Yutaka Hirano  wrote:

> Contact emails
>
> yhir...@chromium.org, vasi...@chromium.org
>
> Explainer
>
> https://github.com/w3c/webtransport/blob/main/explainer.md
>
> Specification
>
> https://w3c.github.io/webtransport
>
> https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3/
>
> https://datatracker.ietf.org/doc/html/draft-ietf-quic-datagram/
>
> Design docs
>
> https://web.dev/webtransport/
>
>
> https://docs.google.com/document/d/1UgviRBnZkMUq4OKcsAJvIQFX6UCXeCbOtX_wMgwD_es/edit
>
> Summary
>
> WebTransport is an interface representing a set of reliable/unreliable
> streams to a server. The interface potentially supports multiple protocols,
> but based on discussions on the IETF webtrans working group, we are
> developing WebTransport over HTTP/3 which uses HTTP3 as the underlying
> protocol.
>
> This time, we want to ship the core part. The following features are
> excluded:
>
>-
>
>Connection sharing
>-
>
>Stream Prioritization
>-
>
>Statistics
>-
>
>WebTransport over HTTP/2
>
>
> Blink component
>
> Blink>Network>WebTransport
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/669
>
> TAG review status
>
> Pending
>
> Risks
>
> Interoperability and Compatibility
>
> This is a new API and doesn’t change any existing behaviors.
>
> Gecko: Worth Prototyping
> . They are
> actively involved in the specification effort.
>
> WebKit: No signal
> 
> .
>
> Web developers: Positive
>
> Twitch
>
> https://twitch.tv
>
>
>
> Twitch is using WebTransport to serve live video to our users with lower
> latency and higher quality. We plan on rolling out our new playback
> experience once it's fully available given our positive results.
>
>
>
> WebTransport offers all of the benefits of QUIC, but in a browser
> environment and without the constraints of HTTP semantics. Most notably we
> can push data over multiple streams, eliminating head-of-line blocking and
> enabling new functionality during congestion. This is not possible with
> existing browser standards such as WebSockets and WebRTC data channels.
>
> Google Stadia
>
> https://stadia.google.com/
>
> “Google Stadia is using the WebTransport API in conjunction with the
> WebCodecs API for several use cases, both internally and with partners. The
> underlying WebTransport protocol, QUIC, has far greater throughput and
> resiliency characteristics than other mechanisms available, which enables
> use cases like webcams, and transmission of results of browser-based
> processing to applications and games in the cloud. The capability to
> transmit datagrams to cloud endpoints enables many new use cases for Stadia
> including communication with custom hardware endpoints. In the future we
> hope to explore using this API for other use cases.”
>
> Ergonomics
>
> The API is built around ReadableStream/WritableStream interfaces, which
> means that its core I/O principles would be familiar to the developers who
> had already used Streams via Fetch and other APIs.
>
> The API does not use cookies, HTTP authentication or socket pooling.  This
> would help us avoid unexpected interactions with the other elements of the
> network stack.
>
> Activation
>
> Since UDP is often blocked on the network, the developers have to assume
> that the API often would not work even in the situations when it is
> implemented in the browser.
>
> Security
>
> See  for more
> info.
>
>
>
> We allow web developers to use an alternative certification verification
> method than the usual HTTPS way. We allow a web developer to connect to a
> WebTransport over HTTP/3 server when its certificate’s fingerprint matches
> with the developer provided fingerprint. This is discussed at
> https://github.com/w3c/webtransport/issues/349 and we will update the
> spec shortly.
>
> Debuggability
>
> Printing an error message with the reason when the opening handshake fails.
>
> We show outgoing WebTransport sessions in the “Network” section of
> DevTools, the same place where WebSocket connections are shown.  Unlike
> WebSockets, we do not intend to show the actual contents of the
> WebTransport sessions, thus avoiding the performance decrease that would
> cause.
>
> Just like with regular HTTP/3-based QUIC traffic, detailed information
> about the connection can be obtained via chrome://net-export interface.
>
> Is this feature fully tested by web-platform-tests?
>
> Yes
>
> We are writing WPTs (/webtransport
> 

[blink-dev] Re: [EXTERNAL] Re: Native support of Windows SSO in Chrome

[Owen Min]

+Yulian Pastarmov 

On Sun, Sep 26, 2021 at 11:34 AM Ryan Sleevi  wrote:

> Thanks for the super-detailed response Aleksander! To reflect what Matt
> said, don't feel the need to respond on vacation :)
>
> Regarding the forks: I suspect this might be how GMail vs Outlook differ
> in managing threads, since in Google Groups and GMails, it appears as all
> one conversation
> ,
> not as forks. You shouldn't have to worry too much about it :)
>
> This was a super-helpful response, and I think it teases out a few things
> worth digging into further.
>
> From your remark about WAM, it seems like this is a generic extensibility
> framework , for any
> IDP - from Microsoft, Google, Okta, etc - to be able to hook the not only
> the browser's network stack (effectively), but any consenting applications'
> network stacks, and be able to inject arbitrary cookie names and values
> .
> It appears these providers may be device-wide (although only Microsoft
> IdPs
> 
> are supported for that), but are primarily user-wide. If I'm understanding
> correctly, any IdP application can register to be the handler
> 
> for a given IdP URL.
>
> It seems, from my limited understanding, to be a bit like an OS extension,
> rather than a browser extension - and to allow third-party software to
> affect the authentication flow, not only within a browser, but within all
> apps (that opt-in to supporting this). Although Windows already had an
> extensible API for adding authentication providers - SSPI and the Negotiate
> method - it has the downsides I mentioned in my previous e-mail, of being
> incompatible with modern transport technologies, as well as being a hugely
> complex thing to implement client and server (CredMan
> 
> is easier than GINA
> ,
> but not by much, and SSP/APs
> 
> aren't fun to write, and it seems like this is the next evolution in this
> space, ignoring ADAL/MSAL
> 
> :D). I'm just trying to make sure I understand the space of where this
> fits, on the Windows side of things, since that helps inform a bit how
> we've evaluated security/privacy risks in the past.
>
> Architecturally, as it relates to Chrome/Chromium, this seems a little
> like offering an OS-provided pluggable OAuth2 Access Token Manager
> ,
> except further, not bounded to having to use OAuth2. Conceptually, a
> browser wide notion of the current user's identity, which can be provided
> to websites as needed. Unlike the current implementation, rather than
> triggered by signing in to the browser, it's provided by the OS's
> extensibility framework and signing into the OS itself. Is that at least
> conceptually right? That is, if you sign in to Chrome today, and then a web
> resource wants to go through Google's IdP, Chrome is able to make the
> user's logged in state available to the IdP, creating a frictionless flow
> between the browser content and the Web content, similar (though not
> identical) to the Desktop Identity Consistency effort - where signing in to
> the IdP in the Web allows you to sign in to Chrome (the app).
>
> Assuming I haven't bungled things too much yet, a specific question is
> whether WAM is what serves as the backing implementation for
> IProofOfPossessionCookieInfoManager::GetCookieInfoForUri
> .
> The WAM remarks are all .NET managed code, and it sounds like this COM
> interface provides a handy abstraction around that logic. For example, for
> a given URI, it would see if it matches one of the web account provider's
> managedUrls, and if so, call RetrieveCookies on the web account provider,
> and then make those available via cookieInfoCount/cookieInfo. If no
> provider was registered, I imagine it'd just return no cookies. I have no
> idea if this is remotely correct, and if I've completely bungled it, I was
> hoping you could explain the relationship between 

[blink-dev] Re: Intent to Ship: HTTP->HTTPS redirect for HTTPS DNS records

[Eric Orth]

On Tue, Sep 28, 2021 at 1:13 PM Eric Orth  wrote:

>
>
> On Tue, Sep 28, 2021 at 6:09 AM Mike West  wrote:
>
>> Hey Eric!
>>
>> On Thu, Sep 23, 2021 at 10:36 PM Eric Orth  wrote:
>>
>>> Contact emails
>>>
>>> erico...@chromium.org
>>>
>>> Explainer
>>>
>>> None
>>>
>>> Specification
>>>
>>> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-07
>>>
>>> Summary
>>>
>>> Query DNS for HTTPS records (alongside traditional A and  queries).
>>> When a website has deployed an HTTPS DNS record and Chrome receives it,
>>> Chrome will always connect to the website via HTTPS.
>>>
>>> Design doc for all Chrome DNS HTTPS plans:
>>> https://docs.google.com/document/d/1k461sRbddjDGj7Q8f-ZKHZvmB-ENUWSdX_3Fpp2dmXQ
>>>
>>> This feature covers just the basic query and HTTP->HTTPS upgrade part of
>>> those plans, and only for simpler cases that do not require followup DNS
>>> queries by the Chrome DNS stack.
>>>
>>>
>>> Blink component
>>>
>>> Internals>Network>DNS
>>> 
>>>
>>> TAG review
>>>
>>> Not applicable. No direct changes to web platform APIs. Change is to
>>> underlying DNS infrastructure, following an IETF spec, with only indirect
>>> web-facing side effects.
>>>
>>
>> This seems like an overly narrow take on the feature: it seems like this
>> needs to be wired up to Fetch in order to explain how the DNS assertion
>> turns into a decision about how to connect to sites (similar to HSTS's
>> integration
>> ),
>> and that upgrade will have web-visible impacts.
>>
>
> Seems accurate to me.  All the signals and triggering happen in DNS,
> outside web platform APIs, with no direct web-platform-API interaction,
> e.g. a header like was done for HSTS.  Then the result is a redirect, which
> yes, is web-visible, hence the "indirect web-facing side effects".
>
> But I think you are right that this should get at least a mention in the
> Fetch spec, and I think the ideal situation would be a single additional
> sentence in that point about HSTS upgrade ("[...] or a DNS lookup for the
> request's current URL per [link to section 8.5 of SVCB RFC] returns an
> HTTPS DNS record." or something like that).  Does that sound reasonable to
> you, or do you think this will take more comprehensive updates to Fetch?
>
>
>> Can I assume that you'll be following the same algorithm (e.g. shifting
>> from 80 to 443 by switching the protocol, but not altering non-standard
>> ports)?
>>
>
> Correct.  Non-standard ports result in a redirect to https with the same
> non-standard port.  Also noteworthy that non-standard ports would require
> the HTTPS DNS record to be specific to that non-standard port, e.g. if the
> request URL were "http://example.com:1234;, the redirect will only happen
> if there is an HTTPS record for DNS queries for "_1234._https.example.com",
> not merely at "example.com" as would be sufficient if the request URL
> were "http://example.com[:80];.
>
>
>>
>> TAG review status
>>>
>>> Not applicable
>>>
>>> Risks
>>>
>>> Interoperability and Compatibility
>>>
>>> Not directly part of the web API surface; only has indirect behavior
>>> implications on the web platform in the form of the HTTP->HTTPS redirect
>>> triggered by DNS signals.
>>>
>>> HTTPS DNS records are a feature of DNS.  The spec is a draft of the IETF
>>> DNSOP working group, and while not yet a published RFC, it is widely
>>> considered stable and ready for implementation.  IANA has designated HTTPS
>>> as DNS resource record type 65.
>>>
>>>
>>> Gecko: No signal
>>>
>>> WebKit: Safari has been querying HTTPS DNS records since late 2020.
>>> Unclear if Safari has yet implemented HTTP->HTTPS redirect behavior of such
>>> records.
>>>
>>
>> It would be helpful to ask both Gecko and WebKit developers for more
>> clear signals as described in https://bit.ly/blink-signals.
>>
>
> Okay.  I'll send off those requests.
>

Update:
Request for position sent for WebKit:
https://lists.webkit.org/pipermail/webkit-dev/2021-September/031991.html

For Gecko, I discovered an older but very relevant "worth prototyping"
position (https://mozilla.github.io/standards-positions/#dnsop-svcb-httpssvc)
for the overall HTTPS record draft.  I've updated the chromestatus entry
with this position and added a note that Firefox engineers have since
stayed involved in the IETF discussions.


>
>
>>
>>> Web developers: No signals
>>>
>>
>> Are there any folks lined up to use this? Presumably there are if Safari
>> is already making these queries?
>>
>
> Most of the general interest I have heard for HTTPS records is for the ECH
> and upgrade-to-QUIC functionalities that are not part of this specific
> planned launch.  So it would be fair to say there is a lot of interest from
> various parties for HTTPS record support in general, and this HTTP->HTTPS
> redirect functionality 

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

['Liquan (Max) Gu' via blink-dev]

Yoav, MDN (PR )
and web.dev (PR ) have
taken down the basic-card content.

Is it enough to get our approval for deprecating basic-card?

On Thu, Sep 23, 2021 at 9:12 PM Patrick Guerrero 
wrote:

>
> https://www.google.com/adsense/new/u/0/pub-4013500751301578/payments/?place=USER_MANAGEMENT
>
> On Wednesday, September 22, 2021 at 11:59:57 AM UTC-6 Liquan (Max) Gu
> wrote:
>
>> Yep! We are working  with @Joe
>> Medley on updating the MDN documentation.
>>
>> On Tue, Sep 21, 2021 at 2:32 AM Yoav Weiss  wrote:
>>
>>>
>>>
>>> On Mon, Sep 20, 2021 at 9:16 PM Liquan (Max) Gu 
>>> wrote:
>>>
 Rouslan has sent a bunch of emails to the owners of the documentation:

- Samsung:
   - Samsung is removing their doc referencing “basic-card”. They
   will keep us posted.
- web.dev:
   - Eiji is updating web.dev with a PR
    (preview
   
   ).
- whatwebcando 
   - Rouslan has requested Adam to remove it. No response yet.
- MDN

:
   - Rouslan filed https://github.com/mdn/content/issues/8828 where
   the owner is looking for someone with bandwidth to update


>>> Would the team be able to write an initial draft and work with the
>>> relevant tech writers? Fixing up MDN seems critical for this deprecation to
>>> be successful.
>>>
>>>

- Adyen

 
:
   - They are reaching out to the owner to update the article, or
   will connect Rouslan Solomakhin with the article author. (meeting
   note
   
 
   ).



 On Mon, Sep 20, 2021 at 3:06 PM Yoav Weiss 
 wrote:

> Thanks! Any word on PRs to MDN and other existing documentation?
>
> On Mon, Sep 20, 2021 at 8:48 PM Liquan (Max) Gu 
> wrote:
>
>> Hi folks,
>>
>> Thanks for your patience. We ended up adding the timeline and
>> alternatives to https://www.chromestatus.com/feature/573005107056.
>> Eiji is in the process of writing a blog post that will be published at
>> https://web.dev/payment-request-basic-card-deprecation which is
>> about the deprecation. I will add the web.dev article to Chrome
>> status once the article is ready. On the console warning front, I am in 
>> the
>> process of adding basic-card deprecation to the Reporting API
>> ,
>> which will print a warning that links to the chrome status as below.
>>
>> [image: Screen Shot 2021-09-20 at 14.02.52.png]
>>
>> Does the whole thing look good to you? Please let us know. Thanks!
>>
>> On Fri, Sep 17, 2021 at 7:06 AM Mike West  wrote:
>>
>>> Technically, yes. Deprecation warnings should only land when we're
>>> _actually_ going to deprecate a thing, and have a reasonable schedule to
>>> point to.
>>>
>>> Here, though, I think we have agreement that the deprecation itself
>>> is reasonable, and agreement on a schedule. We're only blocking on
>>> documentation of alternatives and developer awareness, both of which
>>> deprecation warnings support. So, I'd LGTM CLs that added warnings if 
>>> you
>>> wanted to send them my way.
>>>
>>> -mike
>>>
>>>
>>> On Thu, Sep 16, 2021 at 9:17 PM Rouslan Solomakhin <
>>> rou...@chromium.org> wrote:
>>>
 HI Mike,

 We've been working on updating our docs and reaching out to
 external documentation owners as well. We will respond back to this 
 email
 thread once we have significant progress to report :-D

 By the way, do we need to get blink-dev@ approval for starting to
 print deprecation warnings in the Developer Console? I'm not sure 
 whether
 Developer Console warnings are considered web-facing.

 Cheers,
 Rouslan

 On Thu, Sep 16, 2021 at 3:11 PM Mike West 
 wrote:

> Hey folks,
>
> We talked about this in the API owners meeting tonight, and I
> think folks are conceptually on board with this deprecation along the
> timeline we talked about above (4 milestones). That said, there's 
> still
> practical concern that the messaging for developers currently doesn't 

Re: [blink-dev] Intent to Extend Origin Trial: Trust Token API

[Rick Byers]

LGTM3

On Thu, Sep 23, 2021 at 1:51 PM Daniel Bratell  wrote:

> With a gap, LGTM2
>
> /Daniel
> On 2021-09-23 14:14, Yoav Weiss wrote:
>
> As this is an atypical OT, this requires 3 LGTMs.
>
> *LGTM1* to extend to M101, conditional on a 2 weeks gap to demonstrate
> that there's no premature reliance on the API.
>
> On Wed, Sep 22, 2021 at 10:26 PM Steven Valdez 
> wrote:
>
>> Contact emails
>>
>> sval...@chromium.org, privacy-sand...@chromium.org
>>
>> Spec
>>
>>
>> https://docs.google.com/document/d/1TNnya6B8pyomDK2F1R9CL3dY10OAmqWlnCxsWyOBDVQ/edit
>> 
>>
>> https://github.com/WICG/trust-token-api
>>
>> Summary
>>
>> This is a new API for propagating a notion of user authenticity across
>> sites, without using cross-site persistent identifiers like third party
>> cookies. Trust Token is built on Privacy Pass
>>  for anonymous tokens that can't be
>> tracked between issuance and redemption.
>>
>> An Origin Trial for Trust Token started in M84 and is scheduled to end in
>> M94. Due to the shift in the API from a primarily first-party issuance
>> model to a third-party issuance model, we've gotten feedback from partners
>> that spinning up the complex infrastructure and models for third-party
>> issuance is taking longer than anticipated, in order to give issuers more
>> time to experiment with this model, we'd like to extend the Origin Trial to
>> M101 (April 2022).
>>
>> Link to “Intent to Prototype” blink-dev discussion
>>
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/X9sF2uLe9rA/
>>
>> Previous Intent to Extend:
>>
>>
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/-W90wVkS0Ks/m/HyICZtuuBAAJ
>>
>> Goals for experimentation
>>
>> For the continuation of the origin trial, we hope to continue to get more
>> experimental data on the value of these token-derived signals from issuance
>> schemes that take place in the third-party context, rather than where a
>> strong first-party signal is available. Additionally, we are continuing to
>> iterate on the API shape and modes to bring it more in line with the
>> underlying Privacy Pass work being standardized in the IETF.
>>
>> Experimental timeline
>>
>> We'd like to extend the Origin Trial again to run to the end of M101
>> (April 2022).
>>
>> Any risks when the experiment finishes?
>>
>> As this feature is only available via Origin Trials and doesn't affect
>> any existing state, we don't believe there will be any risks once the
>> experiment concludes. As we don't maintain backwards compatibility between
>> different versions of Trust Token (
>> https://github.com/WICG/trust-token-api/blob/main/ISSUER_PROTOCOL.md#version-history),
>> as we update it based on ecosystem feedback, we don't expect there to be
>> ecosystem burn-in as the issuers and redeemers are still required to update
>> their implementations to continue functioning in the latest version of
>> Chrome (and the server-side components of the API provided by the component
>> updater maintains minimal compatibility so that older versions of the API
>> will cease to function within a version release or so). As an extra measure
>> of safety, we can also disable the API for a couple weeks to ensure that
>> the ecosystem is not burning in the availability of the API.
>>
>> Reason this experiment is being extended
>>
>>
>> https://groups.google.com/a/chromium.org/forum/?oldui=1#!msg/blink-dev/UIvia1WwIhk/DuXLKdF7AgAJ
>>
>> Due to the complexities of issuance strategies involving purely
>> third-party based issuance, we've seen that issuers are needing a longer
>> time to spin up their infrastructure and experiment logic in order to
>> verify the usefulness of the API. Due to the scope and shape of this API,
>> we'd like to get data from issuers who are using this API before trying to
>> launch it, to help understand the efficacy of the API and the parameters
>> that the shipped version of the API should be using/allowing.
>>
>> Ongoing technical constraints
>>
>> None.
>>
>> Will this feature be supported on all five Blink platforms supported by
>> Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?
>>
>> Yes.
>>
>> Link to entry on the feature dashboard 
>>
>> https://chromestatus.com/feature/5078049450098688
>>
>> --
>> 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/CANduzxCRQpheUxNs-o4YR_Z-9OoqjUhxMHWd3Lh01%2BTPyoZTgA%40mail.gmail.com
>> 
>> .
>>
> --
> You received this message because 

[blink-dev] Re: Intent to Ship: HTTP->HTTPS redirect for HTTPS DNS records

[Mike West]

Hey Eric!

On Thu, Sep 23, 2021 at 10:36 PM Eric Orth  wrote:

> Contact emails
>
> erico...@chromium.org
>
> Explainer
>
> None
>
> Specification
>
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-07
>
> Summary
>
> Query DNS for HTTPS records (alongside traditional A and  queries).
> When a website has deployed an HTTPS DNS record and Chrome receives it,
> Chrome will always connect to the website via HTTPS.
>
> Design doc for all Chrome DNS HTTPS plans:
> https://docs.google.com/document/d/1k461sRbddjDGj7Q8f-ZKHZvmB-ENUWSdX_3Fpp2dmXQ
>
> This feature covers just the basic query and HTTP->HTTPS upgrade part of
> those plans, and only for simpler cases that do not require followup DNS
> queries by the Chrome DNS stack.
>
>
> Blink component
>
> Internals>Network>DNS
> 
>
> TAG review
>
> Not applicable. No direct changes to web platform APIs. Change is to
> underlying DNS infrastructure, following an IETF spec, with only indirect
> web-facing side effects.
>

This seems like an overly narrow take on the feature: it seems like this
needs to be wired up to Fetch in order to explain how the DNS assertion
turns into a decision about how to connect to sites (similar to HSTS's
integration
),
and that upgrade will have web-visible impacts. Can I assume that you'll be
following the same algorithm (e.g. shifting from 80 to 443 by switching the
protocol, but not altering non-standard ports)?

TAG review status
>
> Not applicable
>
> Risks
>
> Interoperability and Compatibility
>
> Not directly part of the web API surface; only has indirect behavior
> implications on the web platform in the form of the HTTP->HTTPS redirect
> triggered by DNS signals.
>
> HTTPS DNS records are a feature of DNS.  The spec is a draft of the IETF
> DNSOP working group, and while not yet a published RFC, it is widely
> considered stable and ready for implementation.  IANA has designated HTTPS
> as DNS resource record type 65.
>
>
> Gecko: No signal
>
> WebKit: Safari has been querying HTTPS DNS records since late 2020.
> Unclear if Safari has yet implemented HTTP->HTTPS redirect behavior of such
> records.
>

It would be helpful to ask both Gecko and WebKit developers for more clear
signals as described in https://bit.ly/blink-signals.

>
> Web developers: No signals
>

Are there any folks lined up to use this? Presumably there are if Safari is
already making these queries?


> Debuggability
>
> No specific DevTools support.  Changes not directly part of the web API
> surface.  Chrome is not generally used as a development tool for changing
> DNS records besides testing/developing the indirect behavior effects on
> visiting websites.
>

We represent HSTS to developers in devtools. Presumably we'd want to do the
same for this mechanism, and signal in some way to developers _why_ a
particular request was upgraded?


>
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> No
>
> Flag name
>
> None
>
> Requires code in //chrome?
>
> False
>
> Tracking bug
>
> https://crbug.com/1206455
>
> Launch bug
>
> https://crbug.com/1206460
>
> Estimated milestones
>
> Desktop 96
>
> Android 96
>
> Link to entry on the Chrome Platform Status
>
> https://www.chromestatus.com/feature/5485544526053376
>
> This intent message was generated by Chrome Platform Status
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "net-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to net-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAMOjQcEJF4%3D7zU16oki_m0vYqfX2_%2BXgH2Fxf51RnMv9ipx63w%40mail.gmail.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/CAKXHy%3DdQYtpcTrCt7L1n1GQwwGVTDr3nyyqz2Ek2div4aam2vQ%40mail.gmail.com.