What they point to are capabilities, but the integer handles that user space gets are annoyingly like pointers. In some respects, better, since we don’t do arithmetic on them, but in others, worse: they’re not randomized, and I’ve never come across a sanitizer (in the ASan sense) for them, so they’re vulnerable to worse race condition and use-after-free issues where data can be quietly sent to the entirely wrong place. Unlike raw pointers’ issues, this can’t even be solved at a language level. And maybe worst of all, there’s no bug locality: you can accidentally close the descriptor backing a `FILE*` just by passing the wrong small integer to `close` in an unrelated part of the program, and then it’ll get swapped out at the earliest opportunity.
BITD the one "fd sanitizer" I ever encountered was "try using the code on VxWorks" which at the time was "posix inspired" at best - fds actually were pointers, so effectively random and not small integers. It didn't catch enough things to be worth the trouble, but it did clean up some network code (ISTR I was working on SNTP and Kerberos v4 and Kerberized FTP when I ran into this...)
> **3. The Layer 7 Limitation** Cloudflare operates primarily at the application layer. Many failures happen deeper in the stack. Aggressive SYN floods, malformed packets, and protocol abuse strike the kernel before an HTTP request is even formed. If your defense relies on parsing HTTP, you have already lost the battle against L3/L4 attacks.
No idea how valid the video is. It could be accurate, it could be entirely simulated, it could be making some kind of simple mistake. (At least there’s a tiny bit more detail in the video description on Vimeo.) Anyway, good time to learn about the blanket “I’m under attack” mode and/or targeted rules.
> **2. The Origin IP Bypass** Cloudflare only protects traffic that proxies through them. If an attacker discovers your origin IP--or if you are running P2P nodes, validators, or RPC services that must expose a public IP--the edge is bypassed entirely. At that point, there is no WAF and no rate limiting. Your network interface is naked.
You pay a cost either way: live in a world with better funded and incentivized scammers and in a community less wealthy by a corresponding amount, or have a slightly less convenient sideloading experience.
I guess if you take the old saying extremely literally, you could conclude that every fool is guaranteed to be parted with 100% of their lifetime available money regardless of what anyone else tries to do to stop that, but that’s not true – and why old sayings (with a respectable 75% of the words right) taken literally aren’t a good basis for decision-making.
Uniformity isn’t directly important for error detection. CRC-32 has the nice property that it’s guaranteed to detect all burst errors up to 32 bits in size, while hashes do that with probability at best 2^−b of course. (But it’s valid to care about detecting larger errors with higher probability, yes.)
There’s a whole field’s worth of really cool stuff about error correction that I wish I knew a fraction of enough to give reading recommendations about, but my comment wasn’t that deep – it’s just that in hashes, you obviously care about distribution because that’s almost the entire point of non-cryptographic hashes, and in error correction you only care that x ≠ y implies f(x) ≠ f(y) with high probability, which is only directly related in the obvious way of making use of the output space (even though it’s probably indirectly related in some interesting subtler ways).
E.g. f(x) = concat(xxhash32(x), 0xf00) is just as good at error detection as xxhash32 but is a terrible hash, and, as mentioned, CRC-32 is infinitely better at detecting certain types of errors than any universal hash family.
This seems to make sense, but I need to read more about error correction to fully understand it. I was considering possibility that data could also contain patterns where error detection performs poorly due to bias, and I haven't seen how to include these estimates in probability calculations.
> What would be an issue, if they used 128 bit xxhash instead of 128 bit cryptographic hash like they do now (if we assume we don't need to protection from tampering)?
malicious block hash collisions where the colliding block was introduced by some way other than tampering (e.g. storing a file created by someone else)
> Are we saying that we are okay to cut trees to make straws when we could make them out of petroleum ?
It’s more okay to make things out of paper than plastic, yes. Plastic waste and microplastics are a huge problem. Trees are a renewable resource.
> Moreover, paper straws are not even recyclable due to water content which makes them soggy. Plastic ones are almost 100% recyclable
Plastic straws are almost never (literally never?) recycled. Paper straws are supposed to be fully biodegradable.
> Most importantly, unlike plastic straws, they are laced with glue and other chemicals which gets ingested.
But yes, this and the usability issue make the other points moot (n.b. leaching harmful chemicals is a concern that also applies to plastic straws and paper cups). The vast majority of existing straws should be replaced with no straw, and most beyond that with reusable straws.
That doesn’t look like a counterexample to “we formalize the statements by hand and inspect the proofs carefully to ensure they capture the full spirit of the problem”.
reply