[whatwg] HTML 5 : The Youtube response

[Jeremy Doig]

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-February/018438.html

On Thu, Jul 1, 2010 at 2:02 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>
> On Jul 1, 2010, at 1:37 PM, Kevin Carle wrote:
>
> One part of (2) [well, debatably part, but related to video streaming] is
> the lack of visibility into stream behavior. I can't ask the video element
> questions about dropped frames, bitrate, etc. This is incredibly useful in
> Flash for getting streaming feedback, and means I really don't know how well
> the HTML5 player is working for users. The best I can do is waiting/stalled
> events which is nowhere near as granular.
>
> I agree that exposing info like that would be useful. What does the Flash
> API for this look like? What parts of the available data do you find most
> useful?
> Regards,
> Maciej
>
> -Kevin
>
> On Thu, Jul 1, 2010 at 9:16 AM, Maciej Stachowiak <mjs at apple.com> wrote:
>>
>> On Jul 1, 2010, at 6:12 AM, Kornel Lesinski wrote:
>>
>> >>
>> >> I believe we can allow arbitrary content to go fullscreen, along the
>> >> lines of what Robert O'Callahan has proposed on this list, if we impose
>> >> sufficient restrictions to mitigate the above risks. In my opinion, the
>> >> following measures would likely be sufficient:
>> >>
>> >> A) Have a distinctive animated sequence when an element goes into
>> >> full-screen mode. This helps the user understand what happened.
>> >> B) Limit the ability to go fullscreen to user gestures, much as many
>> >> browsers limit pop-ups. This prevents shenanigans from happening while the
>> >> user is away from the keyboard, and greatly limits the potential annoyance
>> >> factor.
>> >> C) On systems with keyboard/mouse input, limit the keys that may be
>> >> processed by fullscreen content to a small set, such as the set that Flash
>> >> limits to in full-screen mode:
>> >> <http://www.adobe.com/devnet/flashplayer/articles/fplayer10_security_changes_03.html#head5>.
>> >> D) On multitouch devices with an onscreen keyboard as the normal means
>> >> of input, things are trickier, because it's possible for a dedicated
>> >> attacker to simulate the keyboard. My best idea is make sure that a visually
>> >> distinctive status indicator appears at the top of the screen even in
>> >> full-screen mode, since that is the norm on such platforms.
>> >> E) Reserve one or more obvious key combinations to exiting fullscreen
>> >> no matter what (Escape, perhaps Cmd+W/Ctrl+W).
>> >> F) Even on keyboard/mouse type systems, have some distinctive visual
>> >> affordance which is either always present or appears on mouse moves, and
>> >> which allows the user to exit full-screen mode.
>> >>
>> >> I think these measures greatly mitigate risks (1) and (2) above, and
>> >> open up highly valued functionality (full screen video) with a UI that users
>> >> will enjoy, and customizability that video hosting sites will appreciate.
>> >
>> > Another option (for low-res videos on desktop) might be to use lower
>> > screen resolution when in full screen — text and UI elements displayed by
>> > attacker will look noticeably different.
>>
>> That would probably make the controls look ugly for video with custom
>> controls, and I suspect neither users nor content authors would appreciate
>> that. Interesting idea, though.
>>
>>  - Maciej
>>
>
>
>