--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/279adf77-aba3-45aa-860c-d588e76235a1%40chromium.org.
You should probably try to re-work your code so yo're not using eval().Eval() is potentially dangerous, I'd be very surprised if Google allowed it under any circumstances.
On Mon, Dec 16, 2019 at 9:16 AM Hr Gwea <hrg...@gmail.com> wrote:
The Manifest V3 migration guide says: If you are using eval() in content scripts, then move all external code into your extension bundle.--
Does this mean that it won't be possible to allow the use of eval() via the CSP content_security_policy.isolated_world ?If this is the case, then our only option to evaluate JS code in a page would be to inject a <script> element and hope that the page doesn't prevent eval() with its own CSP.Is this the intention with the new manifest V3?i.e. to relay the decision (of whether eval() is permitted) to the webpage's author via their own CSP, and the extension developer has to obey?
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extensions+unsub...@chromium.org.
function myEval(code){
let elem = document.createElement('script') ;
elem.textContent = code ;
document.head.appendChild(elem) ;
}
myEval("Arbitrary JS code") ;
Injecting a <script> element with arbitrary code is exactly the same as using eval(), so I would say they are very much related.
An attack vector that could exploit a vulnerability related to eval() in the isolated world can very well exploit a similar vulnerability related to myEval (the function I gave in my last post).
I don't see much of a difference. The few chrome APIs that are accesible from the isolated world context doesn't justify for me to prevent eval() in that context.
Do they want to prevent arbitrary code execution in general ("remotely hosted code" as they call it)?Or do they only wan't to prevent arbitrary code execution that has access to chrome APIs?
By the two links you provided, the former is discarded. They don't want to prevent arbitrary code in general.
Which means that user script extensions like Tampermonkey and others will be able to continue to work (which makes me wonder why there are so many news about this saying that user script managers could stop working... nonsense).
let elem = document.createElement('script') ;
elem.src = chrome.runtime.getURL('file.js') ;document.head.appendChild(elem) ;
let elem = document.createElement('script') ;
elem.textContent = 'arbitrary code' ;document.head.appendChild(elem) ;
We want to find a way to let Tampermonkey and similar tools keep working while also disallowing other extensions from executing arbitrary script.
chrome.tabs.insertCSS(tabId, {code:'...Arbitrary CSS...'})
Not just 'arbitrary code' (as this can be interpreted as a literal code string which is obviously allowed since it's inside the package) but specifically external code, not present in the extension package. - wOxxOm
Will you provide a workaround for extensions that do [chrome.tabs.insertCSS]? … This means extensions like Stylish and Stylus face the same fate as user-script managers. - Hr
Not just 'arbitrary code' (as this can be interpreted as a literal code string which is obviously allowed since it's inside the package) but specifically external code, not present in the extension package. - wOxxOmI don't believe this is accurate; to my knowledge the code must be in a file that is included with the extension. As a practical result developers won't be able to ship Webpack development builds.