Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why We Can No Longer Trust Microsoft

pcmag.com

Post reply on HN
Print view View original

211–220 of 310 posts

Re: Why We Can No Longer Trust Microsoft

#211

Post by Ygg2 »

yuhong wrote: post #80
bad_user wrote: post #77

Earlier quoted context omitted.

What really bothers me about this is not the actual spying - I always assumed that governments do engage in whatever spying they can get away with. What really bothers me about this is that U.S. companies and individuals have to keep their interactions with the NSA a secret, while obeying whatever demands the NSA has, including the installing of back-doors. Trust is a fragile thing and we rely on trust for conducting…

>however the damage done to U.S. companies will prove to be massive. Will?

It probably already has, in lieu of current European rattling.

I don't expect that GOOG or MSFT will suffer any damage in short term. But in long term they have proved unreliable. This erodes confidence. And if it keeps eroding, it will eventually cause them to collapse.

I'll be doing my earnest to move away from any non-OS tool. And will advocate others to do so as well.

Re: Why We Can No Longer Trust Microsoft

#212

Post by leopoldfreeman »

prewett wrote: post #182
leopoldfreeman wrote: post #122

The reason is obvious in China. Google is blocked by GFW, but Bing is not. So, there must be some dirty business between Microsoft and government of China. If Microsoft can do this in China, they can do this anywhere, even in USA.

The dirty business is that Microsoft is willing to cooperate with the Chinese government and censor its search results. Google publicly pulled out of China precisely because it was unwilling to do that. Even so, China did renew Google's Internet license, and they do run ditu.google.cn (un-offsetted maps, possibly only accessible from within China). Google is not actually blocked by the firewall. Gmail is slow, occasi…

Censor its search results? You mean Microsoft cope with the government to filter the result. Great! Today they filter the results. Tomorrow they will share the user data with government. You are right, Google is not actually blocked by GFW. If you search something the government think it's sensitive (just they think), they will block you from Google for serveal minutes. After that, you can connect to Google again. I say, what the hell is that? Fuck the government.

Re: Why We Can No Longer Trust Microsoft

#213

Post by flexie »

sageikosa wrote: post #201
flexie wrote: post #180

Earlier quoted context omitted.

Fighting unconstitutional laws in the phony secret "court" set up by the same laws is not really fighting, is it? It's sort of accepting the terms. Take the battle to the real courts and ask them to decide on the matter.

Unfortunately, those are real courts, their functions and jurisdictions have been established by the Congress.

If congress can redefine courts into what is basically an administrative panel, then the entire separation of powers can be short-circuited.

It's not a court just because congress says so.

Re: Why We Can No Longer Trust Microsoft

#214

Post by brudgers »

cs702 wrote: post #169

GNU/Linux, and Free software and hardware in general, look to be the BIG winners out of the NSA brouhaha, because all non-US governments, businesses, organizations, and individuals around the planet who need to safeguard their private or confidential information now have reason to mistrust proprietary (unauditable) software and hardware. Free, open software and hardware are less likely to have secret 'back doors' ins…

It would be grossly unprofessional of the three-letter agencies if they should have failed to run counter-intelligence operations upon the open source communities. Futhermore, given their resources to hire hackers and long history of infiltrating loosely affiliated organizations, it is hard to image that they have struggled to place moles deep within many critical projects.

Open source communities have no membership committee or state-funded security apparatus. Contributions are accepted based on trust and trust is established by technical merit. The means the three-letter agencies used against Microsoft and other corporations are not the only strategies they have available.

Maybe Linus doesn't have a price. I hope so and I trust him. But regardless of my trust and hope, there is no verification. My trust still acknowledges that no one is scanning Swiss accounts for activity which might be linked to him - and even if there were someone doing so, what would be my basis for trusting them?

Again, I'm not saying I don't trust in the integrity of Linus, but it's hard for me to trust everyone contributing to my Linux distro. Patriots and mercenaries can contribute to open-source just as well as anarchists and Samaritans.

Microsoft's closed source model required a more transparent method to subvert [more transparent than a black operation]. Subverting open source requires little more than a clever branch and merge with a veneer of social engineering. The fruit is so low hanging that merely singing the Open-Source Internationale, will get one street cred. Anyone who thinks they are immune, isn't. This is state level resources - put a man on the moon and bring down communism scale.

Re: Why We Can No Longer Trust Microsoft

#215

Post by acqq »

dllthomas wrote: post #206
acqq wrote: post #194

Earlier quoted context omitted.

how well can you trust the commercial ones ? At least with open source, you can look into it more easily and eventually find security holes. It's a step towards trust. There is no trust to gain with commercial solutions, but at least with open source, it's at least possible. Ever heard of reverse engineering? It turns out you'd need even that approach even with open source as soon as you use binaries you haven't comp…

"Ever heard of reverse engineering? It turns out you'd need even that approach even with open source as soon as you use binaries you haven't compiled yourself." This is true: reverse engineering can be used for verification, but it's a whole lot more work than inspecting source. "And you'd have to verify the compiler and your disassembler that way too." This is false. You can verify the compiler with diverse double c…

Am I missing something: does it mean that to verify the compiler with DDC you need a trusted compiler that always produces the same binary output as an untrusted one, so to verify GCC you need a compiler that duplicates the whole GCC functionality but is trusted? What is practicality of that approach? Proving that "hello world" produces the same output doesn't prove that the crypto functions wouldn't be patched?

Please a specific example of what would be needed to prove GCC and LLVM now.

EDIT: I'm not interested in toy compiler and theoretical pie-in-the-sky examples, I want to know how practical it is for the systems in real use. GCC and LLVM as they are now please. If the proposition is "suppose that we have something that can compile gcc sources and we trust it" tell me what is that, does it exist and how hard would it be to make it. Don't talk to me about your experiment where you change one line in TTC and then prove it's changed by comparing the binaries.

Re: Why We Can No Longer Trust Microsoft

#216

Post by npsimons »

Intermernet wrote: post #53
twentyfourseven wrote: post #44

Earlier quoted context omitted.

Let's boycott the hell out of Microsoft. They gleefully sold out their users to the NSA.

As long as you also "boycott the hell" out of: Yahoo Google Facebook PalTalk YouTube Skype AOL Apple Who have also been mentioned as complicit in this whole scandal. Just to be fair :-) By the way, I actually agree with you and have been slowly switching all my home stuff to linux and trying to get away from Google Dependence (although I type this in Chrome on a Win 8 laptop... damn work computer)

As long as you also "boycott the hell" out of:

Yahoo Google Facebook PalTalk YouTube Skype AOL Apple

Done and done (including Microsoft) for well over a decade; I don't get this whole "can't be trusted anymore" thing. These companies could never be trusted, and never should have been.

Re: Why We Can No Longer Trust Microsoft

#217

Post by acqq »

dllthomas wrote: post #208
acqq wrote: post #196

Earlier quoted context omitted.

Just believing "somebody would see it" is provably not enough. http://www.schneier.com/blog/archives/2008/05/random_number_... The bug was introduced in September 2006. Discovery published May 2008. Affected: the most popular Linux distribution, all the keys generated on it in that period. Scary. Moreover, the bug was not found by reading the source code. The keys generated by all the existing system were analyzed. I…

But the odds it will be found (and publicly acknowledged) is higher than with closed-source software. Availability of the source is not a substitute for audit and care, but is helpful and you're not guaranteed audit or care with closed solutions.

The mentioned bug was not discovered by reading sources. The sources were available for one and half years and were used for the most popular Linux distributions. What can we expect for less popular ones then?

I'm not saying that it's better to have closed source, even if we can discuss that too when we consider how often the changes are introduced (for security: the less often the better provided the start is good enough) I'm saying that just believing something is secure simply because "it's open source" is pure hand waving.

Re: Why We Can No Longer Trust Microsoft

#218

Post by dllthomas »

acqq wrote: post #215
dllthomas wrote: post #206

Earlier quoted context omitted.

"Ever heard of reverse engineering? It turns out you'd need even that approach even with open source as soon as you use binaries you haven't compiled yourself." This is true: reverse engineering can be used for verification, but it's a whole lot more work than inspecting source. "And you'd have to verify the compiler and your disassembler that way too." This is false. You can verify the compiler with diverse double c…

Am I missing something: does it mean that to verify the compiler with DDC you need a trusted compiler that always produces the same binary output as an untrusted one, so to verify GCC you need a compiler that duplicates the whole GCC functionality but is trusted? What is practicality of that approach? Proving that "hello world" produces the same output doesn't prove that the crypto functions wouldn't be patched? Plea…

You're missing something.

The idea is to take one compiler source (S), and compile it with a diverse collection of compilers (Ck being a compiler in C0-CK), producing a diverse collection of binaries that are compilations of S: (Bk = Ck(S)). Because the different compilers are almost certainly not functionally identical, the various Bk should not be expected to be bitwise identical. However, because they are compilations of the same source, they should be functionally identical, or one of the original compilers was broken (accidentally or deliberately). So now we can compile that original source with the Bk compilers, and because these compilers are functionally identical, the results (Bk(S))should be bitwise identical. There is certainly some chance of false positive, due to bugs in the Ck compilers or exploitation of undefined behavior in S, but if you do get the same output (Bk(S)) from all of the (Bk) compilers then you can be pretty confident that there is no Trusting Trust style attack present: exceedingly so, when the various compilers have diverse histories so that it's exceedingly unlikely that all Ck compilers contain the same attack. If there are any differences, you can manually inspect them to determine what the issue is and either issue a bug report to the appropriate compiler, change the source (S) to avoid undefined behavior, or notify people of the attack present in the compiler in question, depending on what you find. This does involve some binary digging, but quite targeted compared to a full audit and it may well not be necessary at all.

Obviously, if you do have a trusted compiler, including it in the mix is great, but the technique doesn't rely on this, nor on any two compilers returning the same binary output except when they are compilations of the same source.

Re: Why We Can No Longer Trust Microsoft

#219

Post by bentcorner »

brudgers wrote: post #214
cs702 wrote: post #169

GNU/Linux, and Free software and hardware in general, look to be the BIG winners out of the NSA brouhaha, because all non-US governments, businesses, organizations, and individuals around the planet who need to safeguard their private or confidential information now have reason to mistrust proprietary (unauditable) software and hardware. Free, open software and hardware are less likely to have secret 'back doors' ins…

It would be grossly unprofessional of the three-letter agencies if they should have failed to run counter-intelligence operations upon the open source communities. Futhermore, given their resources to hire hackers and long history of infiltrating loosely affiliated organizations, it is hard to image that they have struggled to place moles deep within many critical projects. Open source communities have no membership…

Is there any evidence of this? Certainly there is a single hacker out there that has been approached by the gov't or contracted for them for these purposes at some point, that is also willing to talk, even anonymously.

Re: Why We Can No Longer Trust Microsoft

#220

Post by dllthomas »

acqq wrote: post #217
dllthomas wrote: post #208

Earlier quoted context omitted.

But the odds it will be found (and publicly acknowledged) is higher than with closed-source software. Availability of the source is not a substitute for audit and care, but is helpful and you're not guaranteed audit or care with closed solutions.

The mentioned bug was not discovered by reading sources. The sources were available for one and half years and were used for the most popular Linux distributions. What can we expect for less popular ones then? I'm not saying that it's better to have closed source, even if we can discuss that too when we consider how often the changes are introduced (for security: the less often the better provided the start is good e…

Availability of the source is not a substitute for audit and care, but is helpful and you're not guaranteed audit or care with closed solutions.
Post reply on HN