The FairPlay certificate rotation theory makes the most sense. Apple has done silent re-signing before when DRM certificates expired. What's unusual here is the update note surfacing in the App Store UI at all — that's probably an unintended side effect of whatever pipeline they're running this through, not intentional transparency.
hmm, my money is on some actively used 0-day exploit that Apple is sealing shut before the CVE gets announced.
By the looks of the app list, they seem to be apps and games that used to be popular and have fallen in disrepair and apps that are starved of maintenance attention.
On the one hand it could be an exceptionally good example of "stewardship"; on the other hand, if this is true, what if authorities could later compel Apple to manipulate applications in some malign manner?
If you are worried about apple being compelled to do something, then they can do that at the OS level rather than something obvious in the
I think this is simply updating some api call which no longer works properly, coupled with the terrible "changelogs" that are the norm on the app store. Someone down thread mentioned certificate rollover.
A sensible changelog would be "update expired certificate", or "fix integration with ios 26.2", or "patch security issue"
An actual changelog would be "we're bringing you ever more great new improvements"
Here's the latest Audible one:
> At Audible, we're always making updates and improvements to make your listening experience better.
> If you're experiencing issues, please reach out to customer services. For feedback or suggestions contact us at audible.co.uk/help
This is the same every time, because these changelogs are meaningless.
Neither developers nor consumers should be comfortable with this, as this breaks the trust model and is extremely worrying. The site is of course downplaying it given its name, which is a huge shame.
What trust model are you thinking of though? Because another way to look at it is that Apple has pushed an update to ensure these apps keep working and remain secure.
And this is part of the agreement between an app developer and Apple; for a long time now, a developer doesn't upload a full compiled app to Apple, but a package containing partially compiled (itermediary language) code and assets for many different platforms and resolutions, leaving it up to Apple to do the final assembly based on what device it downloads. This allows them to (re)compile for newer hardware, 32 vs 64 bit CPUs, save bandwidth and storage space by only having the device download the assets for its device (and for e.g. games the assets for the level they are playing at that time), etc.
So again, what trust model are you thinking of? Apple is a trusted party when it comes to this, I'd even argue they're more trustworthy than the app developers themselves.
I saw this the other day in a couple of apps, I've checked other apps and didn't have that, did a quick check on HN frontpage and saw nothing and said wth I'll update to see if something changes in the app or there is a message. Got nothing, and didn't think more about it but I'm not sure why, is it the "trust in the process" thing or what?
Has anyone ever done a proper security audit of VLC that is downloaded from the web? I don't trust it, and the fact that their releases on Github don't include binaries makes me trust it even less. Nobody is compiling VLC from source, and they don't provide any sort of provenance from the GH actions pipeline.
Look at the supported formats lists. It includes so many parsers, mostly written in C, which means there probably are a few dozen ways to exploit the player.
Can you tell us about any prior or active incidents like that though?
That is, I'm calling you out for fearmongering, for a possible what-if, but given how popular VLC is you'd think it would've happened / is actively happening already. And there is no evidence for that.
Speculation for fun: I always thought popular apps can use private apis or are handled in a special way by the OS itself. If yes, perhaps this is related.
Then again I found no source for that - and some certificate rollover seems more likely.
As always, it depends; VLC "the iOS app" is not the same as VLC "the binary compiled from source". The article itself says they couldn't find any code changes, and the theories are that a certificate was updated.
I don't believe an iOS distribution specific certificate falls under the license you're referring to, but I'm no expert on these matters.
FTA: “The update text is appearing on apps that have not been updated in some time, as well as apps that received recent updates, so it's not clear what the apps have in common.”
⇒ I think that’s unlikely. If some optimization got broken that produces results that bad that it has to be fixed, users would have noticed in those apps that “have not been updated in some time”.
In the past, things like this used to be done for signing certificate rollovers.
I wonder what this means:
> When analyzing the code of one of the apps that received an Apple update, MacRumors could not find what had changed.
Unfortunately, it's put so vaguely, it could either mean the diff showed no code changes - or they were unable to compute a diff, for whatever reason.
If it's the former, that would be a strong indication for certificate issues, I think.
The FairPlay certificate rotation theory makes the most sense. Apple has done silent re-signing before when DRM certificates expired. What's unusual here is the update note surfacing in the App Store UI at all — that's probably an unintended side effect of whatever pipeline they're running this through, not intentional transparency.
hmm, my money is on some actively used 0-day exploit that Apple is sealing shut before the CVE gets announced.
By the looks of the app list, they seem to be apps and games that used to be popular and have fallen in disrepair and apps that are starved of maintenance attention.
On the one hand it could be an exceptionally good example of "stewardship"; on the other hand, if this is true, what if authorities could later compel Apple to manipulate applications in some malign manner?
If you are worried about apple being compelled to do something, then they can do that at the OS level rather than something obvious in the
I think this is simply updating some api call which no longer works properly, coupled with the terrible "changelogs" that are the norm on the app store. Someone down thread mentioned certificate rollover.
A sensible changelog would be "update expired certificate", or "fix integration with ios 26.2", or "patch security issue"
An actual changelog would be "we're bringing you ever more great new improvements"
Here's the latest Audible one:
> At Audible, we're always making updates and improvements to make your listening experience better.
> If you're experiencing issues, please reach out to customer services. For feedback or suggestions contact us at audible.co.uk/help
This is the same every time, because these changelogs are meaningless.
Neither developers nor consumers should be comfortable with this, as this breaks the trust model and is extremely worrying. The site is of course downplaying it given its name, which is a huge shame.
What trust model? Is there anyway to verify that an app from the app store is the same as the one the developer uploaded?
What trust model are you thinking of though? Because another way to look at it is that Apple has pushed an update to ensure these apps keep working and remain secure.
And this is part of the agreement between an app developer and Apple; for a long time now, a developer doesn't upload a full compiled app to Apple, but a package containing partially compiled (itermediary language) code and assets for many different platforms and resolutions, leaving it up to Apple to do the final assembly based on what device it downloads. This allows them to (re)compile for newer hardware, 32 vs 64 bit CPUs, save bandwidth and storage space by only having the device download the assets for its device (and for e.g. games the assets for the level they are playing at that time), etc.
So again, what trust model are you thinking of? Apple is a trusted party when it comes to this, I'd even argue they're more trustworthy than the app developers themselves.
Vast majority of change logs are along the lines of “implements to make things better”
that's proprietary software for you
I saw this the other day in a couple of apps, I've checked other apps and didn't have that, did a quick check on HN frontpage and saw nothing and said wth I'll update to see if something changes in the app or there is a message. Got nothing, and didn't think more about it but I'm not sure why, is it the "trust in the process" thing or what?
Has anyone ever done a proper security audit of VLC that is downloaded from the web? I don't trust it, and the fact that their releases on Github don't include binaries makes me trust it even less. Nobody is compiling VLC from source, and they don't provide any sort of provenance from the GH actions pipeline.
This seems utterly pointless to worry about. You're fucked either way if you trust VLC.
Care to elaborate?
Look at the supported formats lists. It includes so many parsers, mostly written in C, which means there probably are a few dozen ways to exploit the player.
It's downright trivial to hide a backdoor in a codebase like this.
Can you tell us about any prior or active incidents like that though?
That is, I'm calling you out for fearmongering, for a possible what-if, but given how popular VLC is you'd think it would've happened / is actively happening already. And there is no evidence for that.
All linux distros build VLC from source
Speculation for fun: I always thought popular apps can use private apis or are handled in a special way by the OS itself. If yes, perhaps this is related.
Then again I found no source for that - and some certificate rollover seems more likely.
If Apple is distributing modified vlc binaries without releasing the source of the changes when requested, is that a potential legal problem?
As always, it depends; VLC "the iOS app" is not the same as VLC "the binary compiled from source". The article itself says they couldn't find any code changes, and the theories are that a certificate was updated.
I don't believe an iOS distribution specific certificate falls under the license you're referring to, but I'm no expert on these matters.
Could be a fix for per-device asset optimization that got messed up somehow.
FTA: “The update text is appearing on apps that have not been updated in some time, as well as apps that received recent updates, so it's not clear what the apps have in common.”
⇒ I think that’s unlikely. If some optimization got broken that produces results that bad that it has to be fixed, users would have noticed in those apps that “have not been updated in some time”.
This sounds like a bug with the App Store app than a new update actually being installed.
Is it a conspiracy, or just a bug in the app store? Nobody knows.
Well no, people do know. It's not a bug because it's clearly intentional. It's not a conspiracy because that's just vagueposting.