iOS App Update Technique Puts Users At Risk (csoonline.com)

← Back to Stories (view on slashdot.org)

iOS App Update Technique Puts Users At Risk (csoonline.com)

Posted by timothy on Saturday January 30, 2016 @01:28AM from the key-under-the-doormat dept.

itwbennett writes: An increasing number of iOS application developers use a technique that allows them to remotely modify the code in their apps without going through Apple's normal review process, potentially opening the door to abuse and security risks for users. An implementation of this technique, which is a variation of hot patching, comes from an open-source project called JSPatch. After adding the JSPatch engine to their application, developers can configure the app to always load JavaScript code from a remote server they control. This code is then interpreted by the JSPatch engine and converted into Objective-C. 'JSPatch is a boon to iOS developers,' security researchers from FireEye said in a blog post. 'In the right hands, it can be used to quickly and effectively deploy patches and code updates. But in a non-utopian world like ours, we need to assume that bad actors will leverage this technology for unintended purposes.'

67 comments

Min score:

Reason:

Sort:

Brought it on themselves by jareth-0205 · 2016-01-30 01:35 · Score: 3, Insightful

I have to think that Apple have brought this kind of thing on themselves - their ridiculous app approval system is uncertain and slow and developers are obviously going to try to find a way round it. If I find a bug in Android I fix it and release it. My iOS counterparts often have to live with the bug for weeks before they release because of the faff of the approval process.
1. Re:Brought it on themselves by tepples · 2016-01-30 02:22 · Score: 3, Insightful
  
  You could distribute your app as source code under a free software license and allow iOS device users who also own a Mac to install the fix right away. Since Xcode 7, Apple has stopped requiring each individual user to buy a $99 per year developer license just to test an app compiled on his own Mac on his own iOS device.
2. Re:Brought it on themselves by Anonymous Coward · 2016-01-30 02:45 · Score: 0
  
  Amen.
  I once had a phrase missing in the description about GPS usage increasing battery drain. A 5 second fix, but it took Apple 3 weeks to approve it.
3. Re:Brought it on themselves by Anonymous Coward · 2016-01-30 03:47 · Score: 0
  
  Amen.
  I once had a phrase missing in the description about GPS usage increasing battery drain. A 5 second fix, but it took Apple 3 weeks to approve it.
  GrumpyCat: "Good!"
  Maybe next time you'll budget for quality control.
4. Re:Brought it on themselves by gstoddart · 2016-01-30 03:51 · Score: 4, Insightful
  
  By the same token, I'm not going to trust an app which decides it's going to silently update itself without telling me.
  I think it's high on the "software-asshole meter". It says "we'll do anything on your device we choose", and I'm sorry to say, but it's my fucking device.
  And since this has huge potential for security exploits and other malicious acts, it's a big risk for users that may not even know it's there.
  I'm pretty sure unless you explicitly set Android to automatically update stuff your fix isn't going to get pushed to my device without me knowing it ... and enabling auto-updates is something Microsoft and host of others have demonstrated is idiotic.
  Because you really can't trust people who expect to just do a quick fix when nobody is looking. Because in my experience that usually means the software was poorly tested and pushed out the door.
  Apple app approval may be "ridiculous" to you, but it beats the alternative of malware, or poorly thrown together code.
  Boo hoo, you need to wait weeks ... software cycles used to be FAR longer than that, and overall quality has suffered. Because people expect to push out a steaming turd every few weeks and call themselves agile.
  I view software which bypasses approved update mechanisms and just does it in the background as little more than trojans and malware.
  
  --
  Lost at C:>. Found at C.
5. Re:Brought it on themselves by Duckman5 · 2016-01-30 04:01 · Score: 2, Insightful
  
  You could distribute your app as source code under a free software license and allow iOS device users who also own a Mac to install the fix right away.
  Please tell me you're kidding. These are iOS users we're talking about. They have purposely chosen the "easy to use" OS (even with all its limitations). Like hell you're going to get them to figure out how to compile an app
  Not only that, in order to run XCode you need to have a Mac. You just went from a $200-$600 investment in the iPhone/iPad and added a thousand dollars to it. There are no shortage of iOS users with Windows machines who like their iDevice but aren't ready to make that leap to a Mac.
6. Re: Brought it on themselves by _merlin · 2016-01-30 04:19 · Score: 2
  
  Well you thought wrong. Google Play Services automatically and silently updates itself with no user interaction. The only way to stop it is to disable it completely, but this also breaks that use its APIs. Most Android apps don't/can't update update silently, but Play Services definitely can and does unless you go out of your way to stop it.
7. Re:Brought it on themselves by Anonymous Coward · 2016-01-30 04:27 · Score: 1
  
  Yep, that's a totally realistic solution.
8. Re:Brought it on themselves by macs4all · 2016-01-30 04:48 · Score: 2
  
  Apple app approval may be "ridiculous" to you, but it beats the alternative of malware, or poorly thrown together code.
  This. EXACTLY this!
  
  I hope that Apple changes the iOS App Store approval process to look for this insanely-dangerous BACKDOOR, and make the inclusion of that cause for instant REJECTION of the App.
  
  Just like with Encryption backdoors, there is NO WAY this won't be exploited in 3...2...1...
9. Re:Brought it on themselves by tepples · 2016-01-30 04:49 · Score: 3, Insightful
  
  I'm not kidding that it's possible. In fact, several developers of iOS apps that do things forbidden by the App Store Review Guidelines, such as classic game console emulators or WLAN troubleshooting apps, have chosen this route of requiring a Mac for installation. But I agree with you that it's unrealistic for the majority of users.
  
  and added a thousand dollars to it
  The last time I checked Apple.com, a Mac mini started at 499 USD plus tax. Where do you get this "thousand dollars", unless you live in a country whose dollar happens to have such an exchange rate with the USD?
10. Re:Brought it on themselves by jareth-0205 · 2016-01-30 05:05 · Score: 1
  
  Amd software has far less budget than it used to, and people expect more and quicker and cheaper. I'm not sure how you expect to vet every app update anyway, it's not like you could vet the original code so what really can you say about updates. Software used to have long release cycles. It also used to cost 10s of dollars, and have testers. Your average $1 or free app is not gonna be able to do that.
11. Re:Brought it on themselves by Anonymous Coward · 2016-01-30 05:11 · Score: 0
  
  The last time I checked Apple.com, a Mac mini started at 499 USD plus tax.
  I suppose the users are going to use some combination of telepathy and telekinesis to use that computer without a keyboard, mouse and monitor? Not to mention the router and other network hardware and ISP costs they'll incur while trying to get the thing onto the internet to download a compiler and the source code.
  Fortunately, people's time isn't worth anything, right? No cost there as they spend days or weeks (depending on their pre-existing knowledge) trying to figure all this shit out and make it work.
  Yep.. "Do it yourself" is such an awesome solution. It's a good thing we have open-source jerkoffs around to propose it every goddamn time there's a problem.
12. Re: Brought it on themselves by Anonymous Coward · 2016-01-30 05:30 · Score: 0
  
  Apple also has a process for expedited reviews for critical bugs, a process that is quite fast. You do, however, only get one of these. After that, you are politely rejected for expedited review. Lesson learned: test thoroughly and don't cry wolf.
13. Re:Brought it on themselves by Fnord666 · 2016-01-30 05:31 · Score: 3, Insightful
  
  I hope that Apple changes the iOS App Store approval process to look for this insanely-dangerous BACKDOOR, and make the inclusion of that cause for instant REJECTION of the App.
  I'm curious when exactly they changed their policy in the first place. Apple used to reject any application that tried to do anything like this.
  
  --
  'The tyrant will always find pretext for his tyranny.' - Aesop's Fables
14. Re:Brought it on themselves by Duckman5 · 2016-01-30 07:39 · Score: 1
  
  The last time I checked Apple.com, a Mac mini started at 499 USD plus tax. Where do you get this "thousand dollars", unless you live in a country whose dollar happens to have such an exchange rate with the USD?
  To be quite honest, I didn't even know that Apple even offered the mini anymore. I don't really shop Apple very often.
  I think that's a bit of a strawman, though. You could just as easily suggest that someone buy a used or refurb unit. The point still remains that it's unreasonable to expect people to invest in an entirely new computer, learn to use it, and learn how to use XCode just to run an app on their iDevice.
15. Re:Brought it on themselves by macs4all · 2016-01-30 07:40 · Score: 1
  
  I hope that Apple changes the iOS App Store approval process to look for this insanely-dangerous BACKDOOR, and make the inclusion of that cause for instant REJECTION of the App.
  I'm curious when exactly they changed their policy in the first place. Apple used to reject any application that tried to do anything like this.
  I would bet they haven't changed their policy. This is either a b.s. Story, or something that has slipped past Apple (until now).
16. Re:Brought it on themselves by Anonymous Coward · 2016-01-30 07:48 · Score: 0
  
  Yes because Android users are so tech-savvy because they can change a stupid widget on an OS built on top of spyware.
17. Re:Brought it on themselves by dissy · 2016-01-30 08:35 · Score: 2, Informative
  
  Your post is either a standard Apple troll, or you are just purposely being dense.
  
  Please tell me you're kidding. These are iOS users we're talking about. They have purposely chosen the "easy to use" OS (even with all its limitations).
  WE are talking about iOS users, but I'm not sure you are on the same page...
  
  Like hell you're going to get them to figure out how to compile an app
  Are you seriously arguing Mac users are too stupid to double click one icon? Trollolol?
  
  Not only that, in order to run XCode you need to have a Mac.
  That's very likely why he said: and allow iOS device users who also own a Mac
  Or put another way, no you are very incorrect. If one already owns a Mac, there is no need for any additional Mac computers. Just the one will do.
  I suppose you bought your Android phone to make phone calls, then went right out to buy two or three more Android phones due to your thinking that one of the things somehow wasn't enough?
  
  You just went from a $200-$600 investment in the iPhone/iPad and added a thousand dollars to it.
  
  If you purchase no computer, you will spend $0. How are you arguing not buying a second computer costs thousands of additional dollars?
  
  There are no shortage of iOS users with Windows machines who like their iDevice but aren't ready to make that leap to a Mac.
  Hate to have to be the one to tell you this but MacOS is not Windows, and Windows is not MacOS.
  He clearly stated this option is only for Mac users. Why do you feel the need to repeat what was already said and specifically name Windows users as excluded?
  You forgot to mention Linux users can't do this either, nor can QNX users, nor can Mainframe users...
  Quit being dense or try to troll somewhat intelligently next time.
18. Re: Brought it on themselves by Anonymous Coward · 2016-01-30 09:58 · Score: 0
  
  They have not changed their policy. They have always allowed html / JavaScript content to be loaded. The hooks for JavaScript to access native functions is directly enabled in official APIs and has been used in Phonegap and the like for years. None of this is new. It may always have been possible to hide unused JS hooks in an app and remotely update JavaScript to use them. But this development methodology has been specifically endorsed for YEARS by Apple. What they don't allow is arbitrary code to be loaded i.e. users loading new code. Users can run their own code if they write it or copy / paste it. See the Pythonista app and its history.
  Apps generally have to point internally to the external JS code to load. Though that could point to additional code to load. Apple can and has shut it down if it gets too close to being 1) too close to an alternative App Store or 2) a source of abuse of policy or security by the developer.
19. Re: Brought it on themselves by macs4all · 2016-01-30 11:50 · Score: 1
  
  They have not changed their policy. They have always allowed html / JavaScript content to be loaded. The hooks for JavaScript to access native functions is directly enabled in official APIs and has been used in Phonegap and the like for years. None of this is new. It may always have been possible to hide unused JS hooks in an app and remotely update JavaScript to use them. But this development methodology has been specifically endorsed for YEARS by Apple. What they don't allow is arbitrary code to be loaded i.e. users loading new code. Users can run their own code if they write it or copy / paste it. See the Pythonista app and its history. Apps generally have to point internally to the external JS code to load. Though that could point to additional code to load. Apple can and has shut it down if it gets too close to being 1) too close to an alternative App Store or 2) a source of abuse of policy or security by the developer.
  So this is a vestige of the pre App Store days? Interesting!
20. Re:Brought it on themselves by tepples · 2016-01-30 15:20 · Score: 1
  
  it's unreasonable to expect people to invest in an entirely new computer
  Thank you. Can I quote you on this in case the issue comes up with someone else?
21. Re:Brought it on themselves by Anonymous Coward · 2016-01-30 18:04 · Score: 0
  
  The last time I checked Apple.com, a Mac mini started at 499 USD plus tax. Where do you get this "thousand dollars", unless you live in a country whose dollar happens to have such an exchange rate with the USD?
  Zimbabwe..
22. Re:Brought it on themselves by tlhIngan · 2016-01-30 20:20 · Score: 1
  
  You could distribute your app as source code under a free software license and allow iOS device users who also own a Mac to install the fix right away. Since Xcode 7, Apple has stopped requiring each individual user to buy a $99 per year developer license just to test an app compiled on his own Mac on his own iOS device.
  Has anyone asked RMS about this? I mean, a proprietary operating system allowing proprietary apps to use a proprietary approval method AND allowing open-source apps at the same time by sideloading it? And enforcing open-source-ness?
  (Yes, Apple told f.lux developers they couldn't use this method because all they did was wrap their binaries around a dummy source code build. So Apple is fine if you distribute source code, but not fine if you use it to distribute binaries.)
  The mind boggles.
23. Re:Brought it on themselves by Anonymous Coward · 2016-01-30 20:21 · Score: 0
  
  I hope that Apple changes the iOS App Store approval process to look for this insanely-dangerous BACKDOOR, and make the inclusion of that cause for instant REJECTION of the App.
  See, I think this is a really great idea, and that any developer who isn't doing it is a fool. These days, even a tiny bug fix update takes two full weeks to go through app review, and that's if Apple doesn't come up with some random rejection based on something that didn't actually change over the last forty updates, resulting in two more weeks' delay over and over until you've spent two months in f**king app review. And before you say this doesn't happen, you bet your a**, it does.
  By using something like this, developers can at least hot patch the problem so that their users don't end up screwed for two weeks while Apple sits their with their thumbs up their a**es.
  The app review process does serve a purpose for new apps, and it is even slightly beneficial for existing apps, but there's absolutely no statistical benefit from Apple reviewing every minor update when compared with mere spot checking of existing apps, and the sole result of Apple bizarrely checking every single minor tweak with a fine-toothed comb as though every developer were some evil entity trying to harm Apple's reputation has been an appallingly slow update process that harms consumers irreparably.
  The current system is basically broken beyond repair and has been broken for the better part of a decade at this point. If Apple isn't willing to spend the time, effort, or money to fix the brokenness, then it is the responsibility of developers to find a way around Apple by solving the problem themselves. Bravo.
  Posting anonymously because I don't want Apple to retaliate by making the review process even worse than it already is for me and other developers.
24. Re:Brought it on themselves by tepples · 2016-01-31 04:24 · Score: 1
  
  Apple's policy with Xcode 7 sort of resembles the LibreJS browser extension that FSF promotes, which acts like NoScript except whitelisting all free scripts, except that Apple requires a $499 dongle (a Mac mini) to compile the apps.
25. Re:Brought it on themselves by Aaden42 · 2016-02-01 04:56 · Score: 1
  
  How many people could even afford enough wheelbarrows to carry the amount of cash they'd need to buy a Mini. Or an iPhone for that matter...
Weird by Anonymous Coward · 2016-01-30 01:36 · Score: 0

Android doesn't have this problem because publishing app updates take about 30 seconds, where iOS can sometimes take weeks.
This glaring security flaw must be why Android and Google went out of business, and people didn't flock to their platform by the hundreds of millions.
1. Re:Weird by rasmusbr · 2016-01-30 04:51 · Score: 1
  
  It takes more like 2-4 hours before the update is rolled out by Google. I believe they run some tests on your update before they let it through.
2. Re:Weird by macs4all · 2016-01-30 04:53 · Score: 0
  
  Android doesn't have this problem because publishing app updates take about 30 seconds, where iOS can sometimes take weeks.
  This glaring security flaw must be why Android and Google went out of business, and people didn't flock to their platform by the hundreds of millions.
  Android is only "that" popular because it is on a zillion SHIT "smartphones" that the Telcos GIVE away.
  
  And you know what? I wouldn't come within ten feet of a mobile platform that has Apps that basically are Rubber-Stamp "Approved". Calling such an "Approval Process" is a cruel joke on the unsuspecting user.
  
  And the difference in Malware-amount on the two platforms clearly shows that that "joke" is being played on the Android user time and time again...
3. Re:Weird by Anonymous Coward · 2016-01-31 11:30 · Score: 0
  
  wow you sound really butthurt, just take a few deep breaths and relax, it'll be ok
4. Re: Weird by Anonymous Coward · 2016-02-01 08:17 · Score: 0
  
  You do understand that this is how software use to be, right?
  The company in question puts their software on their own website and "rubber stamps" their own updates.
  Even the most stringent QA will miss things... users behave and use it differently quite frequently.
5. Re: Weird by macs4all · 2016-02-01 10:37 · Score: 1
  
  You do understand that this is how software use to be, right?
  The company in question puts their software on their own website and "rubber stamps" their own updates.
  Even the most stringent QA will miss things... users behave and use it differently quite frequently.
  Yeah, I understand that is how software used to be... When a loaf of bread was fifty cents (U.S.), cars all had carbeurators, and lot of TVs still had vacuum tubes (other than the CRT).
  
  Oh, and before everyone and his dog wasn't trying to steal your personal info off your smartphone through the internet; because smartphones didn't exist, the "internet" was still called DARPAnet, and China was still an agrarian society...
  
  Times change. Sometimes that means old habits have to, too.
  
  For example, Microsoft was slow to learn that the world wasn't one big, happy, computing family, and they (well, mostly their users) suffered for decades because of it.
  
  But by the time Android came around (especially considering it is the idiot-bastard-son of Linux, which is the idiot-bastard-knockoff of Unix) there was simply NO excuse to not have a more "hardened" approach to software distribution, like iOS does.
  
  Call it a Walled Garden or whatever, the proof is in the pudding...
How long before Apple rejects by Registered+Coward+v2 · 2016-01-30 01:38 · Score: 1

apps using JSPatch?

--
I'm a consultant - I convert gibberish into cash-flow.
1. Re:How long before Apple rejects by jonwil · 2016-01-30 01:57 · Score: 5, Informative
  
  Apps using JSPatch are already violating the app store rules anyway. Apple prohibits any app that downloads unapproved code from somewhere and runs it (or did last time I checked)
2. Re:How long before Apple rejects by Registered+Coward+v2 · 2016-01-30 02:09 · Score: 1
  
  Apps using JSPatch are already violating the app store rules anyway. Apple prohibits any app that downloads unapproved code from somewhere and runs it (or did last time I checked)
  Yes, the question appears to be "Is Apple rejecting such apps?" TFA states developers are currently using it so the answer a[[ears to be No; so I wonder if Apple is simply not looking for JSPatch or has decided to let it go.
  
  --
  I'm a consultant - I convert gibberish into cash-flow.
3. Re:How long before Apple rejects by Anonymous Coward · 2016-01-30 02:50 · Score: 0
  
  The reviewers often miss things. The apps are usually yanked from App Store, and the developer must submit a new version for it to be reinstated.
  I'm not aware if Apple has ever disabled an installed app remotely, but I believe iOS has that capability in case of a malware outbreak.
4. Re: How long before Apple rejects by Anonymous Coward · 2016-01-30 10:04 · Score: 0
  
  Apple specifically allows this practice--hybrid (Phonegap and Cordova) apps can update their JS code on their own. But they can still only access native functionality through native hooks. Nothing new, nothing to see here. Not only that, Apple allows code interpreters e.g. Pythonista as long as they do not enable an alternate App Store or become abusive.
5. Re: How long before Apple rejects by null+etc. · 2016-02-01 02:32 · Score: 1
  
  You are completely incorrect. Only Webkit or JavaScriptCore components may execute dynamically-retrieved, remote code.
  Per Apple's iOS Developer Program Agreement:
  3.3.2 An Application may not download or install executable code. Interpreted code may only be used in an Application if all scripts, code and interpreters are packaged in the Application and not downloaded. The only exception to the foregoing is scripts and code downloaded and run by Apple's built-in WebKit framework or JavascriptCore, provided that such scripts and code do not change the primary purpose of the Application by providing features or functionality that are inconsistent with the intended and advertised purpose of the Application as submitted to the App Store.
Thanks by Opportunist · 2016-01-30 01:39 · Score: 1

Next time I get whined at by middle management why iPhones are on the corporate blacklist this should do.

--
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
1. Re:Thanks by 110010001000 · 2016-01-30 01:47 · Score: 1
  
  What types of phones are on the whitelist? Any phone where you can execute arbitrary code is insecure, even if it has been "vetted" by an app store. And even if you can't execute external code, it is likely insecure anyway due to bugs in the OS itself.
2. Re:Thanks by tepples · 2016-01-30 02:25 · Score: 1
  
  What types of phones are on the whitelist?
  Presumably company-owned wired phones that connect to the company's internal PBX or VoIP or whatever. My current employer allows BYOD, but I know of a lot of employers that don't. At non-BYOD workplaces, employees' cell phones go in a locker at the start of the shift and remain in the locker until the end of the shift.
3. Re:Thanks by Opportunist · 2016-01-30 03:34 · Score: 1
  
  Sorry, that information is not available. :)
  In a nutshell, the list is VERY tiny. And unless you really spend a lot of time doing mobile auditing, you probably won't recognize half of them.
  
  --
  We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
4. Re:Thanks by Anonymous Coward · 2016-01-30 04:19 · Score: 0
  
  AKA "I've been looking for an excuse to annoy everyone by not actually supporting their needs properly, this should do!"
I am agree by handbagsmsn · 2016-01-30 01:39 · Score: 0

i am agree with that http://www.handbagsmsn.com/
lordy lordy lordy by Anonymous Coward · 2016-01-30 01:49 · Score: 0

how eva will we be safe from da master!
Duh by Anonymous Coward · 2016-01-30 03:10 · Score: 0

Double Duh.
Converted into Obj-C? by Anonymous Coward · 2016-01-30 03:13 · Score: 0

How would downloading source code help anything; it need be compiled first?
1. Re:Converted into Obj-C? by tricorn · 2016-01-30 07:06 · Score: 1
  
  Yeah, the "converted into Objective-C" doesn't make any sense.
  What it seems to actually be doing is creating an interface between Obj-C and JavaScript so that JS can call out to any Obj-C method, and can override any method as well to call into JavaScript code. Combined with converting Obj-C code into JavaScript, you can effectively patch existing (compiled) Obj-C code with downloaded JavaScript.
  This probably went undetected in the review process because it just looks like a call to execute some sandboxed JavaScript, not something that has full access to the dispatch tables of Obj-C classes.
2. Re: Converted into Obj-C? by Anonymous Coward · 2016-01-30 10:09 · Score: 0
  
  You are correct about the method. Hybrid apps like this are officially sanctioned, can update their own JS without issue. They cannot load arbitrary code, that is against policy. They can load whatever code the developer may want to add though. Just not code the user may want to load, as that would be either a competing App Store or big source of security problems.
3. Re: Converted into Obj-C? by tricorn · 2016-01-30 13:50 · Score: 1
  
  Hybrid apps would have a well defined interface that the loadable code can use, with it being well isolated otherwise. This goes well beyond that, allowing the entire app to be rewritten (for example, allowing it to load arbitrary code to execute, bypassing the app store entirely).
Article is a piece of crap... by fabrica64 · 2016-01-30 03:15 · Score: 2

The linked article is just FUD. It basically says that using JSPatch the App can circumvent the app sandbox, and without any technical exlication. Just Fud
1. Re:Article is a piece of crap... by fabrica64 · 2016-01-30 03:22 · Score: 1
  
  And CSO (where the article is hosted) is interested in spreading FUD about iOS "risks", they live on "analyzing" security threats and they have to identify risks even where there's no risk
Wait...so the apps only run remote code? by Anonymous Coward · 2016-01-30 03:37 · Score: 0

As someone who regularly finds himself off-grid, that would suck tremendously to have to pull your code from a live network connection every time start the app.
Nonsense by vtcodger · 2016-01-30 03:45 · Score: 1

"Total nonsense!!! The brilliant technical minds creating our computer software, firmware and hardware would NEVER (cough ... sputter .. ) put users at risk"
Maybe if I practice that over and over maybe 50 or 100 times , I'll be able to get that out with a straight face.

--
You can't see ANYTHING from a car, You've got to get out of the goddamned contraption and walk...Edward Abbey
How dangerous by allo · 2016-01-30 03:45 · Score: 1

A phone app can use an complicated technology to do something, which pc apps can do without any problems all the time.
1. Re:How dangerous by rasmusbr · 2016-01-30 04:57 · Score: 1
  
  A phone app can use an complicated technology to do something, which pc apps can do without any problems all the time.
  Yeah.
  An Android or iOS app can silently download a patch that will do bad things with the data that you have created using that particular app. It can also spy on you if you have previously given it permission to do so.
  A PC app can silently download a patch that will do bad things with all of your data. It can also spy on you.
2. Re:How dangerous by allo · 2016-01-30 23:02 · Score: 1
  
  So the problem is trust. And that's a problem of app stores. Both google and apple suggest, that everything from their app store is safe. If they would label it just like a typical download site, the people would mistrust a bit more. And stop installing all the legal adware and spyware, which is seen as normal on mobile devices.
3. Re: How dangerous by Anonymous Coward · 2016-02-01 08:23 · Score: 0
  
  Actually, Google never makes any assertion that the Play Store is safe. It doesn't need to.
  If you don't trust the developer, you shouldn't install an app that has any permissions that could compromise your stuff
4. Re: How dangerous by allo · 2016-02-03 11:25 · Score: 1
  
  I think the ecosystem, the preinstallation and so on are asserting most users, that it's safe.
  On the other hand, most PC software from not too shady sources (even warez) are pretty safe, while mobile developers seem to build adware and/or spyware without any doubts by default. I think its a mixture of claiming a new software ecosystem, which doesn't have any rules yet and the typical mobile device users, which sees his phone/tablet as consumer device like a tv and not like a computer. Realizing that something read your private data comes later.
Mac + display, keyboard, and mouse = $529 by tepples · 2016-01-30 05:31 · Score: 2

I suppose the users are going to use some combination of telepathy and telekinesis to use that computer without a keyboard, mouse and monitor?
The last time I checked Apple.com, a Mac mini started at 499 USD plus tax, to which one can add either A. the display, keyboard, and mouse of one's existing non-Mac PC or B. one's existing HDMI TV and a 30 USD keyboard and mouse, bringing the total to 529 USD. This is still well shy of the $1,000 that Duckman5 quoted.

Not to mention the router and other network hardware and ISP costs they'll incur while trying to get the thing onto the internet to download a compiler and the source code.
I was assuming someone who already owns an Internet-connected PC running Windows or X11/Linux and an iPhone or iPad and is looking to replace the PC running Windows or X11/Linux with a Mac in order to receive updates to a particular Free program before App Store users receive them. How would an iPod touch or iPad user use the App Store anyway without paying "router and other network hardware and ISP costs"?
Just exposes the APIs in Javascript by sc0rpi0n · 2016-01-30 06:11 · Score: 2

How is this different from what you can do with Cordova and Appcelerator? These frameworks allow you to create new plugins to expose any iOS APIs you want to Javascript and can load Javascript remotely.
I assume that the app cannot access any functionality that was not enabled during the App Store submission, though I'm not sure of that. Anyone any insights regarding this?
1. Re: Just exposes the APIs in Javascript by Anonymous Coward · 2016-01-30 18:02 · Score: 0
  
  AFAICT that is essentially what the article is talking about.
  Use html5 and you can skip the review process for updates.
No permissions enforced at runtime? by l2718 · 2016-01-30 08:43 · Score: 1

This article seems to imply that Apple's primary security model is to first verify the apps and then give them at runtime unlimited access to the system, trusting them to only do the things they promised. This seems odd, especially compared with Android, where apps are limited at runtime to whatever capabilities they were granted by the user.
This issue could be trivially solved by enforcing permissions at runtime.
1. Re:No permissions enforced at runtime? by Anonymous Coward · 2016-01-31 04:47 · Score: 0
  
  The article and its implications are BS FUD click bait.
2. Re:No permissions enforced at runtime? by Aaden42 · 2016-02-01 05:11 · Score: 1
  
  article seems to imply that Apple's primary security model is to first verify the apps and then give them at runtime unlimited access
  The implication (which I agree is what I got reading the article) is utterly false. Many sensitive API's are secured in the runtime sandbox by the presence of crytographically signed "entitlements." Apple won't approve an entitlement unless the app has a legitimate need for it. Calling those secured API's through any mechanism when the app bundle lacks the necessary entitlement just fails. Entitlement-secured API's include background execution and iCloud access among others.
  Other less-sensitive APIs such as photos/camera access, microphone access, contacts, calendar, etc. don't require an entitlement, but still trigger an OS-provided permission dialog on first use. If the user doesn't approve, access to those API's just fails. It doesn't matter if the app didn't trigger those API's during the review process. The first time it does at runtime, the dialog pops up. Granted less savvy users might just hit "Approve," but if you read dialogs before mashing your thumb on the screen, a JSPatch app can't just run off with your data.
  As for the suggestion in the article that the app would modify system settings etc? Pure FUD. In order to expose that functionality to JavaScript, the JSPatch library itself would have to contain references to those symbols. Any binary that refs non-public API symbols is rejected. Whether the code actually calls them or not is immaterial*. If JSPatch did anything polymorphic to conceal the presence of those symbols, I'm pretty confident the thing would get blacklisted double quick.
  *Source: I had an app rejected once because one of my own function names happened to match a private API. Had to rename my function to get it approved.
Perhaps the point was too few Mac users by tepples · 2016-01-31 04:22 · Score: 1

Not only that, in order to run XCode you need to have a Mac.
That's very likely why he said: and allow iOS device users who also own a Mac
Just a guess, but let me try to be fair to Duckman5. I read the post as implying a claim that most iOS device users do not in fact already own a suitable Mac. Therefore my suggestion would apply to so few users that relying on it would not be worthwhile.

If one already owns a Mac, there is no need for any additional Mac computers. Just the one will do.
Unless the existing Mac is too old to run Xcode 7.