Closed Bug 716664 Opened 13 years ago Closed 13 years ago

Popup windows in b2g

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: cjones, Unassigned)

References

Details

We need to figure out how popups should work in b2g. I think there are three classes of popup to worry about (1) window.open. The case we care about here is web pages opening new tabs. Those need to turn into intents or something fired at the browser app, so it can decide between opening a new "app window" or a new tab for the newly-created <iframe remote>. We don't want these to create new nsWindows in the compositor process, although they will create new PuppetWidgets in the content process. And they of course have to be opened in the same content process that called window.open. (2) alert etc. It would be nice if the app launcher could style these, and it would be nice if they didn't create new nsWindows too. But tbh I don't care about these very much. (3) Auth dialogs. I think it's best if these stay implemented by gecko, because it's a huge trust to allow an app to see every credential for every site visited. We probably don't want to allow installed apps to style these, since the style is part of the security. Vivien is there previous work from fennec that we can reuse here, or move into gecko? I'm happy to track these as separate work items.
(In reply to Chris Jones [:cjones] [:warhammer] from comment #0) > We need to figure out how popups should work in b2g. I think there are > three classes of popup to worry about > (3) Auth dialogs. I think it's best if these stay implemented by gecko, > because it's a huge trust to allow an app to see every credential for every > site visited. We probably don't want to allow installed apps to style > these, since the style is part of the security. > The issue here is, if auth dialogs are implemented by gecko/b2g, then the IME still might be implemented by a web app. So this argues for either folding (2) and (3) above into the same item, or packaging "really super trusted" IMEs along with b2g. But even then, the default web-app IME still gets to see my facebook password, e.g. so maybe all IMEs need to be "really super trusted".
(In reply to Chris Jones [:cjones] [:warhammer] from comment #0) > We need to figure out how popups should work in b2g. I think there are > three classes of popup to worry about > > (1) window.open. The case we care about here is web pages opening new > tabs. Those need to turn into intents or something fired at the browser > app, so it can decide between opening a new "app window" or a new tab for > the newly-created <iframe remote>. We don't want these to create new > nsWindows in the compositor process, although they will create new > PuppetWidgets in the content process. And they of course have to be opened > in the same content process that called window.open. > For case 1 I have opened bug 721777. Basically the patch there capture all window.open (from the apps or from the content of web pages) and redirect them to the main window that decide what to do with them. If it the url of an app, then the app is opened. If it's not the url of an app then the url is transmitted to the browser app - the browser app is opened if needed. > (2) alert etc. It would be nice if the app launcher could style these, and > it would be nice if they didn't create new nsWindows too. But tbh I don't > care about these very much. > We could re-use some code from fennec. Hopefully Fabrice hasv worked on it and knows a lot about it :) > (3) Auth dialogs. I think it's best if these stay implemented by gecko, > because it's a huge trust to allow an app to see every credential for every > site visited. We probably don't want to allow installed apps to style > these, since the style is part of the security. Does the auth dialog block the execution of JS? if not I wonder if it already works with the IME? That's possible.
(In reply to Vivien Nicolas (:vingtetun) from comment #2) > > If it the url of an app, then the app is opened. What do you do if the app is already open? I think it should switch the the open app? > If it's not the url of an app then the url is transmitted to the browser app How do you know which app is the browser app? What if the user installs their own browser app? Perhaps we should have a way to define a default browser...
(In reply to Vivien Nicolas (:vingtetun) from comment #2) > (In reply to Chris Jones [:cjones] [:warhammer] from comment #0) > > (3) Auth dialogs. I think it's best if these stay implemented by gecko, > > because it's a huge trust to allow an app to see every credential for every > > site visited. We probably don't want to allow installed apps to style > > these, since the style is part of the security. > > Does the auth dialog block the execution of JS? if not I wonder if it > already works with the IME? That's possible. I don't know. I would imagine that it doesn't block JS execution, since content can't directly block on the auth, only indirectly through XHR.
(In reply to Ben Francis from comment #3) > (In reply to Vivien Nicolas (:vingtetun) from comment #2) > > > If it the url of an app, then the app is opened. > > What do you do if the app is already open? I think it should switch the the > open app? > Yes, I agree. We need to fire an intent or notification at the app though, so it has a chance to launch() another copy of itself. > > If it's not the url of an app then the url is transmitted to the browser app > > How do you know which app is the browser app? What if the user installs > their own browser app? Perhaps we should have a way to define a default > browser... INTENTS INTENTS INTENTS INTENTS ;). If we have to hard code this while awaiting intents, c'est la guerre.
(In reply to Chris Jones [:cjones] [:warhammer] from comment #0) > We need to figure out how popups should work in b2g. I think there are > three classes of popup to worry about > > (1) window.open. The case we care about here is web pages opening new > tabs. Those need to turn into intents or something fired at the browser > app, so it can decide between opening a new "app window" or a new tab for > the newly-created <iframe remote>. Yes. But we also need to figure out what happens when an app does window.open. Maybe we ignore it and return null. > (2) alert etc. It would be nice if the app launcher could style these, and > it would be nice if they didn't create new nsWindows too. But tbh I don't > care about these very much. Bug 741587. > (3) Auth dialogs. I think it's best if these stay implemented by gecko, > because it's a huge trust to allow an app to see every credential for every > site visited. We probably don't want to allow installed apps to style > these, since the style is part of the security. If an app goes to (say) an http auth page, the http auth will be handled by the *parent* app, which is either the window manager (Gaia), the browser app, or another app which is allowed to create <iframe mozbrowser> elements. Being able to create an <iframe mozbrowser> is a huge vote of trust. In particular, anyone who can create an <iframe mozbrowser> can display a fake http auth dialog. Or they can just display a fake bank login page and get you to enter your credentials in there. So I'm not worried about securing the auth dialogs from their parent app.
I'm doing window.open in bug 742944.
Blocks: 698116
> > (3) Auth dialogs. I think it's best if these stay implemented by gecko, > > because it's a huge trust to allow an app to see every credential for every > > site visited. We probably don't want to allow installed apps to style > > these, since the style is part of the security. > > If an app goes to (say) an http auth page, the http auth will be handled by > the *parent* app, which is either the window manager (Gaia), the browser > app, or another app which is allowed to create <iframe mozbrowser> elements. > > Being able to create an <iframe mozbrowser> is a huge vote of trust. In > particular, anyone who can create an <iframe mozbrowser> can display a fake > http auth dialog. Or they can just display a fake bank login page and get > you to enter your credentials in there. So I'm not worried about securing > the auth dialogs from their parent app. The vast majority of authentication on the web today happens through HTML forms. Any such authentication can be snooped on by the browser application. And even if you couldn't steal the username/password, the browser application can steal the session cookies after the user has logged in which almost as good (though doesn't permit you to reuse the credentials on other sites of course). So trying to impose stricter policies for auth dialogs won't really protect anyone in any meaningful ways. So basically users need to be aware the logging in to a website through an app means trusting that app not to steal your credentials. It's unfortunate but I don't see a way around it. We should think of ways to mitigate this though. Maybe by putting up warnings the first time a user interacts with a password field through an app.
> And even if you couldn't steal the username/password It's trivial to steal the username/password in a browser. User types http://bank.com into the location bar. Send them to http://phishing.com, but display http://bank.com (with a lock icon and everything) in the location bar. User types in username/password. > We should think of ways to mitigate this though. Maybe by putting up warnings the first time a user > interacts with a password field through an app. I guess that might be OK.
What does this have to do with bug 698116, in-app purchases?
(In reply to Jonas Sicking (:sicking) from comment #8) > > > (3) Auth dialogs. I think it's best if these stay implemented by gecko, > > > because it's a huge trust to allow an app to see every credential for every > > > site visited. We probably don't want to allow installed apps to style > > > these, since the style is part of the security. > > > > If an app goes to (say) an http auth page, the http auth will be handled by > > the *parent* app, which is either the window manager (Gaia), the browser > > app, or another app which is allowed to create <iframe mozbrowser> elements. > > > > Being able to create an <iframe mozbrowser> is a huge vote of trust. In > > particular, anyone who can create an <iframe mozbrowser> can display a fake > > http auth dialog. Or they can just display a fake bank login page and get > > you to enter your credentials in there. So I'm not worried about securing > > the auth dialogs from their parent app. > > The vast majority of authentication on the web today happens through HTML > forms. Any such authentication can be snooped on by the browser application. > And even if you couldn't steal the username/password, the browser > application can steal the session cookies after the user has logged in which > almost as good (though doesn't permit you to reuse the credentials on other > sites of course). > I don't see why this is the case with the current "browser API" we expose, except through something like the phishing attack Justin suggests.
Doesn't the current browser API allow the browser app to reach into the page and execute script in its context. I got the impression when I last talked to Justin that this was at least planned.
That's not exposed. I want to see how far we can go without implementing that, for reasons like what you point out in comment 8. I suspect we might have to expose it eventually, but that will be a sad day for me. If we do, it should be a separate permission bit, IMHO.
(In reply to Jonas Sicking (:sicking) from comment #12) > Doesn't the current browser API allow the browser app to reach into the page > and execute script in its context. I got the impression when I last talked > to Justin that this was at least planned. You didn't misunderstand the plan, but we didn't end up doing it that way. At least for now. :)
(In reply to Justin Lebar [:jlebar] from comment #10) > What does this have to do with bug 698116, in-app purchases? Similar to browser ID, in-app purchases need to use window.open when displaying purchase confirmation (if a cookie doesn't already exist). Normally we will use an iframe. If we can switch to a web intent / activity then that should probably work, we just need to know what to use.
I think using window.open for in-app purchases is a bad idea, because if we supported window.open, it would necessarily load in the browser. So that's an out-of-app purchase.
Blocks: 758271
No longer blocks: b2g-demo-phone
The part of this work that's not already covered by existing bugs is bug 759511 and bug 759512, so closing this in favor of the more specific work items.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.