On 2015-05-23 at 13:17 +0000, Edward Ned Harvey (lopser) wrote: > You mean, you're drafting the privacy policy that your customers will see > when they use your cloud service, right?
Kind of, except that this is cloud hosting, for corporates, so sysadmins are my customers. > If you're not doing my work for me, I don't see any reason I should be > required to give you any access to my stuff at all. Encrypt client-side, > using keys that are not accessible by the service provider. Then the only > privacy policy I need to care about is the fact that you have my email > address and billing information. Keep it private. We're running your jobs. Skip the next paragraph if you don't want to read something dangerously close to a product plug; I was trying to avoid plugging while asking for help. Building your code-bases into verifiable packages, going through audit pipelines; running the code, with application proxies intermediating access to databases, to rewrite auth credentials and provide latency measurements and ability to whitelist/blacklist per-app-level protocol frames; scaling up the jobs running; moving jobs transparently between AWS/GCE/OpenStack/etc while making sure the job moved from AWS to GCE can still access RDS. All under policy controls, granting access where needed. The current marketing blurb reads "Hybrid Cloud OS". So anyway: we don't do backups of your jobs, we provide the tools for you to manage the backups, we do backups of cluster state. We're careful to avoid performing exfiltration attacks on our own customers and accept that this means having to patiently explain why they still need to do their own backups. (So far, folks have been pretty clueful and have accepted this rationale quickly). We need to formalize the privacy guarantees we offer. I can write something which covers the points I think should be included, but no matter how much it sometimes feels like it, I have not experienced all the pain which the world holds to offer to sysadmins. I have not experienced every underhanded contract interpretation, every dodgy checklist compliance feature implementation, every contract term which was deliberately ambiguous. We want to produce a good faith document which is simple, clear, unambiguous but still covers enough to not be leaving gaping holes. So, where have you been burnt? What needs to be clear? What "standard" phrases raise red flags to you, and why? -Phil _______________________________________________ Discuss mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
