- From: Pradeep Kumar <pradeep.online00@gmail.com>
- Date: Wed, 19 Nov 2014 20:39:59 +0530
- To: Michaela Merz <michaela.merz@hermetos.com>
- Cc: public-webapps <public-webapps@w3.org>, noloader@gmail.com
Received on Wednesday, 19 November 2014 15:10:28 UTC
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). >> > > >
Received on Wednesday, 19 November 2014 15:10:28 UTC