[frankjr]

> This does bring Chromium in line with the URL spec, but Firefox still works properly with those callback links. Not sure which other engines you are speaking of, to my knowledge there really aren't any other viable Windows desktop browsers.

Hm, you're right, they're still working on it (https://bugzilla.mozilla.org/show_bug.cgi?id=1876105). Is it Safari then? I don't remember and don't have a way to test it right now. Obviously Safari is not something you care about on Windows anymore.

> On the server side, this is dead-easy to fix. For example register customprotocol64: and pass all your data in a base64 encoded blob, to stop the browser from mangling it.

You don't need to obfuscate it that much, just not start with // and then the rest can be still human readable/inspectable.

> Unfortunately every single offered workaround starts with deploying an upgraded version of your desktop application, so it understands the fixed link format. The challenge is not making the URLs spec compliant, it's getting the massive install bases upgraded to a version that properly parses the new URL format.

I agree. I'm a little bit surprised that they just dropped this and there wasn't any "grace" period where the browser would parse the URL as before but complained loudly in logs/console.

> PS Better just bite the bullet and start planning those emergency upgrades now, the odds of the Chromium team restoring non-standards-compliant behaviour to fix thousands of enterprise apps is essentially zero

It wouldn't be unheard of. If a big important Google customer complained enough, they might release a patch version with the kill switch turned on (base::kStandardCompliantNonSpecialSchemeURLParsing).

[nikanj]

> You don't need to obfuscate it that much, just not start with // and then the rest can be still human readable/inspectable.

Fool me once, shame on you. Fool me twice, shame on me. I'll never again trust Chrome to not "help" with custom URLs