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