<div dir="ltr"><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small">It will be tons easier to distribute a small WebExtension that works on every OS than a whole browser on multiple platforms, and having to maintain a robust update infrastructure and constantly chasing the upstream source to keep up with security fixes. I STRONGLY RECOMMEND you try to make that work before taking on the responsibility of going down the custom-browser path.<br></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small">The extension mechanism Dave linked to can also resolve to a page internal to your extension which I would expect to be a blank shell that loads your JS libraries and generates the web content in-place--you don't necessarily have to just translate it to an HTTPS request to a server you have to keep running. This mechanism and the HTML registerProtocolHandler API that Jonathan mentioned will only work for "documents" (windows/tabs and iframes) and not arbitrary tags like the <IMG> you gave as an example. The fact that you want both makes me worry that you might be using this protocol as a "command" that affects the state of something rather than as something that returns data (there's nothing that makes sense as a document, a <script> and an <img>, for example), and exposing a command language to the web usually ends in tears. See, for example, the cautionary tale of <span style="font-family:monospace">zoomopener:</span> from last summer <a href="https://blog.assetnote.io/bug-bounty/2019/07/17/rce-on-zoom/">https://blog.assetnote.io/bug-bounty/2019/07/17/rce-on-zoom/</a></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small"><br></div><span class="gmail_default" style="font-family:arial,sans-serif;font-size:small">-Dan Veditz</span></div>