Hacker News Reader

Comment by ImTheMaddest | Hacker News Reader

Seems mostly reasonable to me.

“It was used for an old version of the Apple Watch app, specifically to run the heavy lifting of rendering maps on your phone & then send the rendering to the Watch app. This dependency was removed with previous improvements to Apple’s OS & our app. Therefore, we’re removing this API from our iOS codebase."

View on HN

The explanation is good, but that's a heck of a permission to allow. I hope Apple wisely took special precautions to make sure Uber wasn't using other functions that permission allows.

I don't see how this is reasonable. I can grant needing to do the rendering on the phone, and pushing to the watch, due to resources. But why does it need access to the screen? Is the phone not capable of rendering to a buffer in memory? (Or, because that just doesn't sound plausible & given the name of the permission in the article, can iOS not separately permission access to the screen & rendering to a buffer?)

I believe the API gave you control over the framebuffer (r/w), so theoretically it would have been possible for Uber to read and store buffer data to record your screen.

I don't know how custom the GPU on the Axx series SoC is, but it might be hooked to the screen in a very non-standard way.

I don't know, but still sounds a bit fishy to me. Rendering to a buffer and then turning that buffer into bytes is a standard feature of any graphical OS - and iOS can't do that without hogging the entire framebuffer and granting security-critical permissions?

Also, how was this supposed to work if the user wanted to switch to another app while keeping the map open on their watch? Doesn't this mean the phone would have force-mirrored the waych the entire time? This feels like a pretty unpolished and impractical UX.

Finally, if the entire point of the permission was to draw on the screen, why would it require access to the buffer while in the background? Or was the permission simply not fine-grained enough?

The API sounds really bad. But it could be limitations of the GPU underneath.

I guess the argument then is "technical limitations excuse privacy lapses."

Further to this, Apple auditing that Uber is not abusing this permission is pretty easy: they could reasonably have Apple engineers embedded in the team at Uber – something that would make sense for the scale, Uber is a US company, based in CA, so dealing with it in court would be possible and a fairly well-defined process, Apple could even have engineers trace the application properly during App Store review to check what it was doing at runtime, or put very stringent requirements on _how_ the entitlement was used at the code level to make it easier for them to enforce usage.

None of that scales to the millions of developers they have on their platform, but for such a key application, for essentially marketing purposes for the Apple Watch product launch, sure.

> Further to this, Apple auditing that Uber is not abusing this permission is pretty easy

Are we talking about the same company using Greyball to fool local authorities not just abroad, but also in the USA? Taking into account total lack of moral integrity in their top management, I would not believe in anything they promise.

> I would not believe in anything they promise.

This is exactly my point – there's very little trust needed because Apple can verify/audit one company far more than they can the millions of registered developers.

I'm not saying I agree with it, I'm saying I can understand why they did it, why it works, and that it's likely possible to do safely.

Reply on news.ycombinator.com