- From: Ian Fette <ifette@google.com>
- Date: Fri, 2 Jul 2010 08:28:41 -0700
Also related discussion, where I proposed something similar on WHATWG: http://www.mail-archive.com/whatwg at lists.whatwg.org/msg21565.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 >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100702/07bf1559/attachment.htm>
Received on Friday, 2 July 2010 08:28:41 UTC