iOS App Store - Fake Microsoft Word 2012 Approved(itunes.apple.com)
itunes.apple.com
iOS App Store - Fake Microsoft Word 2012 Approved
http://itunes.apple.com/app/microsoft-word-2012/id534884750?mt=8
122 comments
I love these reviews of F1 Birdie Driver:
----------
Wow! by {{{Indie_John}}} (Five Stars)
Surprising control system! It's cool, that you can steer.
Birds! by david35689 (Five Stars)
It's so cool, that birds are in racing game now!
Worthless by Jim hannoonen (One Star)
Horrible game! Total waste of money.
----------
Someone should release a game called "Spot The Fake Review".
----------
Wow! by {{{Indie_John}}} (Five Stars)
Surprising control system! It's cool, that you can steer.
Birds! by david35689 (Five Stars)
It's so cool, that birds are in racing game now!
Worthless by Jim hannoonen (One Star)
Horrible game! Total waste of money.
----------
Someone should release a game called "Spot The Fake Review".
Or even better: "Create fake reviews" :)
I also agree that Apple has a right to curate their store. But I disagree that the only store I should be allowed to buy from is Apple's.
Then don't buy an iOS device.
This would only hold true if Apple phones were the only decent phones on the market.
The iPad is a one of a kind because of the retina screen. Try it for a week and you'll be banging your head against the wall looking at the pixels on your laptop/desktop screen.
[deleted]
Did you forget about the Cydia marketplace & jailbroken iPhones?
That also brings down the sandbox, which is nice to have when you run apps from developers you wouldn't necessarily trust. Too bad there's no way to side-load unsigned (or signed by a custom CA) apps while still maintaining the sandbox restrictions.
We add some exceptions to the sandbox that I will argue do not decrease your security (as some parts of the sandbox are designed to help Apple, not the device owner). We do not deactivate the sandbox entirely.
Can you tell me where you got this information? It would help in our attempts to mitigate misinformation: a lot of people say a lot of very wrong things about jailbreaking, and it is nice to fix the source.
Can you tell me where you got this information? It would help in our attempts to mitigate misinformation: a lot of people say a lot of very wrong things about jailbreaking, and it is nice to fix the source.
Wow, that's actually news to me. I based this information on some first-hand experience/reasoning and also on various web pages. In particular:
* After installing OpenSSHd, obviously there is full access to the file system (at least as the "mobile" user, "root" may require a password). So at least this application is able to access more of the file system than a standard sandboxed application, right?
* At least one of the jailbreaks I tried caused iBooks to fail, and according to sources such as http://lumosdigital.com/blog/2011/02/15/apple-cripples-ibook... this is caused by an anti-jailbreak check that fails because sandbox restrictions are lifted
* I remember some drama (via twitter? irc? can't remember) about some .debs shipping with suspicious (setuid) files? (Probably from shady 3rd party repositories)
* None of the jailbreaks I've looked at has ever come with a technical description that explains their particular modifications.
* And finally, the fact that the jailbreak even works shows there are security measures being defeated in some capacity.
I'd love to be corrected on any or all of these points. :)
* After installing OpenSSHd, obviously there is full access to the file system (at least as the "mobile" user, "root" may require a password). So at least this application is able to access more of the file system than a standard sandboxed application, right?
* At least one of the jailbreaks I tried caused iBooks to fail, and according to sources such as http://lumosdigital.com/blog/2011/02/15/apple-cripples-ibook... this is caused by an anti-jailbreak check that fails because sandbox restrictions are lifted
* I remember some drama (via twitter? irc? can't remember) about some .debs shipping with suspicious (setuid) files? (Probably from shady 3rd party repositories)
* None of the jailbreaks I've looked at has ever come with a technical description that explains their particular modifications.
* And finally, the fact that the jailbreak even works shows there are security measures being defeated in some capacity.
I'd love to be corrected on any or all of these points. :)
The main thing for which you seem to need correction is that you apparently do not know what the sandbox does ;P. You seem to be operating under the belief that the sandbox is a system-wide primitive, when in fact each separate process operates in its own optional sandbox.
There are many processes, then, where there is no sandbox configured even on a stock iPhone. When you use Cydia (no sandbox) to install sshd (no sandbox) that is orthogonal to the behavior of other third-party applications that are still restricted to their sandboxes.
(As a quick aside on OpenSSH, as you mention that the root user "may" required a password: all users require passwords. However, the default password for both the mobile and root accounts is "alpine". If you install something like OpenSSH you should change these passwords.)
In the specific case of iBooks, the fairplay DRM checks are not checking that the sandboxes were damaged, but more generally that the system was jailbroken at all: the new checks verify that the kernel memory has not been modified by comparing hashes of critical code, and the old ones from this article that unsigned code runs (orthogonal to a sandbox).
Finally, the fact that the jailbreak works indicates that the pre-jailbroken system was insecure, not that the jailbroken system now has less security. In fact, for more serious exploits, the opposite is true: until Apple releases a patch, you should jailbreak to be safe.
As an example, the exploits that are launched from jailbreakme.com take advantage of bugs in the web browser (v1 attacked TIFF, v2 and v3 attacked TTF). These bugs were already there: any web page anywhere on the Internet could have used these to compromise MobileSafari.
Once in MobileSafari, bugs in the kernel are used that, again, were already there. These bugs could have been used by any code running on your system, including code running inside of a third-party App Store app (despite the sandbox) to jailbreak and possibly even rootkit your device.
However, once you were jailbroken, we offered (in all three of those cases; sometimes as packages and sometimes just by default as part of the process), patches to MobileSafari that would correct the ingress attack vector. Thereby, once jailbroken, you were protected from that exploit.
As to your separate (valid) point about jailbreaks not describing what they do, sadly the different jailbreaks that are available often use specific (as in, not shared; I'm failing to find the right word) kernel patches that are often even incompatible with each other (having different behavior).
Thereby, I can't tell you exactly what any specific jailbreak does. :( However, the overall game plan that they follow is fairly constant, and I can tell you what the "best practice" patches that jailbreaks install by default are in a short list here.
1) AFC2: allows you to access, over USB, all of / as root instead of just /var/mobile/Media as mobile. (Some people, including myself, do not like this patch; it is just an entry in a config file and is easy to remove.)
2) fstab / rw: makes / be mounted read-write. Normally the partition that holds the system software is read-only. As the files on this partition are owned by root, this does not affect the abilities of App Store applications (which run as mobile).
3) fstab /var suid dev: allows setuid executables and device nodes on the user data partition. You have to already have elevated permissions to create these files, so again this does not affect the abilities of App Store applications.
4) codesign: allow code that has not been signed by anyone to execute. This patch allows you to install code from third-party sources on your device, but does not affect the content you obtain from the App Store: they will only give you binaries that they have signed and verified.
5) codehash: allow processes with "corrupt" pages of code to execute. I disagree with this patch (and many jailbreaks do not include it), but it does not affect the abilities of App Store applications as they do not have write access to modify any executables.
6) rw->rx: supports changing a page of memory from writable to executable. Combined with earlier patches, this allows you to build JIT compilers, and is needed for Substrate's MSHookFunction to modify the behavior of a C function. This does affect all process security.
This sixth patch does not, as some people will claim, remove all the advantages of non-executable data or other stack protections. These pages still load as rw and are not executable: you cannot just overflow into them and then jump to them to execute their contents.
However, you can first re-mark the memory region as rx before jumping to it. To do so would require a return-to-libc attack. However, if you already know enough about the target process to do a return-to-libc you may as well just do a return-oriented-programming attack.
It also should be noted that even if you consider the return-to-libc followed by the jump to the now-executable region to be a security hazard, it must be noted that there could be any manner of non-memory security-related mistakes in the App Store applications you have installed.
I will thereby argue that you are really, in the end, relying on the application sandboxes to provide security: the App Store developer probably left tons of gaping holes in their code, and may have even included an entire interpreter-VM... this patch does not increase the magnitude of an attack, only the probability.
7) rwx: allows memory to be marked for write and execute at the same time. This is dangerous, conceptually, but it is required for high-performance JITs. Otherwise, you find yourself having to flip the page from write to execute back constantly, which has performance and safety ramifications.
Applications that choose to mark their pages rwx will end up with lowered security with this patch. However, such processes are normally virtual machines that have numerous other security mitigation strategies, and should therefore, in the end, be much safer than stricter native applications.
However, I will argue that this patch does not offer an attacker anything over the sixth patch: to attack a normal process you will still need to use mmap/mprotect to manually get some rwx pages, at which point you already have return-to-libc and probably just need rx, not rwx.
8) sandbox: allow processes to access files that are outside of their sandbox based on Unix permissions rather than the normal sandbox rules. This affects the security of App Store applications, but there is much more nuance to it.
This, then, is the last and most important patch to our discussion. In some jailbreaks this patch sucks: it literally just turns off the sandbox entirely. You can normally tell that this happened because nothing works ;P (the sandboxes also mediate shared keychain access).
Most jailbreaks instead make targeted modifications to the sandbox restrictions. The "best practice" that I laid out for this patch a while back (and which planetbeing and comex both implemented for various jailbreaks, and which I believe is being used in redsn0w and Absinthe currently) is:
"Add an exception that if a file being accessed is not stored in /var/mobile (the user's home directory) then rather than do not have the sandbox intercept or affect the access check: allow the normal Unix permissions to (probably deny) the access."
This allows you to get read access to files stored on the system permission (not write access, as that would require root). It also allows developers to specifically create scratch storage that is writable by mobile (if they need) somewhere on the filesystem.
While I can come up with some theoretical reasons why there might be a security risk in having read access to files that, thanks to any single person having jailbroken their device, anyone can just download from the Internet anyway, I consider this a far and difficult stretch.
Instead, I will argue that all of the important data is stored in the user's home directory (/var/mobile), and that the parts of the sandbox that "work for the user" protect the files in that folder, while the other parts of the sandbox are more "working for Apple".
(This is detectable because if you install some extensions, such as "file:// for MobileSafari", you can get Safari to read from static web pages stored anywhere on the filesystem but your home directory. This causes a lot of confusion to some people, as that is an obvious place to put things ;P.)
So, AFAIK, none of the major jailbreaks that you find deactivate the sandbox on these personal files. When developers really consider the ability to access these files important, they build daemons (running in the background outside of sandboxes) to mediate access.
Hopefully this goes to some length to help you with your concerns (and I guess I'll now go tell Britta that I wrote this, so she can use content from it or refer people to it as required in the future). I'd still love to get better references for where you see random misinformation ;P.
(edit: I just thought of another patch that is included. 9) crazeles: a ludicrously complicated hack by planetbeing that neuters the FairPlay DRM checks that cause iBooks to refuse to operate correctly on jailbroken devices. This specifically addresses the earlier paragraph on iBooks.)
There are many processes, then, where there is no sandbox configured even on a stock iPhone. When you use Cydia (no sandbox) to install sshd (no sandbox) that is orthogonal to the behavior of other third-party applications that are still restricted to their sandboxes.
(As a quick aside on OpenSSH, as you mention that the root user "may" required a password: all users require passwords. However, the default password for both the mobile and root accounts is "alpine". If you install something like OpenSSH you should change these passwords.)
In the specific case of iBooks, the fairplay DRM checks are not checking that the sandboxes were damaged, but more generally that the system was jailbroken at all: the new checks verify that the kernel memory has not been modified by comparing hashes of critical code, and the old ones from this article that unsigned code runs (orthogonal to a sandbox).
Finally, the fact that the jailbreak works indicates that the pre-jailbroken system was insecure, not that the jailbroken system now has less security. In fact, for more serious exploits, the opposite is true: until Apple releases a patch, you should jailbreak to be safe.
As an example, the exploits that are launched from jailbreakme.com take advantage of bugs in the web browser (v1 attacked TIFF, v2 and v3 attacked TTF). These bugs were already there: any web page anywhere on the Internet could have used these to compromise MobileSafari.
Once in MobileSafari, bugs in the kernel are used that, again, were already there. These bugs could have been used by any code running on your system, including code running inside of a third-party App Store app (despite the sandbox) to jailbreak and possibly even rootkit your device.
However, once you were jailbroken, we offered (in all three of those cases; sometimes as packages and sometimes just by default as part of the process), patches to MobileSafari that would correct the ingress attack vector. Thereby, once jailbroken, you were protected from that exploit.
As to your separate (valid) point about jailbreaks not describing what they do, sadly the different jailbreaks that are available often use specific (as in, not shared; I'm failing to find the right word) kernel patches that are often even incompatible with each other (having different behavior).
Thereby, I can't tell you exactly what any specific jailbreak does. :( However, the overall game plan that they follow is fairly constant, and I can tell you what the "best practice" patches that jailbreaks install by default are in a short list here.
1) AFC2: allows you to access, over USB, all of / as root instead of just /var/mobile/Media as mobile. (Some people, including myself, do not like this patch; it is just an entry in a config file and is easy to remove.)
2) fstab / rw: makes / be mounted read-write. Normally the partition that holds the system software is read-only. As the files on this partition are owned by root, this does not affect the abilities of App Store applications (which run as mobile).
3) fstab /var suid dev: allows setuid executables and device nodes on the user data partition. You have to already have elevated permissions to create these files, so again this does not affect the abilities of App Store applications.
4) codesign: allow code that has not been signed by anyone to execute. This patch allows you to install code from third-party sources on your device, but does not affect the content you obtain from the App Store: they will only give you binaries that they have signed and verified.
5) codehash: allow processes with "corrupt" pages of code to execute. I disagree with this patch (and many jailbreaks do not include it), but it does not affect the abilities of App Store applications as they do not have write access to modify any executables.
6) rw->rx: supports changing a page of memory from writable to executable. Combined with earlier patches, this allows you to build JIT compilers, and is needed for Substrate's MSHookFunction to modify the behavior of a C function. This does affect all process security.
This sixth patch does not, as some people will claim, remove all the advantages of non-executable data or other stack protections. These pages still load as rw and are not executable: you cannot just overflow into them and then jump to them to execute their contents.
However, you can first re-mark the memory region as rx before jumping to it. To do so would require a return-to-libc attack. However, if you already know enough about the target process to do a return-to-libc you may as well just do a return-oriented-programming attack.
It also should be noted that even if you consider the return-to-libc followed by the jump to the now-executable region to be a security hazard, it must be noted that there could be any manner of non-memory security-related mistakes in the App Store applications you have installed.
I will thereby argue that you are really, in the end, relying on the application sandboxes to provide security: the App Store developer probably left tons of gaping holes in their code, and may have even included an entire interpreter-VM... this patch does not increase the magnitude of an attack, only the probability.
7) rwx: allows memory to be marked for write and execute at the same time. This is dangerous, conceptually, but it is required for high-performance JITs. Otherwise, you find yourself having to flip the page from write to execute back constantly, which has performance and safety ramifications.
Applications that choose to mark their pages rwx will end up with lowered security with this patch. However, such processes are normally virtual machines that have numerous other security mitigation strategies, and should therefore, in the end, be much safer than stricter native applications.
However, I will argue that this patch does not offer an attacker anything over the sixth patch: to attack a normal process you will still need to use mmap/mprotect to manually get some rwx pages, at which point you already have return-to-libc and probably just need rx, not rwx.
8) sandbox: allow processes to access files that are outside of their sandbox based on Unix permissions rather than the normal sandbox rules. This affects the security of App Store applications, but there is much more nuance to it.
This, then, is the last and most important patch to our discussion. In some jailbreaks this patch sucks: it literally just turns off the sandbox entirely. You can normally tell that this happened because nothing works ;P (the sandboxes also mediate shared keychain access).
Most jailbreaks instead make targeted modifications to the sandbox restrictions. The "best practice" that I laid out for this patch a while back (and which planetbeing and comex both implemented for various jailbreaks, and which I believe is being used in redsn0w and Absinthe currently) is:
"Add an exception that if a file being accessed is not stored in /var/mobile (the user's home directory) then rather than do not have the sandbox intercept or affect the access check: allow the normal Unix permissions to (probably deny) the access."
This allows you to get read access to files stored on the system permission (not write access, as that would require root). It also allows developers to specifically create scratch storage that is writable by mobile (if they need) somewhere on the filesystem.
While I can come up with some theoretical reasons why there might be a security risk in having read access to files that, thanks to any single person having jailbroken their device, anyone can just download from the Internet anyway, I consider this a far and difficult stretch.
Instead, I will argue that all of the important data is stored in the user's home directory (/var/mobile), and that the parts of the sandbox that "work for the user" protect the files in that folder, while the other parts of the sandbox are more "working for Apple".
(This is detectable because if you install some extensions, such as "file:// for MobileSafari", you can get Safari to read from static web pages stored anywhere on the filesystem but your home directory. This causes a lot of confusion to some people, as that is an obvious place to put things ;P.)
So, AFAIK, none of the major jailbreaks that you find deactivate the sandbox on these personal files. When developers really consider the ability to access these files important, they build daemons (running in the background outside of sandboxes) to mediate access.
Hopefully this goes to some length to help you with your concerns (and I guess I'll now go tell Britta that I wrote this, so she can use content from it or refer people to it as required in the future). I'd still love to get better references for where you see random misinformation ;P.
(edit: I just thought of another patch that is included. 9) crazeles: a ludicrously complicated hack by planetbeing that neuters the FairPlay DRM checks that cause iBooks to refuse to operate correctly on jailbroken devices. This specifically addresses the earlier paragraph on iBooks.)
Thank you for an incredibly detailed, interesting and well formulated explanation of the jailbreak process!
I had the general idea that the sandbox was probably working out of some complicated rulesets a la SElinux (which I also do not know in detail, unfortunately).
To clarify a few of my original mis-conceptions:
* For the iBooks DRM, one of the JB tests was apparently to drop an (incorrectly signed?) exexutable and try to exec() it, if it runs, the sandbox is "no good". Out of this; I assumed (some) jailbreaks would therefore allow any App Store app to go crazy exec()ing (since iBooks comes from the App Store), which feels like a security problem
* I wasn't aware that jailbreaks still maintained a sandbox for AppStore apps, while bypassing it for non-AppStore apps. I assume installing .debs from cydia is the equivalent of handing the .deb author a root shell. (OpenSSH comes from a .deb, for example)
* I wasn't aware whether keychains and other private data was protected after a jailbreak. Could apps go snooping on other app data, for example to pick up credentials/session cookies from Facebook.app, read stored mail, access the photo roll without the location permission prompt, etc. Only non-AppStore apps?
In other words, does it boil down to:
* You can still install AppStore apps without worry, they only run within their own context? (I am guessing: mostly yes, but if apple were evil they could do the iBook DRM trick, post back your UDID to apple and ban your device)
* You should exercise extreme caution with any .deb, since that's equivalent to handing out a root shell to the author (even just for a moment - .deb preinst scripts etc?)
Thanks again for taking time to explain all the details so far. (You really should just copy&paste this into a section of your cydia website! :) )
I had the general idea that the sandbox was probably working out of some complicated rulesets a la SElinux (which I also do not know in detail, unfortunately).
To clarify a few of my original mis-conceptions:
* For the iBooks DRM, one of the JB tests was apparently to drop an (incorrectly signed?) exexutable and try to exec() it, if it runs, the sandbox is "no good". Out of this; I assumed (some) jailbreaks would therefore allow any App Store app to go crazy exec()ing (since iBooks comes from the App Store), which feels like a security problem
* I wasn't aware that jailbreaks still maintained a sandbox for AppStore apps, while bypassing it for non-AppStore apps. I assume installing .debs from cydia is the equivalent of handing the .deb author a root shell. (OpenSSH comes from a .deb, for example)
* I wasn't aware whether keychains and other private data was protected after a jailbreak. Could apps go snooping on other app data, for example to pick up credentials/session cookies from Facebook.app, read stored mail, access the photo roll without the location permission prompt, etc. Only non-AppStore apps?
In other words, does it boil down to:
* You can still install AppStore apps without worry, they only run within their own context? (I am guessing: mostly yes, but if apple were evil they could do the iBook DRM trick, post back your UDID to apple and ban your device)
* You should exercise extreme caution with any .deb, since that's equivalent to handing out a root shell to the author (even just for a moment - .deb preinst scripts etc?)
Thanks again for taking time to explain all the details so far. (You really should just copy&paste this into a section of your cydia website! :) )
I had just noticed, in passing through the open tab to the link you provided, that I had not adequately explained the old iBooks-on-4.2 check. I added some clarification, and then saw that in fact you had noticed the issue now in this reply as well ;P.
It seems that Corona (the iOS 5.0.1 untether), at least, does allow an App Store application to call exec(). I am honestly not certain why that is allowed... I am, however, also not entirely certain whether that is normally disallowed: it might actually not be considered a problem by Apple.
The reason why I point out that there might actually not normally be a restriction against exec() is that I just tested using fork() on my iOS 5.0.1 iPhone 4S using Corona (Absinthe 0.4) and, in fact, you can't call that from an App Store application. (So, the sandbox works. ;P)
To test, I ran Facebook, then used `cycript -p Facebook` to inject a console into that process (using cycript, my JavaScript/Objective-C hybrid shell). I then ran `new Functor(dlsym(RTLD_DEFAULT, "fork"), "v")()` to get a reference to and call the fork system call stub from libSystem (libc).
The sandbox daemon was then asked by the kernel to verify whether that process was allowed to fork, and as it was not I got the following log message and the process was denied. (I say "denied" as it was not killed: it just got -1 from fork() with EPERM.)
Jun 18 15:00:16 Transponder sandboxd[768]: Facebook(759) deny process-fork
Moving on, your comparison to SELinux is, AFAIK, fairly accurate; on Ubuntu, AppArmor is also a similar system to the Apple sandbox (and, transitively, SELinux). It should be pointed out, however, that these systems are also per-process: I can still install things on the computer and mark them "no limits".
As for your other comments, App Store applications on jailbroken devices still cannot snoop into your keychain, mail, or the data stored for other applications such as Facebook. They do have access to your camera roll, but that is true of non-jailbroken devices as well (this is fixed on iOS 6).
Finally, you are correct in that installing a .deb on your system is handing the packager the equivalent of a temporary root shell on your device: in addition to installing arbitrary code with the package (the point of installing it at all), it gets to actually run scripts as root during the (un)installation itself.
It seems that Corona (the iOS 5.0.1 untether), at least, does allow an App Store application to call exec(). I am honestly not certain why that is allowed... I am, however, also not entirely certain whether that is normally disallowed: it might actually not be considered a problem by Apple.
The reason why I point out that there might actually not normally be a restriction against exec() is that I just tested using fork() on my iOS 5.0.1 iPhone 4S using Corona (Absinthe 0.4) and, in fact, you can't call that from an App Store application. (So, the sandbox works. ;P)
To test, I ran Facebook, then used `cycript -p Facebook` to inject a console into that process (using cycript, my JavaScript/Objective-C hybrid shell). I then ran `new Functor(dlsym(RTLD_DEFAULT, "fork"), "v")()` to get a reference to and call the fork system call stub from libSystem (libc).
The sandbox daemon was then asked by the kernel to verify whether that process was allowed to fork, and as it was not I got the following log message and the process was denied. (I say "denied" as it was not killed: it just got -1 from fork() with EPERM.)
Jun 18 15:00:16 Transponder sandboxd[768]: Facebook(759) deny process-fork
Moving on, your comparison to SELinux is, AFAIK, fairly accurate; on Ubuntu, AppArmor is also a similar system to the Apple sandbox (and, transitively, SELinux). It should be pointed out, however, that these systems are also per-process: I can still install things on the computer and mark them "no limits".
As for your other comments, App Store applications on jailbroken devices still cannot snoop into your keychain, mail, or the data stored for other applications such as Facebook. They do have access to your camera roll, but that is true of non-jailbroken devices as well (this is fixed on iOS 6).
Finally, you are correct in that installing a .deb on your system is handing the packager the equivalent of a temporary root shell on your device: in addition to installing arbitrary code with the package (the point of installing it at all), it gets to actually run scripts as root during the (un)installation itself.
Neat! Thanks again for the super-detailed clarifications!
Going back to my comment that started this sub-thread, I guess the point then still stands, "Too bad there's no way to side-load unsigned (or signed by a custom CA) apps while still maintaining the sandbox restrictions." (i.e. no "safe thirdparty appstores") ;)
[quick note on the camera roll thing, I think apps are denied access before the user confirms a location permission popup]
[another quick note on the exec() thing, exec() probably wouldn't work since appstore codesign only works on a single binary. probably related to why only static libraries are allowed, too]
[edit: the fork/exec thing may also be tied in to the strict limitations on background processing for appstore apps? interesting to see your cycript experiment there!]
Going back to my comment that started this sub-thread, I guess the point then still stands, "Too bad there's no way to side-load unsigned (or signed by a custom CA) apps while still maintaining the sandbox restrictions." (i.e. no "safe thirdparty appstores") ;)
[quick note on the camera roll thing, I think apps are denied access before the user confirms a location permission popup]
[another quick note on the exec() thing, exec() probably wouldn't work since appstore codesign only works on a single binary. probably related to why only static libraries are allowed, too]
[edit: the fork/exec thing may also be tied in to the strict limitations on background processing for appstore apps? interesting to see your cycript experiment there!]
It would be easy to provide such a thing on top of a jailbroken system, but in practice there are very few use cases for it: Apple's curation is only evil in a small handful of situations. Again: the vast and overwhelming majority of things people jailbreak to do (and even ten pay for in Cydia) are not apps and fundamentally cannot be installed as an app with an icon into a sandbox. It would likely then be a political death blow of that, as opposed to "ability to bypass the sandbox" we're all that was allowed (as explaining to people, even to developers, even to those actively at that minute using them, what substrate extensions are and how they have no similarity to the apps they modify, is sufficiently tricky that the response will just be "we already gave you the ability to side-load apps").
Please consider posting this whole thread on your blog, or somewhere more accessible/searchable. Lots of interesting stuff that I'm certain have never been stated anywhere in a coherent manner, and would literally rot here, with just a handful people reading them.
I think he means that codesigning is disabled, for all intents and purposes, when you jailbreak.
As described in my longer response (which was posted a while before you posted this reply, so I will not assume that it helped), disabling codesign does not affect your ability to trust content you get from the App Store, as that content will not be sent to you by Apple had it not been already signed.
No, I was actually worrying about losing the "data firewall" between apps.
both options void the warranty. I'm an apple fanboy, but what iOS needs is what android, OSX, and Windows has already done..
- a carefully groomed, public facing store monitored by apple (they have already)
- allow other app stores for non-monopolistic competition (eg: Amazon's android store)
- allow developers to use DRM on their apps
- allow app files to be loaded manually by the user
- a carefully groomed, public facing store monitored by apple (they have already)
- allow other app stores for non-monopolistic competition (eg: Amazon's android store)
- allow developers to use DRM on their apps
- allow app files to be loaded manually by the user
This looks attractive, but does not /really/ help: the reason people use Cydia is not to get apps, but is instead to download "extensions". It is not possible to install these modifications (things "be able to put five icons on the dock instead of the default four") on any of the modern mobile platforms without first jailbreaking: the ability to "side load" an app is honestly kind of boring.
It's certainly possible to perform that particular customisation on Android: the launcher is just another app, and many are available.
That specific customization is possible but requires you to replace that entire component, so it isn't really a customization any more than saying you can customize that particular thing by just replacing the entire phone. ;P
This distinction becomes important when you want to install that customization on a device for which the stock launcher is not open source but has been customized to fit with other apps, or simply when you want multiple customizations from different people.
However, if you insist on something a little more concrete: what if you want to add new buttons to the Android notification center, add new features to the status bar, or affect the behavior of the lock screen? These are not apps you can replace.
This distinction becomes important when you want to install that customization on a device for which the stock launcher is not open source but has been customized to fit with other apps, or simply when you want multiple customizations from different people.
However, if you insist on something a little more concrete: what if you want to add new buttons to the Android notification center, add new features to the status bar, or affect the behavior of the lock screen? These are not apps you can replace.
Yes. We all kind of forgot, didn't we?
Yes! But also convince everybody else not to buy iOS devices so that the market gets Apple to improve its behavior.
While I'm not at all for curated computing, I don't think some people are ever going to care about how locked down their devices are.
Of course not.
Far too many geeks have this innate delusion that people are like them. That they care about side loading apps, open source freedom, other browser rendering engines, jail breaking etc. Most people just see this as introducing complexity and unnecessary choices.
Perhaps the problem is in how these are articulated.
Far too many geeks have this innate delusion that people are like them. That they care about side loading apps, open source freedom, other browser rendering engines, jail breaking etc. Most people just see this as introducing complexity and unnecessary choices.
Perhaps the problem is in how these are articulated.
Apple is not in the business of justice. They will go to great lengths to protect their business, and other things are only important as long as they are relevant to their business. Now, the shittiness of the app store should concern them. I believe they are doing a pretty good job of promoting good apps, and letting the bad reviews bury horrible apps. If an app like this one floats up all the filters and publicly shames them, they will take down the app and probably all the other apps by the developer. So, if they will take dramatic action, it will probably on a case basis; which is both more conservative as an action from their part, and probably as effective as a countermeasure.
> but I think they should do it more vigorously and reject every single shitty app, and ban those developers
Easy to say, but hard to do with the volume of app submissions. That's the trouble with a large-scale process that must be carried out by humans -- consistency and fairness are just plain hard.
This example is a clear sign that there's room for significant improvement, however.
Easy to say, but hard to do with the volume of app submissions. That's the trouble with a large-scale process that must be carried out by humans -- consistency and fairness are just plain hard.
This example is a clear sign that there's room for significant improvement, however.
[deleted]
You feel that Apple should reject "every single shitty app"? Really? You do realize that such things are subjective, right?
I actually meant 'scammy'.
I just don't think they should be doing it so half-assedly... Either don't reject apps that fall short of some stupid 'guideline', or add 'don't produce scammy/confusing apps' to your 'rules' and reject such apps. There are hundreds of apps on the App Store, allegedly allowing you to record your phone calls. Only 1 of them works as far as I've heard (and that works by adding another remote listener to the conversation, in conference mode), or thousands of scammy apps that are supposed to let you change wallpapers, screen savers, put notes in 'lock screen', warm up your hands (by emitting ultra-something rays out of screen!), put more than 4 icons in the dock, create password-protected folders, blacklist phone numbers, auto-response to SMS, you name it. I think every single one of these apps should be removed from the App Store.
I just don't think they should be doing it so half-assedly... Either don't reject apps that fall short of some stupid 'guideline', or add 'don't produce scammy/confusing apps' to your 'rules' and reject such apps. There are hundreds of apps on the App Store, allegedly allowing you to record your phone calls. Only 1 of them works as far as I've heard (and that works by adding another remote listener to the conversation, in conference mode), or thousands of scammy apps that are supposed to let you change wallpapers, screen savers, put notes in 'lock screen', warm up your hands (by emitting ultra-something rays out of screen!), put more than 4 icons in the dock, create password-protected folders, blacklist phone numbers, auto-response to SMS, you name it. I think every single one of these apps should be removed from the App Store.
Sure, there's no reason why apple shouldn't be able to make subjective quality value judgments. When I go to any retail store, the purchasers have already made hundreds of subjective rejections for me. Some stores are stricter than others, and that's OK.
I like knowing that something I buy at Nordstrom probably won't be complete and utter garbage. If Apple wants to be the Nordstrom of app stores, that's their right.
I like knowing that something I buy at Nordstrom probably won't be complete and utter garbage. If Apple wants to be the Nordstrom of app stores, that's their right.
It's getting ridiculous - I'd heard of this happening a lot, and then last week one of my GPL'd Mac apps that's hosted on GitHub appeared on the Mac Store, being sold for €23.99 by some person (obviously Chinese with a really dodgy website). Surely the dodgy website should ring some alarm bells at Apple?
Despite going through the process on the store feedback to notify Apple of counterfeit apps, I've had no response...
I don't really care that much that someone's profiting off my work (they didn't even bother to do their own screenshots), I'm more concerned that some people are going to pay that money for that clone of my app, when it's free (although not in the App Store), and the other developer is very unlikely to help them if there are any problems.
Despite going through the process on the store feedback to notify Apple of counterfeit apps, I've had no response...
I don't really care that much that someone's profiting off my work (they didn't even bother to do their own screenshots), I'm more concerned that some people are going to pay that money for that clone of my app, when it's free (although not in the App Store), and the other developer is very unlikely to help them if there are any problems.
If they provide the source code on request or in the credits or something similar, isn't that perfectly legitimate?
Not according to: http://en.wikipedia.org/wiki/Mac_App_Store
and people familiar with the issue...
My understanding was that the GPL and Apple's app store terms were fundamentally incompatible, but I suppose that might only be true of iOS (because of the development tool issues and such).
GPLv3 which requires handing over the keys, yes. GPL(v2), no.
Aren't we handing over all the flexibility of open app development so that Apple can protect us from crapware? What the hell are they doing with my $100 a year?
No. It's so Apple can protect you from malware.
Not choosing and buying crapware is still on you.
Not choosing and buying crapware is still on you.
I don't know what they're doing. But I think it must be something really complex as my last application needed 13 days to get "in review" status and then 18 days more to get approved.
Feels good paying those $100 every year ...
Feels good paying those $100 every year ...
You could just stop developing for Apple. I hear Android is an "open" platform.
Yeah, but Java no thanks :)
You're probably joking, but in case you're not aware, it's possible to develop Android apps in many languages other than Java. Other JVM languages like Scala [1,2] are perhaps the easiest. C and C++ (and feasibly other languages that can call C libraries) are supported through the NDK [3]; there's even a project to use Objective-C on Android using the NDK [4]. It's also possible to use scripting languages such as Python or Lua using the Scripting Layer for Android [5]. Some of these methods will require you to write a very minimal Java wrapper to properly package your app, but realistically Android is no more tied to Java than iOS is to Objective-C.
[1] - https://code.google.com/p/scalaforandroid/
[2] - http://robots.thoughtbot.com/post/5836463058/scala-a-better-...
[3] - https://developer.android.com/sdk/ndk/index.html
[4] - https://code.google.com/p/android-gcc-objc2-0/
[5] - https://code.google.com/p/android-scripting/
[1] - https://code.google.com/p/scalaforandroid/
[2] - http://robots.thoughtbot.com/post/5836463058/scala-a-better-...
[3] - https://developer.android.com/sdk/ndk/index.html
[4] - https://code.google.com/p/android-gcc-objc2-0/
[5] - https://code.google.com/p/android-scripting/
I can't comment on the other options because I haven't investigated enough yet, but people should definitely stop suggesting SL4A as a viable option to developing Android apps. It's not.
Due to the fact that you have to either assume users already have SL4A installed on their systems, or package it with your app, it's certainly not an ideal solution for developing a typical Android Market app. There are definitely a lot of specialized applications that it is well suited to address though, and it can also be useful to quickly prototype a tech-demo for an app that will later be fleshed out in Java or one of the NDK-supported languages.
Prototypes, sure, but people always mention it to say “You can write apps in Python on Android”. That’s simply not true.
SL4A is kinda like PhoneGap: you can use it, but you will not get a quality app out of it. That might be fine for your use case, but it’s definitely not on par to using the canonical platform.
Other quick notes: The last commit on the Scala for Android project is from two years ago and says “add 2.2 support”, the related blog post is from one year ago. Same deal with Android ObjC: last commit April 2010. I would never trust either of these for production development.
I’m sorry but languages other than Java and C++ for Android development are closer to vaporware than reality right now. The only good alternative is Mono http://xamarin.com/monoforandroid which is actually working and supported and not a forgotten weekend hack.
Please note: I’m perfectly fine with Java.
SL4A is kinda like PhoneGap: you can use it, but you will not get a quality app out of it. That might be fine for your use case, but it’s definitely not on par to using the canonical platform.
Other quick notes: The last commit on the Scala for Android project is from two years ago and says “add 2.2 support”, the related blog post is from one year ago. Same deal with Android ObjC: last commit April 2010. I would never trust either of these for production development.
I’m sorry but languages other than Java and C++ for Android development are closer to vaporware than reality right now. The only good alternative is Mono http://xamarin.com/monoforandroid which is actually working and supported and not a forgotten weekend hack.
Please note: I’m perfectly fine with Java.
Their other apps: http://itunes.apple.com/us/artist/super-racing-real-games/id...
From the looks of it, they're a total scam developer. How does this stuff get into the store? At least two of their apps use the logos of other apps with some quick filtering to change the colors.
I guess Apple isn't doing much more than a cursory check against trademarks when approving apps. That seems really dangerous. Copyright infringement procedures are well defined by the DMCA. Trademark doesn't have an equivalent law.
From the looks of it, they're a total scam developer. How does this stuff get into the store? At least two of their apps use the logos of other apps with some quick filtering to change the colors.
I guess Apple isn't doing much more than a cursory check against trademarks when approving apps. That seems really dangerous. Copyright infringement procedures are well defined by the DMCA. Trademark doesn't have an equivalent law.
To quickly follow up on your aside regarding how this might work for copyright issues (as opposed to for trademarks): the DMCA procedures do not apply to Apple due to their specific curation: they have forfeited any possible safe harbor protections, and the procedure for dealing with them is not simply a take down notice.
Thereby, if you have an issue with an app in the App Store, you can and probably should (as in, the American legal system will, in the end, fail to work correctly for you if you don't) directly sue Apple for any copyright infringement that occurs in their App Store. (Of course, most directly, what you should do is talk to your lawyer. ;P)
(I am not a lawyer, but I do run Cydia, the alternative to the app store that distributes substrate extensions for jailbroken devices, and have in the past run other systems such as Cyrket. I thereby have received a fair number of C&D's myself, and have had my own lawyers brief me on these matters.)
(That said, Cyrket had DMCA safe harbor and for Cydia I only host my own work, so I can easily and often be fuzzy about details as they might apply to companies like Apple. It is interesting, though, to hear at conferences from people at Google about the balance the Android Market must keep to maintain their DMCA safe harbor.)
Thereby, if you have an issue with an app in the App Store, you can and probably should (as in, the American legal system will, in the end, fail to work correctly for you if you don't) directly sue Apple for any copyright infringement that occurs in their App Store. (Of course, most directly, what you should do is talk to your lawyer. ;P)
(I am not a lawyer, but I do run Cydia, the alternative to the app store that distributes substrate extensions for jailbroken devices, and have in the past run other systems such as Cyrket. I thereby have received a fair number of C&D's myself, and have had my own lawyers brief me on these matters.)
(That said, Cyrket had DMCA safe harbor and for Cydia I only host my own work, so I can easily and often be fuzzy about details as they might apply to companies like Apple. It is interesting, though, to hear at conferences from people at Google about the balance the Android Market must keep to maintain their DMCA safe harbor.)
I highly doubt that curating the market removes the safe harbor immunity. They are no longer a common carrier, perhaps, but that's orthogonal to the DMCA safe harbor.
I appreciate your doubt, but am having a difficult time matching it up with the law. In specific, the DMCA safe harbor provisions only apply to entities that can be called "service providers", and Apple's prior-to-posting editorial control over the contents of their catalog then seems to be incompatible with the definitions that are laid out in USC § 512. Apple, playing the role of online retailer, thereby seems to be every bit as responsible for the content of their App Store as if they were to be hand-compiling printed catalogs of products for their own mail-order company for which they stocked their own inventory.
In comparison, Google pulls some ludicrous stunts to maintain separation: developers sign up separately for a payment merchant account (yes, also from Google ;P) and are legally responsible for things like their own sales tax collection (yes, this is insane). Google, then, attempts to claim that they are just a mechanism to allow direct-from-developer-to-user sales of products, and that their catalog is nothing more than web hosting. (This also has the horrible side effect, of course, that even if someone at Google has reason to believe something is sketch in their store, they have to not touch it and wait for something to come through channels.)
In comparison, Google pulls some ludicrous stunts to maintain separation: developers sign up separately for a payment merchant account (yes, also from Google ;P) and are legally responsible for things like their own sales tax collection (yes, this is insane). Google, then, attempts to claim that they are just a mechanism to allow direct-from-developer-to-user sales of products, and that their catalog is nothing more than web hosting. (This also has the horrible side effect, of course, that even if someone at Google has reason to believe something is sketch in their store, they have to not touch it and wait for something to come through channels.)
I think Apple's position is "it's not our job to police your trademarks, since you don't tell us when you license them to developers".
I am pretty certain that would not hold up in court: because they do very specific curation of their App Store (including reading the descriptions for content and vetoing certain forms of text), they are legally liable for all of the content displayed in their catalog.
In fact, due to the way the American legal system works (with our concept of "joint and several liability"), Apple would probably end up paying any and all trademark damages, and would then have to go after the developer to recover as much as they could themselves.
In fact, due to the way the American legal system works (with our concept of "joint and several liability"), Apple would probably end up paying any and all trademark damages, and would then have to go after the developer to recover as much as they could themselves.
Nope. When I first submitted SharePics the logo had a white space at the bottom. They rejected it because they said it looked like a Polaroid. Apple needs to be more consistent, either curate the hell out of it, or don't. Inconsistent application of the rules make it more confusing for naive users.
Not only naive users, it makes it pretty hard to get a feeling for what's acceptable even for seasoned developers with good intentions. (Volume button for camera, anyone?)
Apple does respond to complaints from trademark holders. It's not Apple's job to determine trademark infringement; it's the job of the trademark holder to protect their marks. When Microsoft files a complaint, Apple will take down the offending app, assuming the violation can be proven. The burden of proof (as in the courts) is on the trademark holder, not the seller.
They usually do catch or question or flag apps that can't provide license to use trademarks. We publish apps using well known apps and they sometimes get rejected until we can prove we have permission by the mark holders.
Apple's job is not to do a check against trademarks when reviewing an app. They test for bugs and malicious code. The test private API's aren't being used and they check it meets the public guidelines document.
I've released an app before which infringed on a trademark (accidentally, I didn't realise the name of this sport was trademarked). The owner of the trademark emails Apple, who forwards it to the developer who is told to take action immediately and respond to the trademark owner. If there isn't a quick resolution Apple will take down the app. They even have a check box when you are submitting an update which tells them if you are updating for a legal reason. I presume they would then expedite the review process.
I've released an app before which infringed on a trademark (accidentally, I didn't realise the name of this sport was trademarked). The owner of the trademark emails Apple, who forwards it to the developer who is told to take action immediately and respond to the trademark owner. If there isn't a quick resolution Apple will take down the app. They even have a check box when you are submitting an update which tells them if you are updating for a legal reason. I presume they would then expedite the review process.
oh they do check - this is either a total oversight or an inside connection that the developer has.
> inside connection
The app store feels like some corrupt east european kleptocracy. Your only chance to get featured is if you have some inside connections. And if you need "special" functionality in your app - no problem! Inside connections help again.
The app store feels like some corrupt east european kleptocracy. Your only chance to get featured is if you have some inside connections. And if you need "special" functionality in your app - no problem! Inside connections help again.
Apple, just a few days ago, also approved (and pulled once there was a lot of online press being caused by it) a fake Cydia. (Cydia is the alternative to the app store that distributes substrate extensions for jailbroken devices.) A bunch of people bought it and then left reviews saying that they had been ripped off.
http://cache.saurik.com/tinyimg/cydiascam.png
http://cache.saurik.com/tinyimg/cydiascam.png
Sorry, but I find that hilarious. Who in their right mind would believe that Apple would let Cydia into their own store?
Of course, Apple shouldn't have let the scam app through either, and should remove it ASAP, but consumers do have some responsibility to use their faculties.
Of course, Apple shouldn't have let the scam app through either, and should remove it ASAP, but consumers do have some responsibility to use their faculties.
That's fairly obvious to us. The problem is that Apple have created an environment where people are encouraged not to use their faculties. Apple insist on acting the way they do with the store, so it falls to them to make sure crap like this never sees the light of day. I mean really, which member of the Apple team allowed Word 2012 through?
Probably near closing time and failing to meet quota...
I mean, with the number of apps they have to check, it must be a sweatshop.
I mean, with the number of apps they have to check, it must be a sweatshop.
I'd be very interested to know in which country these app reviewers are, whether they're educated, whether they're being paid well, and how the working conditions are for them.
You should ask Mike Daisey to check that out for us.
Funny! I prefer non-fiction.
http://www.newyorker.com/online/blogs/evanosnos/2012/03/mike...
http://www.theatlantic.com/international/archive/2012/03/the...
http://www.newyorker.com/online/blogs/evanosnos/2012/03/mike...
http://www.theatlantic.com/international/archive/2012/03/the...
Yeah, it was meant a joke, but either people didn't get it, or people don't like it. I should know better than to try to be funny.
Considering the scams people fall for on the web, I'm hard pressed to see this as something Apple created - or do you think social engineering attacks didn't work before the app store?
You'd think they would know about your app by now and not even let it get approved. ;)
(Amazing work btw, you rock.)
(Amazing work btw, you rock.)
Was it paid, or free? (I kinda know the answer, just want to make sure!)
I had said "bought it", but I did not indicate the price: $0.99.
Maybe it's because it is in Apple's interest to get people pissed off at Cydia?
To take this question seriously fr a moment: the reaction is more to undermine the trust in the App Store's curation; this I one of those scams where the moment after you fall for it you know, in hindsight, that you've been had, so you don't seek retribution on the person being impersonated.
Or more reasonably one of the people reviewing the apps had never heard of Cydia.
Remember the reviewers are the equivalent of tele-sales positions. They aren't necessarily from technical backgrounds.
Remember the reviewers are the equivalent of tele-sales positions. They aren't necessarily from technical backgrounds.
I thought it was interesting that the seller's last name was Potemkin:
http://en.wikipedia.org/wiki/Potemkin_village
http://en.wikipedia.org/wiki/Potemkin_village
This is so deceitful. If they weren't trying to swindle people they would have named it "Tips and Tricks for Microsoft Word" or "Microsoft Word 2012 Helper". This product is not "Microsoft Word 2012" and they should not get away with naming it as such. I rarely say this about small companies, but I hope they get sued into bankruptcy by the big M. Most importantly, I hope everyone who purchased it gets their money back without having to ask.
Out of all of the reasons why this is crazy including a misleading title and screenshots, I just can't believe the app size is 121MB.
Looks like it contains videos too.
The price is pretty ridiculous too. I would have bought it simply for the novelty if it wasn't $10.
I believe that's part of their magic trick. I don't think as many people would rush to think it's the official MS Word if it cost only $1.
The price, app size, screenshots. Everything is misleading, except the one thing most people don't even look at, which is the text description.
The price, app size, screenshots. Everything is misleading, except the one thing most people don't even look at, which is the text description.
Yeah, they deliberately made the in-app interface look like a mobile word processor. Which is really, really deceitful.
I only have very specific first-hand knowledge, but Android's OneNote application is free, released by Microsoft. If you think about it you'll likely come to the conclusion that Word wouldn't be free, but at first blush I'd believe it.
The app store is full of scams right now, and Apple doesn't seem to care, they just want their cut. Apple is more interested in banning whoever competes with their own offerings (BitTorrent clients, Music stores, etc.) than actually reviewing apps.
Looks like the walled garden's walls are pretty easy to hop over these days.
So when Microsoft wants to submit the "real" 'Microsoft Word 2012' to the app store, how does Apple handle the name conflict?
Can I go and submit an app under the name of every existing company name I can think of, just like domain parking?
Can I go and submit an app under the name of every existing company name I can think of, just like domain parking?
Considering that Microsoft Word is a registered trademark of Microsoft that the author of this app is presumably not licensed to use, I would think that Apple should have no issue removing it.
[deleted]
"How quickly can you page numbering?"
A question for the ages, indeed.
A question for the ages, indeed.
This is a "great" scam. I can't belive people is falling for it. But worst, I can't believe Apple "stantards" approved this one.
It is incredible the amount of people that doesn't read at all. Not even the small description.
> "stantards"
Not sure if typo or insult.
Not sure if typo or insult.
reminds me of The Asylum film studios - they do the same thing, except for movies. I've been tricked into renting their movies instead of the real ones before, when I had forgotten the correct title.
http://en.wikipedia.org/wiki/The_Asylum
http://en.wikipedia.org/wiki/The_Asylum
Yes! I went from very confused to very angry when I watched "Battle Of Los Angeles" on Netflix streaming thinking it was "Battle: Los Angeles". And that didn't cost me anything (other than the 20 minutes wasted before I realized I had been tricked).
To be true, this mockup movie was not much worse than the "original".
The description sounds hilarious and man I am loving the grammar:
Description:
Every modern person some time or other is faced with Microsoft Office Word. However not everyone knows it to perfection! "How quickly can you page numbering?" How about adding and changing the page header? If takes more than a minute, this program is for you! Now you always have a list of tips which makes any Microsoft Office task easy and simple.
Seems like the developer tried to make this version of Word less sucky...
Description:
Every modern person some time or other is faced with Microsoft Office Word. However not everyone knows it to perfection! "How quickly can you page numbering?" How about adding and changing the page header? If takes more than a minute, this program is for you! Now you always have a list of tips which makes any Microsoft Office task easy and simple.
Seems like the developer tried to make this version of Word less sucky...
Utter joke. Some app reviewers must be getting bribed - no way they can miss this scam app!
Seems to be already removed, at least that's what I see from Europe with a U.S. account.
Remember that whatever amount of money is this publisher making, Apple is taking a 30%. Maybe they don't put too much effort on their side on purpose, just saying.
Remember that whatever amount of money is this publisher making, Apple is taking a 30%. Maybe they don't put too much effort on their side on purpose, just saying.
Apple breaks even on app sales, and has done so for years. The 30% of paid apps is used for developing the Xcode software and SDK, evaluating app submissions, advertising, affiliate programs, payment processing, storage and bandwidth.
Also remember, Apple pays the storage and bandwidth for all the free apps, which devs can submit for free.
Also remember, Apple pays the storage and bandwidth for all the free apps, which devs can submit for free.
Is there a link to this that doesn't want me to install iTunes? For some reason, some iTunes links do not hit people with a paywall but some (such as this) do.
Is it just me or has the app been removed? Saw it earlier on, and indeed, what a scam.. Can't believe it got approved!
unless they changed it before now, the text specifically reads that its a tutorial app, and has tips, not pretending to be a full Word client... mind you, how many people bought it not reading the text fully? how many dident look at the screen shot? And if that was a lot of people, i am releasing a Microsoft Excel and Outlook app for the iPhone/iPad later on... free money from what i can only imagine are people with too much feeking money...
I'm willing to bet a fair number didn't read it. Given one of the reviews:
>Very Stupid App!!!!
This is just a waste of money. Don't buy this app because you cannot even write a document!!!!!!
But that's about par for the course. The dissatisfied ones are always the loudest. I do highly doubt they had permission to use the Microsoft trademark in that way though.
>Very Stupid App!!!!
This is just a waste of money. Don't buy this app because you cannot even write a document!!!!!!
But that's about par for the course. The dissatisfied ones are always the loudest. I do highly doubt they had permission to use the Microsoft trademark in that way though.
> I'm willing to bet a fair number didn't read it.
Why would I? I'd personally have assumed that no Apple reviewer would ever permit a developer named "Super Racing Real Games" to use the Microsoft Word logo and name for an app. They're supposed to be there to protect against this sort of stuff, so I can't blame folks for not reading too closely.
Why would I? I'd personally have assumed that no Apple reviewer would ever permit a developer named "Super Racing Real Games" to use the Microsoft Word logo and name for an app. They're supposed to be there to protect against this sort of stuff, so I can't blame folks for not reading too closely.
Are developers able to change the name of their app after it is approved and published in the app store? Because, if so, there might be a reasonable explanation for this mistake:
1. Developer submits app named "Tips for Microsoft Word". 2. App is approved. 3. Developer changes app name to "Microsoft Word 2012". 4. Profit?
1. Developer submits app named "Tips for Microsoft Word". 2. App is approved. 3. Developer changes app name to "Microsoft Word 2012". 4. Profit?
No, you cannot change the App name once the application is in the app store. On top of that, all app names must be unique.
Yes you can.
Just a few days ago, 'The EagleBook' changed its name to 'The CIA World Factbook', for example: http://itunes.apple.com/us/app/eaglebook-cia-world-factbook/...
Just a few days ago, 'The EagleBook' changed its name to 'The CIA World Factbook', for example: http://itunes.apple.com/us/app/eaglebook-cia-world-factbook/...
You can change the name, but to do so requires you to change the app metadata in XCode, rebuild a new binary, and upload it back to iTunes Connect like you would any other update.
That would trigger another round of reviewing, so in theory you shouldn't be able to "sneak" a name change past Apple.
That would trigger another round of reviewing, so in theory you shouldn't be able to "sneak" a name change past Apple.
Exactly, not sure why I got the down-vote above. You can't simply edit the app name and change it after the app has passed review.
Maybe because a lot of people thought you were implying App names can't be changes, period (I upvoted you btw!).
I'd imagine Apple has to review and approve the change, though.
> They're supposed to be there to protect against this sort of stuff
no... They are here to protect their bottom line, their business, their interests, then, maybe, their customers... Its a business, not a charity. App seems to be missing now, so cant confirm its the Word Logo, but i dont think it was the actual Word Logo... and if you are blindly buying apps based on their name, well, I will sell you the Golden Gate Bride*
* Bridge may not actually be included...
no... They are here to protect their bottom line, their business, their interests, then, maybe, their customers... Its a business, not a charity. App seems to be missing now, so cant confirm its the Word Logo, but i dont think it was the actual Word Logo... and if you are blindly buying apps based on their name, well, I will sell you the Golden Gate Bride*
* Bridge may not actually be included...
Totally... that developer sounds like a kids name. Also the logo looks a little bit crappy. Even for a noob.
- Fruit Defense (ripoff of Fruit Ninja): http://itunes.apple.com/us/app/fruit-defense/id527599882?mt=...
- File Manager (a game!): http://itunes.apple.com/us/app/file-manager/id529097807?mt=8
- Orient Fight (icon is a ripoff of Temple Run's): http://itunes.apple.com/us/app/oriental-fight/id527894964?mt...
- F1 Birdie Driver (bird looks like an angry bird): http://itunes.apple.com/us/app/f1-birdie-driver/id529098374?...
- Slider Customizer (obviously does nothing): http://itunes.apple.com/us/app/slider-customizator/id5316330...
- Videogram Pro (ripoff of Instagram, with almost the same icon): http://itunes.apple.com/us/app/videogram-pro/id529801444?mt=...
- Tapped (ripoff of Bejeweled): http://itunes.apple.com/us/app/tapped-./id527589234?mt=8
- Real Robot Attack (I know it's a ripoff of some famous game, but I don't remember its name): http://itunes.apple.com/us/app/real-robot-attack/id529803195...
- Two other shitty apps: Beauty Meter (http://itunes.apple.com/us/app/beauty-meter!/id527010584?mt=...) and Oldity Meter (http://itunes.apple.com/us/app/oldity-meter/id529098528?mt=8)
---
This is why I sometimes get mad at Apple. I do believe they have the right to curate their store, but I think they should do it more vigorously and reject every single shitty app, and ban those developers. App Store is getting filled with these crap...