- From: Giorgio Maone <g.maone@informaction.com>
- Date: Thu, 07 Aug 2014 17:41:44 +0200
- To: Frederik Braun <fbraun@mozilla.com>, public-webappsec@w3.org
- CC: Julien Vehent <jvehent@mozilla.com>, Tarek Ziade <tziade@mozilla.com>
I can see significant intersections with ABE, too: http://noscript.net/abe ABE's grammar requires an ad-hoc parser, but is likely more human-friendly IMHO. Maybe an ABE -> EPR JSON translator could make ABE cross-browser... -- G On 06/08/2014 11:46, Frederik Braun wrote: > Hey Dave, > > This looks really valuable. > My colleagues Julien and Tarek (CCd) have experimented with the same > idea, but enforced on the server: They also use a manifest file that > looks like yours. It's called Videur and is already available on Github: > <https://github.com/mozilla/videur>. > > As far as I undersand your project focus is aiming to protect the users > from being affectd by XSS/XSRF while Videur aims to protect the server > and the webapp by defining entry points, regardless of the client. Of > course the latter approach has less request context (frames, origins, > referers...), but the upside is that a strong policy might also protect > against other typical web attacks. > > Still I think it would be worthwhile to bring the file format in > accordance with both projects. What do you tzink? > > Cheers, > Freddy > > > On 05.08.2014 20:48, David Ross wrote: >> I've been working on a project to address XSRF and reflected XSS by >> enabling web apps to regulate their entry points. >> >> Blog with more details: >> http://randomdross.blogspot.com/2014/08/entry-point-regulation-for-web-apps.html >> >> Code for a Chrome extension implementing EPR: >> https://github.com/google/epr >> >> Mike West and I have been talking about spec'ing this out with hooks for >> CSP and Fetch. It would be great to get any comments and feedback from >> the webappsec list! >> >> Dave >> >> >
Received on Thursday, 7 August 2014 15:42:12 UTC