T3OU-736
Joined 8 years ago
Joined 8 years ago
My own helacipusly amateur take is that given the speed of and, intentional or otherwise, access to various things that the models are granted, it does seem super-useful to maintain the inspectability of chain of reasoning which lead to actions taken (and other artifacts) by the model.
If things become inscrutable, they are on the path of being ineffable.
https://keepass.info/help/kb/yubikey.html talks of different ways of doing something like that, but I've not played with it yet.
Another option is just to store passkeys natively on the token itself?
I... Am not sure how I feel about it. On tech merits, this absolutely makes sense - the tech is slinging private keys around, and their secure storage is a hard problem.
On the practical merits - maybe? Token-backed decryption of the password manager's database seems like a devent solution? But does this happen? Is there a password manager which uses the public key derived from FIDO2 token's on-chip private key to decrypt the database?
On-token storage is limited (though 100 passkeys on a YK 5 Nano is fairly generous) - but what if we just used the YK as the "Private key is here and ONLY here" setup?
I kinda like the OFFOAD+ design - it promises to show me to where I am authenticating. With origin binding should be a nobrainer, but still, it speaks to me.
The PCP is absolutely nowhere _near_ the graphical wizardry of the state of this app, and the overlay of executing code atop a given directory structure is quite beautiful (practicality be damned), but I can see the inspiration.
I do wonder if, on a modern Linux system with SELinix, this model (code accessing a directory) is actually closer to viable? SELinux's contexts/labels for subjects overlaying with the same for objects can, I imagine, be visualized. The normal access patterns would be way too overwhelming, I think - but exceptions/policy violations? :ponder:
The IRIX OS even had functionality to migrate kobs and theor working memory closer to each other to lower the latency of access.
We see echoes of this when companies like high-frequency traders pay attention to motherboard layouts and co-locate and pin the PTS (proprietary trading systems) processes to specific cores based on which DIMMs are on which side of the memory controller.
That does not appear to be true. The investagiom reporting shows that the shooter bought the guns after he turned 18 - the legal age to purchase them (long guns, aka rifles - different from pistols) in the state of Texas.
Buying things on credit seems like a reasonable way to do business in general - are you suggesting that all deadly weapons should be sold for cash to increase the difficulty of legally acquiring them and so lowering the frequency of mass shootings?
This is why NSA asked for (and got from SGI) a guranteed rate I/O API - to make sure that whstever the signal intelkigence platform sensors captured could be written to storage.
Not sure if there is any additional value in the re-coverage, though it does feel like the message is important enough to be spread, and I suspect there is more readers of The Verge than the original source.
(Not my core field, so this is SWAG-ish): There is also a separate but equally important problem of signal vs noise - isolating the signal for decryption. Doable, but fairly costly to implement, and far more brittle than I suspect would be acceptable.