Our great sponsors
-
EdgeDeflector
Discontinued A tiny helper application to force Windows 10 to use your preferred web browser instead of ignoring the setting to promote Microsoft Edge. Only runs for a microsecond when needed.
-
winget-cli
WinGet is the Windows Package Manager. This project includes a CLI (Command Line Interface), PowerShell modules, and a COM (Component Object Model) API (Application Programming Interface).
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
brave-core
Core engine for the Brave browser for Android, Linux, macOS, Windows. For issues https://github.com/brave/brave-browser/issues
Great write-up! I did want to share a brief response to the following, however:
> The new implementations in Brave and Firefox follow the exact parsing logic I wrote for EdgeDeflector. It’s not the only way to parse them, it’s not the best way to parse them, but it’s the way every third-party implementation now parses them. Neither codebases attribute the code to EdgeDeflector, although both are clearly inspired by it. (Don’t get me wrong, I’m fine with this.)
With all due respect to the author, I don't believe this is an accurate statement. While the problem being solved (parsing a microsoft-edge: protocol string) is quite simple, there are still noticeable differences in how EdgeDeflector, Brave, and Firefox have chosen to tackle this process.
[EdgeDeflector](https://github.com/da2x/EdgeDeflector/blob/469a0c8523c6bb7fb...) checks to see not only that the string begins with "microsoft-edge:", but also that it does not contain any space character (" "). The latter check *is not* conducted by [Brave](https://github.com/brave/brave-core/blob/8a93d29c45800719c9e...) or [Firefox](https://phabricator.services.mozilla.com/differential/change...). EdgeDeflector performs an initial case-insensitive check for the protocol, while Brave and Firefox do not (both expect lower-case characters). There is a code path in EdgeDeflector where a case-sensitive check may also be conducted.
EdgeDeflector and Brave both remove the "microsoft-edge:" prefix from the input, but Brave performs and additional check at this point. If the resulting string is empty, Brave stops attempting to extract a workable URL.
EdgeDeflector performs no such empty-string test, instead proceeding to check whether the resulting string starts with "https://" or "http://" (a case-insensitive match). Firefox also proceeds to check whether the string starts with "https:" or "http:". Brave, on the other hand, proceeds to check whether the resulting string starts with a ? character.
If the string doesn't start with a ? character, Brave attempts to parse the string as a URL and initiate navigation. If the string begins with a ? character, Brave removes that character and proceeds to split the string into chunks on occurrences of the & character.
With the string split into chunks, Brave cycles over each piece looking for one that starts with "url=". If a match is found, Brave attempts to parse everything after the = character as a URL. If it succeeds, that URL is visited.
Firefox and EdgeDeflector do take a similar approach in these later steps. While EdgeDeflector utilizes .NET's HttpUtility.ParseQueryString to parse and extract the URL value, Firefox passes the string to the URLSearchParams constructor, and retrieves the "url" parameter from the resulting object. Brave is the odd-man out on this step, opting instead to split the string, and cycle through to the nearest matching chunk.
While there are similarities here and there (given the simplicity of the task itself), there are stark differences as well. One thing is certain, however, Brave and Firefox both explicitly refer to EdgeDeflector as leading this effort to restore liberty to users impacted by Microsoft's heavy-handed approach to shoehorning users back into Microsoft Edge.
I'm still hoping winget[1] catches on so I can just utilize that for all the tools I typically use, but it seems like it's still a ways away from being fully ready. Still making progress, though.
[1] https://github.com/microsoft/winget-cli
Great write-up! I did want to share a brief response to the following, however:
> The new implementations in Brave and Firefox follow the exact parsing logic I wrote for EdgeDeflector. It’s not the only way to parse them, it’s not the best way to parse them, but it’s the way every third-party implementation now parses them. Neither codebases attribute the code to EdgeDeflector, although both are clearly inspired by it. (Don’t get me wrong, I’m fine with this.)
With all due respect to the author, I don't believe this is an accurate statement. While the problem being solved (parsing a microsoft-edge: protocol string) is quite simple, there are still noticeable differences in how EdgeDeflector, Brave, and Firefox have chosen to tackle this process.
[EdgeDeflector](https://github.com/da2x/EdgeDeflector/blob/469a0c8523c6bb7fb...) checks to see not only that the string begins with "microsoft-edge:", but also that it does not contain any space character (" "). The latter check *is not* conducted by [Brave](https://github.com/brave/brave-core/blob/8a93d29c45800719c9e...) or [Firefox](https://phabricator.services.mozilla.com/differential/change...). EdgeDeflector performs an initial case-insensitive check for the protocol, while Brave and Firefox do not (both expect lower-case characters). There is a code path in EdgeDeflector where a case-sensitive check may also be conducted.
EdgeDeflector and Brave both remove the "microsoft-edge:" prefix from the input, but Brave performs and additional check at this point. If the resulting string is empty, Brave stops attempting to extract a workable URL.
EdgeDeflector performs no such empty-string test, instead proceeding to check whether the resulting string starts with "https://" or "http://" (a case-insensitive match). Firefox also proceeds to check whether the string starts with "https:" or "http:". Brave, on the other hand, proceeds to check whether the resulting string starts with a ? character.
If the string doesn't start with a ? character, Brave attempts to parse the string as a URL and initiate navigation. If the string begins with a ? character, Brave removes that character and proceeds to split the string into chunks on occurrences of the & character.
With the string split into chunks, Brave cycles over each piece looking for one that starts with "url=". If a match is found, Brave attempts to parse everything after the = character as a URL. If it succeeds, that URL is visited.
Firefox and EdgeDeflector do take a similar approach in these later steps. While EdgeDeflector utilizes .NET's HttpUtility.ParseQueryString to parse and extract the URL value, Firefox passes the string to the URLSearchParams constructor, and retrieves the "url" parameter from the resulting object. Brave is the odd-man out on this step, opting instead to split the string, and cycle through to the nearest matching chunk.
While there are similarities here and there (given the simplicity of the task itself), there are stark differences as well. One thing is certain, however, Brave and Firefox both explicitly refer to EdgeDeflector as leading this effort to restore liberty to users impacted by Microsoft's heavy-handed approach to shoehorning users back into Microsoft Edge.