[rfc][icedtea-web] allow permissions on the fly

[Jacob Wisor]

On 2/9/2015 at 11:08 AM Jiri Vanek wrote:
> It is quite hard to preset all policies *before* run in sandbox is clicked.
> On devconf, where this approach was quite appreciated, following idea was raised:
>   - when mode is "run in sandbox"  AccessControlException access denied -permission.type- should be 
> thrown, then instead throw, allow user to temprary/pernamently allow this policy for codebase.
> 
> During first run many of thsoe dialogs will rise, but at the end  the application will be well tuned.
> 
> AFAIk there is issue - the policy file can remember only allowed policies, but in this case we need 
> to have also permanently banned policies saved. As policy file do not allow this, i see two solutions:
>   - extend policy file - probably no way
>   - have two "run in sanbox" buttons (or similar setting)
>     - run in sandbox
>     - interactive run in sandbox
> 
> 
> Thoughts?
> 
> (no patch here!-)

What you are proposing is the "Windows Vista with UAC" approach but on the first run only. In short,
this leads to this: https://www.youtube.com/watch?v=VuqZ8AqmLPY
Although this conecpt is logically correct, it does not work with most users and just annoys the
*s4!+* out of them. It does not matter whether users are confronted with this once or every time.
Of course, you can implement this but does it really make user's computers more secure?

I think, I have already covered this in previous posts.
Anyway, the *core* problem of the current J2SE permission framework/conecpt is, that the user (or
administrator) needs to know what the application is actually doing and what resources it needs to
access /before/ runtime. Or, iterate running the application with the default security manager and wait
for permission exceptions. Then decide which permissions, and thier scope, should be granted.

This is very cumbersome, difficult, and requires deeper understanding of Java concepts as well as
general OS conecpts. This level of understanding can only be expected from administrators and/or
developers, not the vast majority of users. Yes, even some administrators have problems understanding
Java or OS concepts. Again, most users just want thier work done, and whatever makes an app happy, that
is makes is run smoothly, they will just grant it that particular permission clicking "OK" on whatever
comes up. In the end, this effectively does not differ /much/ from granting every permission an app
asks for to AllPermissions. A user and even administrators have very little to no information to be
truly able to decide whether the requested permission is legit or not, except perhaps for obvious cases
when accessing system configuration files, kernel files, bootloader files etc. And even in those cases
it might be legit. So this concept heavily relies on information and knowledge of users, which most
users simply do not have or should not need to have, just to get thier work done.

So again, I do refer to taking a look at Android's permissions conecpt. However, Android's concept is
incomplete because it forces users to decide on "everything or nothing". You can either install/run the
app or not. Cyanogenmod actually makes this concept complete by enabling users to grant or deny
particular permissions (which have been predefined by the app's developer), after installation but
*before* runtime.

So there is little or nothing we can do with a broken conecpt, or a concept that leads into a dead end.
I might have read some post on this mailing list that would suggest a new permissions
framework/concept in Java 9. I did not take a deeper look into this yet but I am assuming very much it
to be similar to Android's/Cyanogenmod's.

Jacob