Just look at the code, it's determining that h/w accel exists in Chrome OS. If it's not in this path it gets 720p as the highest resolution. This isn't some widevine/netflix joint effort that recently got leaked or something.
Yes fair point, that's the only thing happening client side.
But somebody else mentioned that widevine on chrome os and chrome are different. So I wouldn't have expected their servers to accept those 1080p requests for chrome's version.
Edit: says so on Github:
ChromeOS apparently has a different DRM implementation than chrome, even though both use Widevine.
There are two different things going on here. One is detecting Chrome OS and the other is determining the set of stream profiles. If you were to change your useragent to get Chrome OS, like the GitHub says, this would alter code paths in other areas related to DRM. However the fix that was found was simply pushing the stream profile into the array. This doesn't affect DRM at all.
The fix from the Netflix side would be to find a suitable alternative to user agent sniffing for h/w accel and swap that in to this code path.
What I am saying is: If they are blocking everything but chrome os intentionally, it would have been easier.
According to widevine docs [1] chrome on desktops does not support security level 1. They could have and probably did block access to 1080p content on level 3.
Which leads me to believe that netflix relaxed security to allow 1080p on level 3.
As you said the next step would be to replace the user agent detection client side.
