Closed kuro68k closed 5 years ago
Did you enable "Prevent WebRTC from leaking local IP addresses"?
Can you try if you also experience the issue with a different content blocker?
Thanks for the response. I did have the WebRTC block enabled on my personal browser profile but just went with the default on the test profile, which is not enabled.
I have already tried Privacy Badger. It's less consistent but does sometimes prevent it from working. I will try the others.
I did have the WebRTC block enabled on my personal browser profile but just went with the default on the test profile, which is not enabled.
So did it work ?
Disabling the WebRTC block did not work, no.
Well any logs from browser console or extension console ?
Console log:
[DOM] Password field is not contained in a form: (More info: https://goo.gl/9p2vKq) <input type="password" class="whsOnd zHQkBf" jsname="YPqjbf" autocomplete="off" tabindex="0" aria-label="Enter PIN" data-initial-value>
m=N5mZo,Utzytb,XuIccf,ZtzJ9c,b6g2Fc,dNQjze,XXXXXX,l9KnA,rV91d,v2P8cc,xbfkSc:1978 state = started; transport = unknown
m=N5mZo,Utzytb,XuIccf,ZtzJ9c,b6g2Fc,dNQjze,XXXXXX,l9KnA,rV91d,v2P8cc,xbfkSc:1978 state = signaling; transport = unknown
m=N5mZo,Utzytb,XuIccf,ZtzJ9c,b6g2Fc,dNQjze,XXXXXX,l9KnA,rV91d,v2P8cc,xbfkSc:1978 state = connecting; transport = unknown
m=N5mZo,Utzytb,XuIccf,ZtzJ9c,b6g2Fc,dNQjze,XXXXXX,l9KnA,rV91d,v2P8cc,xbfkSc:1978 state = authenticated; transport = unknown
m=N5mZo,Utzytb,XuIccf,ZtzJ9c,b6g2Fc,dNQjze,XXXXXX,l9KnA,rV91d,v2P8cc,xbfkSc:1978 state = failed; transport = unknown
uBlock log:
14:12:05remotedesktop.google.com1xhrhttps://instantmessaging-pa.clients6.google.com/$rpc/google.internal.communications.instantmessaging.v1.Messaging/AckMessages
14:12:04remotedesktop.google.com1xhrhttps://instantmessaging-pa.clients6.google.com/$rpc/google.internal.communications.instantmessaging.v1.Messaging/AckMessages
14:12:04remotedesktop.google.com1xhrhttps://play.google.com/log?format=json&hasfast=true
14:12:04remotedesktop.google.com1xhrhttps://instantmessaging-pa.clients6.google.com/$rpc/google.internal.communications.instantmessaging.v1.Messaging/SendMessage
14:12:04remotedesktop.google.com1xhrhttps://instantmessaging-pa.clients6.google.com/$rpc/google.internal.communications.instantmessaging.v1.Messaging/AckMessages
14:12:04remotedesktop.google.com1xhrhttps://instantmessaging-pa.clients6.google.com/$rpc/google.internal.communications.instantmessaging.v1.Messaging/SendMessage
14:12:03remotedesktop.google.com1xhrhttps://instantmessaging-pa.clients6.google.com/$rpc/google.internal.communications.instantmessaging.v1.Messaging/SendMessage
14:12:03remotedesktop.google.com1xhrhttps://instantmessaging-pa.clients6.google.com/$rpc/google.internal.communications.instantmessaging.v1.Messaging/AckMessages
14:12:03remotedesktop.google.com1xhrhttps://instantmessaging-pa.clients6.google.com/$rpc/google.internal.communications.instantmessaging.v1.Messaging/AckMessages
14:12:03remotedesktop.google.com1xhrhttps://instantmessaging-pa.clients6.google.com/$rpc/google.internal.communications.instantmessaging.v1.Messaging/SendMessage
14:12:03remotedesktop.google.com1xhrhttps://instantmessaging-pa.clients6.google.com/$rpc/google.internal.communications.instantmessaging.v1.Messaging/SendMessage
14:12:03remotedesktop.google.com1xhrhttps://instantmessaging-pa.clients6.google.com/$rpc/google.internal.communications.instantmessaging.v1.Messaging/AckMessages
14:12:03remotedesktop.google.com1xhrhttps://instantmessaging-pa.clients6.google.com/$rpc/google.internal.communications.instantmessaging.v1.Messaging/AckMessages
14:12:02remotedesktop.google.com1xhrhttps://instantmessaging-pa.clients6.google.com/$rpc/google.internal.communications.instantmessaging.v1.Messaging/SendMessage
14:12:02remotedesktop.google.com1xhrhttps://instantmessaging-pa.clients6.google.com/$rpc/google.internal.communications.instantmessaging.v1.Messaging/SendMessage
14:12:02remotedesktop.google.com1xhrhttps://instantmessaging-pa.clients6.google.com/$rpc/google.internal.communications.instantmessaging.v1.Messaging/AckMessages
14:12:01remotedesktop.google.com1xhrhttps://instantmessaging-pa.clients6.google.com/$rpc/google.internal.communications.instantmessaging.v1.Messaging/SendMessage
14:12:01remotedesktop.google.com1xhrhttps://play.google.com/log?format=json&hasfast=true&authuser=0
14:12:01remotedesktop.google.com1xhrhttps://instantmessaging-pa.clients6.google.com/$rpc/google.internal.communications.instantmessaging.v1.Messaging/ReceiveMessages
14:12:018.client-channel.google.com1xhrhttps://8.client-channel.google.com/client-channel/channel/bind?ctype=chromoting&gsessionid=XXXXXX&VER=8&SID=XXXXXX&RID=XXXXXX&AID=1&zx=66aiuvc2dbd9&t=1
14:12:018.client-channel.google.com1xhrhttps://8.client-channel.google.com/client-channel/channel/bind?ctype=chromoting&gsessionid=XXXXXX&VER=8&RID=rpc&SID=XXXXXX&CI=0&AID=0&TYPE=xmlhttp&zx=khd26iic5ayl&t=1
14:12:018.client-channel.google.com1xhrhttps://8.client-channel.google.com/client-channel/channel/bind?ctype=chromoting&gsessionid=XXXXXX&VER=8&RID=XXXXXX&CVER=5&zx=XXXXXX&t=1
14:12:018.client-channel.google.com1xhrhttps://8.client-channel.google.com/client-channel/channel/cbp?ctype=chromoting&gsessionid=XXXXXX&VER=8&TYPE=xmlhttp&zx=XXXXXX&t=1
14:12:018.client-channel.google.com1xhrhttps://8.client-channel.google.com/client-channel/channel/cbp?ctype=chromoting&gsessionid=XXXXXX&VER=8&MODE=init&zx=XXXXXX&t=1
14:12:018.client-channel.google.com1xhrhttps://8.client-channel.google.com/client-channel/gsid
14:12:008.client-channel.google.com1xhrhttps://8.client-channel.google.com/client-channel/gsid
14:12:00remotedesktop.google.com1framehttps://8.client-channel.google.com/client-channel/client?cfg=XXXXXX&ctype=chromoting&xpc=%7B%22cn%22%3A%2294SH4Pcekl%22%2C%22ppu%22%3A%22https%3A%2F%2Fremotedesktop.google.com%2Frobots.txt%22%2C%22lpu%22%3A%22https%3A%2F%2F8.client-channel.google.com%2Frobots.txt%22%7D
14:12:00remotedesktop.google.com1xhrhttps://instantmessaging-pa.clients6.google.com/$rpc/google.internal.communications.instantmessaging.v1.Registration/SignInGaia
14:12:00remotedesktop.google.com1xhrhttps://remotedesktop.google.com/_/RemotingUi/data/batchexecute?rpcids=jh3iPd&f.sid=XXXXXX&bl=boq_remotinguiserver_20190907.14_p2&hl=en-GB&soc-app=1&soc-platform=1&soc-device=1&_reqid=XXXXXX&rt=c
14:12:00remotedesktop.google.com1xhrhttps://play.google.com/log?format=json&hasfast=true
14:11:59remotedesktop.google.com1xhrhttps://play.google.com/log?format=json&hasfast=true&authuser=0
If the logger shows that uBO is doing nothing, it's more likely that the issue is elsewhere -- hence why it's useful to report whether you also suffer the issue with other content blockers.
Do Remote Desktop require additional (installed by default?) extension? Can you check chrome://extensions
and chrome://apps
?
If yes - disable this extension -> open uBO logger -> enable extension back. See if something is blocked.
Chrome Remote Desktop requires an extension on the target machine, but not on the machine you are connecting from.
Since disabling uBO fixes the problem and it's the only extension installed, it seems like it must have something to do with it.
I'll try the other extensions when I have some time later.
Disabled uBO and still won't work for me.
That's different to what I get.
AdGuard on default settings worked fine.
AdBlock Plus on default settings broke Remote Desktop.
So, so far, it breaks with:
How thoroughly did you test with AdGuard?
I installed it, left everything on default after it had done the initial filter update, and then tested Remote Desktop.
Earlier you said regarding Privacy Badger, "less consistent but does sometimes prevent it from working". Is it possible you could also reproduce with AdGuard if testing the same way you did with Privacy Badger?
My understanding is that Privacy Badger blocks things using some kind of algorithm that detects potential trackers, so my guess is that it decided to block based on that.
As a test I tried with AdGuard again, and this time it failed. So the behaviour is not consistent, but knowing the way Google likes to dynamically generate stuff and use a large pool of servers it's possible that something is changing on their end.
I'm a C guy, I'm afraid debugging this kind of network stuff is a bit outside by comfort zone.
I have been having the same issue for some time and I can verify now that in both Google Chrome and Brave Browser, that WebRTC is the cause of the problem for me. It appears that the service needs to know the local IP of the localhost...
The resolution to make Chrome Remote Desktop to work:
Google - Version 77.0.3865.90 (Official Build) (64-bit) Brave - Version 0.68.138 Chromium: 77.0.3865.75 (Official Build) (64-bit) uBlock Origin v1.22.2 macOS 10.14.6
WebRTC is the cause of the problem for me
That was my first guess, but @kuro68k reported:
I did have the WebRTC block enabled on my personal browser profile but just went with the default on the test profile, which is not enabled. [...] Disabling the WebRTC block did not work, no.
Can confirm that disabling the WebRTC block in uBlock Origin does not fix the problem for me. Did you try installing a clean copy of Chrome?
Never had a problem with CRD. Also never had Prevent WebRTC enabled.
Do you have a G Suite account and are you syncing/logged into Chrome? Then perhaps your G Suite admin needs to adjust the WebRTC settings in the admin console, and make sure that the firewall has those same ports open for incoming traffic.
Maybe worth noting, I do have a number of google hosts whitelisted.
admin.google.com groups.google.com gsuite.google.com plus.google.com services.google.com sites.google.com support.google.com
I tried your whitelist, it didn't help. I do not have a G Suite account.
I experimented with the Prevent WebRTC option again. Out of 5 attempts I was able to connect 3 times, which is better than zero times with it enabled. Perhaps it is related.
Does the whitelist affect WebRTC? Is there any way I can monitor WebRTC requests?
Is there any way I can monitor WebRTC requests?
chrome://webrtc-internals/
Not possible in uBO as it bypasses webRequest API, so uBO can't see any webRTC peer network requests made by any website.
Well I can see that CRD is making WebRTC requests so let's assume that is the primary issue.
I don't really want to disable that protection for all sites. Is there a way to whitelist CRD? I already have remotedesktop.google.com in the whitelist, which is where the request is to.
let's assume that is the primary issue
Why? The logger output you showed does not show anything blocked, and you said that disabling "Prevent WebRTC from leaking local IP addresses" made no difference.
So if WebRTC was blocked it would appear in the logger?
In that case I agree, it must be some side effect related to that option. Odd that it is inconsistent.
So if WebRTC was blocked it would appear in the logger?
Read https://github.com/uBlockOrigin/uBlock-issues/issues/726#issuecomment-540489715
Now I am confused. Above you said disabling "Prevent WebRTC from leaking local IP addresses" made no difference:
Can confirm that disabling the WebRTC block in uBlock Origin does not fix the problem for me.
Now you are suggesting this is your issue:
Well I can see that CRD is making WebRTC requests so let's assume that is the primary issue.
Which statement is correct?
In response to uBlock-user I experimented with the "Prevent WebRTC" option again. Out of 5 tests 3 connected. It doesn't seem to be consistent. Every time I checked the log and did not see any blocked requests.
If I open chrome://webrtc-internals/
I can see a single connection:
https://remotedesktop.google.com/access/session/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx [xxxxx-xx]
And just to re-iterate, remotedesktop.google.com
is on the whitelist.
The only way to make it consistently work is to disable uBlock. I'm afraid I'm an embedded developer, I'm not that familiar with web stuff.
If something is not shown as blocked in the logger, than nothing is blocked by uBO.
WebRTC connections are not shown in uBO because the extensions API does not relay WebRTC network traffic through uBO -- so uBO can't block anything WebRTC.
The setting "Prevent WebRTC from leaking local IP addresses" is a behavorial one, it just asks the browser to not leak local IP address, uBO is not involved beyond this regarding WebRTC stuff.
It would be best if you filter out the logger output to show only blocked items and report the result here (select the All entry in the drop down list in the logger), partially[1] reporting the non-blocked items as you did above is not useful, what I want to see is a strong confirmation that nothing is reported as blocked in uBO's logger.
[1] The logger output you provided is partial -- I do not see an entry for doc
which would appear on page reload.
Okay, this is the log with the "all" setting.
With regards to WebRTC, since it is an internal Chromium thing then perhaps I should try opening an enhancement request to make it settable on a per-site basis (ideally via whitelist).
The above was when I clicked on the connection button. I did it again but also refreshed the page first:
perhaps I should try opening an enhancement request to make it settable on a per-site basis (ideally via whitelist).
Not possible as per documention.
I'm not 100% clear on what public and private interfaces are, I'm guessing not like in the Windows terminology of public and private networks. But anyway, what I'm suggesting is asking the Chromium developers to add another option for a whitelist or something.
Am I right in saying this is not something that can be resolved in uBlock, it has to be a change in Chromium?
Okay, I did a load more tests today. Even with uBlock disabled it does sometimes fail to connect, so I think we can just put that down to network issues or whatever. So in hindsight I think it is almost certainly the WebRTC blocking that causes the issue, and it's not something that can be fixed uBlock from the sound of it.
Well, here's one idea. Have a whitelist and change the setting when tabs with matching URLs are in the foreground. Once the connection is established you can disable WebRTC again and the connection keeps working just fine.
Can I open it? This issue is still persist. After whole reading this topic I have something new and fresh. I have exactly same issue - cannot connect through Google Remote Desktop while uBlock Origin is enabled. However (the new thing is) I can connect through Google Remote Desktop with enabled uBlock Origin on my notebook device. I would assume that this is some internal issue of Google Chrome or uBlock Origin but since it is working on different computer I wanted to dig in internet and found what others had to say. I found this topic. I'm uploading screenshot from my notebook that is connected to my PC with enabled uBlock Origin. I would put screenshot of settings from both uBlock Origins but they are in my native language and I have no idea how to change it to English (but they have exactly same settings, same filters and same rules). Both PC have enabled antivirus (same type) with firewall. Both are under same local network. Both have downloaded and installed that Google Remote Desktop additional software. Both have exactly same extensions because sync is enabled. Both have local network marked as Private. However PC cannot connect to any other (without disabling uBlock Oiring) but my notebook can connect to anything with enabled uBlock Origin. When I'm trying to connect from PC to notebook then I get that message about extension like someone already put in this topic. The only way to connect is to disable uBlock Origin. Once I connect then I can enable it and keep connection open (enabling uBlock Origin is not disconnecting the session).
I don't know if it's coincidence but the first time I tried it this year (today) it worked with uBlock 1.24.2 enabled.
All right, looks like no one care about it. Then I will not care about uBlock Origin too. It's good time to try other solutions. I heard tons of good opinions about AdGuard. This cannot continue that blocking extension is still blocking something when setup to not block anything on specific website.
Apologies for reviving this thread, but I also had this issue and have since "resolved" it.
After several attempts to see why I wasn't able to use Chrome Remote Desktop, I decided to disable all my extensions and re-enable them one by one. uBO was the extension that caused the issue. After reading this thread I compared the settings between my desktop (that was not able to connect) and my laptop (that was able to connect). Every extension was synced; the only difference was the settings in uBO. My desktop had "Prevent WebRTC..." enabled and my laptop did not.
So, after disabling that option I can confirm that this is most likely the cause of the issue and while not optimal, it will have to do. There is no need to completely disable the extension on my end.
Good catch! Yeah, WebRTC is necessary for other good things too, so I'd keep it enabled.
Disabling the WebRTC blocking didn't work for me.
Behaviour is random. Sometimes for weeks I can't open Remote Desktop with uBlock enabled, then for weeks I can. Closing the browser and opening it again seems to trigger the change.
Prerequisites
Description
When enabled with the default settings I cannot open a Chrome Remote Desktop connection (https://remotedesktop.google.com). When connecting the site asks for a PIN number and then reports an error connecting.
The logger shows no URLs blocked. It appears that merely having uBlock Origin enabled is enough to trigger the problem.
A specific URL where the issue occurs
https://remotedesktop.google.com
Steps to Reproduce
Expected behavior:
Remote desktop session connects
Actual behavior:
"Cannot connect" error message displays. Chrome suggests trying Incognito Mode and disabling extensions.
Your environment