Tony Morris

So I don't see how they can possibly be part of the language spec when they are completely optional.

What I’m trying to say (as a hacker who professionally abuses this) is that there are many lenses through which to see a language, a machine, a system. Sometimes stacks exist, sometimes they don’t. Sometimes integers overflow, sometimes they cause exceptions, sometimes BigInt.

When @maradydd and I are doing work in #langsec the impl is part of the math because of course it is, we’re defending against otherwise unpredicted states. There’s just different analytical domains and no absolute ontological walls. Useful ones, yes. You choose your axioms.

You can say an abstraction is leaky but what implementation details can a developer depend on? Matters. Poorly defined. Consistently emits unpredicted states.

Yeah. "Consistently emits unpredicted states" is the definition of a leaky abstraction. I don't think you're thinking clearly.

The thing is, brains do that. Nature does that. Physics does that. As Dan Geer says, security is the absence of unmitigatable surprise.

All abstractions are leaky because they encode implicit assumptions. Attempting to make all assumptions explicit creates awkward pedantry that *still* leaks, because thought transfer is a lossy process. Conversational vs. legal verbiage. I'm thinking clearly about the unclear.

Reminds me of testing's finding, "All oracles are heuristic". There are no perfect tests that can always separate the working from the not-working.