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
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?
+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,
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
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
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
* 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
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
* 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
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
10 matches
Mail list logo