Haketilo

Jahoti, please, remind me. Why aren't we just making a synchronous AJAX call in the content script and redirecting it appropriately using webRequest?

Btw, I tested that redirecting to data: works under Ungoogled Chromium. I seem to be having problems getting anything to work under Mozilla but honestly, I experimented little

Jahoti, please, remind me. Why aren't we just making a synchronous AJAX call in the content script and redirecting it appropriately using webRequest?

Primarily because you never mentioned it and I never thought of it :). If this works, it will make life much easier!

Btw, I tested that redirecting to data: works under Ungoogled Chromium. I seem to be having problems getting anything to work under Mozilla but honestly, I experimented little

I will continue the experimenting right now.

It turns out Firefox did once support redirection to data: URLs (prior to v60, it seems), before it was accidentally broken and forgotten about for long enough the devs decided it wasn't worth fixing: https://bugzilla.mozilla.org/show_bug.cgi?id=1475832. It's quite shocking how many useful old features have been left to rot by Mozilla.

That said, there are several options. Apart from the obvious approach of data: URLs for Chromium and contentScripts.register for Firefox, both browsers support tabs.executeScript (and Manifest V3 has the somewhat similar scripting.executeScript), and somebody has somehow written a contentScripts.register polyfill for Chromium.

This might also (not as a priority!) remove the need for bundled secrets on Chromium, in fact, as the secret can be stored in storage.

That said, there are several options. Apart from the obvious approach of data: URLs for Chromium and contentScripts.register for Firefox, both browsers support tabs.executeScript (and Manifest V3 has the somewhat similar scripting.executeScript), and somebody has somehow written a contentScripts.register polyfill for Chromium.

Actually, I thought about simply redirecting to an extension-packaged file. For basic functionality we only need 3 such files, with contents that tell the content script to either allow everything, block scripts or block scripts & sanitize <meta>s. For the third option we would need to find a way content script could deal without an immediately-accessible nonce... but this should be achievable. Although I am still suspecting it might be possible to smuggle arbitrary data somehow

As to tabs.executeScript (and the polyfill that depends on it), I don't thing it gives the document_start guarantees we need :/

This might also (not as a priority!) remove the need for bundled secrets on Chromium, in fact, as the secret can be stored in storage.

With this we're not going to need any secret at all :)

Actually, I thought about simply redirecting to an extension-packaged file. For basic functionality we only need 3 such files, with contents that tell the content script to either allow everything, block scripts or block scripts & sanitize <meta>s. For the third option we would need to find a way content script could deal without an immediately-accessible nonce... but this should be achievable. Although I am still suspecting it might be possible to smuggle arbitrary data somehow

That's a good idea! Come to think of it, couldn't we use the query component of the file's URL to smuggle arbitrary data? In fact the actual contents of the file wouldn't even really matter then- the full path itself could provide all the necessary information.

As to tabs.executeScript (and the polyfill that depends on it), I don't thing it gives the document_start guarantees we need :/

Ah! I forgot about that.

With this we're not going to need any secret at all :)

Which means we won't need any dependencies either! (Not, of course, that it's a significant problem anyway)

Unfortunately, smuggling via redirection of requests seems to open up the risk of fingerprinting; I can't find a useful way to distinguish requests made by content script from requests made by pages :'(.

jahoti wrote:

Unfortunately, smuggling via redirection of requests seems to open up the risk of fingerprinting; I can't find a useful way to distinguish requests made by content script from requests made by pages :'(.

I thought the "universal" way would be to keep track of what tabs and frames have already made such request and only redirect the first such request in frame's lifetime, blocking subsequent ones.

I did, however, hope there could be some simpler solution. When I tried it seemed that some fields of the details object were different in cases the AJAX call was made by content script. Or have you already found that this is not reliable enough?

I did, however, hope there could be some simpler solution. When I tried it seemed that some fields of the details object were different in cases the AJAX call was made by content script. Or have you already found that this is not reliable enough?

Not at all- the documentation, insofar as I can tell, doesn't mention such behavior. When there's time I'll test and see if there's any information available on what happens.

You know what? I'd leave the fingerprinting issue for now. The vunlerability doesn't exist in Mozilla browsers and can be mitigated in Manifest V3 under Chromium which we're going to support anyway. It might be more practical to release more quickly and just warn users of this

I'd leave the fingerprinting issue for now. The vunlerability doesn't exist in Mozilla browsers and can be mitigated in Manifest V3 under Chromium which we're going to support anyway.

Dynamic content scripts can also be used in both cases, which may be necessary (seeing as Mozilla doesn't offer effective synchronous AJAX).