3 ms·

Show HN: Move 1000 subscription emails out of your Gmail inbox in 10 seconds

10 points by makemills 6y ago

matlin 6y ago
I like the clear incentives i.e. to convert users to $1/month subscription rather than a free service that mines data. However, the "cant read your emails" part is somewhat misleading. Slimbox is still storing and processing all of the email headers, most importantly the 'to' and 'from'. This is understandable because it's as granular as you can get to provide this service. It just would be awesome if no data was transferred at all and instead ran in a client but there's the obvious trade-offs of speed, reliability, and availability.
- makemills 6y ago
  Appreciate this comment, and I'll try to explain a bit more of what takes place under the hood. The codebase of Slimbox can not read the content of your emails. Slimbox does not look at the content of the email or the header in fact to determine what is clutter. We instead use the Gmail API to effectively search for clutter. In a traditional IMAP-based environment, you're right that one would have to process email headers, but the Gmail API allows us to find clutter more efficiently – hence the bold claim regarding the speed of our service. The only user data that we store in our encrypted database is the user's email address, name, and a list of the senders. We only store this list of senders in order to allow for a UI to enable the user to easily manage senders (the only "read" operation). I agree it would be ideal if we didn't even have to store the "from" address, and we've looked into obfuscating this as data as well.
  - matlin 6y ago
    That all makes sense and I think you guys are absolutely doing the right things for what's available to you. I've dealt with the woes of making something relatively straightforward with the Gmail API and having to include a whole FAQ of why Gmail's "This app can ruin your inbox and steal your info" warning isn't accurate to how the app works. I am currently working on making building services with user data a much simpler process but until then keep up the great communication and transparency!
    - makemills 6y ago
      Thank you! I just checked out what you're building with Aspen. This looks amazing. Love the clear language too, and the idea that users get their own "tiny piece of the cloud" – such a clear concept. Reminds me of what Tim-Berners Lee is trying to do with Solid, but written in simple terms. Good luck!
igneo676 6y ago
I don't think I've ever seen a "Verified by Google" badge on a website. Looking into it, apparently you're under a different set of API usage policies and only a limited set of uses. I'm guessing according to this https://developers.google.com/terms/api-services-user-data-policy#additional-requirements-for-specific-api-scopes https://developers.google.com/terms/api-services-user-data-p... slimbox falls under the following 1. Native and web email clients that allow users to compose, send, read, and process email via a user interface 3. Applications that enhance the email experience for productivity purposes (such as applications for customer relationship management, delayed sending of email, or mail merge) Interesting stuff! I don't see where that badge comes from though. It implies to me more than "I accept the Google policies and have followed a couple hoops to allow usage of these APIs" and more of a relationship with Google
- makemills 6y ago
  If you scroll down that link you sent, you'll see where Google talks about recently introduced "Restricted Scopes". When we say that we are "Verified by Google", it is because we have been verified by Google as complying with their OAuth policies for Restricted Scopes. You can see the detailed requirement process here: https://support.google.com/cloud/answer/9110914#restricted-scopes https://support.google.com/cloud/answer/9110914#restricted-s... Note: I hope that doesn't come off the wrong way, there is literally a rigorous verification process that you must meet to be verified to connect to the Gmail API via OAuth. To your point about the badge: we believe Google should provide this type of badge to developers that have paid between $15,000 - $75,000 for the third-party security audit to be able to be even considered verified by Google. Unfortunately, all you get is an email and a fat receipt. So, we made this badge ourselves. I can understand your point of view that this implies more of a relationship with Google. That is totally fair. If you look at our back and forth with their Trust & Security team last year to secure this verification, you might feel like we had a relationship with them too, haha. We certainly don't want it to be problematic or misleading. We do think it's important for users to realize that our app is indeed verified and safe to connect to.
  - saaaaaam 6y ago

10 points by makemills 6y ago

I like the clear incentives i.e. to convert users to $1/month subscription rather than a free service that mines data. However, the "cant read your emails" part is somewhat misleading. Slimbox is still storing and processing all of the email headers, most importantly the 'to' and 'from'. This is understandable because it's as granular as you can get to provide this service. It just would be awesome if no data was transferred at all and instead ran in a client but there's the obvious trade-offs of speed, reliability, and availability.

makemills 6y ago
Appreciate this comment, and I'll try to explain a bit more of what takes place under the hood. The codebase of Slimbox can not read the content of your emails. Slimbox does not look at the content of the email or the header in fact to determine what is clutter. We instead use the Gmail API to effectively search for clutter. In a traditional IMAP-based environment, you're right that one would have to process email headers, but the Gmail API allows us to find clutter more efficiently – hence the bold claim regarding the speed of our service. The only user data that we store in our encrypted database is the user's email address, name, and a list of the senders. We only store this list of senders in order to allow for a UI to enable the user to easily manage senders (the only "read" operation). I agree it would be ideal if we didn't even have to store the "from" address, and we've looked into obfuscating this as data as well.
- matlin 6y ago
  That all makes sense and I think you guys are absolutely doing the right things for what's available to you. I've dealt with the woes of making something relatively straightforward with the Gmail API and having to include a whole FAQ of why Gmail's "This app can ruin your inbox and steal your info" warning isn't accurate to how the app works. I am currently working on making building services with user data a much simpler process but until then keep up the great communication and transparency!
  - makemills 6y ago
    Thank you! I just checked out what you're building with Aspen. This looks amazing. Love the clear language too, and the idea that users get their own "tiny piece of the cloud" – such a clear concept. Reminds me of what Tim-Berners Lee is trying to do with Solid, but written in simple terms. Good luck!

igneo676 6y ago

I don't think I've ever seen a "Verified by Google" badge on a website. Looking into it, apparently you're under a different set of API usage policies and only a limited set of uses. I'm guessing according to this https://developers.google.com/terms/api-services-user-data-policy#additional-requirements-for-specific-api-scopes https://developers.google.com/terms/api-services-user-data-p... slimbox falls under the following 1. Native and web email clients that allow users to compose, send, read, and process email via a user interface 3. Applications that enhance the email experience for productivity purposes (such as applications for customer relationship management, delayed sending of email, or mail merge) Interesting stuff! I don't see where that badge comes from though. It implies to me more than "I accept the Google policies and have followed a couple hoops to allow usage of these APIs" and more of a relationship with Google

makemills 6y ago
If you scroll down that link you sent, you'll see where Google talks about recently introduced "Restricted Scopes". When we say that we are "Verified by Google", it is because we have been verified by Google as complying with their OAuth policies for Restricted Scopes. You can see the detailed requirement process here: https://support.google.com/cloud/answer/9110914#restricted-scopes https://support.google.com/cloud/answer/9110914#restricted-s... Note: I hope that doesn't come off the wrong way, there is literally a rigorous verification process that you must meet to be verified to connect to the Gmail API via OAuth. To your point about the badge: we believe Google should provide this type of badge to developers that have paid between $15,000 - $75,000 for the third-party security audit to be able to be even considered verified by Google. Unfortunately, all you get is an email and a fat receipt. So, we made this badge ourselves. I can understand your point of view that this implies more of a relationship with Google. That is totally fair. If you look at our back and forth with their Trust & Security team last year to secure this verification, you might feel like we had a relationship with them too, haha. We certainly don't want it to be problematic or misleading. We do think it's important for users to realize that our app is indeed verified and safe to connect to.
- saaaaaam 6y ago