What about life expectancy? If smoking makes you die 10 years earlier, that's ~10 years of pension savings for social insurance. Sure, an unlucky few may get lung cancer at 50 and cost a lot of money but most smokers will die, retired, of cheap ailments like COPD or hypertension without fully realizing their social security investment.
Yes, public pensions make smokers even more fiscally positive on expectation.
(However in my adopted home we don't have public pensions like that. Your pension pot is yours, and if you keel over, your heirs get it. But smokers are still fiscally positive.
I brought up the NHS as a short-hand for any kind of healthcare system where the general taxpayer foots your medical bill.)
Can you share more about your particular setup? I use a pretty vanilla setup of Doom emacs on Linux, and while I really wish to give exwm a try my experience with emacs has been too unstable so far. E.g. it sometimes crashes when it gets an I/O error trying to write a file (which happens when a USB drive is removed by accident). A more common annoyance is the entire program freezing while waiting for plugins that should be asynchronous, like Tramp or some LSP servers.
For livestreams there's AceStream built on BitTorrent, but I think it's closed-source. They do have some SDK but I never looked into it. It's mostly used by IPTV pirates. I've used it a few times and it's hit-or-miss but when it works well I have been able to watch livestreams in HD/FullHD without cuts. Latency is always very bad though.
Then for video-on-demand there are some web-based ones like PeerTube (FOSS) and I think BitChute? Sadly webtorrent is very limited.
no. fingerprinting is like denying a kid at a carnival ride with a height check.
what this thread is about is denying a kid a kindergarten spot because the dna shows their height will never get them a basketball college scholarship.
Your example doesn’t make any sense, because they could do it right now: most of the kids are never going to get a basketball college scholarship, everyone knows it, including schools, and they don’t care
That dictionary normally has a lot of rather obscure/long/hard to remember stuff. If you 'reroll' until you get a password you like better you're taking an unknown hit to the entropy of the results.
It's better to use a dictionary where every word is acceptable and commit yourself to taking the first result or best of two (confining the human-selection entropy loss).
Though I don't have any suggestion for a suitable one that is just a wget away.
The post links to this GitHub issue [1] where the critic explains his issues with the design and the programmer asks him to elaborate on how those crypto issues apply to his implementation. The critic's reply does not convince me. It doesn't address any points, and refers to some vague idea about "boring cryptography". In what way is AWS secrets manager or Hashicorp Vault more "obviously secure" than the author's 72-line javascript file?
The criticism in that issue is pretty bad, I agree. But the crypto in secrets.js is all kinds of bad:
The use case is sometime calling this tool to decrypt data received over an unauthenticated channel [0], and the author doesn’t seem to get that. The private key will be used differently depending on whether the untrusted ciphertext starts with '$'. This isn’t quite JWT’s alg none issue, but still: never let a message tell you how to authenticate it or decrypt it. That’s the key’s job.
This whole mess does not authenticate. It should. Depending on the use case, this could be catastrophic. And the padding oracle attack may well be real if an attacker can convince the user to try to decrypt a few different messages.
Also, for Pete’s sake, it’s 2025. Use libsodium. Or at least use a KEM and an AEAD.
Even the blog post doesn’t really explain any of the real issues.
[0] One might credibly expect the public key to be sent with some external authentication. It does not follow that the ciphertext sent back is authenticated.
But having bad crypto doesn't mean you have to be aggressive... in fact if the critic's goal is to actually improve the situation (and not just vent or demonstrate their superiority) then being polite and actually answering the questions might go a long way further to remedy it.
You’re right. The problem is that after repeating the same thing hundreds of times to different developers you can develop a bit of an anger toward the situation, as you see the same mistakes play out over and over.
I’m not defending it, but I can understand where it comes from.
What's the point of filing the issue if you're already fed up giving adequate answers then? For a random open source project I'd definitely expect people who file issues to help solve them collaboratively.
I don’t disagree with you. The idea is that there is a lot of information online about how to do it right. I would have stayed to explain, because it’s confusing af, but I think that’s what happened. I don’t think soatok is intentionally self-serving, but I don’t know them personally.
Great question. AWS secrets and Hashicorp Vault have both been audited by a plethora of agencies (and have passed). GitHub code for someone's pet project very likely isn't going to pass any of those audits. When something goes wrong in prod, are you going to point your copy of 'some JS code that someone put on the Internet' and still have a job?
The very fact it was audited massively reduces the chances it’ll be breached compared to a random JS file that hasn’t been seriously audited. A “please read and tell me the problems” is NOT a security audit.
You can’t separate “auditing can reduce chance of breaches” from “using unaudited security critical software when certified alternatives exist can be gross negligence.”
Wow, the smugness of that reply. Responding by calling someone naive and blowing them off despite there being real questions.
The “insecure crypto “ that they clearly link to (despite not wanting to put them on blast) was also a bit overdone.
I guess we all are stuck hiring this expert to review our crypto code(under NDA of course) and tell us we really should use AWS KMS.
There are some weird attacks against KMS that I think are possible that are not obvious. For example KMS has a mode where it will decrypt without supplying a key reference (suspicious!). If an attacker can control the cipher text then they can share a KMS key from their AWS account to yours and then control the plaintext. I haven’t confirmed this works so maybe my understanding is incorrect.
Also, with KMS you probably should be using the data key API but then you need some kind of authenticated encryption implemented locally. I think AWS has SDKs for this but if you are not covered by the SDK then you are back to rolling your own crypto.
I agree with his comment and would like to add that the critic came across as rude and superior. Instead of answering the dev’s question in good faith, they linked to their own blog entry that has the same tone. Is it a cryptographic expert thing to act so rude?
Those aren’t even the correct answer for the use-case in question, anywho. What they’re looking for would actually be sops (https://github.com/getsops/sops), or age (made by the fantastic Filo Sottile: https://github.com/FiloSottile/age), or, hell, just using libsodium sealed boxes. AMS KMS or Vault is perhaps even worse of an answer, Actually
Taking some time to point out the vulnerability is already charity work. Assuming that's also a commitment to a free lecture on how the attacks work, and another hour of free consultation to look into the codebase to see if an attack could be mounted, is a bit too much to ask.
Cryptography is a funny field in that cribs often lead to breaks. So even if the attack vector pointed out doesn't lead to complete break immediately, who's to know it won't eventually if code is being YOLOed in.
The fact the author is making such a novice mistake as unauthenticated CBC, shows they have not read a single book on the topic should not yet be writing cryptographic code for production use.
> Taking some time to point out the vulnerability is already charity work
Sure, but if you’re not going to reason why the vulnerability you’re pointing out is an issue or respond well to questions then it’s almost as bad as doing nothing at all.
A non expert could leave the same Maintainers on many Github pages. Developers can’t be expected to blindly believe every reply with a snarky tone and a blog link?
>Developers can’t be expected to blindly believe every reply with a snarky tone and a blog link?
Developers are adults with responsibility to know the basics of what they're getting into, and you don't have to get too far into cryptography to learn you're dealing with 'nightmare magic math that cares about the color of the pencil you write it with', and that you don't do stuff you've not read about and understood. Another basic principle is that you always use best practices unless you know why you're deviating.
The person who replied to that issue clearly understands some of the basics, or they at least googled around, since they said "Padding oracle attacks -- doesn't this require the ability to repeatedly submit different ciphertext for decryption to someone who knows the key?"
In what college course or book is padding oracle described without mentioning how it's mitigated, I have no idea. Even Wikipedia article on padding oracle attacks says it clearly: "The CBC-R attack will not work against an encryption scheme that authenticates ciphertext (using a message authentication code or similar) before decrypting."
The way security is proved in cryptography, is often we give the attacker more powers than they have, and show it's secure regardless. The best practices include the notion that you do things in a way that categorically eliminates attacks. You don't argue about 'is padding oracle applicable to the scenario', you use message authentication codes (or preferably AE-scheme like GCM instead of CBC-HMAC) to show you know what you're doing and to show it's not possible.
If it is possible and you leave it like that because the reporter values their time, and they won't bother, an attacker won't mind writing the exploit code, they already know from the open source it's going to work.
If the snarky comment is "your crypto implementation is bad", then, yes, I would always take that seriously. If I really know what I'm doing then I'll be able to refute the comment; if not, then I probably should be using an audited library anyway.
Mistakes in crypto implementation can be extremely subtle, and the exact nature of a vulnerability difficult to pin down without a lot of work. That's why the usual advice is just "don't do it yourself"; the path to success is narrow and leads through a minefield.
It probably is stemming from the fact that cryptography needs to be perfect code to guarantee total confidentiality with complete integrity. Without this goal of writing perfect code, that always encrypts and decrypts, but only for the keyholder(s), they're simply begging to get things wrong and waste time.
How is it as bad if no signal means you'll likely never fix it, and some signal means you're more likely to fix it? Like seriously, this is the only 1 (one!) issue in this repo, not hundreds of bot vulnerability submissions, where is this fear of snarky replies come from?
> Developers can’t be expected to blindly believe every reply with a snarky tone and a blog link?
Sure, they can google around, read the blog, do other steps to educate themselves on crypto - all with their eyes wide open - before realizing they've made a big mistake and fixing vulnerabilities (and thanking the snarky author for the service)!
For hacks that don't access program memory directly, would external hardware make things less detectable? I don't know how anti-cheat programs work but I'd be surprised if they banned every skilled player that happens to be running AHK and OBS. More likely they work with heuristics that try to detect super-human mouse movements, precision/speed-wise.
> For hacks that don't access program memory directly, would external hardware make things less detectable?
Yes. But, it's a game of cat and mouse. Anticheat always is. There's not been a need go to the level of "there are X players who report having a Razer deathadder, which we've validated as having a DPI range of Y-Z. With your OS settings, it's not possible to have achieved that with that mouse therefore we suspect you of cheating". But we're probably there now.
> More likely they work with heuristics that try to detect super-human mouse movements, precision/speed-wise.
It's heurestics all the way down. You're unlikely to be banned for AHK+OBS, but a heurestic on what you're doing with the combo might ban you.
reply