I am pleased to share with you (at nearly 4am) the results of consolidating efforts by James Urquhart on his blog and Rich Wellner and I offline, by way of a draft of a ‘consensus’ Cloud Computing Bill of Rights or Ten Commandments available on the brand new Cloud Computing Community Wiki (http://wiki.cloudcommunity.org/).
This MediaWiki site was setup to facilitate tasks like this which are not suitable for inclusion in Wikipedia (which forbids such original research). It is fully open and you don’t even need to create an account (let alone ask for permission to do so) in order to both read and write, making it significantly more accessible than existing efforts. The wiki is hosted by Dreamhost and the mailing list on a VPSlink VPS dedicated to the community and sponsored by my company, Australian Online Solutions. Not particularly ‘cloudy’, I know, but accessibility was the #1 goal.
Cloud computing: Bill of rights
The Cloud Computing Bill of Rights (CCBoR) (aka Ten Commandments) is a community consensus maintained document designed to protect the interests of cloud computing users.
We believe that users have certain rights when using resources on a cloud. Cloud computing is a powerful approach to sharing resources in a highly connected world and will succeed or fail on the basis of how that sharing takes place. In recognition of the growing value, be it financial or intellectual, of the work we will do using cloud based resources, providers and consumers must know the set of common assumptions they can make when engaging in this style of computing.
RFC2119 requirement levels are used throughout but for the sake of style all-caps are not used.
- User consumes the cloud computing service.
- Subuser consumes the cloud computing service sub-allocated by the User (eg Google Apps accounts)
- Provider delivers the cloud computing service to the user.
- Data is the collection of organised information belonging to the user and their subusers, including metadata and configuration data
- Metadata is data about data, including tags, access control lists, content types, etc.
- Configuration Data is any and all data relating to parametrisation of the application(s)
- Transparent means machine-readable and represented in a format whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic software
- Events must be securely recorded for an appropriate period depending on the needs of the user
- Logs must be made available by download in a transparent format and optionally online
- Monitoring beyond that required for service delivery be able to be opted out of
- Itemised Invoices must be made available with sufficient information so as to validate the providers’ claims
- Limits must be able to be enforced so as to prevent runaway costs
- Transparency is required in billing, in that a user should be able to calculate and anticipate usage
- Usage Data (both current and historical) must be available to enable Users to monitor usage trends
- Bulk Access shall be provided to all user data (including metadata and configuration data)
- Frequency of access shall not be unreasonably limited (eg >30 days)
- Redundancy should be built into the systems such that user data is protected against loss
- Transparent formats shall be used, except where the user explicitly stores opaque data
- Encryption of data shall be facilitated where feasible and never unnecessarily hindered
- Integrity of data should be maintained (exception is data processing where data is easily replaced by user)
- Licensing as necessary for delivery of services (eg hosting) is acceptable with explicit permission
- Metadata and configuration data (eg settings) is included
- Ownership is retained by the user along with all associated rights (eg copyright)
- Purging of data as required, including immediate, permanent and secure purging if necessary
- Subusers’ data is included (eg Google Apps users have multiple accounts, SalesForce users have customer accounts)
- Availability of Application Programming Interfaces (APIs) shall be maintained for accessing and manipulating data
- Change control shall allow for all API changes to be notified well in advance# Documentation shall be made available online in open standard formats
- Existing standards shall be used (eg REST)
- Superseded versions of APIs shall be available for a reasonable period
- Conflicts of interest shall be revealed to the user (eg where sponsorship has affected platform choice)
- Contracts shall use clear and easy to understand contract language, striving for the fewest surprises
- Termination of service agreements without penalty must be possible in the event that Terms of Service changes are not acceptable to the User
- Warrants shall be defended and notified to the user according to a set of published policies, except where forbidden
- Exact Location need not be provided beyond the smallest significant jurisdictional boundary (eg state, country, union of states)
- Location of systems and data shall be made available to users
- Selection of an appropriate location based on user preferences shall be provided where feasible (price may vary according to local conditions)
- Access to systems must be available in a secure fashion (eg appropriate authentication and transport layer security with appropriate ciphers)
- Administrative Requests be handled using secure processes resistent to social engineering (eg identity verification, proof of control of domain)
- Confidentiality of user data must be maintained
- Multitenancy be strictly enforced such that no user can access or modify the data of any concurrent, former or future user
- Advertising shall match service levels and price points (eg never advertise a high service level at a low price point and demand a premium) and service delivered shall match expectations
- Alternative service levels may be offered to the customer and priced accordingly
- Availability shall be maintained by vendor according to prevailing Service Level Agreements
- Expenses accrued in maintaining the service levels shall be borne in full by the provider
- Subusers service levels shall be the responsibility of the User; subusers may or may not be assisted by provider
- Innovation should not be impaired by forced adoption of standards
- Open Standards should be used where appopriate standards are available
- Sam Johnston prepared this document based on existing efforts and contributed to it
- James Urquhart refined a draft document over a number of blog posts
- Rich Wellner contributed a pre-prepared draft document for incorporation