Support for QUIC through cronet

[FireMasterK]

Checklist

• [x] I checked, but didn't find any duplicates (open OR closed) of this issue in the repo.
• [x] I have read the contribution guidelines given at https://github.com/TeamNewPipe/NewPipe/blob/HEAD/.github/CONTRIBUTING.md.
• [x] This issue contains only one feature request. I will open one issue for every feature I want to request.

Describe the feature you want

https://developer.android.com/guide/topics/connectivity/cronet

I want to support quic though cronet (chromium's network stack), so we can replicate a chrome browser and bypass recaptchas.

Is your feature request related to a problem? Please describe it

Without quic, you may be limited to captchas as explained in https://github.com/iv-org/invidious/issues/957#issuecomment-576424042.

How will you/everyone benefit from this feature?

Lesser captchas for everyone who uses QUIC! (this does not include tor users as tor is tcp only)

[FireMasterK]

There is a GMS version of cronet, and a non GMS version:

"In cases where Cronet cannot be loaded from Google Play services, there is a less performant implementation of Cronet's API that can be used. To use this fall-back implementation, depend on org.chromium.net:cronet-fallback and call new JavaCronetProvider(context).createBuilder()."

We want to use the non GMS version ideally.

[FireMasterK]

There also appears to be a cronet extension for exoplayer: https://github.com/google/ExoPlayer/tree/release-v2/extensions/cronet

[Stypox]

Can't the specific functionality of QUIC that fixes recaptchas be used here? I wouldn't want to add a full network stack just for making normal requests...

[FireMasterK]

Here's something that Omar Roth said regarding quic and captchas: https://github.com/iv-org/invidious/issues/957#issuecomment-576424042

[Stypox]

Yeah I've read that

[unixfox]

I don't think it's worth keeping this issue opened because the innertube API doesn't have CAPTCHA, and they are not going to restrict users that don't communicate to the YouTube API through HTTP3.

Simply because HTTP3 doesn't work everywhere, some networks like enterprise networks do block UDP connections, so YouTube apps fallback to HTTP2.

[AudricV]

so YouTube apps fallback to HTTP2

Not for Google video servers, which only support HTTP/1.1 and HTTP/3.

Also Cronet sends a user-agent ID containing the application package and its version. This is not not configurable at all from Cronet APIs, and may be configurable by writing of a lof of custom classes, but would require a ton of work and maintainability in the future. This could be used in the future to fingerprint NewPipe.

I suggest instead to wait on other network stacks to implement a proper HTTP/3 support, once it is finally a real standard.

[FireMasterK]

Also Cronet sends a user-agent ID containing the application package and its version. This is not not configurable at all from Cronet APIs, and may be configurable by writing of a lof of custom classes, but would require a ton of work and maintainability in the future. This could be used in the future to fingerprint NewPipe.

Can't that be changed with https://chromium.googlesource.com/chromium/src/+/lkgr/components/cronet/android/api/src/org/chromium/net/CronetEngine.java#111?

[AudricV]

This is to set the User-Agent header, not the QUIC User-Agent ID.

See https://chromium.googlesource.com/chromium/src/+/lkgr/components/cronet/android/api/src/org/chromium/net/CronetEngine.java#143 and https://chromium.googlesource.com/chromium/src/+/lkgr/components/cronet/android/java/src/org/chromium/net/impl/CronetEngineBuilderImpl.java#227.

[vukitoso]

I support adding QUIC (HTTP/3).