3 ms·

How is web side javascript being sandboxed from extensions? Extensions can inject javascript into web pages. (Assuming it works like Chrome, then sure the code

How is web side javascript being sandboxed from extensions? Extensions can inject javascript into web pages. (Assuming it works like Chrome, then sure the code runs in a separate isolated world by default, but you can inject code to run in the web page's own context by appending a script element to the page.)

brudgers 9y ago
The content provider gets to define the entire javascript context before any code can be injected. The content providers code can monitor the DOM and prevent other code from changing it. It can effectively whitelist/blacklist URL's. It can redefine everything from object.prototype on down. The logical structure is that user side code can only do what the content provider does not prevent. content scripts have some limitations. They cannot: + Use chrome.* APIs, with the exception of: extension ( getURL , inIncognitoContext , lastError , onRequest , sendRequest ) i18n runtime ( connect , getManifest , getURL , id , onConnect , onMessage , sendMessage ) storage + Use variables or functions defined by their extension's pages + Use variables or functions defined by web pages or by other content scripts https://developer.chrome.com/extensions/content_scripts https://developer.chrome.com/extensions/content_scripts
- AgentME 9y ago
  Doesn't setting "run_at":"document_start" allow the content script to run before any of the page's scripts? All of those ways that you mentioned that a web-page could booby-trap its javascript context could be done by an extension first. >+ Use variables or functions defined by their extension's pages >+ Use variables or functions defined by web pages or by other content scripts Those are just consequences of the content script not running in the same javascript context. If it ran in the same context, then the web page javascript could access private extension APIs or otherwise break content script code. If you actually want to interact with the page's variables, there's ways to do that.

brudgers 9y ago

The content provider gets to define the entire javascript context before any code can be injected. The content providers code can monitor the DOM and prevent other code from changing it. It can effectively whitelist/blacklist URL's. It can redefine everything from object.prototype on down. The logical structure is that user side code can only do what the content provider does not prevent. content scripts have some limitations. They cannot: + Use chrome.* APIs, with the exception of: extension ( getURL , inIncognitoContext , lastError , onRequest , sendRequest ) i18n runtime ( connect , getManifest , getURL , id , onConnect , onMessage , sendMessage ) storage + Use variables or functions defined by their extension's pages + Use variables or functions defined by web pages or by other content scripts https://developer.chrome.com/extensions/content_scripts https://developer.chrome.com/extensions/content_scripts

AgentME 9y ago
Doesn't setting "run_at":"document_start" allow the content script to run before any of the page's scripts? All of those ways that you mentioned that a web-page could booby-trap its javascript context could be done by an extension first. >+ Use variables or functions defined by their extension's pages >+ Use variables or functions defined by web pages or by other content scripts Those are just consequences of the content script not running in the same javascript context. If it ran in the same context, then the web page javascript could access private extension APIs or otherwise break content script code. If you actually want to interact with the page's variables, there's ways to do that.