Once an IP in a botnet attacks someone, it ends up on a blocklist and can’t attack anyone else who uses that blocklist. This is a big part of Cloudflare’s DDoS model: if you attack one CF property (with non-volumetric DDoS) you will not be able to attack any others with the same bot for an extended period. This makes attacks to CF properties limited in scope and way more costly, because you have to essentially “burn” IP addresses after sending relatively little traffic.
Large DDoS botnets will have hundreds of thousands of return-path-capable IP addresses. Your temporary blocks will have to be very sensitive (i.e. trigger on a relatively small number of requests within the time window) for an application-level DDoS to be usefully mitigated.
The law can be bad and a specific legal argument against it can be wrong at the same time. Would you logically accept (as opposed to mere political convenience) every potential argument whose conclusion is that this law is invalid? If not, does that mean there is something “wrong with you”?
On the object level: giving medical advice is a form of (literal) speech. If you want to practice medicine and give medical advice as part of that practice, there are tons of constraints on what you can say to patients. The argument you’re laying out here is clearly too general.
RAM is always storing something, it’s just sometimes zeros or garbage. Nothing in how DRAM timings work is sensitive to what bits are encoded in each cell.
Yes, but the attestation does not tell the RP anything about the browser. The whole point of the nightmare scenario above was for Google to sneak browser attestation in via passkey attestation. The browser being able to see the attestation doesn’t matter for that.
None of the password managers (including but not limited to ones built-in iOS/Android) work that way. The Apple one (and I think Google is the same) keeps the private key inside the secure enclave (security processor), but it is still copied to each new device - though it is end-to-end encrypted during that transmission.
As I said, the attestation structurally does NOT attest to your OS or your browser that are displaying the website performing the authentication. It attests to the device that holds the passkey's key material, which is usually not your desktop computer.
That's a matter of implementing an open standard. Google hasn't done anything to prevent open source browsers and OSes from implementing it, and nothing in the spec makes it difficult for Firefox/Linux specifically AFAICT.
The attestation actually has nothing to do with the browser, only the holder of the passkey's key material. You can satisfy the attestation by having a passkey on your Android device and doing the normal Bluetooth flow with your Firefox browser on your Framework laptop. So this mechanism is totally useless for enacting this plan.
The operating system doesn't manage attestation because that's totally useless for the stated goal of the attestation system. Enterprises don't want their SaaS vendors to accept passkeys from some random employee's BitWarden, instead of the hardware keys they issued the employee. If the OS manages attestation and doesn't send anything to the relying party, then it doesn't solve anybody's problem at all.
Most of these systems already do this, especially since very few applications have a flat encryption key hierarchy regardless of passkeys. The counterpoint would be that not everyone will set up multiple passkeys unless you require it on sign-up, but you're going to have that problem with any other method of storing end-to-end encryption keys. Might as well piggy-back on the password manager's replication methods.
How many people are doing a spring cleaning of unused passkeys in their password managers? We're talking like a kilobyte of data, nobody needs to delete these things in any kind of normal circumstance.
Sure, it would be great if users would store 5 copies of their encryption keys, with one in a lockbox on the bottom of the ocean. But that's just not going to happen at any kind of scale, so an automatic way of putting encryption keys in a replicated password manager makes sense. And compared to how people normally handle end-to-end encryption keys, it's going to result in a lot less loss data in practice.
What about this ban is anticompetitive? The only think I can think of is accusing them of dumping product (as opposed to price discrimination), in which case the remedy is going to be to making them charge the API price for everything.
Okay, but now you’re running a country-scale VPN service in Russia or whatever, and somebody has to pay for it. Or you have to acquire a botnet, again to handle the internet of a whole country. These are non-trivial barriers to overcome, and simply having transit to Russia does not solve them.
How useful is a GPS position for theft prevention? IME cops are not interested in doing more than filing a report after a theft, even if you have a live GPS location of the item for them. Do you try and go get it yourself?
If they mean a real proxy, that’s even more involved - you can’t just do that with BGP configurations and will need someone running what is basically a country-wide VPN in Russia or China (which will probably be very identifiable).
IPs owned by Iranian entities could be blocked straightforwardly by network operators at various levels. They could probably fudge the paperwork via Russian or Chinese entities and obfuscate the routes with cooperation from Russian/Chinese network operators, but that would take time.
Does the Iranian economy rely heavily on access to the global internet? They can’t trade with most of the world due to sanctions, so what in their internal economy grinds to a halt without global communications? I’m not saying I think that it wouldn’t, just that I don’t immediately grasp the mechanism.
Even if you don't have fiber all the way into your house, most cable internet terminates pretty close to the home these days. It kind of has to, since bandwidth has gone way up and as a result they can't put very many subscribers on the same termination system.
We didn't really understand this kind of thing when the Carrington event happened, so nobody knows for sure, but estimates for induced voltage on long conductors are usually something on the order of 20V/km. So for a 5 km long coaxial cable, you're only talking about ~120V of induced potential difference (i.e. the same voltage as a residential plug in the US). When people are analyzing the potential damage from this kind of electromagnetic disturbance (E3 is the term you'll see, based on analysis of nuclear EMP which has other components that you don't see in geomagnetic storms regardless of severity), it's mostly about really long conductors, like on the order of 100km.
Yes, and it’s quite inefficient compared to L4 or Zircon’s IPC so it isn’t used for anything that wouldn’t work just fine over a SEQPACKET socket using SCM_RIGHTS like Linux does. Is modern Windows a microkernel because ALPC exists?
All the major OSes have components of the larger operating system that run in userspace and communicate via IPC, including Linux. But userspace drivers and basic system services (VFS, network stack, etc.) are very limited in their use of userspace/IPC. If macOS is a microkernel in the sense of those built on L4, then so are Windows and Linux, and the word doesn't have any meaning anymore.
They're threatening to take their ball and go home. If they move all of their operations out of Italy, under what principle does Italy demand they block content globally? Should Wikipedia remove their page on Tiananmen Square because the Chinese government demands it (which they would, if they thought it would work)?
They can read the statement, and the definitions that the statement references. If everything it references is in a well-tread part of the Lean library, you can have pretty high confidence in a few minutes of going over the syntax.
A warning doesn’t help at all. The main threat model for FDE is that someone steals your device and dumps the disk. If you don’t protect the boot process somehow, then you’re just storing the encryption key next to the data.
If you don’t care about that (which is not “military level security”, laptop thieves stealing creds is a thing), just don’t use FDE or use it with an on-boot password every time. No point in the theater.
I mentioned XNU below. It doesn’t really count as a microkernel if you, you know, don’t actually use the microkernel part. At least for the 30 years between the FreeBSD collision and the introduction of DriverKit, which does most of its IPC through shared memory (because the mach ports are not efficient enough, I would assume).
These are pretty much all about mandatory locking. Which giveth and taketh away in my experience. I’ve had substantially fewer weird file handling bugs in my Linux code than my Windows code. POSIX is very loosey-goosey in general, but Linux’s VFS system + ext4 has a much stronger model than the general POSIX guarantees.
`FILE_FLAG_DELETE_ON_CLOSE`’s equivalent on Posix is just rm. Windows doesn’t let you open new handles to `FILE_FLAG_DELETE_ON_CLOSE`ed files anyway, so it’s effectively the same. The inode will get deleted when the last file description is removed.
NFS is a disaster though, I’ll give you that one. Though mandatory locks on SMB shares hanging is also very aggravating in its own right.
It depends what they mean by some of these: are the state machine race conditions logic races (which Rust won’t trivially solve) or data races? If they are data races, are they the kind of ones that Rust will catch (missing atomics/synchronization) or the ones it won’t (bad atomic orderings, etc.).
It’s also worth noting that Rust doesn’t prevent integer overflow, and it doesn’t panic on it by default in release builds. Instead, the safety model assumes you’ll catch the overflowed number when you use it to index something (a constant source of bugs in unsafe code).
I’m bullish about Rust in the kernel, but it will not solve all of the kinds of race conditions you see in that kind of context.