8 ms·
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
by danpalmer 7y ago
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.
- Guzba 7y agoI 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.
- danpalmer 7y agoYeah, 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.
- duxup 7y agoPermissions 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?
- gowld 7y agoWhy 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?
- jpalomaki 7y agoUsual answer is that this would make it easier for malicious actors to bypass the limitations. Likely there is some automated system running these checks.
- freehunter 7y agoSecurity through obscurity is no security at all. Edit - this is a basic principle of security: https://en.wikipedia.org/wiki/Security_through_obscurity https://en.wikipedia.org/wiki/Security_through_obscurity
- ashtonkem 7y agoAnti-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.
- freehunter 7y agoIf anti-cheat through obscurity worked, there would be no cheaters. The fact that cheaters exist means it does not work.
- streb-lo 7y agoYour logic does not follow. 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.
- TuringNYC 7y ago>> 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!
- andrewmutz 7y agoExtension 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.
- onefuncman 7y agoThey aren't solving this problem, they're killing off extensions. And I say this having received many unsolicited attempts to "purchase" Chrome extensions.
- andrewmutz 7y agoI disagree. I think this practice could be seen as anti-developer, but it is pro-consumer.
- AmericanChopper 7y agoThe bit that improves user’s privacy is pro-consumer. The bit that removes user’s access to products is anti-consumer.
- danpalmer 7y agoIt'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.
- bosswipe 7y agoThe 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.
- wombat-man 7y agoyeah, it would make way more sense to codify the policy and just tell devs that they are using banned functionality or something.
- sixothree 7y agoThis exemplifies Google's reputation well.
- xg15 7y agoI strongly disagree. If they were actually interested in this, they could simply tell the developers what to fix. This is beyond arrogant and counterproductive.
- adverbly 7y ago> 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.
- the_gipsy 7y ago> These rules impact this developer's livelihood. Let this be the millionth lesson of "the perils of building on a platform instead of on a protocol".
- crankylinuxuser 7y agoYou misspelled "sharecropper".
- fdavison 7y agoI don't know why you are being downvoted, sharecropper is exactly the right metaphor.
- danpalmer 7y agoWell they did give details on what needs tightening, it's just that those details are in the form of policy points not being hit. What do you think they should be providing? Honest question, I have some ideas but they all feel very tricky/error prone to implement.
- laughinghan 7y agoAt 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.
- awinter-py 7y agoDisagree 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).
- ViViDboarder 7y agoAlso, 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.
- danpalmer 7y ago> - 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.
- gnu8 7y agoI'm trying to figure out why that was their setting to begin with. > We do not need to request access to data on https://*/* https://*/* and http://*/* http://*/*. 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.
- trashfindhunter 7y agoExactly. 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. Why are they asking for https://*.pushbullet.com/* https://*.pushbullet.com/*, http://*.pushbullet.com/* http://*.pushbullet.com/*, and http://localhost/* http://localhost/* read permissions? I suspect it's the localhost permission request that is currently blocking them. 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.
- ekanes 7y agoYes, it seems pretty bad that by default they were accessing user data everywhere. Gross.
- fgonzag 7y agoThat'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.
- megablast 7y agoThis is an unsafe extension that had access to every website but did not need it. Yes, that is what I got too.
- danpalmer 7y agoAs 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.
- munk-a 7y agoIt'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.
- danpalmer 7y agoIt'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).
- lvs 7y agoEdit: I was the one who misread it. My mistake
- vntok 7y ago> 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://*/* https://*/* and http://*/* http://*/*. Instead, we can simply request data access for https://*.pushbullet.com/* https://*.pushbullet.com/*, http://*.pushbullet.com/* http://*.pushbullet.com/*, and http://localhost/* 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.
- mkl 7y agoI think you're the one misreading. From the article: "We do not need to request access to data on https://*/* https://*/* and http://*/* http://*/*. Instead, we can simply request data access for https://*.pushbullet.com/* https://*.pushbullet.com/*, http://*.pushbullet.com/* http://*.pushbullet.com/*, and http://localhost/*." http://localhost/*."
- Aperocky 7y agoI disagree with you here because: 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.
- jshevek 7y agoPlease don't use that quoting style for non-code.