Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Let's guess what Google requires in 14 days or they kill our extension

blog.pushbullet.com

Post reply on HN
Print view View original

181–190 of 811 posts

Re: Let's guess what Google requires in 14 days or they kill our extension

#181

Post by Wowfunhappy »

Guzba wrote: post #169
Wowfunhappy wrote: post #160

> 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…

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? An optional permission seems 100% reasonable.

> 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.

Re: Let's guess what Google requires in 14 days or they kill our extension

#182

Post by gnu8 »

danpalmer wrote: post #53

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.…

I'm trying to figure out why that was their setting to begin with.

> We do not need to request access to data on https://*/* and 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.

Re: Let's guess what Google requires in 14 days or they kill our extension

#183

Post by paulirwin »

Guzba wrote: post #166
thorum wrote: post #94

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…

I believe you're supposed to use Native Messaging for that: https://developer.chrome.com/extensions/nativeMessaging

Re: Let's guess what Google requires in 14 days or they kill our extension

#184

Post by deckard1 »

jaywalk wrote: post #121
AaronFriel wrote: post #59

Earlier quoted context omitted.

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. See the uBlock Origin author's post: https://github.com/uBlockOrigin/uBlock-issues/issues/338#iss... This is ironic, because uBlock implements an extr…

> In fact, this change is meant to give developers a way to create safer and more performant ad blockers. Imagine anyone actually believing Google is trying to help ad blockers. What a dumb thing for them to even say.

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.

Re: Let's guess what Google requires in 14 days or they kill our extension

#185

Post by jlevers »

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.

Re: Let's guess what Google requires in 14 days or they kill our extension

#186

Post by VWWHFSfQ »

Guzba wrote: post #166
thorum wrote: post #94

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…

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.

Re: Let's guess what Google requires in 14 days or they kill our extension

#187

Post by calmchaos »

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.

Re: Let's guess what Google requires in 14 days or they kill our extension

#188

Post by [deleted] »

Guzba wrote: post #166
thorum wrote: post #94

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…

[deleted]

Re: Let's guess what Google requires in 14 days or they kill our extension

#189

Post by jschwartzi »

dylz wrote: post #161
freehunter wrote: post #149

Earlier quoted context omitted.

That's a stupidly hidden way to go about it.

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.

Re: Let's guess what Google requires in 14 days or they kill our extension

#190

Post by Wowfunhappy »

filleduchaos wrote: post #91
ChrisMarshallNY wrote: post #62

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.

This is why I'm often amused when people gripe about the $99/year membership fee for the Apple Developer Program.

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).
Post reply on HN