- CSP that allows cdn.jsdelivr.net/unpkg.com (which serve anything on npm, which anyone can publish to) indiscriminately is not effective (and I’m sure some cdnjs script in an Angular-style library executes arbitrary code in otherwise-benign HTML attributes too)
- rate limiting using a key derived from the freely attacker-settable User-Agent header
- (and storing it in Netlify Blobs, “a highly-available data store optimized for frequent reads and infrequent writes“?)
- “The remaining item — constant-time comparison — is a calculated risk I have accepted for now.” What was the calculation? If Netlify Functions supports Node.js APIs as a quick search suggests, this is just `crypto.timingSafeEqual`. But even better without delving into more complicated options would be to store only a hash of the token to compare against.
I know parameters don’t translate directly like that (and that linear and exponential aren’t the only types of growth) but a doubling as a go-to example of “not exponential growth” is pretty funny.
The point of ASLR is that even if you fully understand how it works, this won't make it easier to bypass the protections of ASLR, since the primary way ASLR works is through dynamic adaptation. This turns it into a probabilistic security technique where there is always a chance that an attack goes through.
Security through obscurity in this case would be to roll your own ASLR implementation with a different randomization strategy.
That's not what security through obscurity means. Security through obscurity has a specific meaning, it doesn't just mean to gain security by hiding anything it means to attempt to gain security by hiding how a system works.
ASLR is a well understood system that exploit writers know to expect and thus ASLR is not security through obscurity.
no because it's still possible to find the data using standard techniques, it doesn't count as obsecurity it's still possible.
I.e. just because you* don't know where something is, doesn't mean it's using obsecurity to hide.
The reason is important, because words mean things: If you say, knowledge of some secret is security though obsecurity. That means passwords are security though obsecurity.
*: that may or may not be available to the attacker.
it other words, just because a secret exists, doesn't put that secret into the 'obsecurity' category.
> Any TLS break delayed by more than 15 minutes would be worthless.
It sounds like you’re talking about breaking TLS’s key exchange? Why would this not have the usual issue of being able to decrypt recorded traffic at any time in the future?
Edit: If it’s because the plaintext isn’t useful, as knorker got at in a sibling comment… I sure hope we aren’t still using classical TLS by the time requiring it to be broken in 1 minute instead of 15 is considered a mitigation. Post-quantum TLS already exists and is being deployed…
What you're talking about is a property called "forward secrecy". There are new techniques which have better quantum resistance for handling key exchange, but I think the point of the person you're responding to is that if you rotate keys often enough that forward secrecy may not be as essential of a property. I would say whether it is or it isn't is largely dependent on your use case and threat model. Either way, if the symmetric keys used for the session aren't directly breakable and you are using PQC for the key exchange, you can still enforce forward secrecy in a way that is only strengthened by rotating keys often.
> Rather, an interactive window running under the user’s name has implied access to the user’s home folders, regardless of what’s been set under “Files & Folders” (which still applies for background/non-interactive processes).
No, that’s not true at all. Granting permission using the folder picker is required.
Npm and the other JavaScript package managers do generate and check lockfiles with hashes by default. This was a new release, not a republishing of an old version (which isn’t possible on the npm registry anyway).
i wasn't aware npm lockfiles check hashes by default now. my concern is more about the initial install before a lockfile exists, like in CI from a fresh clone without a committed lockfile. but you're right, once the lockfile is there the hash mismatch would be caught.
No, the comment was pointing out that the HN platform automatically replaces `--` in titles with `–`. (I don’t know if that’s true, but that was the intent. Nothing to do with AI.)
But... it's not more appropriate than an em dash for representing command line arguments? I don't see how either is any more incorrect than the other. There's a uniquely correct answer here and the em-dash is not it. Period.
It’s about the top-level comment’s horror that ”--” was substituted with “an en dash, not even an em dash”. If you’re picking a substitution for “--”, en dash makes more sense. The comment you originally replied to had already agreed “that it should be left as a double hyphen”.
> If you’re picking a substitution for “--”, en dash makes more sense.
No, it doesn't? This seems like crazy talk to me, like "If you're picking a substitute for saffron, blood plasma makes more sense than monocrystalline silicon". Like, what?
It makes zero sense to substitute this at all. It's exactly what it says it is, the "--hard" command line option to "git reset", and you write it in exactly one way.
Nobody is confused or disagrees about the `--hard` part. It was a minor tangent about contexts where these ASCII substitutions are established, like LaTeX (`` -> “, '' -> ”, -- -> –, --- -> —, etc.)
reply