I'd feel way more comfortable if this would be an app or a browser add-on that would handle everything locally, without sharing the access token with your servers.
PS: WE NEVER store any email data that belongs to you. Google has verified our compliance via a lengthy audit!
Manage mailbox labels — this allows DarwinMail to add and remove labels (inbox, snoozed, spam, etc) to your emails.
Manage your sensitive mail settings — this allows DarwinMail to update settings such as your forwarding address and aliases.
Manage you basic mail settings — this allows DarwinMail to update settings such as your signature and out of office reply.
View and modify but not delete your email — this allows DarwinMail to create your email (when you use the compose functionality), modify you email, and send your email (when you click the send button). This also allows you to update and save drafts.
Please feel free to check out the following official documentation from Google for further reading.
I like your point. It's fascinating.
Right now, I need to look into the implications of running DarwinMail as a browser extension would be. To be sure your security would be maintained, the core functionality is not lost and DarwinMail remains usable (landing page with about, features, testimonials, pricing etc).
Thank you for your suggestion!
I'd not say - go and build this as an extension on mobile; but if you have the code built to run as an extension, it should be fairly quick to repackage it as a standalone mobile app, i.e. get a dedicated instance of the browser that runs your app).
Another successful example of this model is LastPass - they deliver the functionality via browser extensions and mobile apps, but they handle all the payment and marketing and CRM via their own product site.
Thank you for the feedback!
The user logs into DarwinMail.app, DarwinMail makes a login request to Google's servers, Google logs the user in, DarwinMail asks for the users emails at which point this data is rendered in the user's browser. None of this email data is stored on DarwinMail's servers. There is no need! Think of all the space it would take up and the time that would be spent retrieving the data.
Google's API & servers do the heavy lifting. DarwinMail allows you to view your emails just like Inbox, and hopefully provides (or will soon provide) the same kind of functionality :)
Even if you say you don't need to store emails, there is still a chance of leaks via logging systems or simply programmer errors, or some caching layer. It's likely your security protocols aren't as robust as Google's. (You mention "https" as the primary reason this is secure. Much wow.)
Given the importance of email there is no way I could trust another closed system with my email. I'm sorry if that sounds harsh, I also want to see alternative email frontends because gmail isn't cutting it.
You make a very good point, and I see where you are coming from.
I personally have a hard time trusting other products with my data too. That's why I'm trying to be as transparent as possible with DarwinMail.
If I were to make the product open source, would you consider using it then?
Hopefully you can still make a living. I suspect "open source + commercially hosted" is a good model for something like this?
Thank you so much. I'm so happy that you understand as it can be difficult for a creator to explain such things :)
I really appreciate it!
In fact I suggested he look into the open source + hosted business model. Ghost seems to be doing alright with it:
> It seems like it would be easier for you to just not evaluate new mail clients.
There are plenty of OSS mail clients. I was just looking at RoundCube the other day. It's actually pretty slick as far as traditional email clients go.
I thank you :) I love receiving new 'outside of the box' ideas that will increase DarwinMail's appeal :)
That means that you would not consider using by it unless you could use it for free, presuming you wouldn’t qualify for a commercial license. I only summarized what you said.
Thank you for understanding :)
That's why I mentioned the OSS + hosted version. It would allow to be more open while still making money on the hosted version. Those who are very concerned about privacy can self-host, and those who think self-hosting is too hard (that's many people) can pay to use your hosted version.
See Ghost as a success story that works that way:
That's quite an interesting concept! It would alleviate users concerns :)
I like it!
Ghost has done very well in recent years. I will read up on this.
Open-sourcing and authenticating the client code would resolve this issue for me.
I will think about it :)
Additionally you have our access tokens correct? With those you have effective access to all of our email data. They are effectively a password. Worse actually since they bypass 2FA. If you leak those on accident or decide to use one from your home PC, you have access to all of our email data.
The statement "None of this email data is stored on DarwinMail's servers" remains technically true, but does not address the real scope security issue most users are worried about.
DarwinMail looks amazing and I'd love to use it, but until these questions above are answered or obviated via open-sourcing it, I don't think many users will be comfortable. My company admin policy explicitly denies your app for these reasons by the way:
"Error: admin_policy_enforced
Access to your account data is restricted by policies within your organization. Please contact administrator for more information."
What you have said is true but I'm not sure you fully understand how DarwinMail works.
I hope to alleviate your concerns somewhat by explaining.
DarwinMail does request and use your individual access tokens from Googles API servers in order to retrieve your emails.
All the displaying is done on your browser. Any action you take for your emails is done on your browser. Any email you type and send it handled in your browser.
Sure, DarwinMail is hosted on a server (Linode) but that's just to store the DarwinMail website on the internet so you can visit it.
Even without open sourcing the code, you can still see all of the code that does the above managing of your emails in your own browser! Just right click -> Inspect -> Open up the sources tab and you can see it all! It's not hidden!
In fact, search for Sarge's posts on this thread... that gentleman was looking through the code, reporting bugs to me and telling me how to fix them!
Furthermore, Linode does not take security lightly and are trusted by many many companies and individuals. See for yourself: https://www.linode.com/security
You also say this has been audited by Google. Mind if I ask under which program, and how did you get Google to audit it?
--
This document explains how to implement OAuth 2.0 authorization to access Google APIs from a JavaScript web application. OAuth 2.0 allows users to share specific data with an application while keeping their usernames, passwords, and other information private. For example, an application can use OAuth 2.0 to obtain permission from users to store files in their Google Drives.
This OAuth 2.0 flow is called the implicit grant flow. It is designed for applications that access APIs only while the user is present at the application. These applications are not able to store confidential information.
In this flow, your app opens a Google URL that uses query parameters to identify your app and the type of API access that the app requires. You can open the URL in the current browser window or a popup. The user can authenticate with Google and grant the requested permissions. Google then redirects the user back to your app. The redirect includes an access token, which your app verifies and then uses to make API requests.
--
DarwinMail basically sits on top of Google's servers and displays the data in the same manner (and in time using the exact same features + more) as Inbox did.
Darwin does not store any of your email data whatsoever. In fact, if it did, Google would have asked me to audit the tool - but they instead granted me Google verification. It took them almost a month to break down DarwinMail and make sure it did not store any user email data.
Further reading: https://developers.google.com/gmail/api/auth/about-auth https://support.google.com/cloud/answer/9110914
What does that mean?
DarwinMail basically sits on top of Google's servers and displays the data in the same manner (and in time using the exact same features + more) as Inbox did.
Darwin does not store any of your email data whatsoever. In fact, if it did, Google would have asked me to audit the tool - but they instead granted me Google verification. It took them almost a month to break down DarwinMail and make sure it did not store any user email data.
If you have any questions on the verification process, please ask me! Or look here at the official Google documentation.
https://twitter.com/joeytawadrous https://support.google.com/cloud/answer/9110914
Because each of the participants has only a fraction of your e-mails.
However, I won't be giving any third parties access to DarwinMail ;)
I didn't give it out to anybody else that Google. Google I trust implicitly because they host the server, so the email is already read by them before reaching the interface. Thunderbird stores email locally doesn't need to push it out. I wouldn't give Facebook ever access to my email account.
Why should I give Darwin access AS A WEBSITE when it's not clear to me that they NEED to run their SERVER? If the interaction is done through JS entirely and the whole thing runs in the browser between me and Google, they can easily pack it as an extension.