This comment is confusing to me on so many levels. What’s with the tangent(?) about a math test your algebra teacher could have generated? Did you bring up an illiterate teacher (extreme outlier) as evidence that the general population has low comfort with written English, or…? (I’m going to resist getting into the rest of the tangent, but it’s really impressively densely perplexing.)
(edit: I’m not going to resist)
> If he could have written (in 2009) "give 20 question test for week 1 algebra II student with answer guide"
Is the “could” here just about AI not existing back then, or does “could not interact with the written language” imply that he could not have written this prompt? Why would he need the output, given that most of it is math? (If we assume he can speech-to-text the prompt, why can’t he do the same for other writing?) If the level of writing of “Write equation of a line in slope-intercept form with slope 3 and y-intercept −2” is the challenge, is he able to read it? What if the output is wrong – who’s going to verify it? Are you presenting this as a good thing? How did/would he grade handwritten written-answer questions?
- 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.
reply