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.
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
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.
Annoyingly thunderbird allow but not gmail, so I wanted to use thunderbird. But it doesn't easily allow archive-ing, like GMail does.
Contrived but still easy solution: tag all your inbox you want to go through with two labels SetA and SetB. Open SetA in thunderbird, using `a` to remove emails from SetA as if you archived. Then in GMail, use the search `label:setB - label:SetA` and it gives all the emails you wanted to archive. Archive those and done
GabrielAI (https://getgabrielai.com) can filter your emails given a GPT prompt and then make a special action, like drafting a reply or apply a label.
I am now introducing a digest if emails. So that every 6 hours (or whatever time) you receive an email with the summary of all the unread emails in your inbox.
It is free for now, but the summary feature is hide by a feature flag.
If you are interested, I can ungate your account.
ah yes, since that's what I want all my communications fed through
Unfortunately there doesn't seem to be any quick way of toggling between threaded and non-threaded.
The queries are the same as what you'd type into the Gmail search bar to filter emails so you can test them out in Gmail and then add them to the list. I've added a comment to the gist with an image showing the trigger to run it daily. You can run it manually from the Google Script editor too for testing.
Edit: Forgot to mention I removed a bunch of queries and only left a few in as examples.
Perhaps I will look into developing more serious extensions in the future, it was actually a quite pleasant experience.
Is it fair to say that developing extensions for Chrome is comparable?
The latter two have API differences from Chrome - e.g. using the `browser` namespace for extension APIs instead of `chrome`, and Promises instead of callbacks for async functionality - but for the sake of compatibility they also implement Chrome's version of these APIs [1][2], so if you just use the Chrome APIs and don't venture into the more browser-internal APIs such as bookmarks, the same extension code will likely run everywhere, with some specific differences/incompatibilities noted in the docs below.
If you were to create a new cross-browser extension today, one of the main issues would be that Chrome Web Store no longer accepts new MV2 extensions so you have to use MV3 for it, but MV3 in Firefox currently has some serious usability issues around permissions which are being addressed in upcoming releases [3] so you'll want to use MV2 for it, however this likely just means you'd need to have separate MV2 and MV3 manifest.json files which get bundled into different zip files for submission to the different browser extension stores. I had to do this recently for one of my extensions [4]
[1] https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
[2] https://developer.apple.com/documentation/safariservices/saf...
[3] https://blog.mozilla.org/addons/2024/05/14/manifest-v3-updat...
[4] https://github.com/insin/control-panel-for-twitter/commit/59...
Yes it's pretty similar. There just some minor API differences. e.g
Chrome - chrome.tabs.query(queryInfo) Firefox - browser.tabs.query(queryInfo)
So you could easily port any firefox extension to chrome and vice-versa using the same codebase.
Also, I seem to have a lot of attachments, like a lot, and I can't clean them up, because gmail doesn't let me see the datasize clearly.
I downloaded my mail as an export, I think EML, I wanted to build a mail list myself to see attachments with a python script, but I think gmail doesn't export all the metadata of how mail are chained with each other and such.
Unfortunately, I think your extension cannot really do statistics on an existing mailbox, to see a map of mail counts per domain.
You're right Gmail does not show the datasize clearly, but to get emails with large attachments, you can use search filters like: "larger:15M", where 15M is 15 megabytes. It's not exactly what you want but might help
From there is a bit up to you and depending on actually what data you get.
But I had a reasonable simple time with parsing it and getting data out of it while building https://getgabrielai.com
How did you go about the unsubscribe functionality? Also, I think I saw that Gmail has that feature themselves now.
As at Febuary, Gmail introduced new guidelines for bulk email senders to make it easy unsubscribe from by adding a value for "List-Unsubscribe"
https://support.google.com/a/answer/81126?hl=en&visit_id=638...
So unsubscribing is simply a POST request to the value of this email header (List-Unsubscribe) - which is a link and comes as part of the email headers in the Gmail API response
The alternative approach is to parse the content of the email and use regex to get the unsubscribe link using the likely words. e.g links with words like: unsubscribe, opt-out etc..
Yes, Gmail has the unsubscribe functionality. Unfortunately, you cannot mass unsubscribe. If you have over 100 unwanted subscriptions you would have to unsubscribe from each one at a time.
Hope that helps you
That is a valuable info. Thank you!
>The alternative approach is to parse the content of the email and use regex to get the unsubscribe link using the likely words. e.g links with words like: unsubscribe, opt-out etc..
That's how I started to implement it. But then again you will need to go through every unsubscribing process manually...
Best of luck with your extension!
I'm just very wary of giving closed source extensions "the keys to the kingdom" and complete access to all of my eamil.
> With this Chrome extension, emails are not sent to any external servers.
Don't you have to send an "Unsubscribe" email? To an external server?
> All calls to the Gmail API happen locally on your device.
Aha, you mean in comparison to a "SaaS" where these things happen on a third party server...
So generally in order to actually help you mass unsubscribe from unwanted emails, most email cleaning tools handle your email data on their server. The process of parsing email data to fetching unsubscribe links or unsubscribe instructions etc..
So there's a trust problem where some tools have been caught selling user data: https://www.nytimes.com/2017/04/24/technology/personal-data-...
So the goal here with InboxPurge is to move all these processes related to your email data to your device(browser), ensuring your privacy.
> ensuring your privacy
But only if we trust the extension author (and the authors of all of the transitive dependencies) to be neither malicious nor incompetent… right? I don’t know of resources that explain exactly what actions each permission in the manifest grants the extension to perform, nor a characterization of the execution environment of extensions. Do all browsers handle these matters similarly? Does some browser provide any more isolation or sandboxing than any other?
Edit: by no means did I mean to throw shade or cast doubt on your extension, I’m just grumpy in general and in particular about browser extensions, since nowadays “the browser is the OS”.
[0] or maybe there’s a gmail api that does it for you, and this extension actually can’t make arbitrary http connections?
So the way most email cleaning tools work is:
- Scan your emails for all your subscriptions - via Gmail API - Each subscription has a link, that link is what is used to unsubscribe the link can either be in the email header or email body - This can be a POST request or a GET request, in some complex cases a mail send to unsubscribe - With this link for each mailing list, mass unsubscription can happen
So the main difference here is, other tools do this on the third-party servers. InboxPurge does this on your browser/device (specifically the email scanning bit). Making HTTP requests to the Gmail API from your device.
Yes, it's also possible to build a browser extension that does this on a third-party server.
*Other things happen depending on the email cleaning tool but I've tried to simplify to explain better.
Hope it was helpful.
You can find the list of browser permissions a Chrome extension can request for here: https://developer.chrome.com/docs/extensions/reference/manif...
For instance at last look I had north of 40k emails from ebay. I can't just delete them all as I want to keep anything that is related to either an order I placed or an item I sold. I have went back 15+ years before to find part numbers before.
But I have no interest in the 38000+ marketing emails from them. (I kinda wanna keep getting them but don't want them a week after I get them.
And if I recall correctly the emails have often come from the same accounts so I can't even filter by that.
I developed GabrielAI (https://getgabrielai.com) an assistant for Gmail.
You provide a GPT prompt and it scan all the new emails. If the email matches the prompt it will do an action. Either drafting a reply for you or set a label.
It will be trivial to go through the whole inbox. But expensive.
It is a nice feature to add though...
I would love to preview some emails (are these just promos or do they include receipts?), perhaps by hovering or clicking the sender.
Yes this is the actual working flow. When you click on a sender it should show the emails sent by that sender. Unfortunately, at the moment there's a bug. I'm waiting for a Chrome store review approval for the version with the fix to be published.
I will reply here once it's approved
I used https://screen.studio/ for the showcase videos and for the YouTube video I used a combination of Canva/Eleven Labs + Some manual mouse zooming
But just in case you use any of these browsers, it works on other chrome-based browsers aside from Chrome: - Brave - Opera - Edge - Opera GX
its a chicken and egg problem that you as a developer can help tilt in favour of an open web. If your product works on firefox as well, your customers wont be forced to choose chromium, then stats otherwise will say there are more chromium users.
> while ensuring privacy
...is rather contrary to gmail's whole business model.
In cases where you want to mass delete older emails that you previously subscribed to, you might find InboxPurge useful.
> InboxPurge will only use your Gmail data accessed via the Gmail API to read or control Gmail message metadata (including attachment information), headers, and message content, to enable you to process (delete/move/archive/unsubscribe from) emails. It will not share this Gmail data with others unless required by law.
But how can you share data if required by law when in a previous paragraph you say you are not collecting this data and it never leaves my device?
I hope that answers your question.
Edit: Just to add more context. The Google Oauth verification team requires that statement in the privacy policy.
And which jurisdiction is this service governed in?
I think there is just many ambiguities which do not seem clear to me at all.
It's technically not possible from InboxPurge's perspective. As there'd be no email information to share
If required by law to share that information, what steps would you take to fulfill that legal requirement?
Is the implication that despite you being legally obligated to do so, you would in actuality have no method for sharing said information, and would therefore have nothing to offer law enforcement?
I've added edit to explain why that particular statement is in the privacy policy
It's technically not possible from InboxPurge's perspective. As there'd be no email information to share.
I don’t think I would touch it anymore.
"All these processes happen on your browser(device). The extension uses the Gmail API locally on your browser to perform all the necessary tasks. Your emails never get sent to any external server."
Hope you give it a try.
Otherwise I think a lot of people would be easily deterred by the current/similar statements.
Thank you for sharing and taking the time to answer questions though.