Re: CORS performance

2015-02-17 Thread Eric Mill
On Tue, Feb 17, 2015 at 2:43 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote: * Anne van Kesteren wrote: On Tue, Feb 17, 2015 at 8:18 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote: Individual resources should not be able to declare policy for the whole server, ... With HSTS we gave up on

[WebCrypto.Next] Any ideas on how to proceed?

2015-02-17 Thread Anders Rundgren
As you probably noted, all proposals related to http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/ were shot down. Are we waiting on something, and if so is the case, exactly what? Is the idea of building on an already semi-established solution like Chrome Native Messaging unacceptable?

Re: CORS performance

2015-02-17 Thread Devdatta Akhawe
+1 to Anne's suggestion. The current design is pretty terrible for API performance. I think a request to / with OPTIONS or something, with a response that requires some server side logic (like return the random number UA just sent) is pretty darn secure. cheers dev On 17 February 2015 at 11:24,

Updated: Running trusted code in the untrusted web

2015-02-17 Thread Anders Rundgren
Although I still prefer native messaging, here is a more complete proposal for a webish solution: http://webpki.org/papers/trusted-web-apps.pdf Anders On 2015-02-17 06:32, Anders Rundgren wrote: For those who frown at the idea of calling native (trusted) applications from the untrusted web

CORS performance

2015-02-17 Thread Anne van Kesteren
Concerns raised by Monsur https://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0260.html and others before him are still valid. When you have an HTTP API on another origin you effectively get a huge performance penalty. Even with caching of preflights, as each fetch is likely to go to a

Re: CORS performance

2015-02-17 Thread Brad Hill
On both this, and CSP pinning, I find myself getting nervous about adding an increasing number of headers which, when sent by any resource, impact the security posture and functioning of an entire origin. HSTS and HPKP are somewhat special in that: they convey only a few bits of information. are

Re: CORS performance

2015-02-17 Thread Bjoern Hoehrmann
* Anne van Kesteren wrote: With the recent introduction of CSP pinning, I was wondering whether something like CORS pinning would be feasible. A way for a server to declare that it speaks CORS across an entire origin. The CORS preflight in effect is a rather complicated way for the server to

Re: CORS performance

2015-02-17 Thread Anne van Kesteren
On Tue, Feb 17, 2015 at 8:18 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote: Individual resources should not be able to declare policy for the whole server, ... With HSTS we gave up on that. HTTP/1.1 rather has `OPTIONS *` for that, which would require a new kind of preflight request. And if

Re: CORS performance

2015-02-17 Thread Bjoern Hoehrmann
* Anne van Kesteren wrote: On Tue, Feb 17, 2015 at 8:18 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote: Individual resources should not be able to declare policy for the whole server, ... With HSTS we gave up on that. Well, HSTS essentially removes communication options, while the intent of CORS

Is clearUndo() in UndoManager the wrong way round?

2015-02-17 Thread Simon
I'm implementing a partial version of UndoManager myself, as I see it to be rather useful. I'm interpreting clearUndo as clearing any undo actions, so Ctrl+z will not do anything anymore. The spec states that clearUndo resets the position to 0, but is this the wrong way round? Since position