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: CfC: publish WG Note of UI Events; deadline November 14

+1 On 19-Nov-2014 8:07 pm, "Anne van Kesteren" wrote: > On Wed, Nov 19, 2014 at 3:20 PM, Arthur Barstow > wrote: > > Although there appears to be agreement that work on the [uievents] spec > > should stop, the various replies raise sufficient questions that I > consider > > this CfC (as written)

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: CfC: publish WG Note of UI Events; deadline November 14

On 11/19/14 9:35 AM, Anne van Kesteren wrote: On Wed, Nov 19, 2014 at 3:20 PM, Arthur Barstow wrote: Although there appears to be agreement that work on the [uievents] spec should stop, the various replies raise sufficient questions that I consider this CfC (as written) as failed. Travis, Gary

Re: CfC: publish WG Note of UI Events; deadline November 14

On Wed, Nov 19, 2014 at 3:20 PM, Arthur Barstow wrote: > Although there appears to be agreement that work on the [uievents] spec > should stop, the various replies raise sufficient questions that I consider > this CfC (as written) as failed. > > Travis, Gary - would you please make a specific prop

Re: CfC: publish WG Note of UI Events; deadline November 14

On 11/7/14 10:28 AM, Arthur Barstow wrote: During WebApps' October 27 meeting, the participants agreed to stop work on the UI Events spec and to publish it as a WG Note (see [Mins]). As such, this is a formal Call for Consensus (CfC) to: a) Stop work on this spec b) Publish a "gutted" WG Note

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

[Bug 27366] New: Define how shadow DOM should be handled when host is adopted to a new document

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27366 Bug ID: 27366 Summary: Define how shadow DOM should be handled when host is adopted to a new document Product: WebAppsWG Version: unspecified Hardware: PC

[Bug 24338] Spec should have Fetch for Blob URLs

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24338 Anne changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED

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