Content Script Isolation for IE

[reicolina]

Hi, @antoinevg 👋 Question for you, if you don't mind: Firefox has the Sandbox and evalInSandbox() functionalities and Chrome has sandboxed (isolated worlds) execution in their content scripts. Unfortunately, IE doesn't provide such isolation mechanisms out of the box, which causes naming and library (i.e jQuery, Angular, etc) conflicts between injected scripts and the host page. I've been trying to explore ways that we could create such an isolated context within the BHO C++ implementatiom but wanted to ask you first, in case you have any suggestions, solutions in mind, or even comments on the matter?

I, and I'm sure a lot of people in the community, wouldn't mind writing the actual implementation, but any insights are very welcome 😄

Thoughts?

[antoinevg]

Hey @reicolina!

It's been a rather long time since I've thought about any of this so I'm not sure how much insight I have to contribute :-)

So Firefox and Chrome have the advantage in that they can pretty much create as many Javascript contexts as they want with complete control over how much or little access they have to each other and the parent HTML contexts.

With IE there is no way to instantiate additional Javascript contexts within the scope of the browser window.

That said, if you can live without direct access to the parent browser and handle all communication between the sandboxed code via some kind of JSON messaging interface it might be do-able.

A heavy-weight approach would be to adapt the existing code for hosting background scripts (ie/source/forge/NativeBackground.cpp if my memory doesn't betray me!) to create a new hidden browser instance for each Tab to run your sandboxed code in.

A lighter weight approach might be to, rather than creating a whole new hidden browser for running Javascript, just create a new instance of the Microsoft Javascript engine for each tab and execute on that?

[reicolina]

I like the Javascript Engine "lighter" approach you mentioned. Do you think that either with that approach or with the NativeBackground one, the script will be able to communicate with the host's DOM? just wondering 🤔

One idea in the back of my mind is to move all "conflicting" code/libraries to a background script, and just leave the parts that communicate with the DOM in the content script. The two could communicate with each other via messaging. However, that may not be the perfect solution for all use cases, since, in some instances, libraries like Angular or jQuery are used to communicate with the DOM from the content script, which is one of the main causes of conflicts.

Thanks again, @antoinevg! 🙌