Re: Browser API: iframe.executeScript()
On 16 June 2015 at 16:24, Paul Rouget p...@mozilla.com wrote: In bug 1174733, I'm proposing a patch to implement the equivalent of Google's webview.executeScript: https://developer.chrome.com/apps/tags/webview#method-executeScript This will be useful to any consumer of the Browser API to access and manipulate the content. In 2011 when we started talking about how to build a web browser using web technologies for B2G we discussed two options: 1. Provide the ability to inject scripts into cross-origin iframes with access to the whole document 2. Build an explicit DOM API which just pokes the holes needed in the cross-origin boundary to access the information needed to build a browser, and nothing more What you're talking about is the first option. We chose the second option because we wanted to build a relatively safe API which could be used to build third party browser apps (and other webview type use cases). I've written about this in some length in this blog post https://hacks.mozilla.org/2014/08/building-the-firefox-browser-for-firefox-os/ The Browser API we have today is accessible to privileged apps, there are currently 13 apps in the Firefox Marketplace using the Browser API. Those apps can do basic things like frame a cross-origin web page with X-Frame-Options headers, navigate it and know when its location, title, icon etc. change, but they can't read or modify the content of all the web pages you visit and read your credit card details etc. The most privileged thing the Browser API provides is getScreenshot(), which I have argued should be a separate API only available to certified apps for this very reason. The existing iframe mozbrowser element is very similar to Google's webview element in Chrome OS and Microsoft's x-ms-webview element in Windows. I still hold out hope that one day we might be able to standardise this as a new webview HTML element http://benfrancis.github.io/webview/ - what's missing is a standards-based security model fit for the purpose of exposing this API to web content (as is the issue with many of our other APIs). It seems taking the script injection approach is a fundamentally different approach to the current Browser API and would essentially give the embedding document chrome privileges over the embedded document and remove the cross-origin boundary entirely. This is a valid approach, but would essentially make the Browser API redundant and there would be no point in ever trying to standardise it. I'm not saying that you shouldn't take this approach, it would certainly make some of the new use cases we have around Linked Data easier because we could just walk the DOM of any web page the user visits. But I want to make it clear that this is not just an addition to the Browser API, it's a replacement for it. My preference would be to keep the current approach and extend it where needed for browser.html rather than taking this shortcut, but I am probably biased. I know Jonas thinks there's little prospect of standardising this API any time soon. Please keep me in the loop in this discussion because it has huge implications for the work me and my team do. In particular, let's talk about what data browser.html needs access to to build its tab previews because it sounds very similar to our use cases of extracted Linked Data from a page. Thanks Ben ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Browser API: iframe.executeScript()
On Wed, Jun 17, 2015 at 2:06 PM, Benjamin Francis bfran...@mozilla.com wrote: On 16 June 2015 at 16:24, Paul Rouget p...@mozilla.com wrote: In bug 1174733, I'm proposing a patch to implement the equivalent of Google's webview.executeScript: https://developer.chrome.com/apps/tags/webview#method-executeScript This will be useful to any consumer of the Browser API to access and manipulate the content. In 2011 when we started talking about how to build a web browser using web technologies for B2G we discussed two options: 1. Provide the ability to inject scripts into cross-origin iframes with access to the whole document 2. Build an explicit DOM API which just pokes the holes needed in the cross-origin boundary to access the information needed to build a browser, and nothing more What you're talking about is the first option. We chose the second option because we wanted to build a relatively safe API which could be used to build third party browser apps (and other webview type use cases). I've written about this in some length in this blog post https://hacks.mozilla.org/2014/08/building-the-firefox-browser-for-firefox-os/ The Browser API we have today is accessible to privileged apps, there are currently 13 apps in the Firefox Marketplace using the Browser API. Those apps can do basic things like frame a cross-origin web page with X-Frame-Options headers, navigate it and know when its location, title, icon etc. change, but they can't read or modify the content of all the web pages you visit and read your credit card details etc. The most privileged thing the Browser API provides is getScreenshot(), which I have argued should be a separate API only available to certified apps for this very reason. I'm introducing a new permission for executeScript. The existing iframe mozbrowser element is very similar to Google's webview element in Chrome OS and Microsoft's x-ms-webview element in Windows. I still hold out hope that one day we might be able to standardise this as a new webview HTML element http://benfrancis.github.io/webview/ - what's missing is a standards-based security model fit for the purpose of exposing this API to web content (as is the issue with many of our other APIs). It seems taking the script injection approach is a fundamentally different approach to the current Browser API and would essentially give the embedding document chrome privileges over the embedded document and remove the cross-origin boundary entirely. This is a valid approach, but would essentially make the Browser API redundant and there would be no point in ever trying to standardise it. I'm not saying that you shouldn't take this approach, it would certainly make some of the new use cases we have around Linked Data easier because we could just walk the DOM of any web page the user visits. But I want to make it clear that this is not just an addition to the Browser API, it's a replacement for it. My preference would be to keep the current approach and extend it where needed for browser.html rather than taking this shortcut, but I am probably biased. I know Jonas thinks there's little prospect of standardising this API any time soon. Please keep me in the loop in this discussion because it has huge implications for the work me and my team do. In particular, let's talk about what data browser.html needs access to to build its tab previews because it sounds very similar to our use cases of extracted Linked Data from a page. Well, that the thing. what data browser.html needs access to to build its tab previews is not a thing we want to set in stone. We want to be able to change that as often as we want without tweaking platform's code all the time. Extending the API every time we want to do something that goes beyond the API capabilities is painful and slow. The executeScript approach makes our life a lot easier and gives us a lot more flexibility. -- Paul ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Browser API: iframe.executeScript()
How about the risk of having API users intentionally creating local APIs? For example, people can implement support for meta apple-touch-icon just in Gaia. I was told this is a concern back in B2G v1.0. On Wed, Jun 17, 2015 at 5:52 AM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Jun 16, 2015 at 10:33 AM, Bobby Holley bobbyhol...@gmail.com wrote: On Tue, Jun 16, 2015 at 10:06 AM, Paul Rouget p...@mozilla.com wrote: What would be the right approach to allow such a feature? Would adding a new permission help? Well, it sorta depends on what you're trying to accomplish. browser.html is supposed to be creating a web browser using only the web, right? I really hope we're *not* trying to accomplish that. It will probably never be possible to implement a web browser using just web technologies. A web browser needs the ability to do things like clearing cookies for arbitrary domains, rendering websites that doesn't want to be iframed, and grant/deny websites the ability to use geolocation. We don't want arbitrary websites to be able to do those things. / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Browser API: iframe.executeScript()
On Wed, Jun 17, 2015 at 12:02 AM, Tim Guan-tin Chien
timdr...@mozilla.com wrote:
How about the risk of having API users intentionally creating local
APIs? For example, people can implement support for meta
apple-touch-icon just in Gaia.
I was told this is a concern back in B2G v1.0.
I think that's fine. It's definitely something we should discourage
partners, or browser app developers, from to all of the web. But I
don't think we have many browser apps, and partners will soon be able
to do using addons, so I don't see this as a reason to disallow it on
the Browser API.
If I said otherwise back then, then I was wrong and I'm sorry.
However it might be a good idea to add some security features to the
API. I.e. something like:
browserAPI.executeScript(script, { origin: http://a.com; });
and
browserAPI.executeScript(script, { url: http://a.com/b.html; });
which would only execute the script if the url/origin match.
/ Jonas
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Browser API: iframe.executeScript()
On 16.06.2015 21:41, Paul Rouget wrote: On Tue, Jun 16, 2015 at 9:33 PM, Bobby Holley bobbyhol...@gmail.com wrote: On Tue, Jun 16, 2015 at 12:28 PM, Paul Rouget p...@mozilla.com wrote: The goal is to build a browser in HTML. Not to run a browser in current Firefox Desktop or in Chrome. Ok. Are you also aiming to remove the dependency on XPCOM (i.e. Components)? In that case it seems reasonable to swap out the System Principal for a privilege called UniversalXSS - just make sure it's clear that that's what it does. ;-) I will add a special permission called universalxss. I'll ask you, Paul and Jonas to look at the patch. For the sake of completeness, what's the bug id? Also, the eval API should almost certainly be asynchronous, right? Current patch is asynchronous. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Browser API: iframe.executeScript()
On 17 June 2015 at 13:29, Paul Rouget p...@mozilla.com wrote: Extending the API every time we want to do something that goes beyond the API capabilities is painful and slow. Yes I'm acutely aware of this, having done it for the last three and half years :) The executeScript approach makes our life a lot easier and gives us a lot more flexibility. I agree. But I also think it makes browser.html more like chrome privileged code than web content. I'm not saying that's the wrong approach, it's just a different approach to the Browser API. The goal of the Browser API was to enable you to build a browser as web content. I guess what I'm saying is that I don't really think an executeScript() API has much to do with the Browser API, it's a parallel solution to the same sorts of problems. I suppose it comes down to the same debate as if none of our privileged APIs get standardised, is privileged/certified content just a new type of chrome?. I'd still be interested to learn more about your use cases. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Browser API: iframe.executeScript()
On Wed, Jun 17, 2015 at 4:41 PM, Benjamin Francis bfran...@mozilla.com wrote: On 17 June 2015 at 13:29, Paul Rouget p...@mozilla.com wrote: Extending the API every time we want to do something that goes beyond the API capabilities is painful and slow. Yes I'm acutely aware of this, having done it for the last three and half years :) The executeScript approach makes our life a lot easier and gives us a lot more flexibility. I agree. But I also think it makes browser.html more like chrome privileged code than web content. I'm not saying that's the wrong approach, it's just a different approach to the Browser API. The goal of the Browser API was to enable you to build a browser as web content. I guess what I'm saying is that I don't really think an executeScript() API has much to do with the Browser API, it's a parallel solution to the same sorts of problems. I suppose it comes down to the same debate as if none of our privileged APIs get standardised, is privileged/certified content just a new type of chrome?. I'd still be interested to learn more about your use cases. - access the computed style of the body to update the theme of the browser - walk through the DOM to get data to build a preview of the tab - access any metadata (today the list is limited) - find the largest image of the page for a tab card - … But mostly, being able to do more with the browser api without requiring an update of gecko. -- Paul ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Browser API: iframe.executeScript()
On 17 June 2015 at 15:57, Paul Rouget p...@mozilla.com wrote: - access the computed style of the body to update the theme of the browser By theme do you mean like a kind of automatic theme-color? You probably know the b2g browser currently just uses the metachange event to get theme-color meta tags for this, and falls back to a default. - walk through the DOM to get data to build a preview of the tab - access any metadata (today the list is limited) - find the largest image of the page for a tab card This all sounds like it might be similar to the cards we're creating to represent pages in Pinning the Web https://wiki.mozilla.org/FirefoxOS/Pinning_the_Web - we're planning on using Linked Data to get the key metadata we need for this - like title, description, image and other more specialised data for various content types (we have a working prototype). We fallback to a default card composed from a screenshot, theme-color and the document title. But mostly, being able to do more with the browser api without requiring an update of gecko. That's just cheating ;) Ben ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Browser API: iframe.executeScript()
On Tue, Jun 16, 2015 at 2:48 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Jun 16, 2015 at 9:08 AM, Bobby Holley bobbyhol...@gmail.com wrote: Do privileged and certified apps currently have the ability to perform universal XSS? Because this would give them that, certainly. The Browser API runs content in a separate cookie jar. That means that the browser API from a security point of view is no more capable than systemXHR. I.e. it's even less capable than cross-site XHR since it doesn't use the user's normal cookies. I.e. the Browser API is just a systemXHR API plus a really good implementation of a web rendering engine in JS. That effectively means that this is not universal XSS. The browser API can only be used to XSS things that it itself has rendered. But that says nothing about multiple consumers of the browser API, right? The origin information gives us one bit that tells us whether we're in a browser element or not. The Browser App uses mozbrowser, and that's where users enter all their sensitive data. With the proposed API, this sensitive data would be vulnerable to XSS from any other app using the browser API. At least on FFOS, it seems like the most useful cookies are inside, rather than outside, the browser cookie jar. One way to solve this would be to switch the inBrowser OriginAttribute from a boolean to a nested origin. That could have other complicating implications though. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Browser API: iframe.executeScript()
To anything that has access to the browser API. So I guess that
includes privileged and certified apps.
On Tue, Jun 16, 2015 at 5:44 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
What contexts are you planning to expose this to? Certified apps?
On 2015-06-16 11:24 AM, Paul Rouget wrote:
In bug 1174733, I'm proposing a patch to implement the equivalent of
Google's webview.executeScript:
https://developer.chrome.com/apps/tags/webview#method-executeScript
This will be useful to any consumer of the Browser API to access and
manipulate the content.
For some context: the browser.html project needs access to the DOM to
build some sort of tab previews (not a screenshot, something based on
colors, headers and images from the page), and we don't feel like
adding more and more methods to the Browser API to collect all the
information we need. It's just easier to be able to inject a script
and tune the preview algorithm in the system app instead of changing
the API all the time we need a new thing. It also doesn't sound like a
terrible thing to do as other vendors do a similar thing (Android's
executeScript, iOS's stringByEvaluatingJavaScriptFromString, and IE's
InvokeScript).
The API is pretty straight forward:
let foo = 42;
iframe.executeScript(`
new Promise((resolve, reject) = {
setTimeout(() = resolve({foo: ${foo + 1}}), 2000);
})
`).then(rv = {
console.log(rv);
}, error = {
console.error(error);
});
Any reason to not do that?
Any security concerns?
Or is there a better way to do that (like a worker)?
-- Paul
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
--
Paul
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Browser API: iframe.executeScript()
You mean, being able to inject any script into the content?
Afaik, there's no way to do that. That's exactly why we need this API.
Do we want to keep the barrier between the browser and the content?
If so, why?
On Tue, Jun 16, 2015 at 6:08 PM, Bobby Holley bobbyhol...@gmail.com wrote:
Do privileged and certified apps currently have the ability to perform
universal XSS? Because this would give them that, certainly.
On Tue, Jun 16, 2015 at 8:57 AM, Paul Rouget p...@mozilla.com wrote:
To anything that has access to the browser API. So I guess that
includes privileged and certified apps.
On Tue, Jun 16, 2015 at 5:44 PM, Ehsan Akhgari ehsan.akhg...@gmail.com
wrote:
What contexts are you planning to expose this to? Certified apps?
On 2015-06-16 11:24 AM, Paul Rouget wrote:
In bug 1174733, I'm proposing a patch to implement the equivalent of
Google's webview.executeScript:
https://developer.chrome.com/apps/tags/webview#method-executeScript
This will be useful to any consumer of the Browser API to access and
manipulate the content.
For some context: the browser.html project needs access to the DOM to
build some sort of tab previews (not a screenshot, something based on
colors, headers and images from the page), and we don't feel like
adding more and more methods to the Browser API to collect all the
information we need. It's just easier to be able to inject a script
and tune the preview algorithm in the system app instead of changing
the API all the time we need a new thing. It also doesn't sound like a
terrible thing to do as other vendors do a similar thing (Android's
executeScript, iOS's stringByEvaluatingJavaScriptFromString, and IE's
InvokeScript).
The API is pretty straight forward:
let foo = 42;
iframe.executeScript(`
new Promise((resolve, reject) = {
setTimeout(() = resolve({foo: ${foo + 1}}), 2000);
})
`).then(rv = {
console.log(rv);
}, error = {
console.error(error);
});
Any reason to not do that?
Any security concerns?
Or is there a better way to do that (like a worker)?
-- Paul
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
--
Paul
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
--
Paul
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Browser API: iframe.executeScript()
On Tue, Jun 16, 2015 at 9:20 AM, Paul Rouget p...@mozilla.com wrote: You mean, being able to inject any script into the content? Afaik, there's no way to do that. That's exactly why we need this API. Do we want to keep the barrier between the browser and the content? If so, why? Well, presumably because we might not want the browser app to be able to XSS every website ever? Maybe we're ok with that, but it's tantamount to running the browser app with system principal, which is something that we currently don't do, so presumably the b2g security people have a thing or two to say about it. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Browser API: iframe.executeScript()
In bug 1174733, I'm proposing a patch to implement the equivalent of
Google's webview.executeScript:
https://developer.chrome.com/apps/tags/webview#method-executeScript
This will be useful to any consumer of the Browser API to access and
manipulate the content.
For some context: the browser.html project needs access to the DOM to
build some sort of tab previews (not a screenshot, something based on
colors, headers and images from the page), and we don't feel like
adding more and more methods to the Browser API to collect all the
information we need. It's just easier to be able to inject a script
and tune the preview algorithm in the system app instead of changing
the API all the time we need a new thing. It also doesn't sound like a
terrible thing to do as other vendors do a similar thing (Android's
executeScript, iOS's stringByEvaluatingJavaScriptFromString, and IE's
InvokeScript).
The API is pretty straight forward:
let foo = 42;
iframe.executeScript(`
new Promise((resolve, reject) = {
setTimeout(() = resolve({foo: ${foo + 1}}), 2000);
})
`).then(rv = {
console.log(rv);
}, error = {
console.error(error);
});
Any reason to not do that?
Any security concerns?
Or is there a better way to do that (like a worker)?
-- Paul
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Browser API: iframe.executeScript()
Do privileged and certified apps currently have the ability to perform
universal XSS? Because this would give them that, certainly.
On Tue, Jun 16, 2015 at 8:57 AM, Paul Rouget p...@mozilla.com wrote:
To anything that has access to the browser API. So I guess that
includes privileged and certified apps.
On Tue, Jun 16, 2015 at 5:44 PM, Ehsan Akhgari ehsan.akhg...@gmail.com
wrote:
What contexts are you planning to expose this to? Certified apps?
On 2015-06-16 11:24 AM, Paul Rouget wrote:
In bug 1174733, I'm proposing a patch to implement the equivalent of
Google's webview.executeScript:
https://developer.chrome.com/apps/tags/webview#method-executeScript
This will be useful to any consumer of the Browser API to access and
manipulate the content.
For some context: the browser.html project needs access to the DOM to
build some sort of tab previews (not a screenshot, something based on
colors, headers and images from the page), and we don't feel like
adding more and more methods to the Browser API to collect all the
information we need. It's just easier to be able to inject a script
and tune the preview algorithm in the system app instead of changing
the API all the time we need a new thing. It also doesn't sound like a
terrible thing to do as other vendors do a similar thing (Android's
executeScript, iOS's stringByEvaluatingJavaScriptFromString, and IE's
InvokeScript).
The API is pretty straight forward:
let foo = 42;
iframe.executeScript(`
new Promise((resolve, reject) = {
setTimeout(() = resolve({foo: ${foo + 1}}), 2000);
})
`).then(rv = {
console.log(rv);
}, error = {
console.error(error);
});
Any reason to not do that?
Any security concerns?
Or is there a better way to do that (like a worker)?
-- Paul
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
--
Paul
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Browser API: iframe.executeScript()
What would be the right approach to allow such a feature? Would adding a new permission help? On Tue, Jun 16, 2015 at 6:32 PM, Bobby Holley bobbyhol...@gmail.com wrote: On Tue, Jun 16, 2015 at 9:20 AM, Paul Rouget p...@mozilla.com wrote: You mean, being able to inject any script into the content? Afaik, there's no way to do that. That's exactly why we need this API. Do we want to keep the barrier between the browser and the content? If so, why? Well, presumably because we might not want the browser app to be able to XSS every website ever? Maybe we're ok with that, but it's tantamount to running the browser app with system principal, which is something that we currently don't do, so presumably the b2g security people have a thing or two to say about it. -- Paul ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Browser API: iframe.executeScript()
On Tue, Jun 16, 2015 at 7:50 PM, Bobby Holley bobbyhol...@gmail.com wrote:
On Tue, Jun 16, 2015 at 10:38 AM, Paul Rouget p...@mozilla.com wrote:
I don't how this work (Xray vision).
Given what you're doing, it's definitely worth learning about. A basic
overview is here: https://developer.mozilla.org/en-US/docs/Xray_vision
For more detail and a bigger-picture view of why this is a tricky problem,
I'd recommend watching the talk I gave in Portland:
https://air.mozilla.org/safe-by-default/ . Currently accessible for vouched
mozillians, but we should get rid of that soon.
Code, in the child process, is executed this way:
+let sandbox = new Cu.Sandbox(content, {
+ sandboxPrototype: content,
+ wantXrays: false,
+ sandboxName: browser-api-execute-script
+});
+
+let sandboxRv = Cu.evalInSandbox(script, sandbox, 1.8);
I use `wantXrays: false`, but I don't know what we really want here.
wantXrays is a deprecated option - it doesn't actually help you unless you
run with sandbox with an Expanded Principal ([content] instead of content),
which begs the whole web platform not supporting asymmetric privilege
relationships question.
This is a pretty complicated topic, and requires a fair amount of background
to discuss meaningfully, unfortunately. The links above should help a lot.
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.
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.
You mentioned that this is like UniversalXPConnect. I don't understand
that. It's just one more API on top of many others. Like we have
`drawWindow` accessible as with chrome privileges, we also have
`getScreenshot()` from the Browser API.
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. Or maybe I'm misunderstanding something.
--
Paul
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Browser API: iframe.executeScript()
On Tue, Jun 16, 2015 at 10:21 AM, smaug sm...@welho.com wrote: What is the context where the scripts would run? In the page or something more like a TabChildGlobal (the child side of a message manager) but without chrome privileges? This is also worth emphasizing - without Xray Vision (which you can't have without an elevated principal), you basically have no guarantees that your code does what you expect. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Browser API: iframe.executeScript()
On Tue, Jun 16, 2015 at 10:06 AM, Paul Rouget p...@mozilla.com wrote: What would be the right approach to allow such a feature? Would adding a new permission help? Well, it sorta depends on what you're trying to accomplish. browser.html is supposed to be creating a web browser using only the web, right? If we add a privilege that more or less equates to the UniversalXPConnect of days past, is that really the web anymore? Why not just run with System Principal like Firefox does? Again, maybe we're fine with this, and maybe the B2G system app already has permissions like this (I don't know much about it - hopefully people who know more can chime in). But that's the crux of the issue we need to answer, IMO. AFAICT, the webview APIs you're comparing with are embedding APIs, and aren't ever intended to be exposed to the web. bholley ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Browser API: iframe.executeScript()
What is the context where the scripts would run? In the page or something more
like a TabChildGlobal (the child side of a message manager)
but without chrome privileges?
On 06/16/2015 06:24 PM, Paul Rouget wrote:
In bug 1174733, I'm proposing a patch to implement the equivalent of
Google's webview.executeScript:
https://developer.chrome.com/apps/tags/webview#method-executeScript
This will be useful to any consumer of the Browser API to access and
manipulate the content.
For some context: the browser.html project needs access to the DOM to
build some sort of tab previews (not a screenshot, something based on
colors, headers and images from the page), and we don't feel like
adding more and more methods to the Browser API to collect all the
information we need. It's just easier to be able to inject a script
and tune the preview algorithm in the system app instead of changing
the API all the time we need a new thing. It also doesn't sound like a
terrible thing to do as other vendors do a similar thing (Android's
executeScript, iOS's stringByEvaluatingJavaScriptFromString, and IE's
InvokeScript).
The API is pretty straight forward:
let foo = 42;
iframe.executeScript(`
new Promise((resolve, reject) = {
setTimeout(() = resolve({foo: ${foo + 1}}), 2000);
})
`).then(rv = {
console.log(rv);
}, error = {
console.error(error);
});
Any reason to not do that?
Any security concerns?
Or is there a better way to do that (like a worker)?
-- Paul
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Browser API: iframe.executeScript()
On Tue, Jun 16, 2015 at 10:38 AM, Paul Rouget p...@mozilla.com wrote:
I don't how this work (Xray vision).
Given what you're doing, it's definitely worth learning about. A basic
overview is here: https://developer.mozilla.org/en-US/docs/Xray_vision
For more detail and a bigger-picture view of why this is a tricky problem,
I'd recommend watching the talk I gave in Portland:
https://air.mozilla.org/safe-by-default/ . Currently accessible for vouched
mozillians, but we should get rid of that soon.
Code, in the child process, is executed this way:
+let sandbox = new Cu.Sandbox(content, {
+ sandboxPrototype: content,
+ wantXrays: false,
+ sandboxName: browser-api-execute-script
+});
+
+let sandboxRv = Cu.evalInSandbox(script, sandbox, 1.8);
I use `wantXrays: false`, but I don't know what we really want here.
wantXrays is a deprecated option - it doesn't actually help you unless you
run with sandbox with an Expanded Principal ([content] instead of content),
which begs the whole web platform not supporting asymmetric privilege
relationships question.
This is a pretty complicated topic, and requires a fair amount of
background to discuss meaningfully, unfortunately. The links above should
help a lot.
bholley
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Browser API: iframe.executeScript()
On Tue, Jun 16, 2015 at 10:33 AM, Bobby Holley bobbyhol...@gmail.com wrote: On Tue, Jun 16, 2015 at 10:06 AM, Paul Rouget p...@mozilla.com wrote: What would be the right approach to allow such a feature? Would adding a new permission help? Well, it sorta depends on what you're trying to accomplish. browser.html is supposed to be creating a web browser using only the web, right? I really hope we're *not* trying to accomplish that. It will probably never be possible to implement a web browser using just web technologies. A web browser needs the ability to do things like clearing cookies for arbitrary domains, rendering websites that doesn't want to be iframed, and grant/deny websites the ability to use geolocation. We don't want arbitrary websites to be able to do those things. / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Browser API: iframe.executeScript()
On Tue, Jun 16, 2015 at 9:08 AM, Bobby Holley bobbyhol...@gmail.com wrote: Do privileged and certified apps currently have the ability to perform universal XSS? Because this would give them that, certainly. The Browser API runs content in a separate cookie jar. That means that the browser API from a security point of view is no more capable than systemXHR. I.e. it's even less capable than cross-site XHR since it doesn't use the user's normal cookies. I.e. the Browser API is just a systemXHR API plus a really good implementation of a web rendering engine in JS. That effectively means that this is not universal XSS. The browser API can only be used to XSS things that it itself has rendered. / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Browser API: iframe.executeScript()
On Tue, Jun 16, 2015 at 9:33 PM, Bobby Holley bobbyhol...@gmail.com wrote: On Tue, Jun 16, 2015 at 12:28 PM, Paul Rouget p...@mozilla.com wrote: The goal is to build a browser in HTML. Not to run a browser in current Firefox Desktop or in Chrome. Ok. Are you also aiming to remove the dependency on XPCOM (i.e. Components)? In that case it seems reasonable to swap out the System Principal for a privilege called UniversalXSS - just make sure it's clear that that's what it does. ;-) I will add a special permission called universalxss. I'll ask you, Paul and Jonas to look at the patch. Also, the eval API should almost certainly be asynchronous, right? Current patch is asynchronous. -- Paul ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Browser API: iframe.executeScript()
On Tue, Jun 16, 2015 at 9:24 PM, Bobby Holley bobbyhol...@gmail.com wrote: On Tue, Jun 16, 2015 at 11:45 AM, Paul Rouget p...@mozilla.com 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 dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Browser API: iframe.executeScript()
I may be wrong, but isn't it possible to implement the same thing by injecting a `postMessage()`-based piece of code in the source code of the page during load? I'm doing just that in my HTML5 ebook reader. It's pretty annoying, because this is pre-ServiceWorker code, but I suspect that this can be done more easily with a ServiceWorker. Cheers, David On 16/06/15 17:24, Paul Rouget wrote: In bug 1174733, I'm proposing a patch to implement the equivalent of Google's webview.executeScript: https://developer.chrome.com/apps/tags/webview#method-executeScript This will be useful to any consumer of the Browser API to access and manipulate the content. For some context: the browser.html project needs access to the DOM to build some sort of tab previews (not a screenshot, something based on colors, headers and images from the page), and we don't feel like adding more and more methods to the Browser API to collect all the information we need. It's just easier to be able to inject a script and tune the preview algorithm in the system app instead of changing the API all the time we need a new thing. It also doesn't sound like a terrible thing to do as other vendors do a similar thing (Android's executeScript, iOS's stringByEvaluatingJavaScriptFromString, and IE's InvokeScript). -- David Rajchenbach-Teller, PhD Performance Team, Mozilla signature.asc Description: OpenPGP digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Browser API: iframe.executeScript()
On Tue, Jun 16, 2015 at 12:28 PM, Paul Rouget p...@mozilla.com wrote: The goal is to build a browser in HTML. Not to run a browser in current Firefox Desktop or in Chrome. Ok. Are you also aiming to remove the dependency on XPCOM (i.e. Components)? In that case it seems reasonable to swap out the System Principal for a privilege called UniversalXSS - just make sure it's clear that that's what it does. ;-) Also, the eval API should almost certainly be asynchronous, right? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Browser API: iframe.executeScript()
On Tue, Jun 16, 2015 at 11:45 AM, Paul Rouget p...@mozilla.com 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? 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. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Browser API: iframe.executeScript()
On Tue, Jun 16, 2015 at 9:13 PM, Andrew Sutherland asutherl...@asutherland.org wrote: On Tue, Jun 16, 2015, at 02:45 PM, Paul Rouget 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, …). The other critical APIs are explicitly requested separately. It seems like it's worth making this one a separate privilege too. Or we run into the Android problem of I need this permission for this reasonable thing, but it also grants me access to do all these sketchy things, so what are you gonna do? Currently the browser API may be used for OAuth2 dance purposes for a variety of reasons. As we overhaul how we do webapps and per-app cookie jars and all that, the need for this may be removed, but right now the email app and the calendar app and probably others have the mozbrowser privilege. They do need this, but they absolutely do not need or want the ability to inject code into a google.com origin or other origins. Absolutely. I was suggesting that earlier, adding another permission. -- Paul ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
