> 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.)
But you're completely ignoring the point that even without the all http(s) permission they will still be kicked off the store, so that has nothing do do with the issue at hand.
If localhost is the issue, Google could literally respond exactly the way you did and the problem is gone, "why do you need http://localhost/?"
This isn't about permissions at all. This is about communication and whether it's worth putting effort and trust into a company that acts like this as SOP.
That's the thing I'm sympathetic to - having fixed the bug, it's frustrating that it's not clear what the next steps are.
But given that they had the bug, Chrome was absolutely in the right to deny them the first time. And while I don't like Chrome's position that they're too busy to explain to everyone what they're doing wrong, if extensions that go "oh hey, we don't actually need access to literally every website, imagine that, oops!" is what you expect out of good, competent, non-malicious extension authors, I have a lot of trouble disagreeing with their conclusion, in practice.
(Would it be better if Chrome said "There are 200,000 extensions on the Chrome store, each and every one of them deserves attention, we need to spend at least 30 minutes looking at each one and composing a response, we have a ten-person team, we'll get back to you within 5 years?")
I can only assume that this isn't the result of a human flagging Pushbullet like this; I expect it's an automated system. And if that automated system can make a decision to flag the extension, it could also include in the email specifically what caused that flagging to happen.
At this point I'm really starting to become unsympathetic to the idea that they can't tell you what you're doing wrong because it'll enable people to figure out ways to work around the flagging algorithm. I kinda just don't care anymore. If you're going to run a platform like this and capriciously threaten to kick people off of it, it's pretty antisocial to hide the reasons why.
(And yes, I know, Google has no obligation to do anything differently here. But I can perfectly well think they suck for their current practices.)
I agree, and will go further in that I believe they actually should have such an obligation: it should be a consumer right to find out why you were denied access to a platform--or a restaurant, or a barber shop, or a wedding cake maker, or whatever else that someone is refusing you service due to, as a business operating in the public--and that whatever reason that is must be something that either 1) has nothing to do with the customer and can be shown to have nothing to do with the customer (such as "we do not have enough workers to take more orders and we didn't do anyone other than you") or 2) is clearly and obviously "correctable" (so like "because you are gay" doesn't count); if the platform (or service or business) refuses to tell you, or their reason isn't "correctable", there should be heavy penalties attached for what amounts to opaque discrimination.
(FWIW, I appreciate the idea that eventually it would be useful to be able to ban a bad actor entirely from something to exclude the possibility of future harm: the past tense of "correctable" was "avoidable", and it needs to be very clear exactly what was done wrong and what could have been done differently for someone to end up in the situation of being banned from the usage of a platform, service, or business: the alternative where people get to apply secret and obscure reasons to refuse service is madness.)
I was ready to get behind this line of reasoning, but then I thought about e.g. comment sections. Anyone who has moderated a forum will know that trolls find every possible way to walk right up to the line without technically crossing it.
If you say "personal attacks aren't allowed", they'll say "I wasn't attacking him personally, I just suggested that anyone who says [the thing he said] should consider getting evaluated by a doctor for mental retardation."
At some point you just have to say "I know what you're doing, you're clearly not acting in good faith, and I have to ban you." Are all of those people now potential lawsuits?
Yeah, this is the issue. They're not going to catch every dirty thing extensions (perhaps unwittingly) do. If they are able to detect one or more problems with an extension, there's a good chance that there are other problems that were undetected. Forcing extension authors to go back and think about what they could be doing better rather than just telling them the minimal set of changes that are needed seems like it can only result in more well-behaved extensions across the board.
There should at least be some appeals process that involves a human then. In this case they fixed legitimate cases where they had too many permissions (including removing some functionality), and were still rejected. What if the reason they were flagged was because of a legitimate usage of a permission that the automated (or manual) system wasn't aware of? At the very least there should be a way for a flagged extension author to go through a process where they explain why they need each permission they request, and if that is they are still rejected, told why their explanation wasn't good enough.
This is especially important given google's market power in the browser industry. What if the extension is from Google's competitor? Google could ban the extension without a legitimate reason to hurt their competition.
> If you say "personal attacks aren't allowed", they'll say "but I wasn't attacking him personally, I just suggested that anyone who says [the thing he said] should consider getting evaluated by a doctor for mental retardation."
1) That pretty clearly qualifies as a personal attack
2) There is a significant difference between a forum and a business critical software distribution platform.
> That pretty clearly qualifies as a personal attack
Okay, let's take the obscurity up one level: I used to moderate a very small internet forum, where there was one user who had certain mannerisms in his writing. I also had reason to suspect this user was mildly suicidal.
A troll began to mimic these mannerisms as a way to make fun of that user, and talk about how horrible their life was. The troll wasn't overt about it, but if you knew the history between these two, you could tell what was going on. The troll of course feigned innocence, but as he'd been given warnings before, I made the call to ban him.
I firmly believe I was acting within the forum's stated policies—but I am not 100% confident a judge would agree. If these types of actions could lead to lawsuits, I don't know what I would have done.
---
> There is a significant difference between a forum and a business critical software distribution platform.
Great—but where's the line? Is Youtube critical, for example?
It sounds like this case would comply with the proposed rules to me. You informed the bad actor of what he was doing wrong, the behaviour was correctable, and he continued to exhibit said bad behaviour, so you banned him.
It would be common enough to have laws that say only businesses of a certain size are fully obliged to comply. GDPR has this for some clauses, for example. I guess the idea is along the lines of the market determines whether you're critical by letting you become a huge company?
> I can only assume that this isn't the result of a human flagging Pushbullet like this; I expect it's an automated system
There isn't. Take a quick look at stupid popular apps on the Play Store, almost all of them require completely unnecessary permissions literally in conflict with the bullet points that Google listed in their email to PushBullet.
Also note that almost all of them have 10-50x the amount of downloads compared to PushBullet.
The odds just spell bullshit.
Their "automated scanning process" didn't just happen to pick the popular app that gives users more control and platform independence from Google.
Because really that's what it's about, PushBullet is dangerous to a closed ecosystem like Google wants.
(also, I believe that given the permission system, and if an automated scanning system was in fact in place, it should be super easy to exactly point out what is wrong, like compiler errors. and being granular permissions, there's no "gaming the system" about it, you either get the permission or you don't)
> If you're going to run a platform like this and capriciously threaten to kick people off of it, it's pretty antisocial to hide the reasons why.
I don't believe Google gets to be "antisocial", they're not a person. They exist since ~20 years and are made of shifting people, none of whom really control it. As far as it can be "antisocial", I wonder if it even vaguely "realises" that its interchangeable parts are the same entities as its consumables.
That's a bit extreme. Google sends out emails every few months about new policy that may get checks. They definitely aren't very good at doing automatic checks that are relevant or have much relationship with the policies they publish.. But that is a bit different than strategically attacking specific apps beyond choosing the X thousand most popular apps to get the most users affected per presumed threat.
(I get various compliance spam and ignore it and among things with small numbers of users and/or owners who lost interest a small percentage a year fall out of the stores. The only differences are that we don't care enough to forward the threats Google sends us and no one would bother to amplify them.)
> And if that automated system can make a decision to flag the extension, it could also include in the email specifically what caused that flagging to happen
Unless it's a black box machine learning model that just says yes/no but can't tell you why
I think it's more likely that their flagging is heuristic based and could easily defeated by a malicious extension author and giving detailed feedback makes reverse engineering the rules trivial.
Law enforcement has a solution for that: Do tell people what the rules are and what they are doing wrong. Don‘t tell them how they got caught and what methods were used to catch them.
Telling people that they are going to be severely punished within days by a very powerful global entity, without telling them which specific rules they are in breach of or what they have to change is a dystopian nightmare.
Being audited isn't an explicit accusation that you've violated anything either; at best, it's an implicit suspicion to which the tax authority is fully entitled to probe and we as taxpayers are given reasonable opportunity to corroborate claims.
Absolutely. My point is simply that you can tell people what the rules are and which ones they may have broken without revealing absolutely everything about how you detect any malicious behaviour.
> flagging is heuristic based and could easily defeated by a malicious extension author
Well, if the reason is the "https://*/*" permission or something like that, and it is flagged and reported automatically, and everyone learns not to use it, it's a win-win. Benign extensions will have smaller targets on their backs, and malicious extensions will become less malicious OR will have to jump through hoops to achieve what they're trying to achieve (and will become easier to detect).
This isn't something vague or hard like OCR, voice-recognition or image classification.
It's a finite list of app permissions.
Unless it's a random number generator that just says yes/no but can't tell you why -- is just as valid of a non-excuse for using the entirely wrong solution to a problem, and surprise the solution doesn't work very well.
> Unless it's a black box machine learning model that just says yes/no but can't tell you why
Recently there's been some interest in Explainable Artificial Intelligence (XAI) which addresses the problem of "black box" machines. There are techniques such as SHAP and LIME that can help the ML designers provide explanations for why any specific observation has been "rejected". That said, I'm not sure if that's what Google uses here.
Sure, it's anti-social. But is it more or less anti-social than running a huge software platform that advertises the ways to exploit itself?
I think it's a very interesting question. Who is more deserving of a good experience - uninformed users who might get taken advantage of by malicious extensions, or developers for the platform, who definitely do get taken advantage of by virtue of running afoul of rules they can't read?
Even if the average damage to a user is very low, the ratio of users to developers is massive.
> But is it more or less anti-social than running a huge software platform that advertises the ways to exploit itself?
Security through obscurity is no security at all. Google is not doing its user a favor by hiding the criteria it uses to determine whether an extension is malicious or not. Also, just because Google won't publish the criteria, it does not mean that it can't be discovered by someone with enough determination. I think that a malicious actor is more likely to spend the necessary time and effort to do so than a developer who is more interested in creating an extension that will serve its users well. If anything, these types of policies drive away developers who act in good faith and leave the marketplace with more developers who are looking to exploit the users.
It seems likely to me that it's impossible to have an extension system that allows useful extensions that users want while also being completely secure against malicious actors. Security by obscurity is an important tool in the abuse fighting toolbox, because it allows you to have cheap heuristics while increasing the costs for malicious actors.
Not really, because malicious actors don't care about their reputations, accounts, etc.
A reputable developer has a reputation to maintain (by definition), which makes Google's threat to permaban them a threat indeed.
A disreputable developer doesn't care about their reputation (again, by definition). They can create a new throwaway account every day and apply using the same (or slightly, easily, altered) code with different permissions every hour until they get permabanned, and start again tomorrow.
So the "obscurity" can be discovered easily through experimentation by the bad guys, but is still obscure for the good guys. This is not a good outcome.
The point is making it more expensive for malicious actors. You can't make it impossible to get malicious extensions in, but you can make it harder. It's the same as captchas. You can also defeat captchas, but adding them reduces abuse a lot. As with captchas you're making it harder for good actors too. The difficult part is finding a good balance.
> The point is making it more expensive for malicious actors.
Malicious actors don't care about expenses nearly as much as benign ones do. So the point ought to be, if you want me to fix something, tell me what's broken.
Except that in this case, it's misplaced, and causing benign actors far more pain than malicious actors. If they want to hurt malicious developers, they need to flag extensions as untrustworthy for:
1. age < 180 days
2. dau < 1000
3. some rule around user reports of malice on uninstall?
and this gets a bright warning banner on the top of the page, and it can't be discovered through the chrome store until crossing these thresholds.
But this is not email, where literally everybody can send things. Raise up the barrier at submission level - where you must be authenticated - to get rid of automated trial/error attempts, I bet they can.
But when an extension/developer is there, when it has a long history in the store and used by 1M users, hey, give some human feedback. It won't break your automated anti-spam/scam rules.
Getting kicked off the platform happens on HN itself a lot/ I get flagged on HN on almost regular basis (and my ability to reply/talk back is taken away) for speaking my mind (no curse words, just opinions that are others strongly disagree with) about Google, HN itself, Amazon et al. If I ascribe a n ulterior motive to someone in power, I get kicked off. Worse, sometimes I get attacked personally. So I think it's pretty ironic to complain about being kicked off on HN. This is probably my 50th username.
Who is referring to getting kicked off HN? I believe the post you're responding to, which said "If you're going to run a platform like this and capriciously threaten to kick people off of it," -- the "it" referred to Google.
> given that they had the bug, Chrome was absolutely in the right to deny them the first time
Sure, but if that bug gets fixed, why reject the fix?
Also, if that's the bug that was the concern, it would certainly be nice to have something in the email along the lines of "We don't want extensions to ask for access to every website anywhere on the Internet, so please narrow your http and https permission request."
> they're too busy to explain to everyone what they're doing wrong
If a human flagged this, how much longer would it have taken to add the sentence above to the email? Or even write that instead of the useless generic boilerplate that's in the email?
If, OTOH, an automated bot flagged this (which is what I suspect, and what others seem to suspect too), why didn't whoever wrote the automated bot put at least some kind of clue in the script that writes the email? Something like "if bad thing #6 is found, add text XYZ to the email".
> we have a ten-person team, we'll get back to you within 5 years?
It is TOTALLY not OK to have a ten person team (and I have no way to know if they even have that).
Considering the fact that the browser platform is now a real service required by billions of people, they should be responsible to have enough staff to handle extensions properly.
Aside from the amount of money the Chrome extensions make them, the amount of influence it buys them, and the amount of damage it can do, it should be required of them to have a real team to handle it.
Imagine if the I ran a private airlines that provided service for 4 billion people around the world, and the entire team that inspects, approves, and monitors the pilots and co-pilots had ten people. Would you think that is acceptable, or would you expect multiple governments to intervene?
> Considering the fact that the browser platform is now a real service required by billions of people, they should be responsible to have enough staff to handle extensions properly.
Extentions don't have to exist at all. At least for a very long time, there were no extensions for Chrome on Android (not sure about now but that may still be the case).
I suspect google would love to just deprecate all extensions entirely, they're probably a massive headache for them (as this thread shows).
A lot of things Google used to do that attracted geeks like us are really a problematic thing when the average masses of people are using them. Google is learning that the hard way, and the process of fixing that pisses off us geeks.
Apple took a different path of locking things down more aggressively earlier, and a lot of geeks (myself included) hated them for it. Now, after we're seeing how the modern world is so incredibly tech illiterate and how security issues are affecting the world, I think Apple got this right and Google got it wrong, and Google knows it and is trying to fix it, which is pissing us off in the same way Apple used to piss us off (but we apparently got over it).
Yes. So more importantly, these may or may not even be the kinds of things that the system flags. So we can’t even say that Google’s system is working correctly and is flagging things correctly. I’m happy to concede that the plugin needs to fix vulnerabilities, but it seems like it’s distracting from the main argument, which is how the hell do devs know what to fix in these review processes. I’ve had similar experiences with Apple, Google, and especially Facebook in the past.
By "the bug" I mean the fact that they're asking for permissions on any site when they don't need them - which is a bug (and a serious one) whether or not Chrome notices.
I'm not sure I get your point, yes that permission was overreaching but they fixed that and were still rejected and left in limbo without Google's system giving them enough specific information to reliably mitigate whatever it is the system did not like.
They haven't fixed the localhost thing which is in a roughly similar category. Google's response was vague and poor but the problems this extension had are quite serious. More serious than, say, Zoom's recent ones.
The theoretical problems that are also hypothetical because the browser vendor isn't specifically saying that it's what they take issue with here even after the developer tried to mitigate it? And which is apparently pretty common with the prescribed best practice being buggy and badly documented as per the thread below? I'm fine with putting some blame on the extension developers here but this communication by Google is pretty abysmal and for all practical purposes more worrying to me than overreaching permissions that have apparently not impacted security in the real world at this point. The thread below indicates that the localhost thing was/is pretty standard for some use cases, if Google wants that changed they could just communicate it clearly, openly, and with a good upgrade path. Not with vague, unspecific "do something or you're out" messages. Even a few links to documentation that likely didn't exist when this was first implemented would be fine here to change the odd messaging to something actionable.
I just did not see any indication of the permission actually being abused by this specific extension, hence the hypothetical. That's not meant to dismiss that it is an issue but in this specific case I think the communication is worse than the potential problem given that the devs don't seem to have a negative track record and actively work on mitigating it.
As for the redundancy, I blame my lack of coffee for that, apologies.
Would it be better if Chrome said "There are 200,000 extensions on the Chrome store, each and every one of them deserves attention, we need to spend at least 30 minutes looking at each one and composing a response, we have a ten-person team, we'll get back to you within 5 years?"
Yeah, but with 100 people it would take only a few months and after that it would take far less people to maintain everything. Also, they could just have their algorithm do the flagging and then have a team of 10/20 people to handle users. It's just that they don't care (enough) Not all 200.000 extensions are being killed in the next 14 days. Also if this is done for security reasons then put this responsibility with your security team and make that team bigger.
I see a lot of threads on HN discussing complaints about how locked down Apple is. I suspect many of the extensions that are problematic for Google never would have even been allowed into Apple's ecosystem in the first place.
In general, Safari's extension system is more restricted than Chrome's, and changes that Chrome is attempting to make to be more similar to Safari's approach result in fierce backlash exactly like this thread (e.g. https://www.wired.com/story/google-chrome-ad-blockers-extens...).
> we have a ten-person team, we'll get back to you within 5 years?"
I'm of the opinion that a company with revenues > 30 billion dollars per quarter could afford to increase the ten person team ten-fold to get the response time to a reasonable number.
The tool could tell them what the problem is. There are fine grained permissions, and Google could say which of those fine grained permissions are used badly. OR, they could just restrict those permissions themselves in the browser.
If it did, it'd be easy for malware authors to work around the scanner. The system we've got right now isn't great, but I've yet to see any better ideas.
How does that make any sense? There's some set of permissions that's safe enough to approve, but too dangerous to tell you it's safe enough to approve?
I don't understand what you're talking about. If the scanner looks for extension with permissions for all your web browsing activity, so malware authors stop asking for permissions for all your browsing activity...isn't that great news?
I understand that's the reason they give. I just don't believe them. At some point you have to assume good faith. Maybe that point is when the item in question has over a million users and a good rating.
Couldn't malware authors start from the other direction? Create a no-op extension with no permissions and gradually add things until it's no longer approved.
Only years later, as in the case of a certain Vietnamese hacking group that did exactly this starting at the end of 2015 and didn't have their apps yanked until Nov & Dec of 2019 and another batch located & yanked only last month, well after any and all damage was already done to those who used the apps.
Honestly i wouldnt give them the excuse. they have more than anyone else to be able to either:
- automate this with a message that tells you what thing is dangerous
or at least:
- automatically push to a human that will spend 30 real minutes on it for extensions that have many users/popular (that sounds like the basic thing any business would do!)
> But given that they had the bug, Chrome was absolutely in the right to deny them the first time.
This is not a given at all.
Google's communication was and is absolutely unclear on what is their problem.
And if you'd take their communication on their word (dumb idea), they have been pretty clear that this was in fact not, "the bug", and that is has in fact not "been fixed".
Regardless of your (and my) opinion about apps requiring access to every site on the www -- Google did exactly the opposite of indicating that this was the problem why PushBullet is threatened to get kicked off the Play Store.
How many of those extensions have 1mil+ users though. Its called prioritizing. The fact that they treat popular extensions just like one that tom wrote for him and his family to share pictures is poor mgmt. They are making money so there should be more accountability on Google's part even if they dont "have" to .
Google's customer service is pretty terrible across the board and it seems their review process is no exception, but even so, reading the account of the above issue with domain access does not imbue in me a sense that the developer of this extension is competent. It would not surprise me in the slightest if there are many many other issues with this extension's code.
> ... all of this is consistent with an extension that should be kicked off the app store within 14 days.
No, it absolutely isn't. You can't take someone's livelihood off the app store within 14 days when they have every interest in complying with your policy but you just don't feel the need to even tell them what all the policy is. The fact it was approved in the first place is Google's fault, not the app developer, so is totally irrelevant to this saga.
If you can hit the Reject button you can fill in a text box that says why. There's no excuse for that.
The outcome seems to be that this extension fixed the bug and will still be kicked off the Chrome Web Store. That's probably not a net benefit for users _as a result_, even setting aside the unclear communication.
Imagine using a build system that doesn't give any error messages, except to say at the end "build failed, there was a syntax error". This sucks as a tool. Everyone would avoid it if they could, even if it found real bugs.
We shouldn't accept this level of information from services either.
> ... an amazingly huge oversight ... a point in favor of the review process
This seems like a rosy interpretation. It's not actually clear whether http permissions really are the reason the extension got flagged, and the fact that fixing them didn't affect the review feedback implies that the process isn't working the way you're imagining.
And both Grammarly and LastPass have had security bugs that let any website worm their way into the extension and access all the data from the extension (anything you've ever typed, for Grammarly, and all your passwords, for LastPass). Extensions with wide-ranging access are useful, and there's a reason Chrome has support for it, but they're also very very hard to get right, even if your entire business is writing a security-focused browser extension.
You could go the approach Firefox is going on mobile where there are currently six vetted extensions. As it turns out, they all need access to every website (or fine-grained APIs, perhaps). But... there are six of them. https://blog.mozilla.org/addons/2020/04/14/april-extensions-...
Do you have a link for that claim on LastPass? I use the extension and am wondering if I shouldn't use an PM extension thats more reliable in terms of security. Any recommendations obviously welcome.
The LastPass issues are all pretty old at this point - I mostly mention it to drive in the point that getting this stuff right is hard. (For what it's worth, the researcher who found those issues has good things to say about LastPass: https://twitter.com/taviso/status/1167311357957435392 and also fairly negative things to say about 1Password, which is what I happen to use.)
IMO a password manager is an extremely critical piece of software that I'm ok with if I trust its security model.
There are a couple whose security models I do trust. However, merging those security models with random extensions that may or may not have full run of all code executing in the same context as my password manager is a hard no. It's baffling to me that any legit password managers go to the trouble to write and support browser extensions, given the risk. It's betting your reputation for security on a very small amount of user convenience.
The sad thing is that there are so many bad extensions but they are run by professionals (crime gangs). They can figure out how to game the system (since there is no humans - that is definitely possible). So this "half-ass" approach by Google just helps malicious actors - they just need to be under the "radar" and game the system.
Google is trying to do "half ass" approach. Which does not help users, does not help developers, and it also does not help Google.
The right approach is to do these reviews fully and that human is involved at some point. Of course, these things are are not free. So they can require $1000 or more per year subscription if extension require more than basic permissions. They anyway require at least 60K per year for using an API. Or something like that.
But it could be also that Google does not care about real security: just appearance of security. They need to sell ads and all other things they do (Chrome, Android, G Suite, etc.) is just a smoke screen.
The problem is that extension behaviour is very limited without the https://*/* permission.
Say you have an extension that implements spelling check or grammar check. That need access to every single website to find the text fields it want to add functionality too.
Same thing with a password manager extension, can't find the login boxes without the https://*/* permission.
You want to read data off any page users are on, or add ui elements to every page users are on, or modify style shares to any page, you need that global permission.
About the only extensions that don't need global https permissions are extensions that are designed to only work on a finite set of websites (facebook improvement extensions, or reddit improvement extensions), or things like push-bullet that don't really need to be a chrome extension in the first place, they could be implement as a system tray applet.
This isn't the fault of extensions, this is the fault of chrome for not providing ways to do things without full wildcard https://*/* permissions.
Pushbullet actually has a desktop application with a tray applet. But if you keep your browser running 24/7 it might well be worthwhile to use an extension instead of another piece of software that installs separately, and has more access to your computer.
It should be possible to have an extension interface that allows a spellchecker/grammar checker to get a button on text input fields such that if you click it, then the extension is activated on that field at that time. That seems like a much better Least Privilege design to me than giving the extension access to... literally everything you do.
>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.
This is interesting, and I didn't realize this was a thing.
Are there any lists of extensions with these permissions, or ways that as an average consumer could easily audit my list of extensions for this?
I'm using Firefox and all I have to do to view permissions for an extension is to go to about:addons and click an extension, and there will be a "Permissions"-tab that lists what permissions this extension requests. It's similar in Google Chrome IIRC. Other than that, both browsers lists the permissions an extension requests when installing the extension, and further when the extension requests new permissions.
Yeah. I'v refused to install extension in the past because Chrome tells me this extension wants to read all data on all web pages... No thanks. (Except those extensions I KNOW must have those permissions)
Very good thing app store may nudge people changing permission scope.
Hope extension authors manage to meet the deadline and get their extension re-approved.
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?
> 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 goog did provide guidance on permissions, goog would literally have to audit every app in the store
You’re talking about vetting suppliers and products in order to ensure they’re selling safe products that consumers want. That sounds like an ordinary part of every retailer’s job to me.
Huh? How many products are sold at macys which allow its consumer to go perfectly bankrupt due to purchasing?
How many products ask for permission to ask for visibility into your bank account info? Your personal travel history? and disclose insight on how they are using this info in a way you can understand.
When devs start signing their apps with their full name and information where they live, lets talk.
Hit it right on the head. The localhost thing and coupled with the http thing make me cringe.
And to know they went from https://* to just one domain, yikes indeed. Then they left localhost. Hell, that probably made the case worker’s knee jerk even harder because of such a dramatic change, I can’t imagine they spend much time on each case.
Yes, 14 days is not a lot of time, but this is the ecosystem that needs to change. So the maintainer should have started out being more transparent on their architecture: period.
The fun is over, Google doesn’t care about loyalty or gestures of effort, this is an emotionless process. They care about provable, auditable compliance.
When you think about it, for Google, this is just a little sad story about an extension that didn’t make the cut. But it’s a small price to pay in exchange for evidence they are “enduring self-inflicted wounds” and using it as ammunition in avoiding billions of dollars in fines they face for violating user privacy laws.
Yeah, it sounds like they were working on a "it works, ship it" approach. That's not good enough when there are security implications to what you're doing.
The toughest thing in Google is getting in touch with a Human there. Its virtually impossible unless you know people working there. And this isn't just about scale. Take cloud services. Getting in touch with GCP customer service is a lot more difficult than other providers.
There is a native app for Pushbullet on Windows that you can install to add more features, and this is how the extension is able to communicate with it. I know there was a problem getting duplicate push notifications from the app and Chrome itself, and that was a way to remediate that.
At least that's what I remember from the time I used it.
For people focusing their comments on this particular extension + the permissions it asks for, please take a quick look at the numerous recent posts in the official forum for Chrome extension developers to see it's not an isolated issue:
It's a systematic issue that isn't specific to anything Pushbullet is doing and it's been like this before the pandemic:
- Reviews can take up to 3 weeks. This in alone would be crazy enough if you have an urgent bug to fix.
- Rejection emails are vague and don't tell you what to fix.
- After you guess at what to fix, you've then got to join the up to 3 weeks review queue again.
- If you try too many times, your extension gets pulled.
- On top of this, they've recently disabled new Chrome Web Store paid items, and user reviews.
Can anyone from Google escalate this and help extension developers? I can't speak for everyone but there's lots of complaints in the forum and little action beyond "we hear you and are looking to improve things".
The rule still applies: if you build your business on someone else's property, don't act surprised when they they casually destroy you.
It has happened again and again and again. Building for FB or Google is you making yourself their serf, and you will be allowed to exist at their whim.
This isn't very actionable advice, though, since there is basically no such thing as a software product that isn't built on somebody else's property.
You might think, "Ah-ha, web apps!" But no, Google can still casually destroy you there. Or you might think, "Ah-ha, desktop apps!" But the OS vendor can casually destroy you there.
> Or you might think, "Ah-ha, desktop apps!" But the OS vendor can casually destroy you there.
Casually? The amount of effort and goodwill, say, Microsoft would need to spend to prevent me from installing $PROGRAM on my computer is significantly higher than the amount of non-effort a single extension reviewer would need to expend to click "no" arbitrarily because they are having a bad day.
How would Microsoft do it? Add legit software to Defender? Ship a Win10 update that disables a key API call $PROGRAM uses? Add "if program == $PROGRAM then exit" to the CreateProcess code? All possible, none casual. To the best of my knowledge they've never done something like this. I'm less deep into Apple land but I expect something similar holds on macos.
The OS vendor could "destroy" you by making changes to the OS that affect your app, right? The Old New Thing[0] is full of stories of apps that exploited undocumented implementation details of the OS, and were surprised that those aspects were in fact changed in a later OS version.
To its credit (though not everyone agrees), MS has spent a lot of effort making compatibility shims, basically doing other people's work for them, but they have no such obligation.
This strikes me as a different class of problem. Of course software developers are at the mercy of other software and hardware, and have been since the days of yore. And even in that case, you could still potentially debug the issue.
This is a different class of problem. In this case, a gatekeeper is asking you to use their service to distribute software through their channel, and that channel is governed by vague rules that may, in fact, be enforced on a whim. Further, the gatekeeper isn't being clear with the rules, and why you may have run afoul of them.
That's a software problem for any language. Will the authors break compatibility? They sure can and do all the time. You are always at someone else's mercy in computer science.
People have been complaining about $dominant_player's power to destroy forever. It was IBM, then it was Microsoft, now we have new overlords. (For that matter, Sun was big enough to be a little obnoxious for a bit.)
That's unfortunate, but it is how the software market has worked thus far. Platform owners have massive power over those who build on them. For it to change, the market fundamentals will have to change. People thought the internet would change things, and it did - instead of one monster, we now have several, each with much more reach and control.
As far as actionable advice, well, starting a company isn't easy or formulaic. All I can recommend is look for niches where you'll be hard to dislodge and avoid situations where you have asymmetrical dependence on an entity that has no reason to care about you.
This is actionable advice. The action is to create an offer that is not entirely depeneent on a single platform provider. Don't build browser extensions for just a single browser. Don't build an app based business solely around an iOS or Android app - support both platforms. And so on.
This implies that a company could generally survive 50% of their revenue disappearing overnight. This may be true for 1-3 employee companies but past that I doubt it. Also generally the large majority of your revenue still comes from one of your platforms, making that one still likely an existential risk.
Microsoft threw in the towel, discontinued their web browser development and became a Chromium fork. How are these extension developers supposed to invest enough in platforms that complete with Chrome to succeed?
Here's some actionable advice. Go to your local president / prime minister. Preferably a populist. Tell them how you see the dominance of a few megacorps as a threat to national security. This argument is especially strong if from your point of view they are foreign megacorps. Throw in something about colonialism if it would help your case. Express your wish that they do something.
This is seems like a good advice to increase competition by using nationalist sentiments. The problem is that many of these nationalist countries would outright ban competition. So people who demanded local alternative will end up with less competition.
Technically, yes, you are right. But let's burn that bridge when we get to it.
At the moment the issue is the app store concept; it is designed to be a choke point, it is designed to be obscure, and it is designed to casually destroy software the store owner doesn't approve of.
(What is the status of Microsoft's app store, by the way?)
Maybe this means that software shouldn't be distributed as products, but as code. Maybe people should be free to run code of their choice on their computers.
How can you realistically avoid this for certain products though? For mobile for example, you've got the iOS and Android store policies to go through, the iOS and Android SDKs, and whatever restrictions Safari (e.g. no proper PWAs) and Chrome have.
Not everything can be a website that just needs basic browser capabilities.
> How can you realistically avoid this for certain products though?
You can't. It seems like if you're in business of mobile/web-apps which are not large enough to have paid, direct contacts with your relevant platforms, you should have more than one business.
I'm not saying it's a reasonable expectation or a good thing. But if you can pull off either 2 ok apps, or 1 main app and some set of simple things, it may be preferable to one perfect product from the business continuity perspective.
What business short of The Principality of Sealand's data warehousing is not "built on someone else's property"? Even a brick-and-mortar business needs to appease the taxman.
It's a matter of degree, I imagine. Some approaches expose one to this risk to a greater degree than others. The highest risk might be placing an app or extension into a walled-off store controlled by a single company with sole authority over what is listed there.
1. I agree as to the need to get off the Google lands.
2. Being able to create business relationships to build on other people’s property and work without fear of their yanking the rug out is an incredibly important part of a working society.
Except chrome isn't really a "property app" so much as a "proprietary OS"; it's the platform in which ~70% of desktop users spend >10 hours a day. This is different from eg Facebook, in that FB's valueprop is being "full stack" (content + controls + ads); while Chrome's design is open-ended -running other people's websites, with other people's extensions.
The other side of the issue is tough, though: Chrome extensions are regularly purchased & have ads embedded into them ( https://superuser.com/questions/1551266/how-to-track-down-wh... ), so Google's chrome extension team (couple of ~hundred person?) is essentially held accountable by ~1 billion users to the behavior of ~10s of thousands of extensions.
Google's 2014 net income was $14B. Chrome is one of the most valuable properties that Google owns, as it allows them to control a large fraction of advertising on the desktop, and advertising is their core business. They can afford to hire thousands more developers to vet Chrome extensions, yet they don't - implying that at least the upper levels of the Google command hierarchy don't consider this to be a problem or don't care about fixing it.
This is not a useful comment. You are suggesting a world where no platform is extensible, which isn't realistic nor desirable.
When you are building for an extensible platform it's entirely reasonable to be surprised when the vendor sabotages you. Platforms like this are good because they help both parties, so there is an expectation that one side won't sabotage the other in general. When it happens it's surprising, and usually not a great outcome for the platform provider.
Their business isn’t solely built on google. Part of it relies on browsers and google have a dominant position in browsers. Should no one build a business related to browsers until google is toppled? I wouldn’t follow your “rule”, as most successful businesses started out by violating that rule.
>We hear you and are eagerly looking to improve things.
Joking aside, isn't this just what people should come to expect from the company that has always tried to normalize the "no support and no service" model?
If these antics start causing GOOG to lose share in the browser market then they may review these policies, but I highly doubt it. At the end of the day GOOG is an ad company and publicly-traded at that. They have a bottom-line and a lot of shareholders watching it.
Support channels/forums are probably not the way to go, in other words. Stop using their browser, stop using their search. That's probably the only way they will be incentivized to change.
It's so difficult to imagine a) getting ahold of someone at Google who can actually help you, and b) having some sense of assurance that they will actually help you.
"Google deleted my X" posts always rise to the top on HN because they elicit a strong emotional response from developers. I think it's worthwhile to reflect on why that happens. For me, it's because I absolutely despise seeing an algorithm have control over an individual's livelihood. This may be part of the Google mythos? Or it may simply be that they make their real money selling ads, and allocate support resources accordingly.
I don't understand how people work for these companies as developers and implement these policies and systems and aren't just as angry about it and don't stand up to their supervisors over it: if frankly makes me have a really low opinion of people who work for Google, Apple, etc. :/.
They get a few hundred thousand dollars a year to do it. If you're working for a global surveillance ad tech company, you're obviously not there for the good things they do, you want the money. And they give them the money.
I can confirm that the support on for example displayvideo360 (one of google ad products) is absolutely stellar even for very low revenue players. Meaning live chat with well trained support persons, and quick escalation if needed. Resolution rate : 100% within a couple day in our case.
At Amazon the most important person is the customer. At Google the most important person is the Google engineer. I firmly believe that's why they suck at selling enterprise products.
I’ve emailed and sent Linkedin msgs to 3 people who work at gcp for cloud credits. They didn’t care. AWS gave us credits + support in less than 3 days. I wish Google best of luck with their 5yr strategy. Hope their enterprise game is better than their startup one.
I definitely agree. Microsoft Azure also, I feel customers have a very big part in the direction. (And right from day 1, long before azure, Microsoft focused on having “partner networks” which meant that although you weren’t dealing with Bill Gates directly you were part of a chain of motivated people all the way through to Bill.) Google’s way is not gonna last.
> Stop using their browser, stop using their search.
The more people that do this in general, the better. We've given Google entirely too much power to control what people see and read (and it follows, control over what they say and think).
They don't have our best interests at heart, they have financial interests at heart, and everything else flows from there. I'm not saying this is evil, but it's certainly not _good_.
What should I use for search? I tried switching to DDG for a month but I kept finding myself manually typing in Google.com to make the more obscure searches.
That is my exact habit now - DDG for the easy/lazy stuff, google for more obscure. I'm still giving them some search info to profile me, but hopefully it's skewed enough that it's value is lower. And I'm definitely giving them less ad views.
I actually prefer DDG in a few fronts, like configuration of language and region.
If you have all the adblockers and stuff, and open a fresh private browser, nothing wrong with taking advantage of Google's still-superior search for finding things.
I want to share my opinion on this as it's something that I've spent a lot of time thinking and talking to the Chrome Web Store team about.
The very core of the issue here is less about the manual review process (although that sucks) and more about how the review process is necessary due to how extension permissions work in browsers to-date. The current process works similar to how Android and IOS permissions worked back in the day by requiring the user to grant all permissions up front (equivalent to giving an extension sudo permission to your browser).
The feedback you'll most likely get from Google on this isue is that the solution to this is to narrow down what URLs your extension works on... but that comes with a pretty big assumption that an extension can declare that information up front. Many extensions (including developer tooling) don't need to run on EVERY page - they need to run on specific pages where some extension-specific code is running (this is the case with Urql, Preact, React, Rexux devtools). Narrowing down by URL just isn't possible and an ad-hoc solution where extension-specific code on the webpage can trigger permission requests (similar to how a website requests access to your camera) is needed.
I've written up a proposal for this case which I think addresses 90% of use cases where "sudo permissions" are being requested up front and in reality, could be requested on an ad-hoc basis. Whether it's an agreement or some criticism, anyone who is able to get involved in this discussion - please do! Every other platform is using ad-hoc permissions and we need to push for the same with browser extensions.
I blamed the Chrome Web Store team at first but I can understand why they're anxious about allowing extensions onto the store which basically access everything on your browser.
The issue is the outdated permission spec for browser extensions (I've gone into more detail on another comment on this thread)
Different extension developer here. The Chrome Extension store ecosystem has become a nightmare for developers over the past year. Some items:
- Extension review times have gone from 1 hour to a variable amount of time ranging from 1 minute to 3 weeks or longer (try to plan a release or spot fix an issue when you have no idea how long it will take for a deploy to reach users)
- User reviews of extensions have been disabled (how are you supposed to build an audience or build up trust without reviews?)
- Manifest v3 was announced (this was actually longer than a year ago) which will completely break many types of extensions. Over a year later, it is still on the horizon but the beta releases of it are buggy so it is hard to even try to adapt to it at this point.
- Persistent extension related bugs in Chrome are not being fixed and new regressions are being introduced breaking previously working extensions (which you then need to rush out a fix for but good luck with that when the reviewers may take weeks to approve the update)
- Chrome is exploring hiding extensions by default so they no longer will show up automatically by the omnibar when you install them (say hello to a huge amount of confused users who don't know where your extension went)
I understand the Chrome team is trying to address a user trust and fraud issue with extensions and we are grateful for that. However, the Google extension team appears to be massively understaffed and are having huge issues managing and evolving the ecosystem.
Fellow extension developer here as well. I've been trying to get an update approved since February or March.
Submitted an update in late February and decided to update my screnshots. Remove the screenshots and add new ones only for Google to tell me "you can't add screenshots while you app is in review", fine, add them later after the review.
3-4 weeks go by and I check the approval status. Status has been rejected because....no screenshots provided. I've since updated the screenshots and resubmitted for review. Currently still waiting on approval.
I've been planning on doing a Product Hunt Launch but that's been put on hold until I can get an updated version in the chrome web store (the current version is very old and buggy). I've even looked into distribution outside the store but turns out chrome will no longer let you do that.
> Chrome is exploring hiding extensions by default so they no longer will show up automatically by the omnibar when you install them (say hello to a huge amount of confused users who don't know where your extension went)
Haven't heard about this change (more info at [1] for anyone interested) - wow! I really wonder if those are the first steps of the roadmap to get rid of extensions altogether.
Chrome on Android already doesn't have extensions. That made me switch to Firefox on Android and within a week my laptop was also on Firefox because it's nice to have tab syncing etc between devices.
If enough users do this I think Google will review their policy on extensions and specifically adblockers. Can't browse without one anymore after having used it for a while.
> Extension review times have gone from 1 hour to a variable amount of time ranging from 1 minute to 3 weeks or longer (try to plan a release or spot fix an issue when you have no idea how long it will take for a deploy to reach users)
This is potentially a huge security issue, because the natural way to "fix" the problem is to download and run arbitrary code as an end-run around the review process.
They have some automated review mechanisms to try and stop you from downloading and running arbitrary code, but it's definitely possible to do it.
In my case I settled for having a remote configuration file that I could use to disable features in an emergency (and had to use it a couple times), as a compromise since I didn't want to pull down arbitrary code but was tired of getting burned by it taking a week to push a bug fix.
I removed my Chrome Extension from the store in February. It was averaging about £30 per a month in sales and the cost of keeping up-to-date with the changes in Chrome/the extension store seemed hardly worth it.
The thing which really pushed me over the edge was their new developer dashboard, it was a step in the right direction but what missing some key features which were present in the old dashboard. Googles solution? Make us use both dashboards for almost a year.
I think the interpretation that Google does this because it does not want to compromise the review process to malicious extension authors is a very generous one. As others pointed out, a motivated enough entity could very well be probing the system using multiple submissions (sure it gets your account banned, just use several accounts).
No what is really going on is that Google wants the ability to reject an app for any reason without actually having to give the reasons. To for example protect a business interest.
The only reason for not making a transparent decision process is because you want to keep the ability to make decisions that don't follow the rules you set.
To the people saying that we should keep rules secret so that malware authors can't work around the rules, I ask: the same argument applies to laws, but most people agree that we want transparency. So what makes this different in principle? (I understand that Google might not have an obligation, but you are saying that they do the right thing)
Exactly. It's also completely contradictory to Google's Project Zero, where they expose security flaws in great detail publicly with the intention to educate users and devs to fix the issue and prevent it from happening again.
At the very least, Google should provide a way to contact an actual human - especially if the developer has 1M+ users.
don't create extensions. create browser controllers. you can release them as binaries. anyone can download them. They instrument chrome using the remote devtools API.
I think folks are drastically missing the forest for the trees here. This is just one minor example of the INSANE process that is now the Chrome Approval Process. I've seen extensions go for many months getting random rejections with no reason given.
This forces developers to GUESS as to what is wrong. Want to try and develop according to a roadmap or timeline- forget about it. There is no "app store" approval process that conducts itself in this way.
Fact is Chrome is 80% of the market so Google doesn't worry about competition. If Google Chrome is broken- then the internet is broken. It harms new entrants trying to develop and innovation.
After the 2nd or 3rd rejection- have a HUMAN intervene. Explain what is wrong. Devs are more than happy to make the changes. But you can't do this "make you guess" bullshit.
DOJ and EU need to get involved. Someone at Google with their wits about them and revamp the whole process. It's a travesty against the developer community and should be fixed ASAP. Also from what I hear they need to start with new LEADERSHIP.
This year, my resolution was to start reducing my dependency on Google products. I installed Firefox and deleted Chrome. Then I downloaded a file size manager and remove all files I haven't open in past 5 years, deleting from GDrive. THe same with GDocs. All emails larger than 1Mb were checked if they needed to persist. I end up unsubscribing from the 100Gb service from Google, my inbox has 6Gb, I deleted the Picasa stuff (I was not using), and the GDrive was reduced to 3Gb (the limit is 15Gb altogether).
I am quite happy with this.
PS: I started considering doing this, despite being a Gmail user since 2006 because of their removal of clause "stop being evil" and the huge amount of tracking being done in Chrome, which frankly, annoyed me very much.
You know that Firefox is Google right? Like, literally, Google is the main company paying Firefox's developers, and if they don't do what Google says, Google can just cut the funding, and they all end up unemployed, right ? Of course, to avoid a monopoly, Google would need to fund a different browser instead, but still, people have families to feed.
If you want to cut dependencies on Google, Firefox is not the answer, and neither is Tor or any other Firefox derived web-browser.
The money that Mozilla makes from Google comes primarily from setting Google as the default search engine in Firefox. You can see lots more details on this here (2016 numbers): https://www.mozilla.org/en-US/foundation/annualreport/2016/
I think stating that Google controls Firefox is vastly overstating the degree of influence.
Bing already pays for users, and once you give it time to build up a profile of you so it stops returning reptiles and vegetables when you're trying to search for Python libraries, it's equal in quality to Google. If having a high quality service literally give you things to use it doesn't break Google's stranglehold on search, what will?
I think the default for some time was DuckDuckGo, and that helped raise them out of complete obscurity, but it didn't reshape the internet landscape.
After 2nd to 3rd rejection if it will require a human to intervene Google will have to hire half the earthlings to deal with crappy spammers that will simply spam google store with their extensions.
The answer is not human interaction, the answer is automation tool to give more details as what was detected and didn't pass.
I use firefox, stopped using chrome last year. But my comment was about general usability. Chrome or something else, whoever is number 1 will get corrupted by power. It's human condition
Interestingly, the very same Google is somewhat different in Google Play. Whenever your app is rejected, they will specify why. Sometimes it's evident that there was a human involved — I once received one of my listing screenshots, with the part needing change circled. The thing is, sometimes those rejections are bogus. Then good luck getting to any humans to fix it if you don't know anyone from developer relations.
Most of the time they don't specify why an app is rejected. My app update rejected before I had no idea why. I disputed the rejection which I didn't know what it was and update approved later.
Google play store app review is the opposite of Apple's review process.
I'm in the same boat. My open source chrome extension[1] has just been taken down[2] after several years of no complaints because it apparently violated content policies related to nudity and pornography. Say what? Well, I guess you could view _any_ image using my extension, including nudes. Isn't that the problem with most other extensions which could be used on porn sites, like editing cookies, etc? I've submitted it for re-review but I'm not holding much hopes.
I mentioned this in the GitHub issue thread (howdy!), but I strongly suspect it has to do with specific references to pornographic sites in the extension's manifest.
If only Google would mind its own business instead of playing mommy-knows-best and dictating its morality on grown adults.
That's a possibility, too, but the email specifically mentioned pornographic content or extensions that might "drive traffic" to pornographic sites so that seemed like the more likely reason.
I'm also an extension developer, and Google has done this to me a few times too. We request permissions specifically for what we need, and our extension is unlisted and can only be installed from our website.
Google is a bully, and they use their size and the threat of permanently removing access to your Google Account (and family photos) to terrorize small players without cause.
How many people would Google need to hire to provide email support for extension review for extensions above a certain size? It can't be a huge dent in their budget.
Not going to happen. This is an issue people have been raising for at least the better part of a decade... don't expect anything to change now.
A more productive approach would be to focus on web browsers that allow you to do what you need to and let Google fix what they need to encourage you back. I know, most extension developers will say 'we can't do that because it's where the users/customers/whoever are'. But as long as you encourage their bad behavior by supporting the platform, expect the bad behavior to continue since it's not hurting Google. As a result, it's just a cost of doing business on Google's platform which is unlike to change for the better.
I think you overestimate the percentage of Chrome users who use Chrome for the extensions rather than other reasons ("it's fast", "it's what I'm used to", "I like Google", "Firefox is weird")
maybe what we're really seeing is an alternative - users don't care enough about the quality of the extensions ecosystem. Otherwise browsers should be racing to have the best extension ecosystem.
I believe the suggestion is to incorporate this "bully risk" in your business plan. Some business models might not be profitable anymore if you do this. Others just need additional diversification or more risk capital.
Not exactly to your point, but you raise an excellent reason to never ever use your "personal" account for business things. Google, Amazon, YouTube, it's all the same.
It's all very convenient, until you lose access 10 years of e-mail because of a Chrome extension review.
Haha, my "workarounds" consisted of being persistent with a few different support emails I found, posting on the Chromium support forums, and a few other things. Pretty boring stuff, and I'm not really sure that it even worked.
Weeks or months from now, I'm sure someone will get their extension removed from the store, and may come across this post scrambling for a solution. If that's you, please reach out to me and I can send you the support emails and everything I tried.
Google has effectively created a private monopoly on any Android applications related to Covid-19. And the last time this sort of information was posted to HN the comments section was a race to see who could do the best apology for Google.
This policy by Google is hurting people and businesses.
Meanwhile, Apple has a similar policy but all they do is just take extra care when reviewing your app. I suggest you port your app to iOS and submit it to the App Store. Apple will accept it and approve it.
I had a similar experience but it wasn't important to me and I let it go despite being a growing extension with 10s of thousands of users and lots of good reviews.
Does your browser extension really need to access localhost/* - as in, port 80 on my local machine? That would make me very uncomfortable about installing the extension.
Would it be possible to restrict the extension to accessing a specific port or endpoint that is used by PushBullet?
We use localhost to communicate with our desktop application which is commonly installed alongside our extension by users.
An example of how we use this communication channel is preventing both our extension and desktop apps from showing notifications on the same computer. Our apps are all about notifications so this would get unacceptable very fast. We ping our local desktop app via localhost to see if it can manage the notification, and show it with our extension if it isn't running.
Maybe if we limit it to just the local port we use? Seems like it can't hurt to try that too.
This may be well what needs to change, but in any case the message from Google should have been explicit about it instead of the dev involved having to create a blog post, hope it gets traction on HN and that someone here knows what the problem is.
Yes and no, I would be glad if Google in general could get much much better at this but in this specific case I'm sorry but http://* and localhost access is not a hidden small thing.
So native messaging is fundamentally about opening a named pipe to a child process managed by the browser. I found that the pipe would silently break or time out. In the former scenario, the app was running but could no longer exchange native messages with the browser or extensions - chrome was just ignoring the pipe traffic. In practice I was able to use native messaging to spawn the executable but to actually talk with it I needed to use a websocket, kind of defeating the point.
I initially assumed I was doing something wrong but after a week or so experimenting with simple test cases I could not get it to work. Maybe it works fine on Linux and Mac but not Windows.
It might be a bit trickier, because if you hardcode the port in the manifest, the user wouldn't be able to change it?
Might be better than nothing I guess, but on the long term you'd need to add the port in settings and request the permission for localhost+port dynamically? But that's got another issue, e.g. last time I tried it [0] for my extension, Firefox didn't support dynamic URL permissions for URLs with ports.
You can probably get around this by setting up some DNS like localhost.pushbullet.com -> 127.0.0.1. It's probably not in the spirit of what they're asking for though, if it is indeed the problem.
Huh? What kind of router would filter out 127.x responses by default? Also, this wouldn't work with DoH enabled which is where we're heading with browsers.
Your resolver may not always permit this sort of thing, and that would just obfuscate what they're doing a step further which may come across as sneaky.
I doubt it is at all common in end user environments, but unbound for instance can be configured to prevent local IPs from being resolved in other domains. It's a good practice to follow in a datacenter environment if you're connecting out to hostnames you resolve from DNS you don't control.
This is a very good suggestion, and could very well be the root cause of these rejections. It’s a potential security vulnerability that is triggering the violation.
Right, this suggests the app either (1) runs a web server on the client device, or (2) wants to access a third party webserver on the client device. I don't know if this is common. Or maybe I don't know/understand why this is needed.
Also, isn't allowing access to the app's website the same as allowing access to any website? Can't you just redirect?
Redirects shouldn't compromise the CORS / XSRF security model, which is the key item of concern from a Chrome Extension standpoint. Like if pushbullet.com redirects to foo.com, the crex is now looking at the foo.com page and its permissions will apply accordingly.
Maybe I'm naive but what if pushbullet.com was just running a server-side fetch and returning the result? That would bypass CORS, essentially acting as a proxy server.
That's a great question, and it's not limited to Chrome extensions.
In general, for any resources that don't require credentials to access, pushbullet could hypothetically serve them at like pushbullet.com/proxy/gmail.com/favicon or something. But resources requiring credentials are another thing entirely.
In general, the thing that prevents a third-party server from MITM'ing your interactions with a target server is a combination of domain names and SSL certificate. That doesn't prevent a site from trying to get you to let it act as a MITM, but it prevents the site from acting as the MITM while claiming it's something else.
As a concrete example, let's imagine pushbullet.com wanted to act as MITM for your GMail account. If it has your username and password, then (handwaving here; GMail's authentication model is complex) it could do that; it could forge well-crafted requests that look like they come from your browser, and get proper responses back.
But if it doesn't have your username and password, there's not a lot it can do. Your browser won't give pushbullet.com cookies scoped to gmail.com, and if pushbullet tries to ask you for your password, they can only do so much to make it look like GMail's the one asking (SSL certs make it hard for pushbullet to try and forge a GMail front-page with a gmail.com domain). It can still happen, but "user was tricked into ignoring the domain name and gave their password to another service" isn't something web security models can fix.
Thanks for the explanation! I guess I was looking at it more from the perspective of merely making requests (without creds).
My understanding is that if an extension has a wildcard 'https://*' origin listed in its manifest, then it can make cookie-populated requests to any domain that matches the wildcard. That's actually pretty scary from privacy and security perspectives. But I suppose that's part of the reason CWS has moderation in the first place.
Pushbullet doesn’t need a Chrome extension to tell their server to make a web request. But, their server doesn’t have your cookies, so there’s no security concern.
I have a desktop application that communicates on localhost. I recently read that it’s advisable for the server to bind port 0 and then a free port will be chosen to avoid conflicts. I guess the port could be a configurable option. Although for my users it would just add confusion.
I can see why the security conscious would not like a dynamic port though.
By whole account deleted do you mean your Chrome dev "account" or your Google account including Gmail, Gcal, and YouTube? The latter is my greatest fear.
My play store dev account was deleted, but my gmail and everything was fine. Good thing because I had a lot on there.
To get back to the store I created a new account with a different name. But then google took down my apps because their bots said I was impersonating “Joe Hinkle” (which is me). So then I made this blog post to “verify” that Joe Hinkle gave permission for Impact Studios (my new account name) to host my content, and it worked...somehow...
or pay them 6 bucks a month for a G Suite account instead of free gmail so you actually have the ability to call a 24/7 customer service phone number and yell and scream and get someone to find out why they removed access to your lifeblood account, and have access restored.
it constantly amazes me that so many HN people put their ENTIRE LIVES/BUSINESSES in a free account that [has been proven, countless times] can be taken away from them at any time.
i mean what do folks expect for free?
google is an asshole company, sure. but so many HN'ers expect to be treated like "customers" with associated "customer rights" when in actual fact, they are a free user, a total nobody.
pay a company a small bit of money, and hey, whaddyaknow, you can suddenly call them up and talk to someone, figure out why they removed access to your account, and get it sorted out.
Another happy PushBullet user here. Extremely useful for receiving text messages from my phone while on my laptop, especially for web apps that insist on sending security codes that way instead of TOTP.
This sort of behavior from Google really is infuriating. How they can just decide to boot an app from the Chrome Store that is installed by over a million users is mind-boggling.
It's a pity that Chrome doesn't allow extensions to be installed from the new Edge store, like Microsoft allow Edge to install extensions from the Chrome store. With both built on Chromium, that could've potentially been a workaround (though you may want to consider adding this extension to the Edge store anyway).
Hopefully someone from Google will see this and stop the madness or be able to provide more details on exactly what needs to be done, though I wouldn't bet on it.
I switched to Edge chromium when the first production release came out and I am extremely happy. I use all my extensions including unlock origin straight from chrome Web store and it feels a bit snappier than chrome itself.
> It's a pity that Chrome doesn't allow extensions to be installed from the new Edge store
Why would anyone want to do that? What's a real pity is that they make every effort to block users from installing their own extensions. App stores are terrible.
No, they make every effort to ensure that installing extensions outside the store is annoying so that you can't push your malware by just having users download and install it. This kind of malware plagued Firefox for years until they made extension signing mandatory
If I am in a position to install random shit into Firefox I am also in a position to just modify Firefox, so that doesn't accomplish anything at all except remove functionality from users.
I think I am not understanding your use of the word "target" here, as I would have expected that to be the person being targeted by the malware install, but that person isn't someone who by definition even knows what is going on: it is the attacker who is choosing to install something into Firefox without the express knowledge of the target, and so it is the attacker whom I am noting is able to choose to instead modify Firefox; if the target were making the decision to install the extension then clearly they should be allowed to do whatever they legitimately want to do with their software.
I got the same notification yesterday morning for my own open-source extension HabitLab ( https://habitlab.stanford.edu/ ) - same vague request for "you're not using the minimal set of permissions" without mentioning what permissions they want me to stop using (HabitLab is already using the minimal set of permissions for the features it implements - any removal of permissions would have to be done at the expense of reduced functionality). Emailing just results in them sending me a link to the policy. So this is definitely not an isolated case.
We spend a quite a bit on Google Ads yet they seem to refuse devoting even a few minutes of a knowledgable support staff’s time to our account—even when we’re trying to figure out how to give them more money. For 1-2 years our product shopping ads never displayed and we couldn’t get anyone to tell us why. One day, it just started working by itself (perhaps some engineer pushed a fix).
Contrast this with their sales strategy of aggressively making a human call me every quarter to try to up my budgets. I’m not sure why they are so against helping people succeed with their products...
It’s like they are allergic to manual human processes (unless it’s sales).
I was using Google Ads for a pet project of mine. I lost the password to one account, and then decided to set up another. Using the same CC (which is also my personal CC) on both accounts triggered something and they killed my account. I explained what happened, and told them to check the first account access patterns as they had abruptly stopped due to the loss of the password. They didn't care in the least.
Yes I in fact did. One of the only reasons I took the call. He said he would check internally. Nothing came of that. Technically they weren't sales but were doing a free account review (but purely focused on how to increase my spend).
It is a common theme with Google, what they do makes sense, but communication is impossible.
I don't know if it is an artifact of overusing machine learning "our neural network trained on a variety of malware gives your app a score of 4.3, you have 15 days to get it down to 4.0". How is that calculated? No one knows, maybe you shouldn't use the location permission if your icon is red and your domain is not in .org, or something like that.
Or maybe it is a form of security by obscurity. Or maybe they just don't want to pay for people to support you. Who knows?
It's that last one. Chrome Extensions, as a whole, are a value-add to Chrome. Individual Chrome extensions have negligible added value.
As long as Chrome isn't killing extensions "everyone cares about," their system can bias pretty far towards making it had to get an extension accepted and maintained in the store without killing the whole ecosystem.
Slightly related, Google is also tightening up Android 11 location permissions (with good reason). In this blog post[0] they outline a process for getting approval that was supposed to be underway by the start of May.
So far I have not been able to locate this form nor have I been able to find any Android developers who have.
If anyone here knows where it is or what the deal is, please let me know.
The SMS access process never worked after it was introduced in a similar way several years ago now. Google even put some minority groups in significant danger to their safety as a result.
Nobody at Google gave a shit and it was never fixed.
Those rejection emails are most likely sent by an AI. If you reply back and ask them to specify exactly what is wrong, you'll get the same generic email back. Ask again, and they'll send the same generic response without any details or comments written by a human. They simply can't specify the problem at all. That's how you know you are talking with an AI, not a human.
The correct way to respond to those rejection emails is to ask for a "human being" (this is the keyword that works) to review the case. Also explain in the email why there isn't anything more you can do (if you have done every possible fix already).
As a side note, when AI systems get more common, this will be a common nightmare for regular people. When an AI makes an incorrect decision regarding you, no-one can check the code why it happened because the code doesn't exist. All we may have are some weighted matrices and neural network data as bunch of numbers.
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.
I am pretty confident there is no AI involved, but just a regular deterministic code analysis tool that flags potential discrepancies between code and demanded permissions.
We usually simply call those bots (there can be AI bots too, but there seems to be no indication that this is one).
> when AI systems get more common, this will be a common nightmare for regular people
I'm not sure. We've had automated phone customer service systems forever, but companies that in any way care about their customers still let you escalate to a human.
Google are cutting the branch they are sitting on. I only use Chrome because certain extensions are not available on Firefox. During all these years, they've become impossible to deal with. I open Chrome with 10 tabs and after a couple of hours it's using gigabytes of RAM. From a thin client, it became the thickest client in the visible universe. It's time to consider options... not that there are many.
> I only use Chrome because certain extensions are not available on Firefox.
Which extensions? Especially now that Firefox has moved to WebExtensions, it should (in theory at least) be straightforward for someone to port them over.
Like, if anything it's usually the other way around (Chrome not supporting extensions that Firefox supports).
I just want to mention this is why I believe Google will never be able to compete with AWS, or otherwise be credible in the B2B space. You're relying on automated systems which can take down your business on a whim, with no recourse.
Where I work uses Office 365, which is a horrible, horrible technology compared to Google Suite, but I can't, in good faith, argue for switching to Google. It's not a company I'd ever rely on in a business setting.
I had a terrible, deep-history bug cause problems with one of my Office 365-using clients about six months ago. It was a genuine PITA to troubleshoot.
Once we figured out the source of the problem, I was on the phone with someone from Microsoft who knew exactly what I was talking about, and the available workarounds, within the hour.
Consider yourself lucky that your extension wasn’t pulled after 1 day. I received a 7-day notice on a Sunday and complied same-day. My extension was pulled the next day, and I received an email stating that 7 days had elapsed.
I managed to get reinstated because I know people on Chrome’s accessibility team who promote my extension, but even with that assistance it was still months before I could push a new version without going into purgatory.
FWIW, I’ve had even more issues on Firefox. It’s like they’re in a competition with the App Store for “most opaque review process”.
We went through the same problem at Superhuman (and as I write our latest extension update has been pending review for 2 weeks, so maybe we're about to hit it again).
Simeon on the mailing list was quite re-assuring, and I would recommend reaching out to him, though there are limits to what he can help with.
That said we found that the review process is quite arbitrary, resubmitting may work simply because you get a different reviewer. (We've seen identical copies of the extension with different version numbers where one was approved and one rejected).
We've also observed that they use some kind of automated code-analysis to tell whether or not you're making use of the permission; so you may want to check that it's obvious from the code included in the extension bundle that you need the permissions you're asking for.
We've also hypothesized that they apply different standards to extensions depending on the number of users – our staging extension (~50 users) usually gets approved quickly, but our production extension usually takes a while and is less likely to be approved. (This may just be luck of the draw coupled with arbitrariness though)
Google really sucks at customer service. Like they either don’t get it or they’re so far up their arses that they think fancy AI algorithms will magically fix it.
They are the most inhuman tech company I have dealt with out of the big 3 clouds.
I have a similar experience. I am trying to get an oauth consent screen approved. It’s a simple thing. It takes up to a week for someone on their side to reply and it’s mostly one vague sentence. They don’t give a full list of what needs to be done. I’ve been at it for more than a month. It’s like they really don’t give a shit about how much time you’re sinking to make things work with their services.
I have a love/hate relationship with Google. On one side they know how to keep things reliable like google search, on the other side they need to stop doing a 100 million things and do 10 things really well and maintain it for eternity.
If someone eats Google’s Search lunch, they are done for.
Ironic reading this today. Got locked out of an old gsuite we manage for someone on Monday because I typed the recovery mail wrong 3 times...omg what a crazy battle to follow their recovery process.
Sent them sooo much proof, answers, cname changes, invoices, emails, etc etc, but still get the same canned response back.
The weird thing is I never got a single notification on the recovery mail that unauthorized access was attempted and that the account got locked.
Honestly I feel like such a dumb ass for making our company use gsuite now. I don't think I'll ever recommend a google product to anyone again.
This happened to me, too. After emailing customer support several times asking for clarification, and getting the same uninformative answer every time, I decided to take down the (free) extension (which had 20,000+ users) rather than risk having my developer account deactivated for uploading a rejected extension too many times.
I use Pushbullet every day, and would be gutted if it were killed for such a ridiculous reason as this.
> The other opportunity is the tabs permission. This permission lets extensions see what tabs are open. Pushbullet uses this permission to avoid opening new tabs for websites that are already open when mirrored notifications are clicked. This is a small sacrifice to make to let go of a big permission. Let’s let it go!
No, that "small sacrifice" sounds super annoying! I don't use Pushbullet, but if I did and this got removed in an update, I'd be pissed off! At least leave it behind an optional checkbox.
Thanks for the feedback here. It strikes me as a little crazy I may be infuriating you with a change and never even know if that was something I had to do?
> It strikes me as a little crazy I may be infuriating you with a change and never even know if that was something I had to do?
Oh, for sure! Just to be clear, I didn't intend my comment as a criticism.
It's nuts that you, as the developer, actually went so far as to remove features in your first pass, and Google still rejected that attempt without additional instruction.
The fact that they were requesting https://*/* and http://*/* (i.e. full control over all your accounts) without it being absolutely necessary reflects terribly on them.
Still not clear why localhost (which can mean root access to the local machine since it may have localhost-only services that enable that) and cookies access is needed, also http://*.pushbullet.com is unnecessary since they should always use HTTPS.
If they had properly implemented the extension they may not have this problem now.
Nobody is against enforcing better behaviors from developers, the issue is that they are not telling anyone what those issues are. I don't know why you can always count on someone to defend a multi-billion corporation against small companies, is there no empathy left?
> I don't know why you can always count on someone to defend a multi-billion corporation against small companies, is there no empathy left?
I don't have empathy for companies, I (try to) have empathy for people. Small companies are made up of people. Large companies are made up of people. I try (and often fail, alas) to have empathy for the people in both cases.
Does Google send this message to random developers ([1]) and then look at the changes that developers make to get a list of things that developers apparently think are not so good?
We had a similar interaction with the Chrome Web Store out of the blue. After a few maddening rounds of requests for clarification and nonsensical canned responses, I finally just gave up and accused them of gaslighting me. Our extension was restored the next day, of course with no explanation for the ordeal.
If you are an engineer those type of stories should make you rethink your usage of Google Chrome. Chrome having so many users empower them to implement those type of nonsensical policies.
As said in other comments it is trivially easy to switch to Firefox (or any other browser you feel that fits your needs better).
This is scarily reminiscent of Facebook's App Review process. We submitted 8 identical Apps that, functionally, are just webhooks for Messenger events. All required documentation, justification for the two permissions we needed, screen casts, and test login credentials were submitted for the reviewers.
3 were approved. 5 were rejected - all for different reasons.
Re-submitted the 5 with no changes; 2 more got approved. Two were rejected again. One was rejected with a firm reprimand for making an identical submission (must have hit the same reviewer).
Shuffled some words, re-recorded a couple videos - 2 more approvals, 1 rejection.
Re-submitted the last outlier without changes - Approved.
We are very weary of playing Facebook App Review whack-a-mole.
I haven't written a blog about it, but it's a common experience for those building B2B integrations with Facebook. Also common is feature deprecation with replacement functionality gated (read: withheld) behind a closed beta program. They're difficult to join and often can only be entered if you commit to supporting other Facebook APIs and features (those they wish to publicize).
A little bit meta here but these words are true even today :
Suddenly, 20% meant half-assed. Google Labs was shut down. App Engine fees were raised. APIs that had been free for years were deprecated or provided for a fee. As the trappings of entrepreneurship were dismantled, derisive talk of the “old Google” and its feeble attempts at competing with Facebook surfaced to justify a “new Google” that promised “more wood behind fewer arrows.”
…The old Google made a fortune on ads because they had good content. It was like TV used to be: make the best show and you get the most ad revenue from commercials. The new Google seems more focused on the commercials themselves.
Developing extensions for Google Chrome is a particular form of masochism. They really don't seem to care. And things took a turn for the worst last December when the approval process went from hours to weeks.
It seems like all extension developers play the same game of guess-and-check to find out which permissions they should remove, and the unlucky ones get banned for trying too often.
When I read something like this I have to assume Google is just trying to kill off extensions, it's such a glaringly obvious problem there's no way any human has seen and okay'd it with good intentions.
I'm the person at $dayjob who has to chart a course through the recent chrome web store changes and this is honestly my conclusion too.
These extensions don't make any money at all for Google, in fact some of them lose money for Google (privacy oriented extensions, ironically.)
They are a security nightmare for Google, capable of side channel browser attacks or direct abuse via a permission (all_urls permission can read your emails to grandma.)
Google doesn't want extensions to exist, and they also can't outright kill them without creating a new foothold for their competitors in the browser wars. So we get this intentionally masochistic process change. Jump this high or we'll ban you. Now jump higher but with your eyes closed. Okay, now backflip or you're banned. The extension developers have absolutely no power to fight back.
This is a good extension but here is a cool hack I've discovered that let's you do this anywhere without any chrome extensions:
- Create a new whatsgroupp called 'ping self' and add your friend to it.
- Then kick your friend out from this group
- Open web.whatsapp.com and now you can access your messages, files, photos across any device anywhere, anytime! (telegram also does this and allows file up to 1gb)
For the more limited use case of “get a link from a desktop to my phone right now” I have really enjoyed using an extension on the desktop browser that pops up a QR code linking to the current tab. Then I just point my phone camera at the QR code on the monitor to open the link on my phone. I like this setup because it doesn’t require any pre-configuration to link the desktop and the phone. Your friend sitting next to you can scan the QR code too.
I’m not linking to any specific QR code extension because I haven’t audited them for privacy but it’s easy to find one that claims to generate the QR code locally.
I've replaced Pushbullet with Telegram as I already use it for daily communication.
Telegram's built-in "Saved Messages" is where I share links, files, text snippets, photos, etc. for follow up and archiving; seamlessly between my devices and the Telegram desktop app.
Telegram also has an export feature, so I can backup all (thousands) of saved URLs, messages, media files, and so on for offline safe keeping; both in human and machine-readable formats.
Thanks for posting this publicly. I’m all for the general idea of reigning in unnecessary data collection/prioritizing user privacy, but sometimes you just need certain features to make things work!
Agreed. I really did see benefit to the changes I made that reduced our permissions requested based on the initial email we received from Google. When even that was rejected though, I kind of got slammed with a "well.... what do I do now?".
I am the proud recipient of many Apple rejection notices from the App Store (I have been releasing iOS apps since 2012). I have not had an app pulled, but I have had many rejections to submitted apps (the latest were received yesterday).
In all of the notices, Apple is usually quite explicit in what the problem is, including attaching screengrabs, and they will respond, if I ask them for further clarification.
I've seen cases where Apple will actually decompile/debug your app and point you the exact feature / method / line that they find unacceptable. Despite all of my other complaints about iOS ecosystem, they _do_ keep their App Store walled garden fairly well tended.
I should also mention another common rejection reason, so it's "out there."
Trademark use.
I have had apps rejected because I used a trademark (usually Apple's) in my app name or description.
For example, I had submitted an app called "Bluetooth 8-Ball for tvOS".
I was told that "tvOS" was not allowable. I had to use "TV".
This kind of thing has happened a few times. I casually use Apple trademarked terminology a lot, but I can't be as sanguine about it when I submit apps.
Full Disclosure: They also had a problem with the app being a "demonstrator" app. They don't want us releasing apps that they don't think we're "serious" about. They had a point, and I ended up withdrawing the app.
As someone who gripes about it: I think $99/year is a perfectly reasonable fee in order to submit to the App Store. I just don't think it should be the only way to run my own code on my own phone (without jumping through the rediculous hoop of reinstalling an app every single week).
You just answered yourself. It's not a the only way to run your own code on your own phone. AFAIK that restriction is to prevent jailbreakers from easily sideloading paid apps as "their" apps on their phones.
But it effectively is! There is no way for me to make anything useful for myself if I have to connect my phone to a computer and reinstall the app every seven days. If I forget, the app suddenly won't open. If I go on vacation without a computer, the app won't open. The seven day thing is useful for testing, and nothing more.
If the goal is to prevent piracy, well, as with other forms of DRM I as a paying customer don't appreciate being treated like a thief. Dedicated pirates can and do just buy stolen enterprise certs on the black market anyway.
I suspect that it's all about "brand reinforcement."
Apple is (arguably) the world's most valuable brand. Those don't come in Cracker Jack boxes.
They don't want some knucklehead running around, showing some crapplet that makes the brand look bad, and they certainly don't want them installing said crapplet on their friends' phones, so there's a bunch of folks running around, making them look bad.
This makes that a lot less likely. If they restrict it to paid accounts, then they have an assumption that the people writing the apps are "serious" about developing decent software.
I suspect that a big part of them buying up TestFlight was because they didn't want a company out there, making it easy to install un-vetted crapplets into a wide range of devices (which the old TestFlight allowed).
I have some experience with this. I used to work for a world-renowned corporation that made photographic equipment. Their brand is right up there, with Apple.
They would go nuts about sample photos getting out of the company. It was really difficult to report bugs, or even share test results, because the sample photos couldn't make our cameras look bad.
There's a great deal of controversy about Apple's iron-fisted control issues, but I do understand. I'm not always happy about it, but you can't argue with the results.
Xcode is free, Interface Builder is free, all the documentation for everything is free. I'm trying to get into Windows development and don't use Apple devices, but I agree $99 a year for everything Apple gives developers is not expensive considering the value and the cost of these tools on similar platforms.
Someone from Apple got on the phone with me to explain a rejection. I was disappointed with the outcome but very surprised at how they were willing to talk about it and explain why.
I was able to get a couple of apps approved, but I have perfected my forelock-pulling and wheedling skills. I always deal with them very respectfully and deferentially.
Basically, I support Apple’s “walled garden.” It’s a pain to deal with, but it makes their App Store a lot more valuable.
There is a lot of loud, vocal, opposition to it, but the vast majority of regular (as in non-geek) people like it just fine.
I agree. While I wasn't happy with the outcome, I do respect it and would not do anything to actively work around it. Just pulled the feature and moved on with the app.
The fact that they took the time to explain and justify the rejection made all of the difference. I have been on the receiving end with Google and it's much more difficult to deal with.
I went through the same hell a year ago [0]. My extension [1] now has 60k users (covid added 10k users in 1 month) and I'm also afraid that any insignificant update would trigger this hell.
I'll contact PushBullet with a possible way forward (PB, if you're reading this -- contact me). Anyone else in this situation: my email is in my profile.
Any reason that Google doesn't give reasons and ways to comply?
I haven't ever had to deal with a Google person regarding Android development, but when I built stuff for Blackberry (miss that company), they always provided nice and detailed feedback. Blackberry famously let legal influence design, so I would be surprised if it was a cover your ass thing.
Huh? They turned off reviews because a worldwide pandemic eliminated their ability to maintain staff to moderate reviews. That's the opposite of "automating it".
Famously might be too broad and a bias from my own experience. I went to school in Ontario and knew a bunch of Blackberry interns and employees and people generally know a lot of absurd stories about RIM.
An intern who I went to school with told me about how legal once chose the colors for a dashboard he worked on as they did not want to seem to be copying some other company.
A co-op complained about them being in every meeting and constantly shooting stuff down.
The one written reference to it I know about was in a 2011 open letter.
Google has 70% market share. If Chrome is broken- innovation nd the internet is broken.
If we really want to fix this.
1. Use Survey Monkey to collect info from other developers having issues (which is like all of them).
2. Isolate instances of severe delays, inability to innovate, harm to business, negligence etc.
3. Send to DOJ and EU Antitrust
I’m surprised Google et al. haven’t been forced to make more contractual disclosures at the time of a user submitting an extension or app.
Absent blaring warnings like “you understand that if you build any type of business on this platform we reserve the right to destroy it at any time for any reason”, it’s pretty hard to see how users had any ability to understand the implicit and explicit contracts they were entering into.
This isn’t much different than “Nathan for You” style hiding of onerous terms deep in hilariously small fine print, and judges tend not to look fondly on such games.
I wonder why the cookies permission is requested. It's not needed to communicate with .pushbullet.com, as in that case the normal cookies which have been set by Pushbullet will be sent along in the extension's requests to .pushbullet.com. It is only needed to access 3rd party cookies.
If Douglas Adams were still around, he'd put "Get actual assistance from a human at Google" on the list of "Recreational Impossibilities" in the Hitchhiker's Guide, right after "Get the Brantisvogan Civil Service to acknowledge a change of address card".
Anyone at Google who is listening- this kind of behavior kills my desire to continue using your products dead. I need functionality, of the type PushBullet has provided for years, to do my work. The recent nerfing of ublock origin has already had me feeling iffy on things. Behavior like this is simply unacceptable. If you want people to use your services, you need to have some way to communicate. Period. "If you use our tools, we can kill your livelihood at any time for any reason and tough shit if you want a why" doesn't exactly inspire, you know?
ProtonMail has come a long way as a replacement for Gmail as well. Suuuper happy with them, they're really responsive to feature requests and support inquiries. I requested for an iOS feature to choose browsers so I could open all links from PM in Firefox. They had it implemented in a month or something... it a quick fix but that impressed me. hence me shilling here
They recently added ProtonCalendar too.
Switching email isn't nearly as friction-free as switching your browser. Not only do you have to change your email in every service you've registered for, you also need to convince your friends and other contacts to use the new email.
The most important change you can make for your email is to own your own domain. Once you own your own domain, changing providers is much easier since it is transparent to the people that email you.
Even if you decide to keep Gmail, you should switch your email to your own domain.
One worry about tying your identity to your own domain, is the security of your identity (aka your domain) hinges on the security of your registrar. If a bad actor can socially engineer their way into controlling your domain, your entire identity is compromised.
owning your domain and having control of a domain through a trusted registrar is better than relying on the worlds largest advertising company to manage your digital identity (email), which is offered as a free service, that's subject to a catch-all ToS.
An isolated fail in 2014 by one vendor, primarily due to poor support processes, is not a convincing argument to keep all digital identities in Google's possession.
There's also the risk of Google shutting down your account because you do something they don't like. This will lead to a similiar outcome and you won't have any recourse.
I think that GP's point is that "safe" is a tricky word to use when your data is in the custody of the world's largest non-governmental surveillance network with a a catch-all TOS.
But do you lose your domain if google bans your account?
The requirement is being able to switch email providers, especially google, when they lock your account. You don't secure your flow of email with a domain if that domain is managed by google, too.
So my statement was a total comedic effort not to be taken seriously, I'd never suggest anyone use a company on the basis of terrible customer support. That's what the semi-colon parentheses at the end was meant to signify.
To attempt to actually answer your question, I believe the nature of the governance around registrars would ensure you have recourse to transfer your domain in the case that Google be Google. It might not be slick. I don't know. But, it's unlikely they can override the overarching policies for such things and continue being a registrar.
I think the bigger question is how much work it is to update the DNS servers with your registrar and then change your DNS provider. If google locks you out of your email that you use to manage your domain you could be in trouble...
If you don't use your google account for anything but domain registration, what could they even possibly ban you for?
While I am aware that Google tends to have quite a few false positive account bans, it is one of the most extremely unlikely things to happen, if all you do with it is pay for your domain registration.
I generally trust the major cloud providers a bit more than the companies focused on acting as a domain registrar.
The domain registrars are generally a race to the bottom and focused on "add-on" sales as most people are shopping on price and that's going to reflect in the overall quality of the things that most people don't really notice like, y'know, security and validation.
You don't hear a lot of stories about Amazon/GCP/Azure handing over someone's entire account based on a couple digits of a credit card number and it would be a PR nightmare if they did (hell, look at the flak they catch just for the data that people leave public on their services that ends up released... imagine if they handed it to someone). An active account with 2FA/etc enabled and a secure recovery email is probably safe enough for most people.
Spend the extra couple bucks to register through one of those guys instead of JimbosDiscountDomains.
Or… use a smaller registrar which actually charges more in order to provide support which you can contact personally. Most (if not all) large registrars are indeed in a “race to the bottom”, but that does not mean that all registrars are.
(Disclaimer: I work at such a small registrar. No, I’m not going to tell you which one; we aren’t targeting the global market, anyway, only our local area.)
The main issue raised several comments up is portability. No provider locks you to only using their email offering/cloud offerings if you register their domain through them. Even if they did, transferring domains is trivial and well-supported everywhere.
As far as any other objections people usually raise around using hosted email and the like, a domain really has no comparable privacy implications in the real world (you're not handing Google or Microsoft a huge corpus on your life). It's also through their enterprise offerings where as long as your bill is paid they're generally not going to have some automated review suspend your account with no reason, and if they did they have actual support you can get in touch with.
This solves basically all of the problems with using an @gmail.com/@outlook.com/etc email address.
Google, Microsoft and AWS offer registrar services becuase it keeps you in their ecosystem for their higher margin products. THey generally offer competitive pricing for things like doamin registration and don't pull stunts like charging 2x as much for "privacy protection" or the even more dirty tricks like godaddy and other bottom feeders.
I recently trialed hosted email with AWS and while it is very basic it only costs 4/user/month - cheaper than my google apps service. I was also able to register a new domain at market rates and get dns automatically setup (I think?) on AWS as part of the service. Now because I tie my monthly AWS spend with my registrar I'm more confident I can get some customer service as well.
staying inside a vendor's ecosystem for very selective services can actually work out quite well, as long as the seller/customer incentives align and they are relatively commodity services.
I use Namecheap too, but they took forever to add 2FA (it was added a few months to a year ago, maybe?) and I don't have any faith they'll add FIDO2/U2F any time soon.
EDIT: Oh daaamn it looks like they did it! Huh, faith restored. jgc, CloudFlare should follow!
EDIT 2: I'm just full of failures today, CloudFlare supports U2F as well. This is great news all around.
I've been happy with Joker and AWS Route 53. I've used Joker for years and years; at the time they seemed sane both technically and as a business, and that's how it still feels. Route 53 is more recent, but it's been solid and reliable for me. And it's been very nice to control it declaratively with Terraform.
EasyDNS (https://easydns.com), based in Canada has been around for years, and has a good reputation for not blindly actioning DMCA requests (which can be important for some). :)
I agree that that would be catastrophic, but I’m not convinced that using custom DNS changes my risk factor. If someone took over <my name>@gmail.com, they could do as much damage as they could by taking over <my name>@<my domain>.
Yes, but there's still an increase in the attack surface - it's a lot harder to convince a registrar to turn over gmail.com than <my domain>, for most values of <my domain>. It's not a deal breaker, of course, but it's something to consider when looking at the risk factor.
> Even if you decide to keep Gmail, you should switch your email to your own domain.
Do you pay for Google Domains, or just have some other thing forwarding to gmail, and gmail configured to send with that as a 'from' address, which I think is possible? What's your advice?
You can just do forwarding. I’ve run my own mail service since the 80s, and when I need a google login to work with someone I just create it and forward my mail. When the project is over, just delete it. Easy-peasy.
Unless a client wants to use google docs I‘ve never found an account to add any value anyway. I don’t use google search much any more but when I do it works fine without cookies.
And I try chrome occasionally (it’s needed to use google docs) but it uses too many resources to use as any kind of default. It’s also harder to enforce privacy with it.
Oh, ok. In my case some of my servers are over 20 years old, though I run less critical services on them. My newest machines is about 4 months old. My buddy in the rack next to me is a few servers from the same batch as my 20 year old ones. Obviously the most critical stuff runs on the newest hardware but when you’ve had a machine running uninterrupted for a decade or so why mess with it? Annualized cap ex + the op ex is negligible at this point.
As personal servers of course “critical“ is pretty idiosyncratic, though I have used them to start and host various companies overnthe years until it was worth giving them their “own” hardware and identity.
I admit the age of managing a rack full of servers in a colo has largely passed.
There is always a risk of loosing an asset, that includes hijacking. However to reduce forgeting of renewal there is the recipe I have once read here on HN:
Renew your doman for 10 years now, and then every next year do 1 year renewal. If you forget it then you still have 9 years of buffer.
If your domain name provider is serious, almost none: there's a transition period (a few weeks) between the expiration date of your domain and when somebody else can buy it again. So if you forget to renew it, your emails stop working and you'll renew it really quickly ;).
Source: it happened to me last month (the provider being OVH).
Most registrars are going to send you multiple emails leading up to the expiration, when it expires, and after it expires reminding you it expired. You'd have to miss a lot of emails.
And once it has expired, you have (depending on the TLD) over a month of grace period where it's not available for general registration where you can still renew it. You'd have to miss the fact that all of your services were offline for over a month.
I only work with a company who’s team I can actually call. i pay a bit more, but that direct access is great.
It’s actually hard to lose a domain if you have a good registrar. There is 90 day quarantine period even if you cross the renewal treshold. You can also domain lock, which means you need to manually unlock a domain before moving.
That's we something like PayPal is nice, your cards can expire and be replaced without interruption to automatic payments.
And like the email problem, you don't have to go around changing it every couple of years.
I feel your pain.. I accidentally let my main blog domain go a long while ago when I decided to drop most of the domains I was holding.
Beyond this, I've had a few pretty good ones over the years... right now, I've got about 30 of them, and just keep thinking I should let most of them go.
I recall seeing this recently on another HN post, where they had set up a blanket forwarding rule from their Gmail to another email account. Their Gmail later got dinged but the forwarding rule continued to work.
Have to respectfully disagree here...we tried protonmail for ages and it wasn't good. Wet feature adding it sounds like you got lucky but we ask for several features over the course of a year - ranging from simple things such as HTML signatures (that they fully support, they just hide the button on their editor) to more enterprisey user management 2fa enforcement style features and it just didn't hold up in the slightest. No features got added and we ended up going back to o365..for a personal email it's ok though but I wouldn't tout them as responsive to feature requests as this wasn't our experience at all. We were a sma the on their visionary package if that makes a difference.
You don't have to switch overnight, i simply forwarded all my incoming Gmail e-mails to my new account, and then reply to all my Friends (etc.) from my NEW e-mail address. That way they will all, eventually, automagically update me in their address book. It worked very well :)
ProtonMail user for years too. And non-tech people who get my e-mail immediately like (and ask about) the protonmail.com domain, which opens up an avenue to discuss privacy and the upside of non-Google products.
I'm a paying customer (paid for 2 years upfront), and I only found out after paying that ProtonMail has an incredibly poor implementation of 2FA. All it supports is app-based authentication[1].
No support for U2F (FIDO) keys[2].
No support for sending SMS to phones.
In comparison, my Google account is protected with: (a) three distinct U2F FIDO keys that are stored safely in different countries, (b) three separate phones for SMS authentication (my phone, dad's pone, mom's phone), (c) lastly there's the authenticator app which I rarely use. This is so much more versatile and reassuring that ProtonMail's extremely-mininal 2FA implementation.
Also, ProtonMail has no excuse for not supporting SMS-based 2FA. They can send a SMS to your phone, when you setup a new account -- but for some reason can't do this for 2FA. Despite being a paid service, they trying to save on the SMS charges that SMS-based 2FA would incur?
Not sure about the other stuff, but SMS 2FA is generally frowned upon for auth.. though obviously they've decided it's fine for the one time setup just as a verification on signup (not used as 2fa in that case, more like crude proof of identity). U2F has been a challenge for everyone from what I've seen.
I think most people are never going to choose ProtonMail, but it can be good for people who like simplicity and consistency. I don't need a million bajillion options, "plugins" or "apps" for my web mail. Just show me my emails, let me load attachments, and I'm good. That's why I pay for ProtonMail instead of Gmail. Well, that and all the other reasons to distrust Google.
Is there a provider that lets you send emails from free format users on your domain? With catch all addresses the mail goes into my other@domain account. I use a different email address per site. Now with gmail if I want to reply with that account I first need to create it as an alias. If I want to reply from my phone it even needs to be a full account. Is there any way to fix this? Short of using mutt and write the from header myself?
I can do this with fastmail, though fastmail is a subscription (like $5/month? IIRC, mine auto renews every 2 years so not sure). I have my primary email setup as <firstname>@<lastname>.org. If you set your dns records correctly with them, that allows you to use without any ahead of time setup <randomtag>@<firstname>.<lastname>.org. Setting a different tag where I have <firstname> is can be done too, but you need to set those up individually.
replying to emails, I can change <randomtag> to whatever I want.
They also offer random domains that you can setup burners under, though that does involve some ahead of time setup.
Fastmail lets you create wildcard identities like this so you can send from any username at any domain you have with them, but if you are sending from a third party app you usually still need to set up the sending identity in the app itself, which is annoying. The email programs I've tried haven't let me type arbitrary addresses into the 'from' line.
Many programs won't even automatically reply from the same alias the message was received at.
I used protonmail for a week, but i got tired of waiting hours and days for some emails to arrive. some we so late the verification links were no longer active. ugh, if only proton mail was up to par with Gmail.
I transitioned to FFox myself. I occasionally have to use Chrome for work, and it's nothing I find myself missing. If Chrome is messing up your day, it's really easy to cut it out.
I've found the exact opposite to be true in my very specific experience. Five years ago I used every Google product under the sun, today the only Google product I use at all (even search) is Chrome because it's the only one I haven't been able to replace.
I try Firefox with a fresh install on nearly every major release and I keep it installed as a secondary browser, but I can never manage to use it as my daily browser. For whatever reason, none of my company's (major tech company but not a competitor to Mozilla in any way) internal web pages load in Firefox. No error, no warning, nothing in the console, just zero content. Blank page. I've tried it on two computers with the same result and just nothing. No extensions installed, nothing I've installed on my network or computer to block anything. It just doesn't load anything.
On the other hand I keep Firefox installed because Chrome refuses to load my dev environment with a self-signed certificate. Firefox will let me click "I accept the risk" but Chrome just refuses to load with a self-signed cert.
I'd love to use just one (preferably Firefox) but I guess the web is still hard to get right.
I was doing that but it does break things so you need to remember you're doing it. For weeks I wondered why Slack wouldn't work via my browser until I found it was loading some Javascript only when UA was set to Chrome, and that was breaking something.
IIRC, the intent is that no one should be doing this and anyone doing it should be at least technical enough to figure out what they're doing and be reminded that it's a bad idea.
On the other hand these stupid dialog tricks are why I stopped using Chrome. I'm not an idiot and I know what I'm doing. It's pretty arrogant to assume that I shouldn't be visiting my router's configuration page just because it uses a self-signed certificate. I don't care to set up an X.509 infrastructure at my house, thank you. Please stop mollycoddling me.
Firefox continues to do a good job of just letting me visit the damn website after warning me.
I'm confused - Firefox and Chrome act completely identically to a self signed cert for me. Both let me click through after looking at the cert or expanding a section. I have never been "blocked" by some hidden modal unless the site chooses to be HSTS-enforcing, and in that case Firefox does not allow a clickthrough either.
You’re right to be confused because I’ve never seen a rhyme or reason to it either. I generated a cert using OpenSSL’s command line tools and told Django’s manage.py to use my self-generated cert and it works in Firefox but not Chrome.
It did work in Chrome. And then after an update it didn’t work anymore. I don’t know why and it seems like no one else here does either.
Your router's self-signed cert can be imported into your browser and trusted from thereon — that will also stop any potential attacks from someone pretending to be your wifi ap nearby because I am pretty sure you are not double-checking the cert fingerprint every time you visit the router's admin interface. Provided you were not MITMed once you added the cert in the first place :)
And instead many people will just do a Google search for "Chrome [insert error here]" and run the first command they find, while people like me will say "okay I'll just Firefox where I can click past this warning".
For what it's worth I've always been able to click straight through a self-signed cert on Chrome - in fact I just did it right now to log in to something internal. I am a nearly 50-50 split Firefox/Chrome user.
Are you sure you aren't sending HSTS headers that demand the site be TLS in some way?
Also, have you considered the slightly-saner way of doing it, which is making an internal self-signed CA, trusting that internal CA, and then having it sign the rest of your "self dev stuff" certs?
Yeah, I actually think these sorts of strategies are clever. They're a way to protect normal users without outright barring power users from doing as they wish.
macOS operates in a similar way. I really like how the difficulty increases depending on the task:
• Want to allow one app through Gatekeeper? Instead of double-clicking the app icon directly, right click it and select "open".
• Want to turn off Gatekeeper for all apps? You need to open the Terminal and execute a command.
• Want to turn off System Integrity Protection? You need to reboot your computer into recovery mode and execute a Terminal command there.
Except for those of us who are finding out about it only via a Hacker News comment. As happened with this user, who seems, you know, sufficiently a power user to need that info. Even a "if you know this site to be safe, please read this knowledge base article (link)" and buried in that, amidst all the reasons you shouldn't use untrusted certs, are the instructions.
> Even a "if you know this site to be safe, please read this knowledge base article (link)" and buried in that, amidst all the reasons you shouldn't use untrusted certs, are the instructions.
I don't think that's a bad way to go about it either, if it's sufficiently buried.
I'm primarily just thankful there's a workaround, hidden or not, given how many tech companies seem to respond to these things by disallowing them completely.
You're kidding right? You look at every commit of every open source app you use, or that a closed source app is built atop? For me, off the top of my head, that would mean, yes, Chrome, Firefox, the Linux Kernel, Libre Office, Android, VLC...probably plenty more that I am unaware are open source, and that's not even considering the dev tools to do my job. When would I actually have time to have a life?
Exactly. Reading the source of every program you used was certainly possible back in the 80's when the FOSS movement started; but nowadays, with every program being millions of lines of code, it's implausible to get through all that and still have time to actually use the software.
If you're on OSX/macOS (what a silly rebrand) then if you look in ~/Library/LaunchAgents (and possibly /Library/LaunchAgents and /Library/LaunchDaemons) for any .plist from Google (or Keystone) in there and add
<key>Disabled</key><true/>
under the first <dict> and then unload each file, e.g.
Assuming you are on a Windows domain, since they are able to control your Chrome. Chrome uses all the built in Windows settings. Have you check for proxy settings in internet options? Firefox I believe still uses standalone settings, and will need to be configured manually.
Other thing they could be doing is adding certificates to the Windows certificate store, that Firefox does not trust. Though I expect you would see an error about invalid certs in that case.
Sure, and I use it daily. But my frustration isn't about me particularly, it's about Google's increasingly hostile behavior. They're the 800-pound gorilla of the internet, and the way they behave affects all of us.
I second the Fastmail vote. I have been a happy user for... maybe 3 years now? A while at least. The web UI on mobile and desktop is second-to-none (I love not having an app) and the spam filtering is as good or better than gmail and the other big players.
Because when it first was released, they were one of (if not the only) (free) email providers to give every user over a gigabyte of storage. At the time, most email providers only allowed mailboxes in the dozens of megabytes range.
Nowadays, everywhere gives you plenty of space, but for me personally, it’s just been the fact that I’ve been using it for so long and switching is a hassle. I’m sure it’s the same for a lot of other people, and for the majority, they probably also don’t care enough.
Pretty sure Hotmail (which at the time was like 20% of all web traffic) was still offering a whopping 2MB of space when Gmail launched. It was only after Gmail came out that they started bumping the quota from where it had been since the mid-90s.
Gmail was a HUGE deal. People were going nuts over the invites.
I have fastmail bookmarked waiting for me to find some time to switch over my gsuite admin and some cname redirects off of Google's platform. It's definitely past time for me to get a little less dependent on them.
I am not sure why would one trust something as important as email to any company. Register and use your own domain. Then you are totally free in your choice and switching is no problem
I switched from Pushbullet to Join and one of the hurdle the dev is having is that something regarding push messaging was severely lacking in Firefox compared to Chrome, hence the lack of an extension for it on Firefox.
The only Google product I still use is Android. I won't switch to iOS, that's like cutting off your nose to spite your face. Sadly, the FOSS alternatives do not support Blackberry phones, and for physical reasons I _greatly_ prefer a real keyboard.
I switched when Google killed of ublock origin in Chrome. Firefox is quite nice these days. I just use chrome for development because I'm more familiar with their dev tools.
I will very occasionally find a site that's broken in Firefox and works in Chrome though.
> Firefox's new DNS over HTTPS was bypassing all my firewall DNS rules.
A misstep by Firefox, though it was done with genuine intent to safeguard users (as opposed to just being spun that way).
Though they've walked it back it still needs to be opt-in or be trivially easy for average users to opt-out.
Hard to quantify, but neither Firefox nor Chrome were compromised at Pwn2Own this year. The sandbox architectures are very similar now. Chrome's still ahead in having a slightly tighter sandbox and already shipping process-per-site, while Mozilla is working hard to catch up on those. Firefox gets a slight advantage from using Rust in some places instead of C++. I'd say Firefox security is still behind Chrome but in practice not by "a lot".
Yup, exactly the same. That's what I use. The only thing Chrome was better in the past was audio pitch correction in sped up videos. Firefox recently fixed that so now for me there is absolutely no need to use Chrome anymore.
Thanks for the link. So it's a subset of kdeconnect/gsconnect for Linux/Android [1] [2] [3]. I'm using it to share files and tabs from my phones / tablets to my pc and viceversa. It does many other things including sms from the pc. It works with any browser or with no browser at all. There is no need for an extension.
I'm sure Apple has had that too for a long time and I saw something like that from Microsoft a few days ago.
I have temporary containers extension plus an extension to manage google and Facebook containers and the whole thing has become such a pleasurable experience. Combined with pihole it feels like I’m reclaiming the web back again. Such a blissful experience.
Yep, for me Multi-Account Containers and Tree Style Tabs are both killer features. Being able to load the same page with multiple accounts within the same browser and without losing everything after each session is a game changer for all sorts of situations, as is being able to keep dozens or even hundreds of tabs open without squeezing and squishing them unreadably into the top of the window like some kind of maniac.
And with temporary containers isolation pages that don't have their own dedicated containers get all their history deleted after they close (by default a few minutes later, so undo close tab works), just as if you'd opened each new tab in an incognito window.
Mozilla is becoming more and more Google Like as time progresses, where a few years ago I would have believed it would be unthinkable for Mozilla do so something like this to an extension, today I am not so sure I would trust them either
Can you give a few examples of how Mozilla/Firefox have changed?
We all know about FF Quantum. Yeah it sucks what happened. Maybe there was an alternative, but any one saying Firefox should’ve just stuck to not being compatible with Chromium extensions is kidding themselves on how badly that would’ve continued hurting Firefox’s market share. The XUL powered extension I’m sure were powerful so the outcry in certain places was huge. Vocal minority.
The Pocket integration got lots of outcry which seemed pretty silly to me. It’s one product they own. Mozilla doesn’t have a ton of products. Yes that is Google like. Much like any synergy or integrating is Google like. Which is really just being a modern internet corporation. If this is one of the reasons. Why would Mozilla of 5 years ago not have done that vs the Mozilla of today and whenever they did do it. 1-2 years ago I think?
FWIW, killing XUL extensions wasn't even really about Chromium compatibility. The changes in the Quantum rearchitecting were going to break everything anyway; the decision was made to move everything onto an add-on system which wouldn't just break again and again with every architectural change (which, yes, did have the benefit of Chromium compatibility).
Quantum wasn't even about Chrome compatibility. The XUL extension mechanism was permanent technical debt loaded onto the browser because of how it exposed features, basically welding things directly onto the browser's guts, which on the one hand is super-convenient for making radical changes in an extension and on the other hand is a nightmare to maintain.
The analogy I've used is the Amiga operating system design versus Unix when it comes to multi-core / multi-processor versus multiprocessing. Amiga welds everything to the hardware, the Unix design has a "system call" mechanism cleanly separating your programs from the OS and vice versa.
Because Unix has this relatively thick layer between the OS kernel and the rest of the world, you can just pick up your entire kernel, wrap it in a lock (in Linux this was called the Big Kernel Lock in some BSDs it was Giant Lock and other Unix systems gave it different names) and you've got a multi-processor capable system. Linux did this in about a year IIRC. For purely CPU bound software this minimal work gets you 99.9% of the performance of a custom built OS designed from the outset for multiple processors. Subsequent work to get rid of the BKL further improves performance on more sophisticated workloads, but you're off to a great start.
Amiga couldn't do that, every part of their system could interact with every other part as it liked, so if you tried to just add one lock to protect things the resulting system might randomly deadlock, maybe only on systems with specific hardware or software combinations, and you basically needed to reconsider everything from the ground up.
You need a degree of abstraction like this, the Chromium-style web extensions have it, the XUL extensions didn't, adding it to the latter would have been years of work only to deliberately be incompatible with both existing software on Firefox AND everybody else, madness.
There are definitely things we want in extensions. For example Firefox has a copy of the Public Suffix List baked inside it (all browsers should have this, in its absence you'll get weird security behaviour around how domains and sub-domains work) and I'd like to access their copy from inside an extension to make it behave how users expect. But obviously the extension can just ship its own copy of the PSL, and then keep that up-to-date it's just a waste of resources.
> The XUL extension mechanism was permanent technical debt loaded onto the browser because of how it exposed features, basically welding things directly onto the browser's guts, which is a nightmare to maintain.
There is no evidence for this at all. Extensions can't modify the rendering engine.
"guts" meant the XUL implementing the Firefox UI. tialaramex is absolutely right about that, extensions had total access to that XUL/JS state, which is why changes to the Firefox UI inevitably broke extensions.
DNS-over-HTTPS was the big one for me. Mozilla betrayed us here. They've pushed something browsers shouldn't do into the browser, and in my case, started to roll it out to my browsers despite my network device being set to block it.
They actually managed to implement a policy that respects user choice and freedom less than Chrome, which only implements DoH if your set DNS provider supports it.
> DNS-over-HTTPS was the big one for me. Mozilla betrayed us here.
Betrayal indicates some intent to harm users; the intent of DoH is clearly to safeguard users. However, the rollout was absolutely hamfisted & shortsided.
It's notable that the DoH deployment is about the only example here of Firefox harming users. Compare that with Google rewriting Chrome's code to hobble uBlock Origin & leave users more vulnerable to nefarious ad tech.
The former was Mozilla putting user safety first (in a poorly handled way) while the latter was clearly Google doing the opposite.
Don't get me wrong, I would always choose Firefox over Chrome, but I lament the lack of a major option that seems to not follow Google's plans and generally assume they know better than the user how to use the web.
I don't think the Pocket was owned by Mozilla when they announced their integration. Looking it up, it looks like they bought it 2 years after the initial announcement so I can see it being controversial.
> The Pocket integration got lots of outcry which seemed pretty silly to me. It’s one product they own. Mozilla doesn’t have a ton of products.
I switched to Firefox after the Pocket thing happened, so I didn't follow the "outcry" and can't say if the tenor was justified.
However, as a new Firefox user not familiar with the history, the pocket integration just felt "icky", particularly in combination with the new tab page. Regardless of Mozilla's intentions, it seemed like another instance of Software A trying to push me toward unwanted unrelated Service B, as so many modern tech products are wont to do. Mozilla should be a sanctuary from that crap.
Luckily, I found out about the about:config flag to disable Pocket, and I've been happily ignoring it ever since. I just think it's an unfortunate experience for new users. Hopefully I'm wrong and Mozilla is right about what most new users want.
Being in a country that was the last holdout for Firefox (majority usage) before it was also taken over by Chrome, I know that several others as well as I have issues with Mozilla. Personally, I've always used Firefox, without exception, and stayed with XUL, rather than switch to their new browser, as add-ons are the most important part of a browser for me. I don't care if one is half a second faster or not.
Not to mention that stuff like stupid redesigns of logos as well as the Pocket issue made me basically lose all trust in Mozilla. Privacy is a huge deal here after all. Those who switched regularly complain about design issues (apparently the desktop browser is becoming somewhat "mobile-like") and most recently the address bar problem which upset everyone except for one person who didn't care about that. (Meanwhile, I'm happy with my address bar being my address bar and my search bar (being just right of it) being my search bar.[1]) If you would ask the people still using Firefox here whether they would recommend it...they would most likely say "no" but then would go on that while it isn't good, the alternatives aren't either.
So the question of change in direction (which is obviously there) regarding Firefox begs the question which people they are actually targeting? It's certainly not your average Joe because Firefox will never be able to out-Google Google. They are also annoying the more advanced users who just want privacy as well as useful things (add-ons, proper baked-in features etc) with their shenanigans, so it can't be them either. The only people I see actually celebrating new releases all the time (regardless of negative changes) are the crowd on HN. So, to me, it seems like they are targeting some kind of tech bubble (no offense) while basically ignoring the users out there. This is, of course, also reflected in them continuously losing marketshare while all the back-patting is happening.
Mozilla has to target the mass market or they won't survive. They certainly have to target people who, unlike you, care about performance more than anything else, since that's most of the market. You can argue it's hopeless but you can't expect them just to give up, nor should they.
I'm not the previous commenter, but on Android Mozilla is removing the ability to install extensions from third parties (think GitHub, etc.) and will trim the only left official extension store down to a few extensions. (I think it's below 20 right now.)
An ecosystem where all extensions need to be channelled through one central power broker is pretty much the main requirement to allow them to do what Google is doing in the linked Pushbullet case.
edit: this is all factual, sadly downvotes won't change it.
They've rebuilt their browser from scratch and are re-adding the APIs. It makes total sense to prioritize the most frequently used ones now and expand to the other ones later on.
For me personally, Privacy Badger and uBlock Origin are already there. I don't think I need a third one at all.
This is temporary while the Android team builds out and stabilizes the add-on APIs supported in the new Firefox for Android. Otherwise it'd be a total crapshoot whether an add-on you tried to install worked or broke randomly (potentially in gnarly ways).
If locking down on the extension ecosystem were only temporary they could just defer the nearing downgrade of their main line browser until their replacement is fully functional.
But that's not what they do. Instead we do have a clear announcement on a feature removal and a vague hint that they might add it again in the future.
It's absolutely not sure that disabling non-store extensions is only a temporary defect.
If you have evidence that suggests otherwise, feel free to add it.
It does not help that their marketing language feels designed to consistently avoid any meaning whatsoever.
> If locking down on the extension ecosystem were only temporary they could just defer the nearing downgrade of their main line browser until their replacement is fully functional.
The update is going ahead because the new Firefox for Android is such a dramatic improvement along all other axes, and because, from a development perspective, the incarnation it's replacing is saddled with legacy and technical debt. It never received most of the benefits from Quantum, for example.
> The update is going ahead because Firefox Preview is such a dramatic improvement along all other axes.
...and even the extension axis, from a power-aware Mozilla position. That's what makes it suspicious in the first place.
A few years ago they had a bug that added seconds to every page load that they didn't fix for half a year, but once an update coincidentally consolidates power at Mozilla it needs to be pushed for all its supposed benefits and despite all its known drawbacks asap.
We wouldn't buy that if it were Google or Microsoft and we shouldn't buy it in Mozillas case either. ... If they even announced that they plan to reopen the extension system, which they (to my knowledge) did not.
Personally I don't notice any grave difference between Firefox and preview. Apparently scrolling should be different, but my mid-range phone scrolls just fine in both apps.
> For a long time, it was just setting the default search provider to Google in exchange for a beefy stipend. Later, paid links in your new tab page were added. Then, a proprietary service, Pocket, was bundled into the browser - not as an addon, but a hardcoded feature. In the past few days, we’ve discovered an advertisement in the form of browser extension was sideloaded into user browsers. Whoever is leading these decisions at Mozilla needs to be stopped.
> Here’s a breakdown of what happened a few days ago. Mozilla and NBC Universal did a “collaboration” (read: promotion) for the TV show Mr. Robot. It involved sideloading a sketchy browser extension which will invert text that matches a list of Mr. Robot-related keywords like “fsociety”, “robot”, “undo”, and “fuck”, and does a number of other things like adding an HTTP header to certain sites you visit.
> Mozilla’s motto is “internet for people, not profit,” however the realities of having to fund all of its ventures are forcing the company into adopting one of the web’s less human-friendly aspects: sponsored content. Having acquired read-it-later service Pocket last year, Mozilla has been populating new tabs in Firefox with Pocket reading suggestions — and those are now going to include links that an advertiser has paid for.
I agree to some extent, e.g. the pocket integration and Mozilla burning cash on things that aren't related to Firefox, but Chrome's decision to limit/break key adblocking APIs across their whole ecosystem is much worse. I'd be willing to ignore almost any number of removed extensions to continue using a browser that's not owned by a glorified adtech company.
Browser extensions are going to be turned into a web standard, and W3C is controlled by Google, so Firefox will probably lose its adblocking API: http://browserext.github.io/
Doesn't Mozilla get nearly all its money from Google; I've assumed that actions by Mozilla have been coloured by not wanting to ditch its multi-hundred-million dollar benefactor.
Google has apparently paid Mitchell Baker personally multiple millions of dollars too.
Seems Google know how to manage their risks.
Mozilla seem perhaps even more beholden to ad revenue than Google.
I know that Mozilla has historically been paid by Google to make Google search the default search provider in Firefox. But you just claimed "Google has apparently paid Mitchell Baker personally multiple millions of dollars too" which is something different that I have heard nothing about. So, what is that claim about?
Who do you trust? Certainly not Chromium-Edge. That leaves "only browse the internet on a Mac with Safari" or browsers with such tiny market share that they'll never be tested against, and sites will routinely be broken for you. My company doesn't do any non-Chrome compatibility testing, so all our intranet sites require Chrome.
Why not? Chromium (= Blink, plus some other stuff like a network request stack) development happens in the open, just like WebKit development. It might be steered by Google to such an extent that there's always the possibility of it going in a bad direction; but it's not like you're not going to hear about it if something privacy-violating is introduced into the Chromium codebase (rather than the downstream Chrome codebase.) And you can switch away from the browsers that use it if/when that happens.
For that matter, if upstream Chromium ever did start "going bad", those browsers that rely upon it would also likely switch away from it, either cooperatively forking it into a new community-maintained project, or switching over to WebKit (with which it is still mostly ABI-compatible.)
> browsers with such tiny market share that they'll never be tested against, and sites will routinely be broken for you
Even if you don't want to use anything based on Blink, WebKit is also a large ecosytem, and minor WebKit-based browsers can "inherit compatibility" from developers targeting (mostly Mobile) Safari. Several Linux browsers (GNOME Web, Falkon, Midori) use WebKit, for example. They render everything just fine (i.e. just like Safari does.)
> The browser also sends unique hardware identifiers to Microsoft, which is a "strong and enduring identifier" that cannot be easily changed or deleted.
Oh, ah; I thought the above meant "why not Chromium and/or Edge" rather than "why not the Chromium version of Edge."
Yes, I can see why you'd avoid Edge specifically, same as avoiding Chrome specifically.
But that's not an argument against using upstream Chromium (which is, in fact, a browser all on its own, stadnalone downloadable and shipping with several Linux distros); or against other Blink/Chromium-based browsers (e.g. Brave), no? Either choice would get you compatibility with anything Chrome itself is compatible with (in terms of websites; not necessarily in terms of extensions—though the difference is just in the legacy Chrome extension APIs; WebExtensions work fine everywhere.)
> The recent nerfing of ublock origin has already had me feeling iffy on things.
What did they do to ublock origin? The single best Chrome extension ever. If it stops working and I must suffer YouTube ads again, it's bye bye Chrome.
They're going down the Safari line of limiting the number of rules an extension can use, significantly reducing the efficiency of adblockers.
If it goes as planned, you won't see ads on YouTube for sure, but there likely won't be enough space to add rules for less mainstream ad networks and some of the specific sites you visit.
It's a lot more than just limiting the count; expanding the count would not offer equivalent functionality. Basically they're hobbling adblockers' ability to compete in the arms race, which makes sense as Google is an advertising company.
If Youtube ads mean that much to you, why not just pay for it? I'm all for ad blocking (I use ublock too) but if I heavily use a site that offers me a way to pay a reasonable price, I think it's the right thing to do. Uploaders with monetized videos still get paid that way (and I don't want to bother with Patreon etc, that doesn't nearly scale to everyone I watch videos from).
Eventually there's a whole deal of stuff you end up paying for, a few bucks at a time. I draw the line somewhere. Ads are one such line. I won't watch them anyway, so their only purpose is to annoy me -- and I tend to swat away annoying things.
Never let anyone make you feel bad for blocking ads. It's the right thing to do.
It would be interesting to hear Google's actual reasoning but I don't expect that we will. I will speculate that it is exactly the clipboard permissions as there have been apocryphal reports of Android apps and web extensions that use this to steal passwords that password managers put there for users to "paste" into their pages.
If that is the case, then a much better solution would be for Chrome to implement a secure channel for password managers to use for just that purpose and make access really really explicit. But again, without them saying anything we won't know.
My advice is to watch for a CVE regarding sniffing sensitive data off the clipboard to surface in the next 30 - 90 days.
I've been using PushBullet for years. Great product! It's not fair what big companies are doing to what it seems to be, prioritizing their own features over third party well-built products. It's abusive.
Chrome's Extension v3 API will remove the ability for uBlock Origin to filter web requests in code, instead the application will have to submit a list of URLs to filter to an internal API and this list has a maximum size and limits the flexibility of the URL filtering.
This is ironic, because uBlock implements an extremely efficient filter and is even looking into using WASM to speed it up even more. Google's public position is that implementing functionality in JS or WASM is unacceptably slow. They say "[Preventing or weakening ad blockers] is absolutely not the goal. In fact, this change is meant to give developers a way to create safer and more performant ad blockers."[1]
Google's public position is also that WASM is "consistently fast"[2], fast enough to rewrite Google Earth to target it[3], and "It's entirely feasible to build a complex code-base to run performantly in the browser using WebAssembly"[4].
So which is it? Is the Web Request API being deprecated because it's not possible to write performant code in extensions using Chrome's powerful JS and WASM engine, or is it possible but there might be some other, different reason that they're blocking it?
These days Google's core value appears to be a Kafkaesque hypocrisy.
They promote efficient websites to increase ranking with their search algorithm, while operating ad services that bog websites down. Not to mention the whole AMP business where they looked at Facebook and developed a severe case of walled garden envy after previously being a champion of open web standards.
> They promote efficient websites to increase ranking with their search algorithm, while operating ad services that bog websites down
The online-advertising economy that Google operates in does slow-down websites.
Google's own ads, don't. AdSense ads are loaded asynchronously and I've been happy to run them on my websites. Google Analytics is also fast and light.
It's other scripts that bog things down - right now on my most AdSense-laden webpage the real killer is ZenDesk's chat widget - even when loaded asynchronously it still blocks the page render and pulls in over 600KB of resources, which is ridiculous: https://support.zendesk.com/hc/en-us/community/posts/3600042...
> Not to mention the whole AMP business where they looked at Facebook and developed a severe case of walled garden envy after previously being a champion of open web standards.
I'm not a fan of AMP either, but you don't have to use Google's AMP cache CDN to use AMP - it may surprise you (as it surprised me!) to learn [that Google endorses Bing's AMP cache](https://amp.dev/documentation/guides-and-tutorials/learn/amp...), for example (Google owns and runs amp.dev) - but I won't be happy with AMP until it's possible for people to run their own AMP CDN/caches.
That said, I fully understand why original-content providers aren't keen to adopt AMP: because it restricts the kinds of advertising displayed in a page and restricts monetization, and means you have to trust your CDN to accurately report pageviews.
uBlock Origin is not available for Safari in its original form. It only exists as a (somewhat neutered) fork that's basically dead[0].
There's a disconnect in the sense that a lot of people think that adblocking in Safari is fine, even though it is pretty objectively less capable than Firefox/Chrome in this area right now. There's no disconnect in saying that Manifest v3 is going to hurt adblockers, because the same changes in Safari also hurt adblockers, and (as of last time I checked) Chrome's proposed changes go even farther than Safari's did.
But in general, yes, you should already be avoiding Safari today if you want to use the best adblockers on the market. Safari suffers from the exact same problems, that's why I use Firefox even when I'm on a Mac -- because the adblockers and security extensions for Firefox are just a lot better.
It's not about just me. I use a half-dozen different browsers during my work day. It's how the provider of the world's dominant browser is behaving, with ramifications that affect all of us.
They blocked ublock origin?! Really?! What was their stated rationale (I assume they didn’t admit it is because they want people not to block ads)? Might I suggest using Firefox? I use it and don’t have any trouble with it.
I switched to Firefox because of Google banning Bypass Paywalls extension that is available as a Firefox add-on. When I was building my bootstraped company, Google really taunted us with emails like this, when our AdSense monthly earnings reached $10,000 and we're my only source of income. We had 20 million user profile pages, and they were saying that something is wrong with some of them, without saying what, forcing us to "review" them all. We built sophisticated ML content filters, to receive more unspecified warnings and get the account shut down. I managed to reinstate the account, but it left a very evil taste. I am in the process of degoogling, using Bing as the default in Firefox.
I whole-heartedly agree and this is why I give money to AWS and Azure will not give any to GCP until the lack of transparency and random product killings stop.
If you haven't switched to Firefox, you should! There were a few things I didn't like at first, but after searching StackOverflow and blog posts for how to change the settings, I am now fairly happy!
(old dude here) I knew this attitude was coming when i saw the billboards recruiting PhD's back in 2008 (or so). I figured they'd be completely infected by arrogant (but clever) twats around 2015. i believe my guess proved to be true and it's been getting worse ever since. also, the fact that their (organic) search is so awesome also-also that they were allowed to buy Waze, ffs, get out of my life!.
"If you use our tools, we can kill your livelihood at any time for any reason and tough shit if you want a why"
It has always been thus with proprietary tools and platforms.
Back in 2011 I switched careers from developing software on proprietary stacks - at the time C# 4.0, Silverlight, and MS Windows - to developing on open source stacks, starting with Ruby on Rails and JavaScript.
A short time after I switched away from Silverlight, I found a bug in the open source XML library my team was using. I then submitted a PR to fix it, which was merged (with some revision :)) after a few days. The experience was a revelation after the combination of magic 8 ball and years-long wait times for non-critical bug fixes on Visual Studio.
It looks like the younger generation is busy rediscovering the vulnerability and helplessness of proprietary systems themselves.
Building a business off someone else’s platform is easier because it provides a built-in distribution channel.
However, when you don’t own your distribution, it means your business can be shut down by the decision of one person at X company.
It turns out, all decisions have trade-offs.
If you want to have a real business, don’t do the above, or only do the above while getting started.
Developers hate having to deal with distribution. Platforms exploit this by creating these fantasy worlds where developers don’t have to think about it.
This is a mirage. You have not created an “easier” business. You’ve simply sold your soul to the devil.
The fact that this team realized so simply that they shouldn't be reading data on every site the user visits while the extension is installed is deserving of a vague response from google. Sad really.
I wonder if they got caught up in google removing "creepware" recently and notification mirroring might count. "CreepRank algorithm can identify apps with features that can be abused to extract SMS messages from a device, spoof another user's identity in IM/SMS chats."
As much as we can criticise Google's handling of this situation, the fact that the developer was able to reduce permissions from accessing data on _all websites_ down to _their website_, as well as tighten up a few other permissions, shows that Google is correct that the extension is asking for more than it needs.
I hope the developer finds another load of permissions they can tighten up, resubmits, and is approved. As long as it results in permissions being more correct this is a very positive thing for users because for every PushBullet there's hundreds of attempts at malicious Chrome extensions that are abusing permissions.
That's what you got out of it? Google doing a good job? They sent an email with no guidance whatsoever.
These guys went above and beyond what most developers would've done, which would have been to contact support until they get a clear answer.
This only alienates the extension ecosystem. And this was the primary reason I switched to Firefox. Google is the new Microsoft. If I remember correctly, they started Chrome exactly so this very thing wouldn't happen.
As mentioned, I think Google have handled it poorly, but their fundamental position – that this extension is incorrectly using permissions – was significantly correct and may prove to be fully correct.
Google deserve criticism for the lack of clarity in the communication, they deserve criticism for the lack of human touch, customer support and many other aspects.
They do not deserve criticism for calling out incorrect permissions usage and forcing developers to do better.
It's confusing because whatever system (whether human or automated) they're using to flag permission issues has more precise detection abilities than they chose to expose with a simple "Permission is too wide - fix it".
The fact that the extension has over broad permission asks isn't good but I think saying their communication lacks clarity is underselling just how opaque they were with their feedback. It also concerns me a bit because it looks like their opaqueness might be an attempt at security via obscurity by trying to cloak what the rules actually are - which is a generally bad approach to trying to fight malevolent actors.
It's possible that the flagging has come from user submitted reports. In that case if Google trust the reports (and they have enough data about users to know if reports are likely to be genuine) then they don't necessarily need to know any more details.
Alternatively it could be vague to restrict the possibility of bad actors circumventing the letter of the rules without adhering to the spirit of them, or even just protecting themselves from legal repercussions (perceived or real).
Your later point is the one that concerns me. Organizations like governments have issues where the spirit of the law is valued over the letter due to inertial restrictions over revising the law - when it comes to private corporations the ability to restructure rules remains unless it's explicitly surrendered. In these cases keeping the set of rules exposed to the public (and even demoing changes) can allow revisions to those rules to increase their accuracy.
And, when you get right down to it, any rule that isn't well structured will be exploited by bad actors, people looking to roll out malicious browser extensions have a strong motivation to try and discover those rules with a high level of accuracy by testing them - only the good actors remain uninformed.
My gripe is that you should always be specific making requests, especially if you dangle something like a complete block of your account towards op but then you don’t say what needs to be done to prevent it.
It’s like I tell you get me a book on computer science or Ill fire you you, but I don’t tell you which one. Also I won’t response to any questions from you.
Whether OPs extension made him think about it is simply an entirely different matter.
a) the extension had been operating for years, unmolested by the Googlebot, with the expanded permission set
b) tightening up the permissions did _not_ solve the problem, indicating clearly that whatever the Googlebot was selecting for, it wasn't an incorrect use of permissions.
14 days is an absolutely egregious duration to get a response for a software change. A developer could be out on vacation for that long. Encouraging fast fixes is also irresponsible from a security perspective, which is what they are trying to fix to begin with.
Google sent an email saying they were asking for too many permissions. Pushbullet was asking to observe all website traffic. Google's email was objectively correct. I agree that the second rejection is more surprising, but yes, the first email seems like a case of Google doing a good job. I have very little sympathy for apps that ask for too many permissions.
Did they, though? The email seemed pretty clear that the problem was requesting more permissions than necessary.
I'm no Google fan, by any means, but if it's that hard for the developer to check which permissions their own app is requesting, I don't know if it's Google's fault.
I really did try to call out the benefits that happened when I was told to "give permissions another look". Like all software, needs change and I was able to make a great improvement.
The issue I have is that it's not clear if I'm even addressing the correct issue(s). If I don't make the Correct change, all other changes are irrelevant since they'll never get published.
Yeah, it's crap that they didn't give you guidance, although it seems like you managed to find plenty of issues quickly so perhaps the guidance is less necessary than it might seem.
Ultimately you know your extension, codebase, and use-case, far better than Google does, so it may not really be possible for them to give you the detail that you're looking for – you may be the only person who can do that.
I hope that they provide the support you need in understanding the problem to the point where the extension can continue to live on the Chrome store.
The big crime isn't the request to reduce permissions. The big crime is the lack of details and lack of communication. It's having to drop everything and work in a panic trying to guess how to please the faceless mysterious robot.
> I hope the developer finds another load of permissions they can tighten up, resubmits, and is approved.
You're missing the point here. The developer isn't given any guidance on what needs tightening. This shouldn't be guess and check. These rules impact this developer's livelihood. They should be well defined, documented, and communicated.
For comparison, some anecdotes elsewhere in the thread about how Apple attaches screengrabs and 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
At the very, very least, they could identify which of the permissions are in violation and need to be made more restrictive, and which aren't. Someone at some point at Google clearly had that information when they decided to flag the extension, but Google's processes failed to ensure they communicated it.
For the record, I actually agree with you that this is a good policy and will be a positive outcome for users. But while you seem to agree that Google could have handled this better, you're not doing a good job of acknowledging just how developer-hostile Google was here, which is why you're getting a lot of pushback.
Most of the discussion on this link is about how Google is being developer hostile. I think that's getting plenty of attention.
> At the very, very least, they could identify which of the permissions are in violation
If they've flagged this through user reports of the permissions being too wide then they may not actually know which permissions need to be changed. This is purely speculation though.
> they may not actually know which permissions need to be changed
How can they not know? They decide whether the update is accepted or rejected, and there's somebody or something at google that makes that decision, so google has to know.
If they didn't know what permissions need to be changed, how is the accept/reject decision made? Something like "accept the fourth try if the developer makes it that far because it is probably an improvement?"
> ... may not actually know which permissions need to be changed.
Sure, the first notice may have come from user flags, and the motivation for those flags is unknowable.
But it's been rejected again, after substantial permissions pruning.
Either they know why they rejected the update, in which case they should tell the developer; or they don't know why they rejected the update, in which case they're holding developers hostage to an inscrutable black box.
Most of the discussion on this link is about how Google is being developer hostile. I think that's getting plenty of attention.
You are certainly within your rights to state things divisively if it pleases you. I was merely suggesting how you might make your point in a way people will agree with you.
If they've flagged this through user reports of the permissions being too wide then they may not actually know which permissions need to be changed.
Even if this were true,
1) what about the update that narrowed the permissions, surely Google knew which permissions remained in violation? Remember, it was the rejection of that update that prompted this post
2) user reports of permissions being too wide should also be required to identify the specific permission that is in violation. That would not only help the developer, but also help Google make the decision on whether to ultimately ban the extension
3) Google should have clearly stated in the initial message that they hadn't actually verified that the alleged violations are occurring
>> As much as we can criticise Google's handling of this situation, the fact that the developer was able to reduce permissions from accessing data on _all websites_ down to _their website_, as well as tighten up a few other permissions, shows that Google is correct that the extension is asking for more than it needs.
OK fair enough, but why aren't the big violators held to this? (I realize this example isn't Chrome, but it is Google Calendar -- ever try to add a Zoom meeting invitation to your Google calendar? Zoom wants access to read and write all events ever on your entire calendar!
Extension developers monetizing their extensions by selling the data that they get from users is a big problem. It's the reason that I don't freely install useful extensions that I find today. I have no way to distinguish those who sell my data from those who dont.
I love that Google is starting to solve this problem, and from my perspective an extension that is sending and receiving SMS messages should not be requesting the ability to read and change all data on all websites that I access.
"Solve the problem" ok, so you're starting that this selling only happens when a third party dev does it?
Do You have an android phone? Do You use google for anything? Gmail? Google docs/drive? Youtube? Chrome? ChromeOS? Anything google owns? Then they're selling your data.
Try reading all those fun TOS agreements that come with using any of the aformentioned products, or heck, visiting sites that use google analytics.that won't tell you how much or what data google gets from you, but it'll tell you that you agreed to it.
They aren't solving this problem, they're killing off extensions. And I say this having received many unsolicited attempts to "purchase" Chrome extensions.
It's obviously a balance, but you could use that argument to allow any plugin on the store. It gives more choice.
I think it's important to remember that while PushBullet is known to many of us, is posting on Hacker News, is a valued part of "the community" in some respect, at Google scale this fact is not know. PushBullet is obviously good to _us_, and maybe just needs to tweak permissions a little, but to a reviewer at Google it probably looks very similar to the hundreds of extensions they may review a day, many of which may contain malware.
They have to use certain metrics to sort the good from the bad, and abuse of the permission system – intentional or not – is a pretty good one when you care about the end user.
I often wish for a separate browser for consumers that are also devs. I'd happily lift the permissions for some open source extensions I'm using if that means better functionality.
Was this not determined before, or they changed their minds now that Google is threatening to pull their product? Either they thought that was appropriate before, or they didn't think about it at all. Inexcusable either way.
Exactly. Not once in their diatribe did they provide a reason that they need those permissions. The fact that noone there knew why they were asking for those permissions in the first place is a huge red flag for me.
And why in the world are they asking for the cookies permission? That's a big, fat nope for me. It's as if they don't understand what they are asking for and the potential implications of passing that data around so haphazardly.
These folks need to take another hard look in the mirror before they point the finger, because their own house is way out of order.
Disagree that G's motivation here is to reduce permission footprint, because:
- if G has the ability to automatically audit necessary permissions, they'd do it when you upload to the plugin store
- if they're doing this manually for popular plugins, then (1) they'd publicly certify safe plugins and (2) the interaction would be way more high touch
Plugins are inherently unsafe + require trusting the developer.
Could be malicious, or G may not even have a reason for this (it may be some forgotten dinosaur instinct to knock over other people's stuff when it gets too big).
> - if G has the ability to automatically audit necessary permissions, they'd do it when you upload to the plugin store
If they added it more recently then they are just back-applying it to an already existing extension.
Alternatively, you can report plugins as requesting incorrect permissions – I've done this. Perhaps that's what's happened here, lots of reports triggering an investigation.
Also, Google could just block the permission and let the extension developers deal. Even that would be less hostile because at least the developers would know what to fix.
1. The article contains more relevant information that you did not show in your point.
2. Those relevant information made your point void
3. I think your point make no sense on the relevant information.
There, I refuted your claim, you have 14 days to change it and show what you learned.
I strongly disagree. If they were actually interested in this, they could simply tell the developers what to fix. This is beyond arrogant and counterproductive.
Why can't Google provide support instead of vague threats?
Provide a permissions audit tool, recommend ways to reduce permissions, provide a dev tool to automatically report on permissions that haven't been used while running an extension.
Is banning someone's entire Google account across all services a proportionate response to a developmer having trouble with Google's confusing permissions API?
Anti-cheat through obscurity on the other hand is absolutely a thing.
As a metaphor, there’s a damn good reason you can’t just pay an Olympic anti-doping facility to test your urine; it would be trivial to develop protocols that evade the tests if you could do that.
That’s not what we’re discussing though. We’re discussing if anti-cheat through obscurity works, and I’m saying if it did there would be no cheaters. Instead companies have to build technology solutions that also don’t work 100% but that’s beside the point.
There are certainly less cheaters than if there were no anti-cheat methods. To use OP's example, an open source urine testing procedure would be trivial to game. The same thing goes for open-source multiplayer games.
> it would be trivial to develop protocols that evade the tests if you could do that.
If it's trivial to evade the tests, then the tests are inadequate in the first place, and should not be trusted to be accurate.
Likewise, if an anti-cheat system relies on obscurity in order to not be bypassed, then it's a crappy anti-cheat system (and, mind you, would be far less necessary if multiplayer games didn't have a fetish for trusting the client to do potentially-exploitable things instead of insisting upon server-side validation, but I digress).
And likewise, if making your policy publicly-known will result in people skirting around the spirit of that policy, then the policy is poorly-written and should be rewritten to better reflect the intent.
Security through obscurity is not security. Full stop.
> 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!
They were completely in the wrong there, and posing a huge security risk to all of their users.
Permissions seem to be a pretty empty metric if you don't' know what the result is...
What was the impact of fewer permissions?
Let's assume PushBullet was doing something bad with some of those permissions and gathering data? Do they no longer have access to that data? I'm not sure that's the case, permissions alone don't determine that.
If PushBullet wasn't doing anything bad, did anything change?
Is it a positive thing for users when the extension disappears in a few days?
I went to look at what pushbullet does since I'm not familiar with it--in this day and age, "bullet" is a fearsome term so I wanted to make sure that wasn't the cause of google's alarm.
The personal information security concern I had is that it seems that pushbullet shovels all sorts of data from Chrome to the pushbullet server and then routes it to, pushbullet says, my other devices while respecting my privacy. While I don't doubt that pushbullet is an honest broker of my data, it's doing all this outside of google's purview. For somebody to spy on my data, they wouldn't need to break into google's ecosystem, they'd just need to break into pushbullet's.
I'm not disagreeing with all the other comments here about big bad google, I already think they are bigger and badder than everybody else here does.
And I'm not at all sure that what I'm pointing out has anything to do with google's motivation here (I liked the comment that said that this app is a threat to their walled garden), I'm just pointing out my impression to try to be helpful to OP in figuring this out.
GCP and the rest of Google are separated from each other similarly to how YouTube and Google are separated. Unfortunately, the odds of that technique working are very low.
> Although I am sure that this is not the correct place to reach out, I have reached out to the Chrome privacy team to see if they can give us some advice for PushBullet.
Though I posted this before this article was on the front page of HN.
Just remove access to http://localhost. This is a huge overreach in permissions, and honestly as a user I would feel violated by that. I have shitloads of things that I can lauch myself on localhost on custom ports, and no-thank-you I do not need to open them to some app.
LONG term Pushbullet user here, big proponent of their services. I use it on Firefox myself so this doesn't affect me personally but still there are few services I will strongly advocate for. Pushbullet is one of them. Google, if you're listening this is going to make a lot of users very unhappy.
I went through this on a side project and just let them kill off my public listing for now. I had the same thought process in terms of what I could change however my extension made use of InboxSDK and had access to GMail and I'm still concerned it might not make it through review...
Anyone else using InboxSDK in a Chrome extension and didn't get killed off by this change?
My extension hooks up the address book from a SaaS project (school information system) to GMail so faculty/staff can quickly look up parent contact information or send to special group email addresses that broadcast out to part or all of the school. The people using it were very happy to have it but I could conceivably go back to a private chrome extension if that is still allowed.
> - Request access to the narrowest permissions necessary to implement your product’s features or services.
> - If more than one permission could be used to implement a feature, you must request those with the least access to data or functionality.
> - Don't attempt to "future proof" your product by requesting a permission that might benefit services or features that have not yet been implemented.
My first thought was "oh it would be NICE if G actually enforced these". But the truth is that they're not. One glance at the Android Play store, and it's abundantly clear that Google is letting shitty apps request whatever unnecessary permissions left and right.
Literally the top flash light app requires "full network access", GPS precise and approx location, "view network connections" and "receive data from internet".
It's complete bullshit, Google isn't policing these permissions at all, but just using it as an arbitrarily enforced rule.
It's pretty clear what the incentives are. Android already has a flashlight, but this one has ads, harvests and sells your data, and uses Google Play Billing Service. Win for Google. On the other hand, there's PushBullet, which gives users more control and this is key, the option to use a platform that is not controlled by Google. It has nothing to do with user privacy.
And the whole nice thing about these permissions is that they are granular, this means it should be trivial to point out which one is wrong or better and why, like an error message. That is not "gaming the system", it's literally what these permissions are for.
This is also clearly not an automated scanning process that PushBullet accidentally got hit by. Because it would have to have been a very slow running process, given the heaping amounts of trash in the Play Store. And then it just happened to pick PushBullet instead of the Flashlight app that has 50 times more downloads??
It's classic google. Now that they are a monopoly, they don't have to compete for developer's attention. That's why I will never give a cent to Google Cloud, I know too well how it's going to end up if they ever become a major force in the cloud, I'm not going to invest anything with them and strongly suggest any business I work in to minimize their exposure to Google product. They all end up the same way.
> Once you have made these changes you may submit and publish a new draft in the Chrome Web Store Developer Dashboard.
> Your draft will then be reviewed for policy compliance. If the outcome of the review is successful, your existing store listing will get replaced by the approved draft. However, if the new draft fails to comply with our policies, both the draft and the existing store listing will be removed. Please note that the rectification window expires the moment a new draft is submitted. After this point, you will not be able to make iterative changes regardless of the days remaining in the warning period.
Holy fuck, that's insane. You get one shot; if you miss, game over.
Counterpoint: there is a team within Google that got it right at least once. We have live import/export integration with Google Sheets and this requires additional OAuth scopes. The request for justification they sent was polite, specific about the scopes of concern (and why), and with no hard deadline. Our response was handled politely and promptly.
I realise the GCP API team may not be dealing with as big of a swamp as a consumer-facing apps group, but it was nevertheless one of those few occasions when Google left me with an impression other than overwhelming hubris. It was more like talking to AWS service teams, or Cisco TAC when you have a CCIE on staff.
I'd been in a similar issue on the Android store and found that the best solution was to try to game whatever bot is flagging you. Support was completely unable to provide clarity and getting escalated by internal Google employees just led to more unhelpful emails from higher levels of support.
I was positive that I was in compliance but I could also see that a bot was flagging something. So I kept tweaking code and resubmitting. Eventually what worked was taking the offending code block and hiding it at the server level.
It's such a face palm. I literally call out to the server to run some logic that should be completely safe to run in the app.
2020 and our browser privacy handling is like MS-DOS.
Why the hell I can't disable all extensions when I enter my bank account or insurance page? As far as I know Firefox containers are close but still no fine grained control over extensions.
I haven't used Pushbullet in depth but on first glance it doesn't seem like a browser extension at all. It looks more like a standalone chat app that happens to be running in the browser. It has nothing to do with enhancing the browsing experience, except for a share-link feature?
Google might not want to make Chrome the browser into an OS.
If i were Google i would also be skeptical when such standalone apps wants to read my browser cookies or access my http://localhost. Actually i think cookies is the violating permission here.
I understand that with many spam-related heuristics, a company like Google chooses not to share exactly why a site or e-mail server is blacklisted -- because an actual spammer can evade that metric and still get away with everything.
But I don't believe that thinking applies whatsoever to apps or extensions. There are far fewer of them and parties need to work together. It's unfathomable to me why Google doesn't point out which specific permissions a reviewer has flagged as suspect, or given an option for the developer to give the justification specific to each option.
These folks also do the same thing for Adsense on sites. For a site, I am running for a long time. 10+ years. And earned multiples of 100ks worth of revenue from it.
They sent a vague email, regarding violation and suspended Ad serving. Never ever had any issue before.
I can only suspect that their policies have changed because of the current pandemic. But isn't it disingenuous, in that case. Similar to laying off an employee, and cooking up a shady reason for it.
They will only make me kill the business, which in turn will stop payments (reduce significantly) to AWS. Thereby enabling more slow down.
A bit late to this thread but this is happening to my chrome extension right now. No idea why, I have 10,000+ users and the chrome support team just keeps emailing me the same statement with different items highlighted in bold, saying it doesn't work and the description isn't accruate.
a) It does work
b) The description is accurate
I have no idea what they want me to do and I don't have time to try and guess.
I don't get paid for my extension, so I'm just going to redirect everyone to the FireFox version now. The Chrome store will be poorer without it and that's on them.
Is that why universal cut & paste has been flakey? I am dropping all Google stuff. They recently killed my Alexa Skill on Android (Samsung S9). With everything google deleted or permissions denied on my phone, they still hijack the word "contact." Try saying, "Alexa launch Contact Ski Man." Still works with Alexa on iPhone, but how do you use a smartphone without back button? We have reached the point where it is time to throw the baby out with the dirty water. Say, "Hey FireFox!"
I have an app that was falsely flagged as malvertising by Google Ad Manager. Also got a generic message with no insight into the specific problem.
It was only because I had a point of contact at Google with actual influence that I was able to resolve the issue (and they did, miraculously). If you don't know a human, Google's automated systems can more or less destroy your app or business for Google product users, which is pretty much everybody. G is a big, multi-headed beast. Not evil, but worse - indifferent.
It seems like everyone in here suggesting a switch to Firefox is missing the point. The Pushbullet team has already stated that having this Chrome extension pulled might mean the end of Pushbullet. So I'm going to trust that they know their own business well enough to make that statement.
I actually already use Firefox and their Firefox extension. But it won't matter that I'm savvy enough to do this if losing enough users from having the Chrome extension killed is enough to kill the larger business.
My guess is 'cookies'. You really shouldn't need access to (say) the user's Google cookies. I don't expect Google likes extensions doing that without good reason.
I too have deGoogled as much as I can, but I’m hesitant to jump on the hate wagon for this one.
Consider the counter factual - what if google was highly specific about the changes required? Clarifing the boundaries of what’s allow is prone to abuse. This is the same reason why the search algorithms are not explicitly published, but only the spirit is explained.
I would say this is the best solution when there are no perfect solutions.
Perhaps the 14 day period could be longer, but that’s another point of contention.
I stopped using pushbullet because I realised its access made me a bit uncomfortable, but had I had the 'So, can we cut any of these permissions?' paragraph to read at the time, that may have reassured me. Nice to see it not only being investigated (even if it took Google's vague threat to spur it on) but positively so; seen as 'A big win!'.
Long time user of pushbullet since I like to be able to text from the desktop. Google has released messages.google.com, which is a nightmare to use among various desktops.
Microsoft released their Phone app, which disconnects so frequently it is unusable.
I have no confidence Google will allow pushbullet back.
Is there a replacement that allows notifications and texts from the desktop?
As the developer of an exposure notification app put on ice by Apple-Google, it's due time to take back the freedom of the internet that made it so powerful in the beginning.
Is there anything happening around an all-web app phone? Seems like all the pieces are there..like native functionality in JavaScript with certain extensions.
Chrome extension developers should start hosting them on Github.
I use a flavor of Chrome called Ungoogled Chrome (https://ungoogled-software.github.io/) and the only way to install plugins is to manually install the CRX file.
Yikes! I've used PushBullet for since several years and I can't imagine not using it.
I can understand why Google is doing this though. They have a "Send to device" feature in Chrome. Killing the top 3rd party app is the perfect way to grow adoption of their new & in-built feature.
You know, at the very least it would be nice to get something a bit more direct, like, "We are no longer permitting extensions that do X on our marketplace", or heck, even just a "We're permanently rejecting this for unspecified reasons."
But if that's what you're doing, don't claim that the extension is being rejected for "overbroad permissions". I understand that Google may not literally come out and say "We've decided to eat your extension's functionality and you can just burn." But don't lie about why it's being rejected... however much you may wrap the result up in marketingspeak, don't actively lie about the reason for rejection, so that someone can burn the candle at both end for two weeks futilely trying to appease the lying error message.
As for the fact it may not look that great no matter how much marketing-speak it gets wrapped up in for Google to just eat some functionality and kill all competition... yeah, well, suck it up Google. Don't lie about it. I mean, you can always spin it as security security blah blah security if nothing else, which ought to be enough of a fig leaf.
Neither here nor there but it was "Don't be evil", never "Do no evil". The latter evokes the Hippocratic Oath and sounds virtuous, but the former is a somewhat tongue-in-cheek reference to the (at the time) megacorps they wanted Google to not be like.
(Mind, they're arguably not complying with the "Don't be evil" version either, especially lately.)
True, that was the way before they removed the "http(s):///" permission. That is a tremendous permission to ask for and would be a huge red flag in any case.
Now they limited it to ".pushbullet.com", but even then they don't need that permission since ".pushbullet.com" is a server controlled by them, so they are free to set and read those cookies anyway.
The cookies permission is only needed if you want to read cookies from a domain you don't own. The extension has no need to modify the cookies, and if Pushbullet wants to set or change them, for example to set session cookies, it can do so in a non-extension tab. The extension can then send those cookies in their API request automatically without needing to access them.
I know Google employees that have had their accounts on various Google Services shutdown and they couldn't even get them back themselves. The place is very siloed, something needs to give because these nightmare scenarios keep happening over and over.
I had a friend who went through a similar, onerous process with Google which ended up killing his entire chrome extension (which had 400,000+ MAU). This iron-fisted control of the extension marketplace is not becoming to Google.
I've had a Chrome extension removed from the store before, I suspect because it conflicted with Google's business model. I would be very wary of building a business on a foundation that another company controls.
Under the Clayton Act, the Sherman Act, or both? Is this a legal realism commentary on the comparative cost-benefit of civil antitrust litigation in modern America?
Or are you just pretending you know things to feel good on the internet.
I just want to take this opportunity to complain about trying to send a gmail email from a service account, which required us to use G-Suite, and still doesn't work because it can't generate a token.
Wait can some one please simply explain to me whats gong on here? I'm new to this but I absolutely love it! and I paid for it too. Why do all good things have to be taken away?
Normally in a lucrative but restricted market there is a regulator or ombudsman one can appeal to if one feels they have been unfairly pushed out. App stores need regulators.
For one, I think this is good news. I work in a field that exposes me to a lot of dubious ways to collect peoples data. Especially what they are doing in their browser. You would not believe how many pieces of software you are using daily that do this.
A lot of these are chrome extensions. If you are honest, then I do feel for your situation. But, I am also happy to see that Google are finally stepping this up and looking after their users by not exposing them to potentially malicious services.
They don't give shit about your 4.5 star rating. Your 4.5 star rating doesn't mean you are the most private or most secure over there. Facebook got 4+ rating on all there apps with 1B+ users, that doesn't mean they need access to those call logs,messages and everything on your phone.
Keep you permission to the minimum, for both security and privacy. Chrome team doesn't give shit about people like you.
Stuff like this makes me wonder why Chrome's security model allows things if it can be scanned and deemed unsafe. Isn't it preferable to bake such restrictions into the extension API if Google didn't want PushBullet to go beyond it? Why does this need to be enforced by an app store?
This kind of thing just keeps. Coming. Up. from Google and between ML black boxes making arbitrary judgements and random product shutdowns, a hard requirement for any personal projects of mine is "no Google dependency", because it might vanish at any time, with zero notice or recourse.
We never use plaintext http so that is a reasonable thing to remove for our first-part domain (pushbullet.com).
We use localhost to communicate with our desktop application. An example is preventing both our extension and desktop apps from showing notifications on the same computer (our apps are all about notifications so this would get unacceptable very fast). Maybe if we limit it to just the local port we use? Seems like it can't hurt to try that too.
You could try that. Long term, it should also be possible to route this communication through the internet, or use the Chrome/Firefox/WebExtension NativeMessaging API [0][1].
How about removing the permissions for HTTP and keeping the HTTPS permissions? If the problem is "User Privacy Safety" as the rejection suggests, this seems to be the obvious choice.
Funny, very funny. Not your keys, not your coins. Not your store, not your clients. Not your playground, not your rules. etc. etc. I sympathise, but discourage cooperating with Google.
> but they're just responding to market hysteria on permissions.
And responding poorly.
What the market wants is for companies to lay out understandable policies that protect their privacy. People I know want more clarity about what's happening in the extension store and on their devices, not less.
As a consumer, it doesn't make me feel any better for Google to say in vague terms, "we booted off an app that doesn't respect your privacy." Okay, what was it doing? Are there other apps I should be concerned about? How bad did the app need to get before you booted it off? Are there exceptions to these standards? Are they being applied to internal apps as well?
My feeling is that Google's inability to communicate with developers and users is its own problem; it's not the market's fault. Tech companies in general have had difficulty with customer support for a while, even before the media started picking up on privacy issues. Nothing has really changed, Google just happens to be notably bad at this.
I'm not mad about them increasing scrutiny on permissions, that seems fine. What sucks is Google giving a short deadline, no details, and zero response to the developer's repeated communication attempts; all with the threat of Google nuking every single Google resource tied to the developer if they step over some invisible line.
The general idea of "please limit the permissions you request", maybe. The secrecy about what they don't like isn't part of that, that's just Google's preference for keeping things vague.
This dude has written crappy, inefficient code and is now complaining for it. If just permissions are so inefficiently written one can only imagine, what would be the state of rest of the codebase. Badly written apps can also generate traction. Users don't see the code quality. They rarely know the first thing about privacy and security.
It's not Google's job to teach someone to how to write good code. Good compiler can tell you what is the error, it won't pop out a solution as well.
> 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.)