Hanlon's Razor : Never attribute to malice that which is adequately explained by stupidity.

I think it totally applies here.

Not removing temporary files is a very common bug. As a developer, I've encountered it several times, sometimes I caused it, sometimes I fixed it, and I've seen it happen in other people software just as often. This is one of the reason I hate temporary files, they just don't wan't to be temporary.

The Godfather's Switchblade:

Make it look like an accident.

Ultimately I don't think we can judge intent in situations like these, especially because it's so easy to disguise[0]. A sentence can be constructed in favor of any opinion; so I'll spare you my attempt at an alternate reading of the situation that makes them sound guilty so long as you agree that it's possible to do.

I think a few questions can be raised about whether we can trust a company's claim that a problem stops exactly at the limits of what's been made publicly visible. How do we really know that select installations weren't phoning home with their captures?

This is a great moment to plug the idea that we really should be able to see the source code of the software we're running.

[0] http://www.underhanded-c.org/

This is very good. The parent comment is very reasonable, but your switchblade admits the possibility of aonethig very concerning which is not easily dismissed.

They did post a bug fix though.

Well, why wouldn't they post a bug fix? I don't see how that says anything about motive/cause. They'd do that even if it was intentional.

> Hanlon's Razor : Never attribute to malice that which is adequately explained by stupidity.

Why? How do you "accidentally" record someone?

Presumably you have a feature that depends on recording (but not storing) audio. You then write some code to store the audio anyway, because you’d rather just use the stored audio as a development aid while working on the audio-dependant feature. then you forget to disable the storing in the release build.

It seems that storing the file is not just a development aid, because it seems they are still doing it after the fix (according to the report, I don't have any compatible product to try it out...). They just make sure to delete it when it is not needed.

The reason they store the file probably has to do with technical constraints. Maybe the audio API they are using only works with files and not memory buffers, maybe the buffer took too much space, maybe it is a workaround of some kind. We won't know without analyzing their code.

It's possible this was only done on Android specifically because the odds of this being picked up and the app rejected by Apple are close to 100% while the odds of that happening in Google Play are about 0%.

haha. yeah, no. Apple catches UI issues and obvious use of private APIs. You just need the slimmest of excuses to do what you want. Like if you want to track a user's location put a location feature ANYWHERE in the app.

Also if the app is using the mic outside of the app, you'd see a big red bar at the top of your screen.

Does Apple hellban in cases where they discover someone was maliciously trying to call private APIs? How easy is it to get away with this long term?

I know places that have been doing it for years. They just tell you to stop. It's basically an arms race of them trying to figure out how you're doing it and figuring out ways to prevent them from detecting it. The app has a few million users so not sure if Average Joe would just get hellbanned.

Private APIs are APIs that only Apple is allowed to use. They let you do stuff you're not supposed to be able to do like put stuff on the home screen, however, these days, it's mostly enforced by the security model, so you can call the private API all you want and it's not going to do anything.

They also let you do things like record what other apps, etc are doing. Think of the Linux top command, on iOS there's no real reason for an app to need to list the other processes, so you can't. However, if you want to know what apps are running on the phone this would be a very useful API to have access to.

Apologies for my laziness, but what is meant by "private API" here and why Apple does not want them to be used?

They are functions (in the programming sense) that can be called by other code, but Apple reserves them for their own use. They don't necessarily have anything to do with privacy, though some of them do. The "private" refers to them not being publicly documented and not provided for developer use. Internal developers at Apple are allowed to use them, but only as appropriate. Consider a function (API) that allows one to wipe the phone. Apple doesn't want just anyone to be able to write an app that provides that feature. Same with a lot of other functionality. Other private APIs are things that Apple might someday offer to developers, but hasn't yet. For example, Apple can change the icon of its own apps (note the calendar app, which shows the current numeric month day, and the clock app, which shows the time including moving second hand) but it does not offer this functionality to developers. [Edit: I was wrong about this; see firloop's comment below.] If they did, the results could be off the rails, visually, and make the platform look bad, so I expect when they do allow this, they'll do it with a heavy review process in place... but that's just one small example. A lot of private APIs are more under the hood housekeeping stuff that you just don't want the average programmer to mess with.

The API to change an app's icon is not private (as of iOS 10.3)

https://developer.apple.com/documentation/uikit/uiapplicatio...

However, it's much more restricted than the functionality natch referred to. An app can only change its icon while running, and even then only with the user's explicit permission.

Oooh, nice! Thanks.

> Apologies for my laziness, but what is meant by "private API" here and why Apple does not want them to be used?

Private APIs are not meant for use by third-party developers. They are not publicly documented and are subject to change without warning.

Often the private APIs are used to track users, because they allow getting identifying serial numbers from the phone.

Apple markets privacy as one of the features for the iPhone.

In the technical sense it sounds like a minor bug in, in the other implications not so minor - perhaps another mistake on their part of not being more clear with language.

> hahaha do you even code bro?

Yes I do. https://github.com/theShiva/

'no excuse' because of the context and sensitivity. It's a different issue if the programmer was leaving around some code execution log files or non-sensitive data on the disk...

A file containing recordings (audio & video?) of a sexual experience doesn't constitute 'temp file clean up bug' in my world. That said, we may be working in different worlds.