On Tue, Feb 7, 2012 at 5:31 AM, Robin Berjon <ro...@berjon.com> wrote: > Hi all, > > On Feb 1, 2012, at 17:42 , Tim Berners-Lee wrote: >> On 2012-01 -20, at 14:32, Ian Hickson wrote >>> Personally I think the idea of "installing" a Web app is anathema. >> >> You may, but others have a need for it. > > This is a hot topic, and I'm happy to see it openly broached here. That said, > I think that we're unlikely to reach any manner of consensus unless we take a > few steps back to agree on needs and terminology, as well as hopefully find a > clear cutting point between the two positions above (both of which I agree > with) so that we can have our cake and eat it too. > > I say this because as a community we've been navigating this discussion for a > while now, and we haven't reached collective agreement yet despite good > awareness of the issue. > > For the sake of having some terminology with which to conduct the discussion, > I'd like to offer two definitions. I don't care that they're perfect, and > people should feel free to bikeshed the names to their hearts' content, as > well as refine the definitions. For now, I only care that we have a rough > collective understanding of what we're talking about. I will deliberately > avoid using the term "web app" which is fraught with confusion (or "native", > for the same reason). > > On the first hand we have applications that use Web technology, that are > accessed directly over HTTP, and most importantly that only call upon > functionality that is appropriate for an application that is running inside a > sandbox for distributed code that may come from arbitrary, untrustworthy > sources. Let's call these "Browser Apps". This does *not* entail that one can > only access them inside of some browser-like chrome or that they can't be > "installed" in the sense of maybe being available offline or having an icon > on one's desk/palmtop (or being readily available through any such UI > convention). In some cases, perhaps through their "installation", they may > acquire some limited additional privileges (e.g. being able to use the > device's notification system) but never anything more harmful than what is > tolerable inside a sandbox. > > On the other hand, we have applications that use Web technology, that are > probably not accessed over HTTP but rather have (at least) their executable > resources copied locally, and that have access to functionality that is > potentially very damaging. We can call these "System Apps". These could take > on responsibilities that are core to the usage of one's device, such as > navigating the file system, browsing the Web, managing one's contacts > database, etc. > > We can delve into the details of what separates the two, but the operative > and I believe insurmountable distinction is the security model. The line is > drawn at "more harmful than what is tolerable inside a sandbox". It's a > somewhat subjective line, but overall people tend to gravitate to a shared > understanding of where it sits. I find that a useful mental exercise in > trying to figure out which side of that fence a given piece of functionality > falls on is to imagine granting access to that feature by mistake (or > automatically, if it's not protected by user mediation) to a malicious site. > It's an acceptable risk that I might divulge my geolocation once, that I > might upload one file by mistake, that I may provide the email addresses of a > few of my contacts. It is not an acceptable risk if my location can become > permanently tracked, if I give unfettered access to my local drive even just > once, or full control over my address book. > > It may seem like a shame to split these two worlds, but we have to remember > that we're dealing with a distributed execution environment and breaking the > security promise would indeed be one of the Web's many anathemata. What's > more, I believe that clearly instating this secluding line does not "split > the Web" but rather helps us maintain the clarity needed to address both > sides' needs properly, without hurting either. The question we have to deal > with is how to articulate these two universes, how to produce specifications > that work for both, or on the contrary know how to target only one. > > For some, the answer is simply that System Apps are not "The Web". I am not > convinced that that specific terminology rathole is worth spelunking into. We > need to preserve Browser Apps that work, without breaking them with anything > done at the System Apps level, but there is enough activity in the latter > sphere pretty much all over the place to justify coming to a clear > understanding of a) where the line is drawn between the two and b) what the > specific architectural issues with the latter are (since they are less well > known that for the former). > > At this point I think that it is worth pointing out that the need for System > Apps is often overstated because of the currently limited power of Browser > Apps. But once we have a generic user-mediation model that can uniformly (and > safely) plug both device and remote services into the browser execution > environment many doors open up. That's the work being done under the name > "Web Intents" (the idea, not necessarily the exact solution as currently > drafted). To give an example, with a lot of the attempted solutions to date > (e.g. WAC) if an application may legitimately need to obtain a handful of > contacts (for instance for sharing a game result directly to friends), then > it has to obtain full access to the entire address book. That's a broken > model since it requires elevated privileges for trivial operations. Using > Intents, the application can request a few contacts from the user in a manner > that is both safe and usable; and it will only gain access to the contacts it > actually needs, with the permission for that granted only when it makes > obvious sense to the user. This approach (combined with the existing web > applications infrastructure) effectively makes a huge majority of existing > applications workable purely inside the browser security model, as Browser > Apps. > > But there is still a need for System Apps (unless you're happy handing all > your data over to a third party of dubious trustworthiness), and I think that > we should tackle the issues pertinent to them. > > The first problem is that of the security model. A lot of smart people have > tried to come up with a lot of different solutions here, often involving > signatures, policies, intricate user interfaces, etc. I think that's all > massively over-engineered. Once you take into account the fact that the > number of applications that actually need this level of privilege is only a > tiny fraction of the whole, you realise that you can just give up on > privilege policies. These are just regular apps: they have unfettered access > — period (within the limits of the underlying platform's permissions system > naturally). They ought to be harder (and unusual) to install, and maybe > should look different, but that's it. We might want to give them strong CSP > protection by default to defend against XSS attacks, but that's a detail. > > The other main issue is that by running Web content in a non-HTTP setting, we > lose a lot of small things that usually come naturally, and are known and > expected (even relied upon) by developers and common libraries. For instance, > the SOP. Or, since I was mentioning CSP, HTTP-based innovations that if > needed then need to be duplicated as part of a manifest. XHR for local data > has to be emulated, probably with strange corner cases. It's not very clear > what multiple instances of such a package are: the same app twice, multiple > instances, totally separate? Should they have the same URI? None of this is > absolutely horrible, but none of it is really nice and we might end up with a > number of warts like WARP. > > One potential solution could be to use a widget-like packaging method for > distribution only, but have it run from a local server accessed over HTTP for > the UI (possibly inside a new .app TLD that can only map to localhost and is > protected from interactions with the rest of the world). That should take > care of a lot of widgets' rougher edges. But those are details that we can > sort out as we go. >
Robin, this is a pretty interesting and thoughtful treatise and while I am still digesting parts of it, I can't help but think that the key in identifying precise boundaries and relative position of these two universes is defining one in terms of another. Namely, we may want to explore if Web App sandbox/container can be a System App (I also heard the term Platform App). And if it can be, it both definitively enumerates the set of limitations and APIs imposed by this container System App and dovetails nicely into that whole browser-in-a-browser discussion. :DG<
