James Ross wrote:
- Tabs, and the browser view, are (of course) untrusted.
If the issue is that extensions want to open trusted tabs, then we should consider fixing that issue... I see no reason for the "of course" here.
One issue you don't mention but which has been talked about in the past is that loading trusted content in an untrusted window has some inherent insecurities; there's been some push to simply disallow that (strip privileges from trusted content loaded in an untrusted window).
I have been lead to believe that code loaded 'for' a window automatically has access to its 'owner'
That's correct; this is actually meant as a performance optimization, but in this case unfortunately affects the behavior. :( Again, the solution, imo, is to make sure that chrome code is only loaded in a ChromeWindow.
- The protect code should not be protected, as it is already in an untrusted place. (Of course, not protecting it and at the same time giving it chrome permissions isn't... so nice.)
Right. Hence the proposal to strip its chrome permissions...
- The protected code should be allowed access to the sub-content because it is a child of the code's "own" window and is flagged trusted in that window.
Unfortunately, there is no concept of "trusted in that window". :(
Would it make sense to have a "trust tree" kinda thing, where the page in the tab can properly trust itself and its sub-content, but have neither trusted by the browser?
Possibly, but I still think it would be easier to just always load chrome code in trusted windows and strip privileges when it's loaded in untrusted ones.
-Boris _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
