r00ty

Well, I did think the “security through obscurity” line would come up. But that’s really something that should be reserved for people making their own “triple XOR” crypto implementations closed source and hoping that protects them.

The “obscurity” if it’s the term we want to use here in my use case isn’t hiding using closed source to provide a perception of security. It’s just giving a choice of crypto, but not adding to the protocol with negotiation.

My thinking is this, and we’ll look at say ssh. We can choose between multiple key types and lengths for that. Now let’s say for example ed25519 is compromised (in real terms I think the only likely compromise for any of the ssh key based auth options would be deriving a private key from the public key, so the “scanning” I talk about is a fantasy. But I’m going with it!). For ssh, there will for sure be bots hunting the internet for vulnerable ssh servers very soon after. Automating the process of getting in, installing whatever nefarious tools they want and moving on. But, crucially they will only get those that have used ed25519 for their auth key login. However they might well get every single wireguard vpn.

I’m really just advocating for the same option really. The option to not use the same as everyone else. With no reduction in security for anyone else and no need to negotiate, the onus would entirely be on the operator to ensure the same stack is configured on client and server. Of course with the understanding that using any other stack is at your own risk. E.g. “triple XOR” security might not be the best, for example :P

Oh and as I said, I doubt I would use it. I use wireguard as it is, I like wireguard as it is. But, I feel like having options is not a bad thing, provided the default is the “best” option currently known.

Well the posts to inbox are generally for incoming info. Yes, there’s endpoints for fetching objects. But, they don’t work for indexing, at least not on mbin/kbin. If you have a link, you can use activitypub to traverse upwards from that object to the root post. But you cannot iterate down to child comments from any point.

The purpose is that say I receive an “event” from your instance. You click like on a post I don’t have on my instance. Then the like event has a link to the object for that on activitypub. If I fetch that object it will have a link to the comment, if I fetch the comment it will have the comment it was in reply to, or the post. It’s not intended to be used to backfill.

So they do it the old fashioned way, traversing the human side links. Which is essentially what I lock down with the managed challenge. And this is all on the free tier too.

It’s the usual enshittification tactic. Make AI cheap so companies fire tech workers. Keep it cheap long enough that we all have established careers as McDonald’s branch managers, then whack up the prices once they’re locked in.

For mbin I managed to kill the attack of the scrapers only using cloudflare managed challenge for all except to fediverse post endpoints, from fediverse ua agents on certain get endpoints. Managed challenge on everything else.

So far, they’ve not gotten past it. But, a matter of time.

While I don’t doubt that’s part of the reason. I would assume ensuring only the microsoft key was used to create a trusted boot path to a clean windows install. At which point during the boot process these invasive anti-cheat engines take over and are then watching everything loading makes it a bit harder to cheat.

But I think there’s a lot of hardware options available that could still remain invisible here. Maybe it makes software options close to impossible though. Not too sure, there’s always inventive workarounds people come up with.

I always find it amusing the lengths people will go to, to cheat… Just short of, learning to play the game better.

Yep. I entirely agree about the good points. I am just always weary about removing options like this, regardless of intention.

I’d be fine if for example I’m running my own wireguard implementation, I could choose the suite to use, not negotiate anything and ensure my client has the same configuration.

I’d probably not use it, but I like the option, and knowing that anyone that wants to try to break this now also needs to guess what options I’m running.

I only have one problem with this. When they say wireguard being crypto opinionated is a good thing. I am weary to agree with that statement entirely.

While it is good for stability (only one stack to support and get right, and to be secure and efficient) I do wonder about overall and future security. Saying “You must use this specific cipher suite because we think it’s the best” is a bit of a dangerous road to take.

I say this just because Curve 25519 is considered a very secure elliptic curve, to the best of my very limited knowledge on this subject. But we had a certain dual elliptic curve pseudo random number generator was pushed as “best practice” (NIST backed) some time ago, which didn’t turn out so well, even omitting possible conspiracy scenarios, it had known weaknesses even before it was recommended. [1]

Since then I’ve generally not been a huge fan of being given one option as “the right way” when it comes to cryptography. Even if it is the “best” it gives one target to try to find a weakness in, rather than many.

I say all this as a wireguard user, it’s a great, fast and reliable VPN. I just have concerns when the choice of using other algorithms and especially putting my own chosen chain together is taken away. Because it puts the exact same target to break on every one of us, rather than having to work out how to break multiple methods and algorithms and multiple combinations.

[1] https://en.wikipedia.org/wiki/Dual_EC_DRBG

I think it’s a real shame because all three of those things you mention are useful. The problem is that once they become a buzzword, then everything needs to be done using that buzzword.

Cloud has been misused to hell and back, and I have no doubt AI will too.

I usually ignore these kind of trends. Just meet any required deadlines etc but don’t engage too much. The vast majority will just disappear.

Specifically as a software developer I cannot see a good outcome from engaging with this trend either. It’s going to go one of two ways.

1: It pans out sooner rather than later that AI wasn’t the panacea they thought it was, and it either is forgotten about, or becomes a set of realized tools we use, but don’t rely on.

2: They believe it can replace us all, and so they replace us all with freshly graduated vibe “programmers” and I don’t have a job anyway.

I don’t really see an upside to engaging with this in any kind of long term plan.

A lot of the large(ish) corporates are moving in this direction, including where I work. It’s not unusual, I always liken large organizations to insects, just following where the others are going, and what they are doing. They don’t really ever put much thought into their actions.

This is analogous to the “I’m using paper straws while the billionaires take a private jet each to Venice” situation.

So I should delete old mails so that maybe (and actually no, it won’t) there will be less drives to cool in the datacentre while the techbros have entire datacentres using hundreds of terawatts of power[1] and is predicted to be using billions of cubic metres of water per year by 2027[2].

As usual, they’re looking toward the people they can influence to make changes to their lifestyle, and ignoring the people actually doing the damage because they know they will not change.

[1] https://www.iea.org/reports/electricity-2024: IEA annual report showing that AI and crypto is estimated to have consumed 465tw/h of energy in 2024. [2] https://www.forbes.com/sites/cindygordon/2024/02/25/ai-is-accelerating-the-loss-of-our-scarcest-natural-resource-water: Forbes report stating that AI datacentres are estimated to use around 6.6 billion cubic metres of water by the year 2027.