Re: Installing web apps

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 Berjon - http://berjon.com/ - @robinberjon

Received on Tuesday, 7 February 2012 13:34:35 UTC