- From: Jeremy Doig <jeremydo@google.com>
- Date: Thu, 1 Jul 2010 15:59:14 -0700
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 >> > > >
Received on Thursday, 1 July 2010 15:59:14 UTC