date:20211027

Re: [blink-dev] Re: Intent to extend the origin trial: WebTransport over HTTP/3

2021-10-27 Thread 'Yutaka Hirano' via blink-dev

On Thu, Oct 28, 2021 at 2:38 AM Joe Medley  wrote:

> Hi,
>
> Can I get some clarification?
>
> So this extends the origin trial through 96, but you don't know yet
> whether it will ship in 97? Is this correct?
>
We're shipping WebTransport over HTTP/3 in 97.

> Joe
> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
> 816-678-7195 <(816)%20678-7195>
> *If an API's not documented it doesn't exist.*
>
>
> On Mon, Oct 25, 2021 at 1:00 AM Mike West  wrote:
>
>> LGTM3.
>>
>> -mike
>>
>>
>> On Thu, Oct 21, 2021 at 9:58 PM Daniel Bratell 
>> wrote:
>>
>>> For a gapless origin trial->shipping it is important to be sure we don't
>>> overlook any feedback in the race to shipping. The normal process has gaps
>>> built in which form natural points to do that final polish based on
>>> received feedback and that will be missing here.
>>>
>>> It does sound like the feedback has been positive though and that there
>>> are no known problems that can't be fixed after shipping, and with that in
>>> mind:
>>>
>>> LGTM2
>>> On 2021-10-21 21:53, Yoav Weiss wrote:
>>>
>>> Discussing amongst the API owners (Alex, Daniel, Rego and myself), this
>>> is essentially a request for a gapless OT, only that the would-be-gap is
>>> slightly longer than usual. Given the evidence
>>> 
>>>  of
>>> developer feedback presented in the I2S, that seems like a reasonable
>>> request.
>>>
>>> LGTM1 (as gapless OT requests require 3 LGTMs)
>>>
>>> On Monday, October 18, 2021 at 10:39:14 AM UTC+2 Yutaka Hirano wrote:
>>>
 Contact emails

 yhir...@chromium.org,vasi...@chromium.org

 Explainer

 https://github.com/w3c/webtransport/blob/main/explainer.md

 Design docs/spec

 Specification: https://w3c.github.io/webtransport/#web-transport

 https://docs.google.com/document/d/1UgviRBnZkMUq4OKcsAJvIQFX6UCXeCbOtX_wMgwD_es/edit

 TAG review

 https://github.com/w3ctag/design-reviews/issues/669

 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.

 Note that we were developing QuicTransport a.k.a. WebTransport over
 QUIC and we ran an origin trial M84 through M90. It uses the same interface
 WebTransport, but because of the protocol difference ("quic-transport" vs.
 "https") it is difficult for web developers to be confused by them.

 new WebTransport("quic-transport://example.com:9922")

 represents a WebTransport over QUIC connection, and

 new WebTransport("https://example.com:9922;)

 represents a WebTransport over HTTP/3 connection.

 Goals for experimentation

 We're shipping the API in M97
 .
 Twitch, one of our partners, wants to continue their experiment until the
 API is fully shipped. I think this is a reasonable request given we
 originally aimed to ship the feature in M96 but we missed the branch point.

 The original goals follow:

 To see whether the API (and the implementation) is useful in various
 circumstances.

 Our partners want to evaluate this API on various network circumstances
 (i.e., lab environments are not enough) to see its effectiveness.

 We also expect feedback for performance.

 Experimental timeline

 M95 and M96

 Ongoing technical constraints

 None

 Debuggability

 The devtools support is under development.

 Just like with regular HTTP/3 traffic, the detailed information about
 the connection can be obtained via chrome://net-export interface.

 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

 ?

 No

 We have browser tests, but we are going to port them to WPT.

 Link to entry on the Chrome Platform Status

 https://www.chromestatus.com/feature/4854144902889472

 --
>>> 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/9ffa05b8-fbbf-4f2a-975d-be72a1089ebcn%40chromium.org
>>>

[blink-dev] Intent to Extend Origin Trial: Subresource loading with Web Bundles

2021-10-27 Thread Daisuke Enomoto

Contact emails

hay...@chromium.org, denom...@chromium.org

Explainer

https://github.com/WICG/webpackage/blob/master/explainers/subresource-loading.md

Specification
Design docs

https://chromium.googlesource.com/chromium/src.git/+/refs/heads/master/content/browser/web_package/subresource_loading_origin_trial.md

Summary

Provides a new approach to load a large number of resources efficiently
using a format that allows multiple resources to be bundled, e.g. Web
Bundles.

Blink component

Blink>Loader>WebPackaging


TAG review

https://github.com/w3ctag/design-reviews/issues/616

(We’ll reopen this once we can have a consensus in the discussion here
)

TAG review status

Pending

Risks
Interoperability and Compatibility

No interoperability and compatibility risk has been identified for the
prototype phase. This is purely a feature addition for the performance
optimization for now.

It is expected that a browser which doesn’t support this feature should
load subresources from the network, as usual.


Gecko: No signal

WebKit: No signal

Web developers: No signals

Ergonomics
Activation

Developers need to package their subresoruces beforehand in order to take
advantage of this feature. We'll work with JS bundler ecosystems to provide
a plugin to package subresources as Web Bundles.

Security

No security risk has been identified for the prototype phase.

Goals for experimentation



This Intent to Extend includes a few major changes based on the feedback
collected during the original OT, which are 1)

Re: [blink-dev] Re: Intent to Deprecate: TLS 1.0 and TLS 1.1

2021-10-27 Thread Claire Miravalles

Hi. Thank you for your reply. This error happened in the night of October
22nd. While I  was checking my google forms and gmail. I am using Avast as
my antivirus software and my OS is windows 10.

I just checked my antivirus software and found out that one of their
services has expired. I tried to uninstall the service (not Avast entirely)
and the issue is not showing up anymore.

Thank you for your suggestions and help. This issue is now resolved.

On Wed, 27 Oct 2021, 11:53 pm David Benjamin,  wrote:

> No, the TLS version negotiated should not be OS-dependent. Chrome does not
> use the OS's TLS stack. If you're seeing an issue that's specific to an
> older version, could you file a bug so we can take a look? Perhaps you have
> an antivirus or other local proxy that has been configured to terminate TLS
> (i.e. decrypt and inspect all your browsing activity), and that proxy uses
> the OS's TLS stack.
>
> On Wed, Oct 27, 2021 at 11:49 AM Slade Watkins 
> wrote:
>
>> Hi all,
>> The other possibility could be OS related. I've had this issue with
>> Chromium on old versions macOS specifically, though I've seen it happen on
>> Windows too.
>>
>> Claire - what version of your operating system are you running?
>>
>> Cheers,
>>  -slade
>>
>>
>> On Wed, Oct 27, 2021 at 10:50 AM David Benjamin 
>> wrote:
>>
>>> Google servers have long supported TLS 1.2, so there is probably some
>>> (very) outdated antivirus or proxy on your computer or network that has
>>> been configured to decrypt your encrypted browsing activity. You'll want to
>>> either disable that or get it updated.
>>>
>>> If this doesn't ring a bell, we can try to help you identify the
>>> antivirus/proxy: file a bug at https://crbug.com/new and attach a
>>> NetLog per these instructions.
>>> https://www.chromium.org/for-testers/providing-network-details
>>>
>>> On Wed, Oct 27, 2021 at 4:54 AM Claire Miravalles <
>>> clairemiravalle...@gmail.com> wrote:
>>>

 Hi. I would like to know that all of my google services on browser in
 my pc has some problems regarding this. I can't open google forms,
 spreadsheets and even my drive has a warning signs of
 NET:ERR_SSL_OBSOLUTE_VERSION . How will it be fix? Can you help me?
 On Wednesday, October 17, 2018 at 5:15:10 AM UTC+8 David Benjamin wrote:

> (This was announced as a blog post
> 
> yesterday.)
>
> Primary eng (and PM) emails
>
> davi...@chromium.org
>
> awha...@chromium.org
>
> Summary
>
> Deprecate TLS 1.0 and 1.1 in Chrome, targeting removal in Chrome 81
> (early 2020). During the deprecation period, sites using those protocols
> will show a warning in DevTools. After which, they will fail to connect if
> they have not upgraded to TLS 1.2 by then.
>
> Motivation
>
> TLS (Transport Layer Security) is the protocol which secures HTTPS. It
> has a long history stretching back to the nearly twenty-year-old TLS 1.0
> and its even older predecessor, SSL. TLS 1.2
> , published ten years ago,
> addresses several weaknesses in TLS 1.0 and 1.1:
>
>
>-
>
>TLS 1.0 and 1.1 use MD5 and SHA-1, both weak hashes, in the
>transcript hash for the Finished message. TLS 1.2 switches this to 
> SHA-2.
>(See the SLOTH  attack.)
>-
>
>TLS 1.0 and 1.1 use MD5 and SHA-1 in the server signature (note
>this is not the signature in the certificate). TLS 1.2 makes this
>negotiable and adds SHA-2 as an option. (Also see the SLOTH
> attack.)
>-
>
>TLS 1.0 and 1.1 only support RC4 and CBC ciphers. RC4 is broken
> and has since been removed. TLS’s
>CBC mode construction is flawed and was vulnerable to a series of 
> attacks,
>most recently Lucky13 .
>TLS 1.2 introduces AEAD
>-based
>ciphers which avoid this and are more efficient.
>-
>
>TLS 1.0’s CBC ciphers additionally construct their initialization
>vectors incorrectly, making them vulnerable to the BEAST
>
>attack. TLS 1.1 fixed this.
>
>
> Supporting TLS 1.2 is a prerequisite to avoiding the above problems.
> Additionally, the industry has been moving towards this deprecation. TLS
> 1.0 is no longer PCI-DSS compliant
> 
> and the TLS working group has adopted a document
>

Re: [blink-dev] RE: [EXTERNAL] Re: Intent to Implement and Ship: Feature policy for Keyboard API

2021-10-27 Thread Dave Tapuska

For a cross origin renderer the browser process would be involved because
the allow attribute restriction is in one renderer, and the enforcement of
the permission is in the renderer that wants to use it. I do not think it
is difficult to check the policy on the mojo request of the keyboard map in
the browser process. Although you'll likely want some additional response
enums

.

I ask because we would need to adjust this model for fenced frames
implementation and the enforcement on the browser side better aligns with
our security design.

dave.

On Wed, Oct 27, 2021 at 5:42 PM Anupam Snigdha  wrote:

> I’m not sure if checking that in the browser would make sense here because
> the allow attribute restriction is specified in the DOM and the browser
> process isn’t involved. I did ask this in the slack channel and pretty much
> got the same response that the renderer should be enforcing this check. If
> you have any other ideas though, then please let me know!
>
>
>
> *From:* Dave Tapuska 
> *Sent:* Wednesday, October 27, 2021 2:27 PM
> *To:* Anupam Snigdha 
> *Cc:* slightly...@chromium.org; blink-dev@chromium.org;
> yoavwe...@chromium.org; Bo Cupp ; Scott Low <
> sc...@microsoft.com>; gary...@chromium.org; dome...@chromium.org
> *Subject:* Re: [blink-dev] RE: [EXTERNAL] Re: Intent to Implement and
> Ship: Feature policy for Keyboard API
>
>
>
> I was looking at the implementation of this. Is it possible to move the
> check of the policy to be based in the browser when the map is fetched? As
> of right now the policy enforcement is on the renderer side, so a
> compromised renderer can request the keyboard map.
>
>
>
> dave.
>
>
>
> On Wed, Oct 27, 2021 at 4:53 PM 'Anupam Snigdha' via blink-dev <
> blink-dev@chromium.org> wrote:
>
> Created an issue to get feedback from TAG:
> https://github.com/w3ctag/design-reviews/issues/685
> 
>
> I added this to the webappsec-permission policy:
> https://github.com/w3c/webappsec-permissions-policy/pull/428
> ,
> but will also create an issue to investigate Permissions API integration.
> Thanks!
>
>
>
> *From:* Alex Russell 
> *Sent:* Thursday, October 21, 2021 12:21 PM
> *To:* blink-dev 
> *Cc:* Yoav Weiss ; Anupam Snigdha <
> sni...@microsoft.com>; blin...@chromium.org ; Bo
> Cupp ; Scott Low ;
> gar...@chromium.org ; Domenic Denicola <
> dome...@chromium.org>
> *Subject:* Re: [blink-dev] RE: [EXTERNAL] Re: Intent to Implement and
> Ship: Feature policy for Keyboard API
>
>
>
> Not consulting the TAG in this instance may have been an error. In
> general, we should be putting things into consistent surfaces that they
> affect. In this case, it seems like we're missing integrations w/ the
> Permissions API.
>
>
>
> I'm LGTM2 on this intent contingent on a commitment to follow up w/ the
> TAG as an FYI and a commitment to investigate Permissions API integration.
>
>
>
> Best Regards,
>
>
>
> Alex
>
>
>
> On Sunday, October 17, 2021 at 10:16:58 PM UTC-7 Yoav Weiss wrote:
>
> LGTM1
>
>
>
> On Sat, Oct 16, 2021 at 12:35 AM Domenic Denicola 
> wrote:
>
> Just chiming in from the sidelines: in general I think this sort of
> exposure via permissions policies is a good thing, and should be encouraged.
>
>
>
> It shouldn't have any additional concerns for an API like this which is
> about exposing information:
>
>- Same-origin iframes can already call
>top.navigator.keyboard.getLayoutMap()
>- The parent can call navigator.keyboard.getLayoutMap(), serialize the
>information, and send it to any cross-origin descendants that it wants to
>receive that information via postMessage().
>
> Permissions policy just streamlines this: same-origin iframes now don't
> need to go via top, and the parent can avoid writing custom code to
> communicate the information to cross-origin descendants, instead replacing
> it with a simple allow="keyboard-map" or allow="keyboard-map
> https://specific-origin;.
>
>
>
> I hope the API owners can support this

RE: [blink-dev] RE: [EXTERNAL] Re: Intent to Implement and Ship: Feature policy for Keyboard API

2021-10-27 Thread 'Anupam Snigdha' via blink-dev

I'm not sure if checking that in the browser would make sense here because the 
allow attribute restriction is specified in the DOM and the browser process 
isn't involved. I did ask this in the slack channel and pretty much got the 
same response that the renderer should be enforcing this check. If you have any 
other ideas though, then please let me know!

From: Dave Tapuska 
Sent: Wednesday, October 27, 2021 2:27 PM
To: Anupam Snigdha 
Cc: slightly...@chromium.org; blink-dev@chromium.org; yoavwe...@chromium.org; 
Bo Cupp ; Scott Low ; 
gary...@chromium.org; dome...@chromium.org
Subject: Re: [blink-dev] RE: [EXTERNAL] Re: Intent to Implement and Ship: 
Feature policy for Keyboard API

I was looking at the implementation of this. Is it possible to move the check 
of the policy to be based in the browser when the map is fetched? As of right 
now the policy enforcement is on the renderer side, so a compromised renderer 
can request the keyboard map.

dave.

On Wed, Oct 27, 2021 at 4:53 PM 'Anupam Snigdha' via blink-dev 
mailto:blink-dev@chromium.org>> wrote:
Created an issue to get feedback from TAG: 
https://github.com/w3ctag/design-reviews/issues/685
I added this to the webappsec-permission policy: 
https://github.com/w3c/webappsec-permissions-policy/pull/428,
 but will also create an issue to investigate Permissions API integration. 
Thanks!

From: Alex Russell mailto:slightly...@chromium.org>>
Sent: Thursday, October 21, 2021 12:21 PM
To: blink-dev mailto:blink-dev@chromium.org>>
Cc: Yoav Weiss mailto:yoavwe...@chromium.org>>; Anupam 
Snigdha mailto:sni...@microsoft.com>>; 
blin...@chromium.org 
mailto:blink-dev@chromium.org>>; Bo Cupp 
mailto:pc...@microsoft.com>>; Scott Low 
mailto:sc...@microsoft.com>>; 
gar...@chromium.org 
mailto:gary...@chromium.org>>; Domenic Denicola 
mailto:dome...@chromium.org>>
Subject: Re: [blink-dev] RE: [EXTERNAL] Re: Intent to Implement and Ship: 
Feature policy for Keyboard API

Not consulting the TAG in this instance may have been an error. In general, we 
should be putting things into consistent surfaces that they affect. In this 
case, it seems like we're missing integrations w/ the Permissions API.

I'm LGTM2 on this intent contingent on a commitment to follow up w/ the TAG as 
an FYI and a commitment to investigate Permissions API integration.

Best Regards,

Alex

On Sunday, October 17, 2021 at 10:16:58 PM UTC-7 Yoav Weiss wrote:
LGTM1

On Sat, Oct 16, 2021 at 12:35 AM Domenic Denicola 
mailto:dome...@chromium.org>> wrote:
Just chiming in from the sidelines: in general I think this sort of exposure 
via permissions policies is a good thing, and should be encouraged.

It shouldn't have any additional concerns for an API like this which is about 
exposing information:

  *   Same-origin iframes can already call top.navigator.keyboard.getLayoutMap()
  *   The parent can call navigator.keyboard.getLayoutMap(), serialize the 
information, and send it to any cross-origin descendants that it wants to 
receive that information via postMessage().
Permissions policy just streamlines this: same-origin iframes now don't need to 
go via top, and the parent can avoid writing custom code to communicate the 
information to cross-origin descendants, instead replacing it with a simple 
allow="keyboard-map" or allow="keyboard-map https://specific-origin;.

I hope the API owners can support this kind of improvement to the platform, not 
only for this case but in general whenever we introduce ergonomic permissions 
policy-based delegation for any feature.

On Fri, Oct 15, 2021 at 6:00 PM 'Anupam Snigdha' via blink-dev 
mailto:blink-dev@chromium.org>> wrote:
getLayoutMap() can already be accessed by the top level browsing context and I 
believe it does have fingerprinting concerns: a site can gain knowledge of the 
keyboard layout of the user even before the user has typed anything. Try this 
site switching between French and English keyboard layouts:

Re: [blink-dev] Intent to Deprecate and Remove: WebSQL in third-party contexts

2021-10-27 Thread Ari Chivukula

Sorry for the delay, the data for actually reading/writing a database
 (as
opposed to opening it
) in
a third party context ended up being nearly identical (0.03% of loads and
about 10% of top-sites).

The code I spot checked still seems to gate usage of WebSQL on
availability. That said, the change in M97 is linked to a feature flag so
can be undone if there are issues in dev/beta. Also, there's an enterprise
policy available to enable it (planned to exist until M102, when it'll be
removed entirely and not simply disabled by default).

~ Ari Chivukula (Their/There/They're)


On Thu, Aug 5, 2021 at 12:21 PM Alex Russell 
wrote:

> LGTM3 with the caveats Yoav outlines. Would like to hear back about the
> new usecounter data on this thread before 97 branch point.
>
> Thank you for taking so much care with this deprecation.
>
> On Thursday, July 29, 2021 at 3:50:14 PM UTC-7 Chris Harrelson wrote:
>
>> LGTM2
>>
>> On Wed, Jul 28, 2021 at 9:50 AM Yoav Weiss 
>> wrote:
>>
>>> Deprecating in M94 while adding a usecounter sounds like a solid
>>> strategy. Please update this thread with the results from the usecounter
>>> once they are available.
>>>
>>> *LGTM1* to deprecate in M94 and remove support in M97, barring
>>> usecounter surprises.
>>>
>>> On Wed, Jul 28, 2021 at 6:38 PM Ari Chivukula 
>>> wrote:
>>>
 I'm saying something slightly different, that the usage I'm seeing is
 (1) checking for the existence of the function (instead of simply looking
 for if the engine is Blink) and (2) wrapping the subsequent call to
 opendatabase in a try statement (as per the spec which allows errors to be
 raised https://www.w3.org/TR/webdatabase/#databases). I think we're
 safe to (1) deprecate the function in third party contexts to alert
 developers to the change in M94 and then (2) raise SECURITY_ERR in a later
 milestone once we've completed outreach around M97 or later.

 When I do (1) I could also add a counter into M94 which looks for
 actual usage of a created database beyond the feature detection we seem to
 be catching now.

 ~ Ari Chivukula (Their/There/They're)


 On Wed, Jul 28, 2021 at 6:21 AM Yoav Weiss 
 wrote:

> So, you're saying that the usage we see is simply feature detection
> for the API and not real usage? Any way to add use counters that would
> confirm this?
>
> On Monday, July 26, 2021 at 6:38:19 PM UTC+2 Ari Chivukula wrote:
>
>> @manuel: Thanks for the corrected code pointer!
>> @yoav: The sample on the platform status page (
>> https://www.chromestatus.com/metrics/feature/timeline/popularity/3865)
>> highlighted a bunch of Hyundai dealerships, but when loading locally I'm
>> unable to reproduce the creation of any WebSQL databases. I did find 
>> usage
>> on https://accounts.mint.com/index.html, but when searching the
>> scripts which created it I found that all checked if window.openDatabase
>> even existed. The lack of support in Gecko and WebKit seems to have 
>> broken
>> in the deprecation/removal codepath for us.
>>
>> ~ Ari Chivukula (Their/There/They're)
>>
>>
>> On Mon, Jul 26, 2021 at 7:46 AM Manuel Rego Casasnovas <
>> r...@igalia.com> wrote:
>>
>>>
>>>
>>> On 26/07/2021 12:32, Yoav Weiss wrote:
>>> > WebKit: Deprecated in version 608 (Safari 13)
>>> > <
>>> https://github.com/WebKit/WebKit/commit/761bce943c0696a6bb93116eb0576ed07dbfdc65
>>> >
>>>
>>> That's a change related to WebKitGTK+ and WPE, where they marked the
>>> API
>>> as deprecated.
>>>
>>> Anyway it seems this was removed in Safari (at least on WebKit2, it
>>> might be still available in WebKit1 though). See this thread:
>>>
>>> https://lists.webkit.org/pipermail/webkit-dev/2019-November/030970.html
>>> And also this commit:
>>> https://trac.webkit.org/changeset/277564/webkit
>>>
>>> Cheers,
>>>   Rego
>>>
>> --
>>>
>> 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/CAL5BFfUCNvRNGQN7Oj6y7R2682KTv%3DgHis8nOSYs7Ne5q%2BHxBg%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

Re: [blink-dev] RE: [EXTERNAL] Re: Intent to Implement and Ship: Feature policy for Keyboard API

2021-10-27 Thread Dave Tapuska

I was looking at the implementation of this. Is it possible to move the
check of the policy to be based in the browser when the map is fetched? As
of right now the policy enforcement is on the renderer side, so a
compromised renderer can request the keyboard map.

dave.

On Wed, Oct 27, 2021 at 4:53 PM 'Anupam Snigdha' via blink-dev <
blink-dev@chromium.org> wrote:

> Created an issue to get feedback from TAG:
> https://github.com/w3ctag/design-reviews/issues/685
>
> I added this to the webappsec-permission policy:
> https://github.com/w3c/webappsec-permissions-policy/pull/428, but will
> also create an issue to investigate Permissions API integration. Thanks!
>
>
>
> *From:* Alex Russell 
> *Sent:* Thursday, October 21, 2021 12:21 PM
> *To:* blink-dev 
> *Cc:* Yoav Weiss ; Anupam Snigdha <
> sni...@microsoft.com>; blin...@chromium.org ; Bo
> Cupp ; Scott Low ;
> gar...@chromium.org ; Domenic Denicola <
> dome...@chromium.org>
> *Subject:* Re: [blink-dev] RE: [EXTERNAL] Re: Intent to Implement and
> Ship: Feature policy for Keyboard API
>
>
>
> Not consulting the TAG in this instance may have been an error. In
> general, we should be putting things into consistent surfaces that they
> affect. In this case, it seems like we're missing integrations w/ the
> Permissions API.
>
>
>
> I'm LGTM2 on this intent contingent on a commitment to follow up w/ the
> TAG as an FYI and a commitment to investigate Permissions API integration.
>
>
>
> Best Regards,
>
>
>
> Alex
>
>
>
> On Sunday, October 17, 2021 at 10:16:58 PM UTC-7 Yoav Weiss wrote:
>
> LGTM1
>
>
>
> On Sat, Oct 16, 2021 at 12:35 AM Domenic Denicola 
> wrote:
>
> Just chiming in from the sidelines: in general I think this sort of
> exposure via permissions policies is a good thing, and should be encouraged.
>
>
>
> It shouldn't have any additional concerns for an API like this which is
> about exposing information:
>
>- Same-origin iframes can already call
>top.navigator.keyboard.getLayoutMap()
>- The parent can call navigator.keyboard.getLayoutMap(), serialize the
>information, and send it to any cross-origin descendants that it wants to
>receive that information via postMessage().
>
> Permissions policy just streamlines this: same-origin iframes now don't
> need to go via top, and the parent can avoid writing custom code to
> communicate the information to cross-origin descendants, instead replacing
> it with a simple allow="keyboard-map" or allow="keyboard-map
> https://specific-origin;.
>
>
>
> I hope the API owners can support this kind of improvement to the
> platform, not only for this case but in general whenever we introduce
> ergonomic permissions policy-based delegation for any feature.
>
>
>
>
>
> On Fri, Oct 15, 2021 at 6:00 PM 'Anupam Snigdha' via blink-dev <
> blink-dev@chromium.org> wrote:
>
> getLayoutMap() can already be accessed by the top level browsing context
> and I believe it does have fingerprinting concerns: a site can gain
> knowledge of the keyboard layout of the user even before the user has typed
> anything. Try this site switching between French and English keyboard
> layouts: https://fortunate-onyx-wren.glitch.me/french-or-english.html
> .
> The privacy mitigation section
> 
> describes some mitigations we could add for fingerprinting related concerns.
>
>
> I don't think exposing this by default to same origin iframes and allowing
> the top-level browsing context to delegate its authority to use
> getLayoutMap() to other iframes increases the concern any. If I'm thinking
> about that wrong please let me know.
>
>
>
> For the privacy section: I’ll make a change to add permission policy along
> with the top level browsing context restriction to the spec.
>
>
>
> *From:* Yoav Weiss 
> *Sent:* Friday, October 15, 2021 5:46 AM
> *To:* blink-dev 
> *Cc:* Anupam Snigdha ; Bo Cupp ;
> Scott Low ; gar...@chromium.org ;
> Yoav Weiss 
> *Subject:* Re: [EXTERNAL] Re: Intent to Implement and Ship: Feature
> policy for Keyboard API
>
>
>
> Reading through https://wicg.github.io/keyboard-map/#privacy
>

Re: [blink-dev] Intent to Prototype and Ship: self.structuredClone

2021-10-27 Thread Fernando Serboncini

This is amazing! :)

I agree it shouldn't block this, but do we have anywhere written what
are the browser's differences on structured clone algorithms? Is it a spec
issue? Could we add WPT tests for it?

On Wed, Oct 27, 2021 at 2:45 PM Andreu Botella 
wrote:

> * Contact emails*
> and...@andreubotella.com, jbro...@chromium.org, su...@chromium.org
>
> *Explainer*
> https://github.com/whatwg/html/issues/793
>
> *Specification*
> https://html.spec.whatwg.org/#structured-cloning
>
> * Summary*
> Enables using the HTML structured clone algorithm synchronously for
> cloning and transferring objects within a single realm.
>
> * Initial public proposal*
> https://github.com/whatwg/html/issues/793
> https://github.com/whatwg/html/pull/3414
>
> *Blink component*
> Blink>Messaging
> 
>
> * TAG review*
> This is just exposing existing browser functionality, with a two-line
> spec. It doesn’t seem like there’s much to discuss architecturally, but
> I’ll file for review if the community thinks it would help.
>
> *TAG review status*
> Not applicable
>
> * Risks*
>
> * Interoperability and Compatibility*
> Low. There are some differences across the browsers’ implementations of
> the structured cloning algorithm, but they are very minor and already
> present in other APIs that use it.
>
> Gecko: Shipped/Shipping (
> https://bugzilla.mozilla.org/show_bug.cgi?id=1722576)
> Edge: No signal
> WebKit: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=228331)
>
> Web developers: Positive (
> https://github.com/whatwg/html/pull/3414#issuecomment-854051942 and
> following comments). There seems to be a lot of demand for a built-in deep
> clone, and while structured clone is not exactly that, it fulfills many of
> the use cases.
>
> * Debuggability*
> n/a
>
> * Is this feature fully tested by web-platform-tests
> ?*
> Yes
> 
>
> * Requires code in //chrome?*
> False
>
> * Tracking bug*
> https://bugs.chromium.org/p/chromium/issues/detail?id=1233571
>
> *Estimated milestones*
> No milestones specified
>
> * Link to entry on the Chrome Platform Status*
> https://chromestatus.com/feature/5630001077551104
>
> *Requesting approval to ship? *
> Yes. This is a relatively small feature which exposes existing
> functionality.
>
> --
> 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/e7299674-54df-4f4d-8c30-d922ebf4e47cn%40chromium.org
> 
> .
>

-- 
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/CADp2-T8MnDX0_S%3DMy1bFSzHEMgx2MJt20ptWuG9GyOKbR%3Dt2OA%40mail.gmail.com.

RE: [blink-dev] RE: [EXTERNAL] Re: Intent to Implement and Ship: Feature policy for Keyboard API

2021-10-27 Thread 'Anupam Snigdha' via blink-dev

Created an issue to get feedback from TAG: 
https://github.com/w3ctag/design-reviews/issues/685
I added this to the webappsec-permission policy: 
https://github.com/w3c/webappsec-permissions-policy/pull/428, but will also 
create an issue to investigate Permissions API integration. Thanks!

From: Alex Russell 
Sent: Thursday, October 21, 2021 12:21 PM
To: blink-dev 
Cc: Yoav Weiss ; Anupam Snigdha ; 
blin...@chromium.org ; Bo Cupp ; 
Scott Low ; gar...@chromium.org ; 
Domenic Denicola 
Subject: Re: [blink-dev] RE: [EXTERNAL] Re: Intent to Implement and Ship: 
Feature policy for Keyboard API

Not consulting the TAG in this instance may have been an error. In general, we 
should be putting things into consistent surfaces that they affect. In this 
case, it seems like we're missing integrations w/ the Permissions API.

I'm LGTM2 on this intent contingent on a commitment to follow up w/ the TAG as 
an FYI and a commitment to investigate Permissions API integration.

Best Regards,

Alex

On Sunday, October 17, 2021 at 10:16:58 PM UTC-7 Yoav Weiss wrote:
LGTM1

On Sat, Oct 16, 2021 at 12:35 AM Domenic Denicola 
mailto:dome...@chromium.org>> wrote:
Just chiming in from the sidelines: in general I think this sort of exposure 
via permissions policies is a good thing, and should be encouraged.

It shouldn't have any additional concerns for an API like this which is about 
exposing information:

  *   Same-origin iframes can already call top.navigator.keyboard.getLayoutMap()
  *   The parent can call navigator.keyboard.getLayoutMap(), serialize the 
information, and send it to any cross-origin descendants that it wants to 
receive that information via postMessage().
Permissions policy just streamlines this: same-origin iframes now don't need to 
go via top, and the parent can avoid writing custom code to communicate the 
information to cross-origin descendants, instead replacing it with a simple 
allow="keyboard-map" or allow="keyboard-map https://specific-origin;.

I hope the API owners can support this kind of improvement to the platform, not 
only for this case but in general whenever we introduce ergonomic permissions 
policy-based delegation for any feature.

On Fri, Oct 15, 2021 at 6:00 PM 'Anupam Snigdha' via blink-dev 
mailto:blink-dev@chromium.org>> wrote:
getLayoutMap() can already be accessed by the top level browsing context and I 
believe it does have fingerprinting concerns: a site can gain knowledge of the 
keyboard layout of the user even before the user has typed anything. Try this 
site switching between French and English keyboard layouts: 
https://fortunate-onyx-wren.glitch.me/french-or-english.html.
 The privacy mitigation 
section
 describes some mitigations we could add for fingerprinting related concerns.

I don't think exposing this by default to same origin iframes and allowing the 
top-level browsing context to delegate its authority to use getLayoutMap() to 
other iframes increases the concern any. If I'm thinking about that wrong 
please let me know.

For the privacy section: I'll make a change to add permission policy along with 
the top level browsing context restriction to the spec.

From: Yoav Weiss mailto:yoavwe...@chromium.org>>
Sent: Friday, October 15, 2021 5:46 AM
To: blink-dev mailto:blink-dev@chromium.org>>
Cc: Anupam Snigdha mailto:sni...@microsoft.com>>; Bo Cupp 
mailto:pc...@microsoft.com>>; Scott Low 
mailto:sc...@microsoft.com>>; 
gar...@chromium.org 
mailto:gary...@chromium.org>>; Yoav Weiss 
mailto:yoavwe...@chromium.org>>
Subject: Re: [EXTERNAL] Re: Intent to Implement and Ship: Feature policy for 
Keyboard API

Reading through 
https://wicg.github.io/keyboard-map/#privacy
 the only risk here is increased fingerprinting surface. Is that correct?
(aside - the

[blink-dev] Intent to Prototype and Ship: self.structuredClone

2021-10-27 Thread Andreu Botella

* Contact emails*
and...@andreubotella.com, jbro...@chromium.org, su...@chromium.org

*Explainer*
https://github.com/whatwg/html/issues/793

*Specification*
https://html.spec.whatwg.org/#structured-cloning

* Summary*
Enables using the HTML structured clone algorithm synchronously for cloning
and transferring objects within a single realm.

* Initial public proposal*
https://github.com/whatwg/html/issues/793
https://github.com/whatwg/html/pull/3414

*Blink component*
Blink>Messaging

* TAG review*
This is just exposing existing browser functionality, with a two-line spec.
It doesn’t seem like there’s much to discuss architecturally, but I’ll file
for review if the community thinks it would help.

*TAG review status*
Not applicable

* Risks*

* Interoperability and Compatibility*
Low. There are some differences across the browsers’ implementations of the
structured cloning algorithm, but they are very minor and already present
in other APIs that use it.

Gecko: Shipped/Shipping (
https://bugzilla.mozilla.org/show_bug.cgi?id=1722576)
Edge: No signal
WebKit: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=228331)

Web developers: Positive (
https://github.com/whatwg/html/pull/3414#issuecomment-854051942 and
following comments). There seems to be a lot of demand for a built-in deep
clone, and while structured clone is not exactly that, it fulfills many of
the use cases.

* Debuggability*
n/a

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

* Requires code in //chrome?*
False

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

*Estimated milestones*
No milestones specified

* Link to entry on the Chrome Platform Status*
https://chromestatus.com/feature/5630001077551104

*Requesting approval to ship? *
Yes. This is a relatively small feature which exposes existing
functionality.

--
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/e7299674-54df-4f4d-8c30-d922ebf4e47cn%40chromium.org.

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

2021-10-27 Thread 'Anupam Snigdha' via blink-dev

Thanks Daniel for raising this concern. I have opened an issue to discuss with 
the Editing WG: https://github.com/w3c/clipboard-apis/issues/161. In the 
current implementation, I think verifying whether the Document is active or not 
after the promises have been resolved should mitigate some of the concerns.

From: Daniel Bratell 
Sent: Thursday, October 21, 2021 12:48 PM
To: Domenic Denicola ; Yoav Weiss 
Cc: blink-dev ; Anupam Snigdha ; 
ann...@annevk.nl ; Marijn Kruisselbrink ; 
Bo Cupp 
Subject: Re: [EXTERNAL] Re: [blink-dev] Intent to Implement and Ship: Add 
support for Promise to Blobs in clipboard item

Inspired by the recent talk about user interaction, I feel like there is one 
thing I want to understand.

So with a Promise you move the execution to a later time. Is it possible here 
for a malicious page to delay an action to much, much later and then do that 
clipboard operation on data that was not available at the time of the clipboard 
operation the user initiated?

If so, could that have security implications?

Could there even be more than one ongoing clipboard operation at a time?

/Daniel

On 2021-10-21 17:20, Domenic Denicola wrote:

On Thu, Oct 21, 2021 at 5:21 AM Yoav Weiss 
mailto:yoavwe...@chromium.org>> wrote:
LGTM1 to ship conditional that y'all continue to work on PR 
#158
 specifically, and clarifying the spec's processing model in general.
On Thursday, October 21, 2021 at 2:04:53 AM UTC+2 snianu wrote:
Gentle ping as the branch cutoff date for 97 is pretty close. While I agree 
that the issues related to clipboard API spec need to be addressed, I don't 
think this feature needs to be blocked on that. It's not a breaking change i.e. 
sites can continue to use Blobs if they want to(although I don't think any 
developer would want to have different codepaths for Apple and Chromium 
browsers)

FWIW, I got curious RE why that *should* work, and did some digging.
It seems like the bindings methods that accept a `Promise` input value call 
`NativeValueTraits`
 on that value, which 
casts
 the value foo into a `Promise.resolve(foo)`, if it wasn't a Promise already.
The same seems to work in WebKit as well. Do you know if this bindings behavior 
is specified?

It is: 
https://webidl.spec.whatwg.org/#es-promise

Also, can you add tests for both input cases as part of your CLs for this?

, and Apple has already shipped this feature. Please let me know in case of any 
concerns.

-Anupam

From: Anupam Snigdha
Sent: Thursday, October 7, 2021 9:53 AM
To: 'Yoav Weiss' mailto:yoavwe...@chromium.org>>
Cc: ann...@annevk.nl; 
blink-dev@chromium.org; 
m...@chromium.org; Bo Cupp 
mailto:pc...@microsoft.com>>
Subject: RE: [EXTERNAL] Re: [blink-dev] Intent to Implement and Ship: Add 
support for Promise to Blobs in clipboard item

Yep, I'll address the feedback from Anne and mbrodesser (from Mozilla).
Thanks for all your help Anne and Yoav!

From: Yoav Weiss mailto:yoavwe...@chromium.org>>
Sent: Thursday, October 7, 2021 12:03 AM
To: Anupam Snigdha

Re: [blink-dev] Re: Intent to extend the origin trial: WebTransport over HTTP/3

2021-10-27 Thread 'Joe Medley' via blink-dev

Hi,

Can I get some clarification?

So this extends the origin trial through 96, but you don't know yet whether
it will ship in 97? Is this correct?

Joe
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Mon, Oct 25, 2021 at 1:00 AM Mike West  wrote:

> LGTM3.
>
> -mike
>
>
> On Thu, Oct 21, 2021 at 9:58 PM Daniel Bratell 
> wrote:
>
>> For a gapless origin trial->shipping it is important to be sure we don't
>> overlook any feedback in the race to shipping. The normal process has gaps
>> built in which form natural points to do that final polish based on
>> received feedback and that will be missing here.
>>
>> It does sound like the feedback has been positive though and that there
>> are no known problems that can't be fixed after shipping, and with that in
>> mind:
>>
>> LGTM2
>> On 2021-10-21 21:53, Yoav Weiss wrote:
>>
>> Discussing amongst the API owners (Alex, Daniel, Rego and myself), this
>> is essentially a request for a gapless OT, only that the would-be-gap is
>> slightly longer than usual. Given the evidence
>> 
>>  of
>> developer feedback presented in the I2S, that seems like a reasonable
>> request.
>>
>> LGTM1 (as gapless OT requests require 3 LGTMs)
>>
>> On Monday, October 18, 2021 at 10:39:14 AM UTC+2 Yutaka Hirano wrote:
>>
>>> Contact emails
>>>
>>> yhir...@chromium.org,vasi...@chromium.org
>>>
>>> Explainer
>>>
>>> https://github.com/w3c/webtransport/blob/main/explainer.md
>>>
>>> Design docs/spec
>>>
>>> Specification: https://w3c.github.io/webtransport/#web-transport
>>>
>>>
>>> https://docs.google.com/document/d/1UgviRBnZkMUq4OKcsAJvIQFX6UCXeCbOtX_wMgwD_es/edit
>>>
>>> TAG review
>>>
>>> https://github.com/w3ctag/design-reviews/issues/669
>>>
>>>
>>> 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.
>>>
>>> Note that we were developing QuicTransport a.k.a. WebTransport over QUIC
>>> and we ran an origin trial M84 through M90. It uses the same interface
>>> WebTransport, but because of the protocol difference ("quic-transport" vs.
>>> "https") it is difficult for web developers to be confused by them.
>>>
>>> new WebTransport("quic-transport://example.com:9922")
>>>
>>> represents a WebTransport over QUIC connection, and
>>>
>>> new WebTransport("https://example.com:9922;)
>>>
>>> represents a WebTransport over HTTP/3 connection.
>>>
>>> Goals for experimentation
>>>
>>> We're shipping the API in M97
>>> .
>>> Twitch, one of our partners, wants to continue their experiment until the
>>> API is fully shipped. I think this is a reasonable request given we
>>> originally aimed to ship the feature in M96 but we missed the branch point.
>>>
>>> The original goals follow:
>>>
>>> To see whether the API (and the implementation) is useful in various
>>> circumstances.
>>>
>>> Our partners want to evaluate this API on various network circumstances
>>> (i.e., lab environments are not enough) to see its effectiveness.
>>>
>>> We also expect feedback for performance.
>>>
>>> Experimental timeline
>>>
>>> M95 and M96
>>>
>>> Ongoing technical constraints
>>>
>>> None
>>>
>>> Debuggability
>>>
>>> The devtools support is under development.
>>>
>>> Just like with regular HTTP/3 traffic, the detailed information about
>>> the connection can be obtained via chrome://net-export interface.
>>>
>>> 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
>>> 
>>> ?
>>>
>>> No
>>>
>>> We have browser tests, but we are going to port them to WPT.
>>>
>>> Link to entry on the Chrome Platform Status
>>>
>>> https://www.chromestatus.com/feature/4854144902889472
>>>
>>> --
>> 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/9ffa05b8-fbbf-4f2a-975d-be72a1089ebcn%40chromium.org
>> 
>> .
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe

Re: [blink-dev] Intent to Ship: Standardize existing client hint naming

2021-10-27 Thread Ari Chivukula

The code is all in for M97

On Wed, Oct 27, 2021 at 10:30 Joe Medley  wrote:

> Hi,
>
> In which version of Chrome do you expect to ship?
>
> Joe
> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>  816-678-7195
> *If an API's not documented it doesn't exist.*
>
>
> On Thu, Oct 21, 2021 at 12:37 PM Alex Russell 
> wrote:
>
>> LGTM3.
>>
>> In future, if you assert a TAG review isn't necessary, please provide
>> links to previous reviews that cover the same space.
>>
>> On Thursday, October 21, 2021 at 12:17:45 PM UTC-7 Manuel Rego wrote:
>>
>>> LGTM2
>>>
>>> On 21/10/2021 21:16, Daniel Bratell wrote:
>>> > LGTM1
>>> >
>>> > /Daniel
>>> >
>>> > On Friday, 15 October 2021 at 14:41:44 UTC+2 ari...@chromium.org
>>> wrote:
>>> >
>>> > Correct, they’ll behave the same as the other non-legacy hints.
>>> >
>>> > On Fri, Oct 15, 2021 at 05:34 Yoav Weiss 
>>> wrote:
>>> >
>>> > Thanks for working on this, Ari!
>>> >
>>> > IIUC, this intent will add these new hint names, but would
>>> > also ensure their behavior when it comes to 3P delegation would
>>> > be different from the legacy hints (as they don't have the same
>>> > legacy baggage). Is that correct?
>>> >
>>> >
>>> > On Mon, Oct 11, 2021 at 8:09 PM Ari Chivukula
>>> >  wrote:
>>> >
>>> > Contact emails
>>> >
>>> > ari...@chromium.org, jadek...@chromium.org, mike...@chromium.org
>>> >
>>> >
>>> > Design Doc
>>> >
>>> >
>>> https://docs.google.com/document/d/1yhVLyEIpDhhDQf698WkvXBiPcLwxEgCBI4o1FjvXwfM/edit
>>> > <
>>> https://docs.google.com/document/d/1yhVLyEIpDhhDQf698WkvXBiPcLwxEgCBI4o1FjvXwfM/edit>
>>>
>>> >
>>> >
>>> > Specification
>>> >
>>> > https://wicg.github.io/client-hints-infrastructure/
>>> > 
>>> >
>>> > https://wicg.github.io/responsive-image-client-hints/
>>> > 
>>> >
>>> > https://wicg.github.io/savedata/#save-data-request-header-field
>>> > 
>>> >
>>> > https://wicg.github.io/netinfo/#networkinformation-interface
>>> > 
>>> >
>>> >
>>> > Summary
>>> >
>>> > This proposal seeks to align our implementation with the
>>> > Client Hint proposal
>>> > by
>>> > adding the `sec-ch-` prefix where it’s missing.
>>> >
>>> >
>>> > Blink component
>>> >
>>> > Privacy>Fingerprinting
>>> > <
>>> https://bugs.chromium.org/p/chromium/issues/list?q=component%3APrivacy%3EFingerprinting>
>>>
>>> >
>>> >
>>> > Motivation
>>> >
>>> > Client Hints
>>> > , a
>>> > method to request information about the user's device or
>>> > conditions, have been implemented in Chrome, but since the
>>> > initial implementation the naming scheme has changed. If
>>> > implemented, this proposal would add new client hints with a
>>> > `sec-ch-` prefix to re-implement the following: `dpr`,
>>> > `width`, `viewport-width`, and `device-memory`. The three
>>> > network related client hints with legacy names, `rtt`,
>>> > `downlink`, and `ect`, will not be updated as they may be
>>> > replaced by different hints in an independent process.
>>> >
>>> >
>>> > TAG review
>>> >
>>> > Not needed
>>> >
>>> >
>>> > Risks
>>> >
>>> > Only Blink implements client hints and we are not (yet)
>>> > removing any current ones, just re-implementing existing
>>> > ones under the correct name. If usage permits, we will
>>> > remove the legacy names in the future.
>>> >
>>> >
>>> >
>>> >
>>> > Interoperability and Compatibility
>>> >
>>> > Gecko: Client hints not implemented
>>> >
>>> > WebKit: Client hints not implemented
>>> >
>>> > Web developers: Positive interest from Cloudinary
>>> > <
>>> https://discourse.wicg.io/t/responsive-image-client-hints-call-for-review/5470>
>>>
>>> >
>>> >
>>> > Is this feature fully tested by web-platform-tests?
>>> >
>>> > Yes
>>> > <
>>> https://chromium.googlesource.com/chromium/src/+/refs/heads/main/third_party/blink/web_tests/external/wpt/client-hints/>
>>>
>>> >
>>> >
>>> > Tracking bug
>>> >
>>> > https://crbug.com/1227043 
>>> >
>>> >
>>> > Link to entry on the Chrome Platform Status
>>> >
>>> > https://www.chromestatus.com/feature/6658223894429696
>>> > 
>>> >
>>> >
>>> > --
>>> > 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/CAGpy5D%2B30oHb6PLFQK0-hFQu2nZ%2Bq_Ge6U4cLXEvsgm-uZaJbQ%40mail.gmail.com
>>> > <
>>>

Re: [blink-dev] Intent to Ship: Standardize existing client hint naming

2021-10-27 Thread 'Joe Medley' via blink-dev

Hi,

In which version of Chrome do you expect to ship?

Joe
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Thu, Oct 21, 2021 at 12:37 PM Alex Russell 
wrote:

> LGTM3.
>
> In future, if you assert a TAG review isn't necessary, please provide
> links to previous reviews that cover the same space.
>
> On Thursday, October 21, 2021 at 12:17:45 PM UTC-7 Manuel Rego wrote:
>
>> LGTM2
>>
>> On 21/10/2021 21:16, Daniel Bratell wrote:
>> > LGTM1
>> >
>> > /Daniel
>> >
>> > On Friday, 15 October 2021 at 14:41:44 UTC+2 ari...@chromium.org
>> wrote:
>> >
>> > Correct, they’ll behave the same as the other non-legacy hints.
>> >
>> > On Fri, Oct 15, 2021 at 05:34 Yoav Weiss  wrote:
>> >
>> > Thanks for working on this, Ari!
>> >
>> > IIUC, this intent will add these new hint names, but would
>> > also ensure their behavior when it comes to 3P delegation would
>> > be different from the legacy hints (as they don't have the same
>> > legacy baggage). Is that correct?
>> >
>> >
>> > On Mon, Oct 11, 2021 at 8:09 PM Ari Chivukula
>> >  wrote:
>> >
>> > Contact emails
>> >
>> > ari...@chromium.org, jadek...@chromium.org, mike...@chromium.org
>> >
>> >
>> > Design Doc
>> >
>> >
>> https://docs.google.com/document/d/1yhVLyEIpDhhDQf698WkvXBiPcLwxEgCBI4o1FjvXwfM/edit
>> > <
>> https://docs.google.com/document/d/1yhVLyEIpDhhDQf698WkvXBiPcLwxEgCBI4o1FjvXwfM/edit>
>>
>> >
>> >
>> > Specification
>> >
>> > https://wicg.github.io/client-hints-infrastructure/
>> > 
>> >
>> > https://wicg.github.io/responsive-image-client-hints/
>> > 
>> >
>> > https://wicg.github.io/savedata/#save-data-request-header-field
>> > 
>> >
>> > https://wicg.github.io/netinfo/#networkinformation-interface
>> > 
>> >
>> >
>> > Summary
>> >
>> > This proposal seeks to align our implementation with the
>> > Client Hint proposal
>> > by
>> > adding the `sec-ch-` prefix where it’s missing.
>> >
>> >
>> > Blink component
>> >
>> > Privacy>Fingerprinting
>> > <
>> https://bugs.chromium.org/p/chromium/issues/list?q=component%3APrivacy%3EFingerprinting>
>>
>> >
>> >
>> > Motivation
>> >
>> > Client Hints
>> > , a
>> > method to request information about the user's device or
>> > conditions, have been implemented in Chrome, but since the
>> > initial implementation the naming scheme has changed. If
>> > implemented, this proposal would add new client hints with a
>> > `sec-ch-` prefix to re-implement the following: `dpr`,
>> > `width`, `viewport-width`, and `device-memory`. The three
>> > network related client hints with legacy names, `rtt`,
>> > `downlink`, and `ect`, will not be updated as they may be
>> > replaced by different hints in an independent process.
>> >
>> >
>> > TAG review
>> >
>> > Not needed
>> >
>> >
>> > Risks
>> >
>> > Only Blink implements client hints and we are not (yet)
>> > removing any current ones, just re-implementing existing
>> > ones under the correct name. If usage permits, we will
>> > remove the legacy names in the future.
>> >
>> >
>> >
>> >
>> > Interoperability and Compatibility
>> >
>> > Gecko: Client hints not implemented
>> >
>> > WebKit: Client hints not implemented
>> >
>> > Web developers: Positive interest from Cloudinary
>> > <
>> https://discourse.wicg.io/t/responsive-image-client-hints-call-for-review/5470>
>>
>> >
>> >
>> > Is this feature fully tested by web-platform-tests?
>> >
>> > Yes
>> > <
>> https://chromium.googlesource.com/chromium/src/+/refs/heads/main/third_party/blink/web_tests/external/wpt/client-hints/>
>>
>> >
>> >
>> > Tracking bug
>> >
>> > https://crbug.com/1227043 
>> >
>> >
>> > Link to entry on the Chrome Platform Status
>> >
>> > https://www.chromestatus.com/feature/6658223894429696
>> > 
>> >
>> >
>> > --
>> > 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/CAGpy5D%2B30oHb6PLFQK0-hFQu2nZ%2Bq_Ge6U4cLXEvsgm-uZaJbQ%40mail.gmail.com
>> > <
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5D%2B30oHb6PLFQK0-hFQu2nZ%2Bq_Ge6U4cLXEvsgm-uZaJbQ%40mail.gmail.com?utm_medium=email_source=footer>.
>>
>> >
>> > --
>> > ~ Ari Chivukula (Their/There/They’re)
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "blink-dev" group.
>> > To unsubscribe from this group and stop

Re: [blink-dev] Intent to Ship: Independent/Individual Properties for CSS Transforms

2021-10-27 Thread 'Joe Medley' via blink-dev

Hi,

In which version of Chrome do you hope to ship?

Joe
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Thu, Oct 21, 2021 at 12:03 PM Manuel Rego Casasnovas 
wrote:

> LGTM3.
>
> On 21/10/2021 19:53, Daniel Bratell wrote:
> > LGTM2.
> >
> > /Daniel
> >
> > On 2021-10-21 08:19, Yoav Weiss wrote:
> >> LGTM1
> >> Seems important to catch up here, so thanks for working on this!!
> >>
> >> On Mon, Oct 18, 2021 at 11:05 PM David Baron 
> wrote:
> >>
> >>
> >> Contact emails
> >>
> >>
> >> dba...@chromium.org, kev...@chromium.org,
> fla...@chromium.org
> >>
> >>
> >> Explainer
> >>
> >>
> >> None
> >>
> >>
> >> Specification
> >>
> >>
> >>
> https://drafts.csswg.org/css-transforms-2/#individual-transforms
> >>
> >>
> >> Summary
> >>
> >>
> >> This adds three new CSS properties: translate, rotate, and
> >> scale. This exposes a simple way for web developers to
> >> access transforms in an intuitive way, without having to
> >> think about how functions in the transform property
> >> interact with each other. The properties are individually
> >> animatable.
> >>
> >>
> >>
> >> Blink component
> >>
> >>
> >> Blink
> >> <
> https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink>
> >>
> >>
> >> TAG review
> >>
> >>
> >> Already shipped in two browser engines.
> >>
> >>
> >> TAG review status
> >>
> >>
> >> Not applicable (I think)
> >>
> >>
> >> Risks
> >>
> >>
> >>
> >>
> >> Interoperability and Compatibility
> >>
> >>
> >>
> >>
> >> Gecko: Shipped/Shipping
> >> (https://bugzilla.mozilla.org/show_bug.cgi?id=1424900)
> >> Shipped in Firefox 72, January 2020.
> >>
> >> WebKit: Shipped/Shipping
> >> (
> https://webkit.org/blog/11420/css-individual-transform-properties/)
> >> Shipped in Safari 14.1 (desktop) / 14.5 (iOS), April 2021.
> >>
> >> Web developers: Positive: 25 stars
> >> on
> https://bugs.chromium.org/p/chromium/issues/detail?id=496550 .
> >> Notable early developer request for the feature (before WG
> >> adoption)
> >> in:
> https://twitter.com/rachelnabors/status/618266391993454592
> https://twitter.com/rachelnabors/status/618267483296825344 and
> >> early reaction to WG adoption
> >> in
> https://twitter.com/SaraSoueidan/status/613368671315054592 .
> >> Positive developer reactions
> >> to https://twitter.com/argyleink/status/1338907239990497280
>  .
> >> Largely positive reactions to news of other engines
> >> shipping the feature in responses
> >> to
> https://twitter.com/jensimmons/status/1387870244392382468 ,
> https://twitter.com/simevidas/status/627956718098485248 ,
> https://twitter.com/dancwilson/status/121457225783989862 ,
> >> and
> >> in
> https://twitter.com/guerriero_se/status/1338468028804001796 ,
> https://twitter.com/eladsc/status/1216286886697885696 ,
> https://twitter.com/_zouhir/status/1389461399026294791 .
> >> More recent developer interest
> >> in https://twitter.com/anatudor/status/1377491818636587008
>  , https://twitter.com/anatudor/status/1309200388311199751 .
> >>
> >>
> >> Debuggability
> >>
> >>
> >> Has the standard exposure in devtools that all CSS
> >> properties have.
> >>
> >>
> >>
> >> Is this feature fully tested by web-platform-tests
> >> <
> https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md
> >?
> >>
> >>
> >> Yes
> >>
> >>
> >> Flag name
> >>
> >>
> >> CSSIndependentTransformProperties
> >>
> >>
> >> Requires code in //chrome?
> >>
> >>
> >> False
> >>
> >>
> >> Tracking bug
> >>
> >>
> >>
> https://bugs.chromium.org/p/chromium/issues/detail?id=496550
> >>
> >>
> >> Estimated milestones
> >>
> >> The feature has been implemented behind a flag on
> >> desktop/android/WebView since Chrome 45 (not a typo).
> >>
> >> For an estimated milestone for shipping, I think the feature is
> >> close to being ready, so I'm still hoping for Chrome 97 but can't
> >> promise that it will be ready in time.  It's waiting on a single
> >> chain of dependencies, as described in the bug
> >> ,
> so
> >> that more than one of the transform properties on a single element
> >> can be simultaneously animated on the compositor.
> >>
> >>
> >> Link to entry on the Chrome Platform Status
> >>
> >>
>

Re: [blink-dev] Intent to Implement and Ship : onsecuritypolicyviolation event handler IDL attribute

2021-10-27 Thread 'Joe Medley' via blink-dev

Hi,

In which version of Chrome do you hope to ship?
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Thu, Oct 21, 2021 at 11:14 AM Daniel Bratell  wrote:

> Indeed, so I'm making my LGTM2 on the other thread into an LGTM3 on this
> thread.
>
> /Daniel
> On 2021-10-21 09:08, Yoav Weiss wrote:
>
> LGTM2 to catch up here
>
> (Apparently we have 2 intent emails for this..)
>
> On Thu, Oct 21, 2021 at 3:50 AM TAMURA, Kent  wrote:
>
>> LGTM1.  It's a small straight-forward change.
>>
>>
>>
>> On Thu, Oct 21, 2021 at 12:44 AM  wrote:
>>
>>> Contact emails
>>> ssin...@igalia.com, fw...@chromium.org
>>>
>>> Explainer:
>>> The securitypolicyviolation event is already implemented in all
>>> browsers, one can find document on
>>> MDN(
>>> https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onsecuritypolicyviolation
>>> ,
>>>
>>> https://developer.mozilla.org/en-US/docs/Web/API/Element/securitypolicyviolation_event
>>> ).
>>> The securitypolicyviolation event is dispatched when there is a Content
>>> Security Policy violation. Typically, the JS code of the web component
>>> will listen to securitypolicyviolation events and react with necessary
>>> updates.
>>>
>>> One could just use addEventListener, but for convenience and consistency
>>> with other events (e.g. slotchange) it makes sense to add a IDL
>>> onsecuritypolicyviolation attribute which also reflect the attribute on
>>> elements. We recently shipped slotchange idl attriubte as well
>>> (
>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/cagoIboJ6Oo/m/yje1mcIUBAAJ
>>> )
>>>
>>> Developers are habitual to use EventTarget.onload = ... and >> onload="..."> , but if this does not work for all events, it will be
>>> surprising.
>>>
>>> Currently, the way to listen an event is:
>>> target.addEventListener("securitypolicyviolation", mylistener);
>>>
>>> After this addition an alternative attribute-based form will be
>>> availlable for the developers
>>> element
>>> 
>>>
>>> Doc Link(s):
>>> - https://html.spec.whatwg.org/#handler-onsecuritypolicyviolation
>>> - https://github.com/whatwg/html/pull/2651
>>> - https://chromium-review.googlesource.com/c/chromium/src/+/3226366
>>>
>>> Specification
>>> https://html.spec.whatwg.org
>>>
>>> Summary
>>> The securitypolicyviolation event is fired when a Content Security
>>> Policy is violated.One can listen to that event via the
>>> EventTarget.addEventListener() API. The goal is now to expose the
>>> onsecuritypolicyviolation IDL attribute from the GlobalEventHandlers
>>> interface, so that one can register a listener by attaching this
>>> attribute to target elements.
>>>
>>> Blink component
>>> Blink>DOM
>>>
>>> Motivation
>>> The securitypolicyviolation event is fired when a Content Security
>>> Policy is violated.
>>> One can naturally listen to that event via the
>>> EventTarget.addEventListener() API. However, web developers are also
>>> familiar with the alternative attribute-based form (e.g.
>>> element.addEventListener("securitypolicyviolation
>>> ", ...) Vs on )
>>> which is sometimes convenient for quick testing. For consistency with
>>> other events, an attribute onsecuritypolicyviolation is thus added.
>>>
>>> TAG review
>>> TAG review status
>>> This is just a small change to an existing spec implemented in browsers
>>> and discussed at WHATWG
>>>
>>> Risks
>>> Interoperability and Compatibility
>>>
>>> Gecko:
>>> Shipped/Shipping (https://bugzilla.mozilla.org/show_bug.cgi?id=1727302)
>>>
>>> WebKit:
>>> Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=229381)
>>>
>>> Web developers:
>>> N/A
>>>
>>> Debuggability
>>> No DevTools changes are required, treated like any other
>>> event/attribute.
>>>
>>> Is this feature fully tested by web-platform-tests?
>>> Yes
>>>
>>> Web Platform Tests:
>>> w3c/web-platform-tests/dom/idlharness.window.html
>>>
>>> w3c/web-platform-tests/html/webappapis/scripting/events/event-handler-all-global-events.html
>>>
>>> w3c/web-platform-tests/html/webappapis/scripting/events/event-handler-attributes-body-window-expected.txt
>>>
>>>
>>> w3c/web-platform-tests/mathml/relations/html5-tree/math-global-event-handlers.tentative.html
>>>
>>>
>>> Requires code in //chrome?
>>> False
>>>
>>> Tracking bug
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1242893
>>>
>>> Patch:
>>> https://chromium-review.googlesource.com/c/chromium/src/+/3226366
>>>
>>> Estimated milestones
>>> -
>>>
>>> Link to entry on the Chrome Platform Status
>>> https://www.chromestatus.com/features/5639484386312192
>>>
>>> --
>>> 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
>>>

Re: [blink-dev] Re: Intent to Deprecate: TLS 1.0 and TLS 1.1

2021-10-27 Thread Slade Watkins

Hi all,
The other possibility could be OS related. I've had this issue with
Chromium on old versions macOS specifically, though I've seen it happen on
Windows too.

Claire - what version of your operating system are you running?

Cheers,
 -slade


On Wed, Oct 27, 2021 at 10:50 AM David Benjamin 
wrote:

> Google servers have long supported TLS 1.2, so there is probably some
> (very) outdated antivirus or proxy on your computer or network that has
> been configured to decrypt your encrypted browsing activity. You'll want to
> either disable that or get it updated.
>
> If this doesn't ring a bell, we can try to help you identify the
> antivirus/proxy: file a bug at https://crbug.com/new and attach a NetLog
> per these instructions.
> https://www.chromium.org/for-testers/providing-network-details
>
> On Wed, Oct 27, 2021 at 4:54 AM Claire Miravalles <
> clairemiravalle...@gmail.com> wrote:
>
>>
>> Hi. I would like to know that all of my google services on browser in my
>> pc has some problems regarding this. I can't open google forms,
>> spreadsheets and even my drive has a warning signs of
>> NET:ERR_SSL_OBSOLUTE_VERSION . How will it be fix? Can you help me?
>> On Wednesday, October 17, 2018 at 5:15:10 AM UTC+8 David Benjamin wrote:
>>
>>> (This was announced as a blog post
>>> 
>>> yesterday.)
>>>
>>> Primary eng (and PM) emails
>>>
>>> davi...@chromium.org
>>>
>>> awha...@chromium.org
>>>
>>> Summary
>>>
>>> Deprecate TLS 1.0 and 1.1 in Chrome, targeting removal in Chrome 81
>>> (early 2020). During the deprecation period, sites using those protocols
>>> will show a warning in DevTools. After which, they will fail to connect if
>>> they have not upgraded to TLS 1.2 by then.
>>>
>>> Motivation
>>>
>>> TLS (Transport Layer Security) is the protocol which secures HTTPS. It
>>> has a long history stretching back to the nearly twenty-year-old TLS 1.0
>>> and its even older predecessor, SSL. TLS 1.2
>>> , published ten years ago,
>>> addresses several weaknesses in TLS 1.0 and 1.1:
>>>
>>>
>>>-
>>>
>>>TLS 1.0 and 1.1 use MD5 and SHA-1, both weak hashes, in the
>>>transcript hash for the Finished message. TLS 1.2 switches this to SHA-2.
>>>(See the SLOTH  attack.)
>>>-
>>>
>>>TLS 1.0 and 1.1 use MD5 and SHA-1 in the server signature (note this
>>>is not the signature in the certificate). TLS 1.2 makes this negotiable 
>>> and
>>>adds SHA-2 as an option. (Also see the SLOTH
>>> attack.)
>>>-
>>>
>>>TLS 1.0 and 1.1 only support RC4 and CBC ciphers. RC4 is broken
>>> and has since been removed. TLS’s
>>>CBC mode construction is flawed and was vulnerable to a series of 
>>> attacks,
>>>most recently Lucky13 .
>>>TLS 1.2 introduces AEAD
>>>-based
>>>ciphers which avoid this and are more efficient.
>>>-
>>>
>>>TLS 1.0’s CBC ciphers additionally construct their initialization
>>>vectors incorrectly, making them vulnerable to the BEAST
>>>
>>>attack. TLS 1.1 fixed this.
>>>
>>>
>>> Supporting TLS 1.2 is a prerequisite to avoiding the above problems.
>>> Additionally, the industry has been moving towards this deprecation. TLS
>>> 1.0 is no longer PCI-DSS compliant
>>> 
>>> and the TLS working group has adopted a document
>>> 
>>> to deprecate TLS 1.0 and 1.1.
>>>
>>> Interoperability and Compatibility Risk
>>>
>>> Once removed, sites that only support TLS 1.0 or 1.1 will fail to
>>> connect. The current usage is a little high (0.5%, see below), but we are
>>> providing an extended deprecation period. The target removal date is Chrome
>>> 81, due early 2020. Additionally, other browsers are also deprecating these
>>> protocols:
>>>
>>> Edge: Supported, positive to removal
>>> 
>>>
>>> Firefox: Supported, positive to removal
>>> 
>>>
>>> Safari: Supported, positive to removal
>>> 
>>>
>>> Enterprise deployments can preview the TLS 1.0 and 1.1 removal today by
>>> setting the SSLVersionMin policy to “tls1.2”. For enterprise deployments
>>> that need more time, this same policy can be used to re-enable TLS 1.0 or
>>> TLS 1.1 until January 2021.
>>>
>>> Alternative implementation suggestion for web developers
>>>
>>> Sites should enable TLS

[blink-dev] Re: Intent to Deprecate: TLS 1.0 and TLS 1.1

2021-10-27 Thread Claire Miravalles


Hi. I would like to know that all of my google services on browser in my pc 
has some problems regarding this. I can't open google forms, spreadsheets 
and even my drive has a warning signs of NET:ERR_SSL_OBSOLUTE_VERSION . How 
will it be fix? Can you help me?
On Wednesday, October 17, 2018 at 5:15:10 AM UTC+8 David Benjamin wrote:

> (This was announced as a blog post 
>  
> yesterday.)
>
> Primary eng (and PM) emails
>
> davi...@chromium.org
>
> awha...@chromium.org
>
> Summary
>
> Deprecate TLS 1.0 and 1.1 in Chrome, targeting removal in Chrome 81 (early 
> 2020). During the deprecation period, sites using those protocols will show 
> a warning in DevTools. After which, they will fail to connect if they have 
> not upgraded to TLS 1.2 by then.
>
> Motivation
>
> TLS (Transport Layer Security) is the protocol which secures HTTPS. It has 
> a long history stretching back to the nearly twenty-year-old TLS 1.0 and 
> its even older predecessor, SSL. TLS 1.2 
> , published ten years ago, addresses 
> several weaknesses in TLS 1.0 and 1.1:
>
>
>- 
>
>TLS 1.0 and 1.1 use MD5 and SHA-1, both weak hashes, in the transcript 
>hash for the Finished message. TLS 1.2 switches this to SHA-2. (See the 
>SLOTH  attack.)
>- 
>
>TLS 1.0 and 1.1 use MD5 and SHA-1 in the server signature (note this 
>is not the signature in the certificate). TLS 1.2 makes this negotiable 
> and 
>adds SHA-2 as an option. (Also see the SLOTH 
> attack.)
>- 
>
>TLS 1.0 and 1.1 only support RC4 and CBC ciphers. RC4 is broken 
> and has since been removed. TLS’s CBC 
>mode construction is flawed and was vulnerable to a series of attacks, 
> most 
>recently Lucky13 . TLS 1.2 
>introduces AEAD 
>-based ciphers 
>which avoid this and are more efficient.
>- 
>
>TLS 1.0’s CBC ciphers additionally construct their initialization 
>vectors incorrectly, making them vulnerable to the BEAST 
> 
>attack. TLS 1.1 fixed this.
>
>
> Supporting TLS 1.2 is a prerequisite to avoiding the above problems. 
> Additionally, the industry has been moving towards this deprecation. TLS 
> 1.0 is no longer PCI-DSS compliant 
> 
>  
> and the TLS working group has adopted a document 
>  to 
> deprecate TLS 1.0 and 1.1.
>
> Interoperability and Compatibility Risk
>
> Once removed, sites that only support TLS 1.0 or 1.1 will fail to connect. 
> The current usage is a little high (0.5%, see below), but we are providing 
> an extended deprecation period. The target removal date is Chrome 81, due 
> early 2020. Additionally, other browsers are also deprecating these 
> protocols:
>
> Edge: Supported, positive to removal 
> 
>
> Firefox: Supported, positive to removal 
> 
>
> Safari: Supported, positive to removal 
> 
>
> Enterprise deployments can preview the TLS 1.0 and 1.1 removal today by 
> setting the SSLVersionMin policy to “tls1.2”. For enterprise deployments 
> that need more time, this same policy can be used to re-enable TLS 1.0 or 
> TLS 1.1 until January 2021.
>
> Alternative implementation suggestion for web developers
>
> Sites should enable TLS 1.2 or later. We also encourage all sites to 
> revisit their TLS configuration. Our current criteria for modern TLS is the 
> following:
>
>
>- 
>
>TLS 1.2 or later.
>- 
>
>An ECDHE- and AEAD-based cipher suite. AEAD-based cipher suites are 
>those using AES-GCM or ChaCha20-Poly1305. 
> ECDHE_RSA_WITH_AES_128_GCM_SHA256 
>is the recommended option for most sites.
>- 
>
>The server signature should use SHA-2. Note this is not the signature 
>in the certificate, made by the CA. Rather, it is the signature made by 
> the 
>server itself, using its private key.
>
>
> The older options—CBC-mode cipher suites, RSA-encryption key exchange, and 
> SHA-1 server signatures—all have known cryptographic flaws. Each has been 
> removed in the newly-published TLS 1.3 
> . We retain them at prior versions 
> for compatibility with legacy servers, but we will be evaluating them over 
> time for eventual deprecation.
>
> Note that supporting TLS

[blink-dev] Re: Intent to implement: WebRTC SVC extensions

2021-10-27 Thread pablo platt

Any update?

On Thursday, August 8, 2019 at 10:20:00 PM UTC+3 gur...@microsoft.com wrote:

> LGTM. In the past Microsoft Edge has supported this for H.264 via ORTC and 
> really helped for conferencing scenarios especially on low end devices with 
> limited resources. Look forward to this!
>
>
> On Sunday, July 21, 2019 at 7:04:06 AM UTC-7, Harald Alvestrand wrote:
>>
>> Contact emails
>>
>> exa...@example.com, exam...@example.com 
>>
>> Explainer
>>
>> None - the spec at https://w3c.github.io/webrtc-svc/ is pretty 
>> self explanatory.
>>
>> Design doc/Spec
>>
>> https://w3c.github.io/webrtc-svc/
>>
>>
>> The WEBRTC WG chairs have been asked about triggering the TAG review 
>> process.
>>
>> Summary
>>
>> Implement Scalable Video Coding (SVC) controls for WebRTC.
>>
>>
>> Motivation
>>
>> Many video codecs (VP8, VP9, AV1, H264-SVC) have modes that allow an 
>> encoder to send out video data in such a format that it's possible to strip 
>> out certain packets from the stream and reconstruct a lower quality video 
>> stream from the result. This makes providing video at differing qualities 
>> to multiple destinations for the same video stream easier, which is a Good 
>> Thing in conferencing scenarios.
>>
>> This extension allows a standard control surface for picking between 
>> possible SVC configurations.
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> Describe the degree of interoperability and compatibility risk 
>> .
>>  
>> For a new feature, the main risk is that it fails to become an 
>> interoperable part of the web platform if other browsers do not implement 
>> it. For a removal, please review our principles of web compatibility 
>> 
>> .
>>
>> Edge: No signals, spec editor from Microsoft.
>>
>> Firefox: No signals.
>>
>> Safari: No signals.
>>
>> Web / Framework developers: Meetecho developers are positive.
>>
>>
>> Ergonomics
>>
>> This will be used by people using WebRTC RTCPeerConnection
>>
>> in videoconferencing scenarios.
>>
>> Activation
>>
>> This feature can't be polyfilled. Detecting the feature is easy.
>>
>> Debuggability
>>
>> No special considerations.
>>
>> We should consider showing video configuration in 
>> chrome://webrtc-internals, but this is not required for shipping.
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac, 
>> Linux, Chrome OS, Android, and Android WebView)?
>>
>> Yes.
>>
>>
>> Link to entry on the feature dashboard 
>>
>>
>> https://www.chromestatus.com/feature/5769626174619648
>>
>>
>>
>> Requesting approval to ship?
>>
>> No.
>>
>

-- 
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/7e40f9dc-223d-4260-a6a2-1880f2d4accfn%40chromium.org.

Re: [blink-dev] Re: Intent to Deprecate: TLS 1.0 and TLS 1.1

2021-10-27 Thread David Benjamin

No, the TLS version negotiated should not be OS-dependent. Chrome does not
use the OS's TLS stack. If you're seeing an issue that's specific to an
older version, could you file a bug so we can take a look? Perhaps you have
an antivirus or other local proxy that has been configured to terminate TLS
(i.e. decrypt and inspect all your browsing activity), and that proxy uses
the OS's TLS stack.

On Wed, Oct 27, 2021 at 11:49 AM Slade Watkins 
wrote:

> Hi all,
> The other possibility could be OS related. I've had this issue with
> Chromium on old versions macOS specifically, though I've seen it happen on
> Windows too.
>
> Claire - what version of your operating system are you running?
>
> Cheers,
>  -slade
>
>
> On Wed, Oct 27, 2021 at 10:50 AM David Benjamin 
> wrote:
>
>> Google servers have long supported TLS 1.2, so there is probably some
>> (very) outdated antivirus or proxy on your computer or network that has
>> been configured to decrypt your encrypted browsing activity. You'll want to
>> either disable that or get it updated.
>>
>> If this doesn't ring a bell, we can try to help you identify the
>> antivirus/proxy: file a bug at https://crbug.com/new and attach a NetLog
>> per these instructions.
>> https://www.chromium.org/for-testers/providing-network-details
>>
>> On Wed, Oct 27, 2021 at 4:54 AM Claire Miravalles <
>> clairemiravalle...@gmail.com> wrote:
>>
>>>
>>> Hi. I would like to know that all of my google services on browser in my
>>> pc has some problems regarding this. I can't open google forms,
>>> spreadsheets and even my drive has a warning signs of
>>> NET:ERR_SSL_OBSOLUTE_VERSION . How will it be fix? Can you help me?
>>> On Wednesday, October 17, 2018 at 5:15:10 AM UTC+8 David Benjamin wrote:
>>>
 (This was announced as a blog post

 yesterday.)

 Primary eng (and PM) emails

 davi...@chromium.org

 awha...@chromium.org

 Summary

 Deprecate TLS 1.0 and 1.1 in Chrome, targeting removal in Chrome 81
 (early 2020). During the deprecation period, sites using those protocols
 will show a warning in DevTools. After which, they will fail to connect if
 they have not upgraded to TLS 1.2 by then.

 Motivation

 TLS (Transport Layer Security) is the protocol which secures HTTPS. It
 has a long history stretching back to the nearly twenty-year-old TLS 1.0
 and its even older predecessor, SSL. TLS 1.2
 , published ten years ago,
 addresses several weaknesses in TLS 1.0 and 1.1:

-

TLS 1.0 and 1.1 use MD5 and SHA-1, both weak hashes, in the
transcript hash for the Finished message. TLS 1.2 switches this to 
 SHA-2.
(See the SLOTH  attack.)
-

TLS 1.0 and 1.1 use MD5 and SHA-1 in the server signature (note
this is not the signature in the certificate). TLS 1.2 makes this
negotiable and adds SHA-2 as an option. (Also see the SLOTH
 attack.)
-

TLS 1.0 and 1.1 only support RC4 and CBC ciphers. RC4 is broken
 and has since been removed. TLS’s
CBC mode construction is flawed and was vulnerable to a series of 
 attacks,
most recently Lucky13 .
TLS 1.2 introduces AEAD
-based
ciphers which avoid this and are more efficient.
-

TLS 1.0’s CBC ciphers additionally construct their initialization
vectors incorrectly, making them vulnerable to the BEAST

attack. TLS 1.1 fixed this.

 Supporting TLS 1.2 is a prerequisite to avoiding the above problems.
 Additionally, the industry has been moving towards this deprecation. TLS
 1.0 is no longer PCI-DSS compliant

 and the TLS working group has adopted a document

 to deprecate TLS 1.0 and 1.1.

 Interoperability and Compatibility Risk

 Once removed, sites that only support TLS 1.0 or 1.1 will fail to
 connect. The current usage is a little high (0.5%, see below), but we are
 providing an extended deprecation period. The target removal date is Chrome
 81, due early 2020. Additionally, other browsers are also deprecating these
 protocols:

 Edge: Supported, positive to removal

 Firefox: Supported, positive to removal

[blink-dev] Re: Intent to Deprecate: TLS 1.0 and TLS 1.1

2021-10-27 Thread David Benjamin

Google servers have long supported TLS 1.2, so there is probably some
(very) outdated antivirus or proxy on your computer or network that has
been configured to decrypt your encrypted browsing activity. You'll want to
either disable that or get it updated.

If this doesn't ring a bell, we can try to help you identify the
antivirus/proxy: file a bug at https://crbug.com/new and attach a NetLog
per these instructions.
https://www.chromium.org/for-testers/providing-network-details

On Wed, Oct 27, 2021 at 4:54 AM Claire Miravalles <
clairemiravalle...@gmail.com> wrote:

>
> Hi. I would like to know that all of my google services on browser in my
> pc has some problems regarding this. I can't open google forms,
> spreadsheets and even my drive has a warning signs of
> NET:ERR_SSL_OBSOLUTE_VERSION . How will it be fix? Can you help me?
> On Wednesday, October 17, 2018 at 5:15:10 AM UTC+8 David Benjamin wrote:
>
>> (This was announced as a blog post
>> 
>> yesterday.)
>>
>> Primary eng (and PM) emails
>>
>> davi...@chromium.org
>>
>> awha...@chromium.org
>>
>> Summary
>>
>> Deprecate TLS 1.0 and 1.1 in Chrome, targeting removal in Chrome 81
>> (early 2020). During the deprecation period, sites using those protocols
>> will show a warning in DevTools. After which, they will fail to connect if
>> they have not upgraded to TLS 1.2 by then.
>>
>> Motivation
>>
>> TLS (Transport Layer Security) is the protocol which secures HTTPS. It
>> has a long history stretching back to the nearly twenty-year-old TLS 1.0
>> and its even older predecessor, SSL. TLS 1.2
>> , published ten years ago,
>> addresses several weaknesses in TLS 1.0 and 1.1:
>>
>>
>>-
>>
>>TLS 1.0 and 1.1 use MD5 and SHA-1, both weak hashes, in the
>>transcript hash for the Finished message. TLS 1.2 switches this to SHA-2.
>>(See the SLOTH  attack.)
>>-
>>
>>TLS 1.0 and 1.1 use MD5 and SHA-1 in the server signature (note this
>>is not the signature in the certificate). TLS 1.2 makes this negotiable 
>> and
>>adds SHA-2 as an option. (Also see the SLOTH
>> attack.)
>>-
>>
>>TLS 1.0 and 1.1 only support RC4 and CBC ciphers. RC4 is broken
>> and has since been removed. TLS’s
>>CBC mode construction is flawed and was vulnerable to a series of attacks,
>>most recently Lucky13 .
>>TLS 1.2 introduces AEAD
>>-based
>>ciphers which avoid this and are more efficient.
>>-
>>
>>TLS 1.0’s CBC ciphers additionally construct their initialization
>>vectors incorrectly, making them vulnerable to the BEAST
>>
>>attack. TLS 1.1 fixed this.
>>
>>
>> Supporting TLS 1.2 is a prerequisite to avoiding the above problems.
>> Additionally, the industry has been moving towards this deprecation. TLS
>> 1.0 is no longer PCI-DSS compliant
>> 
>> and the TLS working group has adopted a document
>>  to
>> deprecate TLS 1.0 and 1.1.
>>
>> Interoperability and Compatibility Risk
>>
>> Once removed, sites that only support TLS 1.0 or 1.1 will fail to
>> connect. The current usage is a little high (0.5%, see below), but we are
>> providing an extended deprecation period. The target removal date is Chrome
>> 81, due early 2020. Additionally, other browsers are also deprecating these
>> protocols:
>>
>> Edge: Supported, positive to removal
>> 
>>
>> Firefox: Supported, positive to removal
>> 
>>
>> Safari: Supported, positive to removal
>> 
>>
>> Enterprise deployments can preview the TLS 1.0 and 1.1 removal today by
>> setting the SSLVersionMin policy to “tls1.2”. For enterprise deployments
>> that need more time, this same policy can be used to re-enable TLS 1.0 or
>> TLS 1.1 until January 2021.
>>
>> Alternative implementation suggestion for web developers
>>
>> Sites should enable TLS 1.2 or later. We also encourage all sites to
>> revisit their TLS configuration. Our current criteria for modern TLS is the
>> following:
>>
>>
>>-
>>
>>TLS 1.2 or later.
>>-
>>
>>An ECDHE- and AEAD-based cipher suite. AEAD-based cipher suites are
>>those using AES-GCM or ChaCha20-Poly1305. 
>> ECDHE_RSA_WITH_AES_128_GCM_SHA256
>>is the recommended option for most sites.
>>-
>>
>>The server signature

[blink-dev] Re: Intent to Ship: CSS Color Adjust: 'only' keyword for color-scheme

2021-10-27 Thread Rune Lillesveen

On Wed, Oct 27, 2021 at 4:09 PM Rune Lillesveen 
wrote:

>
> Debuggability
>
> The existing property and the new keyword should automatically be
> supported in devtools. There is possibly a need for force dark /
> color-scheme override debugging support in devtools, but that is out of
> scope for this minor change.
>

TIL: https://developer.chrome.com/blog/new-in-devtools-96/#auto-dark-mode

-- 
Rune Lillesveen

-- 
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/CACuPfeSt-wm674DzO%3DOv8Njoqv9NBSi-7X3u6rmvKfc5bLh9NQ%40mail.gmail.com.

[blink-dev] Intent to Ship: CSS Color Adjust: 'only' keyword for color-scheme

2021-10-27 Thread Rune Lillesveen

Contact emailsfuth...@chromium.org

Specificationhttps://drafts.csswg.org/css-color-adjust/#color-scheme-prop

Summary

The 'only' keyword has been re-added to the specification for color-scheme
as a way of per-element opt-out of color-scheme override like forced
darkening.

Previously, both declarations below would force the div element into
color-scheme dark and apply forced darkening. With this change, the second
declaration would opt-out of forced darkening and keep the used
color-scheme 'light'.

div { color-scheme: light } div { color-scheme: only light } will keep the
color-scheme for the element light and opt-out of forced darkening.

This feature is already enabled as part of an original trial in M96:
https://chromestatus.com/features/5672533924773888

Blink componentBlink>CSS

TAG reviewN/A Change to existing API already covered by CSS spec

TAG review statusNot applicable

Risks

Interoperability and Compatibility

Low risk: WebView has shipped forced darkening. This change means content
loaded in WebViews may opt out of forced darkening with "color-scheme: only
light;" where it previously would see 'only' as an unrecognized
color-scheme and for 'light' into 'dark'. Low risk: Making 'only' a
recognized keyword instead of a color-scheme means the parser will no
longer accept multiple instances of 'only' in the same declaration, so
declarations like this will be dropped: div { color-scheme: only only dark
} WebKit already recognized 'only' as an opt-out of forced darkening
keyword.

Gecko: In development (https://bugzilla.mozilla.org/show_bug.cgi?id=1576289)
Development of the color-scheme property in progress. At least blocker
issues are being fixed.

WebKit: Shipped/Shipping

Web developers: No signals

Debuggability

The existing property and the new keyword should automatically be supported
in devtools. There is possibly a need for force dark / color-scheme
override debugging support in devtools, but that is out of scope for this
minor change.

Is this feature fully tested by web-platform-tests

?Yes

Changes made to tests under
https://wpt.fyi/results/css/css-color-adjust/parsing to account for spec
changes for 'only'.

Web platform tests do not support running with color-scheme overrides. A
couple of Blink-specific rendering tests have been added to run under
virtual/dark-mode-*

Flag nameCSSColorSchemeOnly (Blink runtime flag)

Requires code in //chrome?False

Tracking bughttps://crbug.com/1224806

Estimated milestones
DevTrial on desktop 96
DevTrial on android 96
DevTrial on Webview 96

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

This intent message was generated by Chrome Platform Status
.

--
Rune Lillesveen

--
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/CACuPfeRTvY%3DTtDB_S41JApSPhEOGgTc%2BFPZKBVUAQFGPsTLR9A%40mail.gmail.com.

Re: [blink-dev] Intent to Extend Experiment: Capture Handle

2021-10-27 Thread 'Elad Alon' via blink-dev

Thank you, Yoav, for this suggestion about resetting the clock. We would 
like to now do just that, pausing the experiment 2021-11-01 to 2021-11-21, 
and restarting it again on 2021-11-22. We would like to experiment for 4 
milestones (96 to 99, inclusive). However, if it's possible to also have 
the experiment active for older milestones during this time, that would be 
nice, too.

On Friday, August 20, 2021 at 6:44:10 AM UTC+2 yoav...@chromium.org wrote:

> LGTM to continue experimenting.
>
> Note that it might be worthwhile to stop the experiment at some point, as 
> that could "reset the clock" in terms of burn-in risk, and enable an 
> overall longer experimentation period.
>
> On Tuesday, August 17, 2021 at 3:41:14 PM UTC+2 Elad Alon wrote:
>
>> Thanks, Yoav.
>> Yes, I intend to formally reach out to Mozilla and Apple soon.
>> Agreed about strong positive signals from developers.
>>
>> On Tuesday, August 17, 2021 at 10:56:26 AM UTC+2 yoav...@chromium.org 
>> wrote:
>>
>>> On Mon, Aug 16, 2021 at 11:42 PM 'Elad Alon' via blink-dev <
>>> blin...@chromium.org> wrote:
>>>
 Contact emailselad...@chromium.org

 Explainerhttps://github.com/WICG/capture-handle/blob/main/README.md

 Specificationhttps://wicg.github.io/capture-handle/

 Summary

 We introduce a mechanism that allows an application to opt-in to 
 exposing certain information to other applications which are 
 video-capturing it. This allows collaboration between capturing and 
 captured applications. For example, a VC application that's 
 video-capturing 
 a tab where a presentation application lives, could expose user-facing 
 controls in the VC tab for navigating the presentation in the captured 
 tab. 

 Blink componentBlink>GetUserMedia>Tab 

 TAG reviewhttps://github.com/w3ctag/design-reviews/issues/645

 TAG review statusPending

 Risks

 Interoperability and Compatibility

 Gecko: No signal

 WebKit: No signal

>>> Have we reached out? https://bit.ly/blink-signals is not required for 
>>> an experiment, but may be good to reach out nevertheless.
>>>
>>>
 Web developers: No signals

>>>
>>> I'd say 
>>> https://discourse.wicg.io/t/proposal-capture-handle-bootstrap-app-collaboration-when-screensharing/5354/
>>>  
>>> gives you a strong positive signal..
>>>  
>>>

 Reason this experiment is being extended

 Enthusiastic support for the feature: 
 https://discourse.wicg.io/t/proposal-capture-handle-bootstrap-app-collaboration-when-screensharing/5354

 Efforts to build useful features on top of this new API are still ongoing.
 Request extension m95-m97 (three months).
 Debuggability

 No DevTools support is needed.

 Will this feature be supported on all six Blink platforms (Windows, 
 Mac, Linux, Chrome OS, Android, and Android WebView)?

 Supported on all Desktop platforms. Not supported on any Mobile 
 platform.

 Is this feature fully tested by web-platform-tests 

 ?No

 Flag nameCaptureHandle

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

 Launch bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1200907

 Estimated milestones
 OriginTrial desktop first 92
 OriginTrial desktop last 94Request extension m95-m97 (three months).

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

 Links to previous Intent discussionsIntent to prototype: 
 https://groups.google.com/a/chromium.org/g/blink-dev/c/yLTykllpNmI
 Intent to Experiment: 
 https://groups.google.com/a/chromium.org/g/blink-dev/c/RKONugfoGwM/m/mpFizHPxAwAJ

 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+...@chromium.org.
>>>
>>>
 To view this discussion on the web visit 
 https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMO6jDOMkgjL_HUMohx4hk7tbC__M53aX3NEiGxeTPfw8nJUHw%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.

[blink-dev] Intent to Experiment: Web app launch handler

2021-10-27 Thread Alan Cutter

Contact emailsalancut...@chromium.org, mgi...@chromium.org

Explainerhttps://github.com/WICG/sw-launch/blob/main/launch_handler.md

Summary

Adds a "launch_handler" app manifest member that enables web apps to
customise their launch behaviour across all types of app launch triggers.
Example usage: { "name": "Example app", "start_url": "/index.html",
"launch_handler": { "route_to": "existing", "navigate_existing_client":
"always" } } This will cause all launches of the Example app to focus an
existing app window and navigate it (if it exists) instead of always
launching a new app window.


Blink componentBlink>AppManifest


Search tagsweb app ,
pwa , link capturing
, link handling
, launch


TAG reviewhttps://github.com/w3ctag/design-reviews/issues/683

TAG review statusPending

Risks


Interoperability and Compatibility



Gecko: No signal 

WebKit:

Web developers: Strong positive signals on the Declarative Link Capturing
origin trial

which
has overlapping behaviour with this API (which is replacing DLC).


Goals for experimentation

Replace the Declarative Link Capturing

API experiment and gather feedback on the "navigate_existing_client":
"never" behaviour as it gets an implementation.

Ongoing technical constraints

Overlap with the Declarative Link Capturing origin trial
 to
enable existing clients to migrate over to this new API.

Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, Chrome OS, Android, and Android WebView)?Windows, Mac, Linux and
Chrome OS.

Is this feature fully tested by web-platform-tests

?No, this requires browser tests

.

Flag nameWebAppEnableLaunchHandler
chrome://flags/#enable-desktop-pwas-launch-handler

Requires code in //chrome?True

Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1231886

Launch bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1247817

Estimated milestones

M97


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

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/g/blink-dev/c/8tNe2jrJ78A


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/CANJJ2Cm5RFDLAf7n5eRhgHbgioCUe8uv16Sh5v5BSoMgSdKJrw%40mail.gmail.com.

Re: [blink-dev] Intent to Prototype: Capability Delegation

2021-10-27 Thread 'Jun Kokatsu' via blink-dev

This is spec is probably written with the assumption that Permission 
Delegation 

is implemented (or should be implemented) in all browsers. However, 
Permission Delegation is not a Web Standard, and browsers (and other user 
agent) are free to implement any sort of permission model.

For example, a browser without Permission Delegation would require 
permission prompt from iframe (which contains origin of iframe in the 
prompt) in order to use any permission-based API. Permission Policy or 
allow attribute are just there to allow permission request from iframes, 
but that doesn't necessary mean that permission is delegated directly to 
iframe. 

If you try to ship Capability Delegation API in above model, this would be 
a bypass of permission prompt or delegating permission to cross-origin 
iframes without user's knowledge.

Thanks,

Jun

On Monday, July 12, 2021 at 9:31:24 AM UTC-7 Mustaq Ahmed wrote:

> A few quick updates:
> - The WICG/capability-delegation 
>  repository is the current 
> home for the explainer and a spec draft 
> .
> - Please use a new/existing issue 
>  for any comments 
> or suggestions.
> - We filed a TAG review request 
>  two weeks ago.
>
>
>
> On Wed, Nov 18, 2020 at 5:01 PM Mustaq Ahmed  wrote:
>
>> Hi Daniel:
>>
>> Sorry for the delay, thanks for listing those concerns.
>>
>> I have added a Privacy and security considerations 
>> 
>>  section 
>> in the design doc to address three of the concerns, please take a look and 
>> let us know if we missed anything.  I haven't yet replied to the Spectre 
>> point, I need to fully understand the attack vector you are thinking of.
>>
>> The relation to Feature/Permission Policy is still an open question, we 
>> will need some time to answer this.
>>
>> Mustaq
>>
>>
>> On Fri, Nov 6, 2020 at 12:04 PM Daniel Vogelheim  
>> wrote:
>>
>>> Hello Mustaq,
>>>
>>> We've discussed your intent within security + privacy teams. The 
>>> discussion raised a number of concerns, but we couldn't find enough detail 
>>> to either substantiate or allay them. This unfortunately makes it difficult 
>>> to give you actionable feedback.
>>>
>>> Our thoughts: This API effectively packages a permission / user 
>>> interaction in a token and allows it to be sent somewhere else, creating a 
>>> permission-capability-thing. This raises a number of questions:
>>>
>>> - The idea of gating functionality on user interaction is to make sure 
>>> that the user understands what they are interacting with. If a user 
>>> interaction is 'packaged' and sent for consumption elsewhere, does this 
>>> still hold? Could a malicious user put the 'packaged' interaction to a 
>>> surprising use?
>>> - Are there limits to where it can be passed to? Could it be passed - 
>>> via a server round-trip - to another site running in the same browser?
>>> - Is there any info on the API that would consume the token?
>>> - The token is unspecified, but seems to follow the pattern of 
>>> 'unguessable secret number'. The problem here is with the Spectre attack 
>>> family, where we've had to change our assumption to assume that any data 
>>> within a process is potentially readable, even by sandboxed code. Under 
>>> this assumption, could the token be read by an unintended recipient?
>>>
>>> We were also a bit unclear on the use cases, and the relationship to 
>>> feature policy.
>>>
>>> Mustaq, could you maybe update the docs to include this type of 
>>> information? We'd like to take a second look at it.
>>>
>>> Thanks,
>>> Daniel
>>>
>>>
>>> On Fri, Oct 23, 2020 at 5:26 PM Mustaq Ahmed  
>>> wrote:
>>>
 Contact emailsmus...@chromium.org

 Explainergithub.com/mustaqahmed/capability-delegation

 SpecificationNone

 Summary

 Capability delegation means allowing a frame to relinquish its ability 
 to call a restricted API and transfer the ability to another (sub)frame it 
 can trust. If an app wants to delegate its ability to call a restricted JS 
 capability (e.g. popups, fullscreen, etc) to a known+trusted third-party 
 frame, the app would utilize a Capability Delegation API to "transfer" the 
 ability to the target frame in a time-constrained manner (unlike static 
 mechanisms like  attributes).

 Blink componentBlink 

 Motivation

 Here are some practical scenarios that would utilize a capability 
 delegation mechanism.

 - Many merchant websites host their online store on their own domain 
 but

Re: [blink-dev] Re: Intent to extend the origin trial: WebTransport over HTTP/3

[blink-dev] Intent to Extend Origin Trial: Subresource loading with Web Bundles

Re: [blink-dev] Re: Intent to Deprecate: TLS 1.0 and TLS 1.1

Re: [blink-dev] RE: [EXTERNAL] Re: Intent to Implement and Ship: Feature policy for Keyboard API

RE: [blink-dev] RE: [EXTERNAL] Re: Intent to Implement and Ship: Feature policy for Keyboard API

Re: [blink-dev] Intent to Deprecate and Remove: WebSQL in third-party contexts

Re: [blink-dev] RE: [EXTERNAL] Re: Intent to Implement and Ship: Feature policy for Keyboard API

Re: [blink-dev] Intent to Prototype and Ship: self.structuredClone

RE: [blink-dev] RE: [EXTERNAL] Re: Intent to Implement and Ship: Feature policy for Keyboard API

[blink-dev] Intent to Prototype and Ship: self.structuredClone

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

Re: [blink-dev] Re: Intent to extend the origin trial: WebTransport over HTTP/3

Re: [blink-dev] Intent to Ship: Standardize existing client hint naming

Re: [blink-dev] Intent to Ship: Standardize existing client hint naming

Re: [blink-dev] Intent to Ship: Independent/Individual Properties for CSS Transforms

Re: [blink-dev] Intent to Implement and Ship : onsecuritypolicyviolation event handler IDL attribute

Re: [blink-dev] Re: Intent to Deprecate: TLS 1.0 and TLS 1.1

[blink-dev] Re: Intent to Deprecate: TLS 1.0 and TLS 1.1

[blink-dev] Re: Intent to implement: WebRTC SVC extensions

Re: [blink-dev] Re: Intent to Deprecate: TLS 1.0 and TLS 1.1

[blink-dev] Re: Intent to Deprecate: TLS 1.0 and TLS 1.1

[blink-dev] Re: Intent to Ship: CSS Color Adjust: 'only' keyword for color-scheme

[blink-dev] Intent to Ship: CSS Color Adjust: 'only' keyword for color-scheme

Re: [blink-dev] Intent to Extend Experiment: Capture Handle

[blink-dev] Intent to Experiment: Web app launch handler

Re: [blink-dev] Intent to Prototype: Capability Delegation

26 matches

Site Navigation

Mail list logo

Footer information