Live data from Hacker News

Why We Can No Longer Trust Microsoft

pcmag.com

231–240 of 310 posts

Re: Why We Can No Longer Trust Microsoft

#231
post #213

Earlier quoted context omitted.

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.

> The judicial Power of the United States shall be vested in one supreme Court, and in such inferior Courts as the Congress may from time to time ordain and establish.

Congress certainly does have the 'say so' -- at least with 'inferior Courts'. That still leaves the Supreme Court though as final arbiter.

Re: Why We Can No Longer Trust Microsoft

#232

The same thing is happening at Facebook, Google, Yahoo, and other tech companies. Why single out Microsoft?

Because statistically unless you're in a clear minority, Microsoft makes the OS which you do all your work and process all your data on. It's sorta a big deal.

Sure, but all the leaks so far are about cases where your data is already going through Microsoft services. If there were any evidence that there was a backdoor in Windows itself, or in any Microsoft software, then you'd have a point.

Re: Why We Can No Longer Trust Microsoft

#233

Earlier quoted context omitted.

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…

Let's just go back to type writers and sending encrypted letters.

http://www.bbc.co.uk/news/world-europe-23282308

Re: Why We Can No Longer Trust Microsoft

#235
post #179

Earlier quoted context omitted.

Exactly. Even more interesting, all of the source code can be OK and just some subtle configuration tweaks can be enough to compromise you. Or just some build flag that you don't even see in sources. Often you don't know the build flags of every binary as soon as you use binaries. You also don't know if the compiler is tweaked to do some preprocessing you don't know about (see Reflections on Trusting Trust by Ken Tho…

You can (which is not, necessarily, to say do ) know if the compiler is tweaked: http://www.dwheeler.com/trusting-trust This only works if you are building things yourself or trust the group building things, of course, but it's way easier than audit by disassembling binaries.

How does this deal with [1]? Also, how do you know that your disassembler isn't compromised?

[1] http://programmers.stackexchange.com/questions/184874/is-ken...

Re: Why We Can No Longer Trust Microsoft

#236
post #215

Earlier quoted context omitted.

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 compilat…

Please explain which exact steps and which assumptions would be needed to have a trusted GCC 4.8.1, both gcc and g++ and then keeping it trusted as the new releases appear.

Then the same for LLVM.

Re: Why We Can No Longer Trust Microsoft

#237
post #111
post #35

Earlier quoted context omitted.

I wonder what would a Tim Cook-made iMessage look like from a security standpoint (probably a lot more like Skype/Hangouts than how it works right now).

iMessage is in no way NSA-proof: http://blog.cryptographyengineering.com/2013/06/can-apple-re... tl;dr: * Apple distributes the encryption keys * Multiple keys can be associated with an account (iPhone, Mac – and the NSA?) * Apple can retain metadata * Apple doesn't use certificate pinning

My understanding is that this isn't that bad. If you use iCloud, then the NSA can read your old messages. If you don't sync your iMessages with iCloud, under the assumption that not every iMessage gets encrypted to an NSA key in addition to the recipient's keys, your messages are safe until the NSA/other law enforcement explicitly targets you, and even then, they can only read new messages and not previous ones.

Re: Why We Can No Longer Trust Microsoft

#238
post #207

Earlier quoted context omitted.

Mistrust of commercial solutions does not translate into trust for open-source ones. Have you audited the crypto code of all your packages? Would you even know how?

Most people don't. But if the need the need comes, it can be done. It may need some effort, but can be done. Can you audit microsoft code?

True, you cannot audit msft code. Have you checked on the size of the linux kernel lately? Yes I could audit the source, but in reality only a select few will have deep knowledge of only small parts of the code

Re: Why We Can No Longer Trust Microsoft

#239

Earlier quoted context omitted.

You can (which is not, necessarily, to say do ) know if the compiler is tweaked: http://www.dwheeler.com/trusting-trust This only works if you are building things yourself or trust the group building things, of course, but it's way easier than audit by disassembling binaries.

How does this deal with [1]? Also, how do you know that your disassembler isn't compromised? [1] http://programmers.stackexchange.com/questions/184874/is-ken...

Disassemblers produce assembly code, not the HLL code, so they are many orders of magnitude easier to write from the scratch than modern compilers. They typically expect human involvement as soon as there's non-trivial assembly-level engineered self-modifying code. Hopefully there's no much of such code in the results of the compilers we use.

Also if you check the whole discussion you'll see I already discussed Ken's work.

Re: Why We Can No Longer Trust Microsoft

#240
post #110

Earlier quoted context omitted.

As I understand it, getting a security clearance doesn't especially care about whether you've done anything illegal, it cares about: 1. Whether you're likely to voluntarily leak any secure information. 2. Whether someone who dug up some dirt on you could blackmail you into leaking secure information. Or as the saying goes, it's fine to have a mistress, but having a mistress that your wife doesn't know about is a prob…

A friend in college wanted to be an FBI agent, so I got to hear alot about this. I believed they polygraphed you about drug use, and I recall that they had a threshold number of "experimental" sessions with marijuana that were ok, as long as you disclosed them during the background check and polygraph.

The FBI still uses the polygraph? I would hope the FBI would be looking for the kind of people that know a polygraph is near worthless.
Post reply on HN