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.
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.
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.
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.
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?
Thank you all for your patience. We were able to get complete clarification on the services that were installed and running. The first service in question was the Intel(R) Content Protection HECI Service.
That service does the following:
The Intel(R) Content Protection HECI Service is used to enable premium video playback (such as Blu-ray) for Intel® HD Graphics. It does not collect any user information. Disabling the service will prevent certain types of premium video from playing on the system; however, unprotected video such as user-generated content and YouTube videos will continue to play.
The second service in question was the Intel(R) Integrated Clock Controller Service.
That service does the following:
“Intel(R) Integrated Clock Controller Service - Intel(R) ICCS” is a service used for accessing the integrated clock controller in the PCH to adjust the clocks to the CPU (BCLK, DPCLK, and DPNSCLK). The graphics driver uses this service to adjust the graphics clocks (DPCLK & DPNSCLK) to perform clock bending. Clock bending adjusts the display clock frequencies to reduce screen flicker. Originally access to the ICC registers was only available internally to the PCH’s embedded controller (ME) so the registers were exposed to host through the HECI interface. On Intel® 8 Series PCHs and beyond, the HW has changed allowing the graphics driver to directly access the display clock registers, and the “Intel(R) Integrated Clock Controller Service” should not be necessary with those chipsets.
In addition the “Intel(R) Integrated Clock Controller Service” is used by the Intel eXtreme Tuning Utility (XTU) to perform overclocking. Overclocking is more complicated with its larger frequency range and dynamic configuration, so the PCH’s embedded controller and SW service are used to abstract the ICC implementation.
Disabling “Intel(R) Integrated Clock Controller Service - Intel(R) ICCS” on Intel 8 Series PCHs will only impact the ability to do runtime overclocking with the XTU. With older chipsets, it will also disable the ability to do clock bending (meaning you may get additional screen flicker).
“Intel(R) Integrated Clock Controller Service - Intel(R) ICCS” does not collect any information.
We apologize for any confusion or misleading that may have been created by not having this information posted at an earlier time.
Makes me wonder why it's being bundled with drivers instead of being a stand-alone software package. I could see the argument that it's somewhat related to the usage of video cards, but it's a shitty argument with little basis.
Having once worked for Intel, that seems about normal for vital information to pass from one fiefdom to another. The poor sap manning the forum wasn't saying "we're not telling you", he was saying "they're not telling me".
(Now, if the other guy thinks you're encroaching on his turf, the response time approaches infinity. In that case pretending to be a member of the public on a forum might be an effective strategy; if I'd listened to Andy and thought of it myself I might still be there.)
I don't think it changes anything whether they say what their software does or not. You run their software in binary form, having no idea what it does. You have no way to verify whether what they say is true.
Mind you, I use Apple machines, so most software that I run comes in binary blobs and I have no idea what it really does. But it wouldn't matter to me what Apple "said" about it. What matters is what Apple does, and most importantly, where I they make money and where their strategic interests lie. This is what I base my (very limited) trust on.
> You run their software in binary form, having no idea what it does. You have no way to verify whether what they say is true.
Sorry, but it's a bit tiring seeing this blanket statement. You can absolutely verify what closed source software does. starting from low tech approaches:
* dissasembly, decompilation and debugging. This is standard old-school reverse engineering. Native code / bytecode is source code, it's just not optimised to be read by humans. :)
* monitoring systemcalls - on Unixes you have strace and other similar tools which allow you to monitor all the systemcalls of an application. This should show all interactions with local and remote data.
* dynamic binary analysis - tools like DynamoRIO and Pin run native code in a system similar to a JIT engine. You can transparently add code which will report what the application does.
* data tracing - using dynamic analysis or managed languages. Data can be tagged based on source (e.g. treating input from files as sensitive) as it is being processed by an application. When that data is pushed outside the application using systemcalls, you can determine where it was coming from, even if it's encrypted or obfuscated. There is a project which implements this on Android (and the results are quite scary): http://appanalysis.org/
That's a valid point, but there's a difference between what software does, which you're recommending you divine based on historical activity, and what it can do, which remains unknown.
Even disassembling provides only a limited view into the code itself. If this method worked every time, we wouldn't have viruses. There are ways of concealing the true functionality of a piece of code to make disassembly and interpretation extremely difficult.
Granted this is true with pure source code as well, but usually subversive code is much more obvious. This is not always the case, though.
You're right about this. Dynamic analysis instance is only useful if the application goes on to the relevant execution path, and static analysis is made quite difficult by dynamic generation and a few other tricks.
However, if hidden behaviour (e.g. backdoors) is a concern, you can implement fine grained access control based on historical activity.
Anyway, my point is that for almost every problem in this area there's a solution. But I think the main issue is that there isn't more pro/consumer software for this kind of auditing / sandboxing. I guess that has to do both with user education (no interest) and industry being afraid of transparency.
Access control is going to be pretty hard to implement for something like EFI firmware, CPU microcode, or other forms of embedded software.
As much as people whinge about sandboxing, I think it's a great idea and hope there's more of it. Apple's model for OS X where certain kinds of apps come with certain limitations, but there is a switch for people to opt out of those restrictions, is a great compromise. Safe for users with limited technical ability and wide open for those that need it.
Actually, the only interesting behaviors all involve phoning home at some point. That's where a product like Little Snitch comes in handy - whatever it is (including OS updates), you can see what is accessing the outside world. It turns out this is actually pretty good way to detect bad stuff.
If a company supplies you software that they claim does one thing, but actually does another thing, you might have some legal recourse if you run it on the basis of their assurances that it only does the first thing. If on the other hand they refuse to tell you what the software does, but you run it anyway, you can hardly complain when it turns out to do something you didn't want it to.
I wouldn't trust my friend just for bending me over, kicking me in the ass, & taking $80 out of my wallet every time I asked him for help with a shiny device he sold me.
aha it figures that HN readers are apple fanboys with no sense of humor. this is the only time i've ever made a joke on here that got downvoted & stuck
Since it's binary-only closed-source, even if they told you what it does, you'd have to take their word for it. Whatever the two new services are, for all you know, they could be things the drivers already did, just now they are neatly organized as Windows services and not just built into the driver itself.
I really can't understand the reason to make such a fuss.
It makes me uneasy how pervasive DRM is becoming and how it's infiltrating lower and lower levels of hardware. We're already 90% of the way to not actually owning our own machines anymore.
Media-consumption devices are the problem. If the primary aim of your device is to consume media (and that's what tablets are for), then DRM playback is socially unavoidable at this point. DRM begets DRM, and lo...
Unless you are talking about metaphysics/teleology, the only difference is levels of description. What software does is what software does.
The difference between a binary and source code is just level of description. A binary is obviously very hard to understand, but it is just instructions to the computer, and those instructions can be interpreted by following them logically according to the hardware documentation. This is true all the way down to the OS.
Of course, you have to trust that the hardware does what it says it does... I guess you could always break out the oscilloscope...
"It's an 8 inch chef's knife in a stain-resistant steel"
and
"It's an 8 inch gyuto-style chef's knife, which is thinner and lighter than the German style knives, but tempered to a higher hardness. This one is hardened to RC-57 (soft for the genre), ground from a hot-forged steel with 1.03%, carbon, 13.06% chromium, 0.37% nickel, and 0.28% nicklel, heated to 1000 degrees to promote austenization, and then oil quenched to form a highly martensitic steel, with moderate levels of pearlite and low levels of cementite. The temperature is then raised to 230 degrees and held until the stress from the quench is relieved. The chromium compounds are relatively coarse, similar to A-1, with a similar effect on the edge. The edge is then wet ground.... etc, etc, etc."
A metallurgist or good blacksmith would be able to write hundreds more pages about a kitchen knife and the processes involved in it's creation.
[Note, I am not a metallurgist. The description, I think, is mostly right, although I may have some of the phase transitions and temperatures wrong. Corrections are welcome.]
The difference is that software is always in an environemnt where any small deviation from the "common sense" approach can lead to disastrous consequences (intentional or not).
I'm not sure how that's different from many other forms of engineering. For the example I gave, bump the temperature you hold it at after quenching by 20 degrees, and it will shatter because it hit the TME (Tempered Martensitic Embrittlement) stage. Hold it above that temperature by 80 degrees, and it won't hold an edge, although it will be ductile. Increase the amount of carbon by 0.5%, and it will be remarkably brittle and weak. Decrease it by 0.5%, and it will be extremely soft and won't hold an edge. etc, etc.
A knife is fairly unimportant, but make the wrong decisions of that sort on a plane, or on a bridge, and people will die.
Even more subtle decisions can have serious consequences. See, for example, the DeHavilland Comet, which crashed because the windows were too square.
The squareness was causing them to act as stress concentrators. With the cyclic loading from pressure changes, this caused metal fatigue, and the windows would fail after hundreds of flights. This could be fixed by rounding the corners of the windows, or by using alloys that don't fatigue as easily. And this is why modern jets have rounded portholes, instead of rectangular windows.
But you can test what the gas pedal does pretty easily. I think parent's point was that without peer review source code audit, we just have to take it on trust.
The analogy doesn't hold because gas pedal's tend to do only one thing. A binary blob can do anything. A better analogy would be what some random wire in your car does... but even then if you know where the wire is located you can reason what it probably does. In this case a binary blob can't as easily be inferred.
I think it goes one step beyond that: you're asked to accept an EULA for a software that you don't know what it does or why it needs to be installed and run... because the vendor refuses to tell you! Amazing.
Well, you accept [probably non-legally binding, at least I always assume that] condition for a driver for your hardware.
Anything else they don't get specific permission for is a breech of the law here (UK, Computer Misuse Act) ... would love to see that prosecuted.
The government should lead such a prosecution really given how important unauthorised computer use/access is to them - extraditing people for it and all.
This is a good point - if it happens to transfer private data and it didn't explicitly say in the EULA that it's going to do so, then they are violating a bunch of laws.
On the other hand, if an EULA for video card drivers starts including language about transmitting your data, then you already know what it means.
Linux adoption might get a serious kick the in pants if mainstream news started reporting that Intel was installing unknown drivers in their cpus.
I am just about ready to switch to linux for desktop after windows xp updates cease. I've been using it for over a decade in the server environment so it is overdue.
"Linux adoption might get a serious kick the in pants if mainstream news started reporting that Intel was installing unknown drivers in their cpus."
Because the general population cares so much about understanding what their computers do, right? I don't give a damn about what my car engine does, as long as it gets me from A to B without exploding.
Linux adoption will dramatically increase only if this sort of software starts making serious trouble for final users, like refusing to play unlicensed MP3s or deleting your family videos because they were encoded with unlicensed tools. They are not that stupid... yet.
Well as TPP showed Hollywood demands are insatiable. So if we have in Windows 10 - Microsoft Genuine Media Advantage Validation that makes the built in antivirus to mark unsigned mp3-s and mp4-s as viruses I won't be surprised. That is assuming you could load your own files on windows machine by that time.
If your gas price changed on where you drove and a handful of government agencies were kept apprised of your location at all times and sometimes the car just refused to take a certain street, you might start having an interest in what's inside your car.
I've been running Linux on the "desktop" since 2006, and it's well worth the switch, in my opinion. Especially now, considering how streamlined most hardware configs are!
When there is a microcode blob update, there is nothing to guarantee it does only what it's supposed to do. The problem is not with GPUs - it's with software (writable microcode is after all, software) that you cannot understand.
Unknown drivers? How much do you know about any of the other drivers for any of the hardware? Most NICs and Video chipset drivers now come with a binary blob you have to feed it, it's completely opaque binary microcode.
As far as video hardware goes Intels is far more open than the other two vendors of actual useful video hardware anyway.
On my new notebook I have some more services and drivers from Intel (even firefox add in!) that allow "remote management" and "remote authorization" they are potentially even more worying. The hardware and drivers are supposed to allow Intel to manage my notebook?
The notebook is made by Acer. If any company which has own drivers can have remote access or have their hardware and/or drivers phone home with the data from us, we're really in trouble.
Yesterday we've found that LG TV sets push to some servers all the filenames on the local USB seen by the set. The comming years are going to be hard.
So I also have these Intel services for which I don't know the whole purpose:
-Intel Capability Licensing Service Interface
-Intel Dynamic Application Loader Host Interface Service
-Intel Management and Security Application Local Management Service
-Intel Managementand Security Application User Notification Service
I also observe that in the folder with HeciServer.exe that is in c:\Program Files\Intel\iCLS Client\ there are also iclsClient.dll and iclsProxy.dll but also openssl libraries and certificates, so obviously at least Intel's HeciServer phones home.
Even stranger, all these services add immense amount of additional entries in PATH, because there are 32 and64 bit versions and they need all every folder thaey use (and they use a lot) in the PATH. Which also means that they somehow don't know what they are doing as with manifests they wouldn't need PATH entries for DLLs at all. And I can't imagine that one service invoke command line for another one.
For what it's worth I've been trying to get NVIDIA to tell me what "NVIDIA Capture Server Proxy" service does for a few days. It recently got installed and if you search NVIDIA's website get get nothing.
I did a chat with a NVIDIA tech and they said "It is related to shadow play. please do not worry about it"
I asked for some documentation and they replied "These are development application so we do not have any documentation on this"
Uh, wtf?
I've recently figured out what 'shadowplay' is but the lack of documentation and reluctance to talk about the service is disturbing.
I've heard several non-native English speakers use that phrase. It's off-putting, but my experience is that it is not indicative of the speaker's technical knowledge.
Today I found out I inadvertently bought an Asus motherboard with a service called "Intel Management Engine Interface" (mei) which "enables remote accessing to the PC including the management, monitoring and maintenance irrespective of the operating system state and PC power state as well".
It sounds to me like an official backdoor and I only found out about it because it conflicted with suspend to RAM. I removed the kernel modules for this service but couldn't find a way to disable it in BIOS.
Surprisingly - the product page doesn't contain any information about the presence of MEI whatsoever.
Oh, this is quite cool when you're in a corporate environment. It originated from servers (iRMC and others) and is now a cheap alternative to additional hardware monitoring cards.
I understand that it's pretty nifty in corporate environments. At the same time, however, it sounds an awful lot like a backdoor that works even with the PC turned off.
Are the 'intel employees' the ones with _intel in their usernames on this forum? These users aren't even marked as admins, just normal members... This doesn't inspire confidence in these answers.
My HP laptop had a similar issue: the fingerprint software (made by Authentec, owned by Apple) wanted an online connection for no good reason (I blocked it with a firewall), and the control buttons software used to run a dozen instances of a "DownloadAD.exe", taking up to 500 MB of RAM for no reason whatsoever (I deleted the executable).
So duck these kinds of software/services that the owner of the hardware "doesn't need to know/worry about".
"There is not a certain way the Intel Content Protection HECI Service, and Protection FW Intel Integrated Clock Controller Service can be explain what they really do. That information is kept with the engineers.
"Also for the proper functionality of the graphics driver, I would not recommend you remove them."
And I just got my new answer for technical questions that I don't want to deal with.
Those who want's a TL;DR probably wants a correct one.
Intel(R) Content Protection HECI Service
The Intel(R) Content Protection HECI Service is used to enable premium video playback (such as Blu-ray) for Intel® HD Graphics. It does not collect any user information. Disabling the service will prevent certain types of premium video from playing on the system; however, unprotected video such as user-generated content and YouTube videos will continue to play.*
Intel(R) Integrated Clock Controller Service
“Intel(R) Integrated Clock Controller Service - Intel(R) ICCS” is a service used for accessing the integrated clock controller in the PCH to adjust the clocks to the CPU (BCLK, DPCLK, and DPNSCLK). The graphics driver uses this service to adjust the graphics clocks (DPCLK & DPNSCLK) to perform clock bending. Clock bending adjusts the display clock frequencies to reduce screen flicker. Originally access to the ICC registers was only available internally to the PCH’s embedded controller (ME) so the registers were exposed to host through the HECI interface. On Intel® 8 Series PCHs and beyond, the HW has changed allowing the graphics driver to directly access the display clock registers, and the “Intel(R) Integrated Clock Controller Service” should not be necessary with those chipsets.
In addition the “Intel(R) Integrated Clock Controller Service” is used by the Intel eXtreme Tuning Utility (XTU) to perform overclocking. Overclocking is more complicated with its larger frequency range and dynamic configuration, so the PCH’s embedded controller and SW service are used to abstract the ICC implementation.
Disabling “Intel(R) Integrated Clock Controller Service - Intel(R) ICCS” on Intel 8 Series PCHs will only impact the ability to do runtime overclocking with the XTU. With older chipsets, it will also disable the ability to do clock bending (meaning you may get additional screen flicker).
“Intel(R) Integrated Clock Controller Service - Intel(R) ICCS” does not collect any information.
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.