On Sat, Dec 10, 2011 at 2:14 AM, Anne van Kesteren ann...@opera.com wrote:
On Thu, 08 Dec 2011 23:16:37 +0100, Jonas Sicking jo...@sicking.cc
wrote:
I think Microsoft's stream proposal would address this use case.
So that would be: http://html5labs.interoperabilitybridges.com/streamsapi/
On Sun, 18 Dec 2011 13:12:57 +0100, Eric Rescorla e...@rtfm.com wrote:
Sorry, I forgot to mention the 1/n+1 splitting countermeasure in my
response.
With that said, this isn't TLS 1.1, but rather a specific, more
backwards-compatible countermeasure. It's fine for the security
considerations
On Tue, Dec 20, 2011 at 9:36 AM, Anne van Kesteren ann...@opera.com wrote:
On Sun, 18 Dec 2011 13:12:57 +0100, Eric Rescorla e...@rtfm.com wrote:
Sorry, I forgot to mention the 1/n+1 splitting countermeasure in my
response.
With that said, this isn't TLS 1.1, but rather a specific, more
On Tue, 20 Dec 2011 21:06:28 +0100, Eric Rescorla e...@rtfm.com wrote:
On Tue, Dec 20, 2011 at 9:36 AM, Anne van Kesteren ann...@opera.com
wrote:
Surely this should be patched in the base
specification rather than in every API that interacts with it. I do not
want to make the life of the guy
On Tue, Dec 20, 2011 at 12:11 PM, Anne van Kesteren ann...@opera.com wrote:
On Tue, 20 Dec 2011 21:06:28 +0100, Eric Rescorla e...@rtfm.com wrote:
On Tue, Dec 20, 2011 at 9:36 AM, Anne van Kesteren ann...@opera.com
wrote:
Surely this should be patched in the base
specification rather than
On Tue, 20 Dec 2011 22:55:40 +0100, Eric Rescorla e...@rtfm.com wrote:
That isn't to say that the browser stacks aren't adding 1/n+1
splitting. NSS, for instance, has such a fix. However, I don't think
there's anything to do from a TLS standards perspective.
What I would like is a standard
On Tue, Dec 20, 2011 at 2:47 PM, Anne van Kesteren ann...@opera.com wrote:
On Tue, 20 Dec 2011 22:55:40 +0100, Eric Rescorla e...@rtfm.com wrote:
That isn't to say that the browser stacks aren't adding 1/n+1
splitting. NSS, for instance, has such a fix. However, I don't think
there's anything
On Sat, Dec 17, 2011 at 6:11 AM, Anne van Kesteren ann...@opera.com wrote:
On Fri, 09 Dec 2011 19:54:31 +0100, Eric Rescorla e...@rtfm.com wrote:
Unfortunately, many servers do not support TLS 1.1, and to make matters
worse, they do so in a way that is not securely verifiable. By which I
mean
On Fri, 09 Dec 2011 19:54:31 +0100, Eric Rescorla e...@rtfm.com wrote:
Unfortunately, many servers do not support TLS 1.1, and to make matters
worse, they do so in a way that is not securely verifiable. By which I
mean that an active attacker can force a client/server pair both of
which
On Sat, Dec 17, 2011 at 6:11 AM, Anne van Kesteren ann...@opera.com wrote:
On Fri, 09 Dec 2011 19:54:31 +0100, Eric Rescorla e...@rtfm.com wrote:
Unfortunately, many servers do not support TLS 1.1, and to make matters
worse, they do so in a way that is not securely verifiable. By which I
mean
-Original Message-
From: Anne van Kesteren [mailto:ann...@opera.com]
Sent: Friday, December 09, 2011 5:15 AM
To: Wenbo Zhu; Jonas Sicking; Robert O'Callahan; Feras Moussa
Cc: WebApps WG
Subject: Re: [XHR] chunked requests
On Thu, 08 Dec 2011 23:16:37 +0100, Jonas Sicking jo
On Wed, 14 Dec 2011 20:17:01 +0100, Feras Moussa fer...@microsoft.com
wrote:
We've only recently uploaded the draft for the Streams API and shared it
with the Working Group [1], which also has the new location.
There is a conversation currently taking place in the media capture WG
[2]
On Thu, Dec 8, 2011 at 2:36 PM, Charles Pritchard ch...@jumis.com wrote:
On Dec 8, 2011, at 1:04 PM, Wenbo Zhu wen...@google.com wrote:
On Wed, Dec 7, 2011 at 6:04 PM, Charles Pritchard ch...@jumis.com
ch...@jumis.com wrote:
**
I think the Web Sockets spec is intended for client to
On Fri, 09 Dec 2011 02:13:50 +0100, Eric Rescorla e...@rtfm.com wrote:
On Thu, Dec 8, 2011 at 5:07 PM, Adam Barth w...@adambarth.com wrote:
Whatever spec we end up going with should note in its security
consideration that the user agent must implement TLS 1.2 or greater to
avoid this attack.
On Thu, 08 Dec 2011 23:16:37 +0100, Jonas Sicking jo...@sicking.cc wrote:
I think Microsoft's stream proposal would address this use case.
So that would be: http://html5labs.interoperabilitybridges.com/streamsapi/
How does that relate to the various APIs for streaming media?
(I added roc and
On Fri, Dec 9, 2011 at 4:59 AM, Anne van Kesteren ann...@opera.com wrote:
On Fri, 09 Dec 2011 02:13:50 +0100, Eric Rescorla e...@rtfm.com wrote:
On Thu, Dec 8, 2011 at 5:07 PM, Adam Barth w...@adambarth.com wrote:
Whatever spec we end up going with should note in its security
consideration
On Fri, 09 Dec 2011 16:33:08 +0100, Eric Rescorla e...@rtfm.com wrote:
On Fri, Dec 9, 2011 at 4:59 AM, Anne van Kesteren ann...@opera.com
wrote:
Are you saying that if responseType is set to stream and the server
only supports TLS 1.0 the connection should fail, but if it is greater
than
On Fri, Dec 9, 2011 at 7:59 AM, Anne van Kesteren ann...@opera.com wrote:
On Fri, 09 Dec 2011 16:33:08 +0100, Eric Rescorla e...@rtfm.com wrote:
On Fri, Dec 9, 2011 at 4:59 AM, Anne van Kesteren ann...@opera.com
wrote:
Are you saying that if responseType is set to stream and the server
only
On Fri, Dec 9, 2011 at 10:37 AM, Adam Barth w...@adambarth.com wrote:
On Fri, Dec 9, 2011 at 7:59 AM, Anne van Kesteren ann...@opera.com wrote:
On Fri, 09 Dec 2011 16:33:08 +0100, Eric Rescorla e...@rtfm.com wrote:
Same-origin requests should be OK because the JS would have access
to the
On Dec 8, 2011, at 1:04 PM, Wenbo Zhu wen...@google.com wrote:
On Wed, Dec 7, 2011 at 6:04 PM, Charles Pritchard ch...@jumis.com wrote:
I think the Web Sockets spec is intended for client to server sessions like
this.
WebSocket protocol isn't yet well-supported by proxies. Besides,
Keep in mind that streamed or chunked uploads will expose the ability
to exploit the BEAST vulnerability in SSL:
http://www.educatedguesswork.org/2011/09/security_impact_of_the_rizzodu.html
Whatever spec we end up going with should note in its security
consideration that the user agent must
On Thu, Dec 8, 2011 at 5:07 PM, Adam Barth w...@adambarth.com wrote:
Keep in mind that streamed or chunked uploads will expose the ability
to exploit the BEAST vulnerability in SSL:
http://www.educatedguesswork.org/2011/09/security_impact_of_the_rizzodu.html
Right. Specifically, it needs to
One use case that we have which is not currently handled by XMLHttpRequest
is incrementally sending data that takes a long time to generate _from the
client to the server_. For example, if we were to record data from a
microphone, we couldn't upload it in real time to the server with the
current
23 matches
Mail list logo