I’ve not been to one of these things, but I’m assuming you have to use your phone tobshow the barcode if it’s changing ‘every few seconds’. From the description it sounds more akin to something like TOTP, where each person’s code is derived from a secret key and the current time. The barcodes aren’t random, but mathematically derived and only the current one works. If that is the case the hackers need the secret keys, not the barcodes, and they need to build an app to display the right one at the right time.

I like it, this is clearly very enterprisey and solution focused, but I would like to suggest a couple of amendments if I may?

• Namespaces We should make full use of namespaces. Make the structural tags be in a language specific namespace (to be referenced in every function spec, obviously) but change the in an out params to use the parameter name as the tag, namespaced to the function they’re for, with a type attribute.

• In memory message queues Have all function invocations be marshaled as xml documents posted to an in memory message queue. Said documents should use a schema that validates the structure and a function specific schema to validate the types of arguments being passed. Namespace everything.

I reckon we could power a medium sided country if we could generate energy from the programmers despair.

If you’re talking about being able to regain access with no local backups (even just a USB key sewn into your clothing) your going to need to think carefully about the implications if someone else gets hold of your phone, or hijacks your number. Anything you can do to recover from the scenario is a way an attacker can gain access. Attempting to secure this via SMS is going to ne woefully insecure.

That being said, there are a couple of approaches you could consider. One option is to put an encrypted backup on an sftp server or similar and remember the login and passwords, another would be to have a trusted party, say a family member or very close friend, hold the emergency codes for access to your authentication account or backup site.

Storing a backup somewhere is a reasonable approach if you are careful about how you secure it and consider if it meets your threat model. The backup doesn’t need to contain all your credentials, just enough to regain access to your actual password vault, so it doesn’t need to be updated often, unless that access changes. I would suggest either an export from your authentication app, a copy of the emergency codes, or a text file with the relevant details. Encrypt this with gpg symmetric encryption so you don’t have to worry about a key file, and use a long, complex, but reconstructable passphrase. By this I mean a passphrase you remember how to derive, rather than trying to remember a high entropy string directly, so something like the second letter of each word of a phrase that means something to you, a series of digits that are relevant to you, maybe the digits from your first friend’s address or something similarly pseudo random, then another phrase. The result is long enough to have enough entropy to be secure, and you’ll remember how to generate it more readily than remembering the phrase itself. It needs to be strong as once an adversary has a copy of the file they jave as long as they want to decrypt it. Once encrypted, upload it to a reliable storage location that you can access with just a username and password. Now you need to memorize the storage location, username, password and decryption passphrase generator, but you can recover even to a new phone.

The second option is to generate the emergency, or backup, codes to your authentication account, or the storage you sync it to, and have someone you trust keep them, only to be revealed if you contact them and they’re sure it’s you. To be more secure, split each code into two halves and have each held by a different person.

I’ve found HSBC to be ok using Firefox on Linux. I don’t know if they have integrations with any accounting software, but the web access works well, and you can export your transactions for processing locally.

ETA: I’ve run small business accounting on Gnucash, I found the learning curve a bit steep, but once you ‘get it’ it’s handy.

Sorry for the slow reply, life occurred.

I think I understand where you’re coming from with the desired to be productive and not reinstall. I think I’ve been there too! One thing that I can suggest, if you do have the time, is to learn a system like Ansible and use it to setup and configure your machine. The discipline of keeping all of the config as source rather than making ad-hoc changes reduces the chance of thinking you’ll make just one little change and breaking something, and, if something does go wrong, you can get back to your working configuration quickly.

Bearing in mind that there really isn’t anything you can do to stop yourself if you’re really determined to not lose the data, because if you can read it at any time you can back it up, the closest you are likely to come is something like creating new key with GPG then using the TPM to wrap your secret key and deleting the original. That way the key is only usable on that specific machine. Then use the key-pair to encrypt your ‘guard’ files. You can still decrypt them because you have the wrapped secret keys and you’re on the same machine, but if you wipe the drive and lose those keys the data is gone. The TPM wrapping prevents you from taking the keys to a different machine to decrypt your data.

There’s an article with some examples here,

Having said all of that, this still doesn’t help if you just clone the disk as all of the data, including the wrapped key and the encrypted files will be cloned. The one difference there is that the serial number of the hard drive will be different. Maybe you could use that, combined with a passphrase as the passphrase for your GPG key, but we’re getting into pretty esoteric territory here. So you could generate a secret key with a command like:

( lsblk -dno SERIAL /dev/sdb ; zenity --title "Enter decrypt password" --password) | sha1sum | cut -c1-40

Where /dev/sdb is the device your root partition is on. zenity is a handy utility for displaying dialogs, there are others available. In this use it just prompts for a passsword. We then concatenate the drive serial number from lsblk with the password you entered and hash the result. The hashing is really only a convenient way to mix the two without worrying about the newline lsblk spits out. Don’t record the result of this command, but use it to set the passphrase on your new GPG key. Wrapping the secret key in the manner the article above suggests is a nice extra step to make it harder to move the drive to another machine or mess around in that sort of way, but not strictly necessary as that wasn’t in the scope of your original question.

Now you can encrypt your file with: gpg -e -r <your key name> <your file>'. That will produce an encrypted version of <your file>called<your file>.gpg. To decrypt the file you can get gpg` to use the hashing command from above to get the passphrase with something like:

gpg -d --pinentry-mode=loopback --batch --passphrase-fd 3 <your file>.gpg 3< <( ( lsblk -dno SERIAL /dev/sdb ; zenity --title "Enter decrypt password" --password) | sha1sum | cut -c1-40 )

Once you’ve tested that you can decrypt the file successfully you can remove the original, plaintext, file. Your data is now encrypted with a key that is secured with a passphrase made of a string you know and the serial number of your disk and optionally wrapped with a key from the TPM that is tied to your physical machine. If you change the disk or the machine the data is irretrievable (ignoring the caveats discussed above). I think that’s about as close to your original goal as you can get. It’s rough around the edges, and I’m not sure I’d trust my data to it, but I believe it’ll work. If you do something like this, please test it thoroughly, I can’t guarantee it!

‘This post is a palaeontological disaster’ is a marvelous turn of phrase, and I intend to steal it for use at the first opportunity.

ImHex requires a GPU with OpenGL 3.0 support in general. There are releases available (with the -NoGPU suffix) that are software rendered and don’t require a GPU, however these can be a lot slower than the GPU accelerated versions.

If possible at all, make ImHex use the dedicated GPU on your system instead of the integrated one (especially Intel HD GPUs are known to cause issues).

This sort of thing drives me round the bend. It’s a hex viewer, not a AAA game, why does it need or even care about your GPU. The data visualisation is nice, but there are other tools for that, Gnu Poke springs to mind.

Well yes, humpback whales reach sexual maturity by around 10 years of age (some much before then it seems). A marine biologist is still practically in it’s larval form at that point.

(Yes, yes, I know that wasn’t what you meant, but I couldn’t help myself)

Let them colonize the sun. That’d show us no-good heathens who’s boss, when we have to look up at their new home every day. Surely their god will keep them safe on such a glorious bit of missionary work.

I guess you could, although the gripper would add a bit of mass to the drone. You still lose some energy from the round into the yeeted barrel, but not as much as having an open breech. Depending on the mass of the projectile vs the mass of the barrel that could be a worthwhile trade-off.

There’s an easier and more reliable way to limit replication; don’t hive them the means to create a small but essential part, and instead load the first probe woth many copies of it and have each replica take a set percentage.

For instance, have the probe able to replicate everything but its CPU, and just load up a rack of them on probe 0. Every time it replicates itself it passes half of its remaining stock to the replica and they both carry on from there.

Crabadile - the ultimate lifeform.

This seems like a very complicated way to achieve your goal! It sounds like sitting yourself down and giving you a stern talking to might be a beter aporoach.

Having said that, if you have these very important files that you don’t want to lose, please make sure they’re backed up somewhere off of your machine. Storage fails, and it’s a horrible feeling losing something important. Unfortunately doing so would defeat the approach you’re thinking of.

This might be a case of needing to reframe the question to get to the cause of the issue, and then solve that. So, why do you want to make it hard to reinstall your machine? Is it the amount of time you spend on it, the chance of screwing it up, needing it working, has it become a compulsion or something else? Maybe if we can get to the root of the issue we can find a solution.

With regard to TPM, it’s basically just a key store, so you can use it fir anything really, althought it’s normally used by generating a TPM key and using it to encrypt the key that’s actually used to encrypt your data, storing the encrypted key with the OS. Just reinstalling won’t wipe the TPM, but unless you made an effort to save the encrypted key it’ll be gone. Given your problem statement above it just adds to the data you’d need to save, which isn’t helpful.

Yes, the hypothetical posed does reveal more about the human mind, as I mention in another comment, really it’s just a thought experiment as to whether the concept of an entity that doesn’t (yet) exist can change our behavior in the present. It bears similarities to Pascal’s Wager in considering an action, or inaction, that would displease a potential powerful entity that we don’t know to exist. The nits about extracting your consciousness are just framing, and not something to consider literally.

Basically, is it rational to make a sacrifice now avoid a massive penalty (eternal torture/not getting into heaven) that might be imposed by an entity you either don’t know to exist, or that you think might come into existence but isn’t now?

I think the concept is that the AI is just so powerful that humans can’t use it, it uses them, theoretically for their own benefit. However, yes, I agree people would just try to use it to be awful to each other.

Really it’s just a thought experiment as to whether the concept of an entity that doesn’t (yet) exist can change our behavior in the present.

I’m not suggesting it could, or would, happen, merely pointing out the premise of the concept as outlined by Roko as I felt the commenter above was missing that. As I said, it’s not something I’d take seriously, it’s just a thought experiment.

Whilst I agree that it’s definitely not something to be taken seriously, I think you’ve missed the point and magnitude of the prospective punishment. As you say, current groups already punish those who did not aid their assent, but that punishment is finite, even if fatal. The prospective AI punishment would be to have your consciousness ‘moved’ to an artificial environment and tortured for ever. The point being not to punish people, but to provide an incentive to bring the AI into existence sooner, so it can achieve its ‘altruistic’ goals faster. Basically, if the AI does come in to existence, you’d better be on the team making that happen as soon as possible, or you’ll be tortured forever.

Ok, I’m still not clear on exactly what you’re trying to achieve as I can’t quite see the connection between somehow preventing certain files being duplicated when cloning the disk and preventing yourself from reinstalling the system.

Bear in mind that reinstalling the system would replace all of the OS, so there’s no way to leave counter-measures there, and the disk itself can’t do anything to your data, even if it could detect a clone operation.

If what you’re trying to protect against is someone who knows everything you do accessing your data, you could look to use TPM to store the encryption key for your FDE. That way you don’t know the password, it’s stored encrypted with a secret key that is, in turn, stored and protected by your CPU. That way a disk clone couldn’t be used on any hardware except your specific machine.

Nothing can prevent a disk clone cloning the data, and there’s no way to make something happen when a disk is cloned as you’re not in control of the process.

If you wish to mask the existence of the files, use either full disk encryption, in which case cloning the disk doesn’t reveal the existence of the files without the decrypt password, or use a file based encrypted partition such as veracrypt in which case the cloner would just see a single encrypted blob rather than your file names.

Ultimately encrypting the files with gpg means they have already effectively ‘destroyed or corrupted’ themselves when cloned. If you don’t want to reveal the filenames, just call them something else.

If you could be a bit more specific about your threat model people may have better ideas to help.

I don’t think that’ll do it. The propellant deflagration is so quick that the momentum of the drone means it can’t be accelerated backwards enough to significantly reduce the force on the airframe. Even if it did, that would just end up applying the acceleration to the internals such as the batteries and motors/engine instead. I think you would need a spring damper that would allow the weapon to recoil quickly and dissipate the energy more slowly, and I’m not sure you could make obe effective on something the size of a drone.