4 ms·

"You ship something with no known bugs and then someone finds one." You managed to say that with a straight face! Let's keep this ... non partisan. You might

by gerdesj 7mo ago

"You ship something with no known bugs and then someone finds one." You managed to say that with a straight face! Let's keep this ... non partisan. You might recall that many vendors have decided to embed static creds in firmware and only bother patch them out when caught out. How on earth is embedded creds in any way: "no known bugs"? I think we are on the same side (absolutely) but please don't allow the buggers any credibility!

AnthonyMouse 7mo ago
> How on earth is embedded creds in any way: "no known bugs"? You misunderstand how organizational knowledge works. You see, it doesn't. Some embeds the credentials, someone else ships the product. The first person doesn't even necessarily still work there at that point. Remember that time NASA sent a Mars orbiter to Mars and then immediately crashed it because some of them were using pounds and the others newtons? Literally rocket scientists. The best we know how to do here is to keep the incentives aligned so the people who suffer the consequences of something can do something about it. And in this case the people who suffer the consequences are the consumers, not the company that may have already ceased to exist, so we need to give the consumers a good way to fix it.
- pixl97 7mo ago
  >Some embeds the credentials, someone else ships the product. It doesn't matter. When you are building software, you build a security process, not security individuals or stuff like this happens. >orbiter to Mars and then immediately crashed Right, and it cost NASA 1.4 billion+ is direct losses to them. With software writers the losses occur to the end user.
  - AnthonyMouse 7mo ago
    > When you are building software, you build a security process, not security individuals or stuff like this happens. You can't solve an incentive problem with process because then they lack the incentive to follow the process. To enforce a law you need to be able to identify a violation at a point in time when you can still impose a penalty for it. When a device is first released, you don't yet know if anyone will find a vulnerability in it or if the company will stay around to update it if they do. By the time you find out if it will happen, you can't punish them for the same reason they can't provide updates: they've ceased operations and no longer exist. So that doesn't work. > With software writers the losses occur to the end user. Which is why the end user needs to be empowered to efficiently prevent the losses, since they're the one with the strongest incentive to do it.
- eesmith 7mo ago
  "Spectrum quickly learned that far more had gone wrong than just a units conversion error. A critical flaw was a program management grown too confident and too careless, even to the point of missing opportunities to avoid the disaster. "As reconstructed by Spectrum, ground controllers ignored a string of indications that something was seriously wrong with the craft's trajectory, over a period of weeks if not months. But managers demanded that worriers and doubters "prove something was wrong," even though classic and fundamental principles of mission safety should have demanded that they themselves, in the presence of significant doubts, properly "prove all is right" with the flight. Quoting https://web.archive.org/web/20210730150049/https://spectrum.ieee.org/why-the-mars-probe-went-off-course https://web.archive.org/web/20210730150049/https://spectrum.... linked to from https://en.wikipedia.org/wiki/Mars_Climate_Orbiter https://en.wikipedia.org/wiki/Mars_Climate_Orbiter . Plus, navigators, had concerns about the trajectory,which were dismissed because they "did not follow the rules about filling out [the incident surprise and analysis procedure] form to document their concerns" - from a trajectory team which was understaffed and overworked.

by gerdesj 7mo ago

AnthonyMouse 7mo ago

> How on earth is embedded creds in any way: "no known bugs"? You misunderstand how organizational knowledge works. You see, it doesn't. Some embeds the credentials, someone else ships the product. The first person doesn't even necessarily still work there at that point. Remember that time NASA sent a Mars orbiter to Mars and then immediately crashed it because some of them were using pounds and the others newtons? Literally rocket scientists. The best we know how to do here is to keep the incentives aligned so the people who suffer the consequences of something can do something about it. And in this case the people who suffer the consequences are the consumers, not the company that may have already ceased to exist, so we need to give the consumers a good way to fix it.

pixl97 7mo ago
>Some embeds the credentials, someone else ships the product. It doesn't matter. When you are building software, you build a security process, not security individuals or stuff like this happens. >orbiter to Mars and then immediately crashed Right, and it cost NASA 1.4 billion+ is direct losses to them. With software writers the losses occur to the end user.
- AnthonyMouse 7mo ago
  > When you are building software, you build a security process, not security individuals or stuff like this happens. You can't solve an incentive problem with process because then they lack the incentive to follow the process. To enforce a law you need to be able to identify a violation at a point in time when you can still impose a penalty for it. When a device is first released, you don't yet know if anyone will find a vulnerability in it or if the company will stay around to update it if they do. By the time you find out if it will happen, you can't punish them for the same reason they can't provide updates: they've ceased operations and no longer exist. So that doesn't work. > With software writers the losses occur to the end user. Which is why the end user needs to be empowered to efficiently prevent the losses, since they're the one with the strongest incentive to do it.
eesmith 7mo ago
"Spectrum quickly learned that far more had gone wrong than just a units conversion error. A critical flaw was a program management grown too confident and too careless, even to the point of missing opportunities to avoid the disaster. "As reconstructed by Spectrum, ground controllers ignored a string of indications that something was seriously wrong with the craft's trajectory, over a period of weeks if not months. But managers demanded that worriers and doubters "prove something was wrong," even though classic and fundamental principles of mission safety should have demanded that they themselves, in the presence of significant doubts, properly "prove all is right" with the flight. Quoting https://web.archive.org/web/20210730150049/https://spectrum.ieee.org/why-the-mars-probe-went-off-course https://web.archive.org/web/20210730150049/https://spectrum.... linked to from https://en.wikipedia.org/wiki/Mars_Climate_Orbiter https://en.wikipedia.org/wiki/Mars_Climate_Orbiter . Plus, navigators, had concerns about the trajectory,which were dismissed because they "did not follow the rules about filling out [the incident surprise and analysis procedure] form to document their concerns" - from a trajectory team which was understaffed and overworked.