= Summary Version =
Can we simplify your proposal by:
1. Removing the separation between hosted apps and regular web content
2. We add support multiple apps per origin, but make sure a specific url will
always belong to one specific app, or be treated as web content. We achieve
this by letting app developers reduce the scope of their apps to only parts of
their manifest’s origin, e.g. subfolders or other regex of their choosing,
through use of manifest parameter.
3. When we navigate to a page which inside an app, we hide chrome and go into
app mode. On each new page load we either stay in this app (no change), go
back to the browser for web content, or switch to a new app.
4. We still need to figure out a way to link to packaged apps, but to me that
is a separate problem
= Long Version =
How about we do away with the separation between web and hosted web apps
entirely (unless the apps explicitly requests to be sandboxed) AFAIK, there is
little difference in the risk profiles of web pages vs hosted apps, so perhaps
they should all be in the same sandbox. Also if we allow an app to not
represent the entire origin, I have a proposal for supporting multiple apps for
origin which I think solves some of the “which app am I in” questions. Allow me
to ruminate in terms of your goals:
A. Always show browser chrome, unless you are on the origin of an installed app
(see B though about reducing app-scope). If you are in an app, and you navigate
to a page which is not contained within the app’s scope, show browser chrome
(unless of course you are linking to a page which is contain within the scope
of another app).
B. Allow web developers to carve up their origins into web content and app
content (potentially multiple apps), but make sure that for any given URL, it
is either web content, or belonging to a specific app - never both, or multiple
apps. To do this, we allow to reduce the scope of its origin in the manifest by
supplying a URL pattern (or maybe regex even) relative to the origin of the
manifest:
{
"name": "GreatApp",
...
“app-scope": “/app/*”
}
All urls are treated as web content unless they belong to an app’s scope. If
you install an app on an origin, all URLs on that origin are now loaded inside
an app without browser chrome when navigated to. We automatically fail any
install if an app specifies a scope that is already claimed by an existing app
(or ask the user if they want to uninstall the existing app, and replace it
with the new app?)
This approach also assumes one developer controls all apps on a given web
origin. Apps on shared hosting may conflict with each other. Do we need to
support this as a use case? Can we somehow try synthesize an app-scope
parameter here? e.g app installed at /foo/manifest.webapp and trying to install
/bar/manifest.webapp - we add a /foo and /bar app-scope parameter to each app
respectively and just fail if one subsumes the other on a subfolder basis? (e.g
if /foo/manifest.webapp, fail for attempts to install /foo/bar/manifest.webapp)
I’m not exactly sure of the correct logic here, but I feel like if we are
careful we can come up with a deterministic algorithm.
C. Hmm, maybe my approach falls down here, but if we are navigating to enter my
google login, don’t I really want to be taken out of the app, and into the
browser view at this point? I actually hate this about other app platforms
where you end up browsing the web inside an app. Note that for web apps, since
web apps and web content is in the same sandbox, we are already logged into
google, just as it is on the web.
D. Not familiar with this issue, but this solution doesn’t require asking the
user anything, if thats what you mean.
E. As per B, support multiple apps per origin, but the developer has to limit
that scope of the apps so that they don’t overlap. (so we always know what app
we are in)
F. Solved as above I think.
G. I think G is solved because we can specifically know when a cookie etc
belongs to an app scope, and when it doesn’t we just treat it all as web scope.
(Note that this may include cookies for origins which belong to an app scope,
but have been loaded in the web sandbox, e.g. when I frame app content in a web
page I shouldn’t get cookies set when from when i was in an app context)
Allowing web apps to elect to be sandboxed:
We should provide a option in the manifest to let sensitive apps that don’t
want to be a part of the web sandbox, hive themselves off, e.g:
{
"name": "GreatApp",
...
“sandbox": true
}
It strikes me that the user should be able to sandbox an app too, so it can’t
slurp services etc, but i think that is just private browsing mode.
Linking to a sandboxed app, you end up in the app, inside a separate child
process. Frame an app and you just get the content, loaded in the whatever app
sandbox you are currently in, same as it is today. So hack any web page, or any
app that hasn’t elected to be sandboxed, and you get everything in the web
sandbox, the same as you would today in any browser. You won’t however get any
cookies for packaged apps, or hosted apps that have elected to be sandboxed.
I haven’t dealt at all with how to link to packaged apps, but that seems
orthogonal, maybe (or at least I don’t have a good answer…)
I’m sure there are other details - updates, for one - but I am out of brain
power for now. I’m sure there are details I’ve overlooked, but hopefully this
helps.
- Paul
On 10 Mar 2014, at 6:33 am, Jonas Sicking <[email protected]> wrote:
> On Wed, Feb 12, 2014 at 6:08 AM, Ben Francis <[email protected]> wrote:
>> *For a given URL, how should we determine whether it belongs to an app or
>> should be opened in a browser window?*
>
> Yay! This is a super fun question that I've done some pondering on.
> There are some quite complex aspects here unfortunately, but we maybe
> don't need to solve every problem at once.
>
> There's a few goals here that I think we should try to accomplish:
>
> A. Make it easy for developers to avoid the problem where clicking an
> ad in an app which doesn't have back/forward UI takes them to some
> other website, but with no way to get back.
> B. When the user receives a link to a facebook post in their email,
> clicking that link should open the post in the facebook app, if the
> user has the facebook app installed. Same thing if finding a link to a
> facebook post on some other website.
> C. Enable an AwesomeGame app to use google login and other 3rd party
> services without causing that to leave the AwesomeGame app.
> D. Don't recreate the issue that the android browser has where every
> so often during navigation it asks which browser you want to open the
> clicked link in.
> E. Support multiple apps per origin.
> F. If the user has used an app, they should be able to use the
> rocketbar to get back to content inside that app.
>
> What I'd further like to accomplish, but that is much more complex is
>
> G. Preserve the current security feature that app data is protected
> using OS-level process boundaries. I.e. if a webpage that the user
> visits manages to hack gecko child process, it still can't access any
> cookies or other data from an installed facebook app or bank app.
>
> I'll leave out G for now, but if someone has ideas for how we can
> accomplish G, then I'm all ears.
>
> I think that in order to accomplish A we need something better than
> targetting links and window.open calls to "_blank". The main problem
> with relying on _blank is that an app can contain literally thousands
> of links. Finding and auditing each of them to make sure that they
> have the right target is tedious and error prone.
>
> Another problem is that in many ads, the markup that renders the ad
> isn't actually in control of the page author. A common way to render
> ads is by using a <script src="http://adprovider.com/...";>. This
> script then generates and inserts the markup for displaying the ad.
>
> So I think we need a way for an app to express a policy of what should
> open in the default browser, and what should be treated as a
> navigation within the app. Sticking something in the manifest is the
> obvious solution:
>
> {
> "name": "GreatApp",
> ...
> "in-app-urls": ["http://greatinc.com/app/*";,
> "https://apis.facebook.com/login/*";]
> }
>
> With that, any attempts to navigate to a URL that doesn't start with
> "http://greatapp.com/"; or "https://apis.facebook.com/login/"; would
> result in the URL being opened in the default browser. This also
> enables use-case C since facebook login service can still be used.
>
> Note that resources like images and scripts can still be loaded form
> anywhere. Likewise <iframe>s can be navigated to any url. Only
> toplevel navigation would be affected by the "scope" attribute.
>
>
> However I don't think we can use the same scope attribute to solve the
> B use case. In the particular case above, we obviously start GreatApp
> any time someone navigates to the facebook login page. So
> unfortunately I think we need to introduce a separate attribute for
> this
>
> {
> "name": "GreatApp",
> ...
> "in-app-urls": ["http://greatinc.com/app/*";,
> "https://apis.facebook.com/login/*";],
> "catch-urls": ["http://greatinc.com/app/*";]
> }
>
> (The names here are in desperate need of improvement)
>
> This would cause any top-level navigation to any URL starting with
> "http://greatinc.com/app/"; to open in within GreatApp rather than
> "normally".
>
> This would of course include markup like <a
> href="http://greatinc.com/app/index.html"; target="_blank">. But also a
> simple link like <a href="http://greatinc.com/app/index.html";> would,
> unless coming from a document inside an <iframe> cause the page to
> open within GreatApp.
>
> This includes the situation where we otherwise would not have created
> a new sheet. I.e. I think that we should, when doing a top-level
> navigation to a URL enumerated in any App's "catch-url" force a new
> sheet to be created, and make that sheet be opened within the
> appropriate app.
>
> This also means that we have to limit the "catch-urls" feature to only
> be allowed to catch URLs that are from the same origin as the
> manifest.
>
> A tricky aspect here is that a lot of websites use a separate origin
> for their mobile sites. So for example facebook uses m.facebook.com
> for their mobile website. I'm not really sure how to reconcile that.
> Possibly this isn't as big of a deal since they might not link
> directly to the m-site from things like emails? Ideas here very
> welcome.
>
> With regards to F. I think we'll have to, for each browsed URL,
> remember not just which URL the user visited, but also as part of what
> app. Possibly this is also something we could use to display the App's
> icon in the awesomebar search results?
>
>
> It's be great to get together and talk through the details of all of
> the above. I realize that I'm glossing over a lot of details, and
> there's a lot of stuff that needs to be figured out.
>
> I also would love to get some more brains than mine thinking about our
> current cookie policies and try to solve goal G above. I don't think
> that what we have right now works very well, but I also don't know how
> to fix it.
>
> / Jonas
> _______________________________________________
> dev-webapps mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-webapps
_______________________________________________
dev-webapps mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-webapps
