> BinDiff: you can't patch software without disclosing vulnerabilities
That’s why Microsoft has been obfuscating its binary builds for at least the last two decades so that even the two builds from the same source would produce very different blobs.
It was a part of our Windows build process when I was at Microsoft. I only assumed that they would keep doing it, but they might have as well dropped the practice.
All the while, Linux is going towards reproducible builds (Debian just announced it as a policy). This is of course the only sane way for FOSS, and, I believe, the only sane long term approach in any case. Security by obscurity, while not worthless, is just a thin mitigation layer.
By the way, build-time randomization is ineffective in light of AI analysis---it needs to be per-binary-run, in the style of KASLR.
> but end to end encryption on instagram is only protecting your chats from Meta.
No. It protects your chats from Meta and all governments of the countries where Meta operates.
In fact, I expect Instagram to be more reachable globally now because these relaxed communication standards would be welcomed by oppressive governments as they can now retrieve messages as they please for whatever purpose they deem.
> This module may generate duplicate UUIDs when run in clients with deterministic random number generators, such as Googlebot crawlers. This can cause problems for apps that expect client-generated UUIDs to always be unique. Developers should be prepared for this and have a strategy for dealing with possible collisions, such as:
> - Check for duplicate UUIDs, fail gracefully
> - Disable write operations for Googlebot clients
> It doesn't matter if it's slop as long as it works
I agree with most of what you said, but that statement doesn't take the time dimension into account. Slop accumulates, and eventually becomes unmanagable. We need to teach AI to become lean engineers too.
I have only seen AI make codebases better, and I'm talking about it making some pretty nuanced changes. I think mass-rewriting of projects is possible these days with AI.
just last week AI led a developer on our team to brick our git history when he was attempting to fix a deploy. he's not a git expert but an llm should of not led him that far astray, no?
i see on a weekly basis where if an llm was left to do what its initial direction was without human oversight it would have broken otherwise working programs
it was related to a deploy issue not a PR and he's the sole developer on a small team, i just consult part time. the example is less relevant; we are seeing developer delegate their understanding to the confidence of an LLM
From what I remember, there were two "Enter/Return" keys on IBM 3270 terminals. One was the regular "Return" key we have today, which just advanced to the next field, and didn't submit the form. There was also another "Enter" key where the Right Ctrl key is today, and that submitted the form. So, I presume, instead of being against Tab key, IBM might be against "Return" to be the form submit key as people who use 3270 would expect it to advance to the next field.
And that was true for many DOS programs. Pressing Return would just go to the next field, not submit the form. That was one of the things that needed some getting used to on Windows.
Your memory is correct, and it's interesting to note that on the IBM terminal keyboards, the Enter key was marked "Enter", and the return/new line key was marked "↵". On the classic IBM PC keyboards such as the Model M, the Enter key is marked "↵ Enter". I believe IBM chose this to convey that the Enter key on the PC was both an "Enter" _and_ "Return" key in one. As you say though - individual applications got to chose what that meant in practice, leading to inconsistent behavior.
reply