The desktop runtime should allow an app to load resources from "allowed origins" explicitly specified in its manifest, to support use cases like integration with a third-party identity provider (BrowserID, Facebook Connect).

This sounds similar to bug 741955. Is it a duplicate? Dependency?

Related bug, not duplicate or dependency.

Note - This bug blocks use of pop-ups on origins other than browser ID and facebook.

I believe the eventual goal is for app manifests to also include browserid.org and facebook in their allowed origins, so then we would remove that auto-whitelist from our codebase.

I wonder if this should be a "required" enhancement for the 1st release, given that this affects pop-up functionality.

This sounds important for k9o. Does it depend on solving the bug at 741955?

Yes, we have to satisfy the security requirement in bug 741955 in order to implement a fix for this bug, since the security issue identified in that bug is a consequence of fixing this bug. Setting the bug dependency accordingly. And yes, it is important. Many apps navigate to other origins, including that of Mozilla Persona (and also Facebook, Twitter, and Google, in particular), for identity authentication. Currently, the desktop runtime works around the lack of this feature by hardcoding a list of popular origins. That doesn't scale, and it isn't a good long-term solution in the small, either. I would very much not want to ship Kilimanjaro without the long-term solution in place. This bug is about implementing the long-term solution.

(In reply to Myk Melez [:myk] [@mykmelez] from comment #7) > Yes, we have to satisfy the security requirement in bug 741955 in order to > implement a fix for this bug, since the security issue identified in that > bug is a consequence of fixing this bug. Setting the bug dependency > accordingly. > > And yes, it is important. Many apps navigate to other origins, including > that of Mozilla Persona (and also Facebook, Twitter, and Google, in > particular), for identity authentication. Currently, the desktop runtime > works around the lack of this feature by hardcoding a list of popular > origins. That doesn't scale, and it isn't a good long-term solution in the > small, either. > > I would very much not want to ship Kilimanjaro without the long-term > solution in place. This bug is about implementing the long-term solution. This bug affects the mozapps API implementation, correct? If so, we should open a bug in the mozapps API and link it here.

The feature touches several parts of the stack, including the manifest specification, the Marketplace and navigator.mozApps validators, any other supported validators, and the runtime. Plus security review. Not sure how many additional bugs that entrains, though. I'd be happy to let the person responsible for implementing this feature figure that out, once we figure out who that is.

I believe you don't mean "load resources" but "navigate to a page". A resource would mean something like an image, which I believe can be loaded from any origin. An alternate proposal was made to use anchor targets to indicate if an outbound link should be opened in the app or locally (what then happens on subsequent links is unclear). This could be handled at runtime, so there no reason that it must be in the manifest. The anchor target proposal has some problems (e.g., using a library that doesn't use the specific kinds of targets you might expect), but perhaps something else could be done at runtime to handle this case?

(In reply to Ian Bicking (:ianb) from comment #10) > I believe you don't mean "load resources" but "navigate to a page". A > resource would mean something like an image, which I believe can be loaded > from any origin. Yes, you're correct; updating the bug summary to clarify. And per the Apps security model <https://wiki.mozilla.org/Apps/Security>, we actually do not intend to restrict an app's ability to navigate off-origin. At least not for "untrusted apps", which are the only kind the runtime currently supports. So we should not fix this bug. Instead, we should make it possible for an app to explicitly distinguish URLs that should load in the user's default browser from those that should load in the app. I filed bug 752666 on that. > An alternate proposal was made to use anchor targets to indicate if an > outbound link should be opened in the app or locally (what then happens on > subsequent links is unclear). This could be handled at runtime, so there no > reason that it must be in the manifest. The anchor target proposal has some > problems (e.g., using a library that doesn't use the specific kinds of > targets you might expect), but perhaps something else could be done at > runtime to handle this case? Indeed, I've described one such approach in bug 752666.