I just love the apple response mail to the guy who disclosed this to them:
"We have forwarded your feedback to the appropriate team. Someone from that team will investigate and follow up as needed with the developer.
Because we can only share communications about an app with its developer, you will not receive updates about this matter."
It's the perfect email, they can do whatever they want, and they have an excuse why they don't need to account for it - they could let the app do whatever it want, demand it to change it's behavior or throw it out, but the one who spent considerable time researching this would never know.
Apple's lack of transparency is one of my biggest problems with them. I refuse to ever file bugs with them since I know I won't get any meaningful updates.
Similarly, I often report problems on Google Maps since they actually send email updates about your report and tell you when it's fixed, whereas I never do with Apple Maps since they don't provide any feedback.
> I refuse to ever file bugs with them since I know I won't get any meaningful updates.
Having your bug get fixed is perhaps the most meaningful update possible, and that's the one you'll never get if you don't file bugs.
I get your pain, I really do. I've filed many hundreds of bug reports with Apple. And many of those never got updates, or (more often) got a single update telling me it's a duplicate. It sucks to spend a bunch of time compiling a bug report only to be told that it's a duplicate.
But many of the bugs actually got real feedback, and many of them got fixed. Sure, if I hadn't filed those bugs, maybe someone else would, so some of those would have gotten fixed anyway, but maybe not as fast, and a bunch of them probably wouldn't have been fixed at all simply because most people don't get around to filing bug reports.
The perception of radar outside the company is definitely something they are aware of. Like everything else associated with the system, they aren't very transparent about what they are planning to do to fix it long-term ;-)
However, internally they use that bug tracker for everything. If it isn't in there as a bug, it likely isn't on the "radar" to be fixed.
BTW, it is unfortunate they don't make public views of bugs available (a la openradar) but if you have an issue impacting you marked as a duplicate, it is not closed. You can both amend your issue with new information and you can request updates on the status of the primary bug.
Worse. I've filed bugs with Apple, and then upon discussing them on Apple public lists, get accused of violating my NDA. As if reporting the bug makes the bug subject to secrecy. IANAL but if that's really true, then yeah, why bother filing bugs?
Nice, they must have added that since launch. I tried providing feedback years ago when it was still new and the feedback seemed to go into a black hole.
I can't get the video links in the tweet [1] to open? Unless I fat-fingered all 3 of them. Either the guy doesn't want to be accused of not following proper disclosure procedures, or he was somehow asked to remove them?
The court of public opinion is fickle, loves to conduct witch hunts, is easily swayed by lies, and is mostly just a reflection of the biases of the participants.
What court isn't? Even a single real judge is biased, and will judge the same case differently according to what time of the day it is, or if their favorite sports-team is on a winning or losing strike[1].
The power of the court of public opinion is, that everything (hopefully) gets revealed instead of being confined to the opinion of a few select.
[1]: This is mentioned in Hello World by Hannah Fry[2]
That they could act in an even worse manner doesn't make the policy any better. Nice that they gave Privacy 1st a "receipt". Would be better if they had some conclusion to provide.
I can think of lots of ways that the policy could be better, but that's not the point I was bringing up... I was pointing out that this sort of complaint is why most corporations say basically nothing in these kinds of emails.
Ahh, fair enough. I get what you're saying. A non-existent reply can't be analyzed at all, whereas their limited acknowledgement is a "thing" that can be criticized. Basically, why even bother to give critics an artifact to coalesce their criticism around? At least Apple is being upfront with their policy, instead of ghosting on the reporting party.
The problem is your average user only sees glowing reviews of ES File Explorer on the Play Store. They do not care to search for information about the data egress to Chinese servers, and are lulled into a false sense of security by the Play Store itself, which claims to 'verify' all apps on it.
Are you saying everyone is aware about those things?
I for one never use a Chinese app or an app that was bought by a Chinese company ever again (sorry, Opera). But I doubt 99% of the users even realize who owns these apps.
Yuck. I installed that a while back to ease dealing with some local files on the phone for some testing, and it's been sitting on there for a while. Uninstalled, since regardless of whether it's true now, it could be true in the future, and an app not used is both an app not needed and a security hole waiting to happen at this point.
Don't use Roku if you care at all about privacy. Their privacy policy specifically calls out that they do visual content identication on everything you watch and sell that to anyone and everyone they can.
I have Kodi on my Android set top box, but as far as I can tell, when I insert a USB drive into the set top box, Kodi cannot see that drive, some other program has to mount the drive to the android file system and this is what the explorer program does.
Depending on how big the files are, you should look at the file system format of the USB drive. I have come across this issue with NTFS formatted drives, but I personally don't know of an automounting solution that supports files larger than 8gb.
I still can't believe android doesn't have a native file explorer. The fact that you need to install a 3rd party addon for such an essential feature boggles me. I can't read a PDF without a file explorer.
I currently use Solid Explorer due to ES File Explorer's shadiness
Android has had a built-in file explorer for about three years now.[1] It's actually pretty good! I haven't had the need to download a third-party one since Marshmallow.
Wow, I did not know that. Thanks for the heads up. I even keep up with security stuff. I don't ES File Explorer any more because I don't really do specific file management on my phone. That's disturbing.
It's the sad state of affair in "trusted" App Stores. Little Snitch is the first app I install on every machine. I look forward to a day when network access becomes a permission a sandbox app asks for.
Sadly, I don’t see Apple making any moves in this direction, probably because advertising is an extremely popular form of revenue these days. It’d be rather awkward explaining why they enable these controls on the computer but they don’t allow them on iOS.
But honestly, I hate ad supported software. Either give me away to remove ads via an in app purchase or I’ll just delete the app.
I bought an iOS device partially because I prefer the simple transaction model of giving Apple money and they give me stuff without subsidizing the purchase price with ads and invasive tracking.
Many “VPN apps” for iOS don’t do anything special except for automatically configuring VPN settings. As the article above stated, you can do the same thing manually by going to settings.
The VPN providers can sell services off the App Store and document the manual setup process.
It is sandboxed from filesystem access, but as soon as it is launched, it asks the user for permission to access their home directory.
Really this is just an indictment of old-school massive deep tree file organisation, and of Unix file permission being too coarse-grained for what are effectively single-user computers.
While I agree in principle, in this case I'm not sure any permission system would help. An anti malware program has legitimate reason to access the internet. It also has legitimate reason to read files. Heck it may even have legitimate reason to upload some of that data for analysis. Those first two capabilities are very hard to keep separate (you'd need one process for each capability and a very tight restriction on interprocess communication). The third is game over.
I think ultimately the problem is more about trust and oversight.
The type and destination of the network request would be useful to block/allow as necessary, ala little snitch.
However, IMHO AV software should be reviewed as such. They clearly didn’t do this. What is the point of the app store? It seems to be a proxy into sandboxing, but it’s hardly useful if there’s no review that the sandbox is effective, and the sandboxing would be more useful decoupled from the app store so that you can sandbox arbitrary apps. If the controls are there, it’s not obvious.
I wonder if there's any chance of improvement of that under linux. Only chrome needs access to my chrome data directory. It also doesn't usually need access to anything outside it. There's not that much use of solid security preventing apps from gaining the root access when all my sensitive data is accessible from my user.
> Only chrome needs access to my chrome data directory.
This is changing in macOS Mojave so that databases for things such as email and contacts are inaccessible except through the proper APIs, which present a prompt asking for access.
Qubes OS (https://www.qubes-os.org/) seems relevant: that sandboxes every application into its own VM. It's a hell of a brute-force approach to application isolation, but I guess it's the most robust strategy available.
Firejail is a sandboxing tool that does this (and also restricts access to other things), and it supports many popular programs out of the box. I’m going to say it supports Chrome because I know it supports Firefox.
So which am I suppose to believe - a random story on HN or an existence proof that I have half a dozen apps on my iOS device that do exactly what the poster said his app was rejected for?
> an existence proof that I have half a dozen apps on my iOS device that do exactly what the poster said his app was rejected for
Well, since the HN story doesn't rely on the fact that no other apps exist with that capability, and actually uses that fact to make its point, I'm not sure what you're trying to use their existence to prove.
"since other apps still get to do this, it's clear the policy change message was BS."
It was never policy. There have been lots of cases with further investigation that there was more to the story. Why would Apple single out his app?
The post said
Since other apps still get to do this, it's clear the policy change message was BS. I've suspected a lot has had to do with Apple's ambitions in the streaming space and their desire to be in a position to offer bundling and other over the top services.
There are literally dozens of cross platform streaming apps on iOS. There has been no policy change. Apple would be more than happy to take a 30% cut on a cross platform streaming service.
> There are literally dozens of cross platform streaming apps on iOS. There has been no policy change.
So, your argument is that because some apps exist now with this behavior, the claim that some apps do or did experience unwarranted attention and extra requirements for non-policy and technical reasons must be false? I'm not sure I follow that reasoning.
I’m saying that if I have a choice between believing knowing that cross platform streaming apps that require a login and that have IAP have existed since 2009, continue to exist in 2018, there is no published policy against it, and the only place where we have seen this is one post on HN, I’m more likely to believe that there is more going on.
I’m definitely not willing to believe that he was singled out because Apple wants to build thier own streaming app seeing that they will already be competing with dozens of other providers on thier own platform when thier streaming service comes out.
If you want to assume that since there's no policy against it, and there exist apps that utilize it, that Apple would not for bureaucratic or internal politicking reasons cause problems in the review process because you've only ever heard of this story, that's definitely your right.
I believe that due to the numerous stories I've heard about the review process arbitrarily holding up some apps and not others, since they very beginning, and the fact that I believe large companies have lots of internal politicking and divisions competing and managers pulling rank to affect outcomes that the app review process is not always purely policy and technically driven, especially since there's essentially no negative consequences to apple for being arbitrary.
I think we just have differing view on the likelihood of certain outcomes and how they combine into a likelihood of the specific outcome in question, so we'll probably just have to agree to disagree.
I have never heard Apple praised for rapid pace of change in their software but there's a first for everything! In fact IMHO they lack behind everyone else and live by taking what others do, brush it up a tad and sell it as the best new amazing feature ever made.
Oh noes, you have to have the platform from the company to make apps for the platform from the company. The horror.
I honestly cannot take seriously any complaints about having to have a Mac to make Mac apps. How on earth are you testing if you don't have the platform you're supposed to be targeting?
Well, with regards to iPhone development at least, it's not that you're buying the platform you're targeting, it's that you have to buy a specific separate piece of hardware, running a specific separate software OS, which are not the same as the target platform, to develop for it. An then, as the GP notes, you have to keep updating them for reasons unrelated to the targeted platform.
I mean, I understand having to have a Mac to develop for a Mac, but having to have a Mac to develop for iPhone is just Apple being Apple.
Maybe because you already have a Mac? If you had to buy a NeXT workstation to develop for it, that might feel a bit different then though, right? It's only a slightly different proposition. Sure, a lot of people already have Macs, but it's not really that hard to make the software work on other operating systems. Apple just doesn't care to to make it cross platform, and also makes more money and solidifies their market by requiring Macs.
> Oh noes, you have to have the platform from the company to make apps for the platform from the company. The horror.
Useless snark.
> I honestly cannot take seriously any complaints about having to have a Mac to make Mac apps. How on earth are you testing if you don't have the platform you're supposed to be targeting?
The point is that you don't have to buy dedicated hardware for the other two big platforms (Windows, Linux). The fact that this restriction is essentially arbitrary makes cross-platform developers reasonably annoyed.
I don't think any app review process is more than theatrics. Google, Apple or Microsoft. There's too many programs with too much code with too many places for malicious code to hide.
The programs allegiance is always with the people who write it (exploitable bugs aside). Either you trust those people with the permissions you give them or you don't give them those permissions. How can Apple know who to trust? How can the end user?
Well, they want a share the developer p&l by forcing them into an app store, they get to share the blame for what those developers do. After all when you buy an app from them, you pay apple, not the developer.
With sufficiently robust and constrained permissions, it wouldn't be out of the realm of possibility to offload the process to trusted third parties. If I could subscribe to Consumer Reports App Review, which was an app that itself was given some access to see binary signatures of installed applications, a robust third party review ecosystem could develop.
If applications were also given the capability to subscribe minimally to resources they require (e.g. this app will access foo.example.com, and bar.example.com, and otherwise interact with registered sharing handlers through the OS), etc, we could be a lot more assured of an application not secretly spiriting away our data, at least if we cared to pay attention.
Alas, neither app store is willing to throw away the billions of dollars in app sales they make, so while we might get more granular permissions over time, we'll likely never be allowed out of our walled gardens. "For our own good", of course.
>If applications were also given the capability to subscribe minimally to resources they require (e.g. this app will access foo.example.com, and bar.example.com, and otherwise interact with registered sharing handlers through the OS), etc, we could be a lot more assured of an application not secretly spiriting away our data, at least if we cared to pay attention.
After which apps will get an update where they first send your data to app-website.com where their own servers will secretly spirit away your data
That's why binary signature capability is important, and why very granular permissions are required. Any application that has even the capability to execute remote code should be precluded from getting the best ratings, and come with a disclaimer from the ratings company. It's hard, and people will try to game it, but at least you have a company that is incentivized to try to solve the problem because it actually matters if they do a bad job, instead of a monopoly (within that market) doing so with almost no repercussions if they do it poorly.
That is the way the rest of the world works, and it does so fairly efficiently and successfully, so yes.
That's how stock ratings work, to my understanding. There are problems, of course, but for the most part, it works out. If any one ratings company does a poor job, they lose public trust, and another one is always ready to compete. In the current setup, Apple is the ratings companies for their platform, and if you don't like the job they do, sucks to be you if you want or need to use Apple for some reason.
I just started looking at making a browser extension for Safari and it's insane compared to every other browser AFAIK, one has to make an app and submit it to the app store for approval.
The truly insane thing is that Safari's original extension mechanism was close to the model used by other browsers, was more capable than the API that replaced it, and was totally free and open to develop for. Apple intentionally killed their small but growing extension ecosystem in favor of more-limited, native code, App Store-only extensions that require a yearly developer subscription to write.
It's not explicit enough for dummies like me, but the Safari extensions gallery is the Safari browser extension app store equivalent (available in browser) and one can submit the app and include the extension for publication in the app store and the extension gallery at the same time it appears (haven't tried or gotten that far yet).
"You can sell and distribute your apps with Safari Extensions to customers worldwide on the Mac App Store. To submit, sign in to App Store Connect. For information on creating Safari Extensions for the Mac App Store, see the Safari App Extension Programming Guide."
The app review process is security theory. I blame the sand boxing mechanism that allows a Mac App Store app permission to an entire folder. That permission is inherently unsafe.
If an app needs that type of permission on the Mac sell it outside of the App Store.
Can we talk about this problem? Amazon gets a lot of attention for questionable reviews but Apple hardly gets any backlash from consumers or the media.
Ratings and reviews help people make informed decisions when considering whether to try out your app. Positive ratings and reviews can mean more downloads of your app, and customer feedback gives you insight into real world usage that helps direct future development efforts.
Delivering a great overall experience is the best way to encourage positive ratings and reviews, but it’s also important to ask for feedback at appropriate times. Keep these considerations in mind when asking people to rate your app.
Ask for a rating only after the user has demonstrated engagement with your app. For example, prompt the user upon the completion of a game level or productivity task.
Nowhere on that page are there any prohibitions against asking for five-star or positive reviews, and indeed, it's quite easy to find examples of high-profile apps asking for five star reviews, including Amazon (see example on the bottom of this page: http://leanmedia.org/amazon-removes-reviewer-emails-profiles...).
It's not hard to see the damage done by inflated or bogus user reviews: The unwary are more likely to download them, as is the case for this top-ranking utility sending browser history back to China.
Search for "app store review farm" and you'll see how easy it is to fake reviews. Apple's system is sufficiently advanced to prevent people from doing it in a fully automated way, so it's done with the manual version of click farming. Basically the same idea as paying somebody to farm gold in a MMORPG. Trust nothing.
Probably less expensive to buy 40 base-model iphones of whatever is the least expensive that can run the latest iOS, and pay a click worker to farm it. Something like $16000 USD one-time cost, plus salary, and once the phones are so obsolete that they can no longer install the app, figure you can wipe and resell them for $80-100 each.
So long as the cost to post a review is less than the reward, abuse will continue. The more a company polices reviews and/or verifies legitimacy, the higher the "cost" of the review.
The value of the review can be diluted by encouraging reviews from actual users. Here, however, the user can't review behavior that is concealed.
This is the problem with all review systems. The cost to post reviews is close to zero, and the value of a good review is non-zero. Retailers are yet to find a reliable way to distinguish real from fake reviews, and they have little incentive to do so: no matter how bad the problem is, consumers still inexplicably trust online reviews, so why change?
This has nothing to do with users coming from Windows. Mac users aren't smarter than users of other OS's. Windows 10 with a walled garden like Apples is safer than a Mac.
This isn't a matter of Mac users being "smarter"–it's just that most Windows users are accustomed to running antivirus software on their computers, and when they come over to macOS they tend to bring this over to macOS.
Thank you to all the security researchers out there reporting this stuff. Keep the bad press flowing, so apple doesn’t get too lazy and let even more of these through...
That seems better in theory than practice - Apple didn't detect the behavior (though it violates their dev TOS), I would think the users whose browsing data was exfiltrated will not feel especially secure.
I don’t expect Apple to catch behavior. What I would expect is that an app on the App Store never be given permission to a users whole home directory - only a sandboxed area for the app to store files. If a user wants to open files somewhere else, the app should open a file picker where the user explicitly allows access to that file.
I assume that's what happened here. The app says "I need permission for your home directory" and the user selects the home directory from a file picker, giving access to everything in it.
DaisyDisk's App Store version has similar sandboxing limitations and a similar workaround. It's an app designed to scan your whole hard drive and show you how your space is used, but by default it doesn't have permission to access the drive at all. So to run the first scan you have to indicate to the OS that you want the application to be able to read your hard drive, IIRC by dragging and dropping the volume onto DaisyDisk.
For an antimalware app, of course users are going to grant it permissions. There's no point in buying that if you're going to keep it in a sandbox where it can't look at your system.
I would expect something more like iOS. Where you can only choose a file not a folder.
True that will limit what types of apps can be distributed on the Mac App Store. But I am okay with that. On the Mac, they can distribute their app outside the store. I would love to be able to tell my mom. Don’t trust any app outside of the store and make it hard to download outside of the store.
That's pretty close to what they have today. Apple started enforcing sandbox restrictions in apps distributed via the Mac App Store, and opening an app downloaded directly from the web takes more effort than it used to.
To be fair, while I stand by my criticism of their lack of oversight, having an App Store model does make a fix much easier to roll out. If this was a piece of malware that was just installed manually, it'd take an OS security update to address, which presumably wouldn't happen in hours (or even days).
Uh, isn’t it widely known that every character you type in the address bar in chrome is sent to google? They wouldn’t be able to give you autocomplete results otherwise.
Are you talking about “Help make Google Chrome better by automatically sending usage statistics and crash reports to Google”? Because that’s not what I am talking about. Even if you turn that off, autocomplete still works in the location bar. Type “h”, it offers to complete “Home Depot”, “Hotmail”, “Huntington Bank”, “Hurricane Florence”, and “Hungry Howies”. It does that by sending the character “h” to the google servers and getting back a list of results.
> The next release of macOS, macOS Mojave, will protect content like Safari History or cookies from apps, even those to which users have granted access to their home directory.
From my own experimentation in Terminal.app in Mojave, ~/Library/Safari is unreadable without granting permission, but I can read everything under ~/Library/Application Support/Google just fine.
Probably Apple should expose a way for applications to register their data to be included in the protected data set.
Apple is a terrible choice for gatekeeper because they stand to benefit from any app becoming popular, regardless of why the app has become popular. Gambling-inducing gem scams and apps with fake reviews do just fine and earn Apple 30% at the expense of users so Apple certainly loses money in the short term if they refuse those apps entirely. Apple also gains when they can brag on stage about how many bazillion apps there are on Apple platforms; scam apps are generally quite numerous (probably because it’s easier to come up with a bunch of crappy apps than a single good one) so they’re sort-of-OK with having lots of “apps” that no one should really be installing. A really tiny list of outstanding apps would be hard to sell on stage.
The only real impact on Apple’s bottom line would be for the entire store to become so infested, relative to competitors, that people jump ship and stop buying expensive Apple hardware out of frustration. Apple is at least observant enough to avoid that; they’ve kept their store clearly better than competing stores but none of them is necessarily a great experience.
I strongly suspect that the convenience of payment processing is the primary reason for developers to put up with Apple’s too-random screening systems. If Apple were required to open up app payment processing to any number of payment services, and if they were relying on trusted 3rd parties to certify apps (perhaps based on category), we would see a very different app experience.
Distributing reviews to different authorities would also be hard. For example, if you had “security experts” handle screening for apps in a certain category, somebody could just write a sneaky app in a different, weakly-reviewed category to make it through the net into the store. Apple would almost have to create secure subsets of their entire API in line with app store categories, e.g. “you can’t even use network-access APIs for apps in this category” would be a very useful restriction. The other nice thing about this is that Apple would finally be free to not need certain expertise in-house; e.g. if you don’t have enough good people on staff who are qualified to assess the security risks of an app but you can find a trusted 3rd party that can, you can hire them to be that trusted authority and we can stop assuming that Apple is the best at handling everything by itself.
"We have forwarded your feedback to the appropriate team. Someone from that team will investigate and follow up as needed with the developer.
Because we can only share communications about an app with its developer, you will not receive updates about this matter."
It's the perfect email, they can do whatever they want, and they have an excuse why they don't need to account for it - they could let the app do whatever it want, demand it to change it's behavior or throw it out, but the one who spent considerable time researching this would never know.