> this is the kind of app that would never have been legal at all on any version of iOS.
Pythonista is a complete Python programming environment which provides access to camera, music, contacts, the network, and so on, and has been available for iOS since 2016. What specifically distinguishes Droidscript from Pythonista such that you think Apple would reject Droidscript?
Droidscript has support for writing custom intents, which Pythonista (and Scriptable, a JavaScript version of the same thing) do not have. A malicious Droidscript application could access other applications on the device.
I've done some, although not a lot of, native Android development and I'm not quite sure what's so bad about sending intents. "Could access other applications" sounds dangerous, but as far as I know that "access" is limited to things those apps have explicitly decided to allow external apps to access.
Probably it's not the capability to send custom intents. Everytime i buy a new device, i look for apps with unknown or curious names, check the manifest and use an app like Intent (https://play.google.com/store/apps/details?id=krow.dev.schem...) to poke around.
Applications could be exposing intents they assume will be used by trustworthy applications (i.e. apps in the Play Store). A user could download a Droidscript (which as I understand doesn't trigger the unknown sources policy) which then tries to use intents it shouldn't need without asking the user for permission.
If Droidscript required unknown sources to do anything (not just APK exports), then other apps could check the unknown sources policy on the device and disable certain intents (which they may do anyway at the moment, since that would mean that the applications installed may be untrustworthy). But this way there isn't any way to tell.
trustworthy applications (i.e. apps in the Play Store)
Please don't equate trust with any app store like that. Firstly, many incidents have shown that this blanket trust isn't warranted, and second, the final arbiter of trust is the owner of the device, not the owner of the app store.
100% false. When a user buys iOS they willingly (maybe not stating 'I relinquish my control to Apple', but implicitly) give up a degree of freedom in determining who they trust to Apple. It's well-known that you can only get apps from the App Store when using iOS.
> Applications could be exposing intents they assume will be used by trustworthy applications (i.e. apps in the Play Store).
This is a poor assumption to make. Any data coming into your application should be assumed to be malicious. This would be the same as a server just accepting any data made to its API calls without any validation.
I know that this has but a fat chance of being taken seriously by Google but... Isn't this a good chunk of the reason why people here on HN and elsewhere have been arguing for much more granular intent management on Android like they had in the early days?
When we get permissions boiled down to one or two popups we end up with issues providing accurate privileges to applications (and might be forced to allow WhatsApp to trawl through our contact list if we ever want to send a picture in it).
Granular control shifts the power to the user and allows programs like this to have more fine tuned privileges.
I disagree - it turns into users clicking through piles of crap if you've got a crap UX. If the UX is well tuned to display this information and let the user break out to greater levels of detail or keep things simple then you can find a good middle ground.
Given the amazing strides in usability we've seen in nearly every other field it baffles me why everyone isn't onboard with the fact that we can take the learnings from elsewhere and bring them to the domain of permissions.
Permissions are almost always hierarchical and grouped into classifications that make it easier to present the user with fewer more meaningful choices than asking the user to approve whether an app can see each contact on their phone one-by-one.
I'm honestly a bit cynical (puts on tinfoil hat) that marketers have held us back here since a lack of granular permissions aligns quite well with their effort to grab as much personal data as possible.
There's so many crazy gotchas in android permissions, though... eg, most users won't know that there's a connection between wifi and geolocation data. That's a non-obvious connection with a real trade-off: the app might have some interesting wifi-based functionality, but in exchange the app authors might harvest your geo data.
Consider the permissions for the lowly keyboard app...
A proper understanding of fine-grained permissions basically requires a working knowledge of how that permission might be or has in the past been abused.
And ultimately, fine-grained permissions are probably answering the wrong questions. The user expresses some basic trust via the initial app installation; what permissions ultimately help with is deciding whether or not to keep trusting the developer. If the app ask for lots of unexpected stuff, it's probably malware and should be uninstalled. If the permissions seem reasonable, the app is probably fine, and the user just wants to delegate responsibility to the app to do what it needs to do to get shit done.
It's really /all/ about trust. If you can't trust a random app, installation is a high-friction event. Check the stars, number of users, read a bunch of recent reviews, carefully go through permissions providing access for exactly what's needed. If you /can/ trust a random app, you can just install it, use it to read the fscking QR code and go on with your day. The need for trust is why we've ended up with centralized app stores with stringent content policies, and all the false positives that come along with it.
Android's fine-grained permissions system isn't a good fit for something like Droidscript; one script could use a permission for valid reasons, then another could do something bad.
You can't access any random application just by sending intents. Available intents must be exposed to other apps if desired - for example, the camera app has a "show the camera for taking a photo" intent.
If you don't want another process sending you an intent, don't export your entry point. This isn't hard. Security through obscurity is no security at all.
You can't use it to create a backup script to online backup your phone data. For good measure iOS also blocks all apps since they would lose iCloud revenue.
Pythonista is a complete Python programming environment which provides access to camera, music, contacts, the network, and so on, and has been available for iOS since 2016. What specifically distinguishes Droidscript from Pythonista such that you think Apple would reject Droidscript?
https://apps.apple.com/us/app/pythonista-3/id1085978097