5 ms·

Part 3: How does DarwimMail actually work? So what happens exactly is: The user logs into DarwinMail.app, DarwinMail makes a login request to Google's servers,

Part 3: How does DarwimMail actually work? So what happens exactly is: 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 :)

teleclimber 7y ago
Is your product open source? Because for this kind of thing it's really hard to trust unless it's open and self-hostable. 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.
- DarwinMailApp 7y ago
  It's not open source at the moment no. 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?
  - teleclimber 7y ago
    Yes, if you make it Open Source and possible to self-host it goes from DOA to definitely possible. Would have to explore more, like how it's written, the community around it, etc... before I really commit. Hopefully you can still make a living. I suspect "open source + commercially hosted" is a good model for something like this?
    - 1123581321 7y ago
      You are asking him to do a ton of work and commit to never charging you for anything on the off chance that you might condescend to use his software. It seems like it would be easier for you to just not evaluate new mail clients.
      - DarwinMailApp 7y ago
        It is so kind of you to defend my position. 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!
      - teleclimber 7y ago
        I'm just suggesting that a service that touches email would benefit from being easier to trust. I never said he should commit to never making money or anything close to that. Like you literally invented that. In fact I suggested he look into the open source + hosted business model. Ghost seems to be doing alright with it: https://blog.ghost.org/5/ https://blog.ghost.org/5/ > 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. https://roundcube.net/ https://roundcube.net/
        DarwinMailApp 7y ago
        You have certainly given me plenty to think about. I thank you :) I love receiving new 'outside of the box' ideas that will increase DarwinMail's appeal :)
        1123581321 7y ago
        You said “Yes, if you make it Open Source and possible to self-host it goes from DOA to definitely possible.[...] Hopefully you can still make a living. I suspect "open source + commercially hosted" is a good model for something like this?” 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.
  - uniformlyrandom 7y ago
    That was my biggest concern as well. I am sure you do not do that, it it would have been so easy to funnel my data (or metadata) to your servers. Open-sourcing and authenticating the client code would resolve this issue for me.
    - DarwinMailApp 7y ago
      That is an interesting point and I very much appreciate your opinion. I will think about it :)
mdeeks 7y ago
Saying that none of the "email data" is stored on your servers is a common way mail clients deflect from the real truth that people are interested in. Our email data traverses through your servers and is stored in memory is it not? 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."
- DarwinMailApp 7y ago
  Hello, and thank you for your comment and for explaining how you feel. 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 https://www.linode.com/security
ddalex 7y ago
I think there is at least one variant of the OAuth2 flow that doesn't require the use of servers to complete the authorization. I know Implicit Grant is broken in some ways, but Google supports it: https://developers.google.com/identity/protocols/OAuth2UserAgent https://developers.google.com/identity/protocols/OAuth2UserA... 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?
- DarwinMailApp 7y ago
  Thank you very much for your input here. You are 100% correct. It is the same implementation that DarwinMail uses. -- 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://developers.google.com/gmail/api/auth/about-auth https://support.google.com/cloud/answer/9110914 https://support.google.com/cloud/answer/9110914

teleclimber 7y ago

Is your product open source? Because for this kind of thing it's really hard to trust unless it's open and self-hostable. 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.

DarwinMailApp 7y ago
It's not open source at the moment no. 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?
- teleclimber 7y ago
  Yes, if you make it Open Source and possible to self-host it goes from DOA to definitely possible. Would have to explore more, like how it's written, the community around it, etc... before I really commit. Hopefully you can still make a living. I suspect "open source + commercially hosted" is a good model for something like this?
  - 1123581321 7y ago
    You are asking him to do a ton of work and commit to never charging you for anything on the off chance that you might condescend to use his software. It seems like it would be easier for you to just not evaluate new mail clients.
    - DarwinMailApp 7y ago
      It is so kind of you to defend my position. 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!
    - teleclimber 7y ago
      I'm just suggesting that a service that touches email would benefit from being easier to trust. I never said he should commit to never making money or anything close to that. Like you literally invented that. In fact I suggested he look into the open source + hosted business model. Ghost seems to be doing alright with it: https://blog.ghost.org/5/ https://blog.ghost.org/5/ > 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. https://roundcube.net/ https://roundcube.net/
      - DarwinMailApp 7y ago
        You have certainly given me plenty to think about. I thank you :) I love receiving new 'outside of the box' ideas that will increase DarwinMail's appeal :)
      - 1123581321 7y ago
        You said “Yes, if you make it Open Source and possible to self-host it goes from DOA to definitely possible.[...] Hopefully you can still make a living. I suspect "open source + commercially hosted" is a good model for something like this?” 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.
- uniformlyrandom 7y ago
  That was my biggest concern as well. I am sure you do not do that, it it would have been so easy to funnel my data (or metadata) to your servers. Open-sourcing and authenticating the client code would resolve this issue for me.
  - DarwinMailApp 7y ago
    That is an interesting point and I very much appreciate your opinion. I will think about it :)

mdeeks 7y ago

Saying that none of the "email data" is stored on your servers is a common way mail clients deflect from the real truth that people are interested in. Our email data traverses through your servers and is stored in memory is it not? 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."

DarwinMailApp 7y ago
Hello, and thank you for your comment and for explaining how you feel. 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 https://www.linode.com/security

ddalex 7y ago

I think there is at least one variant of the OAuth2 flow that doesn't require the use of servers to complete the authorization. I know Implicit Grant is broken in some ways, but Google supports it: https://developers.google.com/identity/protocols/OAuth2UserAgent https://developers.google.com/identity/protocols/OAuth2UserA... 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?

DarwinMailApp 7y ago
Thank you very much for your input here. You are 100% correct. It is the same implementation that DarwinMail uses. -- 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://developers.google.com/gmail/api/auth/about-auth https://support.google.com/cloud/answer/9110914 https://support.google.com/cloud/answer/9110914