HN user

m8urn

938 karma

http://xato.net

[ my public key: https://keybase.io/m8urnett; my proof: https://keybase.io/m8urnett/sigs/BBfZhM0VIhc2ty1yG6MeU50Q0yTf5SBg0dRBDhHNmXg ]

Posts15
Comments69
View on HN

Even with Enterprise edition it is very difficult to disable all telemetry. The lowest official setting for telemetry is "security" which still sends data to Microsoft (see https://docs.microsoft.com/en-us/windows/configuration/confi...).

There are, however, a number of hacks that can trim that down even further. But being hacks they aren't guaranteed to always work--things frequently change.

Since writing the article mentioned a couple comments up I have tried completely ripping out all telemetry components from the install CD, which seems to be the most effective option. Tools such as Blackbird (http://www.getblackbird.net/) also are quite effective. Nonetheless, monitoring traffic still shows connections to Microsoft-controlled servers. There are so many ways Microsoft (and therefore possible governments) can gather--or at least infer--information about your system.

To completely protect yourself would require manually monitoring, selecting, and installing updates, manually updating certificate revocation lists, constantly watching for new settings (including firewall and hosts entries) that must be addressed, etc.

So no, it is not possible to completely disable all forms of Windows 10 telemetry without also committing to an unreasonable amount of work.

I actually didn't spread them widely, I tweeted them. If you follow me you would know I tweet things like that all the time. I observed these connections and showed the settings I have set that should have prevented them.

I haven't published results anywhere and many people, including in the comments here, have corroborated what I saw.

The results are the results. I am re-verifying before I publish anything on this and to provide a script so that others can reproduce the results. That certainly does not make it wildly implausible.

Actually I made this error twice, which is far from "countless times". The one Allow Telemetry setting would not have made a difference because I had also configured it manually and the Teredo setting doesn't actually disable Teredo anyway. This does not make the entire experiment a failure.

But to show how easy of a mistake this is to make, here is what Microsoft's documentation from https://docs.microsoft.com/en-us/windows/configuration/manag... says:

Enable the Group Policy: Computer Configuration > Administrative Templates > Network > TCPIP Settings > IPv6 Transition Technologies > Set Teredo State and set it to Disabled State.

Reading that, it seems as though you should disable the policy but in fact you should first Enable the policy, then go into the policy settings and Disable the setting there. And even with that mistake, I had it manually disabled in both HKCU and HKLM so if disabled means it uses the local host settings then it should use that.

Nevertheless, there are some serious concerns here:

1. Why is it even connecting to facebook, msn ad services, google analytics, etc when nothing is running?

2 Why is it doing this by default on an Enterprise operating system?

4. Why is this the default setting that requires dozens of group policy settings (and knowledge of group policy) to disable?

5. And why is there no option to opt out completely?

And what if they were wherewolves, wouldn't you want to know that too? The problem here is the confirmation bias and logic errors going on with all the theories that there really is no believable proof unless you actually suspend your belief in rational think7.

Another aspect of this is that they make the regular contract plans cost more than twice what they did before, even with a non-smartphone, essentially pushing you into the Next plan.

First of all, a good number of these passwords were simply gathered through google. Some were gathered via the archive.org archive of pastebin pastes and their normal web page archive. Some were from forums that were located via google. This data is already out there, being aggregated doesn't make it any easier to hack these people.

Try searching for "Cucum01:Ber02" or "shawman:badman" and you will see how many passwords are indexed. I have hundreds of searches like these that I monitor and scrape.

Second, I regularly share my data with the owners of password checking sites such as haveibeenpwned to make sure users are able to be aware of these breaches. Releasing this data isn't something I have taken lightly, I debated it for years. I have weighed the risks and felt it was important to release the raw data, although not everyone will agree with me on this. I made a good effort to minimize the risks to actual users.

Finally, keep in mind that most users are already at risk simply because they have bad passwords. Ten percent of users have a password on the top 1000 list. A large percentage of users are at risk because the websites they are on don't have proper security. This is how people get hacked, not because of a password found on this list.

As I explained in the article I seriously doubt that any more than a tiny number of these passwords are still valid. And there is no reason for them to be, having already been widely available, indexed (and cached) by every search engine, archived at archive.org, and downloaded by thousands or tens of thousands of people. Anyone who would use this data maliciously probably already has it.

Much of this data is the same data monitored by sites like haveibeenpwned.com and a dozen others. Facebook scrapes these. Lastpass will send you alerts. The risk here is minimal; the research value is much more than you realize.

The main reason I have always included usernames and passwords in my research is because it allows me to analyze frequency data across multiple sites. Although I could have anonymized the usernames, I thought it would be best to keep them in. There is good value there. For example, there is quite a bit of overlap between usernames and passwords. Also, how many users include all or part of their usernames in their passwords. Plus, what usernames might hackers be most likely to try out?

The main goal here is to put the data out there and let other researchers find the value in it.

That is a key point--that no system can ever be secure as long as the host has some way of intercepting messages. The fact is that no matter how secure Levison makes the system, there will always be some way he could intercept messages if he really wanted to, even if it meant modifying the code a bit. And if he can do it, the feds can compel him to do it.

The problem is that fingerprint matching isn't exact, there are thresholds you must allow for so there is no exact code to match to. Although some implementations may make this possible, it is an issue that all biometric methods must address.

It's like allowing a password that is close enough, in that case you would need the real password as well, not just a hash.

Again, that's the whole point. He wasn't able to provide them with what they wanted, and doing so meant that he either had to allow them to intercept messages (or passwords) on Lavabit's application servers, which is the only place they could be intercepted. Doing so would require either impersonating their servers through a MitM or code changes on their server.

I do acknowledge in the article that this could simple be an overhyped reaction to placing a black box on his network, but the statements Levison made seem to indicate otherwise. And hey I could be wrong about this whole thing, it still is largely speculation based on circumstantial evidence.

Levison did make a comment once that he couldn't give the government what he didn't have, referring to deleted emails. I didn't address that in the article but it is another dimension to this. Being that this is all about something he didn't already have, chances are that archived messages was one of those things.

Nevertheless, the means to decrypt those messages still is the critical difference here.

That's actually the whole point, in the past he complied with warrants because there wasn't much he could supply in the first place. Yes there is a lot of reading between the lines here, but there was a clear line they crossed. In other words, he would no longer be able to just turn over a bunch of encrypted emails, this was a full compromise of the security he had in place.

If you look at the quotes he made, he strongly hints that this affects all his users, that they want to collect data for later review, and that they would have the ability to decrypt any emails they wanted. Yes, there is a lot of speculation going on here, but it is based on facts--what they technically would be able to do based on how Lavabit worked.

Edit: this wasn't just some casual speculation, I did quite a bit of research on this and carefully reviewed every statement he has given to the press. I carefully analyzed their infrastructure and encryption techniques. I'm fairly confident with my conclusions.

There are no providers who can provide full protection from a court order. The only solution is to encrypt on the client side using PGP or S/MIME and make everyone you communicate with do the same. But that means you can only login to your email from computers where your private certificate is installed. It also means no more webmail and no more search capabilities.