Re: What I am missing

On Wed, Nov 19, 2014 at 04:26:48AM +0100, Michaela Merz wrote: > Second: It would be great to finally be able to accept incoming > connections. There's access to cameras and microphones - why not allow > us the ability to code servers in the browser? Maybe in combination with > my suggestion above?

Re: What I am missing

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 sig

Re: What I am missing

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

Re: What I am missing

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

Re: What I am missing

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 in

Re: What I am missing

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 va

Re: What I am missing

On Wed, Nov 19, 2014 at 4:27 PM, Michaela Merz 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/

Re: What I am missing

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, w

Re: What I am missing

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 au

Re: What I am missing

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 0

Re: What I am missing

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" wrote: > > That is relevant and also not so. Because Java applets silently grant > access to a out of sandbox functionality if s

Re: What I am missing

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 pro

Re: What I am missing

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"

Re: What I am missing

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 get

Re: What I am missing

How the browsers can be code servers? Could you please explain a little more... On 19-Nov-2014 7:51 pm, "Michaela Merz" wrote: > 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 regu

Re: What I am missing

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 ke

Re: What I am missing

On 19.11.2014 04:26, Michaela Merz 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. I am thinking about > signed JAR files - just like we did wit

Re: What I am missing

It gives you at least a sandboxed file system, which is about all you can offer without a central authority to make infallible decisions, decisions you'd pay for to get. On Wed, Nov 19, 2014 at 8:35 AM, Jonas Sicking wrote: > On Tue, Nov 18, 2014 at 9:38 PM, Florian Bösch wrote: > >> or direct

Re: What I am missing

On Tue, Nov 18, 2014 at 9:38 PM, Florian Bösch 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 like your

Re: What I am missing

On Tue, Nov 18, 2014 at 7:40 PM, Boris Zbarsky 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 > . > In pra

Re: What I am missing

On Wed, Nov 19, 2014 at 7:54 AM, Marc Fawzi 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. Signing itself doesn

Re: What I am missing

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 malic

Re: What I am missing

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 quick

Re: What I am missing

On Wed, Nov 19, 2014 at 6:35 AM, Michaela Merz 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

Re: What I am missing

<< 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 hac

Re: What I am missing

On Wed, Nov 19, 2014 at 12:35 AM, Michaela Merz 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 c

Re: What I am missing

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 do

Re: What I am missing

On Wed, Nov 19, 2014 at 5:00 AM, Michaela Merz 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 http://www.html5rocks.com/en/tutorials/file/filesystem/

Re: What I am missing

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 be

Re: What I am missing

On Wed, Nov 19, 2014 at 4:26 AM, Michaela Merz 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 thinking about > signed JA

Re: What I am missing

"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 tru

Re: What I am missing

Yes Boris - I know. As long as it doesn't have advantages for the user or the developer - why bother with it? If signed code would allow special features - like true fullscreen or direct file access - it would make sense. Signed code would make script much more resistant to manipulation and there

Re: What I am missing

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 . In practice, people didn't really use it, and it made the security mo