Re: What I am missing

You are correct. But all those services are (thankfully) sand boxed or 
read only. In order to make a browser into something even more useful, 
you have to relax these security rules a bit. And IMHO that *should* 
require signed code - in addition to the users consent.

Michaela



On 11/19/2014 09:09 AM, Pradeep Kumar wrote:
>
> Even today, browsers ask for permission for geolocation, local 
> storage, camera etc... How it is different from current scenario?
>
> On 19-Nov-2014 8:35 pm, "Michaela Merz" <michaela.merz@hermetos.com 
> <mailto:michaela.merz@hermetos.com>> wrote:
>
>
>     That is relevant and also not so. Because Java applets silently
>     grant access to a out of sandbox functionality if signed. This is
>     not what I am proposing. I am suggesting a model in which the
>     sandbox model remains intact and users need to explicitly agree to
>     access that would otherwise be prohibited.
>
>     Michaela
>
>
>
>
>
>     On 11/19/2014 12:01 AM, Jeffrey Walton wrote:
>
>         On Wed, Nov 19, 2014 at 12:35 AM, Michaela Merz
>         <michaela.merz@hermetos.com
>         <mailto:michaela.merz@hermetos.com>> wrote:
>
>             Well .. it would be a "all scripts signed" or "no script
>             signed" kind of a
>             deal. You can download malicious code everywhere - not
>             only as scripts.
>             Signed code doesn't protect against malicious or bad code.
>             It only
>             guarantees that the code is actually from the the
>             certificate owner .. and
>             has not been altered without the signers consent.
>
>         Seems relevant: "Java's Losing Security Legacy",
>         http://threatpost.com/javas-losing-security-legacy and "Don't Sign
>         that Applet!",
>         https://www.cert.org/blogs/certcc/post.cfm?EntryID=158.
>
>         Dormann advises "don't sign" so that the code can't escape its
>         sandbox
>         and it stays restricted (malware regularly signs to do so).
>
>
>