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