# [04:25] <zewt> pritchard's message sure suggests to me that the people designing "web intents" don't understand structured clone transfer at all (but I'll leave it to someone who knows and/or cares about web intents to explain that, in case there really is some weird special property of web intents that makes what he describes not completely wrong)

# [18:08] <jgraham> I still haven't entirely grasped why it is not OK if a video requires a binary component called "Flash" that implements NPAPI, but is OK if it requires a binary component that isn't called "Flash" that implements some CDM API. But I haven't followed the discussion closely so maybe I shouldn't say anything at all

# [18:12] <jgraham> annevk: I still haven't grasped why it is not OK… well I just said that. But I don't see how requiring a binary API that is implemented some places is a win over requiring a binary API that is implemented nowhere

# [18:17] <annevk> jgraham: Apple seemed interested as well, so you can add iOS to that

# [18:19] <Philip`> Also everyone complains about Flash being crashy, which is presumably caused largely by it being very large and requiring lots of low-level platform integration, so it'd be a more technically robust design if you put a minimal amount of code behind a minimal binary API (providing just the encryption support and nothing else)

# [18:22] <Philip`> Also you might want a site that provides both DRMed and unrestricted videos (e.g. Youtube with a subset of videos having special restrictions), and not want to support two totally independent video APIs, so you'd either use <video> plus an optional DRM component (so non-DRM-supporting browsers could still play most of the videos) or you'd use a totally custom plugin-based video API (so those browsers would be locked out entirely)

# [19:32] <hsivonen> Philip`: If the CDM wants to do its own decoding, own painting, virtualization detection, screen recorder detection, etc., it won't be less low-level than Flash or easier to intergrate than an NPAPI plug-in

# [21:09] <AryehGregor> http(s)+aes seems like it only serves the DRM use-case if the key part of the URL isn't exposed to the user, or something like that.

# [21:09] <AryehGregor> But authors can't rely on the browser to do that.

# [21:10] <AryehGregor> Specifically, if the restriction is implemented in open-source code, even if all browsers ship with it (unlikely), it will only be a matter of time before someone writes a patched version.

# [21:11] <othermaciej> ClearKey is not sufficiently specified for me to understand exactly what it does

# [21:11] <othermaciej> but if it's meant to support key rotation, then http(a)+aes is not equivalent

# [21:11] <AryehGregor> If the goal is to stop the user from getting a copy of the video, the best solution that's implementable in open-source seems like site-specific obfuscation of the underlying HTML and transport, like using transparent divs to block "Save As" and using one-time URLs so that grabbing the URL from the source won't help.

# [21:11] <othermaciej> likewise if it's required for encryption to be inside the container instead of outside

# [21:12] <AryehGregor> Anything further seems unlikely to be implementable in open-source software. On the other hand, if you make it moderately inconvenient to extract the video from the site, it should be no problem, as long as a) it's at least as inconvenient as using BitTorrent, and b) the content is already available on BitTorrent.

# [21:13] <AryehGregor> Then again, that's being rational, and the content owners are not necessarily being rational here.

# [21:43] <AryehGregor> And then another one that falls back to Flash cookies or something.

# [21:43] <Philip`> Would you end up using any of SQLite beyond its SQL parser/optimiser?

# [21:43] <AryehGregor> Philip`, of course. You'd use IndexedDB by storing the entire SQLite database as one big database entry. Or alternatively, by storing each page as a separate database entry in a flat table.

# [21:44] <jgraham> Maybe you could also make the backend one of these virtual-filesystem APIs that people have started developing

# [21:44] <AryehGregor> I mean, abstraction layers are no fun if you don't reimplement the same abstractions at multiple levels so that you get all the inefficiency but none of the convenience.

# [21:44] <jgraham> Although I guess they will take longer before they are universially avaliable

# [21:45] <AryehGregor> That's why you have a polyfill that falls back to IndexedDB, then localStorage, then Flash cookies, then synchronous XHR to a server back-end that stores user-specific data based on an id.