[whatwg] HTML 5 : The Youtube response

[Kevin Carle]

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.

-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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100701/2f66b95a/attachment-0002.htm>