I'm not sure if the privacy protection claims made by Gmelius are true.
The plugin claims that I am being tracked via tracking pixel (or other image) embedded in emails and that the trackers know when I read my email and where I read it from (from my IP address). Is this true? Google server attachments through a proxy. This would prevent trackers from seeing my IP address. If assets are cached or pre-downloaded by Google, then trackers wouldn't know when I read their emails either.
Gmelius might even decrease privacy. The plugin includes a JavaScript file hotlinked to inboxsdk.com. It's possible that inboxsdk.com is tracking users this way.
Hi! Regarding your tracking remark, companies such as YesWare, MailTrack, MixMax (and so on) use pixel trackers. While such trackers are indeed made available through a Google proxy, the caching is overridable if you pass a no-cache header (http://blog.movableink.com/real-time-content-and-re-open-tra...).
The Inbox SDK makes easier the interaction with Gmail's UI and does not transmit or index data.
We (Streak) also built the InboxSDK. One explicit goal was that we do not track user data. We do however track usage of certain SDK features but we log no PII info. Happy to answer any other questions about it.
makes it seem like "None", but then, why would you give "Best Effort" email support or any at all if I don't have an account :)
Would suggest "1" is clearer.
There's also a couple of sections with hashmarks but no "Coming soon/Q1/etc." - presumably they follow on from the last section, but it's not immediately obvious what the hashing even means.
It also seems that you _do_ support Inbox by Gmail [1] - but I had to Google this, after nearly dismissing Gmelius because it makes no mention of Inbox on the site.
Why not just write an email client that has sugar for connecting to gmail? A lot of the gmail UI, to me, feels clunky. I switched my email client out to RainLoop as it has all of these features and it also allows me to connect to multiple inboxes at the same time, as well as different types of email servers.
The thing I lack in GMail (or other mail clients / services for that matter): the ability to rename conversations, as well as split/fork them according to my wishes.
Regarding the overriding of a message's design with the theme-based reset: Are bulk precedence messages excluded? As they are more likely to be "designed" (and spam-laden mails using CSS obfuscation are effectively filtered already by Gmail, and thus shouldn't be a primary concern), I would humbly suggest excluding bulk or transactional precedence (changing styles of an invoice could complicate a vendor's life when the "reset" version doesn't look like a standard invoice, for example) emails from this trickery.
Are emails with certain CSS or markup designed for accessibility excluded? If I carefully selected a high contrast design, with heavy stroke-weight fonts because my recipient is vision impaired, or I included specific ARIA landmark roles or other markup, and that markup's semantics are changed when the presentation is changed ... Is Gmelius going to blindly overrule these considered choices?
Can a user choose to exclude senders from having their styles overridden, or themselves change the overriding style sheet? Maybe their contacts list senders don't get overruled?
It's bad enough that ISPs inject themselves into web sites, please don't believe that you are harmlessly changing things for the better. Unless you've got serious design and accessibility knowledge that will ensure emails' design intent or accessibility for disabled users aren't affected, it seems like a needlessly complex and burdensome thing to manage.
Of course, maybe your target audience doesn't care, or knows that accessibility is affected and proceeds anyway. I certainly don't assign malicious intent to the extension, either way. I think it's a nice collection of user styles/user scripts, and if I wasn't already using a different client, I'd at least experiment with your additions (after turning off that vexatious CSS reset, ugh, that kind of thing really bothers me).
TL;DR: Well done. Please consider using bulk/transactional precedence (used by most legitimate commercial senders) and/or user overrides via whitelist or de-facto lists like contacts to exclude emails from having their styles overruled.
Thanks for your comment. When a user enables the feature that homogenizes the look of incoming emails w.r.t. its Gmail theme, Gmelius will not modify the style of well-formatted HTML emails (e.g., invoices, newsletters, etc.).
In addition to our "email scheduling" feature, email follow-ups and reminders will be soon available as well. With the latter features and other ones Gmelius currently offers (e.g., To-do App, email trackers detection and blocking, email templates), I'm sure your will find a place for Gmelius in your browser...
The plugin claims that I am being tracked via tracking pixel (or other image) embedded in emails and that the trackers know when I read my email and where I read it from (from my IP address). Is this true? Google server attachments through a proxy. This would prevent trackers from seeing my IP address. If assets are cached or pre-downloaded by Google, then trackers wouldn't know when I read their emails either.
Gmelius might even decrease privacy. The plugin includes a JavaScript file hotlinked to inboxsdk.com. It's possible that inboxsdk.com is tracking users this way.