Show HN: Move 1000 subscription emails out of your Gmail inbox in 10 seconds | Hacker News Reader

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

slimboxapp.com

10 pointsmakemills10 comments

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-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

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-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.

You might want to reconsider that badge.

https://www.google.com/permissions/logos-trademarks/

“Google G: Third parties are not permitted to use the Google G. It’s reserved for Google products and marketing materials.”

We may need to shift to something that makes it clear that we aren't a Google product (based on this thread). You're 100% correct regarding the Google "G" usage as you point out.

Clean Email has a nice simple banner at the top of their page announcing their Google verification with a simple generic emoji. It's a good alternative to a more formal badge. https://clean.email/

I've added this topic to our weekly sprint review. Appreciate the comment.

Ah, that context is really good to know

IMO that badge really cheapens the look and feel of your site and caused me to scrutinize it WAY more than if it hadn't of been there. If it's not official, it's always going to be suspect

Wow, very interesting. We were hoping the badge would bring more authority, but super helpful to hear otherwise. Thanks.

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.

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.

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!

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!

Reply on news.ycombinator.com