3 ms·

Why do people think it matters what they say? I don't think it changes anything whether they say what their software does or not. You run their software in bin

by jwr 13y ago

Why do people think it matters what they say? 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.

jameshart 13y ago
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.
wzdd 13y ago
In this case, it specifically matters because people want to know if they can safely disable it. Intel's answer shows that they can and also covers the (mild) consequences.
fat0wl 13y ago
You base your trust on Apple's behavior? 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.
- fat0wl 13y ago
  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
lgeek 13y ago
> 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/ http://appanalysis.org/
- astrodust 13y ago
  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.
  - lgeek 13y ago
    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.

by jwr 13y ago

jameshart 13y ago

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.

wzdd 13y ago

In this case, it specifically matters because people want to know if they can safely disable it. Intel's answer shows that they can and also covers the (mild) consequences.

fat0wl 13y ago

You base your trust on Apple's behavior? 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.

fat0wl 13y ago
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

lgeek 13y ago

> 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/ http://appanalysis.org/

astrodust 13y ago
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.
- lgeek 13y ago
  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.