If I'm reading any of this correctly, this doesn't apply to hardware attestation.
It seems apple has a service, with an easily rotated key and an agreement with providers. If the key _Apple_ uses is compromised, they can rotate it.
BUT, apple knows _EXACTLY_ who I am. I attest to them using my hardware, they know _EXACTLY_ which hardware I'm using. They can ban me or my hardware. They then their centralized service gives me a blind token. But apple, may, still know exactly who owns which blind tokens.
However, I cannot generate blind tokens on my own. I _MUST_ talk to some centralized service that can I identify me. If that is not the case, then any single compromised device can generate infinite blind tokens rending all the tokens useless.
The idea behind blind signatures is that the server will give you a signed token which is blinded and you can un-blind it on your end and then use it. The consumer of the token will not be able to collude with the issuer of the token to figure out who it was given to. There is more info here: <https://blog.cloudflare.com/privacy-pass-the-math/>
I don't know if that's what Apple actually does. If it is, once it gets popular enough as an anti-bot measure there may be farms of Apple devices selling these tokens. It's a separate system from remote attestation anyhow.
Maybe not so doable. The whole point of io_uring is to reduce syscalls. So you end up just three. io_uring_setup, io_uring_register, io_uring_enter
There is now a memory buffer that the user space and the kernel is reading, and with that buffer you can _always_ do any syscall that io_uring supports. And things like strace, eBPF, and seccomp cannot see the actual syscalls that are being called in that memory buffer.
And, having something like seccomp or eBPF inspect the stream might slow it down enough to eat the performance gain.
There is some interesting ongoing research on eBPF and uring that you might find interesting, e.g., RingGuard: Guarding io_uring with eBPF (https://dl.acm.org/doi/10.1145/3609021.3609304
).
Ain’t eBPF hooks there so you can limit what a cgroup/process can do, not matter what API it’s calling. Like disallowing opening files or connecting sockets altogether.
No. A batch of submission queue entries (SQEs) can be partially completed, whereas an ACID database transaction is all or nothing. The syscalls performed by SQEs have side effects that can't reasonably be undone. Failures of operations performed by SQEs don't stop or rollback anything.
Think of io_uring as a pair of unidirectional pipes. You shove syscalls and (pointers to) data into one pipe and the results (asynchronously) gush out of the other pipe, errors and all. Each pipe is actually a separate block of memory shared between your process and the kernel: you scribble in one and read from the other, and the kernel does the opposite.
In 2007 several people and I started NYC Resistor, a hacker space in Brooklyn, completely unaware of this resistors in New Jersey.
It was over 10 years later that any of us heard of this much older resistor. It's kinda it funny how similar we are to them, nearly shared a name, and completely unaware of each other.
The world needs more places where people can explore their curiosity of how things work.
Nix in production is more common than you think, even at scale.
It's hard to know what exactly your security concerns are here, but if you look at the current ecosystem of using containers and package registries, Nix is pretty clearly a solid contender, security-wise.
Plenty of wildly unsafe behavior is common in production infrastructure today. This is also why compromised corporate infrastructure is in the news so often. Few orgs hire or even contract security engineers with Linux supply chain and hardening experience, opting to blindly trust the popular options and their maintainers.
NixOS knowingly discards vital supply chain integrity controls to minimize developer friction and maximize package contributions. It is a highly complex Wikipedia style distribution optimizing for maximum package variety which is absolutely fine and great for hobby use cases, but use in security critical applications is absolutely irresponsible.
Guix goes some big steps further in supply chain integrity but still ultimately trusts individual maintainers.
Long article, but the fundamental premise is that IMAP, SMTP, and POP are all you need. And that email clients are good... This is just false IMHO. There is a reason why both Fastmail and Gmail implement their own protocols in addition to those.
But fundamentally the "folder" view of email does not work. A single message often needs to be in several different folders simultaneously. And when the thread is spread across many folders, there needs to be a way to see the whole thread.
The only way to accomplish this is with email tags or labels. These are implemented by nearly all successful email companies. Gmail, Fastmail, and Proton are examples. Labels are a fundamental feature in this day and age, and neither IMAP nor POP can handle them gracefully.
Gmail is so big that when Outlook, Apple Mail, and even Thunderbird connect to it, they do an OAuth exchange and then talk over a proprietary protocol.
JMAP may have poor adoption, but it's the only open protocol that understands labels well. The lack of adoption is mostly due to email providers not implementing it. There is not a lot of incentive for clients to implement it for the few providers. And providers would prefer you use their web clients anyway, as then they control access to your email.
> Gmail is so big that when Outlook, Apple Mail, and even Thunderbird connect to it, they do an OAuth exchange and then talk over a proprietary protocol.
>A single message often needs to be in several different folders simultaneously
Just No. This is by far my biggest complaint of using Gmail.
It makes it impossible to write rules to file mail into folders as all you can do is add tags (labels). Whereas to _move_ you require the ability to unset and label which tags/labels don't support as thats a definining function of a folder.
Make Email Great Again! Now thats a campaign i'd be willing to fund!
This again is a limitation of mapping labels to IMAP, which does not understand labels.
Both the Gmail web interface and the Gmail API allow the ability to set all the labels for a message. This can effectively enable your desired functionality. But IMAP can only deal with "folders", and cannot correctly decide when to remove a single label or remove all other labels when it sees a move action.
IMAP also only deals in messages and not threads. Gmail labels also technically only apply to messages, but the web interface shows the union of all labels of a thread. This is another decision I agree with. It means that when someone explicitly adds me to a thread, the whole thread gets highlighted in my feed.
I personally really enjoy the Gmail/fastmail/proton behavior so please don't make another political campaign to make things worse again. We have enough of those.
File extensions are just a hint about what the file might be and have nothing to do with what the file actually is. If the server sets the MIME type, the browser will use that as the hint.
But even beyond that, most file formats have a bit of a header at the start of the file that declares the actual format of the file. Browsers already can understand that and use the correct render for a file without an extension.
I'm not so sure most people would agree with you. Though I think plenty would.
I dare say that developers like environment variables more than before. Consider that Docker images, and hence Helm charts, are entirely controlled via environment variables. These very popular dev tools suffer from the same problem of having near-zero easy discoverability of what those environment variables might be. Yet they are very popular.
But I don't think Make usually uses all that many environment variables. You're usually specifying build targets as the command line arguments. Automake and autogen usually generate these makefiles with everything hard-coded.
Also, it makes it very easy to get started with, and it is universally available. Makes it very easy to like.
And don't even think about starting a sentence with 'and'.
I think we're taught rules like this to prevent us developing bad habits at the outset. Then, once we have more experience, we know when it's okay to break the rules.
You should look into why cities use smooth asphalt over concert which would be significantly less maintenance.
Cars driving around create a lot of noise. Driving on a rough surface like concert, let alone a bumpy surface like brick or cobblestone, creates a ton of additional noise. Another hint is that gravel driveways are cheap, but they also make it very very easy to hear when someone is pulling up to your house.
Anyone living next to these roads _might_ have some cars go a bit slower, but at the cost of not being able to sleep at night.
Then there is the fact that America loves big cars with big off roading wheels. I think the assumption here is that most speeders would be discouraged by the uncomfortable ride, however I think reality is that the people in that hummer going 90mph on a city street just won't care about a rougher ride.
It seems apple has a service, with an easily rotated key and an agreement with providers. If the key _Apple_ uses is compromised, they can rotate it.
BUT, apple knows _EXACTLY_ who I am. I attest to them using my hardware, they know _EXACTLY_ which hardware I'm using. They can ban me or my hardware. They then their centralized service gives me a blind token. But apple, may, still know exactly who owns which blind tokens.
However, I cannot generate blind tokens on my own. I _MUST_ talk to some centralized service that can I identify me. If that is not the case, then any single compromised device can generate infinite blind tokens rending all the tokens useless.