Live data from Hacker News

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

blog.pushbullet.com

651–660 of 811 posts

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

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

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?" Yeah, but with 100 people it would take only a few months and after that it would take far less people to maintain everything. Also, they c…

Apple manages to do it somehow - when you get rejected, you can discuss the rejection reason if I remember correctly.

Also, from 200k extensions probably most have less than five users, so they could prioritize those that have traction.

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

#652
post #596

Earlier quoted context omitted.

> 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

I think it's more likely that their flagging is heuristic based and could easily defeated by a malicious extension author and giving detailed feedback makes reverse engineering the rules trivial.

> flagging is heuristic based and could easily defeated by a malicious extension author

Well, if the reason is the "https://*/*" permission or something like that, and it is flagged and reported automatically, and everyone learns not to use it, it's a win-win. Benign extensions will have smaller targets on their backs, and malicious extensions will become less malicious OR will have to jump through hoops to achieve what they're trying to achieve (and will become easier to detect).

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

#653
post #486

Earlier quoted context omitted.

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.

This is actionable advice. The action is to create an offer that is not entirely depeneent on a single platform provider. Don't build browser extensions for just a single browser. Don't build an app based business solely around an iOS or Android app - support both platforms. And so on.

> Don't build browser extensions for just a single browser.

That won't matter if 60–70 % of the users are on that single browser.

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

#654
Google really sucks at customer service. Like they either don’t get it or they’re so far up their arses that they think fancy AI algorithms will magically fix it.

They are the most inhuman tech company I have dealt with out of the big 3 clouds.

I have a similar experience. I am trying to get an oauth consent screen approved. It’s a simple thing. It takes up to a week for someone on their side to reply and it’s mostly one vague sentence. They don’t give a full list of what needs to be done. I’ve been at it for more than a month. It’s like they really don’t give a shit about how much time you’re sinking to make things work with their services.

I have a love/hate relationship with Google. On one side they know how to keep things reliable like google search, on the other side they need to stop doing a 100 million things and do 10 things really well and maintain it for eternity.

If someone eats Google’s Search lunch, they are done for.

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

#655
post #493

Earlier quoted context omitted.

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?

So native messaging is fundamentally about opening a named pipe to a child process managed by the browser. I found that the pipe would silently break or time out. In the former scenario, the app was running but could no longer exchange native messages with the browser or extensions - chrome was just ignoring the pipe traffic. In practice I was able to use native messaging to spawn the executable but to actually talk with it I needed to use a websocket, kind of defeating the point.

I initially assumed I was doing something wrong but after a week or so experimenting with simple test cases I could not get it to work. Maybe it works fine on Linux and Mac but not Windows.

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

#656
post #587
post #486

Earlier quoted context omitted.

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.

Invest in more open platforms. Not a great short term solution, but not many alternatives.

Microsoft threw in the towel, discontinued their web browser development and became a Chromium fork. How are these extension developers supposed to invest enough in platforms that complete with Chrome to succeed?

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

#658
post #494

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

> we have a ten-person team, we'll get back to you within 5 years?

It is TOTALLY not OK to have a ten person team (and I have no way to know if they even have that).

Considering the fact that the browser platform is now a real service required by billions of people, they should be responsible to have enough staff to handle extensions properly.

Aside from the amount of money the Chrome extensions make them, the amount of influence it buys them, and the amount of damage it can do, it should be required of them to have a real team to handle it.

Imagine if the I ran a private airlines that provided service for 4 billion people around the world, and the entire team that inspects, approves, and monitors the pilots and co-pilots had ten people. Would you think that is acceptable, or would you expect multiple governments to intervene?

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

#659

Earlier quoted context omitted.

This is actionable advice. The action is to create an offer that is not entirely depeneent on a single platform provider. Don't build browser extensions for just a single browser. Don't build an app based business solely around an iOS or Android app - support both platforms. And so on.

> Don't build browser extensions for just a single browser. That won't matter if 60–70 % of the users are on that single browser.

Which is one big reason, why having one browser dominating the market is a bad thing. Use firefox or something else, people.

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

#660
post #494

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

> we have a ten-person team, we'll get back to you within 5 years?"

I'm of the opinion that a company with revenues > 30 billion dollars per quarter could afford to increase the ten person team ten-fold to get the response time to a reasonable number.

Post reply on HN