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
