Great write-up! I did want to share a brief response to the following, however:<p>> 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.)<p>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.<p>EdgeDeflector (<a href="https://github.com/da2x/EdgeDeflector/blob/469a0c8523c6bb7fb09ce8d93db432a99f2c1db7/EdgeDeflector/Program.cs#L54" rel="nofollow">https://github.com/da2x/EdgeDeflector/blob/469a0c8523c6bb7fb...</a>) 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 (<a href="https://github.com/brave/brave-core/blob/8a93d29c45800719c9e9a76b575a1e5034a47aaf/browser/microsoft_edge_protocol_util.cc" rel="nofollow">https://github.com/brave/brave-core/blob/8a93d29c45800719c9e...</a>) or Firefox (<a href="https://phabricator.services.mozilla.com/differential/changeset/?ref=4340483" rel="nofollow">https://phabricator.services.mozilla.com/differential/change...</a>). EdgeDeflector performs an initial case-insensitive check for the protocol, while Brave and Firefox do not (both expect lower-case characters). <i>There is a code path in EdgeDeflector where a case-sensitive check may also be conducted.</i><p>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.<p>EdgeDeflector performs no such <i>empty-string</i> test, instead proceeding to check whether the resulting string starts with "<a href="https://" rel="nofollow">https://</a>" or "<a href="http://" rel="nofollow">http://</a>" (a case-insensitive match). Firefox also proceeds to check whether the string starts with "https:" or "http:", but in a case-sensitive manner. Brave, on the other hand, proceeds to check whether the resulting string <i>starts with</i> a ? character.<p>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.<p>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.<p>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.<p>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.