Re: Browser vs System level security (was: Installing web apps)

Hi Robin,

I'm happy you are starting to deal with this key thing for the evolution
of the Web as a platform. We say in Spain 'better late than never'.

Unfortunately I won't attend the F2F but will be happy to contribute in
the next months to DAP or other W3C efforts if "System APIs" are under
scope.

best

El 15/02/12 16:58, "Robin Berjon" <robin@berjon.com> escribi�:

>Hi all,
>
>a few days ago there was a thread that spanned both WebApps and the TAG
>about installable Web applications � something that's very much relevant
>to DAP. I suspect that several here have seen it, but not all. What I am
>forwarding below is my position in that discussion (you can find the
>started threads by following
>http://www.w3.org/mid/FA3C1458-84E1-4B03-BC01-08426A0C2097@berjon.com).
>
>There are several things that I think ought to be extracted from that
>discussion.
>
>First, I think that it would be useful to document and reach consensus on
>� beyond DAP � the security architecture for web applications in general.
>Naturally, I offer the ideas below as a starting point, but then I wrote
>them so I would � disagreement is welcome as we move towards consensus.
>Such work is already in scope for our group so it's not a problem.
>
>Second, as you know this group rechartered explicitly in a manner that
>prevents us from working on APIs that are not compatible with the browser
>security model. I still think that's a good choice since it has enabled
>us to stop going back and forth on APIs that tried to work for both
>system- and browser-level security contexts; something that to date has
>never been shown to work satisfactorily.
>
>But I suspect that if we reach a good understanding of what type of API
>can go where, then we could reopen that door with knowledge sufficient to
>do the right thing (hopefully). I would only want to do so cautiously,
>and after careful consideration and discussion here. Notably, those of
>you who have been discussing such things offline should speak up now �
>especially those who likely have changed their minds on the topic over
>the past year.
>
>I'd like to have had enough of a discussion here that we can go to the
>f2f and produce useful decisions there on this topic.
>
>Thoughts?
>
>
>Begin forwarded message:
>> Resent-From: public-webapps@w3.org
>> From: Robin Berjon <robin@berjon.com>
>> Date: February 7, 2012 14:31:10 GMT+01:00
>> To: Tim Berners-Lee <timbl@w3.org>
>> Cc: Ian Hickson <ian@hixie.ch>, WebApps WG <public-webapps@w3.org>,
>>Thomas Roessler <tlr@w3.org>, "Michael[tm] Smith" <mike@w3.org>,
>>"www-tag@w3.org List" <www-tag@w3.org>
>> Subject: Re: Installing web apps
>> archived-at:
>><http://www.w3.org/mid/FA3C1458-84E1-4B03-BC01-08426A0C2097@berjon.com>
>>
>> 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
>>
>>
>
>--
>Robin Berjon - http://berjon.com/ - @robinberjon
>
>


Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra pol�tica de env�o y recepci�n de correo electr�nico en el enlace situado m�s abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

Received on Monday, 20 February 2012 10:40:20 UTC