Serious Discussion ChatGPT and WebRTC blocking (in Ublock Origin)

[Sampei.Nihira]

Today I discovered that ChatGPT no longer works when WebRTC blocking is enabled in uBlock Origin in my Chrome browser.
It is possible to immediately identify the culprit (WebRTC block) because certain characteristic elements are usually missing from the website.
Please note the images below:

Without webRTC blocking:



With webRTC blocking:



P.S.

So I added the exception for WebRTC in uBo.
But in AG it's not necessary.

 

[Bot]

Today I discovered that ChatGPT no longer works when WebRTC blocking is enabled in uBlock Origin in my Chrome browser.
It is possible to immediately identify the culprit (WebRTC block) because certain characteristic elements are usually missing from the website.
Please note the images below:

Without webRTC blocking:

View attachment 293102

With webRTC blocking:

View attachment 293103

P.S.

So I added the exception for WebRTC in uBo.
But in AG it's not necessary.

You’ve diagnosed it correctly: the breakage is very likely tied to how uBlock Origin blocks WebRTC in Chromium, and the fact that ChatGPT’s new interface now relies on (or at least expects) WebRTC to exist.

What’s probably happening

• ChatGPT now uses WebRTC-related APIs in the page (mainly for the voice features and some real‑time logic).
• When uBlock Origin’s WebRTC blocking is enabled in Chrome, it effectively “cripples” those APIs (or the related connections) in a way that makes the ChatGPT frontend code fail early.
• As a result, part of the UI doesn’t finish loading – the logo/menu on the left and the login/register buttons on the right simply never appear, exactly as in your second screenshot.

So your workaround (allow WebRTC for chatgpt.com in uBO) is the correct and safest fix for now.

Why AdGuard doesn’t break ChatGPT in the same way

uBO and AdGuard don’t implement WebRTC blocking in exactly the same manner:

• uBlock Origin (Chromium) – its WebRTC protection on Chromium tends to be more “all or nothing” because of limitations in the browser extension APIs. This can result in WebRTC objects being unavailable or heavily modified, which some web apps don’t handle gracefully.
• AdGuard – AdGuard’s “Block WebRTC” feature is usually narrower: it focuses on preventing local IP leaks (STUN/ICE info) rather than completely disabling WebRTC APIs. So the site can still use WebRTC, but your local IP address is not exposed in the same way. From the site’s perspective, WebRTC still “exists”, so the UI doesn’t break.

That difference alone is enough to explain why:

• With uBO WebRTC blocking → ChatGPT UI breaks.
• With AdGuard WebRTC blocking → ChatGPT UI still works.

Is allowing WebRTC on ChatGPT a problem?

From a privacy point of view:

• The main risk with WebRTC is leaking local IPs (especially when using a VPN/proxy).
• If you’re only allowing WebRTC on chatgpt.com and you’re otherwise careful (VPN, HTTPS everywhere, etc.), the added risk is limited to this domain.
• You can always verify what leaks with BrowserLeaks (which you already have in your bookmarks) with/without the exception enabled.

Practical suggestions

• Keep the per‑site exception in uBO just for chatgpt.com – don’t disable WebRTC protection globally if you don’t need to.
• If you want to be thorough, you can:
• Test WebRTC leaks on BrowserLeaks with uBO exception enabled for ChatGPT.
• If the behavior looks worrying, consider raising an issue on uBlock Origin’s GitHub with screenshots and the logger output so gorhill can see if a less‑breaking workaround is possible.

In short: your observation is valid, your fix (exception in uBO) is the right approach, and the difference with AdGuard comes from how aggressively each one interferes with WebRTC on Chromium.

 

[Divergent]

ChatGPT’s frontend was recently updated, and that update introduced a dependency on WebRTC.

 

[Sampei.Nihira]

You’ve diagnosed it correctly: the breakage is very likely tied to how uBlock Origin blocks WebRTC in Chromium, and the fact that ChatGPT’s new interface now relies on (or at least expects) WebRTC to exist.

What’s probably happening

• ChatGPT now uses WebRTC-related APIs in the page (mainly for the voice features and some real‑time logic).
• When uBlock Origin’s WebRTC blocking is enabled in Chrome, it effectively “cripples” those APIs (or the related connections) in a way that makes the ChatGPT frontend code fail early.
• As a result, part of the UI doesn’t finish loading – the logo/menu on the left and the login/register buttons on the right simply never appear, exactly as in your second screenshot.

So your workaround (allow WebRTC for chatgpt.com in uBO) is the correct and safest fix for now.

Why AdGuard doesn’t break ChatGPT in the same way

uBO and AdGuard don’t implement WebRTC blocking in exactly the same manner:

• uBlock Origin (Chromium) – its WebRTC protection on Chromium tends to be more “all or nothing” because of limitations in the browser extension APIs. This can result in WebRTC objects being unavailable or heavily modified, which some web apps don’t handle gracefully.
• AdGuard – AdGuard’s “Block WebRTC” feature is usually narrower: it focuses on preventing local IP leaks (STUN/ICE info) rather than completely disabling WebRTC APIs. So the site can still use WebRTC, but your local IP address is not exposed in the same way. From the site’s perspective, WebRTC still “exists”, so the UI doesn’t break.

That difference alone is enough to explain why:

• With uBO WebRTC blocking → ChatGPT UI breaks.
• With AdGuard WebRTC blocking → ChatGPT UI still works.

Is allowing WebRTC on ChatGPT a problem?

From a privacy point of view:

• The main risk with WebRTC is leaking local IPs (especially when using a VPN/proxy).
• If you’re only allowing WebRTC on chatgpt.com and you’re otherwise careful (VPN, HTTPS everywhere, etc.), the added risk is limited to this domain.
• You can always verify what leaks with BrowserLeaks (which you already have in your bookmarks) with/without the exception enabled.

Practical suggestions

• Keep the per‑site exception in uBO just for chatgpt.com – don’t disable WebRTC protection globally if you don’t need to.
• If you want to be thorough, you can:
• Test WebRTC leaks on BrowserLeaks with uBO exception enabled for ChatGPT.
• If the behavior looks worrying, consider raising an issue on uBlock Origin’s GitHub with screenshots and the logger output so gorhill can see if a less‑breaking workaround is possible.

In short: your observation is valid, your fix (exception in uBO) is the right approach, and the difference with AdGuard comes from how aggressively each one interferes with WebRTC on Chromium.

@Bot

But in AG I use a scriptlet that should have the same functionality as the one in uBlock Origin.

 

[Bot]

@Bot

But in AG I use a scriptlet that should have the same functionality as the one in uBlock Origin.

Hi Sampei.Nihira,

Thanks for the additional detail – that's interesting, and it could explain some nuances in how the blocking behaves across tools. Let's break this down based on what I know about scriptlets in AdGuard versus uBlock Origin's native WebRTC handling.

Scriptlets in AdGuard vs. uBO's Built-in WebRTC Blocking

• AdGuard does support custom scriptlets (similar to uBO's), which can be used to inject JavaScript for things like blocking or modifying WebRTC behavior. If you're using one that's intended to mimic uBO's WebRTC protection, it might be something like a "prevent-webrtc-ip-leak" scriptlet or a custom filter rule.
• However, even if the scriptlet aims for the same end goal (e.g., preventing IP leaks via STUN/ICE), the implementation can differ significantly:
• uBlock Origin (in Chromium) often relies on browser extension APIs (like chrome.privacy) to alter WebRTC at a deeper level, which can make the APIs unavailable or fail in ways that break sites like ChatGPT if they're not robustly coded.
• AdGuard scriptlets typically work by injecting JS into the page, which might only target specific WebRTC calls (e.g., masking IPs without fully disabling the peer connection objects). This could allow the site's frontend to detect WebRTC as "present" and load properly, even if leaks are prevented.

In other words, if your AdGuard scriptlet is more targeted or less aggressive, it might not trigger the same failure mode in ChatGPT's updated UI, which seems sensitive to full API disruptions.

Why It Might Not Break in AdGuard

• From what you've described, ChatGPT's dependency appears tied to WebRTC APIs being at least partially functional for voice/real-time features. If AdGuard's scriptlet only "hides" sensitive data without crippling the APIs entirely, the site can proceed without issues.
• uBO's approach (especially on Chrome) can sometimes make WebRTC "invisible" to the page, leading to the UI elements not rendering, as you saw.

If I'm off-base here or if you can share the exact scriptlet/filter you're using in AdGuard (without sensitive details), that might help clarify – but I'm basing this on general knowledge of how these tools operate.

Suggestions to Verify and Troubleshoot

• Test for leaks: Visit a site like BrowserLeaks or webrtc.org with your AdGuard scriptlet enabled, and check if local IPs are still hidden while WebRTC functions overall. Compare it directly to uBO's behavior.
• Toggle and compare: Temporarily disable the scriptlet in AdGuard and see if ChatGPT still works – this could confirm if it's the scriptlet or AdGuard's core handling that's more forgiving.
• Community input: If the difference persists and seems like a bug/quirk, it might be worth posting about the specific scriptlet in the AdGuard or uBO forums/GitHub for dev feedback. They often have insights into these edge cases.

Overall, it sounds like AdGuard's method (scriptlet or otherwise) is playing nicer with ChatGPT's changes, which is a win for usability. If you run into any other breakage or need help tweaking filters, feel free to share more!

 

[Sampei.Nihira]

ChatGPT’s frontend was recently updated, and that update introduced a dependency on WebRTC.

Yes, you're absolutely right. In fact, I now have three exceptions for the WebRTC block.

 

[Sampei.Nihira]

Hi Sampei.Nihira,

Thanks for the additional detail – that's interesting, and it could explain some nuances in how the blocking behaves across tools. Let's break this down based on what I know about scriptlets in AdGuard versus uBlock Origin's native WebRTC handling.

Scriptlets in AdGuard vs. uBO's Built-in WebRTC Blocking

• AdGuard does support custom scriptlets (similar to uBO's), which can be used to inject JavaScript for things like blocking or modifying WebRTC behavior. If you're using one that's intended to mimic uBO's WebRTC protection, it might be something like a "prevent-webrtc-ip-leak" scriptlet or a custom filter rule.
• However, even if the scriptlet aims for the same end goal (e.g., preventing IP leaks via STUN/ICE), the implementation can differ significantly:
• uBlock Origin (in Chromium) often relies on browser extension APIs (like chrome.privacy) to alter WebRTC at a deeper level, which can make the APIs unavailable or fail in ways that break sites like ChatGPT if they're not robustly coded.
• AdGuard scriptlets typically work by injecting JS into the page, which might only target specific WebRTC calls (e.g., masking IPs without fully disabling the peer connection objects). This could allow the site's frontend to detect WebRTC as "present" and load properly, even if leaks are prevented.

In other words, if your AdGuard scriptlet is more targeted or less aggressive, it might not trigger the same failure mode in ChatGPT's updated UI, which seems sensitive to full API disruptions.

Why It Might Not Break in AdGuard

• From what you've described, ChatGPT's dependency appears tied to WebRTC APIs being at least partially functional for voice/real-time features. If AdGuard's scriptlet only "hides" sensitive data without crippling the APIs entirely, the site can proceed without issues.
• uBO's approach (especially on Chrome) can sometimes make WebRTC "invisible" to the page, leading to the UI elements not rendering, as you saw.

If I'm off-base here or if you can share the exact scriptlet/filter you're using in AdGuard (without sensitive details), that might help clarify – but I'm basing this on general knowledge of how these tools operate.

Suggestions to Verify and Troubleshoot

• Test for leaks: Visit a site like BrowserLeaks or webrtc.org with your AdGuard scriptlet enabled, and check if local IPs are still hidden while WebRTC functions overall. Compare it directly to uBO's behavior.
• Toggle and compare: Temporarily disable the scriptlet in AdGuard and see if ChatGPT still works – this could confirm if it's the scriptlet or AdGuard's core handling that's more forgiving.
• Community input: If the difference persists and seems like a bug/quirk, it might be worth posting about the specific scriptlet in the AdGuard or uBO forums/GitHub for dev feedback. They often have insights into these edge cases.

Overall, it sounds like AdGuard's method (scriptlet or otherwise) is playing nicer with ChatGPT's changes, which is a win for usability. If you run into any other breakage or need help tweaking filters, feel free to share more!

@Bot


Rule uBlock Origin:

*##+js(nowebrtc)

Rule AdGuard Browser Extension:

#%#//scriptlet('nowebrtc')

 

[Bot]

Rule uBlock Origin:

*##+js(nowebrtc)

Rule AdGuard Browser Extension:

#%#//scriptlet('nowebrtc')

Hi Sampei.Nihira,

Thanks for sharing the exact rules – that helps narrow things down a lot! Both are indeed using the 'nowebrtc' scriptlet (originally from uBlock Origin's resources), which is designed to prevent WebRTC IP leaks by overriding or disabling certain APIs. AdGuard's syntax (#%#//scriptlet('nowebrtc')) is their way of supporting uBO-style scriptlets, so on the surface, they should behave similarly. Let's dive into why you're seeing a difference with ChatGPT.

Key Similarities and Potential Differences

• What the 'nowebrtc' scriptlet does: It injects JavaScript to block or modify WebRTC peer connections, primarily to stop local IP exposure via STUN/ICE protocols. This is a common privacy tweak and doesn't fully disable WebRTC in most cases – it just makes it "leak-proof."
• Why the behavior might differ between uBO and AdGuard:
• uBlock Origin (in Chrome): uBO can combine scriptlets with its own internal handling, including extension APIs like chrome.privacy.network.webRTCIPHandlingPolicy. This might make the blocking more aggressive or "early" in the page load process, causing sites like ChatGPT (which now depends on WebRTC for UI/voice features) to fail if they check for WebRTC availability right away. If the scriptlet alone isn't the full story, uBO's broader settings could amplify the effect.
• AdGuard Browser Extension: AdGuard's scriptlet injection might be implemented slightly differently – perhaps with later timing, less interference with core APIs, or better compatibility in Chromium. From user reports I've seen, AdGuard sometimes handles these scriptlets in a way that's more forgiving for modern web apps, allowing partial WebRTC functionality while still blocking leaks. This could explain why ChatGPT's frontend loads fine without an exception in AG.

In short, even though the scriptlets look identical, the extensions' underlying engines (and how they interact with Chrome's APIs) can lead to subtle variations in real-world breakage. It's not uncommon for the same filter to act differently across tools due to these implementation quirks.

Testing and Confirmation Steps

To verify this and ensure your privacy setup is solid:
• Check for leaks: Load up BrowserLeaks.com/webrtc with each extension enabled (and the scriptlet active). See if IPs are hidden in both cases, and note any differences in how WebRTC is reported (e.g., does it show as fully disabled in uBO but partially available in AG?).
• Isolate the scriptlet: In AdGuard, temporarily disable just the #%#//scriptlet('nowebrtc') rule and test ChatGPT – does it still work without breaking? Do the same in uBO by removing *##+js(nowebrtc) and compare. This can confirm if the scriptlet itself is the variable or if it's something else in the extension.
• Browser console check: Open Chrome's DevTools (F12) on ChatGPT with each setup, look for WebRTC-related errors in the Console tab. That might show exactly where the failure happens in uBO but not in AG.

If the difference persists and feels like a bug (e.g., uBO breaking more than intended), I'd suggest reporting it on uBlock Origin's GitHub issues page with your rules, screenshots, and console logs – gorhill is usually responsive to these kinds of reports. The AdGuard forums could also provide insights from their devs.

Overall, it's great that AdGuard is working seamlessly for you here – it highlights how tool-specific tweaks can make a big difference in usability. If you test this out and share what you find (or need help with anything else), I'm here to assist!

 

[Sampei.Nihira]

@Bot

Of course, I have already verified that privacy is robust.
That's why I also use the scriptlet in AG, because the native webRTC blocking feature is insufficient for my needs.

 

[Bot]

@Bot

Of course, I have already verified that privacy is robust.
That's why I also use the scriptlet in AG, because the native webRTC blocking feature is insufficient for my needs.

Hi Sampei.Nihira,

That's smart – verifying privacy robustness firsthand is always the best approach, especially with something as critical as WebRTC leaks. It's good to hear the scriptlet in AdGuard is meeting your needs where the native blocking falls short; that kind of customization is one of the strengths of these tools.

Quick Thoughts on Enhancing Your Setup

Since you're already dialed in on this:
• If the native AG blocking isn't cutting it (e.g., due to incomplete IP masking or edge cases), sticking with the scriptlet makes perfect sense – it's more granular and aligns closely with uBO's proven methods.
• For even more control, you could combine it with browser-level tweaks in Chrome (like setting privacy.network.webRTCMultipleRoutesEnabled to false via policies), but only if it doesn't introduce new breakages. Always test thoroughly on sites like BrowserLeaks afterward.
• Keep an eye on updates: Both uBO and AdGuard occasionally refine their WebRTC handling, so a future version might bridge any gaps without needing custom rules.

If you've noticed any other sites where the scriptlet behaves differently between the two extensions, or if you want tips on optimizing other privacy filters, just let me know – happy to help brainstorm!

 

[Sampei.Nihira]

Hi Sampei.Nihira,

That's smart – verifying privacy robustness firsthand is always the best approach, especially with something as critical as WebRTC leaks. It's good to hear the scriptlet in AdGuard is meeting your needs where the native blocking falls short; that kind of customization is one of the strengths of these tools.

Quick Thoughts on Enhancing Your Setup

Since you're already dialed in on this:
• If the native AG blocking isn't cutting it (e.g., due to incomplete IP masking or edge cases), sticking with the scriptlet makes perfect sense – it's more granular and aligns closely with uBO's proven methods.
• For even more control, you could combine it with browser-level tweaks in Chrome (like setting privacy.network.webRTCMultipleRoutesEnabled to false via policies), but only if it doesn't introduce new breakages. Always test thoroughly on sites like BrowserLeaks afterward.
• Keep an eye on updates: Both uBO and AdGuard occasionally refine their WebRTC handling, so a future version might bridge any gaps without needing custom rules.

If you've noticed any other sites where the scriptlet behaves differently between the two extensions, or if you want tips on optimizing other privacy filters, just let me know – happy to help brainstorm!

@Bot

The native functionality of AG is not insufficient for IP; it allows SDP Log.
Do you know what I mean?

 

[Bot]

@Bot

The native functionality of AG is not insufficient for IP; it allows SDP Log.
Do you know what I mean?

Hi Sampei.Nihira,

Yes, I believe I know what you mean by "SDP Log" in this context – thanks for clarifying that detail. It helps paint a clearer picture of why you're opting for the scriptlet over AdGuard's native WebRTC blocking. Let me break it down briefly to confirm we're on the same page.

What SDP Log Refers To

• In WebRTC, SDP (Session Description Protocol) is the format used to describe and negotiate media sessions (like audio/video streams, including details on codecs, ports, and ICE candidates).
• "SDP Log" typically means the ability to access or log SDP data via browser APIs or dev tools, which can sometimes expose sensitive info indirectly – such as network topology hints, even if direct IP leaks are blocked. This could be used for advanced fingerprinting or debugging, but it's a privacy risk if you're aiming for maximum hardening.
• AdGuard's native "Block WebRTC" feature is solid for preventing direct local IP leaks (via STUN/ICE), but it might not fully restrict SDP-related logging or manipulation. That's where a more aggressive scriptlet like 'nowebrtc' comes in – it can override these APIs more comprehensively, blocking SDP access/log at the script level to close that potential gap.

If that's not exactly what you meant (e.g., if it's referring to something specific like console logging in dev tools or a particular test site), feel free to elaborate – I want to make sure I'm addressing it accurately.

Why This Matters for Your Setup

• You're spot on to use the scriptlet if native blocking leaves SDP exposed in ways that concern you. It's a targeted way to enhance privacy without overhauling everything.
• For verification: Sites like BrowserLeaks or WebRTC internals pages (chrome://webrtc-internals/) can show SDP details – test with native AG vs. the scriptlet to see the difference in what's logged or accessible.

If you need recommendations for other scriptlets/filters to further lock down SDP or related WebRTC elements, or if there's another aspect of this you'd like to discuss, just say the word!

 

[Sampei.Nihira]

@Bot

That's right, you can find the SDP Log in this test:

WebRTC Leak Test

However, even the scriptlet does not always work 100%, but this is another issue that I have reported to the AG team.
I assume they have other more important issues to resolve.

 

[Bot]

@Bot

That's right, you can find the SDP Log in this test:

WebRTC Leak Test

However, even the scriptlet does not always work 100%, but this is another issue that I have reported to the AG team. I assume they have other more important issues to resolve.

Hi Sampei.Nihira,

Thanks for the link and the extra context – yes, the BrowserLeaks WebRTC test is a great one for spotting SDP-related details, including logs that might reveal more than just direct IP leaks (like candidate info or session descriptors). It's a solid tool for privacy auditing, and it's smart that you've already reported the scriptlet's inconsistencies to the AdGuard team. They do prioritize based on impact, so if it's an edge case, it might take time, but feedback like yours helps improve things.

On Scriptlet Reliability and SDP Logs

• The 'nowebrtc' scriptlet is effective for many scenarios by overriding RTCPeerConnection and related APIs to prevent leaks, but as you've noticed, it's not foolproof 100% of the time. This can happen due to:
• Browser-specific quirks: Chrome's WebRTC implementation evolves, and extensions like AdGuard might not catch every variation in how SDP is generated or logged.
• Site or timing factors: Some tests (like BrowserLeaks) dynamically probe WebRTC in ways that bypass partial blocks, or the scriptlet might inject too late in the page load.
• Updates and conflicts: Browser updates or other extensions/filters can interfere, leading to incomplete blocking.

If the SDP log exposure is a persistent concern, it's worth re-testing periodically after AG updates to see if they've addressed your report.

Suggestions for Further Hardening

• Alternative approaches: If the scriptlet falls short, you could layer on browser policies (e.g., via Chrome's group policy or extensions like Policy Control) to set webRTCIPHandlingPolicy to "disable_non_proxied_udp" – this often reduces SDP exposure without fully breaking functionality. Just test it on key sites to avoid unintended issues.
• Multi-tool combo: Since you use both uBO and AG, experiment with enabling the scriptlet only in one while using native blocking in the other – sometimes this hybrid setup covers gaps better.
• Community resources: Check the AdGuard GitHub or forums for similar reports; users often share workarounds or custom scriptlets for stubborn SDP issues. If it's a broader WebRTC problem, the uBO community might have insights too.

Overall, it's impressive how tuned your setup is – prioritizing robust privacy like this is key. If you share more about the specific scenarios where the scriptlet fails (without sensitive details), or if there's another privacy tweak you're considering, I'd be glad to offer thoughts!