[whatwg] More YouTube response

On Thu, Jul 1, 2010 at 6:59 PM, John Harding <jharding at google.com> wrote:
> Some of the discussion here seems to have conflated application-controlled
> video delivery with content protection, but in an ideal world, the two are
> independent. ?The basic requirements around content protection that we get
> from content owners basically consist of encrypting the content and limiting
> the decryption to a "verified" and authorized client - the realm of
> traditional DRM. ?Rather than ask browsers to get into the DRM business,
> what I think would work best is having a means for 3rd party DRM providers
> to supply browser plug-ins which implement the <video> tag for protected
> content - not all that different than selecting a pluggable codec.

I suspect that it would be best to just leave this use-case to Flash.
It would be basically impossible to get the kind of obfuscation that
content owners will want via open standards, because people will just
implement clients that skip the obfuscation.  So you're pretty much
stuck with nonstandard plugins anyway.  This decision could be
revisited if there's still a lot of demand for this once the basic
non-DRM use-cases are covered.

> As several people pointed out (and which I tried to get at in my post), this
> is really an ecosystem issue rather than a change needed in the spec or in
> browsers. ?I suspect it's going to take some time, but the flexibility of
> embedding content via <iframe> will be a big step forward.

Wouldn't it be straightforward for YouTube to offer <iframe> support
right now, in addition to <object>?  The backend support should be
simple to do.  If you keep the <object> code as the default embed
recommendation and hide the <iframe> embed code somewhere so people
will only use it if they look for it, you won't risk confusing anyone.
 Sites that currently whitelist <object> from YouTube will eventually
whitelist <iframe> from YouTube too -- I hope there aren't many sites
that permit *arbitrary* <object>s to be inserted by untrusted users.
Allowing <iframe> will have other benefits, like allowing fallback
"install Flash" content (currently omitted from the <object> code, I
assume to keep the size down).

Another thing that occurs to me is that you might show HTML5 video
when Flash isn't installed/enabled, or when the Flash player crashes.
Or at least you could give an option, instead of just failing silently
(for embeds) or saying the user should install Flash (on the site
itself).  My primary machine runs Linux, and Flash usually doesn't
work at all.  If I didn't know about the HTML5 beta, I wouldn't be
able to use YouTube at all.  And as it is, I can't use any YouTube
embeds most of the time.

> When limiting keyboard input, I'd suggest devices w/ onscreen keyboards
> simply disable the keyboard. ?Applications that work well with touch
> interfaces generally provide gesture alternatives for the limited set of
> keys that would be available. ?Alternately, devices could limit the keyboard
> to the set of allowed keys.

The problem is if the program makes a fake keyboard and then directly
intercepts touch events to that location, without invoking the OS's
keyboard at all.  The user won't be able to tell that the keypresses
are going to the website instead of the OS.  But I can't see this as
being a big issue -- screen space is so limited on these devices that
websites are fullscreen anyway, or practically.  On my Nexus One,
unless you're scrolled to the top of the site, websites take up the
whole screen except for the bar at the top, which is present in all
apps.  So they could already trivially spoof any application, if they
know the target platform.  Not if the user presses the menu button, I
guess.

> As pointed out, this is not strictly an issue for <video> tag, though
> certainly related especially for local preview. ?I have not been closely
> following the work on the <device> element, though that seems to be where
> this is headed.

<device> adoption shouldn't interfere with <video> adoption, though.
Even if YouTube switched to <video> by default, it could keep Flash
for recording until <device> was implemented.  It's probably best for
implementers to focus on perfecting <video> (and maybe <canvas>, etc.)
before they put too much work into <device>, since those are much
bigger use-cases.

Received on Thursday, 1 July 2010 21:16:58 UTC