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

591–600 of 811 posts

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

#591

Post by roca »

derefr wrote: post #86
the_jeremy wrote: post #51

Earlier quoted context omitted.

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.

> Who do you trust? Certainly not Chromium-Edge. 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 Chromi…

It's Chromium that's hobbling the content-blocking extension API.

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

#592

Post by kishansagathiya »

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.

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

#593

Post by mirimir »

IG_Semmelweiss wrote: post #558
bentcorner wrote: post #544

Earlier quoted context omitted.

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.

No. This gets you banned.

Is that really true?

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

#594

Post by petre »

csours wrote: post #578
Filligree wrote: post #513

Earlier quoted context omitted.

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.

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.

You're missing the fact that the reason is given by software not an actual person. Welcome to the world of social automation.

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

#595

Post by m-p-3 »

cryptonector wrote: post #563
geofft wrote: post #403

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…

Like you, I suspect http://localhost/ is part of the issue, indeed. I wonder if Google could have a .localhost origin for this.

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.

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

#596

Post by umvi »

kelnos wrote: post #518
geofft wrote: post #494

Earlier quoted context omitted.

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

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

> 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

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

#597

Post by erikrothoff »

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…

Can’t you setup a DNS entry on your domain that resolves to 127.0.0.1 that you reference instead of localhost?

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

#598

Post by zobzu »

geofft wrote: post #494
JaggedJax wrote: post #485

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

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!)

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

#599

Post by caf »

Filligree wrote: post #513
csours wrote: post #497

Earlier quoted context omitted.

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?

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

#600

Post by phire »

kevingadd wrote: post #472
geofft wrote: post #403

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.

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.

Post reply on HN