This doesn’t affect valve at all though. It’s borrowing their tech that they’ve made open source, and figuring out how to use it elsewhere outside of steam.

Actually, it’ll benefit them. More eyes are on proton and any fix will benefit everyone, including games played via steam.

Thanks,

So they haven’t made an announcement about retiring the proton bridge app yet.

I think I’ll wait until I see them actually remove it before I believe they’re locking us in.

I’ve just skimmed through the proton blog briefly and I couldn’t see anything referencing this. Do you have a link by chance?

That’s a bold claim. Got a source for this move?

WatchOS 10.2 is also needed for enabling Contact Key Verification in iOS 17.2.

You need to enable CKV yourself it seems.

Settings -> Apple ID -> scroll right down to the bottom -> contact key verification.

I think the phrasing is important here.

Later next year, we will be adding support for RCS Universal Profile, the standard as currently published by the GSM Association.

If Google’s & Samsungs implementations aren’t compliant with the GSM associations’ standard then I don’t think this is going to work how people are expecting it to. The stuff Google has added to RCS messaging has all been their own implementation of it and not part of the standard, and as far as I’m aware android RCS gets routed through Google’s servers.

I wonder if RCS support is Apple trying to appease the EU with the DMA stuff forcing messaging apps to be interoperable with each other.

No, I don’t think I will

I’ll trust what the cyber security and privacy experts say.

Facebook might know who you’re messaging but that’s also true for Signal.

Signal’s sealed sender does a good job at knowing you’re sending a message, but not who to. All it’ll know on the receiving end is that a message was sent to it.

Of course people have found other methods of identifying this but sealed sender does cover most of the low hanging fruit.

Signal does also purposefully attempt to find ways to not collect any metadata, whilst also making it more difficult for anyone attacking to the servers to find anything. (e.g. ORAM for Secure Enclave operations)

My understanding is that meta used E2EE on your messages themselves, but everything else is up for grabs.

You can run Mac apps on Linux?

Cat? I’m a kitty cat. And I dance dance dance and I dance dance dance. 🎶

Imagine if Linux was supported by all the big names such as Adobe and Microsoft. Heck, those companies tend to (or at least for a good decent while used to) release all of their brand spanking new features first on macOS before bringing them to windows.

Well, less customisation compared to Linux, but if you’re happy with the UI layout then this is essentially what you’re getting.

The one thing that feels off to me about Google’s implementation is that it’s not vendor agnostic and all comms would need to go through Google’s servers to work. The E2EE bit is an entirely Google specific extension to RCS, for example. The last thing we need is another chromium situation in a different area.

If it wasn’t a Google specific extension, phone networks around the world would need to pick up the pace and adopt RCS, but also they’d need to keep up to date with the latest version of the standard to ensure the functionality is supported. Now, looking at phone networks’ previous track record, they’re really not going to implement it unless they’re forced to and they’ll do so at a real snails pace.

At this point I’d agree that Apple not adopting RCS is really not helpful here.

I feel the EU’s Digital Market Act that’s forcing messenger applications to be interoperable with each other is going to be a much more viable option towards that perfect world scenario. The IETF is even fleshing out a common protocol for it, MIMI with MLS.