Re: [blink-dev] Intent to Deprecate and Remove: WebRTC's RTCStats of type "track" and "stream".

['Harald Alvestrand' via blink-dev]

Do we have trackable statistics on the usage of corporate policies?
ie if nobody uses the policy in 2 milestones, can we detect that and decide
that it is not needed and delete it, or will we be as unsure as we are now?


On Mon, Feb 6, 2023 at 9:41 PM Mike Taylor  wrote:

> We don't know what we don't know, but it's not hard to imagine an in-house
> enterprise WebRTC application that is using "stats" or "track". Twilio is
> the breakage we know about (because a developer took the time to report a
> bug). Having a policy so an app continues to work while a fix is made is a
> good thing - and comes with the nice side effect of appearing on the
> Enterprise release notes, increasing awareness.
>
> On 2/4/23 3:28 AM, Harald Alvestrand wrote:
>
> What's the imagined scenario in which an enterprise policy would be
> useful?
>
> The only place I could imagine it being relevant is if there exists a
> WebRTC application that is only used within a single enterprise (neither
> hosting nor usage exists outside the enterprise), and that WebRTC
> application depends on non-upgraded Twilio libraries.
>
> I don't know that we have evidence that such applications exist.
>
>
>
> On Fri, Feb 3, 2023 at 6:14 PM Mike Taylor  wrote:
>
>> I agree with Johnny that an enterprise policy would be useful, at least
>> for a few milestones.
>>
>> On 1/30/23 5:16 AM, 'Harald Alvestrand' via blink-dev wrote:
>>
>> I'm not sure an enterprise policy is appropriate - I see the same problem
>> with sunsetting the policy as with sunsetting the stat in general, and
>> usage of enterprise policies is (as far as I know) far more opaque to us
>> than origin trials or Finch feature usage.
>>
>>
>> On Mon, Jan 30, 2023 at 11:13 AM Henrik Boström 
>> wrote:
>>
>>>
>>>
>>> On Friday, January 27, 2023 at 7:24:58 PM UTC+1 Johnny Stenback wrote:
>>> Is there an enterprise policy in place for this deprecation already? If
>>> not, adding one seems appropriate given the challenges of rolling out even
>>> simple fixes in some enterprise environments.
>>>
>>> One does not exist at the moment but I can add one
>>> <https://chromium.googlesource.com/chromium/src/+/HEAD/docs/enterprise/add_new_policy.md>
>>> .
>>>
>>>
>>> Thanks,
>>> Johnny
>>>
>>> On Fri, Jan 27, 2023 at 5:16 AM Henrik Boström 
>>> wrote:
>>> Delaying the enabled-by-default to M112 is fine by me but I'll wait for
>>> a resolution here before taking action. Currently it is enabled-by-default
>>> in Canary.
>>>
>>> On Friday, January 27, 2023 at 12:41:23 PM UTC+1
>>> philipp...@googlemail.com wrote:
>>> Am Fr., 27. Jan. 2023 um 11:49 Uhr schrieb Henrik Boström <
>>> h...@chromium.org>:
>>> *Contact emails*
>>> h...@chromium.org, h...@chromium.org
>>>
>>> *Background*
>>> I attempted to remove this feature before but had forgotten to file an
>>> intent to deprecate, background here
>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/RsIktnGhHqw/>.
>>>
>>> *Specification*
>>> The getStats() API spec is here <https://w3c.github.io/webrtc-stats/> and
>>> it contains all the metrics. The deprecated metrics are also listed, but in
>>> the obsolete section
>>> <https://w3c.github.io/webrtc-stats/#obsolete-rtcmediastreamtrackstats-members>.
>>> There's an open issue to remove obsolete metrics from the spec as soon as
>>> they are unshipped from modern browsers. This is considered a blocker for
>>> the document to reach Proposed Recommendation status.
>>>
>>> *Summary*
>>> WebRTC is a set of JavaScript APIs (spec
>>> <https://w3c.github.io/webrtc-pc/>) that allow real-time communication
>>> between browsers. For the relevant metrics being removed, we're only
>>> talking about the WebRTC use case that is sending or receiving audio or
>>> video (typically Video Conferencing use cases), not the data channel use
>>> cases that is a popular WebRTC use case, since data channel only use cases
>>> would never have any tracks/streams.
>>>
>>> RTCPeerConnection.getStats() returns a map of string-to-objects, where
>>> each object is one of the dictionaries defined in the stats spec. The
>>> reason an app calls getStats() is mostly to report quality metrics (send
>>> and receive resolutions, bitrates, glitches, video QP, etc) which can be
>>

Re: [blink-dev] Intent to Ship: Support URLs with non-special schemes

['Harald Alvestrand' via blink-dev]

Is there a blacklist of "special schemes" that this change won't touch? Who
maintains that list?

This seems a bit dangerous, in that if a new scheme is deployed that is
"special", code intended for handling non-special schemes will try to parse
it.

Note that the term "special" in the URL specification (
https://url.spec.whatwg.org/#special-scheme) refers strictly to ftp, file,
http, https, ws and wss; there's nothing "special" about urn, turn, stun or
any of the other standardized schemes that don't use the // syntax.




On Wed, Feb 22, 2023 at 5:08 PM Yoav Weiss  wrote:

>
>
> On Wed, Feb 22, 2023 at 4:43 PM Mike Taylor 
> wrote:
>
>>
>> On 2/22/23 8:21 AM, 'Jiacheng Guo' via blink-dev wrote:
>>
>> Contact emails g...@google.com
>>
>> Explainer None
>>
>>
> An explainer (even inline) would be helpful to get a better understanding
> of what this change does.
> Does it impact only URL() object construction? What is happening today?
> What will happen after this change lands?
>
>>
>>
>> Specification https://url.spec.whatwg.org/#url-parsing
>>
>> Summary
>>
>> URLs with non-special schemes will be supported in chrome.
>> `non-speicial://test.com:1234/path`  will be
>> become a valid URL. One can access and set the URL properties such as host,
>> port and path via the URL class.
>>
>>
>> Blink component Blink>JavaScript>API
>> 
>>
>> TAG review
>>
>> TAG review status Not applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> *Gecko*: Positive
>>
>> *WebKit*: Positive
>>
>> Any links to those positive signals?
>
>
>>
>> *Web developers*: No signals
>>
>> *Other signals*:
>>
>> Ergonomics
>>
>> No significant risks.
>>
>>
>> Activation
>>
>> No significant risks.
>>
>>
>> Security
>>
>> data:// and javascript:// URLs handling is not modified due to their
>> critical role.
>>
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially high risk for Android WebView-based applications?
>>
>> Do URLs with an intent:// scheme have any security considerations, or
>> implications for WebView? (I don't know, hopefully someone who does can
>> answer. :))
>>
>>
>>
>> Debuggability
>>
>> 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
>> 
>> ? Yes
>>
>> Flag name NonSpeicalSchemeURLParsing
>>
>> Requires code in //chrome? False
>>
>> Tracking bug https://crbug.com/1416006
>>
>> Sample links
>> https://chromium-review.googlesource.com/c/chromium/src/+/4273893
>>
>> Estimated milestones
>>
>> No milestones specified
>>
>>
>> Anticipated spec changes
>>
>> Open questions about a feature may be a source of future web compat or
>> interop issues. Please list open issues (e.g. links to known github issues
>> in the project for the feature specification) whose resolution may
>> introduce web compat/interop risk (e.g., changing to naming or structure of
>> the API in a non-backward-compatible way).
>>
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5201116810182656
>>
>> 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/CAJQw1Nzk847XL759vMSQaF3L5zvtykg6UfQvuss4diyU-h1%3Duw%40mail.gmail.com
>> 
>> .
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to blink-dev+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7cdf2693-c8a3-d263-0eb0-a44a2390979e%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/CAL5BFfVfGhV%2BDRzpCjGFoHg7EXb325nHz3nu4OSQVTTC6bkS1A%40mail.gmail.com

Re: [blink-dev] Re: Intent to Ship: HTTPS Upgrades

['Harald Alvestrand' via blink-dev]

How will this affect login to captive portals (WiFi login), which
frequently rely on rewriting HTTP requests?


On Tue, Jun 6, 2023 at 12:00 AM 'Panos Astithas' via blink-dev <
blink-dev@chromium.org> wrote:

> On Wed, May 31, 2023 at 7:31 AM Mike West  wrote:
>
>>
>> -mike
>>
>>
>> On Wed, May 31, 2023 at 4:17 PM Rick Byers  wrote:
>>
>>> As a long-time user of HTTPS-first mode, I'm excited to see this ship
>>> ASAP!
>>>
>>> On Wed, May 31, 2023, 5:29 a.m. 'Mike West' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
 On Fri, May 26, 2023 at 1:32 AM Chris Thompson 
 wrote:

> On Thu, May 25, 2023 at 3:36 AM Mike West  wrote:
>
>> I am enthusiastic about this (and not just because it should allow us
>> to deprecate/remove `Upgrade-Insecure-Requests`). A few comments inline:
>>
>> On Thu, May 25, 2023 at 1:13 AM Chris Thompson 
>> wrote:
>>
>>> Contact emailscth...@chromium.org, dadr...@google.com
>>>
>>> Explainer
>>> https://github.com/dadrian/https-upgrade/blob/main/explainer.md
>>>
>>> Specificationhttps://github.com/whatwg/fetch/pull/1655
>>>
>>
>> Thanks for putting this together! I'll leave some comments on the PR.
>> Given that we haven't gotten any feedback from Fetch editors, it might be
>> prudent to let them take a pass before locking in our current behavior.
>>
>
>  Yes, hopefully we can get some feedback, but I'm optimistic that we
> won't be locking in behavior if we ship this as it should hopefully be not
> site or user visible, so if we need to change the behavior to align
> cross-browser we can iterate.
>

 I left a few comments last week. I think the PR needs some work before
 we can reasonably expect it to land in Fetch.

 Do we have tests in place for this behavior in Web Platform Tests?
>> https://wpt.fyi/results/mixed-content/tentative/autoupgrades?label=experimental&label=master&aligned
>> holds some tests for subresources, but I didn't see any around
>> navigation or fallback behavior (which seems like it might need some WPT
>> infrastructure change to produce a domain that's only served over HTTP).
>>
>
> We do not have Web Platform Tests but we can look into adding them.
> Currently this is implemented in //chrome which I think might make this
> more difficult (my understanding is that the WPT suite is run against
> content_shell rather than chrome).  We are currently relying on browser
> tests for our integration testing.
>

 WPT is a pretty important part of shipping features that affect the
 platform. It would be ideal if we could share these tests with our friends
 at other vendors (and update existing tests that might be expecting
 different behavior). Shifting the implementation to //content to make that
 possible would also have the advantage of helping other Chromium embedders
 ship this feature, which would be excellent for consistency in the project.

>>>
>>> Note that the official WPT results on wpt.fyi are using full Chrome
>>> builds. IIRC there are other features that require Chrome. I  personally
>>> only consider having WPTs passing on upstream infra to be blocking I2S. 
>>> @Panos
>>> Astithas  can say more authoritatively.
>>>
>>
> Indeed, upstream WPT results use full Chrome (and Firefox, Safari, etc.)
> through wptrunner. Soon, this will also be the case when running WPT in
> Chromium CI on Linux, once some blockers have been resolved.
>
> Panos
>
> +1 to the benefits of having this in content, but I personally think
>>> that's outside the scope of API owners so not something that should block
>>> an I2S.
>>>
>>
>> I agree with this. I didn't mean to imply that //content implementation
>> was necessary, but that _having_ web platform tests is important for
>> interop. Browser tests are less useful in that regard. :)
>>
>>
>>>
>>>
 Summary
>>>
>>> Automatically and optimistically upgrade all main-frame navigations
>>> to HTTPS, with fast fallback to HTTP.
>>>
>>>
>>> Blink componentInternals>Network>SSL
>>> 
>>>
>>> TAG reviewFetch change process does not mention a TAG review,
>>> therefore this is N/A (https://github.com/whatwg/fetch#pull-requests
>>> )
>>>
>>
>> Blink's process does mention a TAG review. I think it would be a good
>> idea to put this in front of them. I also think they will appreciate it,
>> since it's directly in line with their previous guidance (e.g.
>> https://www.w3.org/2001/tag/doc/web-https).
>>
>>
>
> Sure, we can file a TAG review. I'll update this thread once that's
> done.
>
>
>> TAG review statusNot applicable
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>>
>>>
>>> *Geck

Re: [blink-dev] PSA: request TAG feedback early!

['Harald Alvestrand' via blink-dev]

what's your advice on going to TAG with respect to getting agreement in the
WG?
I've got a couple of spec changes now that I really would like TAG to
review early, but they consist of an explainer + PR because the WG doesn't
have agreement to merge yet.

Harald


On Thu, Oct 19, 2023 at 10:33 PM Sam Goto  wrote:

> +1
>
> The TAG has introduced (~year ago, I think?) an "Early Design Review",
> which is a lot more lightweight than the "Specification Review".
>
> https://github.com/w3ctag/design-reviews/issues/new/choose
>
> If you haven't gone through this part of the process before, I'd encourage
> you to try again and look into using the TAG for "Early Design Reviews"
> somewhere between your I2P and you kicking off a Devtrial.
>
> Sam
>
> On Tue, Oct 17, 2023 at 10:53 AM Alex Russell 
> wrote:
>
>> Hey all,
>>
>> A frequent occurrence in recent reviews have been sizeable features
>> arriving at Intent-to-Ship with no effort made in previous intents to ask
>> the TAG for advice and no reason given for avoiding this part of the
>> processes.
>>
>> This slows down launches while we pause consideration of an intent to
>> give the filer time to consult the TAG and wait O(weeks) for a response.
>>
>> You should expect delays of this sort of you do not file a request for
>> feedback for TAG review at or near I2P-time, preferably as soon as you have
>> an Explainer that holds together.
>>
>> If you have questions about of and when to ask the TAG for feedback,
>> don't hesitate to ask me or other current/ex-TAG members privately for
>> feedback.
>>
>> Best,
>>
>> Alex
>>
>>
>> --
>> 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/CAA44PQhmudMCTwbuSywafnwxiY6mU2e34nHzTEFdqGrHMMjPFg%40mail.gmail.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALdEk-wW9wErZQMGj7QhrSeOFJL25MzJ6wdyeH9k%3DXZMnYUJzg%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOqqYVEGg1Nmo6Q%2BbeTyx95G-%2B13-xSQ4HeCLKL8TGmft_mDWA%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Experiment: IP Protection Phase 0

['Harald Alvestrand' via blink-dev]

standard naming rant  can we call this "IP Address Protection"?
My initial read of the title was "Intellectual Property Protection", and I
opened it with a sense of dread expecting to find DRM-related stuff and a
long argument.

There are IETF efforts related to automatic relays (MASQUE, OHAI), but I
think they are intended for a lower level of the protocol stack.
Relays in HTTP are also well defined in IETF (for some value of "well"). I
can't remember having seen this particular usage discussed there (but I
don't follow HTTP that closely).

On Fri, Oct 20, 2023 at 6:29 AM Alex Russell 
wrote:

> This is going to change observable network behavior, right? The TAG liases
> with IETF, and if there aren't already active conversations in IETF about
> this change, I worry that it will be received poorly.
>
> On Thu, Oct 19, 2023, 7:15 PM Mike Taylor  wrote:
>
>> I'm recused from voting on this feature so with my API OWNER hat off (or
>> maybe just back and to the side to make me look cool...), it's possible
>> that we submit an FYI review in the future ahead of an I2S.
>>
>> That said, this is a feature that arguably does not materially alter web
>> platform APIs, but instead masks the client's IP using IETF defined
>> CONNECT, CONNECT-UDP, and MASQUE, etc. But if TAG would like to provide
>> input on our design choices, that could be useful. But it shouldn't block
>> an experiment.
>> On 10/19/23 3:22 PM, Alex Russell wrote:
>>
>> Why has the TAG not been consulted?
>>
>> On Thu, Oct 19, 2023, 3:09 PM 'Brianna Goldstein' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> *Correction*:
>>> The link to the entry on the Chrome Platform Status was incorrect. Below
>>> is the corrected link
>>>
>>> https://chromestatus.com/feature/5111460239245312
>>>
>>> On Thu, Oct 19, 2023 at 4:52 PM Brianna Goldstein <
>>> brgoldst...@google.com> wrote:
>>>
 Contact emails

 Brianna Goldstein , James Bradley
 , David Schinazi 

 Explainer

 IP Protection formerly known as Gnatcatcher
 

 Specification

 None

 Summary

 IP Protection  is a
 feature that sends third-party traffic for a set of domains through proxies
 for the purpose of protecting the user by masking their IP address from
 those domains.

 After receiving much feedback from the ecosystem, the design of the
 broader proposal is as follows:

-

IP Protection will be opt-in initially. This will help ensure that
there is user control over privacy decisions and that Google can monitor
behaviors at lower volumes.
-

It will roll out in a phased manner. Like all of our privacy
proposals, we want to ensure that we learn as we go and we recognize 
 that
there may also be regional considerations to evaluate.
-

We are using a list based approach and only domains on the list in
a third-party context will be impacted. We are conscious that these
proposals may cause undesired disruptions for legitimate use cases and 
 so
we are just focused on the scripts and domains that are considered to be
tracking users.


 We plan to test and roll out the feature in multiple phases. To start,
 Phase 0 will use a single Google-owned proxy and will only proxy requests
 to domains owned by Google. This first phase will allow us to test our
 infrastructure while preventing impact to other companies and gives us more
 time to refine the list of domains that will be proxied. For simplicity,
 only clients with US-based IP addresses will be granted access to the
 proxies for phase 0.

 A small percentage of clients will be automatically enrolled in this
 initial test, though the architecture and design will evolve between this
 test and future launches. To access the proxy, a user must be logged in to
 Chrome. To prevent abuse, a Google-run authentication server will grant
 access tokens to the Google run proxy based on a per-user quota.

 In future phases we plan to use a 2-hop proxy, as had previously been
 indicated in the IP Protection explainer.

 Blink component

 Privacy>Fingerprinting>IPProtection
 

 TAG review

 None

 TAG review status

 N/A

 Risks Interoperability and Compatibility

 IP Protection changes how stable a client's IP address is but does not
 otherwise cause a breaking change for existing sites. In this experiment
 the only sites impacted are Google owned domains which include the some
 domains
 

Re: [blink-dev] Intent to Ship: RTCRtpSender setParameters() extensions for requesting the generation of a key frame

['Harald Alvestrand' via blink-dev]

This extension has consensus in the WEBRTC WG, and CLs are approved by the
Chrome WebRTC folks.


On Fri, Jan 12, 2024 at 8:01 AM 'Philipp Hancke' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emails
>
> phan...@microsoft.com, ma...@microsoft.com
>
> Explainer
>
> https://fippo.github.io/webrtc-explainers/rtcrtpsender-setparameters
>
> Specification
>
>
> https://w3c.github.io/webrtc-extensions/#rtcrtpsender-setparameters-keyframe
>
> Summary
>
> Adds an optional second parameter to WebRTC's RTCRtpSender.setParameters
> call which can be used to ask the associated encoder to generate a key
> frame.
>
> Blink component
>
> Blink>WebRTC>PeerConnection
> 
>
> TAG review
>
> None, small addition to WebRTC
>
> TAG review status
>
> Not applicable
>
> RisksInteroperability and Compatibility
>
> None
>
> Gecko: No signal (
> https://github.com/mozilla/standards-positions/issues/858)
>
> WebKit: No signal (
> https://github.com/WebKit/standards-positions/issues/237)
>
> Web developers: Positive Microsoft Teams is quite interested in the
> feature.
>
> Other signals:
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such that
> it has potentially high risk for Android WebView-based applications?
>
> None
>
>
> Debuggability
>
> None
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, ChromeOS, Android, and Android WebView)?
>
> Yes
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> Yes
>
> See WPT added as part of
> https://chromium-review.googlesource.com/c/chromium/src/+/4643591
>
> Flag name on chrome://flags
>
> None
>
> Finch feature name
>
> None
>
> Non-finch justification
>
> None
>
> Requires code in //chrome?
>
> False
>
> Tracking bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1354101
>
> Estimated milestones
>
> Shipping on desktop
>
> 122
>
>
> Anticipated spec changes
>
> None
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5161082937409536
>
> This intent message was generated by Chrome Platform Status
>  and then copy-pasted around
>
> --
> 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/CADxkKiJ0%3D-O%2BQoJoXfEWO1KBrLNHWnzTUGxXJSJOpm8BJTQEjw%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOqqYVEd14tYEaUdAUCeQGDqEKEJ7EiR1ikENhy%2B5G9sLEu1dA%40mail.gmail.com.

[blink-dev] Intent to Ship: WebRTC Scalable Video Coding extensions

['Harald Alvestrand' via blink-dev]

DRFT
Contact emails

h...@chromium.org, sergio.garcia.muri...@gmail.com

Explainer

https://w3c.github.io/webrtc-svc/

Specification

https://w3c.github.io/webrtc-svc/

Design docs

https://w3c.github.io/webrtc-svc/

Summary

This extension defines a standard method for picking between possible
Scalable Video Coding (SVC)  configurations on an outgoing WebRTC video
track.



Blink component

Blink>WebRTC>Video


Search tags

video , svc


TAG review

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

TAG review status

Issues addressed

RisksNone identified

*Interoperability and Compatibility*

This is the first implementation of the spec.

Gecko: Positive - https://github.com/mozilla/standards-positions/issues/544

WebKit: Positive, with change request  -
https://lists.webkit.org/pipermail/webkit-dev/2021-October/032008.html

https://github.com/w3c/webrtc-svc/issues/49


Web developers: Positive (sample
)



*Ergonomics*

This is an extension to the WebRTC 1.0 API (webrtc-pc).
Support can be detected by checking the presence of scalabilityModes values
in the RTCRtpCodecCapability dictionary.


*Security*

None identified above what's already part of video in WebRTC in general.


Debuggability

No special considerations.

Is this feature fully tested by web-platform-tests

?

Yes (as far as the API surface goes; effect on bitstream content is not
tested).

Flag name

RTCSvcScalabilityMode

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=986069

Estimated milestones

M97


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5769626174619648

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/CAOqqYVE9m_ydsJww6Xa8R2HTK2nkAW1grUGF0t%3D9%3DXifzEx96A%40mail.gmail.com.

[blink-dev] Re: Intent to Ship: WebRTC Scalable Video Coding extensions

['Harald Alvestrand' via blink-dev]

Note - the change request from WebKit (
https://github.com/w3c/webrtc-svc/issues/49) involves removing the list of
scalability modes from the codec information in WebRTC and instead using
the MediaCapabilities API with the "webrtc" usage to detect whether a given
scalability mode is available or not.

This would require gating this API behind the updated MediaCapabilities
API, and would not give exactly the same programming paradigm (see bug).


On Mon, Oct 25, 2021 at 12:03 PM Harald Alvestrand  wrote:

> DRFT
> Contact emails
>
> h...@chromium.org, sergio.garcia.muri...@gmail.com
>
> Explainer
>
> https://w3c.github.io/webrtc-svc/
>
> Specification
>
> https://w3c.github.io/webrtc-svc/
>
> Design docs
>
> https://w3c.github.io/webrtc-svc/
>
> Summary
>
> This extension defines a standard method for picking between possible
> Scalable Video Coding (SVC)  configurations on an outgoing WebRTC video
> track.
>
>
>
> Blink component
>
> Blink>WebRTC>Video
> 
>
> Search tags
>
> video , svc
> 
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/396
>
> TAG review status
>
> Issues addressed
>
> RisksNone identified
>
> *Interoperability and Compatibility*
>
> This is the first implementation of the spec.
>
> Gecko: Positive -
> https://github.com/mozilla/standards-positions/issues/544
>
> WebKit: Positive, with change request  -
> https://lists.webkit.org/pipermail/webkit-dev/2021-October/032008.html
>
> https://github.com/w3c/webrtc-svc/issues/49
>
>
> Web developers: Positive (sample
> )
>
>
>
> *Ergonomics*
>
> This is an extension to the WebRTC 1.0 API (webrtc-pc).
> Support can be detected by checking the presence of scalabilityModes
> values in the RTCRtpCodecCapability dictionary.
>
>
> *Security*
>
> None identified above what's already part of video in WebRTC in general.
>
>
> Debuggability
>
> No special considerations.
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> Yes (as far as the API surface goes; effect on bitstream content is not
> tested).
>
> Flag name
>
> RTCSvcScalabilityMode
>
> Requires code in //chrome?
>
> False
>
> Tracking bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=986069
>
> Estimated milestones
>
> M97
>
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5769626174619648
>
> 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/CAOqqYVGpUOxnK_ibpNiGaJof%3D6B-1pCd-RQMkRYfEG2sYPBuPw%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Ship: WebRTC Scalable Video Coding extensions

['Harald Alvestrand' via blink-dev]

The scalability modes (being able to set them) are the point of the launch.
Figuring out which of the desired ones are available seems like it would be
a requirement.


On Mon, Oct 25, 2021 at 9:32 PM Fernando Serboncini 
wrote:

> It seems they are asking for a delay on Chrome launching this until the
> WebRTC WG makes a decision on it.
> It's not clear from the issue that there's a consensus on the right
> approach there.
>
> Did you consider launching things separately and delaying the scalability
> modes? Or does the whole launch make no sense without it?
>
>

-- 
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/CAOqqYVER1i%2BZBZNLBeWz_%2BWy-%2BFJ_k8P0ZUjr9NU38O9Mrug1A%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Ship: WebRTC Scalable Video Coding extensions

['Harald Alvestrand' via blink-dev]

It seems like we don't have a strong push towards either the
MediaCapabilities or the Codec Capabilities solution in the issue on the
sender side (https://github.com/w3c/webrtc-svc/issues/49). This is bad for
quick resolution.

In the interest of getting the uncontroversial parts shipped - what would
people think of letting the Codec Capabilities list of modes remain behind
the flag, and push the rest of the API to public?
Many usages of the function would work quite well with only probing for
supported modes by trying to set the ones they want; we could then let the
issue sort itself out in peace.

(On the receiver side, there seems to be consensus on abandoning the mode
list for other reasons.)




On Wed, Nov 24, 2021 at 3:21 PM Mike West  wrote:

> Friendly ping on Yoav's question about timelines.
>
> -mike
>
>
> On Wed, Nov 10, 2021 at 7:04 PM Yoav Weiss  wrote:
>
>> How long of a delay are we talking about here? Weeks? Months? Years?
>>
>> On Monday, October 25, 2021 at 11:00:46 PM UTC+2 Harald Alvestrand wrote:
>>
>>> The scalability modes (being able to set them) are the point of the
>>> launch.
>>> Figuring out which of the desired ones are available seems like it would
>>> be a requirement.
>>>
>>>
>>> On Mon, Oct 25, 2021 at 9:32 PM Fernando Serboncini 
>>> wrote:
>>>
 It seems they are asking for a delay on Chrome launching this until the
 WebRTC WG makes a decision on it.
 It's not clear from the issue that there's a consensus on the right
 approach there.

 Did you consider launching things separately and delaying the
 scalability modes? Or does the whole launch make no sense without it?

 --
>> 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/1197505b-23e6-491a-8fc6-4b386cce0bcen%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/CAOqqYVHmEvq6MANGA078Fa9TqQe63b3QS5icAFaLbjH34ETfmw%40mail.gmail.com.

Re: [blink-dev] [ACTION REQUESTED] What's in Chrome 98

['Harald Alvestrand' via blink-dev]

The removal of SDES, originally landed in M97 beta but rolled back, is
landed in M98 (unless I missed the cut; CL landed yesterday).

https://chromestatus.com/features/5695324321480704


On Thu, Dec 9, 2021 at 3:29 PM 'Joe Medley' via blink-dev <
blink-dev@chromium.org> wrote:

> Gang,
>
> Chrome 98 is planned for beta on January 6. Developer Relations needs
> information to help us plan. We want a complete list of everything in
> Chrome beta for the beta post
> . We try when possible to
> have articles for important new features on web.dev
> .
>
> Please let me know of anything that might be shipping in Chrome 98 or 99.
> I don't care if it's a new API, a bug to add a missing interface member, a
> spec change or whatever. I need to know all of it. If you have any
> questions about this, just ask, or refer to the FAQ in my communication
> instructions
> 
> .
>
> Also, please make sure your Chrome Status entries reflect the
> current state of your feature. Origin trial and shipping milestone numbers
> may be edited by clicking the "Edit all fields" link and scrolling down the
> page.
>
> The list of what I currently believe to be shipping is in this spreadsheet
> .
> For those who can't reach it, here's a summary.
>
> (Deprecations and removals are in red.)
>
> auto keyword for contain-intrinsic-size
>  LGTMs to Ship
> Barcode Detection API  
> LGTMs
> to Ship
> (Calling PaymentRequest.show without user activation)
>  I2S
> COLRv1 Color Gradient Vector Fonts
>  LGTMs to Ship
> Convert adoptedStyleSheets to use ObservableArray
>  I2S
> CSS Color Adjust: 'only' keyword for color-scheme
>  Merged, No LGTM
> Declarative Link Capturing for PWAs
>  Prior OT Done
> FileSystemHandle::Remove() method
>  Milestone on
> Chrome Status
> Handwriting Recognition API
>  Prior OT Done
> High Dynamic Range Support for HTMLCanvasElement
>  I2E
> New Canvas 2D API  
> LGTMs
> to Ship
> New window.open() popup vs. window behavior
>  LGTMs to Ship
> Pickling for Async Clipboard API
>  I2S
> Presentation API: Site-initiated mirroring
>  I2E
> Private Network Access preflight requests for subresources
>  LGTMs to Ship
> Progressive Web Apps as URL Handlers
>  Prior OT Done
> Propagate request origin and redirect chain in passthrough service workers.
>  LGTMs to Ship
> Region Capture  
> Milestone
> on Chrome Status
> Sec-CH-UA-Full-Version-List user-agent client hint
>  LGTMs to Ship
> self.structuredClone  LGTMs
> to Ship
> Service Worker subresource filter
>  Prior OT Done
> Speculation Rules  Prior
> OT Done
> WebAuthn minPinLength extension
>  LGTMs to Ship
> WritableStream controller AbortSignal
>  LGTMs to Ship
> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>  816-678-7195
> *If an API's not documented it doesn't exist.*
>
> --
> 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/CAJUhtG_vCD9rhqLv6Vqn-UBm%2BPKE996pDY_L6XLijRAyCziRmw%40mail.gmail.com
> 
> .
>

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

Re: [blink-dev] Re: Intent to Ship: WebRTC Scalable Video Coding extensions

['Harald Alvestrand' via blink-dev]

At the moment, I think we can safely ship:

- RTCRtpEncodingParameters extension scalabilityMode (
https://w3c.github.io/webrtc-svc/#dom-rtcrtpencodingparameters-scalabilitymode
)

We have an open discussion on whether or not to ship this part on senders
(we've decided not to ship it on receivers):

- RTCRtpCodecCapability extension scalabilityModes (
https://w3c.github.io/webrtc-svc/#dom-rtcrtpcodeccapability-scalabilitymodes
)

There are no mandatory-to-implement scalability modes except for L1T1
(which we need to add support for).

I think that as currently specified, feature detection can be done in the
absence of the RTCRtpCodecCapability extension by setting the mode to L1T1,
reading back the encoding parameters, and seeing if the mode is set.




On Wed, Dec 15, 2021 at 6:01 PM Philip Jägenstedt 
wrote:

> Hi Bernard,
>
> Can you clarify what the consensus is on RTCRtpEncodingParameters's
> scalabilityMode member? That remains in https://w3c.github.io/webrtc-svc/,
> but will it be removed? Meanwhile, referenceScaling is only partly spec'd,
> there's no IDL for it but a link to
> https://github.com/w3c/media-capabilities/issues/182.
>
> Harald, if you could confirm the precise API surface that you'd like to
> ship, that would be great.
>
> Best regards,
> Philip
>
> On Thu, Dec 9, 2021 at 3:21 AM Bernard Aboba 
> wrote:
>
>> Harald said:
>>
>> "It seems like we don't have a strong push towards either the
>> MediaCapabilities or the Codec Capabilities solution in the issue on the
>> sender side (https://github.com/w3c/webrtc-svc/issues/49). This is bad
>> for quick resolution."
>>
>> [BA] On the receiver/decoder side (for WebRTC-SVC, Media Capabilities and
>> WebCodecs), we have a path forward  which involves using a referenceScaling
>> boolean and removing scalabiltyMode advertisement and configuration.  The
>> consensus is  reflected in the current editor's draft of WebRTC-SVC (see:
>> https://w3c.github.io/webrtc-svc/ ) and compatible PRs are under
>> development for MediaCapabilities and WebCodecs.
>>
>> On the sender/encoder side, we have added the "L1T1" scalability mode and
>> specified its use in both advertisement and encoder configuration.
>>
>> Chris can provide more details with respect to the moving parts in Media
>> Capabilities and WebCodecs.
>>
>> Here are links to the (now resolved) WebRTC-SVC issues:
>> https://github.com/w3c/webrtc-svc/issues/48
>> https://github.com/w3c/webrtc-svc/issues/52
>>
>> Here are links to related WebCodecs issues:
>> https://github.com/w3c/webcodecs/issues/399
>>
>> Here are links to the related Media Capabilities issues:
>> https://github.com/w3c/media-capabilities/issues/182
>> https://github.com/w3c/media-capabilities/issues/183
>> https://github.com/w3c/media-capabilities/issues/185
>>
>>
>>
>>
>> On Wednesday, December 8, 2021 at 9:37:57 AM UTC-8 Philipp Hancke wrote:
>>
>>> Am Mi., 8. Dez. 2021 um 17:52 Uhr schrieb Philip Jägenstedt <
>>> foo...@chromium.org>:
>>>
>>>> Hi Harald,
>>>>
>>>> Can you spell out what the uncontroversial parts of this would be?
>>>> Looking at the IDL in https://w3c.github.io/webrtc-svc/ it looks like
>>>> it's all about modes.
>>>>
>>>> My guess is that it's RTCRtpEncodingParameters's scalabilityMode, but
>>>> is that right?
>>>>
>>>
>>> yeah
>>>
>>> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/peerconnection/rtc_rtp_encoding_parameters.idl;l=24
>>> which is currently behind a flag.
>>>
>>> Best regards,
>>>> Philip
>>>>
>>>> On Mon, Dec 6, 2021 at 3:27 PM 'Harald Alvestrand' via blink-dev <
>>>> blin...@chromium.org> wrote:
>>>>
>>>>> It seems like we don't have a strong push towards either the
>>>>> MediaCapabilities or the Codec Capabilities solution in the issue on the
>>>>> sender side (https://github.com/w3c/webrtc-svc/issues/49). This is
>>>>> bad for quick resolution.
>>>>>
>>>>> In the interest of getting the uncontroversial parts shipped - what
>>>>> would people think of letting the Codec Capabilities list of modes remain
>>>>> behind the flag, and push the rest of the API to public?
>>>>> Many usages of the function would work quite well with only probing
>>>>> for supported modes by trying to 

[blink-dev] Intent to Prototype: Mediacapture-transform VideoTrackGenerator

['Harald Alvestrand' via blink-dev]

Contact emails...@chromium.org

Explainer
https://github.com/w3c/mediacapture-transform/blob/main/explainer.md

Specification
https://w3c.github.io/mediacapture-transform/#video-track-generator

Summary

API to generate a video MediaStreamTrack from a WHATWG Stream of VideoFrame
objects. This is the WG-agreed form of the interface that was previously
known as MediaStreamTrackGenerator, specialized for video.


Blink componentBlink>MediaStream


Motivation

The WEBRTC WG agreed to adopt the mediacapture-transform proposal; as part
of the debate, the form of the function to generate a video
MediaStreamTrack was changed. This intent tracks the API change.


Initial public proposal

TAG review

TAG review statusNot applicable

Risks


Interoperability and Compatibility



Gecko: Positive

WebKit: No signal

Web developers: No signals

Other signals:


Debuggability



Is this feature fully tested by web-platform-tests

?No

Flag nameVideoTrackGenerator

Requires code in //chrome?False

Tracking bughttps://crbug.com/1300528

Estimated milestones

No milestones specified


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

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/CAOqqYVH5ZynV-S11kjz-OWsnOtbt3P%3DoTo1EqB0D6mUi3itH%2Bg%40mail.gmail.com.

Re: [blink-dev] introduce blink_wpt_tests

['Harald Alvestrand' via blink-dev]

at the moment, wpt tests live under
third_party/blink/web_tests/external/wpt (4 directories down).

What will the new path for wpt tests be, once all is moved and done?



On Tue, Apr 26, 2022 at 12:06 AM 'Weizhong Xia' via blink-dev <
blink-dev@chromium.org> wrote:

> Dear blink devs
>
> As some of you may already know, I am working to split blink_web_tests
> into two test suites: *blink_web_tests* for legacy tests and
> *blink_wpt_tests* for wpt tests(crbug/1299834 ).
> We now have reached the first point to move all baselines to a central
> place (CL
> ).
> Some of the changes you may need to be aware of:
> 1. We renamed web_tests/platform to web_tests/baselines.
> 2. All the generic baselines are now put under
> web_tests/baselines/generic. (reference files are allowed at both
> baselines/generic or in the same folder of the test itself.)
>
> I planned to do another round of rebaseline then land this CL the
> coming Saturday, to reduce the chance of merge conflict.
>
> After that, we will have another CL to actually break blink_web_tests into
> two. This should have no impact on your local experiences. The only
> difference is that we are now running legacy tests and wpt tests at
> different steps, so you need to get log/results at different places.
>
> At this point blink_wpt_tests will continue to run with run_web_tests.py.
> We have a plan to switch it to use wptrunner, targeting the middle of next
> year. After that we will have tools, web_tests, wpt_tests under blink, and
> we will use metadata as test expectation for wpt_tests. More details to
> come.
>
> Thanks for your attention. If you have any suggestion/comments, feel free
> to reply here, or put that in the crbug or CL. I definitely want to get
> more input from you folks.
>
> Thanks, Weizhong
>
> --
> 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/CADXrSioUQu-0wzBbQm1CG2ANTH_aPgdY1NuWS309zASAhcGjtg%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOqqYVE7M1tB1Br89XF3jBS-d7AG6zCJY3Gtc73K-3rPZJfRng%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Prototype: Reduce fingerprinting in the Accept-Language header and ​​support for HTTP Variants

['Harald Alvestrand' via blink-dev]

So if my config is (no, en), the site supports (fr, en), the first response
will be in French with a Vary:(fr, en) header? Will the browser
automatically detect that a better alternative is available and re-ask,
imposing an extra RTT, or will the result remain French?

fre. 20. mai 2022, 19:11 skrev 'Victor Tan' via blink-dev <
blink-dev@chromium.org>:

> NOTES: This intend won't implement Variants in the HTTP cache. It only
> focus on using Variants http header as a support-languages head which in
> the definition on section 2
> 
> .
>
> On Thursday, May 19, 2022 at 10:20:29 AM UTC-4 vict...@chromium.org wrote:
>
>> Contact emails
>>
>> vict...@chromium.org, abe...@chromium.org
>>
>> Explainer
>>
>>
>> https://github.com/Tanych/accept-language
>> Specification
>>
>> Variants header:
>> https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06
>>
>> Summary
>>
>> Support the HTTP Variants header and implement the reduction of
>> information that could be used for fingerprinting in the Accept-Language
>> header, so that Chrome only sends the user’s most preferred language in the
>> Accept-Language header on the initial request.
>> Blink component
>>
>> Privacy>Fingerprinting
>> 
>>
>> Motivation
>>
>>
>> The Accept-Language header is a source of passive fingerprinting
>> information about users, as it can contain a high degree of entropy,
>> particularly if the user has many accepted languages.
>>
>> Chrome (and other browsers) send a full list of the user's accepted
>> languages on every HTTP request via the Accept-Language header. While some
>> sites use this information for content negotiation, servers can also
>> passively capture this information without the user's awareness, to
>> fingerprint a user.
>>
>> We propose to only send a single language—one of the user’s preferred
>> languages determined by the language negotiation process—in the
>> Accept-Language request header by default. Here’s what that would look like
>> when a user tries to access https://example.com:
>>
>> Get / HTTP/1.1
>>
>> Host: example.com
>>
>> Accept-Language: en
>>
>> HTTP/1.1 200 OK
>>
>> Content-Language: en
>>
>> Vary: Accept-Language
>>
>> Variants: Accept-Language=(en)
>>
>> As the response shows, in addition to the Content-Language in the
>> response header, sites will respond with a Variants
>> 
>> header (support for which will be prototyped as part of this intent), the
>> value of which includes all the languages the site supports. Browsers can
>> use the Variants header to do language negotiation if sites offer a page in
>> a language that doesn’t match the user's preferred languages. Initial
>> public proposal
>>
>>
>> https://discourse.wicg.io/t/proposal-reduce-fingerprinting-in-the-accept-language-header/5835
>>
>>
>>
>> TAG review
>>
>> To be filed.
>>
>> RisksInteroperability and Compatibility
>>
>> We are reducing the number of languages sent in the Accept-Language
>> header to protect user privacy. The main source of risk is that sites rely
>> on all or part of a user’s preferred languages instead of the most
>> preferred language. We feel it’s important to minimize the breakage of the
>> features depending on Accept-Language as much as possible, to maintain
>> stability of the web ecosystem. To mitigate the risk of this change, we
>> intend to gradually roll it out via Finch configuration and keep monitoring
>> health metrics and bug reports from the community.
>>
>> Gecko: No signals
>>
>> WebKit: No signals
>>
>> Web developers:  See the explainer for details.
>> Debuggability
>>
>> No special DevTools support needed.
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?
>>
>> It will be.
>>
>> Flag name
>>
>> reduce-accept-language
>>
>>
>> Requires code in //chrome?
>>
>> False
>>
>> Tracking bug
>>
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1306905
>>
>>
>> *Launch bug*
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1307484
>>
>> *Link to entry on the Chrome Platform Status*
>> https://chromestatus.com/feature/5188040623390720
>> 
>>
>>
>> --
> 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/12b25cad-3902-4a09-bd9c-3c30a3b41ab6n%40chromium.org
> 
> .
>

-- 
You 

Re: [blink-dev] Re: Intent to Prototype: Reduce fingerprinting in the Accept-Language header and ​​support for HTTP Variants

['Harald Alvestrand' via blink-dev]

So one extra round trip per page?


On Sun, May 22, 2022 at 5:31 PM Victor Tan  wrote:

> Hi Harald,
> The browser will do language negotiation with resend the request (only
> happen once) with accept-language:en to get a result with English page.
>
> Victor
>
> On Saturday, May 21, 2022 at 8:38:47 AM UTC-4 Harald Alvestrand wrote:
>
>> So if my config is (no, en), the site supports (fr, en), the first
>> response will be in French with a Vary:(fr, en) header? Will the browser
>> automatically detect that a better alternative is available and re-ask,
>> imposing an extra RTT, or will the result remain French?
>>
>> fre. 20. mai 2022, 19:11 skrev 'Victor Tan' via blink-dev <
>> blink-dev@chromium.org>:
>>
>>> NOTES: This intend won't implement Variants in the HTTP cache. It only
>>> focus on using Variants http header as a support-languages head which in
>>> the definition on section 2
>>> 
>>> .
>>>
>>> On Thursday, May 19, 2022 at 10:20:29 AM UTC-4 vict...@chromium.org
>>> wrote:
>>>
 Contact emails

 vict...@chromium.org, abe...@chromium.org

 Explainer


 https://github.com/Tanych/accept-language
 Specification

 Variants header:
 https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06

 Summary

 Support the HTTP Variants header and implement the reduction of
 information that could be used for fingerprinting in the Accept-Language
 header, so that Chrome only sends the user’s most preferred language in the
 Accept-Language header on the initial request.
 Blink component

 Privacy>Fingerprinting
 

 Motivation


 The Accept-Language header is a source of passive fingerprinting
 information about users, as it can contain a high degree of entropy,
 particularly if the user has many accepted languages.

 Chrome (and other browsers) send a full list of the user's accepted
 languages on every HTTP request via the Accept-Language header. While some
 sites use this information for content negotiation, servers can also
 passively capture this information without the user's awareness, to
 fingerprint a user.

 We propose to only send a single language—one of the user’s preferred
 languages determined by the language negotiation process—in the
 Accept-Language request header by default. Here’s what that would look like
 when a user tries to access https://example.com:

 Get / HTTP/1.1

 Host: example.com

 Accept-Language: en

 HTTP/1.1 200 OK

 Content-Language: en

 Vary: Accept-Language

 Variants: Accept-Language=(en)

 As the response shows, in addition to the Content-Language in the
 response header, sites will respond with a Variants
 
 header (support for which will be prototyped as part of this intent), the
 value of which includes all the languages the site supports. Browsers can
 use the Variants header to do language negotiation if sites offer a page in
 a language that doesn’t match the user's preferred languages. Initial
 public proposal


 https://discourse.wicg.io/t/proposal-reduce-fingerprinting-in-the-accept-language-header/5835



 TAG review

 To be filed.

 RisksInteroperability and Compatibility

 We are reducing the number of languages sent in the Accept-Language
 header to protect user privacy. The main source of risk is that sites rely
 on all or part of a user’s preferred languages instead of the most
 preferred language. We feel it’s important to minimize the breakage of the
 features depending on Accept-Language as much as possible, to maintain
 stability of the web ecosystem. To mitigate the risk of this change, we
 intend to gradually roll it out via Finch configuration and keep monitoring
 health metrics and bug reports from the community.

 Gecko: No signals

 WebKit: No signals

 Web developers:  See the explainer for details.
 Debuggability

 No special DevTools support needed.

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

 It will be.

 Flag name

 reduce-accept-language


 Requires code in //chrome?

 False

 Tracking bug

 https://bugs.chromium.org/p/chromium/issues/detail?id=1306905


 *Launch bug*
 https://bugs.chromium.org/p/chromium/issues/detail?id=1307484

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

Re: [blink-dev] Re: Intent to Prototype: Reduce fingerprinting in the Accept-Language header and ​​support for HTTP Variants

['Harald Alvestrand' via blink-dev]

I hope you will be recording the percentage of extra round trips, split on
main language preference. This may be a disproportionate impact on people
without English as their first language.



On Sun, May 22, 2022 at 6:15 PM Victor Tan  wrote:

> The browser will only do language negotiation if necessary. Yea, you are
> right, it would take an extra round trip in some cases. We also plan to
> save some selections in memory to avoid introducing large latency.
>
> On Sunday, May 22, 2022 at 12:11:23 PM UTC-4 Harald Alvestrand wrote:
>
>> So one extra round trip per page?
>>
>>
>> On Sun, May 22, 2022 at 5:31 PM Victor Tan 
>> wrote:
>>
>>> Hi Harald,
>>> The browser will do language negotiation with resend the request (only
>>> happen once) with accept-language:en to get a result with English page.
>>>
>>> Victor
>>>
>>> On Saturday, May 21, 2022 at 8:38:47 AM UTC-4 Harald Alvestrand wrote:
>>>
 So if my config is (no, en), the site supports (fr, en), the first
 response will be in French with a Vary:(fr, en) header? Will the browser
 automatically detect that a better alternative is available and re-ask,
 imposing an extra RTT, or will the result remain French?

 fre. 20. mai 2022, 19:11 skrev 'Victor Tan' via blink-dev <
 blink-dev@chromium.org>:

> NOTES: This intend won't implement Variants in the HTTP cache. It only
> focus on using Variants http header as a support-languages head which in
> the definition on section 2
> 
> .
>
> On Thursday, May 19, 2022 at 10:20:29 AM UTC-4 vict...@chromium.org
> wrote:
>
>> Contact emails
>>
>> vict...@chromium.org, abe...@chromium.org
>>
>> Explainer
>>
>>
>> https://github.com/Tanych/accept-language
>> Specification
>>
>> Variants header:
>> https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-variants-06
>>
>> Summary
>>
>> Support the HTTP Variants header and implement the reduction of
>> information that could be used for fingerprinting in the Accept-Language
>> header, so that Chrome only sends the user’s most preferred language in 
>> the
>> Accept-Language header on the initial request.
>> Blink component
>>
>> Privacy>Fingerprinting
>> 
>>
>> Motivation
>>
>>
>> The Accept-Language header is a source of passive fingerprinting
>> information about users, as it can contain a high degree of entropy,
>> particularly if the user has many accepted languages.
>>
>> Chrome (and other browsers) send a full list of the user's accepted
>> languages on every HTTP request via the Accept-Language header. While 
>> some
>> sites use this information for content negotiation, servers can also
>> passively capture this information without the user's awareness, to
>> fingerprint a user.
>>
>> We propose to only send a single language—one of the user’s preferred
>> languages determined by the language negotiation process—in the
>> Accept-Language request header by default. Here’s what that would look 
>> like
>> when a user tries to access https://example.com:
>>
>> Get / HTTP/1.1
>>
>> Host: example.com
>>
>> Accept-Language: en
>>
>> HTTP/1.1 200 OK
>>
>> Content-Language: en
>>
>> Vary: Accept-Language
>>
>> Variants: Accept-Language=(en)
>>
>> As the response shows, in addition to the Content-Language in the
>> response header, sites will respond with a Variants
>> 
>> header (support for which will be prototyped as part of this intent), the
>> value of which includes all the languages the site supports. Browsers can
>> use the Variants header to do language negotiation if sites offer a page 
>> in
>> a language that doesn’t match the user's preferred languages. Initial
>> public proposal
>>
>>
>> https://discourse.wicg.io/t/proposal-reduce-fingerprinting-in-the-accept-language-header/5835
>>
>>
>>
>> TAG review
>>
>> To be filed.
>>
>> RisksInteroperability and Compatibility
>>
>> We are reducing the number of languages sent in the Accept-Language
>> header to protect user privacy. The main source of risk is that sites 
>> rely
>> on all or part of a user’s preferred languages instead of the most
>> preferred language. We feel it’s important to minimize the breakage of 
>> the
>> features depending on Accept-Language as much as possible, to maintain
>> stability of the web ecosystem. To mitigate the risk of this change, we
>> intend to gradually roll it out via Finch configuration and keep 
>> monitoring
>> healt

Re: [blink-dev] Re: Intent to Ship: DisplayMediaStreamConstraints.systemAudio

['Harald Alvestrand' via blink-dev]

re webrtc trying to skip TAG review ... we were told at one point (a few
years back, I think) that we were sending too many TAG reviews; I believe
that at that point, something like 1/3 of the outstanding TAG reviews were
on relatively small WebRTC features. I guess we scaled back too forcefully
 thanks for pointing out the desire to course-correct.


On Wed, Jun 1, 2022 at 6:13 PM Alex Russell 
wrote:

> Hey Elad,
>
> This is a pretty simple design, and it's great to see the progress here.
> That said, this group of intents (systemAudio, suppressLocalAudioPlayback,
> and selfBrowserSurface) would benefit from a joint explainer with
> considered alternatives outlined. The TAG might not have much to say about
> small changes, but our process asks teams to *at least *send them an FYI
> for non-controversial updates so that they can consider how parts fit
> together in future.
>
> Given that the WebRTC group has a history of trying to skip TAG review, it
> doesn't seem right for this set of features to launch without some
> intentional design review. Can you file a request with them or get several
> of the current and former TAG members (Rossen, David, Alice, myself, or
> Domenic) in the project to review the design directly?
>
> Thanks
>
>
> On Wednesday, June 1, 2022 at 12:35:24 AM UTC-7 Elad Alon wrote:
>
>> I've set my alarm.
>> I'll implicitly assume the same period is intended for the other three
>> intents-to-ship sent at roughly the same time.
>>
>> On Wed, Jun 1, 2022 at 9:29 AM Yoav Weiss  wrote:
>>
>>> Let's give them 1 more week to respond.
>>>
>>> On Wed, Jun 1, 2022 at 9:21 AM Elad Alon  wrote:
>>>
 Okay, will do. (I've also sent a personal email on the day the intent
 went out.)
 When shall I ping this thread if no response is received?

 On Wed, Jun 1, 2022 at 8:30 AM Yoav Weiss 
 wrote:

>
>
> On Wednesday, May 25, 2022 at 2:38:53 PM UTC+2 Elad Alon wrote:
>
>> Contact emailselada...@chromium.org
>>
>> Explainer
>> https://docs.google.com/document/d/1q3oGy7hLJmdQA4ZK7QG7DnwgtcpL6oB2pqLQJ6MP1tY/edit?usp=sharing
>>
>
>>
>> Specification
>> https://github.com/w3c/mediacapture-screen-share/pull/222/files
>>
>> Summary
>>
>> Hint indicating to the user agent whether the application, upon
>> calling getDisplayMedia() with {audio: true} or similar, wishes *system
>> audio* to be offered to the user. (If not - only offer tab-audio.)
>>
>>
>> Blink componentBlink
>> 
>>
>> TAG reviewN/A. This is just an addition of a single flag to an
>> existing dictionary, following well-known patterns.
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> *Gecko*: Positive (
>> https://github.com/mozilla/standards-positions/issues/638) Jan-Ivar
>> Bruaroey from Mozilla, and Youenn Fablet from Apple, have both 
>> collaborated
>> with us closely in shaping this PR. They have then approved merging this 
>> PR
>> into w3c/mediacapture-screen-share. This is implicit support, so I'd
>> consider it POSITIVE even though, as of the time of this writing, the
>> official request for position has not yet been answered.
>>
>> *WebKit*: Positive (
>> https://lists.webkit.org/pipermail/webkit-dev/2022-May/032247.html)
>> Jan-Ivar Bruaroey from Mozilla, and Youenn Fablet from Apple, have both
>> collaborated with us closely in shaping this PR. They have then approved
>> merging this PR into w3c/mediacapture-screen-share. This is implicit
>> support, so I'd consider it POSITIVE even though, as of the time of this
>> writing, the official request for position has not yet been answered.
>>
>
> While encouraging, neither counts as a positive position based on
> https://bit.ly/blink-signals
> It might be good to give them a few more days to chime in.
>
>
>> *Web developers*: Positive Endorsed by Google Meet.
>>
>> Security
>>
>> This feature can only be used by Web applications to REDUCE the
>> amount of private information they obtain from the user. As such, this 
>> is a
>> net security gain.
>>
>>
>>
>> Debuggability
>>
>> N/A
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows,
>> Mac, Linux, Chrome OS, Android, and Android WebView)?No. Supported
>> on all platforms that support getDisplayMedia. (Namely, all desktop
>> platforms.)
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?No
>>
>> Tracking bug
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1329129
>>
>> Estimated milestones
>>
>> No mile

Re: [blink-dev] Intent to Prototype : Background Blur API.

['Harald Alvestrand' via blink-dev]

Effects that are not supported by the camera driver need to be done in
software like the Meet effects pipeline or Breakout Box processing.

tor. 10. nov. 2022, 18:54 skrev Vivek Wamorkar <
vivek.wamor...@ringcentral.com>:

> Greetings,
> Thanks for starting this effort.
> From the spec and some of the answers, I think the proposal indicates that
> the actual blur is applied on the source of the frames i.e. Camera (or
> capturer)...
>
> I am wondering how would we support the following use cases:
> 1. Support for the image (or other media) as a background
> 2.  If I have started a blurred stream toward the remote participants
> (in the call), and would like to go to settings to try different background
> images before I finalize on one. In this case I may need 2 streams (one to
> continue using Blur, and 2nd try image)
> 3.  If I need to provide custom (user-uploaded) images to the
> background.
>
>  Please let me know, how these scenarios will be addressed or if could
> throw some light on how the chromium would implement these.
>
> Thank you for your help
> Regards
> Vivek
>
>
> On Monday, July 4, 2022 at 3:18:37 PM UTC+5:30 ahe...@google.com wrote:
>
>> Hi Bhaumik,
>>
>> Thanks for the precisions! Let me rephrase to verify my understanding:
>> "Background blur is applied by request or constraint. In the
>> first implementation only stream sources like cameras obtained by
>> GetUserMedia support blurring. This is completely unidirectional, from the
>> device to the platform. Getting a stream from another source such as
>> CanvasCaptureMediaStreamTrack will simply not support the capability.
>> Therefore there is no way to send custom crafted bits into the native APIs,
>> and in general no content from the internet flows into the native APIs."
>>
>> Is that accurate?
>>
>> Cheers,
>> Arthur
>>
>>
>> On Thu, Jun 30, 2022 at 3:32 PM Bhaumik, Rijubrata 
>> wrote:
>>
>>> Hi Arthur,
>>>
>>> Thanks for the questions, I will add more info in the Explainer
>>> regarding Privacy in Security
>>> 
>>> .
>>>
>>> Replies inline -
>>>
>>>
>>>
>>> *From:* Arthur Hemery 
>>> *Sent:* Wednesday, June 29, 2022 1:17 PM
>>> *To:* blink-dev 
>>> *Cc:* Bhaumik, Rijubrata ; François Beaufort <
>>> fbea...@google.com>; yoav...@chromium.org ;
>>> blin...@chromium.org ; Guido Urdaneta <
>>> gui...@chromium.org>; Harald Alvestrand ; Youenn
>>> Fablet ; Bernard Aboba ;
>>> Jan-Ivar Bruaroey @Mozilla ; Kenneth Russell <
>>> k...@chromium.org>
>>> *Subject:* Re: [blink-dev] Intent to Prototype : Background Blur API.
>>>
>>>
>>>
>>> Hi there!
>>>
>>> We discussed this yesterday in the OWP Security&Privacy review and had a
>>> couple of questions/remarks:
>>> - Using underlying platform APIs is fine as long as all providers are
>>> aware that they are going to receive random content from the internet. It's
>>> important because they are often more privileged than Chrome. We should
>>> strongly fuzz these API to verify that they meet the bar.
>>>
>>> *[Bhaumik, Rijubrata**] The only source for Background Blur API is
>>> client-side camera via getUserMedia() and the native API is going to do the
>>> entire processing on the client. The native APIs does in-stream correction.
>>> Only then is the "blurred" stream sent to the internet.*
>>>
>>>
>>> - From reading the spec it seems possible to obtain a MediaStreamTrack
>>> that contains arbitrary data and to apply background blur to it. Is that
>>> correct? If that's the case, then it makes fuzzing even more important.
>>>
>>> *[Bhaumik, Rijubrata] **Actually, the implementation [**CL*
>>> *]
>>> does not itself apply background blur but it instead requests camera
>>> (drivers) to apply background blur so that the browser gets video frames
>>> whose background is blurred. I am not sure if it’s possible for the browser
>>> to retrieve unblurred video frames and try to apply background blur
>>> constraint to (frames originating from a canvas) those video frames, but
>>> this implementation does not do that. *
>>>
>>>
>>> - With this change we know via constraints when the system has already
>>> blurred the image right? I imagine you get this information only after
>>> you've queried a MediaStreamTrack?
>>>
>>> *[Bhaumik, Rijubrata] **Yes, it is possible to know via the
>>> MediaStreamTrack’s settings the current background blurring is in effect
>>> (whether it is due to a system wide default or due to a constraints applied
>>> by a web application). The MediaStreamTrack’s settings are only available
>>> after a web application has requested to get a MediaStream and the user has
>>> granted that.*
>>>
>>>
>>>
>>> Thanks!
>>> Arthur
>>>
>>> On Wednesday, June 29, 2022 at 10:16:55 AM UTC+2 rijubrat...@intel.com
>>> wrote:
>>>
>>> Thanks Ken,
>>>
>>>
>>>
>>>1. segmentation result - a grayscale mask : Yes, Harald (Google) did
>>>c

Re: [blink-dev] Intent to Ship: Use Non-Transitional IDNA Processing in URLs

['Harald Alvestrand' via blink-dev]

This IDNA 2008 author applauds your decision.


On Mon, Nov 28, 2022 at 10:16 PM Mustafa Emre Acer 
wrote:

> Contact emailsmea...@chromium.org
>
> Specificationhttps://unicode.org/reports/tr46
>
> Summary
>
> Enable IDNA 2008 in Non-Transitional Mode for URL processing, aligning
> Chrome's behavior with Firefox and Safari. Chrome currently uses IDNA 2008
> in Transitional Mode in URL processing. The main difference between
> Transitional and Non-Transitional Mode is the handling of four characters
> known as deviation characters: ß (LATIN SMALL LETTER SHARP S), ς (GREEK
> SMALL LETTER FINAL SIGMA), ZWJ (Zero width joiner) and ZWNJ (Zero width
> non-joiner). In Transitional mode, deviation characters are handled the
> same as IDNA2003: ß is mapped to ss, ς is mapped to σ, and ZWJ and ZWNJ are
> deleted. In Non-Transitional mode, domains containing these characters are
> allowed in domain names without mapping, and thus can resolve to different
> IP addresses. For example, typing "faß.de " in Chrome and
> Firefox opens different sites today. Enabling Non-Transitional IDNA in
> Chrome will allow deviation characters in domain names. Firefox and Safari
> already made this change in 2016 and continue to use Non-Transitional URL
> processing.
>
>
> Blink componentUI>Security>UrlFormatting
> 
>
> Search tagsidna 
>
> TAG reviewThis feature addresses conformance to an existing spec and
> other browsers already do it.
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
>
>
> *Gecko*: Shipped/Shipping (
> https://bugzilla.mozilla.org/show_bug.cgi?id=1218179)
>
> *WebKit*: Shipped/Shipping (
> https://trac.webkit.org/changeset/208902/webkit)
>
> *Web developers*: No signals
>
> *Other signals*:
>
> Security
>
> This change introduces a potential security issue where a domain pointing
> to one IP may start pointing to another IP. As an example, IDNA2003 and
> Transitional IDNA-2008 maps faß.de  to fass.de (ß is a
> deviation character). Non-Transitional IDNA2008 maps it to xn--fa-hia.de
> which is the punycode representation of faß.de . Typing "
> faß.de " in Chrome and Firefox currently opens different
> sites. Main mitigations discussed were domain bundling / blocking where
> registrars bundle domain names (e.g. registering faß.de 
> along with fass.de) or block the alternative domain name (e.g. disallow
> faß.de  if fass.de is registered). According to data from
> Chrome 106 and 107: - Less than 0.001% of user-typed or pasted main frame
> navigations had a deviation character in the hostname. This excludes link
> clicks and renderer initiated navigations, so the percentage of affected
> domains among all navigations is even lower. - Only one hostname had a
> deviation character and had more than 50 impressions over a 28 day period (
> fußball.de ). Both fußball.de 
> and fussball.de have the same owner so this change doesn't affect them.
> Thus, typing domain names with deviation characters is very rare. Domain
> bundling / blocking aren't blockers as this change won't have a significant
> impact on navigations. Finally, Firefox and Safari have been using
> Non-Transitional IDNA 2008 since 2016 without issues.
>
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such that
> it has potentially high risk for Android WebView-based applications?
>
>
>
> Debuggability
>
>
>
> 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
>
> DevTrial instructions
> https://bugs.chromium.org/p/chromium/issues/detail?id=694157#c70
>
> Flag nameuse-idna2008-non-transitional
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=694157
>
> Launch bughttps://launch.corp.google.com/launch/4224656
>
> Estimated milestones
> DevTrial on desktop 110
> DevTrial on Android 110
>
> Anticipated spec changes
>
> Open questions about a feature may be a source of future web compat or
> interop issues. Please list open issues (e.g. links to known github issues
> in the project for the feature specification) whose resolution may
> introduce web compat/interop risk (e.g., changing to naming or structure of
> the API in a non-backward-compatible way).
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5105856067141632
>
> This intent message was generated by Chrome Platform Status
> .
>
> --
> You received this message because you are subscribed to the Google Group

[blink-dev] Intent to Prototype: WebRTC encoded transform - Clone and Modify functions

['Harald Alvestrand' via blink-dev]

Contact emails...@chromium.org

Explainerhttps://github.com/w3c/webrtc-encoded-transform/pull/164

Specificationhttps://github.com/w3c/webrtc-encoded-transform/pull/163

Summary

Add features to the WebRTC Encoded Transform API that allow: - Creating
frames - Cloning frames - Manipulating frame metadata Background: A number
of use cases have been identified that require the manipulation of WebRTC
encoded media without decoding them first. These include: - Sending data
that has been encoded previously - Sending data that has been received in
encoded form - Receiving data in encoded form and storing it These will be
supported by the new functions. Issue link:
https://github.com/w3c/webrtc-nv-use-cases/issues/77


Blink componentBlink>WebRTC


Motivation

These features are needed to support use cases that involve manipulation of
encoded video / audio frames beyond inline processing on a single
RTCPeerConnection. Use cases:
https://github.com/w3c/webrtc-nv-use-cases/issues/77


Initial public proposal
https://github.com/w3c/webrtc-encoded-transform/pull/164

TAG review

TAG review statusPending

Risks


Interoperability and Compatibility



*Gecko*: No signal

*WebKit*: No signal

*Web developers*: No signals

*Other signals*:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that
it has potentially high risk for Android WebView-based applications?



Debuggability



Is this feature fully tested by web-platform-tests

?No (not yet)

Flag nameTBA

Requires code in //chrome?False

Tracking bughttps://crbug.com/1393964

Estimated milestones

No milestones specified


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

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

Re: [blink-dev] Intent to remove: Shortened IPv4 addresses in the URL

['Harald Alvestrand' via blink-dev]

The two addresses here are IPv6 addresses, not IPv4 addresses, as evidenced
by the :: marker.
The first form is an IPv6 with embedded IPv4, and it has a trailing dot
that I do not understand at all, I think it's not legal syntax.
The second form is two numbers in hex, so the byte value of the last 4
bytes should be 0x01020003. Which would be equivalent to the first one if
there was no trailing dot, because that's the shape of an IPv4 Class B
address, where the last number represents a 16-bit number, not an 8-bit
number.

I'm not sure what you mean by "shortened IPv4 address" - if you mean IPv4
addresses with less than 3 dots (class B and class A addresses, when
classes existed) -  I think that they are indeed rarely used, since modern
IPv4 networks aren't allocated in classes any more.

I would want to check with other browser vendors on whether they think it's
worth deprecating this syntax - it's been standardized since IPv4 was
introduced, so it's a LONG tradition that you are breaking, and unless we
agree with the others first, we're breaking compatibility.

Harald


On Wed, Jan 25, 2023 at 4:52 PM 'Jiacheng Guo' via blink-dev <
blink-dev@chromium.org> wrote:

> Hi everyone
>
> I plan to remove the shortened IPv4 address support in the URLs such as
> 127.1 and 192.168.1.
> WPT failures are reported because of this:
> : Setting .host = '[::1.2.3.]'!EQ("
> http://example.net/";, "http://[::102:3]/";)
>
> I've added an UMA to collect data about whether people are inputting such
> kinds of addresses in the omnibox.
> Data in beta showed that only 0.04% of IPv4 addresses input in the omnibox
> URL are in this form.
> We'd like to remove the support as a part of the URL interop.
>
> Jiacheng Guo
>
> --
> 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/CAJQw1Nx7a-wCL30hB3fdrNkkPYscrQLSDcjVn%2BLidG7OqreJPw%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOqqYVFYUBVc8-nJQN%3DXMLeM3_x%3DKAiqtq_hOo-U4uEX%3DkyoMw%40mail.gmail.com.

Re: [blink-dev] Intent to remove: Shortened IPv4 addresses in the URL

['Harald Alvestrand' via blink-dev]

Checking the spec is always wise:

https://www.rfc-editor.org/rfc/rfc3986#section-3.2.2 says that only the
4-digit form of IPv4 address should be supported (4 numbers from 0-255).
There is no trailing dot, so that one is illegal.

The RFC goes on to say ( https://www.rfc-editor.org/rfc/rfc3986#section-7.4
) about the non-4-number form:

"These additional IP address formats are not allowed in the URI syntax

   due to differences between platform implementations.  However, they
   can become a security concern if an application attempts to filter
   access to resources based on the IP address in string literal format.
   If this filtering is performed, literals should be converted to
   numeric form and filtered based on the numeric value, and not on a
   prefix or suffix of the string form."


So we've been inconsistent with the IETF URI spec since at least 2005,
and it may be time to fix the bug.

But properly!



On Wed, Jan 25, 2023 at 11:22 PM Harald Alvestrand  wrote:

> The two addresses here are IPv6 addresses, not IPv4 addresses, as
> evidenced by the :: marker.
> The first form is an IPv6 with embedded IPv4, and it has a trailing dot
> that I do not understand at all, I think it's not legal syntax.
> The second form is two numbers in hex, so the byte value of the last 4
> bytes should be 0x01020003. Which would be equivalent to the first one if
> there was no trailing dot, because that's the shape of an IPv4 Class B
> address, where the last number represents a 16-bit number, not an 8-bit
> number.
>
> I'm not sure what you mean by "shortened IPv4 address" - if you mean IPv4
> addresses with less than 3 dots (class B and class A addresses, when
> classes existed) -  I think that they are indeed rarely used, since modern
> IPv4 networks aren't allocated in classes any more.
>
> I would want to check with other browser vendors on whether they think
> it's worth deprecating this syntax - it's been standardized since IPv4 was
> introduced, so it's a LONG tradition that you are breaking, and unless we
> agree with the others first, we're breaking compatibility.
>
> Harald
>
>
> On Wed, Jan 25, 2023 at 4:52 PM 'Jiacheng Guo' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Hi everyone
>>
>> I plan to remove the shortened IPv4 address support in the URLs such as
>> 127.1 and 192.168.1.
>> WPT failures are reported because of this:
>> : Setting .host = '[::1.2.3.]'!EQ("
>> http://example.net/";, "http://[::102:3]/";)
>>
>> I've added an UMA to collect data about whether people are inputting such
>> kinds of addresses in the omnibox.
>> Data in beta showed that only 0.04% of IPv4 addresses input in the
>> omnibox URL are in this form.
>> We'd like to remove the support as a part of the URL interop.
>>
>> Jiacheng Guo
>>
>> --
>> 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/CAJQw1Nx7a-wCL30hB3fdrNkkPYscrQLSDcjVn%2BLidG7OqreJPw%40mail.gmail.com
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOqqYVFvZe97aGdvtWr82eUWXsNS%3DRGsq5tuK7D8bWH%2Bx36v8w%40mail.gmail.com.

Re: [blink-dev] Intent to remove: Shortened IPv4 addresses in the URL

['Harald Alvestrand' via blink-dev]

Personal opinion:
Disallowing the trailing dots should not cause any issues at all; I think
we should just do this (as a bug fix).

Since the W3C standard and the IETF standard agree on only permitting the
4-number form embedded in IPv6 addresses, i think it's a safe change to
police that restriction too.

The shortening of pure IPv4 literal addresses is the only case where it
might be reasonable to measure usage; I suppose that's the one you've been
measuring already.


On Thu, Jan 26, 2023 at 6:33 AM Jiacheng Guo  wrote:

> Much thanks for your advice and checking the standard for the correct
> behavior.
> I'd like to provide some more detailed context here.
> The proposed change is a part of the URL section in interop 2023.
> Currently our URL parser treats [::1.2.3.] as shortened IPv4 addresses
> embedded in IPv6 and this is causing a bunch of WPT test failures.
> The URL RFC requires IPv4 address to consist of concisely four parts.
> I revisited the URL web standard and it found that it allows shortened
> IPv4 addresses without trailing dots and disallows embedding them into IPv6
> addresses.
>
> Currently in chrome:
> - We are not validating the trailing dots in IPv4 and IPv4-embedded IPv6
> addresses.
> - We allow shortened IPv4 addresses and embedding them into IPv6 addresses.
>
> My new proposal is to check the trailing dots in IP addresses and remove
> support for embedding shortened IPv4 addresses in IPv6 addresses.
> Does this make sense? Would you advise additional usage metrics to be
> collected?
>
> Much appreciated
> Jiacheng Guo
>
> On Thu, Jan 26, 2023 at 7:29 AM Harald Alvestrand  wrote:
>
>> Checking the spec is always wise:
>>
>> https://www.rfc-editor.org/rfc/rfc3986#section-3.2.2 says that only the
>> 4-digit form of IPv4 address should be supported (4 numbers from 0-255).
>> There is no trailing dot, so that one is illegal.
>>
>> The RFC goes on to say (
>> https://www.rfc-editor.org/rfc/rfc3986#section-7.4 ) about the
>> non-4-number form:
>>
>> "These additional IP address formats are not allowed in the URI syntax
>>
>>due to differences between platform implementations.  However, they
>>can become a security concern if an application attempts to filter
>>access to resources based on the IP address in string literal format.
>>If this filtering is performed, literals should be converted to
>>numeric form and filtered based on the numeric value, and not on a
>>prefix or suffix of the string form."
>>
>>
>> So we've been inconsistent with the IETF URI spec since at least 2005, and 
>> it may be time to fix the bug.
>>
>> But properly!
>>
>>
>>
>> On Wed, Jan 25, 2023 at 11:22 PM Harald Alvestrand 
>> wrote:
>>
>>> The two addresses here are IPv6 addresses, not IPv4 addresses, as
>>> evidenced by the :: marker.
>>> The first form is an IPv6 with embedded IPv4, and it has a trailing dot
>>> that I do not understand at all, I think it's not legal syntax.
>>> The second form is two numbers in hex, so the byte value of the last 4
>>> bytes should be 0x01020003. Which would be equivalent to the first one if
>>> there was no trailing dot, because that's the shape of an IPv4 Class B
>>> address, where the last number represents a 16-bit number, not an 8-bit
>>> number.
>>>
>>> I'm not sure what you mean by "shortened IPv4 address" - if you mean
>>> IPv4 addresses with less than 3 dots (class B and class A addresses, when
>>> classes existed) -  I think that they are indeed rarely used, since modern
>>> IPv4 networks aren't allocated in classes any more.
>>>
>>> I would want to check with other browser vendors on whether they think
>>> it's worth deprecating this syntax - it's been standardized since IPv4 was
>>> introduced, so it's a LONG tradition that you are breaking, and unless we
>>> agree with the others first, we're breaking compatibility.
>>>
>>> Harald
>>>
>>>
>>> On Wed, Jan 25, 2023 at 4:52 PM 'Jiacheng Guo' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
 Hi everyone

 I plan to remove the shortened IPv4 address support in the URLs such as
 127.1 and 192.168.1.
 WPT failures are reported because of this:
 : Setting .host = '[::1.2.3.]'!EQ("
 http://example.net/";, "http://[::102:3]/";)

 I've added an UMA to collect data about whether people are inputting
 such kinds of addresses in the omnibox.
 Data in beta showed that only 0.04% of IPv4 addresses input in the
 omnibox URL are in this form.
 We'd like to remove the support as a part of the URL interop.

 Jiacheng Guo

 --
 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/CAJQw1Nx7a-wCL30hB3fdrNkkPYscrQLSDcjVn%2BLidG7OqreJPw

Re: [blink-dev] Intent to Deprecate and Remove: WebRTC's RTCStats of type "track" and "stream".

['Harald Alvestrand' via blink-dev]

I'm not sure an enterprise policy is appropriate - I see the same problem
with sunsetting the policy as with sunsetting the stat in general, and
usage of enterprise policies is (as far as I know) far more opaque to us
than origin trials or Finch feature usage.


On Mon, Jan 30, 2023 at 11:13 AM Henrik Boström  wrote:

>
>
> On Friday, January 27, 2023 at 7:24:58 PM UTC+1 Johnny Stenback wrote:
> Is there an enterprise policy in place for this deprecation already? If
> not, adding one seems appropriate given the challenges of rolling out even
> simple fixes in some enterprise environments.
>
> One does not exist at the moment but I can add one
> 
> .
>
>
> Thanks,
> Johnny
>
> On Fri, Jan 27, 2023 at 5:16 AM Henrik Boström  wrote:
> Delaying the enabled-by-default to M112 is fine by me but I'll wait for a
> resolution here before taking action. Currently it is enabled-by-default in
> Canary.
>
> On Friday, January 27, 2023 at 12:41:23 PM UTC+1 philipp...@googlemail.com
> wrote:
> Am Fr., 27. Jan. 2023 um 11:49 Uhr schrieb Henrik Boström <
> h...@chromium.org>:
> *Contact emails*
> h...@chromium.org, h...@chromium.org
>
> *Background*
> I attempted to remove this feature before but had forgotten to file an
> intent to deprecate, background here
> .
>
> *Specification*
> The getStats() API spec is here  and
> it contains all the metrics. The deprecated metrics are also listed, but in
> the obsolete section
> .
> There's an open issue to remove obsolete metrics from the spec as soon as
> they are unshipped from modern browsers. This is considered a blocker for
> the document to reach Proposed Recommendation status.
>
> *Summary*
> WebRTC is a set of JavaScript APIs (spec
> ) that allow real-time communication
> between browsers. For the relevant metrics being removed, we're only
> talking about the WebRTC use case that is sending or receiving audio or
> video (typically Video Conferencing use cases), not the data channel use
> cases that is a popular WebRTC use case, since data channel only use cases
> would never have any tracks/streams.
>
> RTCPeerConnection.getStats() returns a map of string-to-objects, where
> each object is one of the dictionaries defined in the stats spec. The
> reason an app calls getStats() is mostly to report quality metrics (send
> and receive resolutions, bitrates, glitches, video QP, etc) which can be
> important for A/B experimentation. It can also be used in a way that
> impacts app logic or even UX inside the app. Most common use case I can
> think of: poll getStats() at 10 Hz and render volume bars for each
> participant based on volume levels from stats objects.
>
> The deprecation in question is to remove some stats objects that were made
> obsolete several years ago: all metrics on the "track" dictionary have been
> moved to non-obsolete objects ("inbound-rtp", "outbound-rtp",
> "media-source"). Reasons for wanting to deprecate include:
>
>- Spec-compliance: needed for browser implementations to align and for
>the spec to become Proposed Recommendation.
>- Web compat: Firefox never implement "track" or "steam"
>
> 
>  due
>to them being obsolete.
>- Performance: the duplicated metrics make up ~40% of the stats report
>size, which can be a significant number of bytes in larger meetings and it
>is common for apps to poll getStats() 10 times per second.
>- Tech debt: unblock removal of 1400 LOC.
>
> In the meantime, the obsolete metrics is duplicated in several places of
> the stats report.
>
> *Risks*
> *- Impossible to properly measure usage*
> Because stats objects are exposed as JavaScript dictionaries, and because
> apps have to iterate all objects of the stats report in order to find the
> ones they are interested in or if they just dump all the data without
> filtering, there is no way to measure how big the dependency is on track in
> the real world.
>
> While we lack use counters, we have some positive signs:
>
>- Because Firefox does not have "track" or "stream" stats, any app
>that can run on Firefox already exercises the paths of these not existing.
>
>
>- An experiment to "unship deprecated metrics" has been running at 50%
>Canary since October
>
> ,
>giving developers testing Canary a heads-up. Nobody complained until the
>experiment reached Stable.
>- We got to 50% Stable in M109 and while we're in the process of
>rolling it back now due to breaking twilio-video.js
>

Re: [blink-dev] Intent to Deprecate and Remove: WebRTC's RTCStats of type "track" and "stream".

['Harald Alvestrand' via blink-dev]

What's the imagined scenario in which an enterprise policy would be useful?

The only place I could imagine it being relevant is if there exists a
WebRTC application that is only used within a single enterprise (neither
hosting nor usage exists outside the enterprise), and that WebRTC
application depends on non-upgraded Twilio libraries.

I don't know that we have evidence that such applications exist.



On Fri, Feb 3, 2023 at 6:14 PM Mike Taylor  wrote:

> I agree with Johnny that an enterprise policy would be useful, at least
> for a few milestones.
>
> On 1/30/23 5:16 AM, 'Harald Alvestrand' via blink-dev wrote:
>
> I'm not sure an enterprise policy is appropriate - I see the same problem
> with sunsetting the policy as with sunsetting the stat in general, and
> usage of enterprise policies is (as far as I know) far more opaque to us
> than origin trials or Finch feature usage.
>
>
> On Mon, Jan 30, 2023 at 11:13 AM Henrik Boström  wrote:
>
>>
>>
>> On Friday, January 27, 2023 at 7:24:58 PM UTC+1 Johnny Stenback wrote:
>> Is there an enterprise policy in place for this deprecation already? If
>> not, adding one seems appropriate given the challenges of rolling out even
>> simple fixes in some enterprise environments.
>>
>> One does not exist at the moment but I can add one
>> <https://chromium.googlesource.com/chromium/src/+/HEAD/docs/enterprise/add_new_policy.md>
>> .
>>
>>
>> Thanks,
>> Johnny
>>
>> On Fri, Jan 27, 2023 at 5:16 AM Henrik Boström  wrote:
>> Delaying the enabled-by-default to M112 is fine by me but I'll wait for a
>> resolution here before taking action. Currently it is enabled-by-default in
>> Canary.
>>
>> On Friday, January 27, 2023 at 12:41:23 PM UTC+1
>> philipp...@googlemail.com wrote:
>> Am Fr., 27. Jan. 2023 um 11:49 Uhr schrieb Henrik Boström <
>> h...@chromium.org>:
>> *Contact emails*
>> h...@chromium.org, h...@chromium.org
>>
>> *Background*
>> I attempted to remove this feature before but had forgotten to file an
>> intent to deprecate, background here
>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/RsIktnGhHqw/>.
>>
>> *Specification*
>> The getStats() API spec is here <https://w3c.github.io/webrtc-stats/> and
>> it contains all the metrics. The deprecated metrics are also listed, but in
>> the obsolete section
>> <https://w3c.github.io/webrtc-stats/#obsolete-rtcmediastreamtrackstats-members>.
>> There's an open issue to remove obsolete metrics from the spec as soon as
>> they are unshipped from modern browsers. This is considered a blocker for
>> the document to reach Proposed Recommendation status.
>>
>> *Summary*
>> WebRTC is a set of JavaScript APIs (spec
>> <https://w3c.github.io/webrtc-pc/>) that allow real-time communication
>> between browsers. For the relevant metrics being removed, we're only
>> talking about the WebRTC use case that is sending or receiving audio or
>> video (typically Video Conferencing use cases), not the data channel use
>> cases that is a popular WebRTC use case, since data channel only use cases
>> would never have any tracks/streams.
>>
>> RTCPeerConnection.getStats() returns a map of string-to-objects, where
>> each object is one of the dictionaries defined in the stats spec. The
>> reason an app calls getStats() is mostly to report quality metrics (send
>> and receive resolutions, bitrates, glitches, video QP, etc) which can be
>> important for A/B experimentation. It can also be used in a way that
>> impacts app logic or even UX inside the app. Most common use case I can
>> think of: poll getStats() at 10 Hz and render volume bars for each
>> participant based on volume levels from stats objects.
>>
>> The deprecation in question is to remove some stats objects that were
>> made obsolete several years ago: all metrics on the "track" dictionary have
>> been moved to non-obsolete objects ("inbound-rtp", "outbound-rtp",
>> "media-source"). Reasons for wanting to deprecate include:
>>
>>- Spec-compliance: needed for browser implementations to align and
>>for the spec to become Proposed Recommendation.
>>- Web compat: Firefox never implement "track" or "steam"
>>
>> <https://wpt.fyi/results/webrtc-stats/supported-stats.https.html?label=experimental&label=master&aligned>
>>  due
>>to them being obsolete.
>>- Performance: the duplicated metrics make up ~40% of the stats
>>report size, whi

Re: [blink-dev] Intent to Prototype: Deprecate support for URLs with non-IPv4 hostnames ending in numbers

['Harald Alvestrand' via blink-dev]

Department of odd facts:

- The ICANN rules for new TLDs forbid all top level domain names that start
with a digit
- The IDNA rules for bidirectional scripts forbid domain names that start
with a digit (Unicode bidi afficandoes will know why)
- The only real reason why leading digits aren't outlawed in domain names
at the second level is 3com.

It seems safe to say that no legitimate fully qualified hostname will ever
have a last component consisting only of digits.
That means the only time we could get a legitimate hostname is for
something that has to be resolved via a search path.


On Thu, Aug 19, 2021 at 2:33 PM Yoav Weiss  wrote:

>
>
> On Thu, Aug 19, 2021 at 2:28 PM Matt Menke  wrote:
>
>> I created the title using Chrome Status's deprecation template, so any
>> confusion should be blamed on that.
>>
>
> +Jason Robbins  - on the title issues.
>
>
>>
>> I used the "Draft Intent to Deprecate and Remove email" button, and
>> assume I'd need to do a "Draft Intent to Ship email" before shipping to
>> stable, after a 50% trial on prerelease channels.
>>
>
> There's no need for 2 emails for removals. We can discuss the full
> deprecation, experimentation/trials and removal on stable here.
>
>
>>
>> On Thu, Aug 19, 2021 at 3:15 AM Yoav Weiss 
>> wrote:
>>
>>>
>>> On Wed, Aug 18, 2021 at 11:36 PM Matt Menke  wrote:
>>>


 On Wed, Aug 18, 2021 at 5:23 PM Yoav Weiss 
 wrote:

>
>
> On Wed, Aug 18, 2021 at 11:18 PM Matt Menke  wrote:
>
>> On Wed, Aug 18, 2021 at 4:53 PM Yoav Weiss 
>> wrote:
>>
>>>
>>>
>>> On Wed, Aug 18, 2021 at 8:47 PM 'Matt Menke' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
 Contact emailsmme...@google.com

 ExplainerNone

 Specificationhttps://url.spec.whatwg.org/

 Summary

 Most hostnames that aren't valid IPv4 addresses, but end in numbers
 are treated as valid, and looked up via DNS (e.g.,
 http://foo.127.1/). Per the Public Suffix List spec, the eTLD+1 of
 the hostname in that URL should be "127.1". If that is ever fed back 
 into a
 URLs, "http://127.1/ " is mapped to "
 http://127.0.0.1/"; by the URL spec, which seems potentially
 dangerous. "127.0.0.0.1" could also potentially be used to confuse 
 users.
 We want to reject URLs with these hostnames.


 Blink componentInternals>Network>DNS
 

 Motivation

 Most hostnames that aren't valid IPv4 addresses, but end in numbers
 are treated as valid hostnames, and looked up via DNS. Example 
 hostnames:
 127.0.0.0.1, foo.0.1, 10.0.0.09, 08.1.2.3. These can be problematic 
 for the
 following reason: * "http://foo.127.1/"; has an eTLD+1 of "127.1",
 per the public suffix list spec. If that's ever used as the hostname 
 in a
 new URL, however, as in "http://127.1 ", it
 will then get mapped to "http://127.0.0.1/";, per the URL spec,
 which is a different host, which is not safe. * "http://127.0.0.0.1";
 and "http://1.2.3.09";, both of which are looked up via DNS rather
 than failing or being treated as IPv4 hostnames, also seem potentially
 confusing. While no exploit is currently known here, we want to remove
 support for these as a preventative security measure. The URL spec has 
 been
 updated so that any URL with a hostname ending in a number that's not 
 an
 IPv4 address (including, e.g., http://foo.1./, but not
 http://foo.1../) is considered invalid. Since this is part of the
 URL spec, not the DNS spec, we want to reject these URLs are the GURL
 layer, for URLs with appropriate protocols (http, https, ws, wss, 
 file).
 For consistency, we should also fail DNS lookup attempts of these 
 sorts of
 hostnames.


 Initial public proposalhttps://github.com/whatwg/url/pull/619

 TAG reviewNot required for an Intent to Deprecate, I believe.

 TAG review statusNot applicable

 Risks


 Interoperability and Compatibility

 Any URL with an affected hostname will fail to load, and will need
 to be migrated to another hostname. URLs of this form do appear to be 
 in
 use, though it's not clear under what circumstances. No entry in the 
 public
 suffix list is affected. Affected URLs make up no more than 0.0003% of
 hostnames looked up via the host resolver on any platform, and are
 basically not used in any file URLs, according to our metrics.

>>>
>>> Do we hav

Re: [blink-dev] Intent to Prototype: Deprecate support for URLs with non-IPv4 hostnames ending in numbers

['Harald Alvestrand' via blink-dev]

An interesting property of all-numeric hostnames is that they *may* be
legitimate IPv4 addresses using highly archaic IP address formats - we're
so used to the 123.45.67.89 syntax that we forget that 31533.67.89 once was
regarded as a legitimate way to encode the same address (class B notation).

There are also certain resolvers that will "helpfully" map an all-numeric
hostname presented in DNS to an IP address without asking anyone.
So if those two bugs (or "archaic features") occur together, the result may
be a successful resolution.

No idea why it would occur more often on Android than on Windows, though.
And my Linux boxes don't resolve 127.0.1 to anything.



On Thu, Aug 19, 2021 at 2:42 PM Yoav Weiss  wrote:

> Interesting! What happens then in the "successful resolution" case Matt
> mentioned?
>
> On Thu, Aug 19, 2021 at 2:39 PM Harald Alvestrand  wrote:
>
>> Department of odd facts:
>>
>> - The ICANN rules for new TLDs forbid all top level domain names that
>> start with a digit
>> - The IDNA rules for bidirectional scripts forbid domain names that start
>> with a digit (Unicode bidi afficandoes will know why)
>> - The only real reason why leading digits aren't outlawed in domain names
>> at the second level is 3com.
>>
>> It seems safe to say that no legitimate fully qualified hostname will
>> ever have a last component consisting only of digits.
>> That means the only time we could get a legitimate hostname is for
>> something that has to be resolved via a search path.
>>
>>
>> On Thu, Aug 19, 2021 at 2:33 PM Yoav Weiss 
>> wrote:
>>
>>>
>>>
>>> On Thu, Aug 19, 2021 at 2:28 PM Matt Menke  wrote:
>>>
 I created the title using Chrome Status's deprecation template, so any
 confusion should be blamed on that.

>>>
>>> +Jason Robbins  - on the title issues.
>>>
>>>

 I used the "Draft Intent to Deprecate and Remove email" button, and
 assume I'd need to do a "Draft Intent to Ship email" before shipping to
 stable, after a 50% trial on prerelease channels.

>>>
>>> There's no need for 2 emails for removals. We can discuss the full
>>> deprecation, experimentation/trials and removal on stable here.
>>>
>>>

 On Thu, Aug 19, 2021 at 3:15 AM Yoav Weiss 
 wrote:

>
> On Wed, Aug 18, 2021 at 11:36 PM Matt Menke  wrote:
>
>>
>>
>> On Wed, Aug 18, 2021 at 5:23 PM Yoav Weiss 
>> wrote:
>>
>>>
>>>
>>> On Wed, Aug 18, 2021 at 11:18 PM Matt Menke 
>>> wrote:
>>>
 On Wed, Aug 18, 2021 at 4:53 PM Yoav Weiss 
 wrote:

>
>
> On Wed, Aug 18, 2021 at 8:47 PM 'Matt Menke' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Contact emailsmme...@google.com
>>
>> ExplainerNone
>>
>> Specificationhttps://url.spec.whatwg.org/
>>
>> Summary
>>
>> Most hostnames that aren't valid IPv4 addresses, but end in
>> numbers are treated as valid, and looked up via DNS (e.g.,
>> http://foo.127.1/). Per the Public Suffix List spec, the eTLD+1
>> of the hostname in that URL should be "127.1". If that is ever fed 
>> back
>> into a URLs, "http://127.1/ " is mapped to "
>> http://127.0.0.1/"; by the URL spec, which seems potentially
>> dangerous. "127.0.0.0.1" could also potentially be used to confuse 
>> users.
>> We want to reject URLs with these hostnames.
>>
>>
>> Blink componentInternals>Network>DNS
>> 
>>
>> Motivation
>>
>> Most hostnames that aren't valid IPv4 addresses, but end in
>> numbers are treated as valid hostnames, and looked up via DNS. 
>> Example
>> hostnames: 127.0.0.0.1, foo.0.1, 10.0.0.09, 08.1.2.3. These can be
>> problematic for the following reason: * "http://foo.127.1/"; has
>> an eTLD+1 of "127.1", per the public suffix list spec. If that's 
>> ever used
>> as the hostname in a new URL, however, as in "http://127.1
>> ", it will then get mapped to "
>> http://127.0.0.1/";, per the URL spec, which is a different host,
>> which is not safe. * "http://127.0.0.0.1"; and "http://1.2.3.09";,
>> both of which are looked up via DNS rather than failing or being 
>> treated as
>> IPv4 hostnames, also seem potentially confusing. While no exploit is
>> currently known here, we want to remove support for these as a 
>> preventative
>> security measure. The URL spec has been updated so that any URL with 
>> a
>> hostname ending in a number that's not an IPv4 address (including, 
>> e.g.,
>> http://foo.1./, but not http://foo.1../) is considered invalid.
>> Since this i

Re: [blink-dev] Intent to Prototype: Deprecate support for URLs with non-IPv4 hostnames ending in numbers

['Harald Alvestrand' via blink-dev]

Thanks - I misremembered which end of the class B network got jammed
together. 67.89.31533 is indeed the one that is "legal" syntax, and so of
course 67.89.1 is too.


On Thu, Aug 19, 2021 at 3:20 PM Matt Menke  wrote:

> Note that 127.0.1 is mapped to 127.0.0.1 by GURL, following the URL spec,
> so that would generally not make it to the DNS resolver (unless something
> tried to resolve it directly).  Per the URL spec, "31533.67.89" would not
> be normalized by GURL, but "67.89.31533" would be converted to
> 67.89.123.45.  My instrumentation was at the DNS layer, so "127.0.1" and
> "67.89.31533" would not show up as problematic hostnames in my metrics,
> though "31533.67.89" would.
>
> On Thu, Aug 19, 2021 at 9:10 AM Harald Alvestrand  wrote:
>
>> An interesting property of all-numeric hostnames is that they *may* be
>> legitimate IPv4 addresses using highly archaic IP address formats - we're
>> so used to the 123.45.67.89 syntax that we forget that 31533.67.89 once was
>> regarded as a legitimate way to encode the same address (class B notation).
>>
>> There are also certain resolvers that will "helpfully" map an all-numeric
>> hostname presented in DNS to an IP address without asking anyone.
>> So if those two bugs (or "archaic features") occur together, the result
>> may be a successful resolution.
>>
>> No idea why it would occur more often on Android than on Windows, though.
>> And my Linux boxes don't resolve 127.0.1 to anything.
>>
>>
>>
>> On Thu, Aug 19, 2021 at 2:42 PM Yoav Weiss 
>> wrote:
>>
>>> Interesting! What happens then in the "successful resolution" case Matt
>>> mentioned?
>>>
>>> On Thu, Aug 19, 2021 at 2:39 PM Harald Alvestrand 
>>> wrote:
>>>
 Department of odd facts:

 - The ICANN rules for new TLDs forbid all top level domain names that
 start with a digit
 - The IDNA rules for bidirectional scripts forbid domain names that
 start with a digit (Unicode bidi afficandoes will know why)
 - The only real reason why leading digits aren't outlawed in domain
 names at the second level is 3com.

 It seems safe to say that no legitimate fully qualified hostname will
 ever have a last component consisting only of digits.
 That means the only time we could get a legitimate hostname is for
 something that has to be resolved via a search path.


 On Thu, Aug 19, 2021 at 2:33 PM Yoav Weiss 
 wrote:

>
>
> On Thu, Aug 19, 2021 at 2:28 PM Matt Menke  wrote:
>
>> I created the title using Chrome Status's deprecation template, so
>> any confusion should be blamed on that.
>>
>
> +Jason Robbins  - on the title issues.
>
>
>>
>> I used the "Draft Intent to Deprecate and Remove email" button, and
>> assume I'd need to do a "Draft Intent to Ship email" before shipping to
>> stable, after a 50% trial on prerelease channels.
>>
>
> There's no need for 2 emails for removals. We can discuss the full
> deprecation, experimentation/trials and removal on stable here.
>
>
>>
>> On Thu, Aug 19, 2021 at 3:15 AM Yoav Weiss 
>> wrote:
>>
>>>
>>> On Wed, Aug 18, 2021 at 11:36 PM Matt Menke 
>>> wrote:
>>>


 On Wed, Aug 18, 2021 at 5:23 PM Yoav Weiss 
 wrote:

>
>
> On Wed, Aug 18, 2021 at 11:18 PM Matt Menke 
> wrote:
>
>> On Wed, Aug 18, 2021 at 4:53 PM Yoav Weiss <
>> yoavwe...@chromium.org> wrote:
>>
>>>
>>>
>>> On Wed, Aug 18, 2021 at 8:47 PM 'Matt Menke' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
 Contact emailsmme...@google.com

 ExplainerNone

 Specificationhttps://url.spec.whatwg.org/

 Summary

 Most hostnames that aren't valid IPv4 addresses, but end in
 numbers are treated as valid, and looked up via DNS (e.g.,
 http://foo.127.1/). Per the Public Suffix List spec, the
 eTLD+1 of the hostname in that URL should be "127.1". If that is 
 ever fed
 back into a URLs, "http://127.1/ " is
 mapped to "http://127.0.0.1/"; by the URL spec, which seems
 potentially dangerous. "127.0.0.0.1" could also potentially be 
 used to
 confuse users. We want to reject URLs with these hostnames.


 Blink componentInternals>Network>DNS
 

 Motivation

 Most hostnames that aren't valid IPv4 addresses, but end in
 numbers are treated as valid hostnames, and looked up via DNS. 
 Example
 hostnames: 127.0.0.0.1, foo.0.1, 10.0.0.09, 08.1.2.3. Thes

[blink-dev] Intent to deprecate and remove: SDES key exchange for WebRTC

['Harald Alvestrand' via blink-dev]

Contact emails...@chromium.org

ExplainerNone

Specificationhttps://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 componentBlink>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 statusNot 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 bughttps://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+unsubscr...@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.

Re: [blink-dev] Intent to deprecate and remove: SDES key exchange for WebRTC

['Harald Alvestrand' via blink-dev]

On Thu, Aug 26, 2021 at 1:10 PM Yoav Weiss  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.


>
> On Thu, Aug 26, 2021 at 11:05 AM 'Philipp Hancke' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> stats here:
>> 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 :
>>
>>> Contact emails...@chromium.org
>>>
>>> ExplainerNone
>>>
>>> Specificationhttps://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 componentBlink>WebRTC>Network
>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EWebRTC%3ENetwork>
>>>
>>> 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 statusNot 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
>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>
>>> ?No
>>>
>>> Flag name
>>>
>>> Requires code in //chrome?False
>>>
>>> Tracking bughttps://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
>>> <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+unsubscr...@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+unsubscr...@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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOqqYVGgQnMQqFJ3Uq4aKHXa9rG2d8k5AKsqugLa62toWCghOA%40mail.gmail.com.

Re: [blink-dev] Intent to deprecate and remove: SDES key exchange for WebRTC

['Harald Alvestrand' via blink-dev]

On Thu, Aug 26, 2021 at 9:29 PM Yoav Weiss  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 
>> 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.


>
>
>>
>>
>>> 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.
>>
>>
>>>
>>> On Thu, Aug 26, 2021 at 11:05 AM 'Philipp Hancke' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
>>>> stats here:
>>>> 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 :
>>>>
>>>>> Contact emails...@chromium.org
>>>>>
>>>>> ExplainerNone
>>>>>
>>>>> Specificationhttps://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 componentBlink>WebRTC>Network
>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EWebRTC%3ENetwork>
>>>>>
>>>>> 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 statusNot 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?
>>>
>>
> Is SDES shipped in other browsers? What's the status there?
>

I believe that neither Firefox nor WebKit ever shipped SDES, but I put "no
signal" because I haven't checked.


>
>
>>
>>>
>>>>
>>>>> Web developers: No signals
>>>>>
>>>>>
>>>>> Debuggabilit

Re: [blink-dev] Intent to deprecate and remove: SDES key exchange for WebRTC

['Harald Alvestrand' via 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.


On Fri, Aug 27, 2021 at 8:22 AM Yoav Weiss  wrote:

>
>
> On Fri, Aug 27, 2021 at 7:31 AM Philipp Hancke <
> philipp.han...@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 
>>> 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 
>>>>> 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?
>
>
>>
>>
>>>
>>>>
>>>>>
>>>>> 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:
>>
>> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/fast/peerconnection/RTCPeerConnection-sdes-constraint.html;l=11;drc=09074552ce314b5d942d960ceaa90599671ee137
>> I'll add a negative assertion as a WPT. Why ask when you can write a test
>> :-)
>>
>>
>>>
>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>> 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.
>>>>>
>>>>>
>>>>>>
>>>>>> On Thu, Aug 26, 2021 at 11:05 AM 'Philipp Hancke' via blink-dev <
>>>>>> blink-dev@chromium.org> wrote:
>>>>>>
>>>>>>> stats here:
>>>>>>> https://www.chromestatus.com/metrics/feature/timeline/popularity/2383
>>>>>>>
>>>>>>
>>>>>> Impressive decline in usage!
>>>>>>
>>>>>>
>>>>>>> Away with it!
>>>>>>>
>>>>>>> Am Do., 26. Aug. 2021