Re: What I am missing

Michaela,

As Josh said earlier, signing the code (somehow) will not enhance security.
It will open doors for more threats. It's better and more open, transparent
and in sync with the spirit of open web to give the control to end user and
not making them to relax today on behalf of other signing authorities.
 On 19-Nov-2014 8:44 pm, "Michaela Merz" <michaela.merz@hermetos.com> wrote:

>  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>
> 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> 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).
>>>
>>
>>
>>
>