notabot

“Cover meee witthhh foooodddd!”

I suspect that they’re hoping that, by dribbling it out, people get bored or fatigued of the story before they release the worst stuff. I don’t think that’s going to happen, but it seems like it might be their intention.

I’m glad it wasn’t just me that found the write up aggressive. They’ve undoubtedly done some good work finding these issues, but this was exhausting to read, and if they interacted with Mediatek in the same tone, I’m not surprised the interactions didn’t go well.

I was a picky ass eater.

That’s something we should all be picky about.

The hierarchy of offensiveness seems weird

I was initially of the same opinion, but actually, which of those would you be most offended to be called? I wonder if that’s the scale they’re using?

It’s likely only showing autocomplete for commonly used works, or maybe words that are statistically likely to be next, otherwise the list would be enourmous. There is a setting to not show offensive words, disabling that make is show pedophile as an option.

The general process would look something like:

1. Find all of the SSH keys you want to replace.
2. For each of thise keys, identify everywhere you use it to authenticate, and write this down! This list will form the basis of the rest of the plan. Make sure you list all of the accounts/servers you log in to, and don’t forget things like github or other external systems if you use them.

You’ll need to perform the following steps for each SSH key you are replacing:

1. Rename the public and private keys to something like old_id_rsa and old_id_rsa.pub (obviously use the same type name as your key, just prefix old_)
2. In your ~/.ssh/config, add a line telling SSH to use the old key as well as the new ones: IdentityFile ~/.ssh/old_id_rsa (change the key filename as aporopriate)
3. Check you can still log in to the servers you could log in to before. It should still be using the old key, just with a different filename, so it should still work.
4. Generate your new SSH keys ssh-keygen -t ed25519
5. Log in to each server and ADD the new ~/.ssh/id_ed25519.pub key to the authorized_keys file or equivalent mechanism. Do not remove the old public key yet.
6. Remove the IdentityFile line from your ~/.ssh/config
7. Check you can log in to all your systems. This will validate that your new key is working.
8. Remove your old public key from the authorized_keys file on each server you log in to.

Depending on your threat model you’re going to want to do this more or less often, and so you may want to consider automating it with sonething like ansible if it’ll be a regular job.

That’s certainly an option, but depending on how paranoid you are that still typically means that a compromised server can overwrite all of its backup images on the NAS, which could leave you in trouble. If you can configure your NAS to only allow creation of new backups but not allow changing old ones, you might be ok.

The big difference between pull and push is which system has keys to access the other, and what an attacker could do with them. With your home network you might ultimately decide this isn’t too important, but it’s worth at least thinking about anyway.

In a push setup, each machine has some way (likely an SSH key) to authenticate to the NAS and push backup files to it. Each server has a different key to access a different path on the NAS, so if a server is compromised the attacker only gets access to that part of the NAS data, and if the NAS gets compromised, the attacker can’t connect to anything but has access to the encrypted backups (you do encrypt the backups you care about, right?). This limits how much extra data the attacker can read, but has the downside you mentioned.

In a pull setup, the NAS has to have a way to connect to each server, typically as root for file access permissions. This means that if a server is compromised the attacker doesn’t gain a way to access even a limited portion of the NAS, but if the NAS is compromised they gain access to keys to root access on every server, which is likely catastrophic.

A compromise solution can work. Have each server back up to a local file, then give the NAS permission to retrieve only that file, rather than root access. Whilst rsync isn’t going to work for creating the single file backup, something like borg or restic would. This does mean you need more disk space on each server, but it also means that the server doesn’t need direct access to the NAS, and the NAS only needs unpriviledged access to each server, mitigating the risk of a compromise.

Most of us are polite enough not to call you that publicly, but we’re all thinking it really, really loudly.

Well, I’m no PugJesus, but I believe this is a reference to the ill fated Donner Party expedition of pioneers attempting to make the east to west journey to California. They became stranded in the Sierra Nevada region during the winter of 1846-47, and ended up resorting to eatting the bodies of the party members who’d perished in order to survive.

These are all very cute, but Junior really loves their stocking.

I wonder how many times we can get the money?

I very much doubt there would be a secobd time, or that you’d get to enjoy your split of the initial bounty. They’re trying to turn the population against each other, and already vanishing people. This isn’t rule of law stuff, this is “decades later their remain were found in an unmarked mass grave” stuff.

The best documents would be birth certificates for each generation, but there was a massive fire at the Dublin records office in 1922, which destroyed a lot of genological records from before then. If you have any information about where in Ireland your great grandparents were from, you may be able to find local records however. Things like parish registers and birth records for sone denominations were stored outside Dublin, so you may be able to find them, although it’ll probably mean going there, or hireing to go there, as most of those records haven’t been digitised.

Fire the start, didn’t we?

It’s Yoda admitting to arson.

This is an important point to remember. Before you go to sea, you should always curse your legs, that who or whatever has them will continuously dance until they drop from exhaustion.

It might backfire a bit, but look at the desperate expression on that whale’s face and tell me it’s not worth it.

I did notice your username, so I suspected this might not apply to you, but maybe it’ll be helpful to someone.

All I can really offer you is ‘good luck, hang in there and this too shall pass’, which is probably not a lot of comfort.

Not everyone will be able to move, it’s true, but a lot of countries have provisions for reclaiming citizenship if you can show that an ancestor (usually only in the last couple of generations, but not always) was a citizen.

For instance, Ireland: if one of your parents was an Irish citizen, born on the island of Ireland, you can claim citizenship and a passport with minimal paperwork. If your parents weren’t born there, but a grandparent was, there’s more paperwork involved, but you can still get citizenship and a passport.

Once you have a passport for an EU country, you have a lot more freedom to travel, and settle, anywhere in the EU.

Many other countries have similar systems, so, if you do want to leave, it can be worth studying your family tree to see if there are any recent immigrants.

In many way I think that would be preferable to the invasive data grab approach. At least you can remove the bracelet when you leave. Unfortunately, I suspect they’ll just do both.

Looking at a timeline of cases against various AI companies suggests that’s not quite the case. This page had a good overview, showing how cases are being resolved. Some of the recent notable outcomes involve the German courts finding OpenAI violated copyright laws, OpenAI being forced to reveal internal communications about trying to hide a massive dataset of pirated books, and a class action suceeding against Anthropic, but there’s a bunch more.