
Show HN: Move 1000 subscription emails out of your Gmail inbox in 10 seconds - makemills
https://www.slimboxapp.com/
======
igneo676
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...](https://developers.google.com/terms/api-services-
user-data-policy#additional-requirements-for-specific-api-scopes) 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
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...](https://support.google.com/cloud/answer/9110914#restricted-
scopes)

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
You might want to reconsider that badge.

[https://www.google.com/permissions/logos-
trademarks/](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.”

~~~
makemills
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/](https://clean.email/)

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

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

