Intent to deprecate and remove: SDES key exchange for WebRTC

233 views
Skip to first unread message

Harald Alvestrand

unread,
Aug 26, 2021, 4:45:47 AM8/26/21
to blink-dev

Contact emails

h...@chromium.org

Explainer

None

Specification

https://www.rfc-editor.org/rfc/rfc8826#section-4.3.1

Summary

The SDES key exchange mechanism for WebRTC has been declared a MUST NOT in the relevant IETF standards since 2013. The SDES specification has been declared Historic by the IETF. Its usage in Chrome has declined significantly over the recent year. This intent is to deprecate and remove this code from Chromium and WebRTC.



Blink component

Blink>WebRTC>Network

Motivation

The reason why SDES is deprecated is that it is a security problem: It exposes session keys to Javascript, which means that entities with access to the negotiation exchange, or with the ability to subvert the Javascript, can decrypt the media sent over the connection.



Initial public proposal



TAG review



TAG review status

Not applicable

Risks



Interoperability and Compatibility



Gecko: No signal

WebKit: No signal

Web developers: No signals


Debuggability

When this feature is removed, people attempting to set up such a connection will fail to do so. This should be easy to diagnose.



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

No

Flag name



Requires code in //chrome?

False

Tracking bug

https://crbug.com/webrtc/11066

Estimated milestones



Link to entry on the Chrome Platform Status

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

This intent message was generated by Chrome Platform Status.

Philipp Hancke

unread,
Aug 26, 2021, 5:05:03 AM8/26/21
to Harald Alvestrand, blink-dev

--
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/CAOqqYVFNbzG24kGbRFT1sMAroU4ifwv%2BpkA0kU2vkmpHFSgDrQ%40mail.gmail.com.

Yoav Weiss

unread,
Aug 26, 2021, 7:11:05 AM8/26/21
to Philipp Hancke, Harald Alvestrand, blink-dev
What would breakage look like? What's the requested timeline for the deprecation part of this?
Any plans for targeted outreach for the remaining users?

On Thu, Aug 26, 2021 at 11:05 AM 'Philipp Hancke' via blink-dev <blin...@chromium.org> wrote:

Impressive decline in usage!
 
Away with it!

Am Do., 26. Aug. 2021 um 10:45 Uhr schrieb 'Harald Alvestrand' via blink-dev <blin...@chromium.org>:

Contact emails

h...@chromium.org

Explainer

None

Specification

https://www.rfc-editor.org/rfc/rfc8826#section-4.3.1

Summary

The SDES key exchange mechanism for WebRTC has been declared a MUST NOT in the relevant IETF standards since 2013. The SDES specification has been declared Historic by the IETF. Its usage in Chrome has declined significantly over the recent year. This intent is to deprecate and remove this code from Chromium and WebRTC.



Blink component

Blink>WebRTC>Network

Motivation

The reason why SDES is deprecated is that it is a security problem: It exposes session keys to Javascript, which means that entities with access to the negotiation exchange, or with the ability to subvert the Javascript, can decrypt the media sent over the connection.



Initial public proposal



TAG review



TAG review status

Not applicable

Risks



Interoperability and Compatibility



Gecko: No signal

WebKit: No signal

Filing for signals may be an overkill here, but are there bugs filed on other implementers asking them to follow?
 

Web developers: No signals


Debuggability

When this feature is removed, people attempting to set up such a connection will fail to do so. This should be easy to diagnose.



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

No

Flag name



Requires code in //chrome?

False

Tracking bug

https://crbug.com/webrtc/11066

Estimated milestones



Link to entry on the Chrome Platform Status

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

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/CAOqqYVFNbzG24kGbRFT1sMAroU4ifwv%2BpkA0kU2vkmpHFSgDrQ%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+...@chromium.org.

Harald Alvestrand

unread,
Aug 26, 2021, 7:34:11 AM8/26/21
to Yoav Weiss, Philipp Hancke, blink-dev
On Thu, Aug 26, 2021 at 1:10 PM Yoav Weiss <yoav...@chromium.org> wrote:
What would breakage look like?

Once the feature is gone (the end state), anyone attempting to set up a connection using SDES will have their session rejected.
Anyone attempting to set the constraint will just have it ignored, like any other unsupported value in a dictionary.

I'm thinking that we should add an intermediate step where anyone attempting to configure SDES has the constructor throw rather than ignoring the member.
 
What's the requested timeline for the deprecation part of this?

I'd like to get the deprecation warning in 95 (stable Oct 19), start throwing in 97 (stable Jan 4), and removing the code entirely in 99 (stable Mar 1).
 
Any plans for targeted outreach for the remaining users?

Only the usual PSA on webrtc-users and discuss-webrtc + word of mouth.

Yoav Weiss

unread,
Aug 26, 2021, 3:29:54 PM8/26/21
to blink-dev, Harald Alvestrand, philipp...@googlemail.com, blink-dev, Yoav Weiss
A few questions raised at the API OWNERS meeting today.

On Thursday, August 26, 2021 at 1:34:11 PM UTC+2 Harald Alvestrand wrote:
On Thu, Aug 26, 2021 at 1:10 PM Yoav Weiss <yoav...@chromium.org> wrote:
What would breakage look like?

Once the feature is gone (the end state), anyone attempting to set up a connection using SDES will have their session rejected.
Anyone attempting to set the constraint will just have it ignored, like any other unsupported value in a dictionary.

OK. Any enterprise risk here? Are you aware of any enterprise apps using this?
  

I'm thinking that we should add an intermediate step where anyone attempting to configure SDES has the constructor throw rather than ignoring the member.

An unhandled exception seems more risky than a silent failure here, right?
Any reason to think console warnings won't be enough?
Is SDES shipped in other browsers? What's the status there?
 
 

Web developers: No signals


Debuggability

When this feature is removed, people attempting to set up such a connection will fail to do so. This should be easy to diagnose.



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

No

Flag name



Requires code in //chrome?

False

Tracking bug

https://crbug.com/webrtc/11066

Estimated milestones



Link to entry on the Chrome Platform Status

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

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+unsubscribe@chromium.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+unsubscribe@chromium.org.

Harald Alvestrand

unread,
Aug 26, 2021, 4:48:01 PM8/26/21
to Yoav Weiss, blink-dev, philipp...@googlemail.com
On Thu, Aug 26, 2021 at 9:29 PM Yoav Weiss <yoav...@chromium.org> wrote:
A few questions raised at the API OWNERS meeting today.

On Thursday, August 26, 2021 at 1:34:11 PM UTC+2 Harald Alvestrand wrote:
On Thu, Aug 26, 2021 at 1:10 PM Yoav Weiss <yoav...@chromium.org> wrote:
What would breakage look like?

Once the feature is gone (the end state), anyone attempting to set up a connection using SDES will have their session rejected.
Anyone attempting to set the constraint will just have it ignored, like any other unsupported value in a dictionary.

OK. Any enterprise risk here? Are you aware of any enterprise apps using this?

I doubt it. There is no real reason for using it; DTLS is safer and simpler to configure.
 
  

I'm thinking that we should add an intermediate step where anyone attempting to configure SDES has the constructor throw rather than ignoring the member.

An unhandled exception seems more risky than a silent failure here, right?
Any reason to think console warnings won't be enough?

The connection won't go through anyway unless both ends of the connection upgrade at the same time; throwing is a failure that is more obvious.
When things fail, I like to have them fail for obvious reasons.
I believe that neither Firefox nor WebKit ever shipped SDES, but I put "no signal" because I haven't checked.
 
 
 

Web developers: No signals


Debuggability

When this feature is removed, people attempting to set up such a connection will fail to do so. This should be easy to diagnose.



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

No

Flag name



Requires code in //chrome?

False

Tracking bug

https://crbug.com/webrtc/11066

Estimated milestones



Link to entry on the Chrome Platform Status

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

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.

--
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.

Chris Harrelson

unread,
Aug 26, 2021, 4:58:51 PM8/26/21
to Harald Alvestrand, Yoav Weiss, blink-dev, philipp...@googlemail.com
On Thu, Aug 26, 2021 at 1:47 PM 'Harald Alvestrand' via blink-dev <blin...@chromium.org> wrote:


On Thu, Aug 26, 2021 at 9:29 PM Yoav Weiss <yoav...@chromium.org> wrote:
A few questions raised at the API OWNERS meeting today.

On Thursday, August 26, 2021 at 1:34:11 PM UTC+2 Harald Alvestrand wrote:
On Thu, Aug 26, 2021 at 1:10 PM Yoav Weiss <yoav...@chromium.org> wrote:
What would breakage look like?

Once the feature is gone (the end state), anyone attempting to set up a connection using SDES will have their session rejected.
Anyone attempting to set the constraint will just have it ignored, like any other unsupported value in a dictionary.

OK. Any enterprise risk here? Are you aware of any enterprise apps using this?

I doubt it. There is no real reason for using it; DTLS is safer and simpler to configure.
 
  

I'm thinking that we should add an intermediate step where anyone attempting to configure SDES has the constructor throw rather than ignoring the member.

An unhandled exception seems more risky than a silent failure here, right?
Any reason to think console warnings won't be enough?

The connection won't go through anyway unless both ends of the connection upgrade at the same time; throwing is a failure that is more obvious.
When things fail, I like to have them fail for obvious reasons.

On the other hand, an unhandled exception will break the whole site, whereas otherwise it'll silently fail and the site will otherwise work.
Could you check and update the status accordingly?
 

Martin Thomson

unread,
Aug 26, 2021, 8:00:43 PM8/26/21
to Chris Harrelson, Harald Alvestrand, Yoav Weiss, blink-dev, philipp...@googlemail.com
Firefox never implemented Security Descriptions. I didn't realise that Chrome did until now. It is prohibited by the spec, so you should definitely cut it.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-JRfZewUFrF_WRO-ban7e2U2T%3DNzCWAfVb2t7hbVTQUA%40mail.gmail.com.

Philipp Hancke

unread,
Aug 27, 2021, 1:31:45 AM8/27/21
to Harald Alvestrand, Yoav Weiss, blink-dev
Am Do., 26. Aug. 2021 um 22:47 Uhr schrieb Harald Alvestrand <h...@google.com>:


On Thu, Aug 26, 2021 at 9:29 PM Yoav Weiss <yoav...@chromium.org> wrote:
A few questions raised at the API OWNERS meeting today.

On Thursday, August 26, 2021 at 1:34:11 PM UTC+2 Harald Alvestrand wrote:
On Thu, Aug 26, 2021 at 1:10 PM Yoav Weiss <yoav...@chromium.org> wrote:
What would breakage look like?

Once the feature is gone (the end state), anyone attempting to set up a connection using SDES will have their session rejected.
Anyone attempting to set the constraint will just have it ignored, like any other unsupported value in a dictionary.

OK. Any enterprise risk here? Are you aware of any enterprise apps using this?

I doubt it. There is no real reason for using it; DTLS is safer and simpler to configure.

I bet there are some callcenters using it on the agent side and being callcenters, they won't report metrics.
The list of vendors is known though. As is the IETF 2013 consensus that this is a MUST NOT.
 
  

I'm thinking that we should add an intermediate step where anyone attempting to configure SDES has the constructor throw rather than ignoring the member.

An unhandled exception seems more risky than a silent failure here, right?
Any reason to think console warnings won't be enough?

The connection won't go through anyway unless both ends of the connection upgrade at the same time; throwing is a failure that is more obvious.
When things fail, I like to have them fail for obvious reasons.

The existing behaviour of throwing in setRemoteDescription when receiving an SDES-only offer seems good (and works in both Chrome and Firefox).
The error code might need some work, it differs between Chrome and Firefox.

We have some test coverage for this:
I'll add a negative assertion as a WPT. Why ask when you can write a test :-)
 

Yoav Weiss

unread,
Aug 27, 2021, 2:22:10 AM8/27/21
to Philipp Hancke, Harald Alvestrand, blink-dev
On Fri, Aug 27, 2021 at 7:31 AM Philipp Hancke <philipp...@googlemail.com> wrote:
Am Do., 26. Aug. 2021 um 22:47 Uhr schrieb Harald Alvestrand <h...@google.com>:


On Thu, Aug 26, 2021 at 9:29 PM Yoav Weiss <yoav...@chromium.org> wrote:
A few questions raised at the API OWNERS meeting today.

On Thursday, August 26, 2021 at 1:34:11 PM UTC+2 Harald Alvestrand wrote:
On Thu, Aug 26, 2021 at 1:10 PM Yoav Weiss <yoav...@chromium.org> wrote:
What would breakage look like?

Once the feature is gone (the end state), anyone attempting to set up a connection using SDES will have their session rejected.
Anyone attempting to set the constraint will just have it ignored, like any other unsupported value in a dictionary.

OK. Any enterprise risk here? Are you aware of any enterprise apps using this?

I doubt it. There is no real reason for using it; DTLS is safer and simpler to configure.

I bet there are some callcenters using it on the agent side and being callcenters, they won't report metrics.
The list of vendors is known though. As is the IETF 2013 consensus that this is a MUST NOT.

Are there vendors still selling such software nowadays?

Harald Alvestrand

unread,
Aug 31, 2021, 5:31:01 AM8/31/21
to Yoav Weiss, Philipp Hancke, blink-dev
I have now verified that neither Safari nor Firefox ever shipped SDES.

Given Yoav's comments about throwing versus erroring upstream, I'm going to propose going with the "just ignore the dictionary member once it's gone" approach.

Yoav Weiss

unread,
Aug 31, 2021, 8:19:01 AM8/31/21
to Harald Alvestrand, Philipp Hancke, blink-dev
Thanks for verifying!

Given that this was never supported by other browsers, LGTM1 to remove

Chris Harrelson

unread,
Aug 31, 2021, 11:13:58 AM8/31/21
to Yoav Weiss, Harald Alvestrand, Philipp Hancke, blink-dev
LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfU5SOqsi%3DRLqU5UJYW-%2Bq3mRZ3-%2Bt5Bkx9_iPCebyMPCg%40mail.gmail.com.

Manuel Rego Casasnovas

unread,
Sep 1, 2021, 10:52:16 AM9/1/21
to Chris Harrelson, Yoav Weiss, Harald Alvestrand, Philipp Hancke, blink-dev
LGTM3

On 31/08/2021 17:13, Chris Harrelson wrote:
> LGTM2
>
> On Tue, Aug 31, 2021 at 5:18 AM Yoav Weiss <yoav...@chromium.org
> <mailto:yoav...@chromium.org>> wrote:
>
> Thanks for verifying!
>
> Given that this was never supported by other browsers, LGTM1 to remove
>
> On Tue, Aug 31, 2021 at 11:31 AM Harald Alvestrand <h...@google.com
> <mailto:h...@google.com>> wrote:
>
> I have now verified that neither Safari nor Firefox ever shipped
> SDES.
>
> Given Yoav's comments about throwing versus erroring upstream,
> I'm going to propose going with the "just ignore the dictionary
> member once it's gone" approach.
>
>
> On Fri, Aug 27, 2021 at 8:22 AM Yoav Weiss
> <yoav...@chromium.org <mailto:yoav...@chromium.org>> wrote:
>
>
>
> On Fri, Aug 27, 2021 at 7:31 AM Philipp Hancke
> <philipp...@googlemail.com
> <mailto:philipp...@googlemail.com>> wrote:
>
> Am Do., 26. Aug. 2021 um 22:47 Uhr schrieb Harald
> Alvestrand <h...@google.com <mailto:h...@google.com>>:
>
>
>
> On Thu, Aug 26, 2021 at 9:29 PM Yoav Weiss
> <yoav...@chromium.org
> <mailto:yoav...@chromium.org>> wrote:
>
> A few questions raised at the API OWNERS meeting
> today.
>
> On Thursday, August 26, 2021 at 1:34:11 PM UTC+2
> Harald Alvestrand wrote:
>
> On Thu, Aug 26, 2021 at 1:10 PM Yoav Weiss
> <yoav...@chromium.org
> <mailto:blin...@chromium.org>> wrote:
>
> stats here:
> https://www.chromestatus.com/metrics/feature/timeline/popularity/2383
> <https://www.chromestatus.com/metrics/feature/timeline/popularity/2383>
>
>
> Impressive decline in usage!
>  
>
> Away with it!
>
> Am Do., 26. Aug. 2021 um 10:45 Uhr
> schrieb 'Harald Alvestrand' via
> blink-dev <blin...@chromium.org
> <mailto:blin...@chromium.org>>:
>
>
> Contact emails
>
> h...@chromium.org
> <mailto:h...@chromium.org>
>
>
> Explainer
>
> None
>
>
> Specification
>
> https://www.rfc-editor.org/rfc/rfc8826#section-4.3.1
> <https://www.rfc-editor.org/rfc/rfc8826#section-4.3.1>
>
>
> Summary
>
> The SDES key exchange mechanism
> for WebRTC has been declared a
> MUST NOT in the relevant IETF
> standards since 2013. The SDES
> specification has been declared
> Historic by the IETF. Its usage
> in Chrome has declined
> significantly over the recent
> year. This intent is to
> deprecate and remove this code
> from Chromium and WebRTC.
>
>
>
> Blink component
>
> Blink>WebRTC>Network
> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EWebRTC%3ENetwork>
> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>?
>
> No
>
>
> Flag name
>
>
>
> Requires code in //chrome?
>
> False
>
>
> Tracking bug
>
> https://crbug.com/webrtc/11066
> <https://crbug.com/webrtc/11066>
>
>
> Estimated milestones
>
>
>
> Link to entry on the
> Chrome Platform Status
>
> https://www.chromestatus.com/feature/5695324321480704
> <https://www.chromestatus.com/feature/5695324321480704>
>
> This intent message was
> generated by Chrome Platform
> Status
> <https://www.chromestatus.com/>.
>
> --
> You received this message
> because you are subscribed to
> the Google Groups "blink-dev" group.
> To unsubscribe from this group
> and stop receiving emails from
> it, send an email to
> blink-dev+...@chromium.org
> <mailto:blink-dev+...@chromium.org>.
> To view this discussion on the
> web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOqqYVFNbzG24kGbRFT1sMAroU4ifwv%2BpkA0kU2vkmpHFSgDrQ%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOqqYVFNbzG24kGbRFT1sMAroU4ifwv%2BpkA0kU2vkmpHFSgDrQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>
> --
> You received this message because
> you are subscribed to the Google
> Groups "blink-dev" group.
> To unsubscribe from this group and
> stop receiving emails from it, send
> an email to
> blink-dev+...@chromium.org
> <mailto:blink-dev+...@chromium.org>.
> To view this discussion on the web
> visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADxkKiJrgemVNeyGP5bw%3Dp40%2Bwc6Zbxi3q-CRWpqV%2BpU%3Dk8%2BgQ%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADxkKiJrgemVNeyGP5bw%3Dp40%2Bwc6Zbxi3q-CRWpqV%2BpU%3Dk8%2BgQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>
> --
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to blink-dev+...@chromium.org
> <mailto:blink-dev+...@chromium.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfU5SOqsi%3DRLqU5UJYW-%2Bq3mRZ3-%2Bt5Bkx9_iPCebyMPCg%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfU5SOqsi%3DRLqU5UJYW-%2Bq3mRZ3-%2Bt5Bkx9_iPCebyMPCg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>
> --
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to blink-dev+...@chromium.org
> <mailto:blink-dev+...@chromium.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_-nv9RqP4p-3RgJvdUMJDmFsE02LKtgkMuau1qqSEyhA%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_-nv9RqP4p-3RgJvdUMJDmFsE02LKtgkMuau1qqSEyhA%40mail.gmail.com?utm_medium=email&utm_source=footer>.

dxssx dxssx

unread,
Mar 26, 2022, 4:39:55 PM3/26/22
to blink-dev, Harald Alvestrand
Is this the right place to ask question? (I came across from google results)
Just curious about the intention "The reason why SDES is deprecated is that it is a security problem: It exposes session keys to Javascript, which means that entities with access to the negotiation exchange, or with the ability to subvert the Javascript, can decrypt the media sent over the connection."
Is javascript a real concern? IIUC, the new insertable stream will allow javascript to be able to access media and the potential usage of it for E2EE will intentionally let javascript to handle E2EE keys.

Thanks.

Philipp Hancke

unread,
Mar 27, 2022, 5:21:45 AM3/27/22
to dxssx dxssx, discuss...@googlegroups.com, blink-dev, Harald Alvestrand
Am Sa., 26. März 2022 um 21:39 Uhr schrieb dxssx dxssx <dxssx...@gmail.com>:
Is this the right place to ask question? (I came across from google results)

the discuss-webrtc mailing list is a better place (so please remove blink-dev when responding)
 
Just curious about the intention "The reason why SDES is deprecated is that it is a security problem: It exposes session keys to Javascript, which means that entities with access to the negotiation exchange, or with the ability to subvert the Javascript, can decrypt the media sent over the connection."

The decision to not support SDES in WebRTC dates back to an IETF decision from 2013.
has some details and links to the slides.
 
Is javascript a real concern? IIUC, the new insertable stream will allow javascript to be able to access media and the potential usage of it for E2EE will intentionally let javascript to handle E2EE keys.

The concern here is not javascript but exposing the key to signaling servers, passive MITM attacks and retroactive decryption.
DTLS doesn't suffer from those problems, not exposing the encryption keys to Javascript is a bonus here.

--
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/39f67083-8391-4e0a-8f3e-549848adbc73n%40chromium.org.
Reply all
Reply to author
Forward
0 new messages