[HN Gopher] iPad Camera Multitasking
___________________________________________________________________
iPad Camera Multitasking
Author : arkadiyt
Score : 268 points
Date : 2021-05-08 04:16 UTC (18 hours ago)
(HTM) web link (blog.thinktapwork.com)
(TXT) w3m dump (blog.thinktapwork.com)
| bredren wrote:
| I'm used to giving the benefit of the doubt to Apple, but this
| one needs to be explained.
|
| Is this fodder for new discovery in the Epic lawsuit?
|
| Due to the nature of that case, can Apple be compelled to provide
| information on this and all other non-public entitlements along
| with and who they are granted to and why?
|
| Is it reasonable to presume that Zoom was under an NDA on this,
| and it was an employee mistake bringing it up by name?
| viktorcode wrote:
| It isn't. Apple can use private APIs and entitlements, while
| other apps can't. Those private APIs eventually become public
| or get replaced with something else entirely. So, this
| advantage is always temporary and can easily be explained by
| security or privacy.
| scarface74 wrote:
| Seeing that Epic admitted they _also_ got early access to APIs
| and beta features to test the Unreal engine, they can't
| actually argue the point.
|
| It also came out in testimony that Epic asked for special deals
| with Apple.
| mrtksn wrote:
| This doesn't bother me at all. Wouldn't it mean that if you talk
| to Apple about something you need they might actually give it to
| you?
|
| I suspect that people imagine Zoom getting a privilege due to
| their inartistic value but I don't think that this is the case. I
| think that it's just a business and there's no reason why you
| can't have it with Apple too.
|
| I imagine, engineers in Zoom needed this to accomplish something
| and they told the management. The management contacted Apple
| management and explained them how this could work well both for
| Apple and Zoom and promised not doing nasty stuff. Apple trusted
| Zoom enough to open or implement that feature for them. Maybe
| Apple have seen the the need of this API, developed it and
| contacted Zoom to give it a try.
|
| Why wouldn't they open it for everybody? Probably edge cases that
| can be worked out on 1:1 partnership but need good design when
| open to everyone.
|
| It's just business. What would have annoyed me though is if a
| competitor like Skype request access in similer terms but got
| denied.
|
| For some reason, the narrative on HN and similar tech heavy
| forums require us to pretend that business relationships don't
| exist or that business relationships are dirty elitist entities
| that you can't have. A lot of people can be surprised how much
| you can have by just asking to have it or proposing something
| that can work for everyone. Maybe that's the dirty secret of the
| non-technicals :)
| jefftk wrote:
| Would you feel the same way if a web browser added a feature
| that could only be used by a specific partner?
| easrng wrote:
| Like window.chrome.webstorePrivate? It exists, but only on
| https://chrome.google.com/webstore/ pages.
| mrtksn wrote:
| Good question. I had to think about it and I can't get more
| definitive beyond "it depends".
|
| In many ways, it's already the case. Browsers are already
| possible through partnerships with companies that manage
| certificates, DNS and so on. They also have special APIs that
| are open only to the vendor. You can't spin off your
| authoritative DNS or certificate authority or malicious site
| detection and have it made accepted by Firefox/Chrome or
| others.
|
| On the other hand, we have an understanding about what web is
| and expectations about the web standards which makes me to
| expect neutrality. It's the tool that promises me to parse
| whatever HTML I throw at it and execute any JS.
|
| Then we have things like Brave browser that has API that's
| not of any standards.
|
| So, I don't know. It depend. I will know it when I see it.
| gregoriol wrote:
| It would be business if there was a way to know this thing
| exists and to contact them and request it; otherwise it's a
| hidden secret between them and that partner, which is a
| disadvantage to all other developers paying 99$ every year to
| have access to it.
| mrtksn wrote:
| Anyone acan do any business deal with anybody and not
| disclose it as long as it complies with the government
| regulations. Companies rarely disclose their dealings with
| other companies, trade secrets are often the most guarded
| secrets out there and its completely legal.
| scarface74 wrote:
| Marco Arment - a one man development shop, albeit well known,
| was able to work with the iOS team to get better audio
| support for the Apple Watch. It's not just big developers.
|
| Have you noticed that when every big tech company announces a
| new product they already have testimonials about how well the
| product works?
| bellyfullofbac wrote:
| I won't speak for anyone else, but my problem is more that I
| need to ask permission to tinker with hardware that I own. We
| can't even deploy apps on the device without having an Apple
| ID...
| risyachka wrote:
| Why do you have a problem with asking permission? You always
| have to ask for it unless something yours and you own 100%
| intellectual rights for it.
|
| And this is the case not only with Apple, but with 99% of all
| devices out there. Developers get access only to what
| manufacturer gives them right to, and this is how it should
| be.
|
| If you make some device no one should force you to open it up
| or give everyone access to it. This is your own product, you
| should be able to control who access what, otherwise it is
| not yours by definition.
| mrtksn wrote:
| You don't need to ask for permission to do anything on your
| own device. What you need permission is, to use Apple's tools
| that makes it orders of magnitude easier to do it.
|
| Just remember, the first iPhone did not have an AppStore or
| SDK. People made apps for it anyway.
|
| People also often confuse the right for access to Apple's app
| distribution services with the right to run apps on their own
| device. In reality, you can have a torrent client or anything
| you want on your phone without asking Apple for permission.
| That doesn't mean that it's going to be as easy as installing
| it from AppStore though. You will need to thinker harder.
| bellyfullofbac wrote:
| OK, fine, they're gatekeeping not their hardware, but their
| dev tools. Kinda sad that you're fine with that...
| mrtksn wrote:
| Why wouldn't anybody be fine with that? Of course it
| would have been amazing if they let us do more with their
| tools but I simply don't see how they are obligated to do
| it.
|
| I also like how Apple is the opinionated elitists design
| house. As long as they are not the dominant force in this
| space, I'm fine with them doing things their way.
|
| I see some people argue that Apple is dominant and
| everything changes when Apple does something but that's
| simply because Apple is really great at designing it.
| There are also many thing that Apple does and then
| doesn't stick. It's the stuff that they simply fail to
| design well.
|
| It's good to have someone around that doesn't race to the
| bottom and have opinions on how things should be made.
| vbsteven wrote:
| This is what bothers me most about Apple devices and software.
| They probably have the "best" devices out there in terms of user
| experience. I use an iPhone and iPad every day because of it. But
| they keep very tight control over what software can be installed
| and run on it in order to safeguard their views on UX and
| security/privacy.
|
| This means for me as a developer that it's hard to write software
| and tools for my own devices without having to deal with Apple in
| some way or root the devices. Some things are even clearly
| impossible because of these private entitlements: There is no way
| for me to explore the CarPlay API's to experiment with my own
| ideas.
|
| A small part of me hopes that the Epic lawsuit and recent
| developments can lead to more abilities for sideloading on
| iDevices.
| kgc wrote:
| If it's your own hardware and app, what's wrong with just
| sideloading it using a dev cert?
| agsnu wrote:
| Dev certs won't give you access to private entitlements
| bydo wrote:
| I'm not an iOS dev, so correct me if I'm wrong, but aren't
| these specifically App Store entitlements? So if you try to
| submit an app using an API covered by one without having
| been granted permission to it, that request will fail, but
| if you're just building and running on your own hardware
| you can use any private API you feel like?
| LeoNatan25 wrote:
| Not the way it works. On non-jailbroken iOS, entitlements
| are enforced at the kernel level. If your app is signed
| with an entitlement that isn't listed in the provisioning
| profile (which only Apple can generate with its private
| key), the system rejects the binary. It's the same on
| Mac, but you can disable amfi to get rid of that shit,
| which used to also be possible on jailbroken iOS.
| bydo wrote:
| Huh. Thanks; I stand corrected. The last time I messed
| with iOS development was years ago, and you could sign
| and deploy whatever you wanted locally. I forget if it
| required a developer account then, but definitely not a
| paid one.
| viktorcode wrote:
| You can use CarPlay simulator for development without being
| enrolled into the program.
| mcot2 wrote:
| We have over a decade of data and experiences with this
| Sandboxed approach. The fact that you still use an iPhone/iPad
| over Android means you are tacitly agreeing with the approach.
| asiachick wrote:
| No it doesn't. Example: Someone votes democrat because they
| want to support public schools doesn't mean they support
| every democrat policy.
|
| Similarly, I can choose iPhone over Android for many reason,
| that doesn't mean I suddenly agree with every feature/limit
| of iOS
| isatty wrote:
| The tight control over what the software can do is a big part
| of what makes apple devices have such a good user experience.
| Even as a power user/SWE/tinkerer I hope that does not change
| because I want my daily driver devices to be as reliable and
| zero config as they can be.
|
| Sideloading/rooting an idevice as long as it can't do Apple
| Pay/bypass find my iPhone is fine of course.
| kennywinker wrote:
| > The tight control over what the software can do is a big
| part of what makes apple devices have such a good user
| experience.
|
| Correlation does not equal causation. There is a way to
| provide streamlined default experience without the control.
| The Mac has so far been an example. Everything under the sun
| is possible, but apple only paves the path they would prefer
| you take.
| scarface74 wrote:
| And the Mac has cases like Zoom installing a back door web
| server so even when you deleted the app, it could reinstall
| itself.
|
| Another case (not saying it's nefarious it was obviously an
| unintentional screw up) was if you had System Integrity
| Protection turned off an installed Chrome, it would render
| your Mac unusable. (https://arstechnica.com/information-
| technology/2019/09/no-it...)
|
| Even Apple is not immune from screwing up on the Mac. A
| certain version of iTunes deleted users files if the hard
| drive name had a space in it.
| ksec wrote:
| >Sideloading/rooting an idevice as long as it can't do Apple
| Pay/bypass find my iPhone is fine of course.
|
| Epic actually made a case or suggestion for this all the way
| back in 2015. The App Store distribution doesn't need to tie
| with App Submission Compliance.
| mcot2 wrote:
| I disagree but will likely get downvoted on HN as this
| communtiy does not really reflect the huge set of customers
| Apple is building these devices for. The Mac is for us.
| iDevices still for the most part target a broad swath of
| users (despite the pro moniker) and have to be easy to use
| and as secure as possible.
|
| Offically suporting sideloading will lead to what we have on
| the Mac, an official app store that is barely used and
| compromises the security model and user experience for many
| major apps. If you give an official channel to bypass Apple
| policies people will use it for everything. A major part of
| the security model for example is a third-party (Apple) being
| able to nuke abusive apps. Also enforcing compliance with
| certain UI guidelines as the devices evolve keeps things very
| easy to use. Its possible to have some of the things for
| sideloaded apps but more difficult to control.
| asiachick wrote:
| Android allows side loading and there are at least 10 3rd
| party app stores. And yet the Google Play store is the main
| player. So there's zero evidence that allowing side loading
| would turn the iOS App Store (top store) into the Mac App
| store (barely used)
| _ph_ wrote:
| I have to agree and disagree. Yes, it is good that not every
| app has root rights, that you have a reasonable expectation
| of security and some level of quality assessment. However, at
| the same time Apple fails dramatically at keeping bad or even
| nefarious apps out of the app store. And in a lot of places,
| user experience is outright horrible because of the
| restrictions. Have you ever tried to move music from files to
| the music app? You can't. So I have music on my iPhone I
| basically cannot play. Same for videos. And a lot of data
| handling is awkward at least. With all their power through
| the App Store, Apple should insist that all apps which have
| some sort of local data also support the files app. That all
| apps which play video properly support picture in picture
| (most don't or differently). Not to mention, that there isn't
| even the most basic, even if completely sandboxed, shell
| application. In this context I can only praise "Working
| Copy", which works really great in giving apps git access.
|
| Personally, I am very excited about the new iPad Pro, but I
| am holding on my order till WWDC, trying to find out whether
| Apple finally has an answer to what I can use this gorgeous
| device for and finally lifts some of the road blocks.
|
| So yes, I do think a good amount of control can help building
| a quality environment and on the one side is responsible for
| all that is good on the iPhone/iPad platform. But also flaws
| in the execution by Apple are responsible for a lot of things
| which are exactly not good user experience. At a minimum,
| they should try hard at improving the developer experience.
| Limiting the ability of apps to access car play? For apps
| actually distributed, yes. For developers, who want to
| experiment with it, definitely not. Same with the discussed
| API in the article. There should be a clear path for
| developers to discover and access these entitlements.
| scarface74 wrote:
| Can you imagine the shit show that would happen if a
| developer installed a video playing app on his own CarPlay
| device and he got in accident?
|
| All car manufacturers are very careful about what you are
| allowed to do on driver accessible controls on dashboard
| gadgets.
| nobodywasishere wrote:
| It'd be only the driver's fault, not anyone else's. How
| is this any different from playing a video from the phone
| and either holding it, or putting it on the dash?
| bengale wrote:
| I think my preference would be that hardware manufacturers
| should give the ability to boot other operating systems. Then
| if people want to run their own software they can without
| forcing someone else's OS to fit them. Then there can be no
| more arguments about not owning your own device, run what you
| want on it. Consoles, phones, laptops whatever.
| mcot2 wrote:
| We are just used to this for "computers" because of how the
| industry evolved but it really is the exception and not the
| norm if you think about it. Even for early cell phones and
| pdas most ran their own OS and didn't seperate the hardware
| and software layers.
| andrepd wrote:
| "A good user experience" and "not being able to do with your
| device as you please" are incompatible concepts to me. It's
| amazing how somebody is okay with Big Daddy Apple controlling
| what they do or do not do with the device they bought.
| fredsted wrote:
| I don't think Apple will grant them the entitlement now that they
| have made a public blog post complaining about it. They don't
| like that at all.
| 0x0 wrote:
| Another weird example is how Apple's own "Clips" app has a
| special private entitlement that bypasses the permission prompt
| for camera access.
|
| Would it hurt them so much to prompt for camera access the first
| time the app is started after installing it from the app store?
|
| I found that extremely worrying as it means I can no longer trust
| the app store to provide a safe sandboxed environment. Suddenly
| there's an app with this special no-cam-permission entitlement
| and your mugshot is uploaded when you believed the ios camera
| permission system would have protected you.
|
| Oh, but Apple would only ever grant that permission to its own
| apps? Better hope we'll never get a repeat of the PsychicPaper
| exploit!
| machello13 wrote:
| I guarantee you the product manager for Clips probably just
| made a lot of noise about trying to reduce onboarding friction
| as much as possible, and their manager talked to someone else's
| manager and got that entitlement. I agree it's bad optics, but
| on the other hand I'm not sure there's a practical difference
| between the Camera app having this entitlement, and Clips
| having this entitlement. Both are made and distributed by
| Apple, regardless of the method of installation.
| erikpukinskis wrote:
| Camera app should ask too.
| machello13 wrote:
| Why? Apple makes everything from the hardware up to the
| apps on the homescreen. Why do you trust the hardware, the
| kernel, and the OS, but not the "apps", when all are made
| by the same organization? They're the same as any other
| software on the device, they just have an icon associated
| with them.
| Grustaf wrote:
| Yeah, it's pretty pointless for first party apps to ask
| for permission, since Apple already have access to
| anything they want.
| 0x0 wrote:
| The "Clips" app is not as first party as the built-in
| camera app is. I mean, it still comes from Apple, but it
| is ONLY distributed as an additional download in the app
| store. You know, via the same app store we're supposed to
| trust to sandbox us from malware.
|
| That changes the game completely!
|
| You're conditioned to trust and think iOS and its app
| store has a permission system, so you can go crazy and
| download and install any app you want, safe in the
| knowledge they won't access your camera without your
| permission.
|
| And then suddenly there's this magic nondescript app
| "Clips" in the same app store... that just bypasses the
| entire thing.
| nexuist wrote:
| Given that you can delete/download first party apps from
| the App Store now, including Camera, doesn't that imply
| that Apple can update first party apps remotely now? If
| so, Clips and Camera are treated the same, Camera just
| happens to come with the device and Clips doesn't.
|
| The real answer is probably that Clips is onloaded onto
| demo units at retail stores, and they don't want the
| first user to deny permission and prevent everyone else
| from using the app.
| Grustaf wrote:
| Apple doesn't want apps to spy in people against their
| will. They know Clips won't spy on people, so no need to
| ask for any permissions.
| jorvi wrote:
| Its not about the technical reason, it's about optics.
| You pre-approve system apps location access during iOS
| first setup, but you do not for camera access. Basically,
| all privacy toggles should be opt-in, not opt-out, even
| for system apps, even though Apple could easily bypass
| that for their own apps.
| Grustaf wrote:
| Why? People explicitly trust Apple with their most
| sensitive data. Asking for permission for specific apps
| makes no sense.
|
| I don't personally care about "level playing fields" but
| even if I did, I wouldn't expect or want it to include
| the first party.
| 0x0 wrote:
| Because the mere fact that an entitlement for bypassing
| permission prompts exists, means that non-apple apps
| could try to exploit it (see for example the PsychicPaper
| exploit).
|
| Designing in such a huge hole in the permission system
| just makes it that much more difficult to trust it.
| mrtksn wrote:
| I had to check that app and wow, what an amazing video editor.
|
| Apparently it's a prosumer level app with quite a bit of power
| and depth: https://www.youtube.com/watch?v=lI8SWCUWMDY
|
| However I agree that it's strange not asking for camera
| permissions. The app itself can be used with no camera.
|
| It's also strange because even apple's own watch app that
| tracks your hand washing habits keeps asking for permission to
| track your location. Every now and then you will be reminded
| that hand washing reminder app tracks your location.
| jonplackett wrote:
| Reckon there's a good chance this turns up in then Epic VS Apple
| case!
| bsaul wrote:
| the worst kind i think is the special entitlement whatsapp and
| other popular messaging apps get for abusing voip push
| notifications (not related to an actual voip call, but still
| waking up the app).
| xuki wrote:
| Remember that one time when Apple let Uber record your screen
| even in background?
|
| https://www.macrumors.com/2017/10/05/uber-removing-apple-gra...
| viktorcode wrote:
| I don't think Apple let Uber record device screen from
| background. I think this is something that Uber would be
| proactively avoiding doing to remain in App Store.
|
| The linked article states that it was granted to render map
| on old Apple Watch.
| jbverschoor wrote:
| And I'm very happy about that. Imagine the horror of some apps
| sending notifications to wake up an app, so they can track your
| ip/location/whatever.
|
| I'd say give more control to Apple.
| matsemann wrote:
| Meh, let me as a user decide if an app should be allowed in
| the background or not.
|
| The "kill everything" approach to keep battery life is just a
| band aid and more often than not just ruining someone's
| experience. I've heard sooo many stories of people using
| fitness trackers on ios that stops working in the middle of a
| run, for instance.
| bsaul wrote:
| there are other solutions to accomplish the same goal (edit:
| maybe not _all_ of the whatsapp features though), but it
| requires a bit of work. I believe the reason they did that
| was to allow whatsapp to keep working when they decided to
| update the voip notification behavior on ios 12 (or 13 ?) and
| stop forwarding voip if the app didn 't actually trigger an
| "incoming call" screen after the notification has arrived.
| GraemeMeyer wrote:
| Source/more info?
| bsaul wrote:
| https://stackoverflow.com/questions/60815763/how-does-the-
| wh...
| tyingq wrote:
| Not great timing for Apple, given the US government's sudden new
| interest in anti-trust and the plight of small business.
| viktorcode wrote:
| Private entitlements aren't news. They've been known for years.
| scarface74 wrote:
| What's the government going to do? Say no large company is able
| to beta test products with a few companies before they make it
| publicly available?
| slver wrote:
| When Apple tests new ground, only their apps have access to a
| feature. Then only partners. Then only approved developers. Etc.
| This gradual rollout allows refinement and reduces the odds of
| screwups.
|
| It looks unfair, but Apples goal isn't to be idealistically fair,
| but to keep iOS a good experience to users.
|
| For every good use of a feature there's an abuse case.
| ClumsyPilot wrote:
| "Apples goal isn't to be idealistically fair"
|
| Either the market is manipulated, or it's not - there is no
| third option.
|
| Anyway, if this is all normal amd legal, why do they lie about
| it?
| misterchrister wrote:
| > It looks unfair, but Apples goal isn't to be idealistically
| fair, but to keep iOS a good experience to users.
|
| So what you're saying, is that when the platform serves as a
| gatekeeper it's unfair? That's what I'm hearing.
| _ph_ wrote:
| It is fair, if Apple uses one or very few select developers in
| bringing a feature to the market. But after a certain point
| when the feature is rolled out in production of a very popular
| app in a way that it is visible to exist to everyone, they
| should be very transparent about it and clearly document it.
| And make it available for development, even if getting approval
| to deploy an application based on it might be a separate step.
| slver wrote:
| So it's not fair. Why should it be though.
| _ph_ wrote:
| We might be missing out a lot of good apps. To get really
| good and innovative apps, a lot of developers need to be
| able to experiment with a features to develop good ideas
| and implement them.
| slver wrote:
| Your hypothesis is missing an entire side of a two-sided
| coin.
| supermatt wrote:
| Reduce the odds of a screwup by giving it to arguably the most
| popular app in the store?
|
| This is nothing more than apple giving themselves and their
| preferred partners an unfair advantage - somewhat in opposition
| to Tim Cooks recent statement on developer equality.
| asutekku wrote:
| Most popular apps are less likely to abuse the feature in a
| malicious way and it gives a great amount of users to test
| the feature.
| schappim wrote:
| Zoom doesn't have a great track record here.
|
| In the past [1] they'd "(ab)use preinstallation scripts,
| manually unpack the app using a bundled 7zip and install it
| to /Applications if the current user is in the admin group
| (no root needed)."
|
| [1] https://twitter.com/c1truz_/status/1244737672930824193
| misterchrister wrote:
| Hilariously, "most popular apps" being Zoom getting busted
| for lacking basic communication security out of the gate
| when the pandemic hit and a/v comms became important.
| Please, tell us more about these most popular apps.
| joshjdr wrote:
| So the pandemic hit, use of teleconferencing apps shot
| up, and then security issues were identified in one of
| the most popular apps. How does that refute the comment
| you're responding to?
| supermatt wrote:
| For zoom in particular, they were calling the app e2e
| encrypted, when it wasn't. That's not a security issue,
| that is a lie.
|
| They were also (among other well known apps) caught
| snooping clipboard contents. That's not something you do
| accidentally.
|
| What else... reinstalling themselves after you remove
| them?
|
| That's 3 anti-user practices I can think of off the top
| of my head - no doubt there are more.
| skinnymuch wrote:
| I think the point is that as a small app. The security
| issues aren't seen or found. So any parent comments about
| bigger apps being worse than other apps doesn't work in
| this case or have any solid evidence of in general.
| slver wrote:
| This argument would make sense only if being less popular
| meant being better at security than the popular apps...
| asutekku wrote:
| Incompetence is not maliciousness.
| kevingadd wrote:
| They also have a track record of being malicious
| https://twitter.com/c1truz_/status/1244737672930824193
| avereveard wrote:
| > [popular apps .. less malicious]
|
| ah yes, the notoriously well behaved facebook and tiktok
| scarface74 wrote:
| Every company does this. They roll new features out to
| trusted partners first to get feedback and then they polish
| it. For instance how do you think that AWS [1] can have
| testimonials about how great a brand new product is before it
| is available for public release?
|
| Once you make an API public, you have to support it for the
| foreseeable future. It's much easier to work with one or two
| trusted third parties.
|
| When I was working for a small company that sold access to
| our APIs, we would test it internally first, then a few
| partners. Then make it available to all of our customers.
|
| Even Epic admitted that it got special treatment from Apple
| and was able to test and recommend features before they were
| made public.
|
| [1] I work at AWS. All opinions are my own....
| slver wrote:
| Do I have to explain that giving something to a few key apps
| is much easier to control and analyze than giving it to
| thousand of obscure apps?
|
| It also gives more to the users - the feature is available in
| apps most of them use.
|
| Also this will be unpopular opinion but I don't consider
| Apple giving themselves features an unfair advantage. Apple
| obviously trusts itself more than some random dude with a Mac
| mini.
| supermatt wrote:
| I'm a huge Apple fan, and am often on their side on HN
| (check my comments). But this whole App dev and
| distribution unfairness I am dead against.
|
| I really don't see how you can view this behaviour as
| anything other than an unfair advantage. By all means let
| them level the field by not using private apis themselves.
|
| And more importantly, when you are asked about it publicly,
| don't lie about it.
| slver wrote:
| Companies would lie less in public if the legal process
| was based on common sense. It is not. Everything you say
| is used against you.
| skunkworker wrote:
| This back and forth exchange between Zoom and Jeremy Provost is
| really all I could find on the entitlement.
|
| https://devforum.zoom.us/t/video-camera-not-working-in-split...
|
| And it's odd how they expect that someone integrating with the
| API will just be able to use it.
| joelhaasnoot wrote:
| Ah yes, the private entitlements. There's also a private
| entitlement to disable Apple Pay/PassKit so that it doesn't clash
| with things like barcodes (for example transit). That one is
| pretty Google-able though.
| withinboredom wrote:
| Ah, reminds me of the time almost everyone in our group got
| stuck in a train station. The people with androids had to let
| us out because our iPhones would open Apple Pay and obscure the
| barcode.
| urbandw311er wrote:
| Just FYI this is available from Apple on request by any
| developer, you just need to write to them to explain the use
| case. I guess this is just to prevent abuse.
|
| (Source: we use this entitlement at our company)
| wodenokoto wrote:
| I wonder if Zoom can get in trouble for spilling the beans on
| this private entitlement.
| xuki wrote:
| No, it's public information if someone wants to find out. This
| is the full entitlement of Zoom https://pastebin.com/0qHP2v1F
|
| Now it would be interesting to automatically download all the
| popular app every update and find private entitlements.
| kmeisthax wrote:
| Given that all App Store apps are encrypted with FairPlay
| DRM, and only accessible on a device filesystem that users
| cannot read, is it necessarily public? Like, I'm pretty sure
| you have to be jailbroken in order to even read that
| entitlements file.
| villgax wrote:
| Finally someone has raised a question regarding private APIs and
| special fees from Apple for certain apps.
| viktorcode wrote:
| Personally, I see nothing newsworthy here. Seems like Apple is
| using private entitlements the way they use private API: to
| implement something now that public entitlements that public
| variants can't accomplish, and maybe make them public in the
| future when polished enough.
| paxys wrote:
| I don't understand how this is even a security concern. How does
| it matter whether an app accesses the camera while it is taking
| up the full screen vs half?
| slver wrote:
| Two apps sit side by side. You see the camera dot. Which one is
| recording you?
| tester89 wrote:
| Put the camera dot on the side of the app using it. Also is
| this really the issue? You can have an app voice recording
| and even quit it and it's just fine.
| slver wrote:
| Do you know when your boss says "just do x" and you get
| frustrated by him not realizing the difficulty or
| implications of his request? That's us right now. Just add
| dot on the side of the app. There is one bar, to start
| with. Not two.
| tester89 wrote:
| When multitasking the black line splits the bar into two
| so, Apple could reasonably just put the camera icon on
| the correct side.
|
| When the app is in overlay mode, there is a bar at the
| top with the grabber, the icon could go on it as well.
|
| There's enough space, and bars.
| isatty wrote:
| When you swipe down it tells you which app was/is using the
| camera.
| skinnymuch wrote:
| Swipe down. Top left I usually see what is using the camera
| eps wrote:
| Add a second dot.
| slver wrote:
| Two dots would look like the camera is used by two apps.
| That's not the scenario.
|
| Also I doubt Apple wants to turn the UI into a Morse code
| sequence to be deciphered by users.
| bellyfullofbac wrote:
| They just want to do that with the hardware...
|
| How many finger and swipe combinations are there with the
| home button, or trackpad?
| bombcar wrote:
| I could see sneakiness happening with an app that detects
| another app is sidescreened and you think the first has the
| camera but it's actually the second. Not sure how effective it
| would be.
| mcot2 wrote:
| I am not defending Apple here but perhaps they intend to make
| this a public entitlement or even an official API but they are
| working with Zoom to test it first.
|
| We know Apple gives testing priority to certain developers, they
| mention it at practically every presentation they do. Granted
| those are usually for NDA'd features for making demo-only apps.
| schoolornot wrote:
| "We treat every developer the same. We have open and transparent
| rules, it's a rigorous process...those rules apply evenly to
| everyone." Right.
|
| https://twitter.com/cbseveningnews/status/128854230760894054...
| bombcar wrote:
| All developers are equal but some are more equal than others
| supernova87a wrote:
| I mean, the surprise here (to many I suppose) is that their
| belief that Apple is one huge company with documented procedures
| and all-their-shit-together is not always true.
|
| Apple is just as much a company full of little people and groups
| as probably any company is. And despite some things seeming
| really polished, others are operating by the seat of their pants,
| with a just-released feature that they're working the bugs out
| of. A team of developers who have some library that they didn't
| fully document yet, or are supporting on an email basis.
|
| Just like whatever open-source project or team you might know, if
| you raise some legitimate need, are not a crackpot weird user,
| are important in some other way, and know how to contact the
| right person, they can probably help you. It's just that it's big
| Apple, so there are some hurdles to doing that.
|
| Is it odd to realize that if a big company / user group raises an
| issue, it's likely to get some legitimate attention versus a
| curious bystander just randomly asking what this API is, with no
| promise of why they need the info? Don't you treat meetings at
| work and random requests similarly, with some judgement of
| credibility of the asker in mind?
|
| Just like a company is not probably "evil" and out trying to get
| you -- it's probably 1-2 people who are responsible for something
| and its fix. And whether the company enables that to happen tells
| you what the outcome will likely be. It even holds true for a
| place like the IRS.
|
| More often than not, there is _someone_ who knows your issue and
| who you can contact to figure it out. If you provide enough
| coherent information and understand that it 's worth their time
| to help fix, and find the right channel.
| f3i-yfq wrote:
| So this explains why I can't use the front camera of my iPhone
| while streaming mobile games?
|
| It's always been a limitation on iOS.
| rock_artist wrote:
| I wondered for a while why only FaceTime can keep camera on while
| I'm switching apps. Not Google meet, Viber, Whatsapp, Signal.
|
| There are many un-fair things with Apple's apps and some valued
| ones. I believe eventually this will get back at Apple.
| viktorcode wrote:
| This was happening since 2008, the year of iOS SDK release.
| Apple's software had every capability, while third-party
| software was quite limited. But with every new SDK release more
| capabilities were made public. Camera multitasking may one day
| become public too.
|
| Nothing to do with "fairness", simply a way of rolling out
| public APIs.
| numair wrote:
| If I were Apple, I would say "oops a couple security-sensitive
| APIs slipped through that we forgot to open up for requests for
| access," and quickly publish an expanded list of all of the
| entitlements they're currently saving for their close friends.
| This is different, and more toxic, than all of the in--app
| purchase stuff -- you're telling indie developers that no matter
| how hard they try, they won't be able to match the functionality
| of Apple's special friends.
|
| Otherwise, well, there goes your narrative of having a level
| playing field. The problem with this is, the loss of trust
| results in a slow, unending decay that only becomes obvious in
| retrospect.
|
| It may not seem like it, but billions of dollars of value are at
| stake with little things like this. If you work at Apple, you
| should raise the alarm.
| hrktb wrote:
| > you're telling indie developers that no matter how hard they
| try, they won't be able to match the functionality of Apple's
| special friends.
|
| To note, the entitlement switching from private-only-zoom-is-
| in-the-loop to public-and-documented doesn't mean that indie
| devs get access to it. Apple still will grant it to special
| friends only, and random indie devs can request but will just
| be rejected.
| judge2020 wrote:
| Chances are it'd be the same as the carplay drop-down - you
| only get access if your app is part of a market that apple
| allows the API to work on. You have no idea if it'll stay
| "only for Apple's friends" once they do this; even the
| current CarPlay app selection has no-name apps like Next[0]
| (74 total ratings), and I doubt they pulled any favors to get
| on there.
|
| 0: https://apps.apple.com/app/id1476724373
| gzer0 wrote:
| Hi, please let me know how I can apply for the entitlement:
| com.apple.developer.avfoundation.multitasking-camera-access
|
| I see no documentation anywhere regarding this besides the
| Zoom forums. Thanks!
| ksec wrote:
| When Smartphone is the centre of our digital society ( and
| this is not an exaggeration ). And Apple gives API and
| special features only to select companies within each
| different industries. Say only certain car makers get X, or
| others gets Y for Banking / Finance. At what point will
| this be Not OK for government and regulators?
|
| Or judging from comments on MacRumors and 9to5 or dozen of
| other Apple's focused website, Apple devices Apple rules,
| and this is a perfectly acceptable norm?
| xuki wrote:
| They have a documented process to apply for CarPlay. There
| is not even a way to apply for this special entitlement.
| judge2020 wrote:
| I said "it'd" (it would) - this isn't a thing yet and
| they likely threw it into iPadOS on short notice due to
| the WFH boom and giving it out is still an informal
| process. I'm not defending this action of Apple's - they
| have the resources to copy and paste the CarPlay drop
| down into a new one for camera access, but the comment i
| was replying to was specifically talking about 'when
| apple adds the application process for this entitlement'.
| saagarjha wrote:
| This is not a new occurrence: Uber got com.apple.private.allow-
| explicit-graphics-priority (yes, I really mean
| com.apple.private!) that let them record the device screen
| several years back.
| tpush wrote:
| That that didn't generate more of a hubbub back then and
| seemingly didn't stay in people's memories for long is a real
| mystery to me (and a great boon to Apple!).
| andrepd wrote:
| Well you can see people in HN are very keen to defend Apple
| as being the world's most privacy friendly tech company,
| despite no evidence in that direction :)
| josephg wrote:
| Their record isn't perfect, but there's plenty of
| evidence Apple cares about privacy. For example, Apple
| added E2E encryption of iMessages long before signal and
| whatsapp made E2E popular. They also E2E encrypt the
| location of AirTags - which they absolutely did not need
| to do. Or the recent opt-in iOS data sharing rules - much
| to Facebook's frustration.
|
| But companies, like governments, countries and people are
| not wholly good or bad. Companies don't think with a
| single mind, or act with a single voice by default.
| They're a flag waved by thousands of different people who
| each have a different background, different capabilities
| and who each make slightly different ethical and
| financial tradeoffs.
|
| Google is a massive contributor to opensource. And they
| harvest vast amounts of user data. And they use far less
| of it for advertising targetting than they could, out of
| respect for their users. Google makes some of their most
| valuable IP - Android and Chrome - (mostly) opensource
| and open platforms. They suspend users' accounts for
| silly reasons, and have a bad habit of shuttering
| services people care about, to the point where I
| generally avoid new google products to prevent heartache.
|
| Apple makes beautiful devices. And they do a good job
| caring about user privacy. And the iOS app store is a
| rent-seeking monopoly designed to maximise profit, where
| they pull crap like this. They have given the world llvm.
| And their design leadership invented the modern
| smartphone. Without them android might still be trying to
| emulate the blackberry.
|
| Apple deserves praise for their privacy friendly
| technology. And they deserve criticism for how they run
| the app store. I see no contradiction there.
| matwood wrote:
| I was going to say tech people, but I think more
| generally people like to view the world in black or white
| or 0 or 1 when in reality there are few issues that
| clear. As you stated very well, most of the world exists
| in the gray. Apple can care about privacy while not being
| perfect. Privacy can also be good for their bottom line
| at the same time. Even the App Store policies are not
| wholly bad or good for users, just a different set of
| tradeoffs, some of which as you say deserve criticism.
| ksec wrote:
| I need some time to come up with an augment against that.
| But the tone and message with privacy differs a lot
| between Steve Jobs's Apple and Time Cook's Apple. I cant
| quite figure out precisely what is wrong but I just smell
| lots hypocrisy.
|
| For example Apple tracks its user within App Store. Which
| is perfectly fine except their PR make its sounds like
| they dont.
| grishka wrote:
| E2E encryption and closed-source software don't mix imo.
| They _claim_ that they encrypt iMessages and AirTag
| locations, but you don 't have much in the way of
| actually verifying that everything is implemented the way
| they claim it is. And even if it is, their threat models
| are usually such that Apple is an unconditionally trusted
| party. Moreover, they hinder reverse engineering of iOS
| as much as they technically could.
| smoldesu wrote:
| +1 to this. If your threat model relies on a single
| centralized system, it's a bad model.
| smoldesu wrote:
| For the record, Apple didn't give the world LLVM. They
| bought out the original development team and then had
| them develop a proprietary fork for Apple devices,
| oftentimes referred to as Apple LLVM.
|
| Also, while I'm here, I still am not convinced of Apple's
| privacy dedication. The T2 chip was a joke for anyone
| familiar with PRNG generation or the actual exploits
| being patched with it, and they've refused to add E2E
| encryption to debatably the most important product in
| their lineup: iCloud. Furthermore, their collusion with
| PRISM and history in China leads me to believe that their
| statement "privacy is a human right" is all security
| theater. Apparently, it's only a human right if you don't
| live in a place where their government disagrees. Then
| Apple has to abide by their rules. And if they're happy
| to turn over information in China, there's nothing
| stopping them from colluding with the US to weaponize
| their information.
| fishywang wrote:
| Does Apple care about privacy? Yea, maybe, as you said
| there are a few evidence to support that.
|
| But does Apple have the competence on security to fulfill
| that care? There are also a lot of evidence to support
| that the answer is no.
| pydry wrote:
| >Google makes some of their most valuable IP - Android
| and Chrome - (mostly) opensource and open platforms.
|
| This was out of market necessity. They likely wouldn't
| have open sourced either if they thought they could have
| dominated the market without it.
|
| Moreover, with both of these products they're drip
| feeding more and more functionality into closed source
| appendages (e.g. google play services). Their end goal is
| likely to ensure that if they did de-open source the
| whole lot, it wouldn't be possible to just fork it.
| scarface74 wrote:
| What most people consider "Android" - open source + all
| of Google's proprietary add ons is not open source. A
| true AOSP only phone would not sell in any kind of volume
| in the US. Google yields a lot of power over Android
| based on its add ons.
|
| Every major tech company open sources software that
| doesn't impact its compatibility and encourages adoption
| of its platform.
| BoorishBears wrote:
| > despite no evidence in that direction :)
|
| Is this a joke?
|
| Anyways, the entitlement Uber had was one thing, it'd be
| another if they had passed approval while _using_ the
| entitlement. Afaik it was used for an Apple Watch demo.
| No one ever found evidence of its use in the main app.
|
| It wasn't an entitlement for recording a screen, it was
| an entitlement for low level graphics access that could
| then be abused to do so.
|
| Had they actually used the entitlement to record screens
| it'd be one thing, and I take exception with unfair
| treatment of devs like this, but please. Actually
| implying Apple has taken 100x the steps of their nearest
| competitor to maintain privacy on the most used computing
| devices...
| sneak wrote:
| Apple is good at controlling Apple narratives even when they
| are completely detached from reality.
|
| I don't think Apple needs to do what you suggest here to keep
| their narrative around the iOS App Store intact.
| someonehere wrote:
| Do we know the full details of this API or is there something
| nefarious it can do we're unaware of? Remember several years ago
| they discovered the webcam can be enabled on Macs without the
| light turning on? I know this is iOS/iPadOS, but as a consumer
| I'd like to know what it can do specifically. Or did I miss
| something?
| londons_explore wrote:
| It looks slightly risky because an app can continue to use the
| webcam after being backgrounded. I can imagine nefarious apps
| tricking a user into streaming their webcam for hours after
| using the app once.
|
| Apple probably decided that was safe enough _only_ if the app
| has been through some extra review to ensure it has a clear UI
| so the user understands they are still streaming video
| somewhere.
___________________________________________________________________
(page generated 2021-05-08 23:03 UTC)