We became experts on Google Play Store policy violations
blog.pushbullet.com
blog.pushbullet.com
The latest rejection:
>>> The app title or description does not accurately describe the app’s functionality. Issue details
We found an issue in the following area(s): Full description (en_US): “▪ Tutorial & Rules ” <<<
So we changed this to:
▪ In app Tutorial & Rules
And it passed. Every release is just a bucket of stress that we are going to lose N-days of revenue again for no obvious reason.
[1] https://play.google.com/store/apps/details?id=com.templegate...
This together with the sometimes 10+ day review times makes it impossible to maintain an app on the Play Store now.
Just because someone wants to get promoted by making another half baked pseudo-AI to check apps, or someone making the 6th chat program (sorry, all people quit already after the 3rd change).
If you don't mind some off-topic feedback on the Dominion website - have you considered making the Tables screen default to "New" only? At busy times, that screen consistently lags for several seconds while displaying hundreds (thousands?) of running and finished games. It's always a pain to wait for it before de-selecting "Running" and "Post-Game".
Google also has a "sync" program, which syncs things within the Google ecosystem. Google doesn't want others encroaching on their domain. Nor do they want easy import and export from their ecosystem. Although, unlike Apple, they don't come right out and say that.
"If we only published the guilty than no one would be afraid" - attributed to Lavrentiy Beria.
I would prefer first-class support for self publishing. Want to install some app, open some-app.com in a browser, and click "download" button.
The security issues should be solved with technical measures on the OS side. Modern phones have sufficient resources for proper sandboxing at the OS level. Modern ARM CPUs even support hardware-assisted virtualization. Virtualization might be an overkill for the problem though, there're simpler ways, like abusing multi-user nature of all modern OS kernels.
Modern phones have sufficient resources for verifying digital signatures. We already have relatively decentralized global infrastructure for that, not too expensive to buy a signing certificate from verisign/comodo/digicert/etc. Can be optional, as long as end users see a clear warning "you're installing an app of unknown identity. Continue?"
Software updates don't need to be centralized either. When a user installs 100 apps from 100 publishers, I think it's OK to run 100 small HTTP requests to web sites of different publishers, couple times a month when checking for updates.
F-Droid (the client) is simply a way to easily access the F-Droid repository (which is there out of the box), but anyone can create a repository and male it available to be registered in the F-Droid client as another source, completely independent from the F-Droid service.
Second this. The existing trust system of the web is much preferable to inventing closed store. Plus the web isn't going anywhere.
Here's what should happen:
Some site says "get our app". Click. A banner shows up showing the app name, icon, screenshots?, highlights the domain.
It declares what capabilities it needs, but most permissions are temporary and on-demand. Apps that have sensitive perms (mic, camera) are highlighted whenever they use it.
Aggregators, blogs, (heck even governments), trust pilot can all have their own ad hoc review systems and warn against whatever, for those that want. You could even have a pre-installed whitelist for extra safety for non-techies for all I care.
Ready to download? Just press get app. There can even be an option to run the app once if it's something stupid that should have been a web page. Once downloaded, the signature is verified against a tls cert.
Something like that.
> It declares what capabilities it needs, but most permissions are temporary and on-demand.
Remember when Android would give you a list of permissions that an app needs and everyone clicked through it because it was impossible to make an informed decision on what the app did?
> I would prefer first-class support for self publishing. Want to install some app, open some-app.com in a browser, and click "download" button.
Self-publishing, web-style, is suboptimal, because developers are never concerned about anything but their precious software. They're essentialy primadonnas who think that world revolves around them and computers around their "app". The results are predictable, resource utilisation of js-heavy websites is tested on high-end boxen with a single tab opened and various "self-publishing" bundles like Flatpack have 200× size vs normal deb packages. Well, I want to open more than 1 tab and install more than 1 software package, not necessarily on maxxed out machine.
And this is just technical issues, because after them there are social ones. DFSG and Social Contract are there for a reason, because far too many times software authors had in mind something other than user's best interest (two days ago there was a thread which started with lenovo, but quickly filled with plenty of other examples).
Maybe it's a good time to remember that PC stands for Personal Computer, not App Developer's.
I believe the actual problem here is the UX. Modern operating systems aren’t doing a great job communicating per-app resource consumption to end users.
I think that can be solved at the OS level. Operating systems actually collecting that data: various task managers, powertop, netstat, etc. But they fail to present these values in a way which would alert users.
If the UX problem is solved, users wouldn’t be using resource-heavy apps for long. Then software developers would be motivated to pick better technologies for their apps, and/or optimize their code.
In particular, validating privacy policies is an unsolved area. How would one enforce that an app is allowed to access health data but doesn't forward it to the internet? One might envision some language environment that can track taint-style the flow of data through an application, but this seems beyond state-of-the-art.
World of Warcraft has had this in its addon system for over 15 years: https://wowpedia.fandom.com/wiki/Secure_Execution_and_Tainti... . It completely controls the language (embedded Lua) and execution environment though.
User-mode code can’t do any IO or networking by itself. Instead, apps call OS kernels asking to open files or sockets for them.
It’s impossible to disable forwarding just for the health data, but it’s easy for an OS to completely disable any TCP/IP networking for an app which uses health data.
Apple and Google are struggling with that problem because in their ecosystems many developers rely on in-app advertisements, and Google is even running its own ads network.
However there are other issues than security ones. Some stuff is not allowed, like for example doing some grown-up things (sorry to be so vague). Self-publishing only works if a third party efficiently controls forbidden things.
And that's an app store.
Since the parent mentioned Debian: this is the model that Debian provides (and yum as well), and Ubuntu extensively uses: https://help.ubuntu.com/community/AptURL
Open some-app.com in a browser, click the apt:// button, and the system will not only install the requested app, but also use the configured channel for updating your apps.
There are numerous improvements to be made in this area, for example to automatically pin a package to an origin, or to limit third-party origins to only installing in /opt/$origin, but the mechanism has been available for two decades.
It would not have to be a public-facing destination (for downloads / marketing info). I would encourage this: it could operate instead like a repository, from which it could republish to other app-stores. So that way one would avoid the varying security and cost differences of each app store destination.
> we still have 0 standardization or agreed-upon APIs
As a former Unity Technologies employee on the in-app purchase abstraction layer, I can say that the Unity runtime abstracts dozens of platforms' (mac, windows, etc) various APIs, today. And alternatively Godot supports a different set of platforms.
So, focusing on Unity, that problem has _a_ solution, however it is another privately managed API rather than one agreed upon presumably democratically by all developers, as I knowingly naively interpret is an aspiration here.
Therefore a free open platform-API standard can be created, trivially based upon Unity's IP. [IANAL so someone else check this plz]
> software distribution
Yeah distribution does not have a technical solution. In my experience it has been handled by agencies, each with proprietary partial automation and a lot of human handholding.
TBH there are 2 big app stores, and 400+ smaller app stores of varying sizes - Microsoft, Amazon, Samsung being larger western-mindshare stores, plus hundreds of global stores with lesser centralization than e.g. the tightly controlled Apple App Store. On top of that is the "no store" model of direct installation which relies on e.g. readme's for comprehensive installation.
So, I suspect a web-driver could be built that abstracts these sites. There exists APIs for many app-stores' publishing pipelines. Note, initial publisher-registration however typically requires manual work often involving real-world bank accounts.
Therefore, from that, a publishing standard could be put out there. Something that would identify app versions, publishing tracks, app high-level service features, permissions, user-facing metadata, publishing schedules, and store-review-status workflows.
I hear you. It's the best solution, and all credit to unity and others for doing that work. That said, I don't like it, because it's almost always a bad upfront tradeoff between fiedlity and velocity. Moreover you just end up with another layer in the stack, when we should have fewer. Half the time these things are broken, in my experience, not because of any fault of the middlemen, but because Microsoft, Apple or Google changed something in their proprietary, poorly documented code base.
A side note, working at Unity was fun because the point was not a generic solution for all programmers, but rather to make life easier for game developers so that they could focus on the creative aspect of their games. For example Not working around Google Play Library's latest unintentional goofiness around how their Android Activitys would close prematurely and send incomplete signals terminating their purchasing flows and then you as the game developer would have to somehow magically capture the now suddenly missing workflow signal and yada yada yada. So yes, I agree with you :-)
And moving the discussion further, designing a new high level platform abstraction API could include a feature that compiles this new APIs bloat away and eliminates intermediate calls.
Platform fragmentation is kind of a never going to solve it perfectly problem in my opinion. Until we have computers that write their own software to solve some end goal, humans are going to have to keep releasing patched versions of adapter layers.
A solution will be to have an AI submit modifications to the other side's enforcement notifications. Robots talking to robots. What a world.
https://twitter.com/jamonholmgren/status/1462955101899788294
Unless someone who actually works behind the scenes can chime in.
It's because it leaves them at risk of using previous precise answers to others as precedents for future cases. Being opaque allows them to not be too committed, and outside of situations like "but you accepted XYZ app which does exactly the same, I don't understand"
You can still claim XYZ app does what you did and didn't get punished by that, but they can never admit it in paper/words.
Scammers will try to skirt rules by making sure to adhere to the letter of the law, even if it’s plainly obvious they are violating the intent of the rule in question.
Rule 407b: no real money gambling apps
Scammers: it’s not real money. It’s Linden Dollars. Or our company script. Or our new NFTs. You can’t reject us.
Should the rule have to list out every single thing that could possibly used as currency? Because there are people who will argue that point.
The more explicit you are with the rules, the more specific bad actors will try to weave around them. It sucks because it means the scalable, machine-assisted review process comes up with more false positives, but it's a two sided market and the marketplace owners care more about the users than the devs.
I feel like the U.S. tax code is a good example of when you try to go more explicit with the rules.
What you're referring to is the application of power, and their retention of arbitrary power, specifically.
Ethics is if they used that power for abuse or an unethical goal, or to acquire an even larger amount of arbitrary power.
Pragmatically, it's their app store, and they need to retain a non-trivial amount of power to police it. It's a requirement of ownership. If they don't do so, it will devolve to an even worse garbage dump, and rather quickly.
We're of course going to complain about inexplicable rulings, things we don't agree with, etc. but that doesn't change the equation unless they get so obnoxious that other places are more attractive or it violates some law.
For the one in 100k poor guy who got on the bad side of the AI this seems like a raw deal, but if you tweaked the system to avoid it, you'd probably end up with something 5 times as expensive and 10 times as slow. Queues of weeks to get your app approved kind of slow.
I can see that if you are talking about humans asking them to compose detailed and specific reports has costs. But we're talking about machines, not humans.
Basically all anyone is asking for is a stack trace so they can identify and debug the issue. I don't understand why that's unreasonable for a bot.
It's like a complier that aborts with nothing more than "syntax error". Most people know compilers can be much more helpful than that.
A good analogy is dating. What they’ll allow you to get away with is highly dependent on how attractive they find you, from a business standpoint.
This. So. Much. This.
We go round and round about specific policies at corporate or civic levels. We hash it all out and pat ourselves on the back that we’ve at least proposed how whatever the issue of the moment might be improved.
But we never come to the basic generic issue. That large swaths of decision makers should not make the decisions they do.
Do big-earners on the app store get higher quality service?
But, we could not use the same Name or Namespace (com.company.project) because those were locked. They are keeping the blocked in, with notes.
Our fix was to refactor the namespace in the code, change product & company name. Jk, we just abandoned Google Play, wasn't worth it.
Working on an app right now that is very close to the industry and we're really worried about a rejection because of that.
Also, if I had known the block would lockout my name/namespace I would have entered with a throwaway, then get the real one in.
We moved away from needing an App and now keep it all web.
It's not impossible. But both were demanding changes to the app and other hoops that just kept increasing the cost to get on the platform.
We had a smaller budget than Pax.
https://www.theverge.com/2020/6/1/21274431/pax-web-app-era-c...
This & the other apps had it live for months, the others are still fine, just this one app now can't get updates. And we simply can't make it better (due to legalities) - still no cooperation from Apple.
Google's process, while not perfect, made it at least transparent that the process is going to take a while. And at least in our case, the process involved some real people at the end to point out the specific concerns that actually lead to actionables.
Apple's process is slow, and seems to be worse in my region; it's clear that they're severely understaffed here. We spent a good 30 days trying to fix a crash, and they were all spent for either submitting a new app version to Apple, waiting for the review to finish, getting it rejected for some very vague reasons, and waiting for a response from them to elaborate their reasons for the rejection.
This is actually my biggest takeaway from the article.
Violations are completely arbitrary and not enforced or closely reviewed upon resubmitting, so we put as much effort into them as Google does.
Being forced to work under these conditions feels like being in an abusive relationship.
1) Pushbullet is frequently 'randomly selected' for extra scrutiny (TSA style) because it competes with some offering from Google or a preferred partner.
2) The review algo simply diffs the resubmission with the previous version and if there are changes 'near' any of the keywords from the violation, it gets approved, until the next 'random' scan.
1- Submit an update
2- Wait a week for it to be approved
3- Publish said update
4- Forget about it and move to working on something else for a few days/weeks
5- Get a random rejection email with a bogus claim and 14 days to "fix it" or the extension is removed
6- Drop everything in my sprint so I can handle this. No actual code change was required, just a series of Kafkaesque support forms and email exchanges.
After 3 or 4 rounds of this, I created a template response with a history of previous interactions and arguments and sending those became part of the routine ...
Summery means "characteristic of or suitable for summer", as in the season
Summary is the word you meant to use
Also means brief, concise. I guess a summary execution (which means without trial if I understand correctly) is a briefer process than an execution with a trial…
Would also properly qualify the rejection of an extension from the Chrome store, I guess, to go back to the main topic.
https://www.wordreference.com/fren/sommaire
(yes, found out by translating from French :-) - sommaire also means basic, rudimentary, now I wonder what made us use this word for executions - the brevity, or the basic aspect, sounded like the latter to me in history lessons)
Thanks to wordreference above all. You might have meant it as a joke initially, but I learned something.
We took the resolution really seriously at first, and we tried our best to find the issue and fix it, but then we realized we had about the same resolution rate if we just changed a random character in the codebase and resubmitted. We had contacts at Google, but even they couldn't tell us what was wrong.
Play Store was/is much better, but we aren't dealing with complicated phone APIs, just basically a React Native app with REST calls. We rarely have any issues getting rejected, and when it is, we get very fast turnarounds on emails.
Play store had a much lower
These threads will surely give PTSD to any extension developer:
I wouldn't be surprised if Google put you through the gauntlet because your extensions either touch their products, or because they offer similar functionality.
An alternative power-broker such as F-Droid (for Android app stores) becoming more popular, somehow, and also following a Code of Conduct for App Stores that we in the dev community maintain, could be satisfactory, though also quite an uphill battle.
I paid for a year. They just totally shut up shop, didn't develop a feature, didn't do a thing. I left after my year's subscription was up, sick of sticking up for them in forums/reddit etc and realising most of the complaints people were leveling and them (him?) were valid.
It's a shame to see Google treat anyone like this, but meh, that's how we felt after paying up for Pushbullet Pro which saw zero development/love after the fact and the developers who had, previously, been very vocal and supportive, go to radio silence.
I kinda support Google here, put this poor thing out of its misery.
1: https://www.reddit.com/r/PushBullet/comments/6wby5b/is_pushb...
2: https://www.reddit.com/r/PushBullet/comments/7bjvhx/is_this_...
3: https://www.reddit.com/r/PushBullet/comments/77egnz/is_pushb...
[1] https://www.reddit.com/r/PushBullet/comments/vv844d/comment/...
https://medium.com/@daniel_11666/331c98270ec4?source=friends...
> We take seriously the security of any information stored on our servers and take all reasonable precautions to protect this information.
All reasonable precautions?
What's that supposed to mean?
You got internal policies in place that not all engineers are able to access these messages according to their contract?
This type of data should be e2e encrypted, pushbullet shouldn't even be able to decrypt it and messages should disappear from pushbullet servers as soon as the message is pushed to all devices.
I've been using pushbullet for years but now I'm considering disabling the sms sync feature, the privacy policy looks really shady and Google has all the right to call it out.
the experience of publishing apps to Google Play is really awful.
After developing native apps for years, we'll be publishing our next project as a PWA for this reason alone.
I recently learned that it’s no longer available for iPhone and that if I get a new iPhone I won’t be able to load it onto the new device. It has kept me from upgrading. Eventually I’ll have to but it will be a sad day. I’ve seen a few alternatives but they don’t appear to have the same usability.
I have gone through the joys and pain of having an app approved and pushed live, to being teared down and removed for not meeting certain guidelines.
What frustrates me, is the reasons are very vague or don't have go into detail as to how YOUR app is in violation.
It is just a generic statement and you have to go through the hell of trial and error to figure it out.
The main ones I have faced are the following.
* Not adhering to Families policy requirements policy
* Not adhering to Google Play Developer Programme Policies
My apps are games built using Trusted Web Applications (TWA) and Google talk about the following...
"Your app must not merely provide a webview of a website or have a primary purpose of driving affiliate traffic to a website, regardless of ownership of the website. We are constantly exploring ways to enable new experiences for kids app developers. If you are interested in joining our Trusted Web App pilot for education apps, please submit your interest here"
My apps have no ads, no tracking, no analytics, they have a privacy policy, but it still gets rejected. :(
Pushover is what I've used for as long as I can remember, I bought the app so long ago that I can't even remember what I paid. It's decent, a little basic though.
Recently I've just been using a Discord server since that's trivial to setup and I can get notifications on desktop and mobile easily. I just have 1 channel per "thing" that might want to alert me and then grab the webhook url for that channel and then I'm good to go.
I usually drop a "push" binary in the ~/bin folder on my machines (which is in my path) so I can do:
./longRunningCommand.sh && push "Command finished!"… of course, it would help build confidence that there is a causal link if Google would clearly articulate their reasons for rejection.
> I really really need to make Google happy.
This is not fair or just.
This is not artificial intelligence.
This is not freedom.
This is abusive.
This is capricious.
This is arrogance on the part of Google developers.
This is comparative programming designing a system to meet a standard maintained by an automaton.
This is the worst form of tyranny.
Things got so frustrating that I wrote my own guide on pushing updates to the webstore: https://getsnapfont.com/posts/avoiding-lengthy-review-times-...
At this point, I can sufficiently say that the author is on point regarding AI training and I know when an extension review has been through an automated process or via a human.
I'm a little confused why the app version would need to access my SMS message history, send messages on my behalf, and access my contact info though.
I don't want that even if you claim to not be sharing it with anyone else...
Your thought is that mentioning that the necessary data is sent to https://api.pushbullet.com instead of just "Pushbullet Servers" might help?
I had not considered this but it is an interesting idea.
In our case, Google was claiming we were sending contact information to a URL corresponding to our static landing page.
In fact, we didn't even upload contact information anywhere.
Somewhat frustrating, but most of the times the issue was just that the apps were already compliant, but the reviewer on Apple/Google side was just not carefully checking
My work had been PATmatched for review, pending cancellation. Drat I was already low on credits to cover food bills this week.
Car capsules filled the crimson sky of the small windows in my 10000 story apartment room, day and night the automated vehicles rolled past my window like a raging torrent. Living so high, not much to do but sit at the console.
Another automated notice from TECHCORP. Always the same. Never a human. So insanely lacking in logic that often I’d want to scream in rage.
But actually, IT WAS LOGICAL. To the billions of learning machines, running at basement level, in windowless buildings, beyond places I’d never know; I was the anomaly.
You pay the in-app-token equivalent of $0.25 to post a new paragraph at any given node, then as other users select your node for that branch, your node rises in popularity.
Once a month, the most popular branches get paid a prize of in-app-currency for submitting good content.
Google just has so much money sloshing around they don't notice or care if they lose a bunch of revenue over stuff like this. There's no business pressure to retain customers. Even with the news from the other day that profits dropped: it's still more than what they did a just a few years back.
Almost all these tech companies have very high profit/per employee; the idea that they can't afford a small army of human support people is just not the case; they just don't because they don't have to.