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

[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?

Or should this disparate community rather standardize on U2F?

Another solution (IMO "workaround") is using local services supplying "Security 
Services" through Redirects, XHR or WebSockets.

Since the (in)famous plugins were simply removed without any thoughts of the 
implications, it seems that the browser vendors currently "own" this question.

Anders

Re: CORS performance

[Eric Mill]

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 dynamic is why you can't set HSTS on an S3 bucket (or a
CloudFront distribution backed by an S3 bucket). Amazon isn't willing to
let you set a HSTS header for a file that might also be served at
s3.amazonaws.com. And so any website backed by S3, even if you never use
the s3.amazonaws.com URLs, is restricted from setting HSTS headers.

-- Eric

-- 
konklone.com | @konklone 

Re: CORS performance

[Bjoern Hoehrmann]

* 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 communication options. I don't think you can compare
them like that. HSTS is more like a redirect and misconfiguration may
result in denial of service, while CORS misconfiguration can have more
far-reaching consequences like exposing user information.
-- 
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de
 Available for hire in Berlin (early 2015)  · http://www.websitedev.de/ 

Re: CORS performance

[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 somewhat self-verifying (e.g. an https pin cannot be applied over http,
and a public key pin cannot be applied from a certificate without a
matching key) and unlikely to change.

For more complex, application-layer issues, are pinning headers really the
best and most manageable approach?

I think it is at least worth discussing the relative merits of using a
resource published under /.well-known for such use cases, vs. sending
"pinned" headers with every single resource.

Some of the things that argue against /.well-known are:

1) Added latency of fetching the resource.

For CORS pinning, this probably isn't an issue.  A client that has never
seen a pinned policy (by whatever mechanism it is delivered) will always
have to make a preflight, and servers will always have to respond
appropriately (rather than relying on the pinned policy) for legacy
clients.  So a client that knows about pinning can make a request to
/.well-known in parallel the first time it makes a CORS request to a given
host, and speed up all subsequent requests without any additional latency
on the first.

2) Clients hammering servers for non-existent /.well-known resources (the
favicon issue)

Again, probably not an issue for CORS, or not nearly as large an issue.
Clients can be configured to never ask for the CORS policy at an origin
unless/until they make a CORS request to that origin.  There is a question
of how long to treat a 404 as authoritative before re-polling, but it can
be fairly long without breaking anything.  We might also devise a "hint"
header that suggests a pinned policy is available, which would only be sent
along with preflight responses.


On disadvantages of headers:

1) Individual resources declaring policy for an entire origin can be
problematic and difficult to manage.

Doing this right, both to set a correct policy and police lower-privileged
resources from setting incorrect ones, in practice would require an
administrator to set up a filtering proxy in front of the entire origin,
which is more difficult and costly than simply locking down access to a
specific resource path to only administrators.

2) Lots of redundant chit-chat.

HTTP/2 header compression reduces the impact of this somewhat, and CORS
specifically could avoid sending pinning headers except on preflight
responses, but it does seem like a real concern.  How much long-term bloat
are we willing to accept on the network in order to save a few ms of
latency the first time you connect to a site?

-Brad



On Tue Feb 17 2015 at 10:42:20 AM Anne van Kesteren 
wrote:

> 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 distinct URL.
>
> 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 announce that it can handle CORS. We made it rather tricky
> to avoid footgun scenarios, but I'm wondering whether that is still
> the right tradeoff.
>
> Something like:
>
>   CORS: max-age=31415926; allow-origin=*; allow-credentials=true;
> allow-headers=*; allow-methods=*; expose-headers=*
>
>
> --
> https://annevankesteren.nl/
>
>

Re: CORS performance

[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, 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.
>
>
>> HTTP/1.1 rather has `OPTIONS *` for that, which would require a
>> new kind of "preflight" request. And if the whole server is fine with
>> cross-origin requests, I am not sure there is much of a point trying to
>> lock it down by restricting request headers or methods.
>
> Yeah, I wasn't sure whether those should all be listed. Maybe simply
> declaring you're fluent in CORS in a unique way is sufficient.
>
>
> --
> https://annevankesteren.nl/
>

Re: CORS performance

[Anne van Kesteren]

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 server is fine with
> cross-origin requests, I am not sure there is much of a point trying to
> lock it down by restricting request headers or methods.

Yeah, I wasn't sure whether those should all be listed. Maybe simply
declaring you're fluent in CORS in a unique way is sufficient.


-- 
https://annevankesteren.nl/

Re: CORS performance

[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 announce that it can handle CORS. We made it rather tricky
>to avoid footgun scenarios, but I'm wondering whether that is still
>the right tradeoff.
>
>Something like:
>
>  CORS: max-age=31415926; allow-origin=*; allow-credentials=true;
>allow-headers=*; allow-methods=*; expose-headers=*

Individual resources should not be able to declare policy for the whole
server, HTTP/1.1 rather has `OPTIONS *` for that, which would require a
new kind of "pre-flight" request. And if the whole server is fine with
cross-origin requests, I am not sure there is much of a point trying to
lock it down by restricting request headers or methods. I suppose some-
thing like this could be implemented, but I don't think "CORS pinning"
is quite the right analogy.
-- 
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de
 Available for hire in Berlin (early 2015)  · http://www.websitedev.de/ 

CORS performance

[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 distinct URL.

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 announce that it can handle CORS. We made it rather tricky
to avoid footgun scenarios, but I'm wondering whether that is still
the right tradeoff.

Something like:

  CORS: max-age=31415926; allow-origin=*; allow-credentials=true;
allow-headers=*; allow-methods=*; expose-headers=*


-- 
https://annevankesteren.nl/

Updated: Running trusted code in the untrusted web

[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 [1],
here is a writeup of how you could run trusted web-code inside of a untrusted 
web-application.

Regarding the use-cases, there are many ranging from phone-dialers on support 
pages to payments [2].

Since you probably do not want to rewrite browsers from scratch, the most 
logical
is building on running trusted code in IFRAMEs so that the existing protection 
scheme
can be reused.   The difference with existing IFRAMEs is that the code must be 
trusted
by the platform which also means that it must be fetched from the platform:



This code should appear to the browser as coming from a virtual domain.
The only communication possible is through postMessage().

If the referenced application isn't available in the local cache, the browser 
should presumably
consult the device-specific "AppStore".

A side-effect of this "specification" is that trusted web-applications may be 
device-specific which
actually is a plus since it reduces the need to standardize access to the OS 
and HW layer.

That is, there could be a new class of standardized trusted web-applications 
where only
the invoke/postMessage part is standardized!

Cheers,
Anders Rundgren

1] https://lists.w3.org/Archives/Public/public-web-intents/2015Feb/.html

2] Although not entirely compliant with the above, the following demo
https://mobilepki.org/WebCryptoPlusPlus
does the same thing from a user's perfective.

Is clearUndo() in UndoManager the wrong way round?

[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 increments whenever we undo, I would think that position 
should be set to the undo stack's length - 1.


Simon