nigeltao@ - can you please help triage (as the call to SetContentSettingRules comes from your r444628).

I asked chromium-mojo at https://groups.google.com/a/chromium.org/d/topic/chromium-mojo/xxbQOT6CL4I/discussion

Based on the mailing list discussions, I don't think it is a regression.

I'll assign the bug to me, but I don't work on Mojo per se any more, so I don't expect to work on this Priority-3 bug any time soon. Anyone else (perhaps from site-isolation-dev) is free to take it.

While it is not strictly a regression, it is in the sense that "it never worked before" for OOPIFs. However, we want to ensure all code is OOPIF compatible as we have shipped OOPIFs to users for a while now and are increasing the usage consistently with time. 

I would like to raise the priority on this work if possible, so please let us know what timeframe we can expect this to be completed.

I spent some time looking at this and it is actually pretty bad. It looks like content settings don't apply to OOPIFs. The repro I got is running Canary with --site-per-process and a few pages from different sites I put together:

Page that includes cross-site frame executing JS: http://tests.netsekure.org/iframes/cross_site_frame_with_js.html
The page being iframed that executes JS: https://web.evilbit.io/javascript.html
Same site page including the JS executing page: https://web.evilbit.io/same_site_frame_js.html
The origin I've disabled JS execution for: https://web.evilbit.io

The result is that if I navigate to https://web.evilbit.io/same_site_frame_js.html, it works as expected - javascript does not execute and the document appears blank. The two iframes are in the same process.

If I navigate to http://tests.netsekure.org/iframes/cross_site_frame_with_js.html, the subframe document has "JS produced output" string, which is the result of JS setting innerText on a div on the page. This means that the content settings disallowing JS execution are not applied.

This needs to be addressed as soon as we can, so raising the priority to P1. I'm not sure who the best person is to handle it, so feel free to reassign.

Labelling this one as security bug, as it can potentially violate security restrictions put in place through content settings by users and/or extensions.

Nasko, I've tried your repro in http://tests.netsekure.org/iframes/cross_site_frame_with_js.html (with JS execution disabled for https://web.evilbit.io in content settings) and it seems to also work without --site-per-process.  Is this a more general issue with content settings relying on the top frame's origin in this case?

Thanks for checking alexmos@! It could be that I don't understand how content settings are designed to work, but as a user it was somewhat surprising to disable JS for the origin and for it to continue working in a subframe.

I'd leave it to the owners of content settings to chime in about what the expected behavior is.

These type of content settings should apply to the entire frame tree. e.g. if I disable JS or plugins for example.com, they should apply to example.com and all iframes it embeds (cross-origin or otherwise), but not apply when example.com is embedded elsewhere. From testing on Canary that seems to be the behavior when --site-per-process is enabled.

Extensions and policy can set "secondary patterns" which allow users to disable embedded scripts for particular origins. I haven't tested if that continues to work, but there's nothing to suggest that it wouldn't. The code that enforces this behavior is in content_settings_observer.cc.

The other thing to note is that TabSpecificContentSettings is mainly about UI and not behavior of content settings.

So I think this is WontFix.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot