4 ms·

Thanks for the kind words. I think the only way we can make this promise is by doing what we're doing right now and not actually storing any email content. I'

Thanks for the kind words. I think the only way we can make this promise is by doing what we're doing right now and not actually storing any email content. I'm not sure the best way to prove that this is what we're doing, short of open sourcing the code, so I'm open to suggestions there!

royosherove 8y ago
Hold public audits by a trusted 3rd party to show you are not keeping any data - on a repeating basis (6 months?)
- jivings 8y ago
  We're already required to perform an audit by Google every 12 months (I've mentioned the requirements of this below, but it basically amounts to the same thing), would this be acceptable?
  - gnicholas 8y ago
    What are the details of this? I've seen how things work on the Chrome Store side, and it's completely haphazard. There isn't an official audit schedule, as far as I can tell, but like with the iOS App Store, they do sometimes decide to flag/remove an extension for completely bogus reasons, with little/no notice: https://medium.com/@BeeLineReader/google-yanked-my-chrome-extension-this-sunday-d9c481e285cb https://medium.com/@BeeLineReader/google-yanked-my-chrome-ex...
    - jivings 8y ago
      As of this year with apps that access the Gmail API it is an official audit by an authorised third party assessor. More info here: https://cloud.google.com/blog/products/g-suite/elevating-user-trust-in-our-api-ecosystems https://cloud.google.com/blog/products/g-suite/elevating-use...
      - gnicholas 8y ago
        That's great. I'd emphasize this both in the privacy policy and in the FAQ. It's not bulletproof, but it goes a long way.
tux1968 8y ago
It would be interesting if you could define a restricted-API for email, with just enough functionality to provide your service. The issues right now is that there is no fine-grained way to grant permission to ones email, it's all or nothing. Of course, it might take a long time for email providers to offer such restricted-API access, if ever. As a stop gap, you could offer an open-source daemon your users could self-host. It would act as a gateway, granting you limited access to their email, without you needing their password or cart-blanche permissions.
gnicholas 8y ago
I totally understand this difficulty. My startup's browser plugin [1] changes text appearance to make reading on-screen easier, and this obviously requires the ability to "view and change content on all sites you browse". I'm sure this permission request scares off some people, but we've not had too much trouble with it. We make it clear in our privacy policy that we don't tie any usage information to user accounts, ever. I think it also helps that we have awards from social-good type organizations like the United Nations, NewSchools Venture Fund, and Stanford. (OTOH, given the leaked emails from the Stanford-based founder of Snapchat, maybe that last one hurts more than it helps....) 1: http://www.beelinereader.com/ http://www.beelinereader.com/

royosherove 8y ago

Hold public audits by a trusted 3rd party to show you are not keeping any data - on a repeating basis (6 months?)

jivings 8y ago
We're already required to perform an audit by Google every 12 months (I've mentioned the requirements of this below, but it basically amounts to the same thing), would this be acceptable?
- gnicholas 8y ago
  What are the details of this? I've seen how things work on the Chrome Store side, and it's completely haphazard. There isn't an official audit schedule, as far as I can tell, but like with the iOS App Store, they do sometimes decide to flag/remove an extension for completely bogus reasons, with little/no notice: https://medium.com/@BeeLineReader/google-yanked-my-chrome-extension-this-sunday-d9c481e285cb https://medium.com/@BeeLineReader/google-yanked-my-chrome-ex...
  - jivings 8y ago
    As of this year with apps that access the Gmail API it is an official audit by an authorised third party assessor. More info here: https://cloud.google.com/blog/products/g-suite/elevating-user-trust-in-our-api-ecosystems https://cloud.google.com/blog/products/g-suite/elevating-use...
    - gnicholas 8y ago
      That's great. I'd emphasize this both in the privacy policy and in the FAQ. It's not bulletproof, but it goes a long way.

tux1968 8y ago

It would be interesting if you could define a restricted-API for email, with just enough functionality to provide your service. The issues right now is that there is no fine-grained way to grant permission to ones email, it's all or nothing. Of course, it might take a long time for email providers to offer such restricted-API access, if ever. As a stop gap, you could offer an open-source daemon your users could self-host. It would act as a gateway, granting you limited access to their email, without you needing their password or cart-blanche permissions.

gnicholas 8y ago

I totally understand this difficulty. My startup's browser plugin [1] changes text appearance to make reading on-screen easier, and this obviously requires the ability to "view and change content on all sites you browse". I'm sure this permission request scares off some people, but we've not had too much trouble with it. We make it clear in our privacy policy that we don't tie any usage information to user accounts, ever. I think it also helps that we have awards from social-good type organizations like the United Nations, NewSchools Venture Fund, and Stanford. (OTOH, given the leaked emails from the Stanford-based founder of Snapchat, maybe that last one hurts more than it helps....) 1: http://www.beelinereader.com/ http://www.beelinereader.com/