Last Comment Bug 693515 - (browser-api) Browser API
(browser-api)
: Browser API
Status: NEW
:
Product: Core
Classification: Components
Component: DOM: Core & HTML (show other bugs)
: Trunk
: All All
: -- normal with 6 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
http://jlebar.github.com/transitively...
: 698821 (view as bug list)
Depends on: 738172 756376 767189 769183 769189 771584 776061 785111 792892 810431 825082 825882 837387 844390 848083 859149 862845 866242 876365 1033999 1043102 1046033 1097434 1105190 1110074 1125713 1126215 1166657 1169634 1173733 1183121 702880 704037 708176 708179 709759 710231 719459 719461 736688 740479 740481 741587 741717 741755 742944 745997 746502 748187 749374 753595 754997 757763 757859 759511 762802 762939 763694 764496 764707 766437 766481 766871 766873 768561 768842 768939 769178 769254 770239 770847 771273 771533 772076 772155 772452 773356 774809 775464 776116 776129 776132 777135 780174 780351 780546 781452 783644 784378 784562 785005 787378 787517 787519 789392 791261 793644 794108 794563 794597 795317 796055 796275 800170 802647 805746 806625 807056 810036 814583 816452 824677 828969 829486 846177 874900 878003 891763 902165 905573 987040 1034001 1044736 1085217 1097479 1105666 1163961 1169633 1170644 1174733
Blocks: webapi b2g-product-phone
  Show dependency treegraph
 
Reported: 2011-10-10 19:37 PDT by Chris Jones [:cjones] inactive; ni?/f?/r? if you need me
Modified: 2016-06-10 15:18 PDT (History)
48 users (show)
dveditz: sec‑review? (ptheriault)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2011-10-10 19:37:19 PDT
+++ This bug was initially created as a clone of Bug #692677 +++

In B2G, we have two scenarios currently in which this is needed
 - "home screen", that loads applications installed from different URIs
 - web browser UI, obviously needs to load arbitrary URLs

(The web browser needs some more things, but I'll file separate bugs for those.)

I think we could probably solve the web-browser case without needing an explicit grant of privilege.  If we had an element that was
 - like a XUL <browser> (i.e. ignored X-Frame-Options)
 - tied to an input box ("URL bar") that could only explicitly be navigated by the user
 - unlike <browser> or <iframe> couldn't be navigated programmatically (or could, but restricted to normal <iframe> security)

then I think we could build a UI around that.  We could call that new element <browser> since that's unused in HTML currently.  The biggest problems then would be implementing open-in-new-tab and window.open(), but I think those can be solved separately.

The "home screen" app launcher is a harder problem.  To enable window-manager style features like "expose" and other animations, the home screen needs references to the app "windows".  Further, it's always going to be launching apps programmatically, because it translates input like clicking on an icon into the app-launch action.  So hm.  I can't think of a way around an explicit permission grant for this.  If we need a grant for the home screen, we might as well use that for the web browser too.
Comment 1 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2011-10-10 19:46:48 PDT
I think trying to make the home screen untrusted is trying too hard.

I think making the browser UI untrusted is also trying too hard, although less so.
Comment 2 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2011-10-10 20:03:25 PDT
That's fine, I conceded that.

What should the API look like?  Adding a new HTML element seems like overkill.  In both cases what's really needed is just a way to ask that X-Frame-Options be ignored.  How about a new iframe attribute?  Strawman: <iframe crossOrigin>, with crossOrigin interpreted the same way as for <img>, but with an additional value: "system".  crossOrigin="system" would turn off x-frame-options, and would require a permission grant from the user.  That'd be a neat way to enable canvas.drawWindow() or texImage2D(window) too, which we might want to use for effects like WebGL transition animations.
Comment 3 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2011-10-10 20:18:48 PDT
Basically sounds right. I don't think you want crossorigin here, you'd be better off steering away from standard-ish stuff. <iframe mozBrowser>?
Comment 4 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2011-10-10 20:29:55 PDT
Why steer away from standard-ish stuff?  I would 100% want to standardize this.  Do you think that's not possible?
Comment 5 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2011-10-10 20:38:54 PDT
Well, I suppose it could make sense to standardize APIs for privileged applications, but like we've discussed before, I think those APIs should be very clearly separated from APIs for regular Web apps. So I wouldn't want to overload an existing attribute.
Comment 6 Jonas Sicking (:sicking) No longer reading bugmail consistently 2011-10-10 20:49:20 PDT
I think the meaning of crossorigin on <img> is very different from what we want here. On <img> it ensures that the contents of the <img> is accessible to you by using CORS to load the data.

What we want here is to not change how the load happens at all, but rather give a permission of the data after the load is done.

Another way to look at it is that <img crossorigin> still stays within the web's normal same-origin-but-relax-if-content-producer-explicitly-allows security model. What you want here is something that requires special privileges.


We'll need something more than just ignoring x-frame-options. For example window.top should not return the top-level B2G home screen or browser-app window, it should return the .contentWindow of the <iframe iamaspecialiframe>.

There's also some things related to what <a target> are allowed to target. But this is all pretty simple stuff I think. We should have most of the plumbing in Gecko already.


And yes, unfortunately I can't think of anything that doesn't require permission granting either. Things like click-jacking means that simply embedding another website and ignoring x-frame-options comes with some risks to the user. So an explicit grant will be needed.

And to implement browsers we'll absolutely need to be able to reach in to the frame and dig out data.


For implementing browsers, do we need some way to enable a process boundary at the new <iframe>? It definitely seems like the home screen will need that, right?
Comment 7 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2011-10-10 21:03:01 PDT
I assume that when you talk about "permission grant" what you mean is "whitelisted application", not something that actually requires user interaction.
Comment 8 Jonas Sicking (:sicking) No longer reading bugmail consistently 2011-10-10 21:32:58 PDT
Yes, this seems hard to ask the user about since the security issues are so subtle.
Comment 9 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2011-10-10 22:03:12 PDT
(In reply to Jonas Sicking (:sicking) from comment #6)
> And to implement browsers we'll absolutely need to be able to reach in to
> the frame and dig out data.
> 

Maybe, maybe not.  I'm not sure yet.  I'm operating under the assumption that we mostly won't.  I'm hoping we can rely on gecko to do things like find-in-page, but it's a bit harder on touch screens since the find isn't initiated by a keyboard.

> 
> For implementing browsers, do we need some way to enable a process boundary
> at the new <iframe>? It definitely seems like the home screen will need
> that, right?

I'm happy to let gecko make that decision; the iamaspecialiframe property could be used as a hint.  This does bear on the "reach into the frame" problem though.  It's not going to be possible to do that across processes.  Another thing we'll need is some kind of "this page is really important and has to have low latency", e.g. for a dialer, which would be a hint to gecko to load that app in a new process.  Need to make sure the critical apps can't be DoS'd.
Comment 10 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2011-10-10 22:05:13 PDT
It would make me sad for this to be whitelist only.  That would pretty much kill competition around browser UIs, since in practice the user would only be able to use the one that shipped on the device.  I'm less OK with whitelisting this permission than I am for something like telephony.
Comment 11 Jonas Sicking (:sicking) No longer reading bugmail consistently 2011-10-10 22:18:58 PDT
I don't think we can make the process separation something that is left up to gecko as like you note, it affects whether you can reach into the iframe or not.

I'm pretty sure we'll definitely need for browsers to reach into pages. I'm fairly sure that the Firefox front-end does so in lots of places. Session restore being one, addons being another.

As for security, I don't mean "whitelist" in the sense of something static and only includes for example pre-installed apps. I also think we should allow this for apps that are installed from trusted stores, where the store has indicated that the app is entrusted with some special privileges. (additionally, users should be able to explicitly grant apps this, and any other, privilege. As to prevent the Apple one-store-to-rule-them-all model)
Comment 12 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2011-10-10 22:45:15 PDT
(In reply to Jonas Sicking (:sicking) from comment #11)
> I'm pretty sure we'll definitely need for browsers to reach into pages. I'm
> fairly sure that the Firefox front-end does so in lots of places. Session
> restore being one, addons being another.
> 

Huh ... what does session restore need from content?  Values of input fields?  The frontend needs to reach into content for the context menu; I'm not sure that's an issue for b2g.  Maybe it is.  Browser frontends wouldn't be able to create their own addon systems with power equivalent to classic firefox addons or jetpacks (that'd be a security nightmare anyway), but jetpack-style addons would work in b2g.

If we do need to reach into iframes, another option is for us to standardize a way of loading code into iframes and communicating with them, probably postMessage().  Something like message manager but maybe could be simpler.  That sounds like it would be really hard to spec and standardize though.
Comment 13 Jonas Sicking (:sicking) No longer reading bugmail consistently 2011-10-10 23:31:10 PDT
> Huh ... what does session restore need from content?  Values of input
> fields?

Form fields in general yeah. And scroll positions of anything scrollable.

> Browser frontends wouldn't
> be able to create their own addon systems with power equivalent to classic
> firefox addons or jetpacks (that'd be a security nightmare anyway), but
> jetpack-style addons would work in b2g.

jetpack addons can reach into page contents. And I believe that at this point all major browsers have greasemonkey-like functionality or addons.

> If we do need to reach into iframes, another option is for us to standardize
> a way of loading code into iframes and communicating with them, probably
> postMessage().  Something like message manager but maybe could be simpler. 
> That sounds like it would be really hard to spec and standardize though.

We'll need something to enable us to build firefox for B2G.
Comment 14 Ben Francis [:benfrancis] 2011-11-02 03:24:25 PDT
Ah, I think my bug report https://bugzilla.mozilla.org/show_bug.cgi?id=698821 is a bit of a duplicate of this one. I started working on a basic browser for Gaia/B2G and have some potential use cases for this.

Events that may be needed outside the iFrame:
* Load Start - When the iFrame starts loading a new document
* Progress monitor - to monitor the progress of the document being loaded inside the iFrame
* Load Stop - When the iFrame finishes loading a new document
* Title Change - When the title of an HTML document inside the iFrame changes

Other use cases might include:
* Get Title - Get the title of the current HTML document inside the iFrame
* Stop Load - Programatically stop the iFrame from loading a document
* Suppress XFrame-Options Header - Render the contents of a document inside the iFrame, even if it was returned with an X-Frame-Options DENY or SAMEORIGIN header. (e.g. web sites like GMail which return this header to prevent phishing scams will still be rendered inside this special iFrame).
* Get favicon URL - As this can be contained inside the HTML document itself
* Get thumbnail - Get a thumbnail image of the content of the iFrame, for use in graphical window manager/tab switching type features
* Zoom - Programatically Make the iFrame content larger or smaller

In order to enable alternative browser UIs, it would seem that these permissions need to be explicitly given to certain apps by the user. Maybe it could be phrased something along the lines of "Allow this app to look inside and control other apps and web sites you use."

Note previous similar work done on Mozilla Chromeless https://github.com/mozilla/chromeless/blob/master/modules/lib/web-content.js

If B2G is to promote the *web* as an app platform rather than just Mozilla, then it does seem this would need to be standardised eventually.
Comment 15 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2011-11-02 13:16:37 PDT
Jonas, Boris, Ben: what's the best way for us to settle on this API?  Should we schedule a quick chat?
Comment 16 Boris Zbarsky [:bz] 2011-11-02 14:56:02 PDT
I think that would be helpful for me, yes.  If nothing else so we can get all the issues and use cases written down clearly...
Comment 17 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2011-11-02 15:13:45 PDT
OK.  Tomorrow and Friday are not good for me, but if you guys can meet without me that's 100% fine.  Monday at 11 PST (1900 GMT) wfm.  We can take the proposal to the WebAPI meeting next Tuesday.
Comment 18 Jonas Sicking (:sicking) No longer reading bugmail consistently 2011-11-02 15:43:38 PDT
11 PST is the time for the all-hands meeting. Any other time works for me.
Comment 19 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2011-11-02 16:10:46 PDT
Oh duh.  Later than that on Monday is bad for GMT, and earlier is bad for me because I have interviews.  Maybe you guys can meet tomorrow or Friday?
Comment 20 Ben Francis [:benfrancis] 2011-11-02 16:35:22 PDT
If you're in PST and need me for chat then early in the morning is best for me as I'm GMT, just ping me in #b2g (benfrancis)
Comment 21 Ben Francis [:benfrancis] 2011-11-07 07:05:36 PST
*** Bug 698821 has been marked as a duplicate of this bug. ***
Comment 22 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2011-11-15 11:46:50 PST
The summary of the quick meeting was
 (1) we need a third docshell type with some of the properties of the chrome/content boundary (X-Frame-Options is ignored, window.top doesn't walk past it), except that privileged web content can create that type of docshell.

 (2) for prototyping the API we need to implement a browser, we'll have a semi-magical little wrapper script that lives in in the browser app and has access to a postMessage() port.  The other end of that port will live in a chrome-privileged magic script in the <iframe magicsauce>.  Frame script seems to be what we want here.  The frame script will forward all the data we need to the wrapper script.  When we settle on the necessary API, we'll move all this into Gecko.

We decided to punt the problem of the browser itself interacting with content, e.g. for something like session restore.  We'll look at this in a v2.

jlebar signed up for (1) and is going to file a bug blocking this one.
Comment 23 Tantek Çelik 2012-02-03 16:42:56 PST
See related WHATWG thread on "Why won't you let us make our own HTML5 browsers?"

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-January/thread.html#34590
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-February/thread.html#34608

In short, Hixie has rejected this (with what appear to be good reasons). It might be useful to post whatever use-cases we have for this API to WHATWG in that thread to get feedback on them. I'm on the fence about it so I'll leave it to those advocating for this API to pursue it.
Comment 24 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2012-02-03 17:32:29 PST
In the first post:

> What is the use case for browser-in-a-browser?
> 
> If you have a browser... then you have a browser. Why would you want to 
> run another one inside your browser?

This is confusing "browser chrome" with "browser engine".

I'm a little surprised that this is so hard to swallow given that this is how the Firefox (and other Mozilla suite) UIs have worked for years and years and years.
Comment 25 Justin Lebar (not reading bugmail) 2012-02-03 18:53:10 PST
I'm going to e-mail Hixie privately and let him know what we're up to.  But I think we'll have a much more compelling case to take to the whatwg list once we have a product.
Comment 26 Jonas Sicking (:sicking) No longer reading bugmail consistently 2012-02-04 21:22:30 PST
Yeah, I think we'll have a much greater chance at getting something standardized once we have at least a demo that we can show.

I would even go as far as saying that this API is complex enough that I don't want to try to standardize anything until we know what the various requirements we have are. The risk of people saying "yeah, that looks like it should be enough" and slapping a standards stamp on it is pretty big.

Not until we have built an actual browser (ideally two, pancake on b2g would be awesome) do I think we'll have a sense for what feature set we need to expose to the browser app, vs. how much can be handled by gecko.
Comment 27 Justin Lebar (not reading bugmail) 2012-03-21 19:29:49 PDT
With apologies, I don't know what sec-review-needed means anymore.  Do I need to take any action here?

None of this is exposed to the web atm -- it's exposed only to super-privileged Gaia origins.  We definitely need to have a long series of conversations before exposing this to the web, but I'm not sure that now is necessarily the right time for those conversations, since the API is still in its early stages of development and we don't have a clear idea what it's going to look like in its final form.  But we can have an informal/informational chat about it now, if you'd like!
Comment 28 Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]] 2012-03-28 14:23:56 PDT
assinged to me for sec action to schedule a meeting
Comment 29 Ben Francis [:benfrancis] 2012-04-03 06:40:44 PDT
I took the liberty or renaming this tracking bug because I can never remember what it's called! Please let me know if this is a problem.
Comment 30 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2012-04-13 02:48:30 PDT
Relevant prior art: http://developer.android.com/reference/android/webkit/WebChromeClient.html
Comment 31 Justin Lebar (not reading bugmail) 2012-08-15 16:48:35 PDT
As I said in bug 748187 comment 5, I don't think another security review of this API would be a useful exercise at this point.  If you disagree, let's discuss in bug 748187.
Comment 32 Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]] 2012-12-18 06:51:09 PST
pauljt ownes the secreview bug for this so chaning the flag to him
Comment 33 Brett Zamir 2015-01-14 11:23:34 PST
For a web use case, see https://bugzilla.mozilla.org/show_bug.cgi?id=618354

To obviate the click-jacking concerns, is there any chance of switching to default browser settings which blackout cross-domain mouse coordinates when over an iframe (or at least for this new kind of iframe)?

Note You need to log in before you can comment on or make changes to this bug.