Uh, yikes: > As I looked at the permissions and what our extension actually needs to operate, I noticed a great opportunity to reduce our permissions requests. We do not need to request access to data on https://*/* and http://*/* . Instead, we can simply request data access for https://*.pushbullet.com/* , http://*.pushbullet.com/* , and http://localhost/* . This is a huge reduction in the private data our extension…
>Uh, yikes Agreed I wish we could send everyone that thinks this kind of response from a megacorporation is good to a kafkaesque alternate universe.
Let's guess what Google requires in 14 days or they kill our extension
491–500 of 811 posts
Re: Let's guess what Google requires in 14 days or they kill our extension
#492Earlier quoted context omitted.
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.
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.
Re: Let's guess what Google requires in 14 days or they kill our extension
#493Earlier quoted context omitted.
I believe you're supposed to use Native Messaging for that: https://developer.chrome.com/extensions/nativeMessaging
Native messaging is extremely broken and has bad documentation. I never got replies to my bug reports about it and gave up and just used websockets.
Out of curiosity, what were the problems you ran into with native messaging?
Re: Let's guess what Google requires in 14 days or they kill our extension
#494Uh, yikes: > As I looked at the permissions and what our extension actually needs to operate, I noticed a great opportunity to reduce our permissions requests. We do not need to request access to data on https://*/* and http://*/* . Instead, we can simply request data access for https://*.pushbullet.com/* , http://*.pushbullet.com/* , and http://localhost/* . This is a huge reduction in the private data our extension…
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 eff…
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?")
Re: Let's guess what Google requires in 14 days or they kill our extension
#495Earlier quoted context omitted.
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…
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.
If you have a half-decent router or firewall, this won’t work from outside the network.
Re: Let's guess what Google requires in 14 days or they kill our extension
#496Earlier quoted context omitted.
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.
the docs are pretty explicit about it
But not their email.
Re: Let's guess what Google requires in 14 days or they kill our extension
#497Earlier quoted context omitted.
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 eff…
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,…
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.
Re: Let's guess what Google requires in 14 days or they kill our extension
#498Earlier quoted context omitted.
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.
Maybe check the Fxtec Pro1: https://www.fxtec.com/pro1 It has a full QWERTY keyboard and reasonably well working Sailfish OS port.
Interesting, thank-you!
Re: Let's guess what Google requires in 14 days or they kill our extension
#499Earlier quoted context omitted.
It seems like the majority of plugins will need to access all websites. Just looking at my list of plugins: - EditThisCookie - ResourceOverride - Ad blocker - Grammarly - LastPass I absolutely expect these to work regardless of website. It seems perfectly reasonable for this to be the default behavior.
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…
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.
Re: Let's guess what Google requires in 14 days or they kill our extension
#500Earlier quoted context omitted.
While Firefox is better than Chrome... 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
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.
Unless you frequently use spyware websites that are too lazy to do server-side scripting, using a browser with a less used engine is fine.