Yes, even when you know what you're doing security incidents dan happen. And in those cases, your response to a vulnerable matters most.
The point is there are so many dumb mistakes and worrying design flaws that neglect and incompetence seems ample. Most likely they simply don't grasp what they're doing
> Overall simple security design flaws but it's good to see a company that cares to fix them, even if they didn't take security seriously from the start.
It depends on what you mean by simple security design flaws. I'd rather frame it as, neglect or incompetence.
That isn't the same as malice, of course, and they deserve credits for their relatively professional response as you already pointed out.
But, come on, it reeks of people not understanding what they're doing. Not appreciating the context of a complicated device and delivering a high end service.
If they're not up to it, they should not be doing this.
Yes I meant simple as in "amateur mistakes". From the mistakes (and their excitement and response to the report) they are clueless about security. Which of course is bad. Hopefully they will take security more seriously on the future.
I definitely don't want my traffic light controller to be written using manual memory management if this is at all possible to avoid. Waiting another millisecond for the light to turn green feels like an acceptable cost. But this seems silly: how on earth did you write such a simple program to have so many allocations that the gc significantly impacts performance? Why would a traffic controller need variable memory in the first place? Surely it's just a mix of a state machine (statically allocatable) and I/O.
"Determinism" feels like a very odd pitch for manual memory management when the latter in no way implies the former, and lack of manual memory management in no way implies non-determinism. Generally, any dynamic allocation is non-deterministic. Furthermore, in the HFT context the non-determinism of the network is going to absolutely dwarf any impacts GC has, especially if you have ever heard of arena allocation. Even your OS's scheduler will have larger impacts if you make any efforts to avoid memory churn.
Now, an interrupt handler should never allocate memory and should generally run with a constant number of cycles. But that's an extremely niche interest, and you'd probably want to hand-code those instructions regardless.
(FYI, I work in a support role to a HFT product, among many others, but it runs on the JVM)
Yes. Another approach would be to use regular 64 bit chunks and speculatively execute each add with and without carry in parallel. Then select the correct variant based on carry result of less significant addition.
With double the amount of additions this allows for log(bits) propagation time (versus linear)
Wouldn’t that produce 2^n possible results to choose from, where n is the number of chunks? That seems like a lot of additional (he-he) instructions executed.
But for a single addition you will also not save any time because you still need to do the select in series. The whole point of the radix 2^51 trick is that you can defer the normalization over several additions, but in order to do that your carry needs to be more than a single bit.
> Claims about "helping the world" are highly subjective and often bullshit
It seems you are making the point that using technology to punish subjective politics is the right way?!
Sidenote: ICC has been backed by many nations, occasionally including US too. Using sanctions in retributions to unfavourable opinions might seem against the spirit of US Constitution in other contexts...
Why not let arguments do their work in open debate? The ICC isn't a bunch of loonies or Saddam's Baath party. These are reasonable people, with dissident opinions, for sure. But reasonable.
> Sanctions are "fight[ing] legally," literally.
Technically, the more appropriate term might be "legalism", in the mechanistic sense.
> Why not let arguments do their work in open debate?
Well, that happened. Israel presented an argument that the investigation legally must end, as they haven't consented to ICC jurisdiction; the ICC openly considered and openly rejected this argument (https://www.icc-cpi.int/news/situation-state-palestine-icc-p...), saying that Palestine's consent was sufficient because the alleged crimes took place in Palestinian territory.
The US has always taken an extremely aggressive stance that this theory of ICC jurisdiction is unacceptable. "It is a fundamental principle of international law that a treaty is binding upon its parties only and that it does not create obligations for nonparties without their consent to be bound", as 22 USC §7421 puts it. (If you're old enough, you may recognize this as part of the bipartisan "Hague Invasion Act" of 2002, widely understood as a threat of military force against anyone who tries to enforce ICC jurisdiction on a citizen of the US or its non-ICC allies.)
Its a little more complicated than that. The dispute is also about if palestine is a "state" and thus able to consent (and i'm not sure, but possibly what the territorial extent of Palestine is. it probably doesnt matter, but the fact that the official government of Palestine lost control of the gaza strip in a civil war a long time ago is another winkle in this whole thing)
While the court initially rejected Israel's challenge, the appeal court reverses the decision, and threw it back to the lower court, which is now deliberating on it https://www.icc-cpi.int/news/situation-state-palestine-appea... . As far as i understand most observers think this is an extreme long shot on the part of Israel and they are unlikely to win this challenge.
[IANAL, and far from an expert at this, this stuff is complicated, it is very possible i got the details wrong]
I think the more interesting point here is that some members of ICC don't recognize Palestine as a state so they don't have a reason to accept ICC jurisdiction because essentially they will be ceding recognition of states to the ICC which seems unlikely.
The US has never meaningfully backed the ICC, and has repudiated it for the overwhelming majority of its existence. Clinton signed the Rome Statute in 2000, on his way out the door; the US never ratified it, and we withdrew our signature in 2002.
Still, US was instrumental in a couple of cases. Supplying evidence against and apprehending suspects in case of ex Yugoslavian culprits and one or two African dictators, but I could be wrong...
The 2002 withdrawal was clearly to sidestep prosecution for the lies that led to Iraq's invasion.
US was okay with ICC until those human right high horse stuff could apply to US...
All I'm saying is that the US is not a signatory to the ICC and does not owe the ICC anything. The ICC sounds like an important supranational body, but is in fact simply a treaty agreed to by a minority of the world's population.
I guess so I was saying, is that US might have been a signatory. In spirit, US has often advocated for applying rules of international humanitarian law where appropriate.
Treaties like NATO, NAFTA, or various "coalitions of the willing" were never backed by a majority of the worlds population. (Maybe an agreement between China and India, might count?).
I think the point isn't that US never believed in multilateralism - it did - but that it feels rules and laws should only apply to others.
I think that's probably a fair criticism of the US! The only thing that rankles me is the idea that there "is" a global criminal court that any country has any moral obligation to comply with. There is not. The US is disrupting the operations of an ICC case? Ok, so what? It's not a real court.
>> Claims about "helping the world" are highly subjective and often bullshit
> It seems you are making the point that using technology to punish subjective politics is the right way?!
My point was to not trust claims that so-and-so is "helping the world," is a vague but positive description that is abused and often collapses on further scrutiny (especially because the speaker may have different subjective interests, what's "helping the world" to him can be "harming the world" to you).
Your response was weird. I was talking about something that I specified clearly, but you took it as I was speaking about something else.
> Using sanctions in retributions to unfavourable opinions might seem against the spirit of US Constitution in other contexts...
No. What are you smoking?
> Why not let arguments do their work in open debate? The ICC isn't a bunch of loonies or Saddam's Baath party. These are reasonable people, with dissident opinions, for sure. But reasonable.
Ok then. I claim authority over you and your friends, but you never consented. I'm not a loony, why don't you recognize my authority over you and engage with me in open debate?
> To me, HDR feels like the system is ignoring my screen brightness settings.
You might be on to something there. Technically, HDR is mostly about profile signaling and therefore about interop. To support it in mpeg dash or hls media you need to make sure certain codec attributes are mentioned in the xml or m3u8 but the actual media payload stays the same.
Any bit or Bob being misconfigured or misinterpreted in the streaming pipeline will result in problems ranging from slightly suboptimal experience to nothing works.
Besides HDR, "spatial audio" formats like Dolby Atmos are notorious for interop isuues
The goal of some languages might be to be easy to learn. But most "system" languages focus on helping design good software, where "good" might mean reliable, maintainable or performant.
Writing good software most often is not easy. The learning curve of a particular language usually is only a modest part of what it takes.
I think it will take a while for people to realize this effort looked great, but wasn't the right approach. Or no silver bullet, at least.
The presentation with a simple diagram that combines this data with an sbom to yield "information" gives me navel gazing vibes of UML being the future of coding.
Just as architecture didn't equate to well designed and maintainable software, I fear this initiative won't fix horribly outdated and vulnerable deployments. Software life cycle, deprecation, abandonment, supply chains are mostly a process problem, standards and technology won't fix that.
It doesn't force someone who already wasn't checking their dependencies for CVEs / maintained-ness to start doing that. It does make someone who *was* doing that be able to show they're doing that in some standard way.
In other words it doesn't force you to add an SBOM + EOX checker step to your CI pipeline. But if your compliance auditor wants you to check your dependencies, adding such a standardized step makes it easier to satisfy the auditor.
I'm basing this mostly off first hand and anecdotal evidence - but through the years I've found that the major contribution of audits lies in having to think about the checkboxes every now and then. And what they mean in the context of my organization or project.
Rarely have I found that compliance to the goals was an issue in themselves. Or that making changes to tick a checkbox correlated to material improvements.
That is to say that if this leads to more efficiency and makes it easier for compliance audits and such, I fear is stream lining the least impactful part of its goals.
> Rarely have I found that compliance to the goals was an issue in themselves. Or that making changes to tick a checkbox correlated to material improvements.
I am confused when I hear people say stuff like this. I guess if you turn on a tool and never look at it again, it won't result in material improvements. But complying with regulations or a particular compliance regime should _absolutely_ result in at least _some_ material improvement to your security posture. Like you can implement segregation of duties just as a checkbox, or use the requirement to revisit the way you gate changes to production, as just one example.
It depends on where you're coming from. Your code base, that is.
If it's already outstanding, you spend a lot of time revalidating what you already know and it's often a noisy process with many false positives.
If it's in a horrible state, however, the regulation often leaves a lot of wiggle room where you do some work to achieve, say, PCI compliance and then spend a lot of time arguing why this and that don't apply in your specific case.
So admitted, the is probably some improvement in the latter case but it's hardly proportional.
So IMHO, it doesn't help those of good will & expertise and does too little for the negligent. It adds noise and in the end quality still depends on factors other than compliance and certification.
Yes, even when you know what you're doing security incidents dan happen. And in those cases, your response to a vulnerable matters most.
The point is there are so many dumb mistakes and worrying design flaws that neglect and incompetence seems ample. Most likely they simply don't grasp what they're doing