Live data from Hacker News

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

blog.pushbullet.com

421–430 of 811 posts

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

#421

Earlier quoted context omitted.

Switching email isn't nearly as friction-free as switching your browser. Not only do you have to change your email in every service you've registered for, you also need to convince your friends and other contacts to use the new email.

The most important change you can make for your email is to own your own domain. Once you own your own domain, changing providers is much easier since it is transparent to the people that email you. Even if you decide to keep Gmail, you should switch your email to your own domain.

> Even if you decide to keep Gmail, you should switch your email to your own domain.

Do you pay for Google Domains, or just have some other thing forwarding to gmail, and gmail configured to send with that as a 'from' address, which I think is possible? What's your advice?

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

#422
post #64

Earlier quoted context omitted.

Chrome is a trivially easy product to switch off of compared to other Google properties like Gmail and YouTube. Have you tried Firefox recently?

ProtonMail has come a long way as a replacement for Gmail as well. Suuuper happy with them, they're really responsive to feature requests and support inquiries. I requested for an iOS feature to choose browsers so I could open all links from PM in Firefox. They had it implemented in a month or something... it a quick fix but that impressed me. hence me shilling here They recently added ProtonCalendar too.

I think most people are never going to choose ProtonMail, but it can be good for people who like simplicity and consistency. I don't need a million bajillion options, "plugins" or "apps" for my web mail. Just show me my emails, let me load attachments, and I'm good. That's why I pay for ProtonMail instead of Gmail. Well, that and all the other reasons to distrust Google.

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

#425
post #182

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.

Exactly. Not once in their diatribe did they provide a reason that they need those permissions. The fact that noone there knew why they were asking for those permissions in the first place is a huge red flag for me.

Why are they asking for https://*.pushbullet.com/*, http://*.pushbullet.com/*, and http://localhost/* read permissions? I suspect it's the localhost permission request that is currently blocking them.

And why in the world are they asking for the cookies permission? That's a big, fat nope for me. It's as if they don't understand what they are asking for and the potential implications of passing that data around so haphazardly.

These folks need to take another hard look in the mirror before they point the finger, because their own house is way out of order.

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

#426

Earlier quoted context omitted.

Out of curiosity, where those big name apps, or small ones? I assume that level of service is reserved or more important apps?

I had Apple point out that I hadn’t yet added a TOS for a trivia app I was making; they’re very thorough.

Almost every rejection has been a matter of "process," like ToS, privacy policy, plist entries, etc.

In a couple of cases, they actually found crashes that I missed in my testing.

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

#427

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.

Someone from Apple got on the phone with me to explain a rejection. I was disappointed with the outcome but very surprised at how they were willing to talk about it and explain why.

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

#428

Earlier quoted context omitted.

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.

This is an all or nothing fallacy; the standard is not 100% success. It’s bit like saying “all locks can be picked, therefore they’re useless”.

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

#429

Earlier quoted context omitted.

At the very, very least, they could identify which of the permissions are in violation and need to be made more restrictive, and which aren't. Someone at some point at Google clearly had that information when they decided to flag the extension, but Google's processes failed to ensure they communicated it. For the record, I actually agree with you that this is a good policy and will be a positive outcome for users. Bu…

Most of the discussion on this link is about how Google is being developer hostile. I think that's getting plenty of attention. > At the very, very least, they could identify which of the permissions are in violation If they've flagged this through user reports of the permissions being too wide then they may not actually know which permissions need to be changed. This is purely speculation though.

> ... may not actually know which permissions need to be changed.

Sure, the first notice may have come from user flags, and the motivation for those flags is unknowable.

But it's been rejected again, after substantial permissions pruning.

Either they know why they rejected the update, in which case they should tell the developer; or they don't know why they rejected the update, in which case they're holding developers hostage to an inscrutable black box.

Both scenarios are shitty.

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

#430

Can anyone at Google even pretend they aren't evil any more?

So Google is evil for asking that an extension not request permissions it doesn't need to use?

If this were Apple we would be celebrating how privacy-forward they were.

Post reply on HN