Hacker News Reader

Comment by lxe | Hacker News Reader

When you say "locally" it usually means it uses the browser's API to navigate the inbox and perform whatever actions necessary. This extension instead requires pretty intrusive permissions, just like the alternative competitors (which are under fire for selling your data).

I appreciate that you state that "data doesn't leave your device", but the whole point of "local" extension is that I don't have to take your word for it.

View on HN

"Locally" here means, calls to the Gmail API are triggered directly from your browser(device) not on any third-party servers.

I totally understand your concern. Unfortunately, to perform those actions(unsubscribe/delete etc..) on your behalf while using the API, those "intrusive" permissions are required. If it wasn't needed, Google oauth verification team would not have approved.

I tried to explain the usage for each permission here: https://www.inboxpurge.com/permissions

But if you are a browser extension I would have expected you wouldn't need your own permissions at all: you would either be scripting the UI of the client to accomplish your goals or stealing its authentication.

Stealing the authentication is arguably way more invasive than this strategy.

I mean, we can argue lots of things, I guess ;P, but an extension already has access to that authentication token, and pretending otherwise is a bit... "performative"? The expectation I have with an extension--as someone who used to manage an entire ecosystem of such extensions of native software for a decade--is that it is a true extension of the application that it is extending, similar to if we had the original source code to patch.

Tbh I didn't really consider this approach as I didn't think it was possible (that's if it is). Also I'm not so comfortable with hijacking authentication session. I very much prefer making the user actually grant permissions to the required scopes and making it clear what the access is used for.

As someone with a lot of experience in working on a Chrome extension that interacts with Gmail specifically, there are two reasons I'd expect an extension like OP's to integrate with the official Gmail API instead of poking the Gmail web app's internal API directly: 1) the official Gmail API is stable, documented, and doesn't take reverse-engineering to use, and 2) the Gmail web app's internal API is pretty strongly rate-limited for some actions.

If an extension only does actions involving the UI and data visible on screen within the Gmail webpage at a regular user pace, then I wouldn't expect it to strictly need the official Gmail API much. But this would mean the extension can't operate on emails that aren't on the current visible page, etc.

Reply on news.ycombinator.com