Does Apple have a way to find out that an application already is in the Cydia store when I try to submit it to the AppStore?
For Example, if I change the name and icon for an application that appears already in Cydia and try to submit it to AppStore? Can Apple find out?
Is it possible that Apple collects statistics about jailbroken phones and their applications and has this data in its db (by sending it in some background process)?
First of all, I'm assuming that the existing app on Cydia is your app. I certainly don't condone stealing some other developer's intellectual property, just because they released a Cydia store app.
To answer your questions:
Yes, of course. They can just use Cydia themselves and search for your app's name. They could certainly also just use a desktop browser and search for your app's name, to see if there is any obvious copyright infringement. While I don't think Apple feels obligated to do this, I have had apps rejected (before ever being released) because Apple believed my client was violating some other 3rd-party's intellectual property. This kind of search could also turn up a listing in a Cydia store repository. So, it is possible.
I very much doubt Apple would find out about this. Simply renaming the app seems likely to avoid any problems.
I'm not sure I understand the question. Are you asking if iOS checks to see if the device it's running on has been jailbroken, and if so, reports that status back to Apple? I don't know, but millions of users run jailbroken phones, and I haven't seen Apple try to disable their functionality.
I have had clients release apps on the Cydia store first, and then try to release them on the iTunes App store. Although none of those have been approved by Apple, they have been rejected for private API usage, or violation of Apple's Human Interface Guidelines, not because they already existed on Cydia.
I suppose that if an app was released on Cydia, because it used private APIs, and then iOS later added that capability in public APIs, then you could try to submit it to Apple.
I don't work for Apple, so these are only my guesses based on personal experience.
It depends on the repo you put it on. If you put it on a personal repo im sure you will get away with it. It depends on what your app does, it shouldn't really matter to apple as long if it doesn't mod, exploit, change, or use a private API or do any illegal acts/violate copyright it should go right past apple's appstore. They monitor and last time I heard check code manualy.
Related
ASP.NET Form. If running a form in a browser on a small (Android) device with a barcode scanner, will the scanned barcode go into the ASP.NET textbox? Or I need to add something to the application?
Well, it going to depend on which of the 150+ barcode scanners you decide to grab from google play.
However, the answer is yes, or no. It will depend on the kind of scanner.
If you download just a scanning application (software based - not built in scanner).
The reason is Android (and even iOS) don't allow one application to set focus, get/grab/take data from other applications. Nor is the reverse allowed. If that was possible, then the app could also get/grab/take values from when you are say running your on-line banking application.
I don't think Android thus supports focus to another application during scan that has focus. Now if this is factory supplied software on the phone? Then yes, this works like a desktop keyboard "wedge". That means the program does not know if you are typing from keyboard, or input is from the scanner (hence the name keyboard wedge). These will work with a web form.
However, we now seeing the rise of software based keyboard wedges. That means the software scanner is installed on android as a custom keyboard. And this in case, then once again, it will work in a web form.
So, for devices with a built in scanner? yes, that will work in all applications. For a software only (uses built in camera), then again, this is possible if the software in question works as a keyboard/wedge scanner.
If you going to adopt android scanning? then use a purpose built Android scanner.
And another possible if you want to use a software scanner? Write a small android application and have it talk to your web site. This I think is the best solution, but of course means you have to adopt some Android dev tools.
So how this works will depend on if the android device has a built in scanner, or it is a software + camera based scanner. However, it would seem that even now installable software based scanners in theory can be made to work for any application since the application is running and behaving as a user installed keyboard.
So, you have to check the particular device. The answer is not in all cases, and the answer depends on if you using a Android device with a built in scanner, or you looking to use any Android phone as that scanner.
Our app has been in the Play Market for 4 years.
Before the last build, we added AppMetrica in the app:
implementation 'com.yandex.android:mobmetricalib:3.13.1'
implementation 'com.android.installreferrer:installreferrer:1.1.2'
implementation 'com.yandex.android:mobmetricapushlib:1.5.1'
The project with these instruments was successfully uploaded into the Play Market without any notifications (errors or warnings). In a few weeks after that, I made minor changes in sending reports in the AppMetrica and received the following notification from Google:
"We reviewed XXX, with package name XXX, and found that your app uses software that contains security vulnerabilities for users. Apps with these vulnerabilities can expose user information or damage a user’s device, and may be considered to be in violation of our Malicious Behavior policy.
Below is the list of issues and the corresponding APK versions that were detected in your recent submission. Please migrate your apps to use the updated software as soon as possible and increment the version number of the upgraded APK.
Vulnerability TrustManager You can find more information about TrustManager in this Google Help Center article."
We don't use TrustManager and his classes in the project.
What can be the possible reason for rejecting? Is it possible that this rejection was made by mistake? How can we find out what is the reason for that? Can AppMetrica cause this setback and should we stop using it?
Also, in the rejection text they said you can set up the network config (https://developer.android.com/training/articles/security-config) in the app -- how can it help?
We are fighting this trouble for two weeks and we hope for your help
I have been using different techniques for jailbreak detection and it was working fine till iOS 11.4. However when I upgraded my iOS to latest 11.4.1 it is showing me the device is jailbroken when the device is not. This issue we are facing only in iOS 11.4.1 and iOS 12 Beta.
Following were the techniques we are using:
1.Process forking
2."CydiaApp" Scheme Detection
3.Check for suspicious/root folders and files
4.Check for folders that was created during the jailbreak process
5.Check for write permission for non user folder
Is there any thing related to these files and folder access permission we are doing wrong to detect the jailbreak detection?
Any help will be appreciated.
But which one is actually gives you false positive?
If I were to guess, I would say that checking write permissions is not reliable. The way that iOS protects unauthorized access to system files is not with permissions but mainly with sandbox profiles. With that in place Apple can assign any permissions they want to system files, sandboxing will still protect the system. Even when you jailbreak your phone you still have sandboxing in place (don't remember any jailbreak that would disable sandboxing completely) and often limited by it when, for example, injecting your CydiaSubstrate dylibs into system daemons/applications that operate under sandbox profiles. That's the whole security of iOS - code signing, entitlements, sandboxing, IPC. No need for POSIX permissions which Apple actually doesn't use that much.
Checking for suspicions directories and files could also give you false positives and is not very reliable in general. Apple often changes it's root file system, you never know what might be in the new iOS version. Of course, if it's related to Cydia then it should be ok.
And that's, in part, why Apple doesn't like AppStore apps checking for jailbreak and often rejects them because of it. Not only you try to access something you shouldn't, which makes it hard to distinguish between jailbreak detection and actual usage of private API to circumvent iOS security. But given that jailbreak is all about very specific kernel patches and things that you wouldn't have access inside AppStore app due to sandboxing anyway (launching unsigned binaries, modifying root partition), there's no reliable way of detecting jailbreak in general. Forking, Cydia, support for CydiaSubstrate - all of that is optional and depends on specific jailbreak implementation. With recent jalbreaks that's even more relevant - all of them are very different and not completely finished lacking some features that were standard in the past. Even more importantly, if Apple decides to change something in iOS, in might trigger jailbreak detecting code by accident. False positive is much worse than false negative.
In the end, no matter what you do, every jailbreak detection code can be easily patched or hooked. When you're in control of the system, apps are no longer able to protect themselves. That's all offtopic but it's a good reason to just ignore jailbreak.
I haven't had much success searching for this. I'm developing an Android Things application that will connect to a user phone to do certain things. I want to use this for delivering app updates as well.
So far, my crude searches on this have just discussed OTA via the Console and thus internet.
My gut has said that I could just build this - I could have a new version of the APK, transfer it to my device via bluetooth, and then just have the device copy it over the old one and reboot. But, not sure. I was hoping maybe there was an API for this and I'm just not wise enough to know how to find it via the searches.
Chrome is on the verge of definitly break compatability with NPAPI, and IE breaking with ActiveX the future of Java Applets is dark. Currenty we actively use a secure applet for out client organizations that enables their users to upload a bunch of files from their file system to our servers with the click of a button. The applet has full access to any configured drive, including network drives.
With the imminent death of the applet this functionality is going to be lost if we don't find an alternative. I have already tried to explore different solutions, including the chrome FileSystem API but that is currently only available for Chrome (http://caniuse.com/#feat=filesystem) and has limited access.
Does anybody know about an alternative to keep supporting the much appreciated functionality? Unfortunately we are obligated to support all browser down to IE8.
I've written a post about this here.
Once Google Chrome was the first to announce that they won’t be supporting NPAPI anymore, they were also the first to provide a new architecture in order to rewrite your code to work on their browser. You can take a look on Native Messaging, which “can exchange messages with native applications using an API that is similar to the other message passing APIs”. The problem is that this approach only works on Chrome, is not something that you can adapt to other browsers.
A more useful approach is FireBreath, a browser plugin in a post NPAPI world. Check the words below from one buddy of the project:
“FireBreath 2 will allow you to write a plugin that works in NPAPI, ActiveX, or through Native Messaging; it’s getting close to ready to go into beta. It doesn’t have any kind of real drawing support, but would work for what you describe. The install process is a bit of a pain, but it works. The FireWyrm protocol that the native messaging component uses could be used with any connection that allows passing text data; it should be possible to make it work with js-ctypes on firefox or plausibly WEB-RTC or even CORS AJAX in some way. For now the only thing we needed to solve was Chrome, but we did it in a way that should be pretty portable to other technologies.”
In light of the answer provided by Uly Marins I have researched the options suggested. Unfortunately these options weren't viable for our application, because the mayority of our users do not have sufficient rights to install third party plugins. Additionally the API is still in Beta which won't do any good in a stable production environment.
The main problem we wanted to solve was the abbility to delete files from the accessed folders. It seemed like one of the mayor goals of the removal of the NPAPI support was exactly to prevent this kind of possibility. Therefore we needed to reduce our goals to a simple solution that was still acceptable for our users, with the additional training on how to clear the selected folder manually (because most of our users are almost computer illiterate and needed to access network folders).
Long answer short. The requested solution is just not possible anymore and had to be replaced by a simpler solution and additional training.