1 karma · joined December 26, 2025
In fact, rather than bash the DOM, Mario wants the DOM to subsume his own DOMPurify project, rather than have users trust him as a third-party module developer. I think that paints the DOM in a favorable light if you ask me.
The slides provide several reasons why server-side algorithms are worse.
"the situation is better client-side, because when running code on the client's side, you can check how exactly the browser parses the HTML code."
Yes, and for this reason, DOMPurify is a client-side sanitizer.
I think you meant to type that you can't sanitize in the "server"? Because with end-to-end encryption the server has no access to the plaintext to be sanitized. Only the client can sanitize, only the client has the plaintext.
I would be more concerned of using server-side sanitizers due to the impedance mismatch between client/server HTML parsing algorithms.
Hello
...
...
Thanks!An edge case when designing a log-structured file system is that a corrupt checksum in a log entry could actually mean one of three things: power loss while writing the last transaction, a misdirected write or bitrot, or a misdirected read.
If you simply read the log up until the corrupt checksum, assuming this can only mean one thing, then you might fall too far back and lose data that has been acknowledged to the user as synced. This could in turn then break the guarantees required for implementing things like Paxos, which could ultimately wreak havoc with a distributed system.
To detect power-loss, you need more than just a checksum. You need a checksum, but you also need a way to "snap" the new log tail onto the old log tail in a two-phase commit. So you write out all your data, then you write out your new log tail, then you sync, then you snap your new log tail on using two atomic sector writes, one of which needs to be synced.
The number of syncs are the same as before, you haven't actually added any additional syncs, but this way you ensure that your log references data which exists, and you can now tell the difference between a power failure and a corrupt log entry.
A power failure is recoverable (roll back), but a corrupt log entry is unrecoverable (assuming no log entry replicas) and means the file system is unmountable.
Prefer dependencies with smaller flatter dependency trees.
At some point, developers need to take responsibility for the security of their projects. If your project is larger, you will need to maintain more code, whether directly or indirectly. You can't simply import a dependency but never audit it. And if you're taking the trouble to audit a third-party dependency, at some point it becomes worth maintaining directly.
> sensitive dependencies, like crypto or network / http libraries.
I am not suggesting that developers reimplement TCP.
To ameliorate the risk, the security of all 73 dependencies would need to be at least an order of magnitude greater, just to catch up to shells with no dependencies.
The irony is that this lack of "dependency-safety" is far more easily exploitable than any previous lack of "memory-safety".
Of course, this can be easily fixed if developers stop multiplying third-party dependencies, so that importing a dependency involves O(1) risk, not O(?).
If you need to run Levenshtein Distance over tens of thousands of strings, perhaps as part of a fuzzy search, and you only need to match on distances of 0 or 1, not any distance in general, then there's an optimization on Levenshtein Distance where you hard code the function just for distances of 0 or 1. It's not difficult to do and the payoff might enable new applications of what would otherwise be too costly.
No, not "history" in the git sense, just "history" in the simpler email sense, i.e. "email history", all past emails in their final converged state.
CRDTs handle split brain fine. They eventually converge. You just don't want your clients flapping in the meantime by resyncing tons of data. That's where a distributed sync algorithm would help keep things working in the interim.
Does JMAP then not support syncing full history efficiently as a key design priority?
> That would be a pretty massive change to the entire data model of IMAP. It's never going to happen[tm].
Sure, and that's why I had hoped JMAP would, especially in a distributed master setting, since this was something IMAP overlooked.
I guess it's because JMAP still needs to be backwards-compatible with the strict consistency master-slave restriction of IMAP?
> What we use for IMAP replication in Cyrus is much dumber than all this - it uses a per-message CRC and XORs them together for the whole mailbox to create the sync_crc value. If those don't match, it does a resync. Fixes up split brain just fine while being cheap and dumb for the common case.
You're implementing the first layer of an incremental Merkle tree right there. How many bits are those CRCs just out of interest?
Thanks for this. It was a good read and promoting UIDs instead of bumping UIDVALIDITY is a great idea.
Surely, it would be even better if IMAP had support for distributed Merkle Tree synchronization, so that clients can sync with different server replicas without the server replicas having to coordinate or promote UIDs at all in the first place?
I don't know of any algorithm other than a Merkle Tree that will do this correctly and simply and efficiently in a distributed setting?
How does it do this in a distributed setting? When clients might be connecting to multiple servers with different states?
Yes, IMAP requires expensive coordination among multi-master servers to generate UIDs in such a way that won't mess with client synchronization. In other words, IMAP is not a fully distributed design, it assumes a centralized control plane (think Raft or Paxos), i.e. a single central server with many distributed clients, which is a shame for new systems building on CRDTs.
How does JMAP address this achilles heel of IMAP? Merkle tree sync?
More detail on the problem: https://news.ycombinator.com/item?id=20479011
Do you know if anyone who was there managed to record the talk? I asked Usenix already but they weren't recording.
And to be fair, Rust does introduce memory issues of its own in terms of allocation strategy. For certain projects, Rust would not be considered "safe" with respect to memory.
Zig's release-safe mode is worlds away from "the memory bugs that exist in C".
No, they don't. See Zig's release-safe mode.
Also: https://news.ycombinator.com/item?id=17184929
> the trade-off that the Rust offers is more in line with my values and my ethics.
By the way, it's awesome that you like Rust, but there's no need to imply there's something ethically wrong with Zig. Depending on the platform you're targeting, you may yet find a use for either language.
I wrote @ronomon/mime [1] for this purpose, to protect downstream user email clients from MIME bombs [2], invalid charsets which can crash Apple Mail, multiple From headers which can exploit Gmail [3], attachment directory traversals, malicious continuation indices, truncated MIME messages, stack overflows etc.
[1] https://github.com/ronomon/mime
[2] https://snyk.io/blog/how-to-crash-an-email-server-with-a-sin...
[3] https://blog.cotten.io/ghost-emails-hacking-gmails-ux-to-hid...
These metrics also need not necessarily by definition take longer to notice gray failures. You can detect a gray failure transfer rate without having to wait 30 seconds. Another example, but a second or two is enough to notice disk latency issues (and retry to a faster disk), which is probably in the same granularity as the window for detecting "Connection refused".
Function.toString being more accurate is helpful.
But real progress would be removing dangerous backtracking regular expressions in favor of RE2: https://github.com/google/re2/wiki/Syntax
We moved away from ClamAV because it detected less than a tenth of virus samples we tested in practice. Simple things like EXEs, ISOs, VBAs and JS attachments.
VirusTotal uploads showed the same single digit detection rate for ClamAV.
I thought ClamAV was a better scanner, have things stagnated?
https://snyk.io/blog/how-to-crash-an-email-server-with-a-sin...
In other words, your text parts can have lines of arbitrary line length, provided you encode them as QuotedPrintable or Base64 and set the Content-Transfer-Encoding header accordingly, which most email clients do.