Mine isn't anywhere near paying the bill yet, but it's at 60+ customers for $20/year.
It's exactly as you described. I had a pain point which was trivial for most, but not for me. No existing solutions solved it properly so I decided to make it myself.
While searching for a solution, I found that a lot of other people had the same problem. It was bad enough for them that they took time out of their day to write their complaints online.
In solving my own problem, I was creating something that other people might've pay for. And they did!
I quickly learned that marketing was the most important part of the process.
Reminds me of the story about two sisters arguing over an orange.
"Management guru, Mary Parker Follett, tells the story of two highly competitive sisters quarrelling over a single orange that they both wanted. Neither of them would budge until their mother intervened and decided that the only way to resolve the dispute was to cut the orange straight down the middle and give each sister one half each. The first sister then squeezed her orange half to make a drink of fresh orange juice while the second sister grated her orange half for peel to add to orange scones. As a result, the sisters only got half of what they wanted." [0]
The sisters valued different parts of the orange. They'd both think they'd gotten the best deal (dating/marrying up) if they had shared it.
> You just make it so that anything behind a paywall requires adding the license key which is generated by Gumroad upon purchase and later verified via their licenses API.
This is what I did. I also had to create a licensing backend to handle cases such as only being able to use your license key on a single account, and for verifying that your license key was still valid (in case you cancelled or got a refund).
I got a few of those rejection emails recently, and replied asking for further clarification. The replies were the exact same rejection email, but with bolded or highlighted sections. Addressing those sections got my extension into the Web Store (or at least to a new rejection email https://www.reddit.com/r/ProgrammerHumor/comments/8j5qim/pro...), so I think there is a human sending those replies, albeit with instructions not to send anything other than the rejection.
> How in the world would making it more clear how to write more secure extensions possibly worsen the extension store's malware problem?
Unfortunately, information that helps the good guys get their extensions past the audit check is exactly the same information that helps the bad guys get their extensions in too. The bad guys simply move onto the next security flaw that Google hasn't anticipated.
Maybe the bad guys use some common tactics to get their scam extensions in the store which good guys don't, which is easy for Google to detect and flag. If you release a list of known no-no's, the bad guys just get smarter and avoid them.
This obviously skews in favour of refusing some good extensions to keep most bad ones out.
In terms of Google already auditing every app, check out the source code for Dark Reader https://github.com/darkreader/darkreader. It's fairly complex. I can only imagine how many extensions are as, or more, complex than that. I wonder how much auditing is done manually vs automated.
Unfortunately, information that helps the good guys get their extensions past the audit check is exactly the same information that helps the bad guys get their extensions in too.
This is just an assertion I'm wrong. It can't possibly persuade me or the people upvoting me. Would you be persuaded by me just asserting you're wrong?
In terms of Google already auditing every app, [e.g.] the source code for Dark Reader [is] fairly complex.
Firstly, Apple is able to do it, there's no reason to make excuses for Google. See anecdotes elsewhere in the thread about how Apple attaches screengrabs, explains rejections by phone conversation, even decompiles apps to point to exact methods/lines of code in apps they reject from the iOS App Store, even small free ones: https://news.ycombinator.com/item?id=23170498
And anyway, without reading a single line of Dark Reader's source code, I can deduce plenty of permissions it shouldn't need, e.g. "cookies" (which it doesn't ask for). Without reading a single line of PushBullet's source code, one can easily deduce it shouldn't need access to "https://*/*", and indeed, it doesn't, yet it asked for it.
Can you explain concretely (not just by pointing to unnamed "no-no's") how could harmful side-effects result from Google telling PushBullet that "https://*/*" specifically was in violation?
If you release a list of known no-no's, the bad guys just get smarter and avoid them.
Firstly, isn't bad guys avoiding no-no's exactly what we want?
If you're saying that there may be some, probabilistic red flags that Google uses to find possible bad guys—sure, that could be true, I have no idea and you don't either, you admitted it was speculation. But in this case, "Request access to the narrowest permissions necessary to implement your product’s features or services." is not a probabilistic red flag, it's a hard rule.
Again, concretely how could harmful side-effects result from Google pointing out the specific violation?
If I've got any sort of work to do, where I could just as easily load up a game, I say to myself "I'm going to work on this for ten minutes until 3:30pm. Then if I'm sick of working on it, I'll just play the game instead."
It's exceptionally practical, since 95% of the time I end up working on that thing for longer than that ten minutes. For me, it alleviates the pressure of thinking I'll need to push through a task for hours by giving myself an escape hatch.
It's a "motivation follows action" technique/trick/hack.
Reddit's "Tip of my tongue" is great for finding things you remember, but can't name. People manage to figure out exactly what the poster is asking for, no matter how obscure the description.
Yes, you never know who you could be talking to. Reminds me of the trial lawyer advice of "never ask a question you don't know the answer to".