Hacker News Reader

Comment by flukus | Hacker News Reader

This has been an issue for 2 years now, so what is it they've done with this oh so valuable data? What improvements have been made as a result of the data collected?

I suspect the answer is that no concrete improvements have been made and all it's accomplished is to make them look bad.

View on HN

https://blogs.msdn.microsoft.com/dotnet/2017/07/21/what-weve...

And there's the money shot:

"Hashed MAC address — Determine a cryptographically (SHA256) anonymous and unique ID for a machine. Useful to determine the aggregate number of machines that use .NET Core. This data will not be shared in the public data releases."

But private releases, that's a different matter...

And as we know from various recent events, private releases can become public releases without proper data control.

Someone please correct me if I'm wrong, but (2^48 possible MAC addresses) / (60000MH/s) / (3600 s/h) = 1.3 h to calculate the SHA256 sum of every MAC address in an AWS p3.16xlarge instance (~$50)

https://medium.com/@iraklis/running-hashcat-v4-0-0-in-amazon...

Looks about right to me.

I wonder why they didn't use something like bcrypt/scrypt with lots of rounds.

You may be right. But it may not be a straight sha256. It could be a multi-round hash based on sha2. In the same way shadow hashes are default called sha512, but in reality it's a 5000 round version, so your price could be $250000 instead. (Or less/more)

You could cut down the search space a lot by only enumerating the MAC addresses of known vendors (https://gist.github.com/aallan/b4bb86db86079509e6159810ae9bd...).

That cuts the search space down to 23000 vendors * 0xFFFFFF = 385875945000. With a hashrate of 60000MHs, you could SHA256 hash that entire space in 6.5 seconds. If you have an NVidia GTX 1080, you can do it in ~2 minutes 16 seconds.

It doesn't really matter which hash function they use here... Your common MAC-48 address is a [Manufacturer ID (3 bytes), Device ID (3 bytes)], this further reduces the enumeration requirements...

So they learned that there are a lot of Linux distros and tried to cater to that and that Mac users don't like open ssl. Improvements 1 and 3 are virtually the same and 4 is just some generic padding.

This is nothing they couldn't have to through more traditional and less invasive feedback mechanisms.

Have you ever debugged issues in production apps without logs? It’s awful. Production apps running on machines you don’t control? Even worse. To suggest that zero value has been derived by the client side analytics is naive at best.

Do you think your inconvenience somehow gives you a right to violate users privacy?

> Production apps running on machines you don’t control?

Yes I have. Last time I did it via a dialogue that would pop-up asking the user to submit the information along with a text area that contained all the information being sent.

It's possible to get the information you want and respect your users.

But that takes way too much effort. It's simpler to just demand admin access and remote to the user's machine.

I know you're being sarcastic, but with this particular software we offered support like that as well. 90% of the time the first level support (and eventually QA) would use this dialog and add in stuff like replication steps manually. It was much better way to triage and debug issues than the usual email with an "it doesn't work" title and an excel document containing a screenshot.

So add "it saved the company buckets of money" to the list of reasons this is a better approach.

This is the correct way to handle it.

For single issues - yes. If you have a large deploy base that you can't easily talk to, aggregate reports which can give you don't easy correlation results are much better. For example https://crash-stats.mozilla.com/home/product/Firefox results in much more stability for FF users. Asking everyone would not be possible.

It's more "something crashed, can we send this information to help diagnose the problem? Here's a big textbox from which you can review what we're sending if you want".

Versus "screw you we're taking it anyway".

In some environments this is a massive compliance issue.

Funnily enough, my tab crashed opening the .net core bug linked and firefox has changed this to prompt users before sending the report.

Unfortunately it's still opt-out, doesn't show what data it's sharing and looks to be purposefully misleading, so no info from me.

> firefox has changed this to prompt users before sending the report

Wasn't it always that way? I remember those opt-in crash dialogs from a long time ago – I think they already had them in Netscape, or at least the (pre-Firefox) Mozilla suite.

No, it's not. Unless used very sparingly, it makes for a shitty user experience.

I'd risk a guess that the average user doesn't have any problem with aggregate, anonymized data being collected for statistical and debugging purposes. A lot of people here on HN do and they like to extrapolate that to the whole society, but it's a stretch.

The average user clicks through privacy agreements and contracts without looking. It's up to us to promote good behaviour by technology vendors rather than say I told you so later which is the current status quo.

Your argument wasn’t about privacy. I was contending your claim that they did nothing with the data - which is obviously false if you do software debugging, and clearly false if you read the sibling link with what they’ve actually done.

Reply on news.ycombinator.com