- From: Michaela Merz <michaela.merz@hermetos.com>
- Date: Wed, 19 Nov 2014 09:27:46 -0600
- To: Pradeep Kumar <pradeep.online00@gmail.com>
- CC: public-webapps <public-webapps@w3.org>, noloader@gmail.com
- Message-ID: <546CB6F2.8060504@hermetos.com>
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.merz@hermetos.com > <mailto: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 <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). >> >> >> >
Received on Wednesday, 19 November 2014 15:27:59 UTC