Hacker News Reader

Comment by ajross | Hacker News Reader

Time for one of these again.

So... having read through their marketing material, this is an on-device tool that opens up what appears to be most of the Android application API to at least the user of the device, and potentially to any Droidscript applications they grab from other sources, and... maybe to other apps on the device? It's not clear from a quick read how extensive the runtime control is.

So just right out of the gate this is defeating basically the entirety of the Play Store vetting process. Droidscript itself may not be engaged in advertising fraud, but it makes advertising fraud trivial to deploy. (And it needs to be said: this is the kind of app that would never have been legal at all on any version of iOS.)

Add to that that it's a closed source IDE for an open platform, and my intuition sides with Google here. My guess is that when details come out it will turn out that at-least-plausibly harmful Droidscript garbage was being pushed to users and Google decided to kill it.

View on HN

> 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?

https://apps.apple.com/us/app/pythonista-3/id1085978097

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.

https://symdstools.github.io/Docs/docs/app/SendIntent.htm

Are Play Store regulations the only defense against this kind of attack? If so, then yikes!

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.

Why was this downvoted? It seems like a reasonable comment.

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.

> 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.

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.

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.

Alas, granularity very quickly turns into users clicking through piles of crap without thinking about it. With great power comes great user error.

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.

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.

I’m sure they’ve already lost a lot of money to Google Photos’s previously-free photo backup.

I think your thoughts on this are plausible, if not likely. However, the usual complete lack of communication by google is the actual problem. Perhaps droidscripts could mitigate googles concerns, if they had the decency to explain them.

> However, the usual complete lack of communication by google is the actual problem.

Uh... Seems like the actual problem (given that scenario) is that adware is being pushed to users, not whether or not Google defended its ban in public. Complaints about customer service (from everyone, not just Google) are a dime a dozen, actual user security is clearly more important, right?

Your answer presupposes a frame where Droidscript is innocent. What if it's not, and it knowingly nodded to a community of junkware being pushed to its users (again, I have no evidence!). In that case you'd want it banned without "decency", right?

Banning it first is fine. banning it first, then not giving a reply to the concerns they have is not. Even if they have reasonable believe or proof that droidscript is indeed malware, it looks like at least a chunk of their userbase uses it for legitimate usecases and the devs, who likely invested at least a few hundred hours of work in it, deserve at least some communication.

I used to work at Google, and a friend reached out to me for help – his company's app was in a similar situation, with similar communication from Google. This was a good friend from high school, so I pressed the issue using internal channels. The person handling it on Google's side was very assertive about them violating a policy, and after some back and forth I received a _vague hint_ about what was the supposed violation. I passed the hint along, and after some digging, lo and behold, it turned out one of their people had lifted someone else's images without permission, violating copyright (kudos to Google for figuring it out). My friend apologized profusely to me, to the support rep, his boss, and let the culprit go. They purged the app's assets, changed their processes, and eventually the app was reinstated.

Now, this was a special situation. I had a personal relationship with the developer, and I was happy to vouch for their honesty. Yet it still turned out Google had been right all along. Now, it's a shame Google couldn't let them know what was the issue. However, it's a safe assumption that the vast majority of people Google support deals with are spammers. And there's a lot of them. If Google gave a detailed explanation to all of them it would mean a ton of additional work – which would create an unsustainable situation at this scale.

> Now, it's a shame Google couldn't let them know what was the issue. However, it's a safe assumption that the vast majority of people Google support deals with are spammers. And there's a lot of them. If Google gave a detailed explanation to all of them it would mean a ton of additional work – which would create an unsustainable situation at this scale.

I don't think that's reasonable. What if most are spammers ? Better let a few spammers in than treat someone unjustly. Why would it become unsustainable ? I've seen this argument repeated ad nauseam, but have yet to see proper proof.

In this particular example, a copyright violation was detected in a image, so an automated response "someone else's image was used without permission, violating copyright" seems entirely plausible.

Google has the scale to do this, but they also have a large enough monopoly where they don't have to, so they won't. It's not that it's unsustainable, it's that it is entirely sustainable to continue doing things this way.

Can you elaborate? I can see how Google can scale this automatically. But I don't see how Google can terminate, say, one million apps a day, if each termination entitles the spammer a one hour conversation with a technical representative.

Make the person but the hour, say $100. It's a very different value proposition for some one saving their business vs some one trying to game a system.

Why does it need to cost them an hour conversation?!

Look at the tone-deaf example this employee just shared. All they had to do was say in the same email that they used to ban someone "you have copyrighted images".

The moment they find an infraction they could literally take a screenshot, say "the problem is X" and email it, which would incur the 5 seconds it takes to add a screenshot and say the problem you already identifies, but make a world of difference for developers.

This nonsense about "it's to stop spammers" isn't about the cost, the laughably bad logic Google uses is that by identifying what rules you broke, spammers will get better at not doing stuff Google catches...

As if the spammers don't already know what they did to get caught!

> In this particular example, a copyright violation was detected in a image, so an automated response "someone else's image was used without permission, violating copyright" seems entirely plausible.

Google should not be enforcing copyright in the first place without at least a report of infringement by the copyright holder - and in that case they should pass the report along to the developer.

If proper support is unsustainable due to the model, it is the model that has to change.

i disagree about unsustainability. there are real people on the other side of the business among these bots and spammers and if you ignore them because they might be bots and spammers, they'll leave and tell other real people that google can't be reasoned with because they assume everyone is a bot and a spammer.

you see exactly this happening all the time here on HN. the sentiment for the past few years is abysmal. google is actively blowing up their power user/developer customer base. looks like a metric somewhere got optimized a bit too well.

I think so as well. As a duopoly Google and Apple owe it to their customers and 3rd party developers to know why something gets banned. Being in that position requires special consideration to hold that much power. Government has to do it, why don't huge corps?

Caveat: I work at Google but know nothing about this area and my opinion here is entirely personal.

> which would create an unsustainable situation at this scale.

Financial sustainability may have something to do with it, but I suspect the larger issue is that providing too much detail essentially trains malware authors to route around the company's defenses.

Imagine the Play Store as a castle which has both good townsfolk coming and going as well as being perpetually under siege by a malicious lord. Sometimes, the castle's defenses inadvertently prevent a townsperson from getting to market to sell their onions. When the townsperson is like, "Hey, I can't get in to sell my onions." it's helpful for the castle defenses to be like, "Well, we have the portcullis raised from 9am-11am on Tuesdays and the gatekeepers listen for your accent to decide if you're a local or an enemy."

But that's, like, exactly not what you want to say if the "townsperson" you're talking to is actually an enemy spy taking notes.

Say it with me now:

>"Rough consensus, and running code. We are not the Protocol Police."

Half the problems we have nowadays is because we have manufacturers playing "the Program Police", which leads inevitably to the point you just made.

You are now, like it or not, adversarial to any User looking to do anything you find unconformant with your bottom line. You cannot solve these issues by whitelisting, just like you can't solve the problem of crime by whitelisting, and hiding the conformance suite. If you can't know the test, you can spend infinite cycles changing the wrong thing to comply with it, and I do not find that to be a tenable state-of-affairs to push on users, even if intentionally aimed at the malicious ones. This is the same problem we have in meatspace with our overly byzantine legal system; but nobody accepts that secret laws are a good idea because if everyone can read the law, it's a national security risk. At least no one without some serious conflicts of interest.

Do you really think that your company is going to nail down a good solution to a problem that society at large can't even handle reasonably? I mean, think about it. This really is a subset of the general question of how to keep everybody doing something productive. I don't even need an answer. I just want to encourage people to think.

> >"Rough consensus, and running code. We are not the Protocol Police."

This model absolutely does not work when it comes to creating spaces where humans interact. There are bad actors and someone has to police them or they will abuse other users.

If you run a bar, you have to hire bouncers. It's simply part of the cost of hosting a safe venue.

That doesn't seem to be a problem in this case? Telling spammers they are blocked due to copyrighted images trains them not to upload copyrighted images. Win-win.

picking up copyrighted images is another indicator that user X is a spammer, providing that info would eliminate the signal

Well, this is the essence of discrimination and we wouldn't tolerate it for a whole range of indicators (you're black, gay, if a particular race, etc etc). My guess is the real reason they won't tell people is that they would end up in court pretty quick.

so, in you mind, detecting copyrighted images and using that as a metric to detect spammers is discrimination? Are antivirus programs discriminating too??

I bet you indent your code in an inclusive way

From a definitional point of view yes. Using an attribute to place someone in a class and then making decisions on a class basis without actual evidence they possess the other attributes of the class is discriminatory behavior.

I suspect the larger issue is that providing too much detail essentially trains malware authors to route around the company's defenses.

Perhaps so, but it seems not unreasonable to have SOME ability to work with the creator of an app that's been on the store for years with a substantial number of ongoing users and (speculating) a non troublesome patten of installs and purchases.

Nobody believes that Google is technically out financially unable to do this, which leaves the other option - at a corporate level not giving a shit enough to even bother trying.

Google will often do the right thing whether by plan or by happenstance, but it pays to be aware that when it does the wrong thing there is no recourse and will be no correction.

I'm sorry, but the "security" excuse is BS. You don't have to tell users what automated tool flagged them or how their violation was discovered.

You do have an ethical obligation to inform them of what policy was violated with sufficient detail that a good actor has a reasonable chance of complying with your policy.

I think that this should be required of any company that to provides publicly available goods/services, not just Google. This doesn't just help with monopolies, but also makes it harder to hide racism and censorship behind opaque policies.

> However, it's a safe assumption that the vast majority of people Google support deals with are spammers. If Google gave a detailed explanation to all of them it would mean a ton of additional work – which would create an unsustainable situation at this scale.

You describe a situation where Google was going to put a whole company out of business -- probably ending your friend's job, as well as that of many other honest people -- rather than give them the information they needed to fix the problem. And you think this is reasonable, because it would be "a ton of additional work" for Google? We just have to accept people losing their livelihoods as collateral damage in the war on spammers?

Imagine if we applied the same logic to the government. If they think you committed a crime, they just toss you in jail and don't have to tell you why. They could catch a lot more criminals if they didn't have to waste time prosecuting them!

No, we need a Habeas Corpus for tech companies. If you are banned, you have to be told why. Make it a law. I don't care if it results in more spam.

I liked all of your comment, but this passage in particular:

> No, we need a Habeas Corpus for tech companies. If you are banned, you have to be told why. Make it a law. I don't care if it results in more spam.

The whole ordeal seems like an attempt to educate app developers by whipping, where the victims have to guess what they did wrong.

Yes, and: Efficient markets require fair & impartial courts, tort, transparency, accountability. Etc.

.. and P=NP

“The opaque email responses will continue until morale improves.”

> It's a safe assumption that the vast majority of people police deal with are criminals. And there's a lot of them. If they gave a detailed explanation of why they are under arrest it would mean a ton of additional work - which would create an unsustainable situation at this scale.

But it's all good, Google is a private company™ and can do whatever they want®.

Actually Google is a public corporation, not a private company.

They mean private in the sense of private sector vs. public sector, not equity trading.

> Yet it still turned out Google had been right all along.

No they weren't. It was not right to terminate the entire app because someone used an image wrong.

How can google even decide that a copyrighted image was used in an illegitimate way? They’d need to check back with the copyright owner to confirm that there is no license and they’d need to confirm that none of the various exemptions apply. This is also a matter that’s entirely between the copyright holder and the author of the app. I could understand if the problem was that the copyright holder explicitly notified google, but then that complaint could just be forwarded to the app owner with no information about any secret sauce being revealed.

> In that case you'd want it banned without "decency", right?

Due process isn't really a sound concept if it's only for innocent people.

> Seems like the actual problem (given that scenario) is that adware is being pushed to users

Google itself is adware.

But if they do, a malicious actor can use that information to circumvent their restrictions, and its their walled garden, so they have very little incentive to tell everyone exactly what they don't like.

That's the claim made by Google and many other big corporations. It's plausible enough, but I haven't seen any hard evidence that it's true.

Suppose it is true that these companies can't reveal their decision making because there's so much to be gained by bad actors that game these highly centralized systems.

Then it seems like a larger number of smaller firms could be more transparent and still achieve the same effective level of security.

And we have very little incentive to not complain loudly and publicly about their practices.

Okay, but this developer isn't "everyone", and there seems to be no reason not to explain in this case.

Unless the developer decides to share on Twitter or HN or w/e, and now malicious actors know as well.

I meant that this information is not a problem to share, and that sharing information in one case does not imply sharing it in all cases.

I know this is standard practice for most big companies moderating lots of content, but it has always seemed like such an insane policy to me.

Imagine if this were applied to actual laws enforced by the police. "You're under arrest but we won't tell you what law you've broken, because then other criminals might use that knowledge of the law to avoid being arrested. And by the way, a secret court has sentenced you to life imprisonment and all of your appeals have been denied."

Putting aside that law enforcement has very different risks & pressures from corporate moderation, you don't really have to imagine: US law enforcement have a tool called civil forfeiture which lets them seize assets suspected of being involved in a crime without charging the asset owners of any specific crime. The owners have to prove to the police that the assets were not involved in a crime to restore their property. The US also has FISA courts for sensitive matters, FISA hearings are secret and only involve the judge & government representatives without the presence of all relevant parties.

I'm not endorsing these US policies, but it's worth noting that even in democratic law enforcement it's accepted that the system isn't always bound by transparent policy and process. There are usually justifications for keeping some things secret and discretionary to enhance law enforcement effectiveness.

If their restrictions are so trivially circumvented... then they probably already have been.

This is the epitome of security by obscurity.

> Add to that that it's a closed source IDE for an open platform, and my intuition sides with Google here.

If I can't ship my closed source IDE on the platform is the platform really open?

> My guess is that when details come out it will turn out that at-least-plausibly harmful Droidscript garbage was being pushed to users and Google decided to kill it.

Of course they will say it was because x, y, and z were done to protect the users. But is it really for the users' benefit or just about control over their walled garden?

> If I can't ship my closed source IDE on the platform is the platform really open?

For clarity: the Play Store is not an open platform. The Android API being exposed by Droidscript very much is.

Fair, I misinterpreted what you were saying.

Sounds like effective lack of means of production available inside the platform is fundamental to sustainable platform...

Yes...Droidscript allowed one to use the tiny computer in their pocket similarly to the way one could use the large computer on the desk. One could script small apps on their tiny computer and they could access most of the same api as java apps. It was pretty awesome.

> My guess is that when details come out it will turn out that at-least-plausibly harmful Droidscript garbage was being pushed to users and Google decided to kill it.

Yes, I'm sure Google will carefully release details that paint them as the good guy. Certainly, we don't want to be needlessly unfair to them, but there is zero reason to give them free trust them at this point.

Google will not release details because Google doesn't care if they look like the good guy (otherwise they wouldn't do stuff like this in the first place!)

Best case is the right person sees this social media outcry, silently gets it fixed and Google moves onto destroying the next developer.

We're talking about a development tool. Of course it's going to make any use of the device possible -- that's the entire point. If the point here is that any development tool shouldn't be allowed in the store (which I think google and apple are mostly fine with), that's a pretty sad thing in my opinion. Maybe google is "right" in enforcing their policies, but is it helping anyone?

> Droidscript itself may not be engaged in advertising fraud, but it makes advertising fraud trivial to deploy.

No more than being able to build an app on my laptop and push it over ADB.

> (And it needs to be said: this is the kind of app that would never have been legal at all on any version of iOS.)

It also needs to be said that this is why I don't use Apple devices. What they inflict on their platform is not an argument for what should happen elsewhere.

> Droidscript itself may not be engaged in advertising fraud, but it makes advertising fraud trivial to deploy.

I think that this is what has happened. The author of DroidScript claims that

> Unfortunately we also have to inform our users that we could no longer support AdMob for use in their own apps either, because we can't test it anymore and can't guarantee that Google won't treat them in the same brutal way.

So apparently users were able to do stuff with AdMob on DroidScript's back, and maybe AdMob registered these fraudulent actions with some Google-ID which was assigned to DroidScript.

I don’t get your point. Sideloading apps was always possible on Android even without a jailbreak. We’re not in Apple world, so it’s unclear which Playstore rules got broken here.

Side loading is an Android OS feature, not a Play Store feature. Can you sideload via Play Store apps? F-Droid isn't in Play Store, but APK Manager is, so I'm confused.

You've always been able to use any of the web browsers in the store to download and install a random APK from a website (for example F-Droid), you don't even need to sideload it. Sideloading apps is mostly just a relevant concept for developers or for users who have no alternative to getting custom code on a device. (Edit: Speaking of ad fraud brought up by the GGP, there are also many automation apps, at least one (Automate) uses a plugin flow-chart architecture exposing all sorts of functionality, with users able to share custom scripts. Not to mention tons of plain "auto-clicker" apps.)

> Can you sideload via Play Store apps?

Yup. Check out aurora store. It's a open source frontend to the google play store. All apps can be installed(except of course paid apps. Though if you bought the app and sign in to the account with aurora you can)

Should the Chrome browser be also banned from Android since it is trivial to deploy ad fraud campaign on the web?

> but it makes advertising fraud trivial to deploy.

Compared to what? If someone wants to run a random APK that has some kind of ad fraud in it, they very easily can even if Droidscript doesn't exist.

The fact that Android Play Store had apps like that all the way back to the earliest days is precisely why some of us have an Android phone rather than an iOS one. There are full-fledged Lua, Python, C++, Java etc IDEs there.

Chrome is closed source and has developer tools, and has damn near every permission Android provides. You can app your apps on it, as long as they are of the web variety. Should we not ban chrome too?

If droidscript enables ad fraud, isn't it an issue with how the android sandboxing model is fundamentally broken? Given that there are far more people using phones than computers, and a lot of new smartphone users will have never used a desktop or laptop computer, droidscript might be their first venture into programming and/or hacking. Let's not shut it down.

Chrome polices websites with per-site permissions, controlled by the user. Does DroidScript give users the same level over control over 3rd party code?

Chrome does not provide raw access to the APIs from JavaScript. Instead everything is sandboxed to the hilt.

Also the product has a very heavy emphasis on security, the security team is superb quality and well funded, and Google know that the team is trustworthy.

Whatever "open platform" might mean Android is becoming less and less of one as Google has made huge efforts to move more and more core operating system functionality into closed source Play Services and continues to remove developer access to many APIs in the name of security. In fact what you're advocating for in this comment is to make the platform less open.

> (And it needs to be said: this is the kind of app that would never have been legal at all on any version of iOS.)

Exactly, iOS is not an open platform and Google has decided they want to be more like iOS.

That said, an open-source version of this on F-droid would be hella cool, but wrapping every API with Javascript sounds non-trivial.

> wrapping every API with Javascript sounds non-trivial.

I am not an expert in JS or the Android API, but I wonder if you couldn't do it automatically? If types line up closely enough, I would think that you could get a list of Android APIs (pull it from AOSP if you have to) and mechanically translate to a JS API.

If Android's JVM supports reflection, you could do it dynamically at runtime, and there are probably already JS+JVM integrations that would work.

Apache Cordova exposes APIs to JS.

Actually, ionic team recently released their native api solution as a library [0]. I think it might fit right in.

[0] https://github.com/ionic-team/capacitor

Drozer does (did?) this, except with Python rather than JS. https://github.com/FSecureLABS/drozer

Vetting process is just excuse for rent seeking, a better client ui for us to approve permissions would cost nothing.

https://news.ycombinator.com/item?id=26961550

Still seems strange to me they focused so hard on the ad fraud part of it, unless they had a sudden change of heart and needed an excuse to get Droidscript out of the Play Store. They could just as well simply have said that any app that allows for easy, arbitrary code execution is a security liability and won't be accepted on the Play Store, which does include a fair number of root-required tools that have been removed at some point before. I don't necessarily agree with it, but that'd be a pretty believeable justification.

My gut feeling says these devs aren't telling the whole story.

It looks like a mobile programming IDE.

You can code up Garbage in Java just fine and get it on the app store. I've seen apps send passwords in plain text....

> So... having read through their marketing material, this is an on-device tool that opens up what appears to be most of the Android application API to at least the user of the device, and potentially to any Droidscript applications they grab from other sources, and... maybe to other apps on the device? It's not clear from a quick read how extensive the runtime control is.

When did we collectively decide that programmable computers were a Bad Thing?

Some of us realised that end users don't want to program and that they can be better protected from themselves by only allowing execution of arbitrary code when they explicitly say they want it.

Presumably those end users aren't downloading Droidscript.

Yup, that's fair for sure.

I thought the parent comment was speaking generally. Maybe I misunderstood.

Either way, I was thinking of downloading Droidscript as one way of saying "I want arbitrary code exec."

I think it's reasonable for Google to say "Most users don't understand what this implies, so if they want this they'll have to get it outside the Play Store."

That said, that doesn't actually seem to be what they're saying here.

I just think it's a reasonable stance to hold as an App Store.

> Play Store vetting process

You mean the one that doesn't exist?

Interpreters are problematic as they all are for executing what amounts to arbitrary, un-vetted and unsigned code. Weather or not to allow them should be up to the user and it is. Google is saying here, if you want this, you'll have to sideload it.

Reply on news.ycombinator.com