jjtech
Joined 2 years ago
Joined 2 years ago
With the App Sandbox, sandbox extensions are issues whenever you open a file using the file picker. They only last until the app is restarted.
A caveat is that you can save "Security Scoped bookmarks" (basically a signed base64 blob [1]) and pass that around to preserve access, but that isn't very common.
[1] https://www.mothersruin.com/software/Archaeology/reverse/boo...
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)
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.
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.
1. https://www.gsma.com/solutions-and-impact/technologies/netwo...
New strategy discovered: Ask LLM to write article, nerdsnipe HN into correcting it, feed corrections back into LLM until people stop complaining
That might also explain the limited Pixel 10 rollout, if it required a specific WiFi chipset/firmware.
[1] https://www.netspi.com/wp-content/uploads/2025/11/google-fea...
So it is entirely plausible that they banned the device, I guess. (Or they could have banned the IMEI, as mentioned)
(this is used under-the-hood on macOS: NSXPCConnection -> libxpc -> MIG -> mach messages)
(I'm also the one who wrote the original code that was refactored a couple times until it became this project... https://github.com/JJTech0130/pypush/blob/async/examples/ope...)
+ 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
On the other hand, I'm not sure if this is a typo on Apple's part, but it certainly is weird: you must use "WindowSerial" here[1], not "WindowsSerial" with the extra s
[1] https://github.com/JJTech0130/pypush/blob/8b33c0ee5d540d8ac7...
There is a newer version of the iMessage encryption (sometimes called "pair-ec") which uses ECIES. Beeper implements it, I never got around to backporting it to pypush proper.
Also, the new Contact Key Verification (I believe it is the same thing as "key transparency" internally) should prevent the man-in-the-middle.
A lot of the things you mentioned can actually be solved on the pypush side: there's nothing preventing pypush from alerting you when a new key is inserted, or providing you with the fingerprints of each of the keys.
I'm not an expert on these things, but I do think it is time that another analysis by a proper cryptographer was done: the one you linked was from 2015, and a lot has changed since then.
Anyway, the point of iMessage is convenience, if we're being honest here. It provides a reasonable level of security that will keep out all but the most entrenched and determined attackers, and that's really all most people care about.