On Tue, Jun 16, 2015 at 9:24 PM, Bobby Holley <[email protected]> wrote: > On Tue, Jun 16, 2015 at 11:45 AM, Paul Rouget <[email protected]> wrote: >> >> You mentioned XSS. If I understand what you're saying, introducing >> `executeScript` allows anything that has access to the Browser API to >> inject code to any web pages. That's exactly what it is designed for. >> The Browser API already allows plenty of things. And when you have >> access to the Browser API, you most certainly have access to other >> critical APIs (bluetooth, file system, …). So I was under the >> assumption that, at this point, we already gave a lot of permissions, >> and adding a way to run arbitrary scripts is just one more of these >> super power. But maybe this is a step too far. > > > This is the root of the question yes, which I can't answer - it needs > answering from people like Jonas and Paul T on the b2g side, as well as > yourself from the browser.html side - is the goal just to switch Firefox > from XUL to HTML, or to be able to run your browser in your browser?
The goal is to build a browser in HTML. Not to run a browser in current Firefox Desktop or in Chrome. I asked Paul to sec-review the current patch. >> Xrays. Is the problem that the script that is injected can be fooled? >> I don't know yet if we want Xrays or not. Naively, I would say yes. >> >> But maybe we want the script to be "fool-able". That could be an >> option in the executeScript method. But anyway, what is returned by >> the script (a JSON object) is obviously not something that should be >> trusted. It comes from the content. If wantXrays=true doesn't work >> with the principal of the content, I think it's ok. > > > Xrays aren't in a spec and probably never will be. They're required if you > want to interact synchronously with untrusted code, but not strictly > necessary if you only want to use message passing (which is the right design > choice, I think). If you treat all responses as untrusted, it's just a > question of making your in-content code robust against all the millions of > ways that content can pollute the global environment - i.e. a functionality > problem rather than a security problem. > >> >> You mentioned that this is like UniversalXPConnect. I don't understand >> that. It's just one more API on top of many others. > > > AFAIK, we don't have another API that allows arbitrary XSS from > non-System-Principaled code. That's exactly what UniversalXPConnect does > (turns off origin checks), and effectively what your proposal does. > >> >> Like we have >> `drawWindow` accessible as with chrome privileges > > > Right, because the caller has system principal. > >> >> we also have >> `getScreenshot()` from the Browser API. > > > If that works the way it sounds, it does seem like a step in that direction. > >> >> It sounds like what you're saying about "is it still the web" applies >> to almost all the APIs we have in B2G. I don't see what's special >> about executeScript that makes it less web than all the other things >> we build for Gaia. > > > This API is fundamentally more powerful - it explicitly lets the page > impersonate the user for any website in the world. That's pretty much the > same catch-call as UniversalXPConnect / System Principal, and something that > we may (or may not) want to avoid. -- Paul _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
