- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 30 Apr 2013 21:20:24 -0700
- To: Mark Nottingham <mnot@mnot.net>
- Cc: Webapps WG <public-webapps@w3.org>
On Mon, Apr 8, 2013 at 12:17 AM, Mark Nottingham <mnot@mnot.net> wrote: > Hi Jonas, > > I don't get a good sense from this proposal (and NavigationController) about what the scope of an application is. E.g., if both > http://example.com/fooApp > and > http://example.com/barApp > say that they both grab the URL > http://example.com/app > who wins? > > More to the point, what's stopping > http://users.example.edu/~bob/ > from taking over responses from > http://users.example.edu/~alice/ > ? > > Also along these lines - I see an outstanding question that some people want to host multiple apps on the same URL. Is that really wise? > > If anything, I'd go the other way and say that one hostname = one app; then the scoping of and separation between apps is intuitive (e.g., fooApp.example.com, barApp.example.com). You could even define a well-known location for the manifest, so that people could just type the hostname in to install / view the app... This is, unfortunately, a great point. The current AppCache spec suffers from this too, but only once users go offline. I.e. I can use FALLBACK to take over http://users.example.edu/~alice/ using a resource from from http://users.example.edu/~bob/newalice.html But that only works when the user is offline, which limits the damage a little. The only solution that I can see to this problem is requiring that manifests, or navigationcontroller-scripts are only allowed to "take over" URLs that are "below" them. I.e. http://users.example.edu/~bob/manifest.json could only control navigations to URLs with the prefix "http://users.example.edu/~bob/". You could still redirect resource loading in more flexible ways, but maybe top-level page loads needs to have this restriction. / Jonas
Received on Wednesday, 1 May 2013 04:21:22 UTC