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

221–230 of 811 posts

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

#221

Post by shadowgovt »

lostinroutine wrote: post #180
shadowgovt wrote: post #147

Earlier quoted context omitted.

Redirects shouldn't compromise the CORS / XSRF security model, which is the key item of concern from a Chrome Extension standpoint. Like if pushbullet.com redirects to foo.com, the crex is now looking at the foo.com page and its permissions will apply accordingly.

Maybe I'm naive but what if pushbullet.com was just running a server-side fetch and returning the result? That would bypass CORS, essentially acting as a proxy server.

That's a great question, and it's not limited to Chrome extensions.

In general, for any resources that don't require credentials to access, pushbullet could hypothetically serve them at like pushbullet.com/proxy/gmail.com/favicon or something. But resources requiring credentials are another thing entirely.

In general, the thing that prevents a third-party server from MITM'ing your interactions with a target server is a combination of domain names and SSL certificate. That doesn't prevent a site from trying to get you to let it act as a MITM, but it prevents the site from acting as the MITM while claiming it's something else.

As a concrete example, let's imagine pushbullet.com wanted to act as MITM for your GMail account. If it has your username and password, then (handwaving here; GMail's authentication model is complex) it could do that; it could forge well-crafted requests that look like they come from your browser, and get proper responses back.

But if it doesn't have your username and password, there's not a lot it can do. Your browser won't give pushbullet.com cookies scoped to gmail.com, and if pushbullet tries to ask you for your password, they can only do so much to make it look like GMail's the one asking (SSL certs make it hard for pushbullet to try and forge a GMail front-page with a gmail.com domain). It can still happen, but "user was tricked into ignoring the domain name and gave their password to another service" isn't something web security models can fix.

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

#222

Post by the_gipsy »

adverbly wrote: post #165
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 hope the developer finds another load of permissions they can tighten up, resubmits, and is approved. You're missing the point here. The developer isn't given any guidance on what needs tightening. This shouldn't be guess and check. These rules impact this developer's livelihood. They should be well defined, documented, and communicated.

> These rules impact this developer's livelihood.

Let this be the millionth lesson of "the perils of building on a platform instead of on a protocol".

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

#223

Post by tonystubblebine »

I'd been in a similar issue on the Android store and found that the best solution was to try to game whatever bot is flagging you. Support was completely unable to provide clarity and getting escalated by internal Google employees just led to more unhelpful emails from higher levels of support.

I was positive that I was in compliance but I could also see that a bot was flagging something. So I kept tweaking code and resubmitting. Eventually what worked was taking the offending code block and hiding it at the server level.

It's such a face palm. I literally call out to the server to run some logic that should be completely safe to run in the app.

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

#224

Post by ridewinter »

As the developer of an exposure notification app put on ice by Apple-Google, it's due time to take back the freedom of the internet that made it so powerful in the beginning.

Is there anything happening around an all-web app phone? Seems like all the pieces are there..like native functionality in JavaScript with certain extensions.

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

#225

Post by necovek »

jschwartzi wrote: post #189
dylz wrote: post #161

Earlier quoted context omitted.

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…

Your router's self-signed cert can be imported into your browser and trusted from thereon — that will also stop any potential attacks from someone pretending to be your wifi ap nearby because I am pretty sure you are not double-checking the cert fingerprint every time you visit the router's admin interface. Provided you were not MITMed once you added the cert in the first place :)

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

#226

Post by sudoit »

foobarbazetc wrote: post #131

lol. We have the same problem, but on the Google Play Store. We have an brand name app used by millions of people. We uploaded an update where the only change was a new Firebase library. Google rejected the update for vague reasons (“violation of Google Play policies” but not telling us which one). Appealing the rejection, the CSR just pasted the vague policy thing back at us. We asked for more information and they j…

Had the same problem when I made a fairly successful app in university. Whole account got deleted for a “3rd strike” meaning “3rd resubmission.”

I’ve made a new account and their AI black box still doesn’t realize it’s me...

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

#227

Post by cpascal »

ashtonkem wrote: post #198
cpascal wrote: post #150

Earlier quoted context omitted.

One worry about tying your identity to your own domain, is the security of your identity (aka your domain) hinges on the security of your registrar. If a bad actor can socially engineer their way into controlling your domain, your entire identity is compromised. Here's a blog post about this nightmare happening to someone: https://medium.com/@N/how-i-lost-my-50-000-twitter-username-...

I agree that that would be catastrophic, but I’m not convinced that using custom DNS changes my risk factor. If someone took over @gmail.com, they could do as much damage as they could by taking over @ .

If you use an email provider to host your domain's email (e.g. Fastmail, GSuite, etc.), I believe you're actually increasing your risk factor.

The security of your identity will depend on your registrar, your DNS provider, and your email provider.

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

#228

Post by blihp »

AlphaWeaver wrote: post #202

I'm also an extension developer, and Google has done this to me a few times too. We request permissions specifically for what we need, and our extension is unlisted and can only be installed from our website. Google is a bully, and they use their size and the threat of permanently removing access to your Google Account (and family photos) to terrorize small players without cause. How many people would Google need to…

Not going to happen. This is an issue people have been raising for at least the better part of a decade... don't expect anything to change now.

A more productive approach would be to focus on web browsers that allow you to do what you need to and let Google fix what they need to encourage you back. I know, most extension developers will say 'we can't do that because it's where the users/customers/whoever are'. But as long as you encourage their bad behavior by supporting the platform, expect the bad behavior to continue since it's not hurting Google. As a result, it's just a cost of doing business on Google's platform which is unlike to change for the better.

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

#229

Post by freehunter »

dylz wrote: post #176
freehunter wrote: post #173

Earlier quoted context omitted.

And instead many people will just do a Google search for "Chrome [insert error here]" and run the first command they find, while people like me will say "okay I'll just Firefox where I can click past this warning".

For what it's worth I've always been able to click straight through a self-signed cert on Chrome - in fact I just did it right now to log in to something internal. I am a nearly 50-50 split Firefox/Chrome user. Are you sure you aren't sending HSTS headers that demand the site be TLS in some way? Also, have you considered the slightly-saner way of doing it, which is making an internal self-signed CA, trusting that int…

If it was HSTS it wouldn't load in Firefox, would it?

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

#230

Post by tracker1 »

RcouF1uZ4gsC wrote: post #130
bcrosby95 wrote: post #105

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.

I know some will reject the idea.. but if Google is your domain registrar, they'll do email forwarding without an extra charge.

I've started using @mydomain where the is the website/service I've registered for... doesn't help with my existing stack though.

Post reply on HN