51–55 of 55 posts
So it's not an email client, it's some app exclusively for Gmail and Google Inbox (using OAUTH for authorization ), not that it lessen the value of the app in anyways but it's important to note.
Earlier quoted context omitted.
And if you use something like Fluid.app you can create an app per email account and even have a separate app for your Calendar like me! Unfortunately Fluid.app is poorly maintained and based on Safari...
Check out https://github.com/jiahaog/nativefier , it's like fluid in that it builds a standalone app for any website, incl. support for badges and segregated cookies.
For some odd reason I couldn't get the badges to work well for gmail though.
Earlier quoted context omitted.
Check out https://github.com/jiahaog/nativefier , it's like fluid in that it builds a standalone app for any website, incl. support for badges and segregated cookies.
I've used nativefier to create apps for Gmail (two separate accounts), facebook, trello, and soundcloud. Even though it feels ridiculous to create a huge app to just wrap a website, it works quite well. For some odd reason I couldn't get the badges to work well for gmail though.
Electron apps are very big in size. It's like having multiple instances of Chrome running. Remind me of Java apps all over again.
Looks like the Google API client ID and client secret are stored in clear text shipped with the released app: WMail.app/Contents/Resources/app/bin/shared/credentials.js , and this seems to be used in authentication with Google: https://github.com/Thomas101/wmail/blob/master/src/main/Auth...
There's not really anything you can do about this unless you want Wmail to have to stand up a server to authenticate with, at which point you're no really getting any additional security because Wmail still needs to store some sort of credential on your machine for persistent login that an attacker could steal to authenticate with Wmail on their own machine. An attacker would have to steal your access token stored lo…