> as Ubuntu package will have same files structured exactly same way as Debian one.
As opposed to what? If Ubuntu uses the same source, of course they get the same binaries. And if Ubuntu applies patches, they'll get something different. And that's still true.
That’s one reason to use Inkscape. If I want to draw a design, I have a shape in mind I then try to draw by editing the points as I see them, with instant visual feedback. I don’t want to code in points and have to modify coordinates.
It’s like asking why people use a parametric CAD suite like NX if they could just use OpenSCAD.
If you want to model something, seeing it and editing it in the 3D view can be much nicer than editing code.
I don't have any points of comparison since I've never used Bitwarden, but it works well enough for my purposes. It'll match the url, offer to autofill (sometimes those multiflow sites like Microsoft will trip it up, but you can always just right click -> enter username/password for a site and that'll work), and it does TOTP filling too.
You do use the browser extension because it's a strong anti-phishing defense.
If someone links me to "rnicrosoft.com" with a perfectly cloned login page, my eyes might not notice that it's a phishing link, but my browser extension will refuse to autofill, and that will cause me to notice.
Phishing is one of the most common attacks, and also one of the easiest to fall for, so I think using the browser extension is on-net more secure even though it does increase your attack surface some.
I know proper 2fa, like webauthn/fido/yubikeys, also solves this (though totp 2fa does not), but a lot of the sites I use do not support a security key. If all my sites supported webauthn, I think avoiding the browser extension would be defensible.
Not having an account for every single damn website + only login from websites you actually entered without following a link goes a long way to avoid that.
Sure there may be existence of typosquatting here and there but they tend to be much easier to spot vs the phising url using unicode variants.
I don't save browser cookies for obvious privacy reasons and it's absolutely a big deal to not need to pull up some program and copy paste my login details constantly for every site.
I usually just use another profile for the stuff that I clear cookies when closing the profile. The other profiles I just use for a limited of sites that need logging in, each site is in its own container and I don't browse other sites on those profiles.
If I ever need to fill the login, I just do any of these:
- KeepassXC has auto-type feature, so I just choose the needed one and let it auto-type
- I enable the extension only when I need to log in and choose the one I need to fill (not auto-fill, but only fill when I click on the account from the extension pop-up dashboard).
I try to limit my account creation to the minimum. HN is one of the few, for the better or for the worse as sometimes I just think I should nuke it and stop wasting time commenting.
Dropbox is literally the worst anmong all. For every little feature, like setting a password it requires upgrading your already paid plan. It’s slow and offers nothing.
I put a Nextcloud snap on a VPS in the same city. Fast and no limitations.
I don’t know why the author likes AES 128 so badly. AES 256 adds little additional cost, and protects against store now decrypt later attacks (and situations like: “my opinion suddenly changed in few months”). The industry standard and general recommendation for quantum resistant symmetric encryption is using 256 bit keys, so just follow that. Every time he comes up with all sorts of arguments that AES 128 is good.
Age should be using 256 bit file keys, and default to PC keys in asymmetric mode.
> The industry standard and general recommendation for quantum resistant symmetric encryption is using 256 bit keys
It simply is not. NIST and BSI specifically recommend all of AES-128, AES-196, and AES-256 in their post-quantum guidance. All of my industry peers I have discussed this with agree that AES-128 is fine for post-quantum security. It's a LinkedIn meme at best, and a harmful one at that.
My opinion changed on the timeline of CRQC. There is no timeline in which CRQC are theorized to become a threat to symmetric encryption.
he pretty explicitly states that AES 128 is not in any imminent danger and mandating a switch to 256 would distract from the actual thing he thinks needs to happen.
So why argue about whether AES-256 is worth it if we can just literally replace those 3 characters and be done with the upgrade? This was the smart move already in 2001 when Shor's algorithm was known and computers fast enough that we don't notice the difference. At least to me, it seems like less bikeshedding will be done if we abandon AES-128 and don't have to deal with all the people left wondering if that's truly ok
Then again, something something md5. 'Just replace those bytes with sha256()' is apparently also hard. But it's a lot easier than digging into different scenarios under which md5 might still be fine and accepting that use-case, even if only for new deployments
There's a whole lot of cases where the tokens are temporary in nature with an easy cut-over, either dropping old entries or re-encrypting while people are not at work. We tend to think of big commerce like amazon or google that need 24/7 uptime, but most individual systems are not of that scale
In most other cases you increment the version number for the new data format and copy-paste the (d)e(n)cryption code for each branch of the if statement, substituting 128 for 256. That's still a trivial change to substitute one algorithm for another
Only if there exists no upgrade path in the first place, you have a big problem upgrading the rest of your cryptography anyway and here it's worth evaluating per-case whether the situation is considered vulnerable before doing a backwards-incompatible change. Just like how people are (still) dealing with md5
I'm working on just that in some IoT context, and a lots of chips I have to deal with only have hardware support for AES-128, so it's a little more complicated...
You can’t just throw “Grover’s algorithm is difficult to parallelize” etc. It’s not same as implementation, especially when it gets to quantum computers. It’s very specialized.
I felt that too, when I first used cursor/claude code, it was awesome and I just wanted keep building, the dopamine hit after shipping is really good. But later, when I needed to inspect the code manually, and I realized there were a lot of trash/dead/unoptimized code. I started drowning in the mess I generated. It is good until you need manual changes.
What is the best way to sandbox LLMs and packages in general, while being able to work on data from outside sandbox (get data in and out easily)?
There is also the need for data sanitation, because the attacker could distribute compromised files through user’s data which will later be run and compromise the host.
I wrote this[1] for myself last year.
It only gives access to the current directory (and a few others - see README).
So, it drastically reduces the attack surface of running third-party Python/Go/Rust/Haskell/JS code on your machine.
reply