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.
If anti-cheat through obscurity worked, there would be no cheaters. The fact that cheaters exist means it does not work.
What next - if philanthropy worked there would not be any poverty in the world. So let's stop all philanthropic actions.
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…
https://*/* being allowed at all without aggressive vetting is a big mistake. It's astonishing to me that they ever made it easy to do this.
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 di…
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 b…
The screenshot thing sounds downright Kafkaesque. Infuriating!
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: https://groups.google.com/a/chromium.org/forum/#!forum/chrom... It's a systematic issue that isn't specific to anything Pushbullet is doing and it's been like this before the pandemi…
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.
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 di…
> 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.
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?
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.
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…
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.
Chrome is a trivially easy product to switch off of compared to other Google properties like Gmail and YouTube. Have you tried Firefox recently?
I have a firewall appliance at home. One day I noticed that some of the stuff I blacklisted (mostly ads) started showing up again. Why? Firefox's new DNS over HTTPS was bypassing all my firewall DNS rules.
> 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.
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: https://groups.google.com/a/chromium.org/forum/#!forum/chrom... It's a systematic issue that isn't specific to anything Pushbullet is doing and it's been like this before the pandemi…
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.
Yeah, if enough intelligent people would just band together and agree to NOT do business with any corporations or co's that don't offer live human people answering their phone with intelligible English within 3 minutes of connection, voice mail and robot mail prohibited - - - bring these bastards to their knees - - or put them out of business.
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: https://groups.google.com/a/chromium.org/forum/#!forum/chrom... It's a systematic issue that isn't specific to anything Pushbullet is doing and it's been like this before the pandemi…
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.
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.