Uh, yikes:
> As I looked at the permissions and what our extension actually needs to operate, I noticed a great opportunity to reduce our permissions requests. We do not need to request access to data on https://*/* and http://*/*. Instead, we can simply request data access for https://*.pushbullet.com/*, http://*.pushbullet.com/*, and http://localhost/*. This is a huge reduction in the private data our extension could theoretically access. A big win!
While I agree with the larger part about the lack of transparency of what they want you to fix, this is an amazingly huge oversight, and the fact that the extension review process got an established, popular extension to go "Wait, we don't actually need to request access to every website ever" is a point in favor of the review process - and, unfortunately, a (weak) argument in favor of the review process taking the attitude that they get lots of crap and don't have the time to explain to all the authors of crap what they're doing wrong. How did the extension ever ask for this in the first place?
Also why do you need http://localhost/? Is the extension running a web server on localhost with native code? If so, can you use the specific mechanism/permission for communicating with native code via a subprocess (because it turns out communicating with a web server on localhost is very hard to do securely)? If not, what's it for?
I'm sympathetic to the broader argument here, but given the provided information, all of this is consistent with an extension that should be kicked off the app store within 14 days.
(Among other things, if you have an approved extension with https://*/* permissions and active users, malware authors will offer to buy your extension for a very high price. So it's definitely in the public interest to make sure there are as few of those as possible and that they're only in the hands of people who have the ability to understand why the friendly person offering them way too much money for their extension isn't just being nice.)
I agree. This is hackernews, so it is easy why devs would feel otherwise, but as a nondev, I represent the the end users.
Why would anyone think it is appropriate for google to reveal their hand, and allow blackhat operators to build apps up to the max limit of permissions? (If they were revealed by google via white glove customer service).
If goog did provide guidance on permissions, goog would literally have to audit every app in the store, or come up with a way to separate bad actors from good ones.
So, Im sorry. No. If its between 1 hacker's inconvenience or in extreme case , livelyhood....and the retirement savings bank account of many grandmas, i am going to side with grandmas.
Google is doing many things wrong. Keeping the "red line" of allowable permissions secret, from data-hungry developers.... is not one of them.
> If goog did provide guidance on permissions, goog would literally have to audit every app in the store, or come up with a way to separate bad actors from good ones.
This makes no sense. For the sake of the grandmas, Google already needs to audit every app in the store and separate bad actors from good ones.
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.