nmadden

> Also, it's quietly, in the email space, that we're seeing real innovation […]

Can you elaborate on this innovation in the email space around PKI?

Not if you program to the interface. This kind of pattern matching is syntactic sugar for `instanceof` checks and down-casts. That’s fine within a module boundary (using “module” in a loose sense), but across module boundaries I think programming to an interface should still be the preferred solution.

I’m glad you’ve fixed that issue. Hopefully you can fix the other design issues, including security weaknesses, I reported at the time [1]. I found the response rather dismissive and unhelpful, I have to say.

[1]: https://marc.info/?l=openjdk-security-dev&m=177435495515512&...

Signing things by default has repeatedly been found to have serious unintended consequences. Do you really want your leaked/stolen photos to be undeniably linked to you?

https://blog.cryptographyengineering.com/2020/11/16/ok-googl...

Speculation, but Edge was John Brockman’s thing and he was heavily connected to Epstein, so probably has become a bit toxic for potential contributors. https://en.wikipedia.org/wiki/John_Brockman_(literary_agent)...

Sort of, but not really. OAuth isn’t RBAC and the Dropbox chooser isn’t FGA in the sense of that article. My book (linked from my profile) covers the distinctions in more detail in chapters 7, 8 and 9.

I used to use the example of Dropbox’s chooser API to illustrate this: https://www.dropbox.com/developers/chooser

If you use this API (via a simple widget library) then the user simply picks a file in their dropbox and the app gets access to that one file. Vs OAuth where you grant the app broad access to the whole dropbox (or maybe some sub-folder).

> The pads are split into three pieces that are XORed to create the actual pad to reduce risk of compromise.

Thus creating a two-time pad, which is completely insecure…

Re: cheap - Anthropic’s write-up said it cost $20,000 of runs to find that bug (and a few others). So not that cheap compared to other tools - more similar in cost to human review/pentest, but probably more exhaustive.

> This was the most critical vulnerability we discovered in OpenBSD with Mythos Preview after a thousand runs through our scaffold. Across a thousand runs through our scaffold, the total cost was under $20,000 and found several dozen more findings.

They don’t talk about the other findings, so I’m guessing they are minor.

> Crashing is not an outage.

Are you in the right thread?

MBP = Macbook Pro AW = Apple Watch? What is APP?

Not sure why you're being downvoted for recommending a classic textbook!

> Because in practice, everything is finite.

Indeed! https://neilmadden.blog/2019/02/24/why-you-really-can-parse-...

100% reproducible deterministic bugs are absolutely the easiest class of bugs.

The proprietary/commercial TALA engine is really excellent too. I’ve been using it to do complex dataflow diagrams, and the results are so incredibly well laid out.

I guess. But it would only impact you if you’re using cookies with curl (I assume the middleware is only applied to requests with cookies?) — and it seems pretty easy to add a -H ‘sec-fetch-site: none’ in that case.

The article has a whole section about requiring those headers by forcing the use of TLS 1.3 — the theory being that browsers modern enough to support 1.3 are also modern enough to support the headers. But why not just enforce the headers?

Enforcing TLS 1.3 seems like a roundabout way to enforce this. Why not simply block requests that don’t have an Origin/Sec-Fetch-Site header?

Yes, of course it’s (largely) subjective. But I have actually read much of the source code of Spring. I know it _very_ well.

Java is sprawling now. It wasn’t 26 years ago.

Yes, in theory they are good. In practice they cause enormous amounts of pain and work for library maintainers with little benefit to them (often only downsides). So, many libraries don’t support them and they are very hard to adopt incrementally. I tried to convert a library I maintain to be a module and it was weeks of work which I then gave up and reverted. As one library author said to me “JPMS is for the JDK itself, ignore it in user code”.

Given how much of a coach and horses modules drove through backwards compatibility it also kind of gives the lie to the idea that that explains why so many other language features are so poorly designed.

Do you really think that in 26 years of professional Java programming I’d have never touched Spring? I’ve been using Spring since it was first released. I’ve found CVEs in Spring (https://spring.io/security/cve-2020-5408). Trust me when I say that my dislike for Spring (and annotations) is not based on ignorance.

> The first day I used it, Claude got stuck in a loop trying to fix a problem using the same 2 incorrect solutions again and again and burnt through $30 of API credits before I realized things were very wrong and I stopped it.

The worse it performs, the more you pay. That’s a hell of a business model. Will users tolerate that for long?

The improvements in programming are largely due to the adoption of “agentic” architectures. This is really a hybrid neural-symbolic approach: the symbolic part being the interpreter/compiler. Effectively the LLM still produces an almost-correct-but-wrong program and then the compiler “fact-checks” it and then the LLM basically local-searches its way from there to something that passes the compiler. (If you want to be disabused of the idea that LLMs on their own are good at programming, just review the “reasoning” log of one trying to fix a simple string | undefined error in Typescript).

It seems clear to me therefore that further improvements in programming ability will not come from better LLM models (which have not really improved much), but from better integration of more advanced compilers. That is, the more types of errors that can be caught by the compiler, the better chance of the AI fuzzing its way to a good overall solution. Interestingly, I hear anecdotally that current LLMs are not great at writing Rust, which does have an advanced type system able to capture more types of errors. That’s where I’d focus if I was working on this. But we should be clear that the improvements are already largely coming via symbolic means, not better LLMs.

I wrote some notes about a year ago about the irony of LLMs being considered a refutation of GOFAI when they are actually now firmly recapitulating that paradigm: https://neilmadden.blog/2024/06/30/machine-learning-and-the-...

This was before LLMs. It was a combination of unit and end-to-end tests and tests written to comprehensively test every combination of parameters (eg test this security property holds for every single JWT algorithm we support etc). Also bear in mind that the product did a lot more than just OAuth.

Adding some OAuth helps a bit: https://neilmadden.blog/2022/01/20/why-the-oauth-mtls-spec-i...

(I quite like the combo of app-level OAuth plus mTLS service mesh for backend comms).

CBOR is basically a fork of MsgPack. I prefer the original - it’s simpler and there are more high-quality implementations available.

Yes (although practically speaking it’s very unlikely that Grover will ever break AES-128), but that’s still a brute force attack and still subject to the physical limits mentioned in the Schneier quote. Whereas attacks on RSA like the number field sieve or Shor’s algorithm are much more efficient than brute force. (Which is why you need such big keys for RSA in the first place).

That’s true for AES-256. But brute force attacks are not the most efficient way to attack RSA, so it’s not true in that case. (Eg quantum computers would break RSA-4096 but not AES-256).

Yes, the WebAuthn spec is pretty unreadable. Every time I open it I feel like I’m lost in a maze of twisty hyperlinks, all alike.