It’s one of those topics where there’s a kernel of truth, but most people who insist women or Black people are scientifically different are not doing so out of any interest in science. So the small percentage of people who just want to make a valid point get lumped in with the much larger group, and unfairly tarred.
Perhaps because, to many people, it seems wrong to set policy based on marginal differences in the aggregate when the policy will affect individuals, and also because people doubt the motives of those who are highly invested in proving a scientific basis for negative stereotypes.
I wonder who makes assumptions that these differences are marginal and refuse or deny any studies that conclude otherwise. The left version of climate change if you will.
Wouldn’t just putting an etag on POST requests accomplish the same thing? If I’m understanding it the server has to maintain state to ensure idempotency.
QUERY is GET with a request body. So it must be safe, not just idempotent. Where safe means it has no significant side-effects. Typically servers will not keep any state for QUERY requests.
There is one interesting variant though, which uses state: The client sends a QUERY containing the full query, and the server returns a url usable with GET with which this query can be triggered in the future. Similar to prepared statements in SQL databases.
Using QUERY for GraphQL queries (not mutations) would be a good match. These only read data, but are sometimes bigger than the url length limit.
I still don’t get how idempotency can typically be ensured without state. It very much depends on data model and application design. Even side effects like using a user’s lookup quota need to be handled at a higher layer than HTTP (I think?).
Interestingly, despite the QUERY request being safe, the RFC says it's subject to preflight requests:
> A QUERY request from user agents implementing Cross-Origin Resource Sharing (CORS) will require a "preflight" request, as QUERY does not belong to the set of CORS-safelisted methods (see [FETCH]).
That paragraph merely describes how existing browsers behave, it doesn't specify how future browsers must behave. After all, a HTTP RFC isn't really the right place to specify browser specific behavior like CORS, that belongs in a W3C/WHATWG specification.
Unlike POST, however, the method is explicitly safe and idempotent, allowing
functions like caching and automatic retries to operate.
Essentially, it's for things that are inherently safe/idempotent already (e.g. search or indeed, anything that you don't mind being retried) but require a lot of data passed in the request.
Can we retire the “seatbelts are useless because they can’t prevent every loss of life” approach to risk mitigation please?
If the acceptance criteria is “would prevent every single past instance and every imaginable future instance”, then yes, no mitigation is every sufficient to address any problem in the world, so we might as well give up.
You're in control of how much danger of accident you expose yourself to.
Nobody is in control of how much danger we are exposed to from other people who are actively trying to do us harm, who will keep going until they get what they're after or are stopped.
For most people, seatbelts are the former. Yeah, not perfect, but they reduce risk. For the latter, if you're known to be a seatbelt wearer, the attacker just does something where seatbelts don't matter.
Every new AI model introduces new capabilities and competencies, so we're not even sure what the true risk levels are yet for self-exposure in this category. The restrictions on AI may be like seatbelts and speed limits, or they may be like "if you install a 1000 HP turbojet engine in your Honda Civic it will no longer be road legal". And this analogy also includes how the first cars had speed limits set low enough to not risk the horse industry, i.e. we may be too cautious.
The “attackers only have to win once” principle is core to infosec; a company has to ensure every single employee rejects every single phishing attempt every single time, an attacker just has to get one employee once.
But I think people misinterpret the principle to mean that only perfect solutions have any value.
When in reality defense in depth is the opposite principle: you scan incoming emails for phishing, and that’s good but imperfect. You do mandatory training, and that’s good but imperfect. You use RBAC to limit blast radius, and that’s good but imperfect. And so on.
Among tech people, especially on HN for some reason, there’s this odd thinking style that goes: 1) company announces security measure, 2) the measure could possibly limit my freedom to do whatever I want with the company’s products, 3) I don’t like that, 4) I can come up with scenarios where the security measure is not sufficient, entirely on its own, to address the claimed risk, 5) therefore the security measure does no good at all, 6) therefore this is a PR smokescreen to disguise their desire to capriciously fuck with me out of pure malice, and I am angry about it
For the typical user, this is far far far more likely to happen than that they would “pop out” the drive and read it in another machine.
Defaults should be safe for most users. Power users are exactly the people who can deal with changing a setting. It’s constantly surprising to me when technical people insist that defaults should be optimized for technical people.
This is not the correct model. For a typical user, they can bring the laptop to someone knowledgeable, who will pop out the drive for them.
The main question is: What is the biggest risk: theft or data corruption.
In my experience, corruption and ransomware is more common so FDE should be off for households desktops or laptops, as these rarely leave the house. A business tends to have managed devices and data loss is a legal nightmare, so FDE should be on. The main thing is: people should be able to choose.
There is a happy medium. Encrypt the user directory/s and leave the rest of the disk unencrypted. There is still a risk that the user loses valuable data due to corruption, but there is much less of a risk of the entire system being unusable or unrecoverable because of corruption or ransomware.
reply