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 <yoavwe...@chromium.org> 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 <yoavwe...@chromium.org> >>> wrote: >>> >>>> A few questions raised at the API OWNERS meeting today. >>>> >>>> On Thursday, August 26, 2021 at 1:34:11 PM UTC+2 Harald Alvestrand >>>> wrote: >>>> >>>>> On Thu, Aug 26, 2021 at 1:10 PM Yoav Weiss <yoavwe...@chromium.org> >>>>> wrote: >>>>> >>>>>> What would breakage look like? >>>>>> >>>>> >>>>> Once the feature is gone (the end state), anyone attempting to set up >>>>> a connection using SDES will have their session rejected. >>>>> Anyone attempting to set the constraint will just have it ignored, >>>>> like any other unsupported value in a dictionary. >>>>> >>>> >>>> OK. Any enterprise risk here? Are you aware of any enterprise apps >>>> using this? >>>> >>> >>> I doubt it. There is no real reason for using it; DTLS is safer and >>> simpler to configure. >>> >> >> I bet there are some callcenters using it on the agent side and being >> callcenters, they won't report metrics. >> The list of vendors is known though. As is the IETF 2013 consensus that >> this is a MUST NOT. >> > > Are there vendors still selling such software nowadays? > > >> >> >>> >>>> >>>>> >>>>> 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 um 10:45 Uhr schrieb 'Harald Alvestrand' via >>>>>>> blink-dev <blink-dev@chromium.org>: >>>>>>> >>>>>>>> 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 >>>>>>>> >>>>>>>> >>>>>>>> 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/CAOqqYVHiYWE8LUwTZT71gH%3DY%3D41iJDdqf_P9SmHkx6NCSDU9ww%40mail.gmail.com.