Enable user opt-in requirement for content scripts in isolated apps by default
Project Member Reported by firstname.lastname@example.org, Apr 19 2012
Currently, an extension can apply to all sites and apps, based on the extension's manifest. To give the user more control, we should support a list of sites and apps to which extensions do not apply, even if their manifests request otherwise. This list would be exposed in the settings and controlled by the user, not the sites themselves. For example, a user may want to install an extension that modifies all sites, but exclude his bank. Note that isolated apps ( issue 69335 ) and platform apps could be placed on this list by default, unless the user chooses otherwise.
Apr 19 2012,
This is going to have to go through UI team as it's a significant amount of new settings UI. But presuming they're into it, I think it makes more sense for this to control whether extensions can run script on the page automatically. We're planning work that will eventually result in most extensions being prevented from automatically running scripts in pages; instead users will have to click a button to execute the script. However we will have to gradually move the ecosystem over to this model. See https://docs.google.com/a/google.com/document/d/1wvybpTbaiFwlJ9IxO9ygYHrz837jSzvgx9YwVc-KESk/edit for more on our plans here. My proposal would be that isolated apps use this model from the beginning. The advantage here is that no configuration UI is required at all.
May 2 2012,
If we can make that model (extensions cannot inject script into a page until the user clicks a button) work on isolated apps in the short term, then I agree we should go with that approach. It avoids any complexity about presenting new UI. Aaron, is there a way we can turn on that requirement if we know the current page is an isolated app?
May 2 2012,
Besides navigation, there also are also other extension APIs that could affect isolated apps (and platform apps): - windows/tabs - context menus - content settings - webRequest/webNavigation Do we want to guarantee some level of isolation from these too?
May 2 2012,
@creis: Yes, we could easily default isolated apps into this model. I just created bug 125962 to track the work I was talking about for opting into content scripts. @mihaip: I think we can consider the platform app case separately. At least initially, I think everyone is in agreement we want to start conservative, and not have any extension visibility into platform apps. But that does not require a list as this bug proposes.
May 4 2012,
See also bug 126257. It's important to check the top-level frame to determine whether something is part of an extension/app.
May 11 2012,
@comment 3: I'm not too concerned about windows/tabs APIs or context menus for isolated apps, and I think we actually want to allow webRequest and webNavigation to still work, since those are often used for privacy enhancing extensions. Not sure about content settings, but I don't see an immediate risk for isolated apps. Bottom line, I think issue 125962 (requiring user opt-in before running content scripts) is sufficient for isolated apps. We'll just ensure that's enforced by default, based on the process and top-level frame. (Thanks for the remdiner, Adam.)
Apr 23 2015,
Jun 21 2016,
This issue has been available for more than 365 days, and should be re-evaluated. Hotlist-Recharge-Cold label is added for tracking. Please re-triage this issue. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Sign in to add a comment