Web start sandboxing and security

[Jiri Vanek]

On 12/04/2013 11:37 AM, helpcrypto helpcrypto wrote:
> Hi
>
> I dont know if the same rules apply to Java Applets.
> In our case we use a crypto applet to sign documents using user certificates.
>
> Said so, i think providing user "less options" is sometimes better/easier for them. A "yes/no"
> dialog is much simpler than a multiple selection option.

true

> Anyhow, I understand your concerns, and considering Google is "switching off" Java (Chrome is a big
> part of browsers market share), i suggest you "moving out" from Java Applets/JNLP. ;)

jnlp have nothing to do with chrome, and google i behaving nasty in this topic - namely misusing its 
position. Now I think about chrome in same way as about IE. And about google nearly as bad as about 
Microsoft - Forcing theirs technologies no matter of cost.
>
> Considering unsigned apps are run on a sandbox (without risks for the user), and signed are
> "dangerous", probably showing the user the application required permissions (by the permissions
> attribute on the manifest) will be ok, but we (as many pthers) will just put "all-permissions", so
> at the end, it will be the same.
>
> BTW: Do end-users really read? xD

I believe yes. Especially when some interest abut the app rise. Nice example can be this discussed 
scenario:

  - I'm bfu, and some strange dialogue starts to jump to me.... not reading it clicking no (as I'm 
paranoid)... and well expected app do not jump out...
  - reload the page, again this dialogue rise, and I click yes.... wou!
  - repeat ^ 10x
  - me, bfu "Do I really need to click this button? five times a day?" ..me, finally reading the 
dialogue , and discovering the  remember checkbox!
  - repeat above 100x.... hm what the hell is this app doing? Isnt it dangerous? What was rising the 
dialogue..
     - studying icedtea-web
     - defining custom policies :)
>
>

The confusing you are speaking about is very nicely solvable by "show advanced option" button.

In case of dialogues we are speaking about - is "show more" worthy for dialogue where are two basic 
buttons and one button and three check boxes "advanced" controls?
>
> On Mon, Dec 2, 2013 at 10:04 PM, Andy Lutomirski <luto at amacapital.net <mailto:luto at amacapital.net>>
> wrote:
>
>     On Sun, Dec 1, 2013 at 11:39 PM, Jiri Vanek <jvanek at redhat.com <mailto:jvanek at redhat.com>> wrote:
>      > On 12/01/2013 02:24 AM, Fernando Cassia wrote:
>      >
>      >>
>      >> On Fri, Oct 18, 2013 at 3:14 PM, Andy Lutomirski <luto at amacapital.net
>     <mailto:luto at amacapital.net>
>      >> <mailto:luto at amacapital.net <mailto:luto at amacapital.net>>> wrote:
>      >>
>      >>     Even if the app is signed, there should still be a way to run it in
>      >>     the sandbox.  I've yet to encounter a JNLP app in the wild that has
>      >>     any legitimate reason to do anything other than access the internet,
>      >>     create some temporary files, and occasionally use the file picker.
>      >>     Let me run it in the sandbox, please.
>      >>
>      >>
>      >
>      > This is intresting idea, to have "Aplication is signed, trust/dont trust"
>      > dialog extedned to  "Aplication is signed, trust/dont trust/run in sandbox"
>      >
>      > I'm not sure how hardor even safe will be to implement it, but there can be
>      > anther solution.  Andrew Azores is working on policy.tool, which should do
>      > exactly waht you wont.
>      > Although application X is requesting permissions A B C, you specifi in
>      > policy file  that it can use only eg B. So when app. X will request A and C
>      > it will get permission denied.
>      > Is it what you wont?
>      > Maybe when this will be safely in and tested, we can add the "run in
>      > sandbox" button, which will just create tmo policy for application.
>
>     That would be great.
>
>      >
>      > However this development is tricky work, and althogh we are trying  to get
>      > it into next (1.5) release, we are not sure if we will make it.
>      >
>
>     In the mean time, I'd still consider a change to the text in the UI to
>     be a considerable improvement.
>
>     --Andy
>
>