jjtech

Note that this isn't "Mac's sandbox system", it's TCC. That's an important distinction to make, because apps that have opted into the proper App Sandbox can't do this... they don't even have the ability to display a prompt for direct access to Documents/.

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...

> 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.

(see also: my comment above)

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.

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.

1. https://www.gsma.com/solutions-and-impact/technologies/netwo...

All of these errors have now been stealth-corrected.

New strategy discovered: Ask LLM to write article, nerdsnipe HN into correcting it, feed corrections back into LLM until people stop complaining

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.

[1] https://www.netspi.com/wp-content/uploads/2025/11/google-fea...

Jibe actually will ask iOS for App Attest attestation (this is actually spec, unfortunately: see section 2.11 Client Authenticity in RCC.14)

So it is entirely plausible that they banned the device, I guess. (Or they could have banned the IMEI, as mentioned)

This is sort of what Mach does with "out-of-line" messages: https://web.mit.edu/darwin/src/modules/xnu/osfmk/man/mach_ms... https://dmcyk.xyz/post/xnu_ipc_iii_ool_data/

(this is used under-the-hood on macOS: NSXPCConnection -> libxpc -> MIG -> mach messages)

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.

[1]: https://github.com/koreader/koreader

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.

(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...)

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?

Unfortunately, there are many typos in my code :P

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...

I was thinking of finding a way to extract it directly from old Mac OS X updates downloaded directly from Apple... anyway, Beeper's app doesn't use it, that's purely a hack I came up with to make the proof-of-concept easier to use.

While I will definitely agree that Signal is more secure:

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.