I have no problem with the DRM. Well, actually I do, I would never buy DRMed content, but I understand the need for it - it's hard to convince content publishers that DRM is from a practical point of view pure BS - the ones that care not to pay (pirates and pirated content consumers) will still get that content one way or the other, while the legit paying customers will be treated as criminals upfront and will have a big inconvenience in consuming their rightfully owned/licensed content (it actually makes legit customers to turn to pirates from time to time when they cannot get the content they paid in a way they want). So, since most (luckily not all) content providers go haywire when they hear `the platform is fully open and supports no DRM of any kind`, one has to cater to their needs if they are to come to their platform. Yes, it's stupid, all the things I said still stand, but do you really think that some manager that decides about those things from some major content provider even knows the problems with DRM or how it works? No, he has instilled mantra `no glove (DRM), no love`, and in today's market if you want to draw people to your platform you need to have plenty of content available on it. That's just the way it is.

What I have a problem with is the way it is to be implemented, judging from that wiki page - you need to use a different kernel for `opened` and for `closed` mode. That's even more of an inconvenience than the DRM itself. There are plenty of ways to implement DRM (at the expense of CPU/memory, tho) without killing the openness. After all, typical DRM implementations work on widely opened and documented types of encryption - it's the keys that are kept as secret. What I'd propose is to move the DRM support from the kernel into additional software layer (or at least a kernel module that can be loaded/unloaded run-time), just the way it is on today's computers. There are plenty of ways to do that, from encrypted partitions/folders, to real-time checking with DRM servers (after all, it's meant to be `always connected`), to hardware implementations. All of which wouldn't require you to boot into a different kind of system whenever you want to consume DRM content, and would allow you to enjoy the openness and the DRM content at the same time.

I hope that the people that decide about that have thought long and hard about the implications and inconveniences that could come from dual-kernel system as a DRM implementation. I'm not sure that they could even do that given the GPLv2 on the linux kernel.

edit: Sorry, qgil, just saw your post. If I have something more to say about the security implementation I'll take it there.