There is no downside to nested encryption, except of course the performance overhead. But this only really makes sense if each layer has an independent key and each layer uses an algorithm from a different family. Improper key reuse weakens the scheme.

For symmetric cryptography like AES the benefit is dubious. It is far more likely that the content is decrypted because the key was acquired independently than that AES would be broken.

However, there absolutely is a benefit for asymmetric crypto and key agreement schemes. This is how current Post-Quantum Cryptography schemes work, because:

• commonly used algorithm families like RSA and Elliptic-Cuve will be broken as soon as a sufficiently large quantum computer exist
• proposed PQC algorithms are comparatively immature, and some of them will be broken in the near future

Nesting one algorithm from each family gives us the best of both worlds, at a performance overhead: conventional asymmetric cryptography give us temporary security in the near future, and the second PQC layer gives us a chance at long-term security.

The text does technically give the reason on the first page:

It is not a regular language and hence cannot be parsed by regular expressions.

Here, “regular language” is a technical term, and the statement is correct.

The text goes on to discuss Perl regexes, which I think are able to parse at least all languages in LL(*). I’m fairly sure that is sufficient to recognize XML, but am not quite certain about HTML5. The WHATWG standard doesn’t define HTML5 syntax with a grammar, but with a stateful parsing procedure which defies normal placement in the Chomsky hierarchy.

This, of course, is the real reason: even if such a regex is technically possible with some regex engines, creating it is extremely exhausting and each time you look into the spec to understand an edge case you suffer 1D6 SAN damage.

FYI https://privacytests.org/ gives a good browser privacy comparison. No affiliation and don’t know how correct the data is.

After that project was started, the author started working for Brave.

The data and tests seem good, but some aspects of the methodology are opinionated. For example, browsers are tested in their out of the box configuration, not in a configuration that a reasonably privacy-conscious user would select with a couple of clicks. Thus, a browser dedicated to blocking tracking (like Brave) gets a lot more checkmarks than a general audience browser like Firefox.

LibreWolf is essentially Firefox with all those privacy features pre-enabled.

In the language of Polandball comics, it means “give land/territory”.

“Gib” is taken from the German imperative for “give!”

Best theory is that “clay” as “land” originates from a bad machine translation.

It seems somene created a Wiki that covers these terms: https://www.polandballwiki.com/wiki/Terminology#Clay

Synology’s DSM has built-in MFA support, though it also has some features for external identity management. I don’t think Keycloak and so on would be compatible though.

C++ does have the problem that references are not objects, which introduces many subtle issues. For example, you cannot use a type like std::vector<int&>, so that templated code will often have to invoke std::remove_reference<T> and so on. Rust opts for a more consistent data model, but then introduces auto-deref (and the Deref trait) to get about the same usability C++ has with references and operator->. Note that C++ will implicitly chain operator-> calls until a plain pointer is reached, whereas Rust will stop dereferencing once a type with a matching method/field is found. Having deep knowledge of both languages, I’m not convinced that C++ features “straightforward consistency” here…