🚒 iPhone vs Android 🚒
Round 394!
ok but in all seriousness, let’s say I want to send some SMS/RCS using my cell, but I want to do that from the computer… should be feasible?
iPhone’s iMessage: “we love our walled garden so much that NO ONE can send messages using a web interface, despite iMessage being an iCloud enabled app and the ecosystem having iCloud apps available online to any non-Mac – but we decided that iMessage alone should never be usable on the iCloud web interface (because reasons?)”
Android via Messages App: “sure thing fellow Happy Camper! here you go! https://messages.google.com and it’s just as secure as using the device itself.”
Best part… Android’s method WORKS ON FREEBSD!
#noFlameWarNeeded #iPhone #Android #mobileDevices #FreeBSD #Linux #Apple
@[email protected] If you can view your iMessage messages on the web it means that Apple has your encryption keys. That would entirely defeat end to end encryption. And when a government agency comes to Apple to get a copy of your messages, they would have to surrender them, something they cannot do today.
@[email protected] No, that’s not correct. It seems you have gotten some misinformation. See the following for a recent implementation:
https://tjthinakaran.blog/wp-content/uploads/2024/04/Beeper-attachment-3-28-24.pdf
@shac @winterschon A convenience bonus for Google and perhaps a reason to dislike iOS. How does WhatsApp web manage to maintain e2e encryption, then?
Webapps generally rely on TLS for data in transit, but full E2EE requires data at rest encryption as well
Since whatsapp is not a part of the hardware storage at the block level it has no control over anything other than the data it presents to the OS – which may or may not be encrypted separately.
I don’t use whatsapp so I’ve not looked into that side of its implementation, but here’s the NCC audit if that seems appealing to review: https://www.nccgroup.com/media/phzpm0qv/_ncc_group_metaplatforms_e008327_report_2023-11-14_v10.pdf
@[email protected] @[email protected] Thank you for this! I’m starting to understand.
@[email protected] too bad that RCS isn’t currently (reliably) working for me on GrapheneOS 😔
@[email protected] keep in mind, that it isn’t always e2e encrypted on Android (not for SMS and for RCS it depends on the used mobile ISPs gateway implementation (if not jibe) and on the remote devices. So, depends of this is really a pro instead of cons on the point of view.
@[email protected] for sure, and that is a present concern for RCS protocol, which is sorta lenient from the carrier perspective. it comes as only a minor surprise that they (cell phone / teleco) wouldn’t want to get into the encrypted traffic side of the engineering – otherwise:
- they would likely argue for a backdoor
- they would likely wedge deep packet inspection provisions
- they never want to do anything for free
- they would bicker amongst themselves and turn it into vaporware
telco cannot be trusted for end-user security, so the implementation of RCS (as you mentioned) really matters quite a lot. My primary annoyance with iOS in this regard is that they’ve refused to implement AES or TLS or anything else on top of their RCS stack, but at least in this scenario it’s usable from a browser regardless.
@[email protected] One reason for “Telcos cannot be trusted” is being forced to assist lawful interceptions. And back in the days where SMS has been frequently been used on the SS7 protocol via UCP and SMPP, every hop could read everything in plaintext (still today). However, e2ee with vendor pre-generated keys (e.g. IMessage) isn’t really better - you can never be sure that not somehow an additional key for encryption got created. People may now say use opensource and right, this might be better…
