That is not true, you can run DLP on an endpoint directly and inside a browser directly (e.g. via an extension or direct integration hooks).
You can also try to stop the situation where the CC numbers are in the clear anywhere in the first place, so that you can't copy/paste them around. What happens if someone writes the CC number down on a piece of paper?
Endpoint DLP helps but it's not even close to bulletproof. Just for fun, if you have DLP at work, open the integrated browser in VS Code and notice how you can send protected test strings without anything chirping you.
> CC numbers are in the clear anywhere in the first place
Sounds great in theory, until you realize that in a large number of industries the majority of employees need access to protected data to do their jobs. Imagine telling the IRS their employees can't see/use cleartext SSNs.
As for paper / mobile phones / whatever.. you're not wrong, but physical security is typically someone else's job.
This is good advice, and there's good people on the signature list, but why is this is an open letter? This feels navel-gazey and straight out of 2017.
ISRG (Let's Encrypt's parent entity) wrote Certbot, initially under the name "letsencrypt" but it was quickly renamed to be less confusing, and re-homed to the EFF rather than ISRG itself.
So, what you've said is true today, but historically Certbot's origin is tied to Let's Encrypt, which makes sense because initially ACME isn't a standard protocol, it's designed to become a standard protocol but it is still under development and the only practical server implementations are both developed by ISRG / Let's Encrypt. RFC 8555 took years.
Yes, it started that way, but complaining about the current auto-update behavior of the software (not the ACME protocol), is completely unrelated to Let's Encrypt and is instead an arbitrary design decision by someone at EFF.
As far as I remember, since the beginning certbot/let's encrypt client was a piece of crap especially regarding the autodownload and autoupdate (alias autobreak) behavior.
And I couldn't praise enough acme.sh at the opposite that is simple, dependency less and reliable!
Honestly I abandoned acme.sh as it was largely not simple (it’s a giant ball of shell) and that has led to it not being reliable (e.g. silently changing the way you configure acme dns instance URLs, the vendor building their compatibility around an RCE, etc)
Usually, completing the domain name by adding the final period will do the job. Instead of entering myprinter into the address bar, try myprinter. so your DNS server doesn't try to resolve myprinter, myprinter.domain, myprinter.domain.tld, and whatever other search domains have been configured. A real, fully-qualified domain ends in a period, though most tools will happily let you avoid that final period.
Alternatively, .local domains will work for mDNS-capable devices (and non-mDNS-capable devices if you like to risk things breaking randomly), and the .internal TLD has been reserved so .internal domains should also work for local addresses.
Chrome has shown the HTTP warning in Incognito mode for about a year, and has shown the warning if you're in Advanced Protection mode for about 2-3 years.
Wasn't Bun the project where the creator once tweeted something along the lines of "if you're not willing to work 50+ hours a week don't bother applying to my team"? Because if so then I'm not surprised and also don't think Zig is really to blame for that.
I'm pretty sure that in an overworked environment the engineers would reach for Rust's unsafe mode pretty quickly because they're too tired to make sense of the borrow checker.
I'm no expert, but I've been hacking in Rust for several years now, and the only unsafe I've written was required as part of building a safe interface over some hardware peripherals. Exactly as intended.
The borrow checker is something new Rust devs struggle with for a couple months, as they learn, then the rules are internalized and the code gets written just like any other language. I think new devs only struggle with the borrow checker because everyone has internalized the C memory model for the last 50 years. In another 50, everyone will be unlearning Rust for whatever replaces it.
OCSP stapling, when done correctly with fallback issuance, is just a worse solution than short-lived certificates. OCSP lifetimes are 10 days. I wrote about this some here [1].
You can also try to stop the situation where the CC numbers are in the clear anywhere in the first place, so that you can't copy/paste them around. What happens if someone writes the CC number down on a piece of paper?
reply