Re: [whatwg] Cryptographically strong random numbers
On Thu, Feb 17, 2011 at 08:29, Allen Wirfs-Brock wrote:
> Array.randomFill= function (length){...};
>
> This would create a new array of the specified length where each element is a
> random value in some range. I propose that this range be 0..65535 as these
> are easily manipulatable (and optimizable) values that are likely to have
> some degree of optimization in all implementations. I don't really see why
> other element ranges need to be supported as they are easily constructed
> these values. However, if strong use cases (endianness??) can be made for
> the utility of natively supporting multiple element ranges then we could
> either add more functions:
> Array.randomFill8(length)
> Array.randomFill24(length)
> Array.randomFill32(length)
> or accept an optimal second parameter that specifies the desired bit width:
> Array.randomFill(length, bitWidth /*1 .. (32?, 48?, 53?) */)
>
> I would recommend keeping it simple and avoiding such non-essential tweaks.
>
> There was some (it didn't seem very serious) concerns about the cost of array
> allocation for such calls. I would point out that creating a new array is
> already the technique used in ECMAScript for most somewhat comparable
> situations such as the results of RegExp matches, the set of items deleted by
> slice, etc. Others might invoke words about the desirability of a functional
> style...
As Glenn pointed out, efficiency is just one part of the concern.
Flexibility is the main one. The fact you struggle to propose an API
that can satisfy everyone with 4 different randomFill functions rings
'code smell' to me.
You are making policy decisions on what kind of values (eg "only
0..65535") you can get from it and might severely hamper use cases
where efficiency is important (eg. just on top of my head, _stream_
random data to WebGL or WebGL) while it is always possible to create
an array before the call if you want to (or write a 3 line wrapper to
do that).
In fact most other languages/frameworks work this way, and I'm not
sure it makes sense in the first place to have this kind of specific
'seldom used' function in the language and/or such a basic and
commonly used type as Array, compared to have it in a type providing
crypto features (eg. .crypto).
Regards,
Re: [whatwg] Cryptographically strong random numbers
On Feb 16, 2011, at 4:54 PM, David Herman wrote: > I say: let's make it typed array in the short term, but TC39 will spec it as > an array of uint32 according to the binary data spec. We will try to make the > binary data spec as backwards compatible as possible with typed arrays > anyway. So in the near term, implementors can use typed arrays, but when they > have implementations of the full binary data spec, they can change to use > those. It'll probably be a slightly backwards-incompatible change, but by > keeping them relatively API-compatible, it shouldn't make too much difference > in practice. Plus we can warn people that that change is coming. Dave, most browsers other than FF4 internally box all integers with with 32-significant bits. Some may box with 31 or even 30 significant bits. So if we spec. the value as a uint32 and (they are truly random enough) then at least half and possible 75% or more of the values in the array will be boxed in many browsers. Such boxing will have a much higher cost than immediate uint16 values. That's why I propose 16-bit values. Allen
Re: [whatwg] Cryptographically strong random numbers
On Wed, Feb 16, 2011 at 4:29 PM, Allen Wirfs-Brock wrote: > So, let's get back to the design of an actual ECMAScript API. > > I'll repeat a couple of initial points: > We are now talking about a pure JavaScript API, Good stuff. Recall that part of what started this is that folks asked for improvements to math.random but math.random had become a key function in many benchmarks. Improving math.random would have the side effect of slowing down benchmark results so some felt touching is was problematic. Then there were some discussions regarding security hacks where guessing or inserting well guessed or spoofed results could compromise business or privacy. One post had a good yet short list of links that made it clear that Math.random as it is, is fragile. Rather than define a full and new API, an alternate tactic might be to code up some "quality" benchmarks metrics where Math.random would be improved because the benchmarks that identified the quality of the random numbers and gave better random tools more weighted value than just wall clock speed. The other issue that surfaced was a lack of rand-seed management policy. If corrected that would effectively make it nearly impossible for one script to guess anything that might go on in another connection. It is important for the old Math.random and any new API that rand-seed management policy be well addressed. I only intend to make the point that a new API will not repair Math.random as used now by numerous sites. Adding a new API will give sites new ways to get it wrong. -- T o m M i t c h e l l mitch-at-niftyegg-dot-com "My lifetime goal is to be the kind of person my dogs think I am."
Re: [whatwg] Cryptographically strong random numbers
Also note that that bug is accumulating use cases that might be worth
considering in this effort. As an example, many banks in various
parts of Asia require the use of ActiveX controls in IE. One could
hope that the web platform could provide those sorts of facilities
natively.
Adam
On Wed, Feb 16, 2011 at 5:00 PM, Adam Barth wrote:
> BTW, there seems to be significant interest around this subject here:
>
> http://code.google.com/p/chromium/issues/detail?id=73226
>
> w.r.t. the below, binary data types seem important for getting
> randomness right. In particular, using strings is bad news bears. We
> have binary data types available in browsers. It would be a shame to
> ignore them.
>
> Adam
>
>
> On Wed, Feb 16, 2011 at 4:29 PM, Allen Wirfs-Brock
> wrote:
>> So, let's get back to the design of an actual ECMAScript API.
>>
>> I'll repeat a couple of initial points:
>> We are now talking about a pure JavaScript API, not a DOM API so it should
>> follow JavaScript conventions.
>> If we want this to appear in browsers in the very near future we should
>> minimize any dependencies upon other Harmony features that are not both
>> totally finalized and trivial to implement (the empty set??)
>>
>> The first point would seem to eliminate DOM-like conventions such as pseudo
>> by-ref/in-our parameters, multiple numeric data types, or dependency upon
>> any host object (DOM) array like objects.
>> The second would seem to preclude the use of the proposed Harmony binary
>> typed arrays.
>>
>> In general, I don't see any particular reason why an ECMAScript array would
>> be unsuitable to collecting a sequence of random numeric values. It's what
>> people do today when they need to manipulate sequences of numbers.
>>
>> If we are using array's, the simplest API is probably a new function on the
>> array construct that is a factory for Arrays fill with random numeric values:
>>
>> Array.randomFill= function (length){...};
>>
>> This would create a new array of the specified length where each element is
>> a random value in some range. I propose that this range be 0..65535 as
>> these are easily manipulatable (and optimizable) values that are likely to
>> have some degree of optimization in all implementations. I don't really see
>> why other element ranges need to be supported as they are easily constructed
>> these values. However, if strong use cases (endianness??) can be made for
>> the utility of natively supporting multiple element ranges then we could
>> either add more functions:
>> Array.randomFill8(length)
>> Array.randomFill24(length)
>> Array.randomFill32(length)
>> or accept an optimal second parameter that specifies the desired bit width:
>> Array.randomFill(length, bitWidth /*1 .. (32?, 48?, 53?) */)
>>
>> I would recommend keeping it simple and avoiding such non-essential tweaks.
>>
>> There was some (it didn't seem very serious) concerns about the cost of
>> array allocation for such calls. I would point out that creating a new
>> array is already the technique used in ECMAScript for most somewhat
>> comparable situations such as the results of RegExp matches, the set of
>> items deleted by slice, etc. Others might invoke words about the
>> desirability of a functional style...
>>
>> If the array allocation was really a concern, then the randomFill function
>> should be a method on Array.prototyoe:
>> Array.prototype.randomFill= function () {...}; /* return the this value */
>>
>> it might be used like:
>> var rand = new Array(8).randomFill(); //create an array of 8 random
>> 16-bit numbers
>>
>> The length parameter is unnecessary because the length is implicit in the
>> array (and if this is about perf. you probably don't want to be dynamically
>> changing the length of already allocated arrays).
>> The same discussion of element size alternatives also applies.
>>
>> Of course we could do both. But really, if we want this to show up very
>> soon in browsers keeping it to a single function or methods with minimal
>> options is likely to yield the best results.
>>
>> Finally, as a dark horse we could consider using Strings rather than Arrays
>> as JavaScript strings are sequences of 16-bit values and the individual
>> element values are directly accessible.
>> String.randomFill(length) //returns a string value containing length random
>> 16-bit character values.
>>
>> Individual values would be accessed as:
>> var rs=String.randomFill(2);
>> var random32=(rs.charCodeAt(0)<<16)|rs.charCodeAt(1);
>>
>> But really, Arrays seem like they should work just fine.
>>
>> Allen
>
Re: [whatwg] Cryptographically strong random numbers
BTW, there seems to be significant interest around this subject here:
http://code.google.com/p/chromium/issues/detail?id=73226
w.r.t. the below, binary data types seem important for getting
randomness right. In particular, using strings is bad news bears. We
have binary data types available in browsers. It would be a shame to
ignore them.
Adam
On Wed, Feb 16, 2011 at 4:29 PM, Allen Wirfs-Brock
wrote:
> So, let's get back to the design of an actual ECMAScript API.
>
> I'll repeat a couple of initial points:
> We are now talking about a pure JavaScript API, not a DOM API so it should
> follow JavaScript conventions.
> If we want this to appear in browsers in the very near future we should
> minimize any dependencies upon other Harmony features that are not both
> totally finalized and trivial to implement (the empty set??)
>
> The first point would seem to eliminate DOM-like conventions such as pseudo
> by-ref/in-our parameters, multiple numeric data types, or dependency upon any
> host object (DOM) array like objects.
> The second would seem to preclude the use of the proposed Harmony binary
> typed arrays.
>
> In general, I don't see any particular reason why an ECMAScript array would
> be unsuitable to collecting a sequence of random numeric values. It's what
> people do today when they need to manipulate sequences of numbers.
>
> If we are using array's, the simplest API is probably a new function on the
> array construct that is a factory for Arrays fill with random numeric values:
>
> Array.randomFill= function (length){...};
>
> This would create a new array of the specified length where each element is a
> random value in some range. I propose that this range be 0..65535 as these
> are easily manipulatable (and optimizable) values that are likely to have
> some degree of optimization in all implementations. I don't really see why
> other element ranges need to be supported as they are easily constructed
> these values. However, if strong use cases (endianness??) can be made for
> the utility of natively supporting multiple element ranges then we could
> either add more functions:
> Array.randomFill8(length)
> Array.randomFill24(length)
> Array.randomFill32(length)
> or accept an optimal second parameter that specifies the desired bit width:
> Array.randomFill(length, bitWidth /*1 .. (32?, 48?, 53?) */)
>
> I would recommend keeping it simple and avoiding such non-essential tweaks.
>
> There was some (it didn't seem very serious) concerns about the cost of array
> allocation for such calls. I would point out that creating a new array is
> already the technique used in ECMAScript for most somewhat comparable
> situations such as the results of RegExp matches, the set of items deleted by
> slice, etc. Others might invoke words about the desirability of a functional
> style...
>
> If the array allocation was really a concern, then the randomFill function
> should be a method on Array.prototyoe:
> Array.prototype.randomFill= function () {...}; /* return the this value */
>
> it might be used like:
> var rand = new Array(8).randomFill(); //create an array of 8 random
> 16-bit numbers
>
> The length parameter is unnecessary because the length is implicit in the
> array (and if this is about perf. you probably don't want to be dynamically
> changing the length of already allocated arrays).
> The same discussion of element size alternatives also applies.
>
> Of course we could do both. But really, if we want this to show up very soon
> in browsers keeping it to a single function or methods with minimal options
> is likely to yield the best results.
>
> Finally, as a dark horse we could consider using Strings rather than Arrays
> as JavaScript strings are sequences of 16-bit values and the individual
> element values are directly accessible.
> String.randomFill(length) //returns a string value containing length random
> 16-bit character values.
>
> Individual values would be accessed as:
> var rs=String.randomFill(2);
> var random32=(rs.charCodeAt(0)<<16)|rs.charCodeAt(1);
>
> But really, Arrays seem like they should work just fine.
>
> Allen
Re: [whatwg] Cryptographically strong random numbers
So, let's get back to the design of an actual ECMAScript API.
I'll repeat a couple of initial points:
We are now talking about a pure JavaScript API, not a DOM API so it should
follow JavaScript conventions.
If we want this to appear in browsers in the very near future we should
minimize any dependencies upon other Harmony features that are not both
totally finalized and trivial to implement (the empty set??)
The first point would seem to eliminate DOM-like conventions such as pseudo
by-ref/in-our parameters, multiple numeric data types, or dependency upon any
host object (DOM) array like objects.
The second would seem to preclude the use of the proposed Harmony binary typed
arrays.
In general, I don't see any particular reason why an ECMAScript array would be
unsuitable to collecting a sequence of random numeric values. It's what people
do today when they need to manipulate sequences of numbers.
If we are using array's, the simplest API is probably a new function on the
array construct that is a factory for Arrays fill with random numeric values:
Array.randomFill= function (length){...};
This would create a new array of the specified length where each element is a
random value in some range. I propose that this range be 0..65535 as these are
easily manipulatable (and optimizable) values that are likely to have some
degree of optimization in all implementations. I don't really see why other
element ranges need to be supported as they are easily constructed these
values. However, if strong use cases (endianness??) can be made for the
utility of natively supporting multiple element ranges then we could either add
more functions:
Array.randomFill8(length)
Array.randomFill24(length)
Array.randomFill32(length)
or accept an optimal second parameter that specifies the desired bit width:
Array.randomFill(length, bitWidth /*1 .. (32?, 48?, 53?) */)
I would recommend keeping it simple and avoiding such non-essential tweaks.
There was some (it didn't seem very serious) concerns about the cost of array
allocation for such calls. I would point out that creating a new array is
already the technique used in ECMAScript for most somewhat comparable
situations such as the results of RegExp matches, the set of items deleted by
slice, etc. Others might invoke words about the desirability of a functional
style...
If the array allocation was really a concern, then the randomFill function
should be a method on Array.prototyoe:
Array.prototype.randomFill= function () {...}; /* return the this value */
it might be used like:
var rand = new Array(8).randomFill(); //create an array of 8 random
16-bit numbers
The length parameter is unnecessary because the length is implicit in the array
(and if this is about perf. you probably don't want to be dynamically changing
the length of already allocated arrays).
The same discussion of element size alternatives also applies.
Of course we could do both. But really, if we want this to show up very soon
in browsers keeping it to a single function or methods with minimal options is
likely to yield the best results.
Finally, as a dark horse we could consider using Strings rather than Arrays as
JavaScript strings are sequences of 16-bit values and the individual element
values are directly accessible.
String.randomFill(length) //returns a string value containing length random
16-bit character values.
Individual values would be accessed as:
var rs=String.randomFill(2);
var random32=(rs.charCodeAt(0)<<16)|rs.charCodeAt(1);
But really, Arrays seem like they should work just fine.
Allen
Re: [whatwg] Cryptographically strong random numbers
On Mon, Feb 14, 2011 at 8:03 PM, Allen Wirfs-Brock wrote: > but we're now talking about a pure ECMAScript function so DOM conventions > shouldn't be applicable. But consistency with common JavaScript practices > should be. > > If you want to apply it to an already allocated array then making it method > on Array.prototype would be a more internally consistent way to do it. > > Although, I also a bit partial to the string based formulation and I assume > that relatively small string values should be fairly efficient to allocated. > > In either case, it does sound like premature optimization relative to > everything else that is likely to beging on the the JS code that actually > uses these random values. > This isn't an optimization; it's simply a different design. Optimization is one underlying rationale, but not the only one. I don't think optimization is an important consideration here for crypto, since you usually don't need a lot of random data to generate a key--often on the order of a few dozen or hundred bytes. You're not reading a megabyte of data to generate a key. There can be uses for generating large blocks of randomness for non-crypto, though, of course. However, it also allows specifying the type of the data to return: whether the random data should be interpreted as 8-bit arrays, 16-bit arrays, and so on. I don't know if that's actually important (havn't seen specific use cases), but that was another rationale. I think it was also intended to avoid encoding 8-bit data in a UTF-16 string. -- Glenn Maynard
Re: [whatwg] How to handle multitrack media resources in HTML
Hi Eric, I'm curious: if you are using @kind=metadata - which is not generically applicable, but only has application-specific data in it - then this implies that the web page knows what type of data is in the track's cues and knows how to parse it. Why do you need a mime type on the cues then? Is it because MPEG has metadata cue tracks that can contain different types of structured content? Can you clarify? Cheers, Silvia. On Thu, Feb 17, 2011 at 6:44 AM, Eric Winkelman wrote: > Silvia, all, > > We're working with multitrack MPEG transport streams, and have an > implementation of the TimedTrack interface integrating with in-band metadata > tracks. Our prototype uses the Metadata Cues to synchronize a JavaScript > application with a video stream using the stream's embedded EISS signaling. > This approach is working very well so far. > > The biggest issue we've faced is that there isn't an obvious way to tell the > browser application what type of information is contained within the metadata > track/cues. The Cues can contain arbitrary text, but neither the Cue, nor > the associated TimedTrack, has functionality for specifying the > format/meaning of that text. > > Our current implementation uses the Cue's @identifier for a MIME type, and > puts the associated metadata into the Cue's text field using XML. This > works, but requires the JavaScript browser application to examine the cues to > see if they contain information it understands. It also requires the video > player to follow this convention for Metadata TimedTracks. > > Adding a @type attribute to the Cues would certainly help, though it would > still require the browser application to examine individual cues to see if > they were useful. > > An alternate approach would be to add a @type attribute to the > tag/TimedTrack that would specify the mime type for the associated cues. > This would allow a browser application to determine from the TimedTrack > whether or not it needed to process the associated cues. > > Eric > --- > Eric Winkelman > CableLabs > >> -Original Message- >> From: whatwg-boun...@lists.whatwg.org [mailto:whatwg- >> boun...@lists.whatwg.org] On Behalf Of Silvia Pfeiffer >> Sent: Wednesday, February 09, 2011 5:41 PM >> To: WHAT Working Group >> Subject: [whatwg] How to handle multitrack media resources in HTML >> >> Hi all, >> >> One particular issue that hasn't had much discussion here yet is the issue of >> how to deal with multitrack media resources or media resources that have >> associated synchronized audio and video resources. >> I'm concretely referring to such things as audio descriptions, sign language >> video, and dubbed audio tracks. >> >> We require an API that can expose such extra tracks to the user and to >> JavaScript. This should be independent of whether the tracks are actually >> inside the media resource or are given as separate resources, but should be >> linked to the main media resource through markup. >> >> I am bringing this up now because solutions may have an influence on the >> inner workings of TimedTrack and the element, so before we have >> any implementations of , we should be very certain that we are >> happy with the way in which it works - in particular that continues >> to >> stay an empty element. >> >> We've had some preliminary discussions about this in the W3C Accessibility >> Task Force and the alternatives that we could think about are captured in >> http://www.w3.org/WAI/PF/HTML/wiki/Media_Multitrack_Media_API . This >> may not be the complete list of possible solutions, but it provides ideas for >> the different approaches that can be taken. >> >> I'd like to see what people's opinions are about them. >> >> Note there are also discussion threads about this at the W3C both in the >> Accessibility TF [1] and the HTML Working Group [2], but I am curious about >> input from the wider community. >> >> So check out >> http://www.w3.org/WAI/PF/HTML/wiki/Media_Multitrack_Media_API >> and share your opinions. >> >> Cheers, >> Silvia. >> >> [1] http://lists.w3.org/Archives/Public/public-html-a11y/2011Feb/0057.html >> [2] http://lists.w3.org/Archives/Public/public-html/2011Feb/0205.html >
Re: [whatwg] Cryptographically strong random numbers
On Wed, Feb 16, 2011 at 11:36 AM, Oliver Hunt wrote: > I agree with this sentiment, the specification should simply state "the > returned values are guaranteed to be cryptographically secure", that's all > that needs to be said. There is no need to describe how this is > implemented, if an implementation provides predictable values then that > implementation is broken. If your prng has low entropy it is not > cryptographically secure, and therefore broken. How you get to > cryptographically secure isn't really relevant as long as you can get > there*. > > This is of course entirely ignoring timing attacks, and other such side > channels. > > --Oliver > > * If a platform can't provide cryptographically secure random i'd be > concerned about that implementation being web facing as i would be dubious > of the theoretical security of its SSL implementation, etc. > Hi Oliver, not disagreeing with anything you said. But in light of this footnote, I want to remind everyone that JS is not necessarily web facing. Normative EcmaScript standards impose an obligation on any implementation wishing to claim standards conformance. That said, I support adding this normative obligation on all conformant EcmaScript implementations. > > > On Feb 16, 2011, at 10:40 AM, David Wagner wrote: > > > [re-sending to es-discuss] > > > > Shabsi Walfish wrote: > >> This depends on what you consider to be the basic use case. Generating > >> long-lived cryptographic keys absolutely requires high quality > entropy... if > >> you are only generating short-lived authenticators (that are not used > for > >> encryption) then you could get away with weaker entropy. You will get > the > >> most mileage out of this feature if it can be used to generate > encryption > >> keys, or long-lived signing keys. > > > > Personally, I think discussion about the "quality" of the PRNG is a > > distraction. The PRNG should produce crypto-quality random numbers. > > Period. That's all that need be said. That's good enough. It's good > > enough for short-lived authenticators, good enough for encryption keys, > > good enough for any signing key that's going to be used in Javascript. > > It's just plain good enough. > > > > There's no need for an interface to request or query or specify the > > quality or entropy of the random numbers. Callers should be able to > > rely upon it to be crypto-quality. Browsers can deliver on that. > > > > My advice is: Keep the API as simple as it possibly can be. Don't get > > distracted with twirly knobs and added complications. A simple API will > > be plenty to get the job done. Stay on target. > > ___ > > es-discuss mailing list > > es-disc...@mozilla.org > > https://mail.mozilla.org/listinfo/es-discuss > > -- Cheers, --MarkM
Re: [whatwg] Proposal for separating script downloads and execution
On Wed, Feb 16, 2011 at 9:28 AM, Will Alexander wrote: > In this bug report Boris Zbarsky expresses concern that prefetching without > creating memory leaks is difficult. > > https://bugzilla.mozilla.org/show_bug.cgi?id=621553 Possibly related: http://code.google.com/p/chromium/issues/detail?id=36142. (Last I checked, you could crash Chrome with Google Maps just by scrolling the map around for long enough, and I hit similar issues with my own code in other WebKit-based browsers.) This isn't a problem with the "noexecute" approach. But, since browsers already need to be able to deal with this for images, that bridge is already crossed... -- Glenn Maynard
Re: [whatwg] How to handle multitrack media resources in HTML
Silvia, all, We're working with multitrack MPEG transport streams, and have an implementation of the TimedTrack interface integrating with in-band metadata tracks. Our prototype uses the Metadata Cues to synchronize a JavaScript application with a video stream using the stream's embedded EISS signaling. This approach is working very well so far. The biggest issue we've faced is that there isn't an obvious way to tell the browser application what type of information is contained within the metadata track/cues. The Cues can contain arbitrary text, but neither the Cue, nor the associated TimedTrack, has functionality for specifying the format/meaning of that text. Our current implementation uses the Cue's @identifier for a MIME type, and puts the associated metadata into the Cue's text field using XML. This works, but requires the JavaScript browser application to examine the cues to see if they contain information it understands. It also requires the video player to follow this convention for Metadata TimedTracks. Adding a @type attribute to the Cues would certainly help, though it would still require the browser application to examine individual cues to see if they were useful. An alternate approach would be to add a @type attribute to the tag/TimedTrack that would specify the mime type for the associated cues. This would allow a browser application to determine from the TimedTrack whether or not it needed to process the associated cues. Eric --- Eric Winkelman CableLabs > -Original Message- > From: whatwg-boun...@lists.whatwg.org [mailto:whatwg- > boun...@lists.whatwg.org] On Behalf Of Silvia Pfeiffer > Sent: Wednesday, February 09, 2011 5:41 PM > To: WHAT Working Group > Subject: [whatwg] How to handle multitrack media resources in HTML > > Hi all, > > One particular issue that hasn't had much discussion here yet is the issue of > how to deal with multitrack media resources or media resources that have > associated synchronized audio and video resources. > I'm concretely referring to such things as audio descriptions, sign language > video, and dubbed audio tracks. > > We require an API that can expose such extra tracks to the user and to > JavaScript. This should be independent of whether the tracks are actually > inside the media resource or are given as separate resources, but should be > linked to the main media resource through markup. > > I am bringing this up now because solutions may have an influence on the > inner workings of TimedTrack and the element, so before we have > any implementations of , we should be very certain that we are > happy with the way in which it works - in particular that continues to > stay an empty element. > > We've had some preliminary discussions about this in the W3C Accessibility > Task Force and the alternatives that we could think about are captured in > http://www.w3.org/WAI/PF/HTML/wiki/Media_Multitrack_Media_API . This > may not be the complete list of possible solutions, but it provides ideas for > the different approaches that can be taken. > > I'd like to see what people's opinions are about them. > > Note there are also discussion threads about this at the W3C both in the > Accessibility TF [1] and the HTML Working Group [2], but I am curious about > input from the wider community. > > So check out > http://www.w3.org/WAI/PF/HTML/wiki/Media_Multitrack_Media_API > and share your opinions. > > Cheers, > Silvia. > > [1] http://lists.w3.org/Archives/Public/public-html-a11y/2011Feb/0057.html > [2] http://lists.w3.org/Archives/Public/public-html/2011Feb/0205.html
Re: [whatwg] Cryptographically strong random numbers
I agree with this sentiment, the specification should simply state "the returned values are guaranteed to be cryptographically secure", that's all that needs to be said. There is no need to describe how this is implemented, if an implementation provides predictable values then that implementation is broken. If your prng has low entropy it is not cryptographically secure, and therefore broken. How you get to cryptographically secure isn't really relevant as long as you can get there*. This is of course entirely ignoring timing attacks, and other such side channels. --Oliver * If a platform can't provide cryptographically secure random i'd be concerned about that implementation being web facing as i would be dubious of the theoretical security of its SSL implementation, etc. On Feb 16, 2011, at 10:40 AM, David Wagner wrote: > [re-sending to es-discuss] > > Shabsi Walfish wrote: >> This depends on what you consider to be the basic use case. Generating >> long-lived cryptographic keys absolutely requires high quality entropy... if >> you are only generating short-lived authenticators (that are not used for >> encryption) then you could get away with weaker entropy. You will get the >> most mileage out of this feature if it can be used to generate encryption >> keys, or long-lived signing keys. > > Personally, I think discussion about the "quality" of the PRNG is a > distraction. The PRNG should produce crypto-quality random numbers. > Period. That's all that need be said. That's good enough. It's good > enough for short-lived authenticators, good enough for encryption keys, > good enough for any signing key that's going to be used in Javascript. > It's just plain good enough. > > There's no need for an interface to request or query or specify the > quality or entropy of the random numbers. Callers should be able to > rely upon it to be crypto-quality. Browsers can deliver on that. > > My advice is: Keep the API as simple as it possibly can be. Don't get > distracted with twirly knobs and added complications. A simple API will > be plenty to get the job done. Stay on target. > ___ > es-discuss mailing list > es-disc...@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss
Re: [whatwg] Proposal for IsSearchProviderInstalled / AddSearchProvider
On Tue, Feb 15, 2011 at 9:42 AM, Bjartur Thorlacius wrote: > > 2. When a user decides to use it, they have to follow a set of complex > > instructions (http://www.google.com/search?q=switch+default+search+engines > ) > > > Annoying implementation issue. http://bugzilla.mozilla.com/enter_bug.cgi > mailto:implement...@lists.whatwg.org It is still complicated in all browsers, so I wasn't trying to point out flaws in any particular browser -- only that it is complicated and hard for users to do. On Tue, Feb 15, 2011 at 9:42 AM, Bjartur Thorlacius wrote: > > IsSearchProviderInstalled(string url) > This seems like a slight privacy violation. Not a serious one, but nothing > I'd > like to be explicitly exposed. Note that it only tells a search engine if they are the default. They cannot query about other search engines. On Tue, Feb 15, 2011 at 1:48 PM, Kornel Lesiński wrote: > > There are many many sites that dream they were used as a default search > engine, but their use of this API is only going to annoy or confuse users. > This should be rare as annoying and confusing your users typically isn't a good business strategy. On Tue, Feb 15, 2011 at 9:42 AM, Bjartur Thorlacius wrote: > > > https://sites.google.com/a/chromium.org/dev/developers/design-documents/chromium-search-provider-js-support > Frankly, this reminds me of the security UI of Windows Vista. ... > On Tue, Feb 15, 2011 at 1:48 PM, Kornel Lesiński wrote: > Change of default search engine may have security implications I understand your concern. In this case, the UI is similar to what happens in many browsers when AddSearchProvider is called in response to a user action. In addition, the default is to not change anything. Yet, we are discussing one possible UI of many that I simply gave as one possible example. It is completely up to the UA to decide what to do in this case. I look forward to others proposing other solutions too in this regard. On Tue, Feb 15, 2011 at 1:48 PM, Kornel Lesiński wrote: > You don't change that often, and there are only few search engines that > make sense to be set as the default one. Browsers can simply ship with > predefined set of engines, and that may be easiest and safest option for > users. > If a UA wanted to limit this to only be available to a predefined set of search engines, that would be possible. It is up to the UA to decide what to do. Technically a "AddSearchProvider" that did nothing ever would be conforming though certainly against the spirit of the api. Best wishes, dave
Re: [whatwg] Device element and the lifetime of the stream objects
Andrei Popescu wrote: Hi Anne, On Wed, Feb 16, 2011 at 12:36 PM, Anne van Kesteren wrote: On Tue, 15 Feb 2011 17:48:24 +0100, Leandro Graciá Gil wrote: All feedback will be greatly appreciated. This is just a thought. Instead of acquiring a Stream object asynchronously there always is one available showing transparent black or some such. E.g. navigator.cameraStream. It also inherits from EventTarget. Then on the Stream object you have methods to request camera access which triggers some asynchronous UI. I thought we were all trying to avoid asynchronous UI (dialogs, infobars, popups, etc), which is a solution that does not scale very well when many different APIs require it. This was one of the main reasons for trying a different approach. We are also trying a different approach but we're not really coming up with anything other than modal dialogs, no-authorization models or policies; none of which are suitable for different reasons. One option that works is, on click, presenting some kind of async authorization request. However, if we're going to do that then we might as well just implement a Javascript API to call the async authorization request in the first place (in the process saving one user click). Once granted an appropriately named event is dispatched on Stream indicating you now have access to an actual stream. When the user decides it is enough and turns of the camera (or something else happens) some other appropriately named event is dispatched on Stream again turning it transparent black again. This also removes the need for the element as has been mentioned off-list. Basically, the idea was that does not really help anyone. What do you mean exactly by this? The usecases are pretty clear. It makes custom in-page UI harder, it does not prevent the need for scripting, and it does not help with fallback. I was never under the impression we need to prevent the need for scripting. Why is that a goal? The element requires JavaScript to do anything useful. Without Javascript all the authorization interfaces will still work and users will still go through them to authorize access to their device but then...nothing will happen if the page is not running JavaScript. That's not great. There's no fallback or interaction within non-scripted environments so a HTML element seems to be the wrong level for integration. As also mentioned above, in-page UI is harder if we force a particular style for elements (a button or otherwise) on to developers. This is somewhat weird though :-) Agreed. And, as I said earlier, I thought the goal was to try something else than asynchronous permission dialogs. What has changed? We've been looking at usability and user interface for vs an async JS API and are finding better ways to make multiple async JS APIs work in our interfaces than we are for element-based authorizations. It would also be easier for prototyping if we didn't make assumptions on a element. We can always jump to implementing a element later on but initially it might be good to prototype in JavaScript with vendor API prefixes in preparation for a final standard approach. We're doing due diligence on both options so it's worth having this discussion and seeing what other implementers think. Cheers, Rich
Re: [whatwg] Device element and the lifetime of the stream objects
Hi Anne, On Wed, Feb 16, 2011 at 12:36 PM, Anne van Kesteren wrote: > On Tue, 15 Feb 2011 17:48:24 +0100, Leandro Graciá Gil > wrote: >> >> All feedback will be greatly appreciated. > > This is just a thought. Instead of acquiring a Stream object asynchronously > there always is one available showing transparent black or some such. E.g. > navigator.cameraStream. It also inherits from EventTarget. Then on the > Stream object you have methods to request camera access which triggers some > asynchronous UI. I thought we were all trying to avoid asynchronous UI (dialogs, infobars, popups, etc), which is a solution that does not scale very well when many different APIs require it. This was one of the main reasons for trying a different approach. > Once granted an appropriately named event is dispatched on > Stream indicating you now have access to an actual stream. When the user > decides it is enough and turns of the camera (or something else happens) > some other appropriately named event is dispatched on Stream again turning > it transparent black again. > > This also removes the need for the element as has been mentioned > off-list. Basically, the idea was that does not really help anyone. What do you mean exactly by this? The usecases are pretty clear. > It makes custom in-page UI harder, it does not prevent the need for > scripting, and it does not help with fallback. > I was never under the impression we need to prevent the need for scripting. Why is that a goal? > This is somewhat weird though :-) > Agreed. And, as I said earlier, I thought the goal was to try something else than asynchronous permission dialogs. What has changed? Thanks, Andrei
Re: [whatwg] Proposal for separating script downloads and execution
On Feb 15, 2011 6:34 PM, "Nicholas Zakas" wrote: > > 1) Should the default behavior for dynamic script nodes be to start downloading the file upon the setting of src and only execute when added to the document (IE's behavior) or not? Could the default behavior be defined by the user-agent and the value of this property reflect that? So in IE the def value would be true, but false in other browsers. > 2) Can the proposals on the table be used to better detect the correct behavior from #1? > 3) Are the proposals close to being feasible with, perhaps, some changes? Or are they completely outlandish and have no possibility of reaching implementation? In this bug report Boris Zbarsky expresses concern that prefetching without creating memory leaks is difficult. https://bugzilla.mozilla.org/show_bug.cgi?id=621553 >
Re: [whatwg] Device element and the lifetime of the stream objects
On Wed, Feb 16, 2011 at 2:36 PM, Anne van Kesteren wrote: > This is just a thought. Instead of acquiring a Stream object asynchronously > there always is one available showing transparent black or some such. :) > E.g. > navigator.cameraStream. It also inherits from EventTarget. Then on the > Stream object you have methods to request camera access which triggers some > asynchronous UI. Once granted an appropriately named event is dispatched on > Stream indicating you now have access to an actual stream. When the user > decides it is enough and turns of the camera (or something else happens) > some other appropriately named event is dispatched on Stream again turning > it transparent black again. > > This also removes the need for the element as has been mentioned > off-list. Basically, the idea was that does not really help anyone. > It makes custom in-page UI harder, it does not prevent the need for > scripting, and it does not help with fallback. Yeah, I'd be quite happy to not have at all. > This is somewhat weird though :-) that is much closer to how i'd want things to work. although from my perspective, i don't know that we need to send many events. I don't see a significant difference between a user with a camera covered by a black tile, or a camera perpetually pointed at a white wall. If the user wants to move where the camera points, that's up to the user, and the app will notice that there's more data streaming. I think it's sufficient for a UA to inform the user that is streaming this and to allow the user to adjust the "virtual camera" to point at something else, out through the fourth wall at the user, out the window, at some other device, at a video file, etc.
Re: [whatwg] Device element and the lifetime of the stream objects
On Tue, 15 Feb 2011 17:48:24 +0100, Leandro Graciá Gil wrote: All feedback will be greatly appreciated. This is just a thought. Instead of acquiring a Stream object asynchronously there always is one available showing transparent black or some such. E.g. navigator.cameraStream. It also inherits from EventTarget. Then on the Stream object you have methods to request camera access which triggers some asynchronous UI. Once granted an appropriately named event is dispatched on Stream indicating you now have access to an actual stream. When the user decides it is enough and turns of the camera (or something else happens) some other appropriately named event is dispatched on Stream again turning it transparent black again. This also removes the need for the element as has been mentioned off-list. Basically, the idea was that does not really help anyone. It makes custom in-page UI harder, it does not prevent the need for scripting, and it does not help with fallback. This is somewhat weird though :-) -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Google Feedback on the HTML5 media a11y specifications
On 2011/02/16 00:23 (GMT-0800) Kevin Marks composed: Classic TV required this (especially with overscan), but on modern TV's there is often a letterbox or pillarbox are that captions should go in. On a decent-sized computer screen, there is no real excuse for obscuring the video with the captions rather than putting them underneath or alongside. Pillarboxes are too narrow for reasonable line lengths of legible text. Letterboxes, except during commercials, which are commonly double boxed, are uncommon on 16:9 HDTVs. "Decent" sized computer screens are uncommon any more in stores. Most are now just miniaturized 16:9 HDTVs, too short for letterboxing to contain captions. -- "How much better to get wisdom than gold, to choose understanding rather than silver." Proverbs 16:16 NKJV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/
Re: [whatwg] Why are media event handlers defined on HTMLElement instead of HTMLMediaElement
On Tue, 15 Feb 2011 23:54:10 +0100, David Flanagan wrote: On 02/15/2011 12:44 PM, Philip Jägenstedt wrote: On Tue, 15 Feb 2011 19:13:26 +0100, David Flanagan wrote: What about Document and Window? What's the justification for defining the media event handler attributes on those objects? Huh, it is on Window, I hadn't seen that before. They were added in http://html5.org/r/3005 but I can't say I understand why. I can't see it on Document in Web DOM Core, though, am I missing something? Sorry, I meant HTMLDocument: http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#documents Looks like they were added to HTMLDocument in the same change set. Well, I really don't know. My best guess is for simplicity, that any interface that has event listeners simply has all event listeners. Hopefully someone with more of a clue will explain. -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] Google Feedback on the HTML5 media a11y specifications
On Wed, 16 Feb 2011 12:30:06 +0100, Silvia Pfeiffer wrote: On Wed, Feb 16, 2011 at 9:27 PM, timeless wrote: On Wed, Feb 16, 2011 at 10:23 AM, Kevin Marks wrote: Moving them only within the video viewport is a bug, not a feature. Of note, the big tv we had in 2000 (probably purchased circa 1998) at a college communal area would display captions for the PIP window below the PIP. So even TV vendors were aware that they didn't need to always stick captions into the box once they had reasonable resolution. Sadly I don't think I've ever seen any TVs which would shrink the primary window just to supply space for captions. There's no reason they couldn't, since they also do shrink the window to provide onscreen menus or program guides. I suppose part of the reason with big TVs is an assumption that the audience will be at a fixed distance with or without captions, but shrinking the view area for the programming would cause the preferred distance to decrease. And as content providers actually do try to pick areas which are mostly dead, the tradeoff of losing "live pixels" vs decreasing optimal distance was not considered worth it. Classic TV required this (especially with overscan), but on modern TV's there is often a letterbox or pillarbox are that captions should go in. Indeed. I'm pretty sure I saw a DVD playes which took advantage of this with a letterbox and stuck the captions below the movie in January when I was in California. IIUC, the YouTube's captions can be moved within the whole video viewport which includes any letterboxing or pillarboxing if available. As for moving them outside - that would turn the whole web page into a potential drop zone for a div (or similar) coming from within a media element. That would probably not make that much sense. But I could imagine an application defining certain areas around the video - in particular below and above it - as drop zones for captions/subtitles and thus extend the on-screen space. I wonder what the browser vendors think about that feature. Cheers, Silvia. On a decent-sized computer screen, there is no real excuse for obscuring the video with the captions rather than putting them underneath or alongside. Yep. Well, it wouldn't be wrong for someone to write a 'Misery compatibility mode' application to enable people to see how their captions would look on old TVs, but I don't think that's something for which primary applications should be designed. I've had the same idea. The rendering of captions is already defined as being on top of another element, namely the parent element. Technically, I don't think it would be very difficult to allow the captions to be rendered into some other container. I think this kind of feature should wait until we have implementations of the current spec, though. -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] Google Feedback on the HTML5 media a11y specifications
On Wed, Feb 16, 2011 at 9:27 PM, timeless wrote: > On Wed, Feb 16, 2011 at 10:23 AM, Kevin Marks wrote: >> Moving them only within the video viewport is a bug, not a feature. > > Of note, the big tv we had in 2000 (probably purchased circa 1998) at > a college communal area would display captions for the PIP window > below the PIP. So even TV vendors were aware that they didn't need to > always stick captions into the box once they had reasonable > resolution. > > Sadly I don't think I've ever seen any TVs which would shrink the > primary window just to supply space for captions. There's no reason > they couldn't, since they also do shrink the window to provide > onscreen menus or program guides. > > I suppose part of the reason with big TVs is an assumption that the > audience will be at a fixed distance with or without captions, but > shrinking the view area for the programming would cause the preferred > distance to decrease. And as content providers actually do try to pick > areas which are mostly dead, the tradeoff of losing "live pixels" vs > decreasing optimal distance was not considered worth it. > >> Classic >> TV required this (especially with overscan), but on modern TV's there is >> often a letterbox or pillarbox are that captions should go in. > > Indeed. I'm pretty sure I saw a DVD playes which took advantage of > this with a letterbox and stuck the captions below the movie in > January when I was in California. IIUC, the YouTube's captions can be moved within the whole video viewport which includes any letterboxing or pillarboxing if available. As for moving them outside - that would turn the whole web page into a potential drop zone for a div (or similar) coming from within a media element. That would probably not make that much sense. But I could imagine an application defining certain areas around the video - in particular below and above it - as drop zones for captions/subtitles and thus extend the on-screen space. I wonder what the browser vendors think about that feature. Cheers, Silvia. >> On a >> decent-sized computer screen, there is no real excuse for obscuring the >> video with the captions rather than putting them underneath or alongside. > > Yep. Well, it wouldn't be wrong for someone to write a 'Misery > compatibility mode' application to enable people to see how their > captions would look on old TVs, but I don't think that's something for > which primary applications should be designed. >
Re: [whatwg] Google Feedback on the HTML5 media a11y specifications
On Wed, Feb 16, 2011 at 10:23 AM, Kevin Marks wrote: > Moving them only within the video viewport is a bug, not a feature. Of note, the big tv we had in 2000 (probably purchased circa 1998) at a college communal area would display captions for the PIP window below the PIP. So even TV vendors were aware that they didn't need to always stick captions into the box once they had reasonable resolution. Sadly I don't think I've ever seen any TVs which would shrink the primary window just to supply space for captions. There's no reason they couldn't, since they also do shrink the window to provide onscreen menus or program guides. I suppose part of the reason with big TVs is an assumption that the audience will be at a fixed distance with or without captions, but shrinking the view area for the programming would cause the preferred distance to decrease. And as content providers actually do try to pick areas which are mostly dead, the tradeoff of losing "live pixels" vs decreasing optimal distance was not considered worth it. > Classic > TV required this (especially with overscan), but on modern TV's there is > often a letterbox or pillarbox are that captions should go in. Indeed. I'm pretty sure I saw a DVD playes which took advantage of this with a letterbox and stuck the captions below the movie in January when I was in California. > On a > decent-sized computer screen, there is no real excuse for obscuring the > video with the captions rather than putting them underneath or alongside. Yep. Well, it wouldn't be wrong for someone to write a 'Misery compatibility mode' application to enable people to see how their captions would look on old TVs, but I don't think that's something for which primary applications should be designed.
Re: [whatwg] Google Feedback on the HTML5 media a11y specifications
On Tue, Feb 8, 2011 at 6:57 PM, Silvia Pfeiffer wrote: > Hi Philip, all, > > > On Sun, Jan 23, 2011 at 1:23 AM, Philip Jägenstedt > wrote: > > On Fri, 14 Jan 2011 10:01:38 +0100, Silvia Pfeiffer > > wrote: > > >> 5. Ability to move captions out of the way > >> > >> Our experience with automated caption creation and positioning on > >> YouTube indicates that it is almost impossible to always place the > >> captions out of the way of where a user may be interested to look at. > >> We therefore allow users to dynamically move the caption rendering > >> area to a different viewport position to reveal what is underneath. We > >> recommend such drag-and-drop functionality also be made available for > >> TimedTrack captions on the Web, especially when no specific > >> positioning information is provided. > > > > This would indeed be rather nice, but wouldn't it interfere with text > > selection? Detaching the captions into a floating, draggable window via > the > > context menu would be a theoretically possible solution, but that's > getting > > rather far ahead of ourselves before we have basic captioning support. > > On YouTube you can only move them within the video viewport. You > should try it - it's really awesome actually. > Moving them only within the video viewport is a bug, not a feature. Classic TV required this (especially with overscan), but on modern TV's there is often a letterbox or pillarbox are that captions should go in. On a decent-sized computer screen, there is no real excuse for obscuring the video with the captions rather than putting them underneath or alongside. I know the flash implementation of YouTube ends up treating the video viewport as a surrogate screen, as you can't draw outside it, but the HTML5 version could do this better. > > When you say "interfere with text selection" are you suggesting that > the text of captions/subtitles should be able to be cut and pasted? I > wonder what copyright holders think about that. > What they think is beside the point; fair use/fair dealing applies in many cases. Omitting a useful feature because of vague fears of what people think is the opposite of a use case.
