Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The moral of the story is that if you have in mind something like "The Intel(R) Content Protection HECI Service", which according to their explanation really is intended to connect to intel's servers in order to enforce some restrictions on hardware that I own, then perhaps the best way to go forward is to :

1) not develop it in the first place;

2) if you really need to develop it, not install it on my computer;

3) if you really need to install it, not bundle it and ask explicit permission.

Software connecting to the vendor for updates is one thing; software connecting to vendor with scans of my machine in order to 'ask permission on how to operate' is different. There can be valid uses for this (say, PunkBuster), but that's why they need to come with (a) separate explicit warnings, and (b) option to not install it (even if it will mean 'not being able to play certain premium videos' as Intel explains).

Simply bundling it in without such a question at installation is definitely wrong and should be made illegal - it might already be illegal under EU privacy laws, but I'm not sure.



Perhaps there should be better advertising regulation for tech like Blu-ray that require features like online revocation checks, but Intel certainly isn't the aggressor here, and kicking at its shins for implementing a feature that you paid for seems a bit silly.

I don't like that the dominance of Blu-ray and DVD forced DRM systems upon the mass market, and there's little we can do about it. But more than that, I hate threads (that have been around since the DVD days) full of impotent, righteous indignation. If insufficient people are willing to vote with their wallets (or letters to their governments), then DRM is simply a fact of life we must learn to cope with.

As far as health warnings go, as my original comment mentions, there is little more dangerous in some online DRM check than the 99.99% of other code running behind the scenes on the average user's system. If we're to talk about freedom to use our appliances as we choose, at least frame the argument more cohesively (and include things like Chrome in the process).


Complaining publicly and voting with your wallet are both valid ways to show disapproval. The former method encourages others to vote with their wallet, whereas voting with your wallet by itself is not very contagious.


> there's little we can do about it

Absolute nonsense. We can lobby to have DRM-encumbered media state it explicitly on software packaging, not unlike the poison warnings on cigarette packaging. It's a horrible concept that deserves little else than derision and ridicule.

I'm in favor of a sliding scale of awfulness in DRM -- from simple watermarks, passive interference with gameplay, to always-on spyware. Innocent users get caught up in the DRM shitfest and their experience with the software is severely degraded where it can get so bad that people cannot even use the software/media that they paid for.

I'm not even going to get into the silliness of not owning the software/media that you pay for (eg: buying an ebook where you don't actually own your copy, but instead you're licensing its usage).


As far as I understand, Blu-ray technology as such does not exactly require online revocation checks - if some new AACS content is encrypted with a key that my player doesn't have, then it can't decode it (no 'online' component); but there's no physical need for a player to ever check if some certificate is revoked; a player that can't or deliberately won't check the online revocation list is in all ways superior to a player that uses the list.


Updates can be contained on BR discs. If you try to play the disc, it will update the firmware or certs or whatever.


Reading an updated cert revocation list will only make the player perform worse, i.e., not play some content. Is there any technical reason why a player should not simply discard the new revocation list, and only add any new keys that may be in the updated certificates?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: