[Nextgrid]

It is sad to see such a misinformed take on a technical forum. You can already do everything you want. It will take some reverse-engineering work, but it's possible.

Similar things were said about iMessage interoperability with Android, until Beeper proved them wrong. They managed to reverse-engineer it, build a compatible client and clearly proved Apple's claims were BS (and no, this didn't lead to a mass-scale compromise of iMessage, contradicting fanboys' claims).

If the feature allows to pull up the iPhone's screen without any user consent, then it is vulnerable to begin with - the reverse-engineering requirement would become an insignificant hurdle compared to the value of such a vulnerability. Presumably however, there will be a consent step, either on the spot or prior (maybe it can reuse the cryptographic pairing mechanism that happens when the phone asks you to "trust this computer?" the first time), and no third-party (whether using an approved API or reverse-engineered) would be able to bypass it without the user intentionally consenting.

[threeseed]

> the reverse-engineering requirement would become an insignificant hurdle compared to the value of such a vulnerability

The idea that breaking device attestation that is secured through Secure Enclave hardware i.e. not accessible from user code is an insignificant hurdle is hilariously ridiculous. It is borderline impossible for any ordinary developer.

And people that bring up the "just ask the user" argument clearly don't remember how poorly that has worked in the past e.g. Microsoft Vista. Users will blindly approve any dialog which is why Apple has been so careful to limit them to targeted actions which a "do you approve this app to record everything on your iPhone" is not.

[Nextgrid]

You're approaching this from the idea that the impenetrability by third-parties is the primary security feature.

If this is true, then my worry isn't even about malicious attackers, it's my neighbor (with a real Mac) being able to (accidentally!) eavesdrop on my phone screen (since according to you this is the primary security measure).

It's obviously ridiculous, and the primary security measure is that there must be a prior key exchange and consent step. If that part is secure, then it would be secure against a third-party.

If that part is not secure, then no Secure Enclave-ing will help you, because worst case scenario, the attacker can just use a real Mac as part of his attack to pass the secure-enclave-protected authentication step, or just exploit the good old "analog hole" by using the real Mac as the main attack vector (and then just capture its HDMI output and feed in inputs via a USB-capable microcontroller simulating a keyboard).

[latexr]

> It is sad to see such a misinformed take on a technical forum.

If you’re going to make such a claim, you should be very careful to ensure you’re not misinformed yourself.

> Similar things were said about iMessage interoperability with Android, until Beeper proved them wrong.

No, they did not. We already knew Apple not allowing iMessage on Android was a lock-in choice. The trial with Epic brought that unambiguously to light, years before the release of Beeper Mini¹.

https://www.theverge.com/2021/4/9/22375128/apple-imessage-an...

https://www.theverge.com/2021/4/27/22406303/imessage-android...

> They managed to reverse-engineer it, build a compatible client and clearly proved Apple's claims were BS

What claims? The only time I remember Apple publicly addressing iMessage on Android was after cutting off Beeper Mini’s access.

¹ Which is an important distinction from the earlier Beeper, which used trickery with iPhones to accomplish the task.