It's brilliant at recapitulating the daya it's trained on. It can be extremely useful. But it's still nowhere close the capability of the human brain, not that I expect it to be.
Don't get me wrong I think they are remarkable but I still prefer to call it LLM rather than AI.
Some of the things we consider prerequisites of general intelligence (what we usually mean by when we talk about intelligence in these contexts) - like creativity or actual reasoning, are not present at all in LLMs.
An LLM is a very clever implementation of autocomplete. The truly vast amount of information we've fed it provides a wealth of material to search against, the language abstraction allows for autocompleting at a semantic level and we've add enough randomness to allow some variation in responses, but it is still autocomplete.
Anyone who has used an LLM enough in an uncommon domain they are very familiar with has no doubt seen evidence of the machine behind the curtain from faulty "reasoning" where it sometimes just plays madlibs to a complete lack of actual creativity.
> I call it a "bullshit generator" because it generates output "with indifference to the truth".
And if we follow the link we find he's referring to LLMs:
> “Bullshit generators” is a suitable term for large language models (“LLMs”) such as ChatGPT, that generate smooth-sounding verbiage that appears to assert things about the world, without understanding that verbiage semantically. This conclusion has received support from the paper titled ChatGPT is bullshit by Hicks et al. (2024).
No one thinks the database, orchestration, tool, etc. portions of ChatGPT are intelligent and frankly, I don't think anyone is confused by using LLM as shorthand not just for the trained model, but also all the support tools around it.
I wasn't thinking about their data store or other infrastructure. I was thinking about the layers added for reasoning and other functions that modify or guide the output of the LLM.
Just consider that storing TOTP codes in the password manager negates the advantage of two factors authentication, namely the added security of needing a second device. This would keep your logins safe even if somebody managed to breach your KeePassXC database.
All of this is true without 2FA, just storing securely generated passwords in the manager.
Whether it negates the benefits of 2FA (i.e. whether it's 1FA) doesn't depend on the threat model. The threat model is what makes an individual decide whether 2FA is worth it
No? Without TOTP in Keepass, an attacker still only requires a password (which may be brute forced or otherwise obtained from badly secured websites). If you have TOTP, they _also_ need a copy of your keepass-file, the password and any other factor to _it_, or have access to your machine during a session or so.
- "an attacker still only requires a password (which may be brute forced" Brute force? Then it wasn't generated securely. Use Keepass' built-in generator or another one that is meant to generate passwords with. You could make the same argument for the 2FA seed: that can also be generated insecurely or set manually by hand
- "or otherwise obtained from badly secured websites" The attackers can obtain the 2FA seed in the same way. Furthermore, the 2FA seed is stored plaintext in the website's database whereas the password is typically stored in hashed form (which is unbruteforceable if you generated it securely)
- "they _also_ need a copy of your keepass-file, the [main] password" The attacker either got the website's password from this same file (so they evidently have that file and the main password to unlock it), or if you imagine a scenario where the site got hacked and the stupid site stored your password in plain text, then they have access to the site (and the 2FA seed) anyway because they hacked it. So long as you don't re-use passwords (don't need 2FA for that, just a password manager), a site's breach has no impact beyond this one site that was hacked outside of your control
- "and any other factor to _it_" Do you mean the key file here? Or what other factor? Either way, again: if they need that to open the vault then they can't get at the passwords either, so what benefit does {2FA when stored inside the password vault} have?
I don't know of a scenario where an attacker can get the website's password from the vault, but not the website's 2FA seed, when you store both inside that same (encrypted) file
1. TOTP (the only 2F we could be discussing) is derived in a specific way by e.g. Keepass, which has been audited. There is an RFC for this. I don't see the vuln here.
2. But this info is transferred just once, so the method relies on either intercepted both (pw and TOTP seed) that one time. Far less likely than intercepting just the pw every time you login. With a compromised or insecure server: all bets were off already.
3. Even if you have safe service-dependent passwords, as one should, 2F renders it useless in certain scenario's, if all they have is the password.
4. Yes, factors to the keyfile. It does not have to be just a password.
While it seems a reasonable assumption that 2F seed and password are stored alongside eachother, the vuln does not need to expose both. We don't know. But we do know more factors means more opportunity for 1 factor to be accidentally safe.
It doesn't negate the advantage of 2FA. There are so many scenarios that don't involve your entire password manager database being leaked in plaintext. In that case, you likely have much more to worry about considering the attacker has a bunch of places to pivot from (account recovery flows, recovery email accounts, etc..)
The second factor does not have to be a second device. Like everything security, it’s what you’re protecting against. Shoulder surfing and device theft are not something I worry about in my home setup, for example.
> The second factor does not have to be a second device. Like everything security, it’s what you’re protecting against.
It doesn't matter if you store your 2FA seed on a billboard or as a tattoo where the sun doesn't shine: 2FA means two factors. The definition doesn't change when your home setup's threat model doesn't call for 2FA and you thus decide to store two secrets in the same place (making a compromise of one necessarily a compromise of the other, thus 1FA)
You're onto something even banks don't seem to understand! The industry standard for doing financial transactions calls for 2FA but then they make a mobile app that can self-approve transactions. Yes, using only one mobile device is 1FA, just like using one desktop only, but people generally consider mobile OSes safer because the permission model and process isolation is on a whole other level
There's a grain of truth in your statement, but no matter how hard it's to accept for all of us nerds here, in real life words are defined by usage. If industry calls it 2FA, users call it 2FA, then it's 2FA.
They can call the sky green but unless the wavelength changed, I don't see the benefit of taking over that terminology, no matter if you're a user or a nerd or both. That's the real-life situation: sky isn't green, idk why anyone would need to "accept" that or not when it factually isn't the case
Your choice of example is somewhat self-defeating: blue-green is probably the best illustration of terms with big semantic overlap even in languages which care to have separate words for these colors (there are those which has one word for both). Generally, meaning of words defined by informal convention of majority. You are free to disagree with it, but it only means you will speak your own dialect always in need to explain yourself to everybody who's not you.
Or Ente Auth: https://ente.io/auth. Opensource, encrypted, can be used on any OS, has sync/backup. The problem with using same password manager for OTP is that you kind of loose 2nd factor: 1 app compromised - passwords and OTP are compromised too. My approach is to use password manager's OTP generator for non critical services and dedicated app for the critical ones..
I also store them in KeePass, except I have a separate DB for codes that exists only on my phone. I use Keepassium on iPhone, on Android I believe Keepass2Android is pretty good.
On android I degoogled almost everything by using Fossify apps. Only gmail and maps remain for obvious reasons. My photos are now synced with Syncthing through my wireguard vpn. Calendar/Notes have local backups that are also synced. The simple camera I use (fossify too) works with physical directories instead of meta directories that I hate.
These clipboards are a privacy problem when you're sharing your screen. So many times a coworker has copy/pasted and a dialog with even passwords have been shown on screen...
I am from EU, so I can see it happening here, or in some smaller countries. Here, you already sort-of have an UBI, where you get enough social benefits to live off if unemployed.
With homeassistant you don't need yaml for 99% of automations. I'm sure OP posted the source code of the automation but used the graphical UI to make it.
You also have the possibility to use Node-Red for that.
I have used HA quite a bit and been burned. I think in the choice between graphical "no code" or "low code" and yaml, I choose yaml. But to do imperative logic there is just one useful way: a proper programming language.
This is just like when writing CI scripts for GitHub actions or Azure pipelines: the right amount of yaml (if it must be used at all) is to just invoke a program in some more expressive language than yaml.
Depending on when that was, it might make sense to try it again. I've got 25+ actively used automations and none of them need custom yaml anymore. Things really are continuously improving with every passing year.
I do use the (jinja) value templates in some places though.
reply