Lukasz Olejnik:
In 2009-2011 we did some research work motivated with a positive aim of educating web users about certain risks of browsing history leaks. The pointed to a perhaps unexpected conclusion. It indicated that web browsing histories may be unique to the user. In our study, the number of unique user fingerprints revealed by observing the set of visited websites was as much as in 97% of cases. Furthermore, such fingerprints were stable over time (in 38% of analyzed cases). We also found that limiting to just 50 most popular sites, the uniqueness was still substantial.
That was the early 2010s. In 2020 the situation is different. Today, user’s private data are processed at an order of magnitude greater scale than in 2010. Fortunately, someone verified that the result holds.
See also: Bruce Schneier (Hacker News).
Previously:
Update (2020-09-07): See also: Hacker News.
iOS Mac Mozilla Privacy Web
Patrick Wardle:
Interestingly, Peter noticed the campaign originating from homebrew.sh, leveraged adware payloads were actually fully notarized! 😱
We can confirm the payloads are indeed notarized via the spctl command (note the "source=Notarized Developer ID")[…]
As far as I know, this is a first: malicious code gaining Apple’s notarization “stamp of approval”.
[…]
As noted, Apple (quickly-ish) revoked the Developer code-signing certificate(s) that were used to sign the malicious payloads. This occurred on Friday, Aug. 28th.
Interestingly, as of Sunday (Aug 30th) the adware campaign was still live and serving up new payloads. Unfortunately these new payloads are (still) notarized[…]
This is discouraging, as OSX.Shlayer is said to be the “most prevalent” Mac malware, yet notarization didn’t catch it. It’s not clear whether Apple was eventually able to adapt or whether new binaries are still being notarized at will. Perhaps the real benefit of notarization is not prevention but rather that it allows related binaries to be found (because Apple can search the previous submissions) and disabled sooner, before they have widely spread.
See also: Zack Whittaker, Thomas Reed, MacRumors, Lily Hay Newman, Nick Heer.
Previously:
Update (2020-09-07): Cedric Owens:
I had similar observations last year when I found that I was able to get my red team apps notarized. I wrote about my steps here. I reported to Apple but not sure if any changes have been made.
Howard Oakley:
Over the last couple of years, a succession of security experts have deemed Shlayer unsuitable for conventional signature-based detection methods, because of its design and frequent evolution. Rapid checks, such as those most probably performed as part of Apple’s initial notarization process, are therefore unlikely to be able to detect it. Most of us had assumed that those brief checks would be followed by slower and more thorough analysis, with triage determining which apps needed to go on for expert human dissection.
Update (2020-09-11): Phil Stokes:
But Shlayer has been up to other tricks since June of 2020 that have been helping it avoid the static signatures employed by most vendors. Although bypassing Apple’s Notarization checks is obviously a headline grabber, this new variant of Shlayer utilizes heavily obfuscated Zsh scripts and is in fact far more prolific in the wild. Let’s take a look at how this new variant works.
Code Signing Mac macOS 10.15 Catalina Malware Notarization Security
Apple (also: Hacker News, 9to5Mac, MacRumors):
The App Store is dedicated to providing a great experience for everyone. To continue offering a safe place for users to download apps and helping you successfully develop apps that are secure, high-quality, reliable, and respectful of user privacy, we’ve updated the app review process as announced at WWDC20. For apps that are already on the App Store, bug fixes will no longer be delayed over guideline violations except for those related to legal issues. You’ll instead be able to address guideline violations in your next submission. And now, in addition to appealing decisions about whether an app violates guidelines, you can suggest changes to the guidelines.
Will Strafach:
guideline challenge successful! ✅
to
@guardianiosapp
users: Day Pass capabilities will indeed live on in our upcoming v2 update.
I am unsure when the text of the App Store Guidelines will be publicly updated on this matter, but keep an eye out.
[…]
I don’t know how the app review process goes internally, but it seems like they could not wrap their heads around a time-based purchase which did not use IAP’s subscription system’s built-in time intervals.
that was what we challenged.
Curtis Herbert:
I was rejected when I launched my day pass in 2016. Since I have the concept of recordings, I worked around by renaming to a “single pass” that unlocked a recording. Later moved to a bundle of single passes. Always called it day pass externally, but in app it was the single pass.
Paul Haddad:
Now that Apple is saying you can appeal guidelines rejections wonder if it’s time to try fighting the one that requires Pastebot’s paste service.
Jeff Johnson (tweet):
My update, which has a new feature but no bug fixes, is currently in limbo because the reviewer is getting mysterious proxy connection errors that no customer of mine has ever reported.
I saw another developer today say their app was “rejected” because the reviewer asked “How does the app utilize Touch Bar and where can we locate these features?”
This kind of crap happens all the time, and I don’t see anything in this announcement that will help.
This is apparently common.
Previously:
Update (2020-09-11): Apple:
Bug Fix Submissions: For apps that are already on the App Store, bug fixes will no longer be delayed over guideline violations except for those related to legal issues. If your app has been rejected, and qualifies for this process, please use the Resolution Center to communicate directly with the App Review team indicating that you would like to take advantage of this process and plan to address the issue in your next submission.
So the bug fix won’t be immediately accepted, but hopefully the delay for this process won’t be too long.
Update (2020-09-14): Hobbyist Software describes how its update to fix a crashing bug was rejected because of an issue with a pre-existing app preview video. The app displays wallpapers across multiple monitors but isn’t allowed to show multiple monitors in the video. As there is no legal issue, the app should be eligible for the new bug fix policy, but App Review at first didn’t want to allow this. They finally agreed, and then it took an additional 68 hours before the bug fix was approved.
Update (2020-09-30): Jeremy Provost:
What Apple told developers on August 31st, 2020 was: “For apps that are already on the App Store, bug fixes will no longer be delayed over guideline violations except for those related to legal issues.” This seems like a very clear statement. Get App Review on the phone and they’ll tell you a different story. According to them bug fixes are not allowed for “legal issues” (makes sense), “user safety issues” (we would whole-heartedly agree), but here’s the kicker, and anything else that App Review on a case-by-case basis decides not to allow as a bug fix update.
Update (2021-08-13): Peter Steinberger:
Apple App Store randomness: After 3 years of having
@pdfviewerapp
in the store, Apple now rejects it because they can’t figure out how to add an image to a PDF (which requires the camera entitlement).
How’s that process still so bad. A month ago it was another random entitlement.
So much for Apple not holding up random patch releases.
Tanner Bennett:
Apple: what if we just… lied? Tell everyone we won’t hold up their bug fixes anymore or something. We don’t have to actually do it
Mauro Vime:
I’ve also seen a trend of rejections around long-lasting features in patch releases rather than in minor/major ones.
Update (2022-01-17): Robin Kunde:
Apple’s App Store review is currently holding up a bug fix release because we didn’t include a video preview? Citing a guideline that doesn’t mention videos at all?
Actually, they want a demo specifically for the reviewer because apparently the app is too complicated?
Update (2022-01-19): Robin Kunde:
Follow up to the bug fix release: I asked about the accommodation, got a vague reply along the lines of “that’s a policy we have, yes”, resubmitted, and got rejected again for the same reason. Ended up having to delay the release to make that video.
Update (2022-05-31): Jeff Johnson:
My Mac App Store update spent 3.5 hours In Review and is now Pending Developer Release. My identical iOS App Store update has been In Review over 44 hours and counting.
[…]
Third, Apple claimed that they wouldn’t hold up bug fixes for unrelated issues[…]
[…]
This claim does not appear to be true. I’ve heard from a number of other developers who have said that their bug fix updates still get held up over other issues.
Unfortunately, I think Apple only meant it wouldn’t reject bug fix updates for unrelated issues. I and others have had bug fix updates stuck “in review” for over a month.
Update (2022-06-06): Trystan Kosmynka (tweet):
The bug fix submission process is very real. When the app update is submitted it goes through the regular review. In the event a reviewer finds an issue with the app, they will notify the developer. The top of that message indicates that if the issue is with a feature that is already live in the app the developer can elect to have the app processed and resolve the issue on a future submission.
With so many conflicting reports, it’s not clear to me that this is actually the case.
Jeff Johnson:
As I mentioned last week, “there’s actually no way for a developer to contact the reviewer while the app is In Review.” My bug fix release was delayed for days with no explanation whatsoever. Furthermore, Apple’s process still delays bug fix updates even if “the developer does choose to have the app approved and resolve on a future submission.” This is because the approval process is interrupted when App Review flags an issue with a preexisting feature in the app.
Update (2024-03-20): Marcin Krzyzanowski:
remember when apple promised to not reject bugfix updates to the AppStore? oh
manabiSRS:
The other day Apple said I had to fix my bugfix update (they could see the crash stats) bc screenshots from a year ago had the word “free” in one of them. Said I could reply and ask for approval if I wanted to remove the word after hotfixing. They ignored my reply.
Update (2024-09-10): Matthias Gansrigler:
Hey, App Review, how about you stop holding my minor critical bugfix update for
@ScreenFloatApp
hostage “In Review” and just release the darned thing already? Sound good? Then I can get back to my business.
No feedback, no progress update, nothing - really unprofessional.
Sindre Sorhus:
I had the same happing too a month ago. I had a bug that caused a crash on launch. Was in review for a week. Super annoying.
App Review App Store App Store Review Guidelines App Subscriptions Entitlements In-App Purchase iOS iOS 13 Mac Mac App Store macOS 10.15 Catalina Touch Bar
Howard Oakley:
There’s one big snag with Catalina’s ingenious linkage of System and Data volumes into a Volume Group: when anything goes wrong, the only option seems to be to wipe them both and start again. I’ve heard of a steady succession of users who’ve been caught by this, most commonly when trying to re-install earlier releases of Catalina.
[…]
Apple doesn’t provide a full suite of maintenance and repair tools for APFS and its volumes. Third-parties have been prevented from doing so because Apple has still not provided documentation more than a year after developers first started using macOS Catalina. All this changes again with the arrival of Big Sur and its Sealed System Volume, where the contents of the system are contain in a special snapshot which is cryptographically sealed and mounted read-only. I can see a lot of users having to perform repeated clean re-installs of macOS 11.0 because there are simply no other options.
Howard Oakley (Hacker News):
Apple has long taken pride that “it just works”, but seems to have convinced itself that is inviolate fact, and has become unable to consider what happens when it stops working.
The long-running saga of failed EFI firmware updates is a case in point.
[…]
Indications are that Catalina’s boot Volume Group was designed without consideration of maintenance procedures which could address that type of problem, and the current solution has only evolved during Catalina’s release cycle, in the last few months.
[…]
Once again, no one seems to have considered the problems which can be caused by orphaned snapshots, so they’re a key macOS feature which is essentially unmaintainable by macOS and its supporting toolset.
Update (2020-09-02): See also: Accidental Tech Podcast (John’s Mac Pro Tale of Woe).
Apple File System (APFS) Apple T2 Bug Mac Mac Pro macOS 10.15 Catalina Time Machine
