Thank you Jonas. I was actually thinking about the security model of
FirefoxOS or Android apps. We write powerful webapps nowadays. And
with webapps I mean regular web pages with a lot of script/html5
functionality. The browsers are fast enough to do a variety of things:
from running a linux
How the browsers can be code servers? Could you please explain a little
more...
On 19-Nov-2014 7:51 pm, Michaela Merz michaela.m...@hermetos.com wrote:
Thank you Jonas. I was actually thinking about the security model of
FirefoxOS or Android apps. We write powerful webapps nowadays. And
with
Perfect is the enemy of good. I understand the principles and problems
of cryptography. And in the same way we rely on TLS and its security
model today we would be able to put some trust into the same
architecture for signing script.
FYI: Here's how signing works for java applets: You need to
I am not sure if I understand your question. Browsers can't be code
servers at least not today.
Michaela
On 11/19/2014 08:43 AM, Pradeep Kumar wrote:
How the browsers can be code servers? Could you please explain a
little more...
On 19-Nov-2014 7:51 pm, Michaela Merz
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
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 wrote:
That is relevant and also not so. Because Java applets silently grant
access to a out of
On Wed, Nov 19, 2014 at 4:27 PM, Michaela Merz
michaela.m...@hermetos.com wrote:
I don't disagree. But what is wrong with the notion of introducing an
_additional_ layer of certification?
Adding an additional layer of centralization.
--
https://annevankesteren.nl/
First: You don't have to sign your code. Second: We rely on
centralization for TLS as well. Third: Third-party verification can be
done within the community itself
(https://www.eff.org/deeplinks/2014/11/certificate-authority-encrypt-entire-web)
.
Michaela
On 11/19/2014 09:41 AM, Anne van
Browser signature checking gives you nothing that CSP doesn't as far
as the security of pages composed from a mixture of content from
different providers.
As Florian points out, signing only establishes provenance, not any
interesting security properties.
I can always write a page that runs an
So there is no way for an unsigned script to exploit security holes in a
signed script?
Of course there's a way. But by the same token, there's a way a signed
script can exploit security holes in another signed script. Signing itself
doesn't establish any trust, or security.
Yup, that's
How would an unsigned script be able to exploit functionality from a
signed script if it's an either/or case - you have either all scripts
signed or no extended features? and: Think about this: a website can be
totally safe today and deliver exploits tomorrow without the user even
noticing. It
Yes - it establishes provenance and protects against unauthorized
manipulation. CSP is only as good as the content it protects. If the
content has been manipulated server side - e.g. by unauthorized access -
CSP is worthless.
Michaela
On 11/19/2014 10:03 AM, ☻Mike Samuel wrote:
Browser
Allowing this script to run may open you to all kinds of malicious attacks
by 3rd parties not associated with the party whom you're trusting.
If I give App XYZ super power to do anything, and XYZ gets
compromised/hacked then I'll be open to all sorts of attacks.
It's not an issue of party A
On Wed, Nov 19, 2014 at 4:26 AM, Michaela Merz michaela.m...@hermetos.com
wrote:
First: We need signed script code. We are doing a lot of stuff with
script - we could safely do even more, if we would be able to safely
deliver script that has some kind of a trust model.
TLS exists.
I am
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
On Wed, Nov 19, 2014 at 5:00 AM, Michaela Merz michaela.m...@hermetos.com
wrote:
If signed code would allow
special features - like true fullscreen
https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Using_full_screen_mode
or direct file access
TLS doesn't protect you against code that has been altered server side -
without the signers consent. It would alert the user, if unsigned
updates would be made available.
Ajax downloads still require a download link (with the bloburl) to be
displayed requiring an additional click. User clicks
On Wed, Nov 19, 2014 at 12:35 AM, Michaela Merz
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
Signed code doesn't protect against malicious or bad code. It only
guarantees that the code is actually from the the certificate owner
if I trust you and allow your signed script the permissions it asks for and
you can't guarantee that it would be used by some malicious 3rd party site
to hack
On Wed, Nov 19, 2014 at 6:35 AM, Michaela Merz 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
There are some models that are a bit better than trust by royalty
(app-stores) and trust by hirarchy (TLS). One of them is trust flowing
along flow limited edges in a graph (as in Advogato). This model however
isn't free from fault, as when a highly trusted entity gets compromised,
there's no
So there is no way for an unsigned script to exploit security holes in a
signed script?
Funny you mention crypto currencies as an idea to get inspiration
from...Trust but verify is detached from that... a browser can monitor
what the signed scripts are doing and if it detects a potentially
On Wed, Nov 19, 2014 at 7:54 AM, Marc Fawzi marc.fa...@gmail.com wrote:
So there is no way for an unsigned script to exploit security holes in a
signed script?
Of course there's a way. But by the same token, there's a way a signed
script can exploit security holes in another signed script.
On Tue, Nov 18, 2014 at 7:40 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/18/14, 10:26 PM, Michaela Merz wrote:
First: We need signed script code.
For what it's worth, Gecko supported this for a while. See
http://www-archive.mozilla.org/projects/security/components/signed-scripts.html.
On Tue, Nov 18, 2014 at 9:38 PM, Florian Bösch pya...@gmail.com wrote:
or direct file access
http://www.html5rocks.com/en/tutorials/file/filesystem/
This is no more direct file access than IndexedDB is. IndexedDB also
allow you to store File objects, but also doesn't allow you to access
things
25 matches
Mail list logo
