Ungoogled-chromium: Chromecasts not working

[fredd727]

Hi, i created this account so i could contribute at least a bit. Im no dev though, this is my first post on github.

Latest windows build (55.0.2883.87-1_windows, both x64 x86) seems to have broken the ability to detect chromecasts.
I managed to get casting to work relativelly well (but rather inconsistent) on previous build (53.0.2785.116).

On a sidenote, i can confirm that this comment is still true. Therefore,

• netflix now gives the "M7121" error code
• and the big buck bunny video says "DRM:widevine update, XHR status is "Precondition Failed" (412), expected to be 200. readyState is 4"

Thanks for this project,

[nopjmp]

most likely it's a similar issue to the other platforms like in the issue #73. I replaced the widevincdm with the one from my Chrome install and big buck bunny streaming worked.

[fredd727]

good, so that might be a easy fix then! I only use firefox for browsing and chromium (UGC) for streaming and webapps so i dont have a chrome install, but let me know if i can be of any help

[Eloston]

I am fairly confident that casting requires communication with Google servers to work. Correct me if I'm wrong.

Regarding Widevine, what @nopjmp said is correct.

[nopjmp]

Chromecasts are just browsers hooked up to your TV. It runs a stripped down version of Android with WebView. It loads a page that the website choices to load and runs content. If you are wanting this seamless integration, you may want to stick with a less paranoid chromium patchset.

[Eloston]

@nopjmp So I'm guessing Chromecasts need Google servers to work?

[nopjmp]

afaik they don't need google's servers to work, but I haven't looking into them in great detail.

[Eloston]

Well if someone wants to look into this, go ahead.

[leso-kn]

I'll drop this comment to give back some attention to this topic.

What exactly is the issue with the chromecast functionality? Does it require proprietary libraries from google?

@nopjmp @Eloston Chromecast v1 works via ssdp and CC v2 via mdns and websockets using the ipc and 'casts'-protocol. It doesn't require connecting to google servers.

The receiver part is quite complicated and not really documented, as google want's to give their technology only to certified device manufacturers. Whereas the sender part is quite well documented and widely implemented (see e.g. Node Cast v2)

@Eloston Would you mind referencing the concerning sections of the code here? I'm very busy at the moment but i'd like to take a look

[Eloston]

@leso-kn Thank you for your insights. I don't know anything about Chromecasts; My previous comment was pure speculation.

If mDNS is all that is needed to make Chromecasts function, then I think ungoogled-chromium needs to consider re-enabling mDNS and Service Discovery (via patches/ungoogled-chromium/fix-building-without-mdns-and-service-discovery.patch and the flags in config_bundles/common/gn_flags.map). However, I am not knowledgeable of mDNS and Service Discovery. For example, what kinds of security and privacy implications are there for simply enabling both? What other components within Chromium use mDNS and Service Discovery?

[leso-kn]

@Eloston I don't think there's any real privacy issue :) Service discovery could only be a privacy issue if information about discovered devices is sent somewhere, which it of cause wouldn't be in case of ungoogled-chromium.

Enabling the features would i guess bring back chromecast functionality, as, as far as i can see, all other components required for it to work are present

[ghost]

_Chromecast is made specifically to be an open device that can be easily be used by anyone on the network. Hence ... No privacy_

👉 https://www.reddit.com/r/Chromecast/comments/79bk34/i_know_pretty_much_nothing_about_chromecasts/dp0nsot/

[leso-kn]

Yes, but that goes for the receiver only. The sender only sends an mDNS request and connects to found devices via websockets to provide the cast functionality. I don't concider this a privacy issue

[Eloston]

If I'm not mistaken, mDNS or Service Discovery sends broadcast packets. This is not acceptable for users who don't use these services and don't want traffic to leak out. Perhaps a flag could block these broadcasts?

[leso-kn]

That's a good idea! Do you think there's a way to sort of switch the no-mDNS patch on and off via a command line arg or config flag?

[Eloston]

It will probably be too difficult ot switch the entire patch on and off since the patch assumes the GN flag is always off. The easiest place to implement this toggle may be for the code that sends the broadcast packet. But I'd prefer to have the toggle at a higher level, such as for the code that loads mDNS or Service Discovery facilities, if possible.

[leso-kn]

Arround Christmas i might actually find time to have a look at the code. I'll try to figure out a useful place for the switch to put at.
Unfortunately i didn't manage to compile chromium myself, i tried it serval times a while ago.
Maybe you could release a test build with mDNS enabled to see if enabling it is already sufficient for chromecast?
I'd be up for testing it, my television supports chromecast

[Eloston]

Arround Christmas i might actually find time to have a look at the code. I'll try to figure out a useful place for the switch to put at.

Sounds good. Feel free to submit a PR whenever you are ready.

Maybe you could release a test build with mDNS enabled to see if enabling it is already sufficient for chromecast?

What platform do you use?

[leso-kn]

Short answer: Linux

Long answer: My main machine is currently still on Ubuntu 16.04. But any debian compatible package is fine, i guess for testing i'd prefer the linux portable build

[leso-kn]

And sure! I'll submit a PR with a patch file if i get this far :)

[leso-kn]

Alright, merry chistmas afterwards!

Today i had a look at the concerning code. I went for a very basic approach now, wrapping all relevant mDNS and service discovery related code into if conditions, that i control via a flag.

Please note, that as i mentioned earlier i didn't have the opportunity to test the changes myself. Thus i will not commit a PR yet, but attached to this post you'll find a patch file containing the changes.

patch.zip

Please note, that this patch replaces the prevous patch 'fix-building-without-mdns-and-service-discovery.patch' inside /patches/ungoogled-chromium, so you'll need to delete that one.

I'd be glad if you could test it @Eloston :) If it works i'll submit a PR containing the patch file and removal of the old patch

[Eloston]

Thanks for writing a patch @leso-kn. Several comments/questions:

1. Does the flag toggle broadcasts in #436? If I'm not mistaken, these broadcasts are related to the features being enabled/disabled by this flag.
2. I'm not too familiar with the code in this area. How is DnsSdDeviceLister used in Chromium? How will Chromium's behavior change with the flag toggled on and off? (Specific files would be great, but a description will work too)
3. What code is affected by the GN flags for mDNS and Service Discovery? How will the current patch address any privacy/security concerns related to code that will be enabled? (Like Question 2, a description will work too)
4. In line 42 of the patch file, you define a function inside another function. This is not valid C++. In addition, you assign this function to a boolean variable in line 47, which also isn't valid C++. Also, will the command line flag be guarenteed to be read (in ::Discover()) before any other function is invoked in DnsSdDeviceLister?
5. Instead of creating a global variable discoveryEnabled, you could define a new instance variable in the constructor of DnsSdDeviceLister (if you still decide it is appropriate to read the flag in this class). Once you compile the code, global variables get stored in a separate region of memory. I don't know enough about C++ to say if this can become an issue once the code is compiled, but it is still conventional in Chromium code to use instance variables for scenarios like these.

Hope this helps. Let me know if you need clarifications.

[leso-kn]

Hey! Forgive me if i didn't get everything right, i'm extremely tired today.
I'll start off question by question:

Does the flag toggle broadcasts in #436?

I'd say yes. As i didn't test it i'm not completely sure of cause, but i think the every two minute broadcast are most likely mdns requests and therefor affected by the patch.

How will Chromium's behavior change with the flag toggled on and off?

As far as i know chromium only uses discovery on the local network for chromecast and cloud print functionality. The patch will probably bring back the mentioned every two minute broadcasts, though i don't think it's used for anything more than printer and chromecast discovery.

Btw, did anyone @ #436 have a look at those packets? It's very unlikely that packages used for udp based discovery are encrypted in any way and i'm sure it would turn out to be just mdns requests addressing printers or something

Tip: mdns traffic can be efficiently tracked and displayed as json by writing a small nodejs program using multicast-dns

What code is affected by the GN flags for mDNS and Service Discovery?

I don't know if i got the question right; the patch doesn't add a GN flag, it adds a chrome://flags flag and a command line argument for chromium.

How will the current patch address any privacy/security concerns related to code that will be enabled?

As i just said, i don't think there are any privacy issues with browsing the local network, as (as far as i can see) ungoogled-chromium blocks any internal requests to the google servers.

Thus i assume this data couldn't possibly be published anywhere and the data will probably even turn out to only be what chromecast devices you have in your house and what printers you have arround.

In line 42 of the patch file, you define a function inside another function

You're absolutely right! Perhaps i have rushed threw this a bit, here's a new version of the patch:

patch (patched).zip

I also made ShouldEnableDiscovery() a private member function.

Also, will the command line flag be guarenteed to be read (in ::Discover()) before any other function is invoked in DnsSdDeviceLister?

Yes, pretty sure!

The only other methods related code is invoked in are callbacks resulting from the discovery and a reset method related to discovery. Everything happens inside a single, nicely assessable file and the patch only enables code that had been disabled by a single patch before.

[…] you could define a new instance variable in the constructor of DnsSdDeviceLister

Yes! The new version of the patch contains the changes.

---

Please tell me if anything's missing, tomorrow I'll probably also provide a concerning nodejs script for #436

[Eloston]

The patch will probably bring back the mentioned every two minute broadcasts, though i don't think it's used for anything more than printer and chromecast discovery.

Will it only bring it back if the flag is enabled?

I don't know if i got the question right; the patch doesn't add a GN flag, it adds a chrome://flags flag and a command line argument for chromium.

Yes, but the patch should address any other code changes that result from changing the GN flags for mDNS and Service Discovery back to their default values (i.e. enabled).

As i just said, i don't think there are any privacy issues with browsing the local network

If the flag is disabled, broadcasts are not acceptable for more cautious users, such as those who want to harden their system. It is not about the payload of the broadcast; it is the act of broadcasting itself that is the issue.

The only other methods related code is invoked in are callbacks resulting from the discovery and a reset method related to discovery. Everything happens inside a single, nicely assessable file and the patch only enables code that had been disabled by a single patch before.

I don't think I'm understanding you correctly. This addresses code within DnsSdDeviceLister, but how about the users of DnsSdDeviceLister (e.g. the code that creates an instance of DnsSdDeviceLister)? Are they guarenteed to call ::Discover() first? For example, is it possible for one of the callback functions to be invoked if a device is already paired before ::Discover() is invoked?

Regarding the new patch:

1. You cannot change a command-line flag during a browser session; They are only read during startup. So, the scenario you described in the code comment is not possible.
2. On line 57, you are still assigning a function to a boolean variable. This is still not valid C++.
3. On line 24, you do not need to add ShouldEnableDiscovery to the header file. Instead, you can move the whole function definition to the unnamed namespace near the top of the .cc file.

[leso-kn]

Will it only bring it back if the flag is enabled?

Yes, as discovery can only be done if the flag is enabled

Yes, but the patch should address any other code changes that result from changing the GN flags for mDNS and Service Discovery back to their default values (i.e. enabled)

Oh! I think there was a missunderstanding from my side. I didn't know there's also GN flags, sorry about that! Of cause we'll have to include those in the patch and check whether it enables any unwanted behaviour.

it is the act of broadcasting itself that is the issue

okay. Then we'll have to make sure there's really no broadcasting if the flag's disabled. I think the easiest solution may be to prepare a prototype patch, compile it and check if any broadcasting is happening.

Are [users of DnsSdDeviceLister] guarenteed to call ::Discover() first?

As i said, i'm sure that it is. If you want we can also adjust the patch to call ShouldEnableDiscovery every time. I was going to put the cache variable in order to keep the performance at best level, but in that case there's practically not really a situation where that plays a major role.

About the new patch:

the scenario you described in the code comment is not possible.

okay, that's right. Even better then! Then technically we may even put the function call in the constructor of DnsSdDeviceLister.

On line 57 […] This is still not valid C++

Yep, sorry about that, i forgot the brackets. As i said, i didn't compile it

On line 24, you do not need to add ShouldEnableDiscovery to the header file.

If you prefer so, sure! I think it's a preference thing but yep, definitely possible.

[leso-kn]

Facing the future of this issue: Do you want me to write a propper patch, or would you prefer writing the final version yourself?

As i said, it's only been a little time arround christmas and work will start again soon, so it may take me some time till i can continue (in a more propper way than before, sorry about all those small mistakes).

I'd still be up for sitting down at some point, checking out the whole chromium sourcecode (till now i only checked out the files i needed) and having a propper overview about what's going on and what needs to be done for writing a clean patch.

[Eloston]

Facing the future of this issue: Do you want me to write a propper patch, or would you prefer writing the final version yourself?
As i said, it's only been a little time arround christmas and work will start again soon, so it may take me some time till i can continue (in a more propper way than before, sorry about all those small mistakes).

If I write this patch, it will not help ungoogled-chromium, its contributors, or myself significantly in the long-term. I'd rather spend time on contributors like yourself, and ensuring we can reach a satisfactory solution.

I am in no rush to complete this feature. You can take as much time as you need.

[ethanpil]

@leso-kn any progress on this? Waiting soooo patiently! :)

[bigmudcake]

I got chromecast working with the "ungoogled" build by first using chrlauncher to download a "stable-codecs-sync" version of chromium.

I then opened the program and changed the chrome flag chrome://flags/#load-media-router-component-extension to enabled, restarted chromium and then clicked on "cast" menu item to generate the profile folder and auto download the needed cast extension "Chrome Media Router".

Casting should be now working with the standard version of chromium. Once this is verified, I deleted the Chromium "bin" folder containing the program files while keeping the "Profile" folder that was created.

I changed the chrlauncher.ini file in order for it to now download and install the ungoogled-chromium version while still using the same profile folder for this build.

You should now find the "cast" menu item still working correctly.

Therefore one can assume that some specific chrome flags are causing the issue of it not working rather than the ungoogled build binary files.

Once I pinpoint the flags that need changing then a wiki page can be made rather than having any code changes. You can also then keep 2 profiles. One for casting and one as your standard ungoogled profile.

[leso-kn]

@bigmudcake That sounds very interesting! I'll try this out within the next days if i find the time.

@ethanpil I'm very busy lately, so i didn't find the time to investigate, sorry. State of things is still: I created a patch mentioned in ^21, but it's still untested.

If someone has the full repo compiling feel free to check it out and see if it works, i'd be happy to investigate if there are any issues!

[bigmudcake]

It appears the latest builds of chromium no longer needs to use any extensions in order to successfully cast to chromecast devices via an experimental flag. Therefore ungoogled -chromium should also be able to cast to chromecast devices.

I got chromecast working with the "ungoogled" build by first using chrlauncher to download the "ungoogled-chromium" version of chromium.

I then opened the URL chrome://flags/#cast-media-route-provider and changed setting to "Enabled". This enables using the native Cast Media Route Provider implementation and no longer needs to download the cast extension "Chrome Media Router".

You should now find the "cast" menu item now works correctly.

My Chromium version that this was tested on was Version 83.0.4103.116 (Official Build) (64-bit)

Therefore if others can verify this works then this issue should now be closed as ungoogled-chromium now supports chromecasting via the "cast-media-route-provider" natively without any further modifications.

[leso-kn]

@bigmudcake That sounds very interesting! I will try it out

[Eloston]

My Chromium version that this was tested on was Version 83.0.4103.116 (Official Build) (64-bit)

That cannot be a standard build of ungoogled-chromium for Windows, because the latest version at the time of writing is 81.0.4044.138-1.1. It might be a chromium.woolyss.com build without the Safe Browsing patches. You should confirm with chrlauncher.

[bigmudcake]

My Chromium version that this was tested on was Version 83.0.4103.116 (Official Build) (64-bit)

That cannot be a standard build of ungoogled-chromium for Windows, because the latest version at the time of writing is 81.0.4044.138-1.1. It might be a chromium.woolyss.com build without the Safe Browsing patches. You should confirm with chrlauncher.

Yes, looking at it further its a "modified" build of ungoogled-chromium according to Chrlauncher INI file it states:
ungoogled-chromium
Unofficial builds without Google integration and enhanced privacy (based on Eloston project)
"github.com/macchrome/winchrome/releases" (32/64 bit)
"github.com/Eloston/ungoogled-chromium"

Therefore it uses the realease built at "github.com/macchrome/winchrome" which in the release notes state:

Standard build of Eloston's ungoogled-chromium. All patches applied apart from "Safe Browser"
and "Add flag for internal PDF viewer plugin name"

I will try a pure build and see if the "safe browser" patches make a difference.

[bigmudcake]

I have now tested Version 81.0.4044.138 (Developer Build) (64-bit) as supplied via https://ungoogled-software.github.io/ungoogled-chromium-binaries/releases/windows/64bit/81.0.4044.138-1.1

It seems that after changing flag chrome://flags/#cast-media-route-provider to "Enabled" chromecasting also works.

[leso-kn]

@bigmudcake I finally took the time to test this. Can confirm, it works for me too!

Perhaps for now it's sufficient to have this as an optional feature? We could document the flag in the wiki and close this issue @Eloston

If at some point the flag is being removed or it stops working for some other reason, a new issue could be opened.

[Eloston]

@leso-kn I agree. Closing.