PSA: Modification of SDP “ufrag” and “passwd” attributes is going away

[Harald Alvestrand]

(If you’re not modifying SDP, you can stop reading now)

The standards for WebRTC have always said that the SDP produced by CreateOffer MUST be passed unchanged to SetLocalDescription 

https://datatracker.ietf.org/doc/html/rfc8829#name-modifying-an-offer-or-answe

https://w3c.github.io/webrtc-pc/#dom-peerconnection-setlocaldescription step 4.2

Unfortunately, this has not been policed in Chrome, and people have taken advantage of this in various ways, some of which are obsoleted by later API extensions, and some of which are actively harmful and should not be permitted.

One of the changes we’ve found to be actively harmful is the ability to modify the “ice-ufrag” and “ice-passwd” attributes. We have therefore decided that in the future, calls to SetLocalDescription that have modified these attributes will be rejected, as specified in the standard.

More restrictions are likely to be enabled further on.

The precise rollout dates have not yet been set.

[林飒明]

Hi Harald. Thank you for your PSA about blocking the munging.

To be honest, our service heavily relies on specific `ice-ufrag` and `ice-passwd` values to make authentication and streamline connection procedures, and this approach has been implemented across thousands of devices, from web to native clients and SFUs. Due to this extensive dependency, removing all non-standard behavior from our entire system will require significant time and resources.

Could you provide an approximate timeline for the planned restrictions on SDP munging? We hope to have sufficient time to correct all non-standard implementations. Thank you for your consideration.

[guest271314]

The standard for MediaStreamTrack of kind audio is clear, too. The track must render silence. However Chromium-based browser do not render silence for MediaStreamTrack of kind audio per the specification. Chromium-based browsers have been non-conformant with the specification for years now https://issues.chromium.org/issues/40799779. 

https://www.w3.org/TR/mediacapture-streams/#life-cycle-and-media-flow

• "A muted or disabled MediaStreamTrack renders either silence (audio) ..."

• "A muted track will however, regardless of the enabled state, render silence ..."

• "The result for the consumer is the same in the sense that whenever MediaStreamTrack is muted or disabled (or both) the consumer gets zero-information-content, which means silence for audio ..."

Can an effort be made to make Chromium-based browser conformant with W3C Media Capture and Streams re MediaStreamTrack of kind audio?

[Philipp Hancke]

you are asking in the wrong thread but note that Chromium is opensource, once you sign the Contributors Licensing Agreement with your real name you can fix the problems (provided the problem and fix is something you can get agreement on).

--
This list falls under the WebRTC Code of Conduct - https://webrtc.org/support/code-of-conduct.
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/discuss-webrtc/c36c0e31-4106-40b8-bffb-c617ebe996bdn%40googlegroups.com.

[guest271314]

I'm just wondering if the WebRTC folks are serious about making sure Chromium-based browsers are up to snuff as to being specification conformant, or if it's just pick and choose which individual aspects of an implementation are conformant, or not. You folks are far more well-suited to fix the Chromium source code. You know the MediaStreamTrack of kind audio implementation is broken. That's not in dispute. The question is are you serious about fixing it, or not.

Been there, done that on the "real name" thing with W3C. guest271314 is my handle on the Interwebs. I don't want ownership of any of your IPR stuff. I'm just hacking Chromium and seeing if you folks care or not if your gear is broken. Thanks.

[PhistucK]

Hey

Just so you know, a real name is actually not required to sign that agreement. I signed with my nickname and their lawyers were fine with it (and I contributed code and it was merged in).

☆PhistucK

To view this discussion visit https://groups.google.com/d/msgid/discuss-webrtc/CADxkKi%2BAa-jE_XvO59QkkWRyLeXNMek0a-jKxLCSwjVgbe99Yw%40mail.gmail.com.

[guest271314]

If we're talking about the https://cla.developers.google.com/about/google-individual I already signed that https://github.com/GoogleChromeLabs/web-audio-samples/pull/198. Different CLA? Same parent entity, right?

[Harald Alvestrand]

Reminder from moderator: Please keep threads on topic.

To view this discussion visit https://groups.google.com/d/msgid/discuss-webrtc/e47037cc-74ad-4e3d-aeb7-3b2a4901ed1bn%40googlegroups.com.

[炫树伍]

Hi, Harald~
Could you confirm if the current changes are confirmed to be included in the M137 release? These changes are impacting our application, and I would like to request additional time to make adjustments and guide users through the upgrade.
Thanks.

[林飒明]

Hi Harald, 

Is there any update about the timeline for the restriction on SDP munging? I discovered a [commit](https://webrtc-review.googlesource.com/c/src/+/385982) that plans to enable this restriction by default. Rolling this out in M137 would not give us sufficient time to adapt our service accordingly. 

We would greatly appreciate if you could consider delaying this implementation to allow us adequate time for necessary adjustments. Thank you for your understanding and consideration.

[Harald Alvestrand]

Given the existence of ongoing abuse of this feature, we are likely to see some rollout in 137, but complete deployment is not likely until 138. We are still discussing mechanisms and timelines.

To view this discussion visit https://groups.google.com/d/msgid/discuss-webrtc/a5f44651-4595-4f07-b2eb-ae70ee1813f2n%40googlegroups.com.

[林飒明]

Hi Harald.

Thank you for your reply. This rollout plan seems too urgent for us and I kindly request to delay this restrcition.

Right now, we get millions of visitors every day and provide the RTC service to several big companies. Most of our customers use Chrome to communicate with others. This restriction will make our service completely unusable for web users on Chrome.

To be honest, we know this restriction is important. Your action is the first step to making WebRTC more standardized and we're also glad to see it. For now, we are rapidly fixing the non-standard usage of `ufrag` and `passwd` and also other usages of RTCPeerConnection APIs gradually. However, it's never an easy job. Our service colleagues have to smoothly apply this change to thousands of server devices. And we also need to encourage our corporate customers to update their software. One or two months is not nearly enough to finish all the things. In my opinion, half or one year may be a reasonable schedule for this break change.

I sincerely hope you can consider our request and give us more time to adapt to this restriction. Thank you.

[Harald Alvestrand]

Would a reverse field trial (where web sites opt in to have the feature work for a few more milestones) help you?

To view this discussion visit https://groups.google.com/d/msgid/discuss-webrtc/dd99601c-2560-445f-ada9-991ce5bffc3en%40googlegroups.com.

[林飒明]

Hi Harald.

Unfortunately, it won't work for us. We provide an NPM package, and our customers typically import and compile it in their own scripts and websites. Our service cannot keep safe without notifying our customers, which is the most time-consuming and challenging part.

[Harald Alvestrand]

Thank you for that information - it means that in order to use an origin trial, all your customers would have to opt into the origin trial, which is, if not totally infeasible, on the same order of magnitude as shipping a new version of the SDK that doesn't use ufrag munging.

For curiosity's sake: Does your UFRAG munging solution work on Firefox, Safari and Edge too?

And for completeness: Which company are you representing? We don't track ownership of @gmail.com addresses...

Harald

To view this discussion visit https://groups.google.com/d/msgid/discuss-webrtc/2c413b3e-66a8-4737-a92e-4e5074cb1237n%40googlegroups.com.

[林飒明]

Hi Harald.

You're correct. Whether it's an origin trial, a third-party origin trial, or fixing all thing on our SDK,  we still need to notify all customers to take action. I think, delaying the rollout maybe the only viable solution for our case.

Given the approaching of the M137 branch point, is it possible to provide a concrete timeline for the public? Otherwise, we need to start the emergency plan at that time.

Additionally, we have applied this strategy across all browser. Firefox, Safari and Edge are all working as expected. 

Best Regards,

Saming

[林飒明]

Hi Harald.

Do you have any updates on this PSA? We remain highly concerned about the detailed timeline for restriction of `ufrag` and other SDP modifications. Given the challenges we've encountered, we sincerely request a delay in this rollout about `ufrag`, at least until M144.

After our initial outreach to customers, we've found that notifying this upgrade is more difficult than anticipated. Many customers have a long upgrade schedules, and some must align with their own downstream partners. Completing this upgrade within a month is simply not feasible, so we must formally request an extension for the `ufrag` modification restriction

Additionally, does this restriction need to follow this [Feature Deprecations](https://www.chromium.org/blink/launching-features/#feature-deprecations) procedure and be announced in blink-dev?

Best Regrads,

Saming