[threeseed]

> supporting interoperability for these protocols is a burden

Also an unprecedented and unacceptable privacy and security risk.

You would be allowing third parties the ability to continuously record your iPhone's screen. Which includes websites you browse, apps you open, health information, text messages etc.

And the Mac is so much open that you could do this, have a local model to transcribe it and ship it to a remote server without the user noticing.

There isn't a government or advertising company on this planet that wouldn't want to get at this information.

[amluto]

> Also an unprecedented and unacceptable privacy and security risk.

> You would be allowing third parties the ability to continuously record your iPhone's screen. Which includes websites you browse, apps you open, health information, text messages etc.

> And the Mac is so much open that you could do this, have a local model to transcribe it and ship it to a remote server without the user noticing.

MacOS is not secure in the way you would like to think it's secure. This is already risk. And Apple really could do this right: make screen mirroring use the DRM playback paths, and open up the API to trigger it to competitors (who would get precisely the same DRM-playback-pathed result of a screen mirror showing up in a window from which they cannot read). I don't really know why a competitor would want to compete here, but they could.

[threeseed]

Most people interact with apps like Health on their phone not their Mac.

And there are also many third party apps that never made Mac versions.

So the amount of data we are talking about exposing is significantly higher.

And the issue is that the DMA is ambiguous about what competition and interoperability specifically means and so it would just take one company to complain about your solution for Apple to be fined 10% of global revenue.

[Nextgrid]

Many people log into their Mac using the same credentials (Apple ID) that give access to the Health data, and in fact Apple makes it really hard or even impossible to use it without (you can't selectively grant access, you need to use a separate Apple ID but then you lose some useful features such as universal clipboard, etc).

This is again a misinformed take. Your Mac can already get all your iPhone's data from the cloud where it is synced without viable opt-out or compartmentalization.

[threeseed]

> Your Mac can already get all your iPhone's data from the cloud

Only if the data is available in iCloud and it is stored in files and it is not encrypted.

Otherwise data from apps like Instagram will be exposed exclusively via screen sharing.

[Nextgrid]

> Only if the data is available in iCloud and it is stored in files and it is not encrypted.

Health data is available in there, just to go after your example. iPhone backups are also available in there.

At no point am I being asked anything else beyond my Apple ID, password, and two-step approval on another device (such as the Mac) to set up a new iPhone and download all my data.

Thus the outcome is that the Mac indeed has everything it needs to get access to all your iCloud data. In fact, reverse-engineering how to get it directly is unnecessary work - instead, just reverse-engineer enough to capture the Apple ID password (or prompt to it - given there's still no way for the user to tell a real system dialog from one drawn by malware) and approve the 2FA prompt, get an actual, real iPhone and sign into the person's account and then extract all the data from there (via screenshots if necessary).

[amluto]

There’s a universe in which your Mac is a locked down device like your iPhone, with a proper immutable filesystem, carefully controlled persistent state, and a strong sandbox in which the terminal, Homebrew, and apps (App Store and otherwise) can act within the sandbox but cannot do things like, say, reading your entire iMessage database.

We do not live in this universe. Consider getting a Chromebook instead if you want to be in that universe. (But then you have a tradeoff: Apple itself seems pretty good about not using your data inappropriately. Google, not so much.)

[the_mitsuhiko]

> Also an unprecedented and unacceptable privacy and security risk.

Put a prompt up that asks for permission? Failing to understand why we're drawing the line on the screen.

[seszett]

If it's so sensitive and dangerous, how do you explain that scrcpy has been available for years under Android?

Are governments recording the screens of Android users?

[elzbardico]

Assume it is trivial for the government to do so if they want.

[wpm]

>You would be allowing third parties the ability to continuously record your iPhone's screen

Apple is first-party to the device, but third-party to me, the user. Why are they more trustworthy than a free open-source tool? Who the hell are they to tell me who I can and cannot trust?

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