Re: [whatwg] Stream API Feedback
On 2011-03-17 04:22, Robert O'Callahan wrote: On Thu, Mar 17, 2011 at 4:36 AM, Lachlan Huntlachlan.h...@lachy.id.auwrote: I'm not entirely sure I understand your proposal, but are you suggesting that the input streams from the camera/microphone would first go tovideo andaudio elements, allowing the existing HTMLMediaElement API on those elements to be used to control those streams, the output of which can then be encoded and recorded to a file or streamed remotely? Yes. In fact, of all the properties that are on HTMLMediaElement, the only ones that seem to have any real use for streaming media are volume, muted, paused and ended. So I'm not convinced that it's a good idea to try and reuse existing APIs simple for the sake of reusing them, when they aren't really a good fit. As Olli said,video andaudio are designed to support streaming media; streaming over a low-latency network is very much like streaming from a local device. Yes, for playback, that's fine, and that's what we've already implemented in our experimental implementation of the device element. But you seemed to be suggesting that it was sufficient for the purposes of controlling and encoding the video stream, despite the fact that those controls are not at all suited to that. Such control needs to occur before the video element in the chain, not after it. -- --- --- | Camera | -- | GeneratedStream | --+--- | video | -- --- | --- | - - | Codec | -- | Recorded blob | - - | | -- +--- | PeerConnection | -- The stated of the stream, in terms of what gets streamed over P2P or recorded locally, must be controlled at the GeneratedStream and given as input into the codec. This includes things like controlling the input microphone volume, video height and width, etc. In particular, the encoded height and width for streaming may differ significantly from the rendered height and width in the local video preview, so this is not something that can be controlled by the video element itself. In Gecko, we allow seeking within cached segements of streamed video, and we could easily allow that for local devices too --- user-controlled instant replay. We don't buffer any streamed data in our initial device implementation and seeking is not possible. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Stream API Feedback
On Thu, 17 Mar 2011 16:48:40 +0100, Olli Pettay olli.pet...@helsinki.fi
wrote:
On 03/17/2011 03:11 PM, Lachlan Hunt wrote:
On 2011-03-16 19:29, Olli Pettay wrote:
Perhaps navigator.getUserMedia(audio,video, success, error);
could return an url to the device in the success callback, and that url
could be then set to video.src.
The creation of a URL is unnecessary indirection. It's easier to avoid
creating special URLs entirely, and instead assign the the Stream object
directly to video.src.
The type of .src is string.
Assigning a different type of object to it
is quite strange.
Also, if getUserMedia would return just an URL, browser wouldn't need
to create any stream object (unless someone then want to stream
from video to PeerConnection).
Sure, but instead one would have to mint URLs and keep a mapping between
those URLs and the streams that they actually represent. If people copy
those URLs around, how long are they supposed to work for? Consider this
scenario:
function getStreamURL() {
var s;
// code that sets s to a new Stream object for the default camera or
something
return s.url;
}
var url = getStreamURL();
/* garbage collector? */
document.querySelector('video').src = url;
Does this break randomly depending on when the garbage collector runs, or
is the returned string somehow magical so that it actually keeps the
stream alive?
... src property definition needs to be changed
from DOMString to any.
That would be strange and make API inconsistent with img and iframe
for example.
video is already very different to img and iframe in that it also
has child source elements and a currentSrc attribute. What's the
practical harm in allowing video.src setter take an object?
--
Philip Jägenstedt
Core Developer
Opera Software
Re: [whatwg] Stream API Feedback
On 03/17/2011 06:31 PM, Philip Jägenstedt wrote:
On Thu, 17 Mar 2011 16:48:40 +0100, Olli Pettay
olli.pet...@helsinki.fi wrote:
On 03/17/2011 03:11 PM, Lachlan Hunt wrote:
On 2011-03-16 19:29, Olli Pettay wrote:
Perhaps navigator.getUserMedia(audio,video, success, error);
could return an url to the device in the success callback, and that url
could be then set to video.src.
The creation of a URL is unnecessary indirection. It's easier to avoid
creating special URLs entirely, and instead assign the the Stream object
directly to video.src.
The type of .src is string.
Assigning a different type of object to it
is quite strange.
Also, if getUserMedia would return just an URL, browser wouldn't need
to create any stream object (unless someone then want to stream
from video to PeerConnection).
Sure, but instead one would have to mint URLs and keep a mapping between
those URLs and the streams that they actually represent. If people copy
those URLs around, how long are they supposed to work for? Consider this
scenario:
function getStreamURL() {
var s;
// code that sets s to a new Stream object for the default camera or
something
return s.url;
}
var url = getStreamURL();
/* garbage collector? */
document.querySelector('video').src = url;
I'd assume stream url would be handled like
urls created using createObjectURL.
It could be then revoked.
Does this break randomly depending on when the garbage collector runs,
or is the returned string somehow magical so that it actually keeps the
stream alive?
... src property definition needs to be changed
from DOMString to any.
That would be strange and make API inconsistent with img and
iframe for example.
video is already very different to img and iframe in that it also
has child source elements and a currentSrc attribute. What's the
practical harm in allowing video.src setter take an object?
API inconsistency.
Re: [whatwg] Stream API Feedback
On 2011-03-17 16:48, Olli Pettay wrote:
... src property definition needs to be changed
from DOMString to any.
That would be strange and make API inconsistent with img and iframe
for example.
This is getting a bit off topic, but it would be better if they were
also modified so that authors could, instead of doing this:
var file = document.getElementById('file').files[0];
if(file){
blobURLref = window.URL.createObjectURL(file);
myimg.src = blobURLref;
}
(Example from File API spec [1])
Do this:
var file = document.getElementById('file').files[0];
if (file) img.src = file;
The creation of a URL is just an unnecessary step for an issue that can
be handled internally by the browser, and suffers from the problems that
Philip pointed out. Besides, this was all discussed in the WebApps WG
some time ago [2].
[1] http://dev.w3.org/2006/webapi/FileAPI/#dfn-createObjectURL
[2] http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0169.html
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: [whatwg] Stream API Feedback
On 03/17/2011 07:41 PM, Lachlan Hunt wrote:
On 2011-03-17 16:48, Olli Pettay wrote:
... src property definition needs to be changed
from DOMString to any.
That would be strange and make API inconsistent with img and iframe
for example.
This is getting a bit off topic, but it would be better if they were
also modified so that authors could, instead of doing this:
var file = document.getElementById('file').files[0];
if(file){
blobURLref = window.URL.createObjectURL(file);
myimg.src = blobURLref;
}
(Example from File API spec [1])
Do this:
var file = document.getElementById('file').files[0];
if (file) img.src = file;
The creation of a URL is just an unnecessary step for an issue that can
be handled internally by the browser, and suffers from the problems that
Philip pointed out. Besides, this was all discussed in the WebApps WG
some time ago [2].
Ok, some kind of DOMURL would make sense.
Perhaps getStreamURL could return that kind of url.
The object wouldn't need to be a stream.
I need to write some pseudo-js code to figure out how this all
could work.
[1] http://dev.w3.org/2006/webapi/FileAPI/#dfn-createObjectURL
[2] http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0169.html
Re: [whatwg] Stream API Feedback
On Thu, 17 Mar 2011 17:51:08 +0100, Olli Pettay olli.pet...@helsinki.fi
wrote:
On 03/17/2011 06:31 PM, Philip Jägenstedt wrote:
On Thu, 17 Mar 2011 16:48:40 +0100, Olli Pettay
olli.pet...@helsinki.fi wrote:
On 03/17/2011 03:11 PM, Lachlan Hunt wrote:
On 2011-03-16 19:29, Olli Pettay wrote:
Perhaps navigator.getUserMedia(audio,video, success, error);
could return an url to the device in the success callback, and that
url
could be then set to video.src.
The creation of a URL is unnecessary indirection. It's easier to avoid
creating special URLs entirely, and instead assign the the Stream
object
directly to video.src.
The type of .src is string.
Assigning a different type of object to it
is quite strange.
Also, if getUserMedia would return just an URL, browser wouldn't need
to create any stream object (unless someone then want to stream
from video to PeerConnection).
Sure, but instead one would have to mint URLs and keep a mapping between
those URLs and the streams that they actually represent. If people copy
those URLs around, how long are they supposed to work for? Consider this
scenario:
function getStreamURL() {
var s;
// code that sets s to a new Stream object for the default camera or
something
return s.url;
}
var url = getStreamURL();
/* garbage collector? */
document.querySelector('video').src = url;
I'd assume stream url would be handled like
urls created using createObjectURL.
It could be then revoked.
I wasn't aware of this API, it's in
http://www.w3.org/TR/FileAPI/#dfn-createObjectURL for reference.
That API has an explicit revokeObjectURL to solve the lifetime issue, but
there's no such thing for the Stream API.
--
Philip Jägenstedt
Core Developer
Opera Software
[whatwg] PeerConnection: encryption feedback
PeerConnection defines packet encryption, but it uses AES-128-CTR without actually defining the counter. It also generates a new AES key for each packet. A major point of using CTR is to not have to do that; you have a single key and vary the counter. The inputs to AES-128-CTR are a key, a counter and a message. A single key is used for the whole connection[1]. Each counter value can only be used once. A nonce isn't created for each packet; only once for the entire connection, as part of the key. A hash should also be included in each packet, to prevent semi-random tampering with packets on the wire. The mechanism I'd recommend is: * The encryption key for the connection is negotiated over the signalling connection, defined as the HMAC-SHA1 of the concatenation of the media stream key and a random 16-byte PeerConnection-wide nonce. * Each PeerConnection has an associated 48-bit counter value[2], which starts at 0. * To transmit a data packet to a peer, do the following: 1: Let connection-key be the value of the PeerConnection's encryption key. 2: Let packet-counter be the value of the PeerConnection's counter. 3: Increment PeerConnection's counter value by 1. 4: Let signature be the HMAC-SHA1 of the raw message. 5: Let signed raw message be the concatenation of signature and raw message. 6: Let masked message be the result of encrypting signed raw message using AES-128-CTR, with a key of connection-key and a counter value of packet-counter. This is 6 bytes larger than the current packet: a 20-byte hash and a 6-byte counter, replacing the 00 00 00 01 magic and the 16-byte random block. It prevents packet tampering and replay. On receiving a packet, the HMAC-SHA1 must be checked (replacing the 00 00 00 01 check), and the counter value must be checked to prevent replay and excessively delayed packets. See RFC 4347 sections 3.3 (Replay Detection) and 4.1.2.5 (Anti-replay) for an algorithm to do this. In short, you keep track of which counter values have been seen recently, reject repeated counters, and reject counter values which are too old. The magic PeerConnection salt (DB 68 B5 FD 17 0E 15 77 56 AF 7A 3A 1A 57 75 02) seems unnecessary, replaced with the connection nonce, but could still be appended to the connection key if desired. There should also be a mechanism to support new hashes and ciphers in the future. There's no need to actually specify other hashes at this point (except perhaps for testing purposes), just forward-compatibility for when AES and/or SHA-1 need to be replaced. This protocol is reinventing the wheel, and I'm sure a cryptography expert will find many more issues. Can anyone more familiar with DTLS say whether it fits here? In particular, it's important to note that users don't have signed SSL certificates; only webservers have those, in practice. Peers can't safely establish a connection to each other directly: they depend on their mutual trust of the webserver, sending the connection key over the trusted signalling channel to prevent MITM attacks between peers. I don't know if TLS can support that model, or if there are other problems with it (eg. too much packet overhead for UDP?). [1] Assuming no mechanism exists to negotiate nonce changes for long-lived connections. [2] 48 bits matches DTLS. This is big enough to avoid problems with long-lived connections, but not so big as to waste space in the packet. -- Glenn Maynard
Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification
I just rewrote the spec, and it's now both shorter and produces better results. For a quick view of the results, as compared to the browser you're currently using, you can look here: http://aryeh.name/spec/editcommands/autoimplementation.html That link isn't stable, and will change and possibly break as I edit it, but it will probably work fine. Each table row gives the input (with the selection marked by brackets), the output of the spec's algorithm as implemented on top of the browser (which might not be quite correct due to browser bugs), and the output of the browser's native execCommand(), all for running the command bold. Everything is given in both rendered and source form. I've looked over all the results of that table in both Chrome and Firefox, and every nontrivial difference I've found between the spec and browsers boils down to one of * The browser's results are visibly wrong (text is bold when it shouldn't be or isn't when it should be) * The browser's markup is more verbose * The browser mangles the markup's semantics (like breaking apart an element with an id, so that things that were previously contained in that id no longer are) * In one case, WebKit normalizes markup more aggressively than the spec does, so it winds up being shorter and still correct, but only because the spec ignored ancestors beyond what it had to modify; I'm ambivalent about this one * In one case, the spec adds b around a single space, while WebKit doesn't; I'm inclined to say this is a WebKit bug (which also occurs in my spec implementation as viewed in WebKit, but not Firefox, since WebKit mangles ranges when you add them to a selection; I plan to change my implementation to work around that) I hope this addresses many of Ryosuke's objections to my previous algorithm. The stable link to the spec is (still) here: http://aryeh.name/gitweb.cgi?p=editcommands;a=blob_plain;f=editcommands.html;hb=HEAD If you don't want to read the spec in detail, a high-level explanation of my goals and of how the new styling algorithm works can be found in the Introduction section, and in the long note at the beginning of Styling a node: http://aryeh.name/gitweb.cgi?p=editcommands;a=blob_plain;f=editcommands.html;hb=HEAD#introduction http://aryeh.name/gitweb.cgi?p=editcommands;a=blob_plain;f=editcommands.html;hb=HEAD#styling-a-node The algorithm was only really designed to support bold so far, although that means it should support italics fine too. Soon I'll work on adding support for foreColor, and trickier things like underline and hiliteColor, but the basic framework should work for those too. I haven't started on entirely different sorts of commands yet, like formatBlock or delete.
Re: [whatwg] PeerConnection: encryption feedback
On Thu, Mar 17, 2011 at 11:07 PM, Adam Barth w...@adambarth.com wrote: But you get this with a per-connection (not per-packet) nonce and CTR's sequence number. You don't need a unique 16-byte nonce for each packet. The attacker observes each packet once delivered, so you need a new nonce for each packet. I think you're talking about the attack described in http://www.openssl.org/~bodo/tls-cbc.txt. These attacks are against CBC, the cipher mode used by TLS block ciphers. That's why TLS 1.1 includes a separate IV for each packet. That sort of attack doesn't apply to the CTR cipher mode, because the contents of blocks don't feed back into the encryption as they do with CBC. If each packet does have its own random IV, then the CBC cipher mode should be used, not CTR. There may be other reasons to use CBC, as it's used by both TLS and IPsec, but if so I don't know what they are. Then the MAC would fail because we're using encrypt-then-mac. That works if the MAC includes the entire packet, including not just C (the encrypted data) but also the packet headers (the sequence number). -- Glenn Maynard
Re: [whatwg] PeerConnection: encryption feedback
On Thu, Mar 17, 2011 at 9:24 PM, Glenn Maynard gl...@zewt.org wrote: On Thu, Mar 17, 2011 at 11:07 PM, Adam Barth w...@adambarth.com wrote: But you get this with a per-connection (not per-packet) nonce and CTR's sequence number. You don't need a unique 16-byte nonce for each packet. The attacker observes each packet once delivered, so you need a new nonce for each packet. I think you're talking about the attack described in http://www.openssl.org/~bodo/tls-cbc.txt. These attacks are against CBC, the cipher mode used by TLS block ciphers. That's why TLS 1.1 includes a separate IV for each packet. That sort of attack doesn't apply to the CTR cipher mode, because the contents of blocks don't feed back into the encryption as they do with CBC. If each packet does have its own random IV, then the CBC cipher mode should be used, not CTR. There may be other reasons to use CBC, as it's used by both TLS and IPsec, but if so I don't know what they are. Nope. I'm not referring to that attack. To be precise, the required property is that each byte on the wire, when viewed independently of the other bytes, appears to be chosen uniformly at random from the point of view of the attacker when the message leaves the user agent. Then the MAC would fail because we're using encrypt-then-mac. That works if the MAC includes the entire packet, including not just C (the encrypted data) but also the packet headers (the sequence number). Correct. Adam
