Ah, in that case I would definitely recommend taking a look at Tailscale!

If you use the .local syntax, and the device name stays the same, I think the domain name based fingerprint should prevent the "do you trust this fingerprint" problem.

If you want to avoid the question all together, you could set up an SSH certificate authority (quick guide here, less dense guides are available on the internet). By signing the servers' host keys, you can prevent the trust on first use prompt entirely, even for servers you may not have logged into before.

The value for the end user, the way Apple and Google do it, is that it works on every phone. It was always intended to be the next generation of MMS messaging. RCS, as designed, never had companies like Google run their own servers, but Google had to because many carriers never bothered to set up RCS in the first place.

Who benefits today? Everyone sharing chat groups with iMessage people. I avoid iMessage but millions of people are stuck with text messaging or ostracised for breaking group messaging (because SMS and MMS are terrible).

Furthermore, RCS isn't just text messaging. The standard also contains digital payments and video calls. It's an open (to carriers) alternative to iMessage that has features ready to go that Signal doesn't even implement yet.

Communication is literally what phone numbers are for.

Yes, because other federated protocols (email, XMPP, Matrix) don't have the same features modern messengers have and don't interoperate with other protocols well. I don't think XMPP OTR or OMEMO are RFC standards either, they're just extensions on top of XMPP.

Some XMPP people are part of the conversation and Matrix is already moving to adopting MLS, so clearly "just use x" wasn't an option, even for them.

Authy just leaked a list of phone numbers. No actual 2FA data was breached. Even if it were, attackers would need your backup encryption password to access any 2FA keys.

You may get more phishing texts, but that's about it.

That line makes me think AI text generation was involved (or the author didn't understand what Authy does).

It's still a good idea to switch on 2FA and switch to TOTP for services that still use SMS.

mDNS solves this. It may actually work out of the box. Try ssh'ing into your-device-name.local. If that fails, check your devices' names and if they have Avahi/Bonjour/mDNS enabled.

Something like Tailscale will set up a VPN with hostnames and IP addresses for you (and you can host your own entry server if you don't want to use the cloud stuff). That'll work across networks. It'll also add overhead and it's probably overkill for your use case, though.

As opposed to what? Encrypt them with a key that's stored elsewhere on the device? Without user prompting (which any malicious app could also do, of course) storing these keys encrypted is very hard. You could use whatever key chain API your platform provides, but that's just plain text passwords with extra steps. On Windows and Linux it wouldn't improve security in any way, on macOS it might also not (I don't know how Keychain access is done on macOS but I doubt it's impossible to get the key from there if you have local file execution).

Desktop applications aren't sandboxed, and the ones that are will only be protected against other sandboxed applications. I'm not sure if encrypting local message databases protects anyone in practice. It just adds half an hour of chatgpt aided programing to the job of the malware devs while the users lose access to their own data.

MLS is just the message encryption part, the MIMI working group is working on a standard that would also open up cross app messaging, using MLS for security. Of course, app developers would need to implement that first. Given the EU is forcing some of these companies to open up their services, it's possible app developers will choose MLS to do this (for EU citizens). Meta itself has several people in the MIMI working group, for instance.

[-] skullgiver@popplesburger.hilciferous.nl 7 points 18 hours ago* (last edited 18 hours ago)

RCS has been around since the early 2010s and absolutely nobody used it until Google did. You had to download carrier specific apps, which then only worked with other people who downloaded their carrier specific apps, because nobody bothered to write unofficial ones. Carriers have been shutting down their RCS servers for years because their customers didn't care. Google is the only reason anyone uses RCS, if it weren't for them we'd still be on SMS/MMS.

I take advantage of the free disk space savings and don't worry about disk space much. I'll clear out my download directory and maybe some caches when my disk usage grows beyond 80% (as reported in GUI tools). Running duperemove across my drive every now and then also tends to help a lot without deleting anything.

If I do run out of space, there are a few interactive terminal tools that'll point out the biggest files so I can delete them and save some space in a pinch. I practice, I just don't really think about it much.

Subtle, but perhaps too much so. Why not go for the more aggressive approach of slapping "TRIAL EXPIRED - GENERATED BY AN UNLICENSED COPY OF website.com" across all pages, images, invoices, and so on? A faded out website looks broken, a website indicating the owner's questionable business reliability much less so. Especially when it comes up in documents hitting other people's accountants!

view more: next ›

skullgiver

joined a long while ago