W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2012

Re: Installing web apps

From: Jean-Claude Dufourd <jean-claude.dufourd@telecom-paristech.fr>
Date: Thu, 09 Feb 2012 12:09:37 -0800
Message-ID: <4F342801.6030604@telecom-paristech.fr>
To: Robin Berjon <robin@berjon.com>
CC: public-webapps@w3.org
As you are saying, we seem to be talking of different things, even if I 
have a problem seeing how different.
You make a difference between apps using web technologies accessed by 
HTTP or not, which I thought close to installed or not.
You postulate the absence of a "safe and usable way of escalating 
privileges for apps".
That is probably what I most react to. You are talking of either 
sandboxing, or unfettered access. That is basically the difference 
between web apps and native apps in iOS, and I hate it!
I can live with it only because Apple does some strict checking on 
native apps, but I hate relying on their judgment on privacy-related data.
So I hope you are wrong, and we can find a workable model with finer grain.
Best regards
JC

On 8/2/12 14:21 , Robin Berjon wrote:
> On Feb 8, 2012, at 01:06 , Jean-Claude Dufourd wrote:
>> On 7/2/12 05:31 , Robin Berjon wrote:
>>> 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.
>>>
>> JCD: I strongly disagree with you there, Robin. I do not see why "installed apps" should have more access.
> You're the one calling them installed apps :) In the section you quote above (and, unless I made a mistake, in the entirety of my post) I don't refer to high-privilege apps as "installed". The installation method is largely an orthogonal problem. I personally think that it should be close to impossible to access a page in one's browser and by mistakenly clicking on a dialog to grant it permissions that would be dangerous. You probably need at least something involving multiple clicks with no quick keyboard bindings and a speed bump.
>
>> "Normal apps" and "installed apps" should have the same security model, but "installed apps" may have permanently remembered security clearances, and that could be the only difference.
> That's not the line that I'm drawing. I'm drawing a line between browser apps and the rest. I'm further pointing out that the number of applications that actually fall into the "rest" category is smaller than most people expect once we have a generic user-mediation security system, such as Intents provide. That works *because* the number of security clearance dialogs (or the size of their content) can be diminished, perhaps even to the point that they disappear in most cases.
>
> Under this approach, System Apps are few are far apart. For a lot of users I suspect it might even be possible that they would never want any beyond those preinstalled. Safety comes from cutting the escalation vector, and making interactions between users and security about what the user wants to do rather than about a personal security policy decision  which most people (myself very much included) don't want to hear about.
>
>> My proposal is as simplistic as yours, but in the opposite direction. You are saying "installed apps" should have all rights, I am saying "installed apps" should obey the exact same security as "normal apps".
>> In your system, it is dangerous to install an app, but it is very simple. In mine, there is no danger, but it is a bit more work.
> It's difficult for me to reply to this properly since you're making a distinction that isn't the one I'm making. How does the approach you propose acquire privileges? Upfront permissions are a security no-go. Doorhanger/infobars don't scale to multiple permissions. Facebook's current model which mixes both in moderation (ask only the smallest set you absolutely need upfront, in full knowledge that asking too many permissions decreases your adoption, and ask more in the flow of user actions) could be an interesting option but I don't know if it could scale to the sort of dangerous features that we'll eventually need for a full platform.
>
> The missing part in your description above is "there is no danger *if we have a way of escalating privileges from web apps in a safe, usable manner*". To the best of my knowledge we don't, hence the noodling on a different approach.
>
>> Java tried that for applets, and Java is now gone from the web apps stage.
> Applets could gain a lot of permissions! It was a terrible model, and has nothing in common with what I'm thinking about :)
>


-- 
JC Dufourd
Directeur d'Etudes/Professor
Groupe Multimedia/Multimedia Group
Traitement du Signal et Images/Signal and Image Processing
Telecom ParisTech, 37-39 rue Dareau, 75014 Paris, France
Tel: +33145817733 - Mob: +33677843843 - Fax: +33145817144
Received on Thursday, 9 February 2012 20:10:07 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:50 GMT