>the various ACME clients like acme.sh are run with elevated privileges

Its really not that difficult to not grant excessive privileges - at the very least for recurring ("cron") runs, once filesystem structure, cache invalidation triggers and web server configuration are in place. Its a shame this is still taught in the "just run as admin" style.

That capability should be added to acme.sh, etc so that it automatically runs with minimal privileges for the invoked task. But people seem to assume privilege management is the sole responsibility of the packager or caller, despite the tool itself being better placed to know precisely which privileges are needed for the particular task it's performing.

acme-client on OpenBSD does this, using privilege separated processes that each in turn use pledge and unveil. You wouldn't know without looking at the source code because it's entirely transparent.

I'd say it's usually on the packager (or caller) because specying privileges depends on the platform you run on, which is better known by the packager or caler

CT indeed worked out pretty well. At least until bots started hammering crt.sh making it unreliable, and those that want to be alerted to newly issued certificated appeared in the logs need to pay for some purpose-built service instead of just adding a relevant query to their feed reader.

But.. the task was never "detect this" but always "detect this within acceptable constraints".

Sure, once you collect enough bits, you can tell that its me. And if you know from other sources that I am human, that solves your immediate problem. But if you do that, you have still failed at the task of detecting certain kind of abusive behavior without harming my anonymity.

How does this relate to the article? They weren't collecting bits until they identified a specific individual so I feel like I'm missing something.

The appendix lists what they were collecting, and the amount of samples needed for not just mathematically significant, but also practically useful distinguishing power implies collecting enough for a stable yet unique fingerprint. In that case you could just add a login form.. and still be less hostile than the increasing number of websites that will not let me browse (maybe my mouse movement does not match other humans in my region, idk).

> In that case you could just add a login form

This is the product insight. We're not going to deploy Stroop tasks for authentication :)

Is that not the commonly cited example for commodity trading, whereas meaningful comparison of fundamentals to market capitalization only started much later?

The idea is broadly similar, but I guess here's another example with a company this time.

https://en.wikipedia.org/wiki/Bengal_Bubble_of_1769

The point is that I don't think irrational exuberance in stocks is a recent thing.

Oh, they had those too back in the day: https://en.wikipedia.org/wiki/South_Sea_Company

That particular alias is mildly interesting. The obsession is with finally making progress in understanding the "We kill people based on metadata" threat. Maybe we can please finally stop stuffing PII & timestamps into each "crash report" and every "telemetry ping" and get back to work towards 100% reproducible outputs. (Well, right after I "enable javascript and cookies" because Cloudflare/Fastly/Akamai refuse to talk to me before they can grab a unique fingerprint..)

You are right. I just wish we didn't need victims to get change :(

Should not set it to nonsense, but rather low-entropy. If its unique, someone with access to old (browser, probably) crash reports might be able to cross-reference. Plus, not too long ago browsers did not care to sanitize the path for input[type="file"], so some websites remembered your account name somewhere in their database.

Also coincides with the time I started seeing Juniors installing "recommended extensions" into GitHub-hosted Visual Studio environments.. because there was a popup that helpfully suggested doing so, based on the programming languages used in the checked out repository.

I continue to receive phishing via AWS pretending to be Amazon. And not even the Unicode-lookalike shenanigans that my spam filter refuses for excessive mixed scripts, no; literally claiming to be Amazon as in: the company that operates the relay.

Easier: Do not start with a "allow all" configuration in the first place.

Maybe all of those userspace-work-done-in-kernel-because-muh-performance features should be restricted to (the "real") CAP_NET_ADMIN, unless positively enumerated as free-for-all-containers. And then subtract from that free-for-all list every time you learn that some kernel module in its currently available version cannot be trusted to do its own memory shuffling.

e.g. for a two keyword search, Google & DDG return results containing a similar (but more at the moment, more popular, so I understand why they do this) keyword as the first one, and no relation whatsoever with the second. Any search that manages to actually show results related to both of my input terms get the "better" award from me.