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?
On Tue, Feb 17, 2015 at 2:43 PM, Bjoern Hoehrmann wrote:
> * Anne van Kesteren wrote:
> >On Tue, Feb 17, 2015 at 8:18 PM, Bjoern Hoehrmann
> wrote:
> >> Individual resources should not be able to declare policy for the whole
> >> server, ...
> >
> >With HSTS we gave up on that.
>
>
FWIW, this dy
* Anne van Kesteren wrote:
>On Tue, Feb 17, 2015 at 8:18 PM, Bjoern Hoehrmann 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 to add
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.
ar
+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,
On Tue, Feb 17, 2015 at 8:18 PM, Bjoern Hoehrmann 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 the whole se
* 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
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
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 [1
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 in
10 matches
Mail list logo