On Mon, Apr 8, 2013 at 12:17 AM, Mark Nottingham <m...@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