[Bug 15127] Please don't use section numbers as these tend to change rapidly and make your feedback harder to understand.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15127 Michael[tm] Smith m...@w3.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: [XHR] chunked requests
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. I believe it's actually TLS 1.1, since the relevant feature is explicit IVs. Or you could allow RC4, I guess. 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 that it is okay? Same-origin requests are always okay? (Though it seems we should just require TLS 1.1 there too then to not make matters too confusing.) -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] chunked requests
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 Feras Moussa.) -- Anne van Kesteren http://annevankesteren.nl/
[Bug 15129] New: Vxvzvxvjbcb vs avatars Bdhzgzgagdffgx Vvgbv bb Gvvcn. Bcc cf hghvhhcygfg fscsssxaxsszzxcxs Gets es Gvvfvbvfamtsf
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15129 Summary: Vxvzvxvjbcb vs avatars Bdhzgzgagdffgx Vvgbv bb Gvvcn. Bcc cf hghvhhcygfg fscsssxaxsszzxcxs Gets es Gvvfvbvfamtsf Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#top OS/Version: other Status: NEW Severity: normal Priority: P3 Component: WebSocket API (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Specification: http://www.w3.org/TR/2011/CR-websockets-20111208/ Multipage: http://www.whatwg.org/C#top Complete: http://www.whatwg.org/c#top Comment: Vxvzvxvjbcb vs avatars Bdhzgzgagdffgx Vvgbv bb Gvvcn. Bcc cf hghvhhcygfg fscsssxaxsszzxcxs Gets es Gvvfvbvfamtsf Posted from: 113.210.98.86 User agent: Mozilla/5.0 (iPad; U; CPU OS 4_3_1 like Mac OS X; en-us) AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2 Mobile/8G4 Safari/6533.18.5 -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 15129] Vxvzvxvjbcb vs avatars Bdhzgzgagdffgx Vvgbv bb Gvvcn. Bcc cf hghvhhcygfg fscsssxaxsszzxcxs Gets es Gvvfvbvfamtsf
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15129 Art Barstow art.bars...@nokia.com changed: What|Removed |Added Status|NEW |RESOLVED CC||art.bars...@nokia.com Resolution||INVALID -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: [XHR] chunked requests
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 that the user agent must implement TLS 1.2 or greater to avoid this attack. I believe it's actually TLS 1.1, since the relevant feature is explicit IVs. Or you could allow RC4, I guess. 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 that it is okay? I'm not sure I understand this feature well enough. The issue is streaming content from the client, not from the server, and in particular the ability of the JS to provide additional content to be sent after the data has started to be transmitted. As for what should happen in this setting if the negotiated TLS version is 1.0, I could imagine a number of possibilities, including: 1. The client refuses to send 2. There is a pre-flight and the server has to explicitly accept. 3. There is a big nasty warning. 4. We just warn people in the spec and hope they do something sensible Same-origin requests are always okay? (Though it seems we should just require TLS 1.1 there too then to not make matters too confusing.) Same-origin requests should be OK because the JS would have access to the relevant sensitive data in any case. -Ekr
Re: [XHR] chunked requests
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 that it is okay? I'm not sure I understand this feature well enough. The issue is streaming content from the client, not from the server, and in particular the ability of the JS to provide additional content to be sent after the data has started to be transmitted. My bad. I meant send(Stream) which would indeed allow for that. As for what should happen in this setting if the negotiated TLS version is 1.0, I could imagine a number of possibilities, including: 1. The client refuses to send 2. There is a pre-flight and the server has to explicitly accept. 3. There is a big nasty warning. 4. We just warn people in the spec and hope they do something sensible Okay. I think I would very much prefer 1 here. Same-origin requests are always okay? (Though it seems we should just require TLS 1.1 there too then to not make matters too confusing.) Same-origin requests should be OK because the JS would have access to the relevant sensitive data in any case. Okay, I guess we can make that difference. Thanks, -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] chunked requests
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 supports TLS 1.0 the connection should fail, but if it is greater than that it is okay? I'm not sure I understand this feature well enough. The issue is streaming content from the client, not from the server, and in particular the ability of the JS to provide additional content to be sent after the data has started to be transmitted. My bad. I meant send(Stream) which would indeed allow for that. As for what should happen in this setting if the negotiated TLS version is 1.0, I could imagine a number of possibilities, including: 1. The client refuses to send 2. There is a pre-flight and the server has to explicitly accept. 3. There is a big nasty warning. 4. We just warn people in the spec and hope they do something sensible Okay. I think I would very much prefer 1 here. Same-origin requests are always okay? (Though it seems we should just require TLS 1.1 there too then to not make matters too confusing.) Same-origin requests should be OK because the JS would have access to the relevant sensitive data in any case. Okay, I guess we can make that difference. Correct me if I'm wrong, but I believe these issues are fixed in TLS 1.1. Most user agents implement TLS 1.1 anyway, so this seems mostly like a requirement to put in the security considerations section. Adam
Web IDL sequenceT and item() method
Hi Cameron, Does the ECMAScript binding for the IDL sequenceT type imply the existence of an item() method as a element accessor, where an element is a property whose property name is an array index? If so, then could describe how it is implied? The reason I ask is because I'm wondering about compatibility with earlier DOM specs, e.g., NodeList, CSSRuleList, etc., where an explicit item() method is defined, and which, in recent newer specifications based on Web IDL, has been re-expressed in terms of sequenceT. In my review of ECMA 262 3rd and 5th editions, I don't see an explicit mention of an item() method on Array objects (or their prototype), which are the ECMAScript binding for IDL sequenceT. If the answer is that no item() method is implied, then does the use of sequenceT in these newer specs entail dropping this method (with respect to prior DOM specs)? Regards, Glenn
Re: [XHR] chunked requests
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 relevant sensitive data in any case. Okay, I guess we can make that difference. Correct me if I'm wrong, but I believe these issues are fixed in TLS 1.1. Most user agents implement TLS 1.1 anyway, so this seems mostly like a requirement to put in the security considerations section. Would that it were this easy. 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 support TLS 1.1 down to TLS 1.0. This may be detectable in some way, but not by TLS's built-in mechanisms. And since the threat model here is an active attacker, this is a problem. -Ekr
[Bug 15104] In reply to: p class=warningFollowing HTTP procedures here could introduce serious security problems in a Web browser context. For example, consider a host with a WebSocket s
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15104 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@hixie.ch Resolution||WONTFIX --- Comment #1 from Ian 'Hixie' Hickson i...@hixie.ch 2011-12-09 23:09:50 UTC --- We can't expose error information (at least, not cross-origin), as that would leak information about servers that have not opted-in. -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 15134] New: Please explain what the proper behavior of getSelection on a display:none iframe is
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15134 Summary: Please explain what the proper behavior of getSelection on a display:none iframe is Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: HTML Editing APIs AssignedTo: a...@aryeh.name ReportedBy: e...@webkit.org QAContact: sideshowbarker+html-editing-...@gmail.com CC: m...@w3.org, public-webapps@w3.org Please explain what the proper behavior of getSelection on a display:none iframe is See: https://bugzilla.mozilla.org/show_bug.cgi?id=585229 https://bugs.webkit.org/show_bug.cgi?id=43655 -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
