Find ways to get InnerTube's client version and API key of WEB and WEB_REMIX clients without using YouTube and YouTube's Music HTML pages

[AudricV]

I'd like to avoid parsing YouTube and YouTube Music HTML pages to get InnerTube's client version and API key of the WEB and WEB_REMIX clients (even if for the last one, the hardcoded version is always used first if it is considered as valid), as it also help to avoid reCAPTCHA issues.

Previously, we were able to do so by using YouTube and YouTube Music's service workers (https://www.youtube.com/sw.js and https://music.youtube.com/sw.js) but they do not contain these information anymore.

The "obfuscated versions" of these scripts (which use JSON protobuf) (https://www.youtube.com/sw.js_data and https://music.youtube.com/sw.js_data) still contain them, but their unreadable form makes a bit difficult to be sure to parse the correct data.

I also know that we can use the embed HTML page of a video for the WEB client, but versions provided are not the same as the ones of the WEB client, but the ones of the WEB_EMBEDDED_CLIENT instead. Even if using the last digits of the WEB_EMBEDDED_CLIENT as the ones of the WEB client would work, this would probably allow YouTube to fingerprint more the extractor.

That's the reason why I am asking all members working on YouTube projects to share there researches and findings about getting client version and API key of these InnerTube clients without using YouTube and YouTube Music's HTML pages in this issue.

[89Q12]

I'm still new to this whole matter and don't if my opinion is even anything new or asked but I don't know if you all ever thought about this, but looking at he WEB / WEB_REMIX client version. This jumps at me:
Version:2, Date(YYYY/MM/DD):20220712 Time:01.00

Knowing that we get 404 when the client version is wrong we can just fuzz it and from the little testing I did just now, we only get a 404 if its not a valid date or the major version is wrong but they are still on 2 so that's not a big deal.

For example these work fine:
2.20330704.00.00(WEB)
2.19700101.12.00(WEB)
2.19700101.24.59(WEB)
1.20330704.00.00(WEB_REMIX)
1.19700101.12.00(WEB_REMIX)
1.19700101.24.59(WEB_REMIX)
or even these:
2.99990101.24.59(WEB)
1.99990101.24.59(WEB_REMIX)

A note to take is that WEB and WEB_REMIX have different major versions, meaning WEB is on 2.xxxxxxxx.xx and WEB_REMIX is still on 1.xxxxxxxx.xx. All this seems to apply to all kinds of clients

Looking the current version in the YouTube site they are on 2.20220712.01.00.
Now if we were to look at the history of the page for lets say a few months and extract the versions they are on in contrast to the day the page snapshot was taken, we should be able to predict the version the current client is on. I would just stick to the today's date minus 2 days and set the time to 01.00 as the version.

Now this obviously has nothing to do with the api key but seeing that they still use the known key in the web app I think its fine to just look from time to time what they are using or maybe setup a CI pipeline for it that runs every other day or so.

Anyway maybe this is all just complete nonsense but yeah thanks for reading my take on this and sorry if its nothing new or I'm repeating things :|

[opusforlife2]

Apart from reducing reCAPTCHAs, will this have any performance/data saving benefits?

[AudricV]

It depends of the size and the number of network requests needed, but probably yes.

[sseodate]

does that mean that INNER api key is dead after sometimes ?