Another reason to use Firefox.
Let's guess what Google requires in 14 days or they kill our extension
401–410 of 811 posts
Re: Let's guess what Google requires in 14 days or they kill our extension
#402Earlier quoted context omitted.
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).
You just answered yourself. It's not a the only way to run your own code on your own phone. AFAIK that restriction is to prevent jailbreakers from easily sideloading paid apps as "their" apps on their phones.
But it effectively is! There is no way for me to make anything useful for myself if I have to connect my phone to a computer and reinstall the app every seven days. If I forget, the app suddenly won't open. If I go on vacation without a computer, the app won't open. The seven day thing is useful for testing, and nothing more.
If the goal is to prevent piracy, well, as with other forms of DRM I as a paying customer don't appreciate being treated like a thief. Dedicated pirates can and do just buy stolen enterprise certs on the black market anyway.
Re: Let's guess what Google requires in 14 days or they kill our extension
#403Uh, 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 could theoretically access. A big win!
While I agree with the larger part about the lack of transparency of what they want you to fix, this is an amazingly huge oversight, and the fact that the extension review process got an established, popular extension to go "Wait, we don't actually need to request access to every website ever" is a point in favor of the review process - and, unfortunately, a (weak) argument in favor of the review process taking the attitude that they get lots of crap and don't have the time to explain to all the authors of crap what they're doing wrong. How did the extension ever ask for this in the first place?
Also why do you need http://localhost/? Is the extension running a web server on localhost with native code? If so, can you use the specific mechanism/permission for communicating with native code via a subprocess (because it turns out communicating with a web server on localhost is very hard to do securely)? If not, what's it for?
I'm sympathetic to the broader argument here, but given the provided information, all of this is consistent with an extension that should be kicked off the app store within 14 days.
(Among other things, if you have an approved extension with https://*/* permissions and active users, malware authors will offer to buy your extension for a very high price. So it's definitely in the public interest to make sure there are as few of those as possible and that they're only in the hands of people who have the ability to understand why the friendly person offering them way too much money for their extension isn't just being nice.)
Re: Let's guess what Google requires in 14 days or they kill our extension
#404Earlier quoted context omitted.
Is there a provider that lets you send emails from free format users on your domain? With catch all addresses the mail goes into my other@domain account. I use a different email address per site. Now with gmail if I want to reply with that account I first need to create it as an alias. If I want to reply from my phone it even needs to be a full account. Is there any way to fix this? Short of using mutt and write the…
I can do this with fastmail, though fastmail is a subscription (like $5/month? IIRC, mine auto renews every 2 years so not sure). I have my primary email setup as @ .org. If you set your dns records correctly with them, that allows you to use without any ahead of time setup @ . .org. Setting a different tag where I have is can be done too, but you need to set those up individually. replying to emails, I can change to…
Fastmail lets you create wildcard identities like this so you can send from any username at any domain you have with them, but if you are sending from a third party app you usually still need to set up the sending identity in the app itself, which is annoying. The email programs I've tried haven't let me type arbitrary addresses into the 'from' line.
Many programs won't even automatically reply from the same alias the message was received at.
Re: Let's guess what Google requires in 14 days or they kill our extension
#405Earlier quoted context omitted.
I generally trust the major cloud providers a bit more than the companies focused on acting as a domain registrar. The domain registrars are generally a race to the bottom and focused on "add-on" sales as most people are shopping on price and that's going to reflect in the overall quality of the things that most people don't really notice like, y'know, security and validation. You don't hear a lot of stories about Am…
So use Google or Microsoft to register your domain? Doesn't that bring us back to the same potential problem though?
Google, Microsoft and AWS offer registrar services becuase it keeps you in their ecosystem for their higher margin products. THey generally offer competitive pricing for things like doamin registration and don't pull stunts like charging 2x as much for "privacy protection" or the even more dirty tricks like godaddy and other bottom feeders.
I recently trialed hosted email with AWS and while it is very basic it only costs 4/user/month - cheaper than my google apps service. I was also able to register a new domain at market rates and get dns automatically setup (I think?) on AWS as part of the service. Now because I tie my monthly AWS spend with my registrar I'm more confident I can get some customer service as well.
staying inside a vendor's ecosystem for very selective services can actually work out quite well, as long as the seller/customer incentives align and they are relatively commodity services.
Re: Let's guess what Google requires in 14 days or they kill our extension
#406It seems like everyone in here suggesting a switch to Firefox is missing the point. The Pushbullet team has already stated that having this Chrome extension pulled might mean the end of Pushbullet. So I'm going to trust that they know their own business well enough to make that statement.
I actually already use Firefox and their Firefox extension. But it won't matter that I'm savvy enough to do this if losing enough users from having the Chrome extension killed is enough to kill the larger business.
Re: Let's guess what Google requires in 14 days or they kill our extension
#407Earlier quoted context omitted.
Yeah, I actually think these sorts of strategies are clever. They're a way to protect normal users without outright barring power users from doing as they wish. macOS operates in a similar way. I really like how the difficulty increases depending on the task: • Want to allow one app through Gatekeeper? Instead of double-clicking the app icon directly, right click it and select "open". • Want to turn off Gatekeeper fo…
Except for those of us who are finding out about it only via a Hacker News comment. As happened with this user, who seems, you know, sufficiently a power user to need that info. Even a "if you know this site to be safe, please read this knowledge base article (link)" and buried in that, amidst all the reasons you shouldn't use untrusted certs, are the instructions.
> Even a "if you know this site to be safe, please read this knowledge base article (link)" and buried in that, amidst all the reasons you shouldn't use untrusted certs, are the instructions.
I don't think that's a bad way to go about it either, if it's sufficiently buried.
I'm primarily just thankful there's a workaround, hidden or not, given how many tech companies seem to respond to these things by disallowing them completely.
Re: Let's guess what Google requires in 14 days or they kill our extension
#408Earlier quoted context omitted.
I’m absolutely loving Firefox at the moment. I have temporary containers extension plus an extension to manage google and Facebook containers and the whole thing has become such a pleasurable experience. Combined with pihole it feels like I’m reclaiming the web back again. Such a blissful experience.
Yep, for me Multi-Account Containers and Tree Style Tabs are both killer features. Being able to load the same page with multiple accounts within the same browser and without losing everything after each session is a game changer for all sorts of situations, as is being able to keep dozens or even hundreds of tabs open without squeezing and squishing them unreadably into the top of the window like some kind of maniac…
And with temporary containers isolation pages that don't have their own dedicated containers get all their history deleted after they close (by default a few minutes later, so undo close tab works), just as if you'd opened each new tab in an incognito window.
Re: Let's guess what Google requires in 14 days or they kill our extension
#409As 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.…
That's what you got out of it? Google doing a good job? They sent an email with no guidance whatsoever. These guys went above and beyond what most developers would've done, which would have been to contact support until they get a clear answer. This only alienates the extension ecosystem. And this was the primary reason I switched to Firefox. Google is the new Microsoft. If I remember correctly, they started Chrome e…
Google sent an email saying they were asking for too many permissions. Pushbullet was asking to observe all website traffic. Google's email was objectively correct. I agree that the second rejection is more surprising, but yes, the first email seems like a case of Google doing a good job. I have very little sympathy for apps that ask for too many permissions.
Re: Let's guess what Google requires in 14 days or they kill our extension
#410I went through this on a side project and just let them kill off my public listing for now. I had the same thought process in terms of what I could change however my extension made use of InboxSDK and had access to GMail and I'm still concerned it might not make it through review...
Anyone else using InboxSDK in a Chrome extension and didn't get killed off by this change?
My extension hooks up the address book from a SaaS project (school information system) to GMail so faculty/staff can quickly look up parent contact information or send to special group email addresses that broadcast out to part or all of the school. The people using it were very happy to have it but I could conceivably go back to a private chrome extension if that is still allowed.