I don't disagree. But what is wrong with the notion of introducing an
_additional_ layer of certification? Signed script and/or html would
most certainly make it way harder to de-face a website or sneak
malicious code into an environment. I strongly believe that just for
this reason alone, we should think about signed content - even without
additional potentially unsafe functionality.
Michaela
On 11/19/2014 09:21 AM, Pradeep Kumar wrote:
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.m...@hermetos.com
<mailto:michaela.m...@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.m...@hermetos.com <mailto:michaela.m...@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.m...@hermetos.com
<mailto:michaela.m...@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).
