"The reason why that's unlikely to happen is that companies treat source code as a significant asset, which is why I first mentioned a longer support period. My favorite approach for this problem would be regulation requiring mandatory release of source code, the toolchain, signing keys, etc. if the manufacturer stops supporting something, so the places which want to keep their trade secrets can still do so but are required to help their users at the same time."

I mostly concur, therefore I certainly hope you're all donating to the Software Freedom Conservancy for their GNU GPL enforcement efforts (see https://sfconservancy.org/supporter/ for more) and encouraging people to license their free software under a strongly-copylefted free software license such as the GNU GPL v3 or later, or the AGPL v3 or later. These licenses allow users to request and deserve to receive complete corresponding source code, build instructions, signing keys, and other materials needed to build the software.

We all need free software for all our computers and we need it whether a manufacturer supports something or not. It's not the public's job to look out for Western Digital's interests including their alleged trade secrets. Western Digital still supports the WDMyCloud device but apparently can't be trusted to handle the software that device runs. It would help WDMyCloud users to publish that device's entire software as free software (if they haven't already), as well as the other things you rightly mention (build instructions, signing keys, and anything else needed to get the device running) so users aren't waiting for this less trusted party to make better choices. Users ought to be free to run, inspect, modify, and share this software or get someone else they trust to do this work on their behalf.

Regarding the first point, I don't positively state that governments do covertly subsidize backdoored products, but it's realistic and a real attack vector. Even if for example the state were totally benign right now, we need to be able to talk about the worst case in case the state goes haywire, without being put in the corner of crackpots.

Regarding the second point, I completely agree with you. First a period of binding and liable responsibility of the manufacturer for the product including software, followed by the release of full source, toolchain and necessary cryptographic material. I think this should be law, and the first period must be time-limited. Reproducible builds could ensure that backdoors in the software are at least retrospectively detected, and the company and people behind it can be hold accountable for it.

> "There's a big issue with quality on devices but spreading conspiracy theories only harms that cause. There's no reason to believe this is connected to a government — and it's way below the level of craft we've seen..."

I think you could be underestimating how and to what level the IC misinformation game is played.

I'm not disagreeing with you. Just pointing out your argument isn't as lockdown air tight as believed.

We've also seen that the governmental attacks are sophisticated because they don't want it to be detected or used by an enemy. The NSA attacks were things like intercepting specific hardware shipments or network links – which reduces the number of people who could possibly notice the problem – or getting people to use a random number generator which only they have the key to reverse[1].

In contrast, this is a textbook example of a sloppy developer who doesn't understand security but is writing network facing code which is never properly audited, and it's consistent with the number of other bugs mentioned.

Saying that it might be a government is like saying that because the CIA has killed people every pedestrian hit by a drunk driver is probably an assassination.

1. https://blog.cryptographyengineering.com/2013/12/28/a-few-mo...

I would say that if people on HN are saying the attack is too stupid to be government supported, then the government has succeeded at their primary goal of having plausible deniability with these issues.

If we take recent history, we now have hard evidence of all sorts of conspiracy theory type stuff being absolutely true. With that in mind, do we just keep defaulting to 'not government' every time there's a deliberate backdoor identified? Sounds like a great way to maintain the status quo and ensure that no action is ever taken to curb this.

> this is a textbook example of a sloppy developer who doesn't understand security

From TFA:

02 - Hard coded backdoor

02.1 - Vulnerable code analysis

02.2 - Remote exploitation

Your argument is that because one thing which some people considered a conspiracy theory, but most experts did not, was true we should believe all of them?

Yes, there’s a hardcoded password. The field has a long history of people adding those to make support easier, and I’d bet a lot more that that password means someone with that name worked on the mydlink project than that the NSA put it there, just as most burglaries are routine crime even if the CIA or FBI has been known to quietly bug houses.

The evidence for a backdoor by the government vs a programming mistake or backdoor by somebody else is weak, I think. Also, what would change even if?

From TFA:

> As you can see in the above code, the login functionality specifically

> looks for an admin user named "mydlinkBRionyg" and will accept the password

>of "abc12345cba" if found. This is a classic backdoor. Simply login with

> the credentials that I just mentioned from the above code.

Programming mistake? Seriously?