> Assuming your carrier bothers to run RCS, the protocol works just like MMS and SMS do. If your operator doesn't peer with other operators then you'll have the same issues getting any kind of multimedia delivered from phone to phone.
Except, SMS/MMS can be implemented by any standard IMS stack and it will function on any carrier (in theory, ignoring implementation bugs/incompatibility);
RCS has an explicit provision in the standard for "client authenticity" checks which in practice means App Attest/Play Integrity signatures.
Unfortunately, I think what a lot of people don't know is that RCS actually has "client authenticity verification"[1]... the RCS server has to actively approve any attempts for a client to connect, if it's Android/iOS/etc.
There are no standards for how this should be implemented, Google uses Play Integrity and Apple uses App Attest at the current moment, with explicit proprietary support by the Jibe servers.
It's basically impossible for any solution that Google doesn't approve to function, because it's never going to be able to get App Attest/Play Integrity verification without relying on a jailbreak/vulnerability.
As an aside, the IMS stack used to implement SMS/MMS/RCS on Android is super cursed. A lot of the heavy lifting is handed off to the OEM, for example, Pixel devices hand it off to the Qualcomm modem.
(Meaning Android the OS doesn't even have any control over how the raw SIP messages are sent: they're inside an IPSec tunnel set up by the modem that it can't see inside)
iirc Samsung devices do it differently and they implement it in userspace using StrongSwan?
That's why it's super annoying to handle SMS/MMS using the standard/legacy APIs, because depending on what device the user has, the implementation may behave radically differently with regards to PDU parsing and such.
RCS makes the whole situation worse because it sets up an entire secondary IMS stack inside the Google Messages app, and then uses weird APIs to try to tie it back into the main stack, even though obviously the modem implementation doesn't understand RCS... it's a mess.
> Pixel devices hand it off to the Qualcomm modem.
Older ones maybe, newer ones use Samsung Shannon modems.
> iirc Samsung devices do it differently and they implement it in userspace using StrongSwan?
Just to be cursed the entire IMS stack for Samsung on both qcom and exynos is custom. It’s why no custom roms have support for voLTE on their devices. They also had their own RCS that they sunset in favor of Google Messages.
Apple’s implementation is cursed too and not only did they use an older specification but they didn’t fully implement required responses to registration issues, I wrote about it here: https://wt.gd/working-rcs-messaging
Yeah, definitely not at all a fan of stealth editing.
I suspected LLM rewriting or generation but I don't possess enough knowledge into how the Apple pre-boot environment works to make an accurate judgement on the accuracy of the post. But I definitely had very strong suspicions of LLM influence with all the bullet lists and hem-hawing the post does; I would expect that someone who successfully reverse engineered the boot chain this thoroughly wouldn't need to hedge anything but Apple's rationale on why they did things. But maybe I'm too overly focused on details.
That's exactly how LLMs are so effective: the text looks impressive to people who don't possess enough knowledge to make an accurate judgement. Meanwhile actual researchers with Apple experience found clear errors on a quick skim.
The large amount of rewriting being done within 5 minutes is another sign of LLM...
I'm pretty sure this is just incorrect. According to the linked report[1], they tested it for compatibility with OpenDrop, so I think they simply implemented AWDL.
That might also explain the limited Pixel 10 rollout, if it required a specific WiFi chipset/firmware.
> Close-range wireless file transfers: this feature allows to access the same iOS-controlled features as Apple’s services in third-party file sharing apps, creating, for example, alternatives to AirDrop.
> Under pressure from the EU’s Digital Markets Act (DMA), Apple is being forced to ditch its proprietary peer-to-peer Wi-Fi protocol – Apple Wireless Direct Link (AWDL) – in favor of the industry-standard Wi-Fi Aware, also known as Neighbor Awareness Networking (NAN). A quietly published EU interoperability roadmap mandates Apple support Wi-Fi Aware 4.0 in iOS 19 and v5.0,1 thereafter, essentially forcing AWDL into retirement. This post investigates how we got here (from Wi-Fi Direct to AWDL to Wi-Fi Aware), what makes Wi-Fi Aware technically superior, and why this shift unlocks true cross-platform peer-to-peer connectivity for developers.
That's what was confusing to me. It's one thing for Apple to add wifi aware by force, it would be another for them to completely reimplement Airdrop with it. I don't think they were required to do that.
They weren't specifically required to drop AWDL, they were just required to implement WiFi-Aware in such a manner that neither technology had an advantage.
In theory Apple could've maintained both, but that seems like a waste of development time to me.
I doubt they would've had to implement any specific protocol if they had just opened up AWDL, but I suppose they'd rather keep that closed to maintain the ability to guard their walled garden in non-EU devices.
> In theory Apple could've maintained both, but that seems like a waste of development time to me.
They need Airdrop to work with phones who haven’t upgraded, so doesn’t feel like a waste to me. And they already have working AWDL code, so it’s just maintenance, probably not a ton of work.
Mach has always been a very interesting project. It doesn't surprise me at all to see that they have this already, but at the same time I was not aware of it so thank you. This also more or less proves that that may well be an avenue worth pursuing.
I learned of the idea from some paper or other of Barrelfish, which is a research OS based on seL4. Barrelfish is underrated! Aside from its takes on a kernel architecture, it also has interesting nuggets on other aspects of OS design, such as using declarative techniques for device management.
I know some projects like Koreader[1] use Lua as their primary application language. If you could convince one of them to switch, it would provide some assurances about the maturity and popularity of the idea.
That's a neat suggestion, thanks.
Lux will need some time to become mature, but building a large multi-platform project like koreader would definitely be a nice goal.
Yeah, uh... you might do well to assume that they can. The Find My Friends API is really really simple, I have a script somewhere that can pull the locations of everyone who has shared their locations with me and record it.
To clarify some points, though I'm sure all will become clear when this releases:
+ This is NOT hardware attestation. It's simply using a combination of things such as serial number and other device identifiers to prove to Apple you own the device
+ Because it is not hardware attestation, in the future this process might be improved, if someone reverses/emulates the (purely software) algorithm "proving" you have that device. Then it would only be a matter of asking the user to input a serial number, once.
+ Hardware attestation is implemented in the protocol. However, the 2019 iMac does not have a T2, so this cannot be enforced for a while yet.
+ Beeper Mini still implements the rest of the iMessage stack on-device
…I wonder if this could be used to implement AWDL (Apple Wireless Direct Link) for use with AirDrop… if I recall correctly, the blocker on normal WiFi chipsets is being unable to send the ACK frames, which this should enable?
Except, SMS/MMS can be implemented by any standard IMS stack and it will function on any carrier (in theory, ignoring implementation bugs/incompatibility);
RCS has an explicit provision in the standard for "client authenticity" checks which in practice means App Attest/Play Integrity signatures.
(see also: my comment above)
reply