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.
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.
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.
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/
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.
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.
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.
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.
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!
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.
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.
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.
[+] [-] _wmd|12 years ago|reply
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.
[+] [-] PeterisP|12 years ago|reply
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.
[+] [-] weland|12 years ago|reply
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.
[+] [-] wahsd|12 years ago|reply
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.
[+] [-] rbanffy|12 years ago|reply
[+] [-] eliasmacpherson|12 years ago|reply
[+] [-] robin_reala|12 years ago|reply
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.
[1] https://communities.intel.com/message/205908#205908
[+] [-] alphakappa|12 years ago|reply
[+] [-] snsr|12 years ago|reply
http://blogs.intel.com/technology/2011/01/intel_insider_-_wh...
[+] [-] rorykoehein|12 years ago|reply
[+] [-] georgeott|12 years ago|reply
[+] [-] rjknight|12 years ago|reply
Problems?
[+] [-] toyg|12 years ago|reply
[+] [-] insom|12 years ago|reply
[+] [-] VMG|12 years ago|reply
> The site's security certificate is not trusted!
[+] [-] jwr|12 years ago|reply
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.
[+] [-] lgeek|12 years ago|reply
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/
[+] [-] jameshart|12 years ago|reply
[+] [-] wzdd|12 years ago|reply
Intel's answer shows that they can and also covers the (mild) consequences.
[+] [-] fat0wl|12 years ago|reply
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.
[+] [-] rbanffy|12 years ago|reply
I really can't understand the reason to make such a fuss.
[+] [-] ryanthejuggler|12 years ago|reply
[+] [-] tim_hutton|12 years ago|reply
[+] [-] teddyh|12 years ago|reply
Is this not the very definition of software in binary-only form?
[+] [-] buren|12 years ago|reply
[+] [-] reidrac|12 years ago|reply
[+] [-] ck2|12 years ago|reply
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.
[+] [-] toyg|12 years ago|reply
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.
[+] [-] girvo|12 years ago|reply
[+] [-] larrik|12 years ago|reply
[+] [-] alexwright|12 years ago|reply
As far as video hardware goes Intels is far more open than the other two vendors of actual useful video hardware anyway.
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] mortyseinfeld|12 years ago|reply
[+] [-] acqq|12 years ago|reply
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.
[+] [-] corncobpipe|12 years ago|reply
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.
[+] [-] Rockdtben|12 years ago|reply
[+] [-] jcromartie|12 years ago|reply
[+] [-] quesera|12 years ago|reply
[+] [-] redblacktree|12 years ago|reply
[+] [-] veganarchocap|12 years ago|reply
[+] [-] Revisor|12 years ago|reply
http://intelmanagementengine.com/intel-technologies/all-abou...
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.
Needless to say, I'm not very happy about it.
[+] [-] timje1|12 years ago|reply
[+] [-] jotm|12 years ago|reply
So duck these kinds of software/services that the owner of the hardware "doesn't need to know/worry about".
[+] [-] mcguire|12 years ago|reply
"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.
Thanks, Intel!
[+] [-] chadwickthebold|12 years ago|reply
[+] [-] wooptoo|12 years ago|reply
[+] [-] skdjf|12 years ago|reply
If someone els is running software on your system, it's not your system anymore.