Hacker News Reader

Comment by _wmd | Hacker News Reader

The moral of the story here for developers is, if you present the user with some scary string they don't understand, they'll overreact and do rash things like disabling chunks of your working, tested software, and probably accuse you of being in bed with Holywood and the NSA in the same sentence. Better to just bury the DRM bits so nobody would ever notice, saves a few hundred threads over the lifetime of your product relating to random crashes caused by machines with chunks of your code in a disabled/inconsistent state.

The moral of the story for users is, you should be used to this. 99% of the code running (or regularly updated) on your machine has no scary labels attached to it. You're running Chrome? Well, they're pushing fancy new ways to fuck with your privacy every day. They just don't install services named things like "address bar keylogger service", "automatic upload your bookmarks service", "youtube DRM service" or whatever else.

View on HN

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?

I don't mean to go all Richard Stallman (who is looking less and less like a crackpot every day!), but the moral of the story for users is, you should not install anything that is not open to the scrutiny of the community. If the source is not available, anything could be in there. Intel decides to give include a virus that wipes your hard drive in the next update? Yeah, well, good luck.

I'm not saying that having the source available is a guarantee because every user will definitely read it. I'm saying having the source available is a guarantee because, when a developer notices a weird service on his computer, he can immediately check out what it does instead of depending on Intel for it.

The real risk that I see is less malice on the part of anybody at Intel, but that some third party could inject some nasty binary into the nice binary and we would have no way of knowing.

Web servers get hacked every day. If somebody gets in and quietly replaces one binary blob with another binary blob, good luck detecting it. Malicious source code is way easier to detect.

This is much in the same vein as basically EVERY piece of software on Windows. We have no recourse in auditing the safety of our own systems.

Yeah 99% of the time the software is benign, but then again so are the police. Personally, I have no reason to mistrust US police. Nonetheless, free states the world over demand recourse against them should they cause harm intentionally or through negligence; I demand the same from my software.

Spoken as a true engineer, ignorant of human interaction. That is not meant as an insult, it's rather an unfortunate observation.

The far better "moral of the story" or lesson should be to improve transparency and documentation and explanation. The only thing that comes from deception through obfuscation is an exponential impact upon discovery of sneaky actions.

This is a larger issue in many, if not all engineering communities; the inability to relate to anyone outside of their community of peers. It is why we get horrible documentation, why we get horribly designed-by-engineers products and structures, etc.

As much as we all know engineers are not exactly people persons, know your engineering strengths, but acknowledge and request assistance for your weaknesses, i.e., everything not engineering domain related, especially when it involves human interaction.

There's no shame, just acknowledge weaknesses and defer. And no, people are not the problem.

Better - misname your modules. So, instead of "Bad-for-you spyware", you call it "Power management you should never disable, ever".

Oh, you thought "power management" was for your battery... That's a common mistake.

It's how the ruling elite manages their power. Thank you for your (enforced) cooperation.

I am aware of google messing with Safari cookie setting and getting fined for it, but I am not aware of any fancy new ways or old ways of messing with someone's privacy in Chrome. Can you elaborate on your accusation?

Reply on news.ycombinator.com