Powerful extensions do not need powerful code · A Day In The Life Of...<br>← PreviousLast night an AI saved my life

When Chrome introduced Manifest V3, ad blockers took the biggest hit. The idea behind MV3 itself was not necessarily a<br>bad one: extension code that sits in the request path of every page load is bad for security and bad for performance, so<br>it had to go. The replacement however was a capped and much less expressive rule format, and the most popular type of<br>extension suddenly got a lot worse. Since then, the general feeling seems to be that you can have security, or you can<br>have proper ad blocking, but not both.<br>We don&rsquo;t believe that is true. For Gosub, we are designing our extension system around a simple idea: powerful<br>extensions do not need powerful extension code. If the browser itself provides good enough building blocks, an extension<br>can do a lot of things while its own code is allowed to do almost nothing. The install dialog is what nudges extension<br>authors in that direction.<br>Capabilities, not permissions<br>In Chrome, the manifest basically is the grant: you list permission names, and those names map more or less directly<br>onto API surface. In Gosub, we treat the manifest as just input. During installation we translate it into an explicit<br>list of capabilities with scopes, things like filtering.block(all sites), content_script(youtube.com) or<br>network.egress_public(api.example.com). That list is what the enforcement layer, the dialogs and revocation all work<br>with, not the manifest itself. This gives us a few things Chrome cannot do:<br>A host permission on its own means nothing. It only means something in combination with the API that uses it:<br>host_permissions plus scripting becomes content_script(hosts), the same hosts plus cookies becomes<br>cookies.read/write(hosts), and so on. There is no general &ldquo;access to example.com&rdquo;.<br>Nothing ever translates into a wildcard. The grant is always a concrete list, so a capability we add next year can<br>never silently end up in the grant of an extension that was installed today.<br>An extension can narrow its grant, but never widen it. With an optional gosub key in the manifest, an author can say<br>&ldquo;of everything my Chrome permissions imply, I only need these&rdquo;. If that key contains a name the translation did not<br>derive, it is rejected, not granted. And unknown or garbage permission strings (the ecosystem is full of them) are<br>simply ignored.<br>When permissions combine<br>Chrome&rsquo;s install prompt lists permissions one by one, and each line on its own sounds harmless enough. The problem is<br>that permissions combine. An extension that can read pages and can talk to the network, can read your pages and send<br>them somewhere. Neither line tells you this.<br>So during translation we don&rsquo;t stop at the individual capabilities. We also calculate what the combinations add up to,<br>and the dialog leads with that instead of with the ingredient list. Let&rsquo;s look at a real one. This is the manifest of<br>Grammarly, straight from the Chrome Web Store, run through our translator:<br>(All dialog images in this post are styled renderings of the actual output of our translator. None of the text inside<br>them was written by hand.)<br>To be clear: this does not mean that Grammarly is doing any of these things. It is a perfectly legitimate tool, and to<br>check your writing it simply needs to read what you type, on every site. But that is exactly the point: the current<br>permission model cannot tell the difference between a grammar checker and a keylogger, since both need to read what you<br>type. So the dialog shows what the granted authority makes possible, instead of guessing what the extension intends to<br>do with it. We only inform the user, we never forbid anything; it is still the user who decides.<br>Further down, the dialog lists what the extension cannot do. We can prove those claims from the grant, and they give<br>the user some contrast to judge the warnings against. And at the very bottom you can see the optional permissions:<br>things Grammarly may ask for later, together with what agreeing to them would unlock.<br>Loudness as an incentive<br>Every capability has a tier: silent, standard, loud or gated. Loud grants, and anything that produces a derived warning,<br>get the ! treatment you saw above. So yes, an extension can still do everything with its own privileged code. But if<br>it does, the dialog will spell out exactly what that code is able to do. Do you want a content script on every site? You<br>can have one, but your users will be told in plain words what that means.<br>The other half of the story is that the browser offers safer building blocks for the things extensions usually do:<br>filtering, cosmetic hiding, a vetted scriptlet library, mediated form filling, declarative DOM actions. If you use such<br>a primitive instead of your own code, your dialog becomes quieter. So the dialog really has two audiences: it tells the<br>user what an extension can do, and it gives the author immediate...