Cloud Computing Consumer Protocol

Transcription

1 78 Sidaway St Chapman ACT 2611 AUSTRALIA Tel: Roger.Clarke@xamax.com.au August 2013 Mr A. Redman Head of Policy and External Affairs Australian Computer Society Inc. Dear Adam Re: Cloud Computing Consumer Protocol Thank you for your time on 30 July. As presaged, I attach my company's submission on the above matter. Much of it is intended to clarify the Protocol's purpose and audience, and ensure effective communication to that audience. However, I draw particular attention to several of the specific Submissions. Unless they are addressed, the Protocol will be of no benefit to anyone. The three critical Submissions are: (13) The section on disbenefits and risks needs to: identify and calmly and soberly explain all of the many factors that give rise to a lack of trust and confidence identify and analyse existing safeguards identify additional safeguards that are needed in order to solve the remaining problems, and phrase the additional safeguards in ways that generate momentum among serviceproviders, industry associations, policy agencies and regulators towards the delivery of solutions (15) The Protocol needs to contain substantive Undertakings by service-providers, well beyond disclosures, in respect of the 13 factors listed on pp of the Discussion Paper (16) The Undertakings need to be comprehensive, such that all factors that represent significant disbenefits, risks, and trust and confidence barriers are the subject of substantive Undertakings by service-providers If any clarifications are needed, I would of course be pleased to provide them. Thank you for your consideration. Yours sincerely Roger Clarke FACS Director Xamax Consultancy Pty Ltd

2 Submission to the Australian Computer Society Cloud Computing Consumer Protocol Xamax Consultancy Pty Ltd 78 Sidaway St Chapman ACT 2611 AUSTRALIA 12 August 2013 Xamax Consultancy Pty Ltd, 2013

3 Submission re Cloud Computing Consumer Protocol Executive Summary It is not appropriate for the Protocol to be prepared in the form envisaged in the Discussion Paper. It is not appropriate for the Protocol to adopt or reflect the NZ CloudCode v.2.0. It is submitted that the following matters need to be addressed: (1) The scope of the Protocol needs to be clarified, in particular in relation to the market segment(s) whose interests are being addressed (2) The content and expression need to be aligned with the scope and purpose (3) The title of the document needs to communicate its purpose (4) The content needs to reflect the needs of the relevant market segment(s) (5) The expression needs to avoid marketing style, and speak to the target audience (6) The definition of cloud computing needs to be accessible, but also of sufficient depth, and consistent with industry norms (7) The information provided about the various categories of service model needs to be accessible, but also consistent with industry norms (8) The Protocol needs to make clear whether it is applicable to all of the various categories of service-model, or to what extent it applies to each of them (9) The potential benefits of cloud computing need to be presented in a balanced manner, avoid marketing-speak, and include complementary discussion of the conditions that must exist for each benefit to actually be achieved (10) The list of potential benefits needs to be reviewed to ensure comprehensiveness (11) The notion of 'barriers' needs to be replaced with notions such as 'disbenefits' and 'risks' (12) The list of disbenefits and risks needs to be reviewed to ensure comprehensiveness (13) The section on disbenefits and risks needs to identify and calmly and soberly explain all of the many factors that give rise to a lack of trust and confidence, identify and analyse existing safeguards, identify additional safeguards that are needed in order to solve the remaining problems, and phrase the additional safeguards in ways that generate momentum among service-providers, industry associations, policy agencies and regulators towards the delivery of solutions (14) The Protocol needs to contain an outline of a process for the assessment by users of their requirements, an outline of a process for the evaluation by users of cloudsourcing proposals, checklists of factors to be considered, circumstances in which each factor is of particular importance, and an indication of categories of application for which cloudsourcing may be appropriate, even where disbenefits and risks are not satisfactorily addressed by safeguards (15) The Protocol needs to contain substantive Undertakings by service-providers, well beyond disclosures, in respect of the 13 factors listed on pp of the Discussion Paper (16) The Undertakings need to be comprehensive, such that all factors that represent significant disbenefits, risks, and trust and confidence barriers are the subject of substantive Undertakings by service-providers (17) The Protocol needs to include an undertaking by service-providers to operate a complaintshandling scheme that is consistent with relevant Standards, including AS ISO , and good industry practices, provide for an independent complaints-handler that operates a scheme that is also consistent with such Standards and practices, and provide that complaints must first be submitted to the relevant service-provider (18) Adoption of the NZ Cloud Code would not satisfy the aims of the present initiative Xamax Consultancy Pty Ltd, August 2013

4 Submission 1. Introduction Cloudsourcing is claimed by its proponents to offer considerable advantages over both insourcing and more conventional forms of outsourcing. Its use is growing, but there is considerable evidence of reticence, in government, among small and medium business enterprises, and among consumers. The Australian Government has a National Cloud Computing Strategy, which includes the development of a voluntary 'cloud computing consumer protocol', intended to be operational by January The Protocol is intended to document undertakings by service-providers, in order to overcome the lack of trust and confidence that is holding back adoption of cloud computing. The Australian Computer Society (ACS) has carriage of the matter, and issued a Discussion Paper in July 2013, for response by 5 August This document is a response to that Discussion Paper. It draws heavily on the author's prior consultancy and research work, which are reflected in a series of published papers listed in the Appendix to this document. 2. Design Criteria for a Protocol In order to achieve its purpose, such a Protocol needs to satisfy a number of criteria. A Protocol of this nature needs to: be oriented to the needs of the relevant market segments be informative for, and accessible by, the relevant individuals in those market segments be realistic and balanced in its content and presentation provide guidance on the evaluation process that adopters need to undertake reflect the insights of the risk assessment and risk management disciplines clearly identify problems, and generate momentum towards solutions to them 3. The Framing of the Project This section considers generic aspects of the project to prepare a Protocol. 3.1 Scope There is a lack of clarity about the market segment(s) whose interests are to be addressed: the Protocol's working title includes the word 'consumer' the introductory text on p. 3 refers to "users... particularly small businesses, not-for-profits (NFPs) and consumers", which appears from a passage on p. 5 to have been adopted from the government's National Cloud Computing Strategy the purpose statement on p. 3 refers to "users" the section 5 heading refers to "SMEs", and the discussion of benefits on pp. 8-9 is couched in terms of relevance to small businesses ('lower time to market', 'global competition', 'competitive edge', 'barriers to capital'), and to a small extent NFPs ('productivity'), but in most cases not to consumers Xamax Consultancy Pty Ltd, Version of 12 August 2013

5 (1) The scope of the Protocol needs to be clarified, in particular in relation to the market segment(s) whose interests are being addressed (2) The content and expression need to be aligned with the scope and purpose The Protocol is intended to embody undertakings by cloud computing service-providers, for the benefit of organisations and/or individuals in some market segment or segments. It is confusing for the Protocol to carry the name of a market segment (currently 'Consumer'). It would be much clearer if the Protocol were called something like a 'Cloud Computing Service-Provider Protocol', perhaps with a short, alternative name such as the 'CloudCode' term adopted in NZ. The market segment whose interests the Protocol addresses would then be spelt out in the opening lines of the document. (3) The title of the document needs to communicate its purpose 3.2 Balance The Discussion Paper reads as though the Protocol is to be written for service-providers. The text is imbued with marketing-driven statements that 'pump' or 'boost' cloud computing. (4) The content needs to reflect the needs of the relevant market segment(s) (5) The expression needs to avoid marketing style, and speak to the target audience 4. The Information Provided Within the Protocol This section considers the information that the Discussion Paper envisages the Protocol will contain. 4.1 Definitions The definition of cloud computing on p. 7, although suitably comprehensible, does not convey the difference between cloudsourcing and conventional forms of outsourcing. An approach along the lines of the following extracts from Clarke (2013) is suggested instead: In conventional outsourcing, a service-provider hosts equipment that supports a relevant stack of software, and stores and maintains data. In cloud computing, the service-provider changes the focus of the offer from the equipment to the processes. Those processes may be run in any of a wide range of devices, and the location of those devices is determined by the needs of the service-provider, not those of the customer. The service-provider scales the number of processes and storage capacity to meet the customer's varying needs over hourly, daily, monthly and/or annual cycles, to reflect growth and decay factors, and in the face of demand uncertainty. The service-provider may offer a tariff based on usage, because instead of unused capacity being locked up in hosts that have been pre-allocated to a customer, the service-provider can make more efficient use of the available computing resources. Xamax Consultancy Pty Ltd, Version of 12 August 2013

6 The definition in the NZ CloudCode v.2.0 of July 2013 is technically clear and appropriate, but may not communicate as effectively with the intended readers as an approach such as that suggested above. (6) The definition of cloud computing needs to be accessible, but also of sufficient depth, and consistent with industry norms The definitions of PaaS and SaaS on p. 7 are not consistent with my understanding of industry norms. My understanding is as follows (Clarke 2013): Infrastructure as a Service (IaaS) refers to the provision of a bare (but virtualised) machine, without software or with little more than a specific operating system and version. Amazon's EC2 and Rackspace were early movers in a marketspace that is becoming densely populated Platform as a Service (PaaS) offers a configured platform on which organisations can develop and/or install their applications. Sub-categories include: proprietary platforms, such as Microsoft Windows Azure standards-based services that provide specific application development and/or execution environments, such as Ruby or PHP extensibility and customisation features in SaaS offerings such as Salesforce Software as a Service (SaaS) makes specific application software available. SaaS is targeted at organisations of all sizes as an alternative to applications running on the organisation's own hosts, or on their employees' workstations. Examples include Salesforce, Google Gmail, Zoho, Google Apps, MS Office 365, Dropbox and MYOB LiveAccounts. SaaS is also offered directly to consumers, e.g. Zoho, Gmail, Google Docs, Dropbox. (7) The information provided about the various categories of service model needs to be accessible, but also consistent with industry norms (8) The Protocol needs to make clear whether it is applicable to all of the various categories of service-model, or to what extent it applies to each of them 4.2 Benefits The section on Benefits on pp. 8-9 is written with a rose-coloured hue. (9) The potential benefits of cloud computing need to: be presented in a balanced manner avoid marketing-speak, and include complementary discussion of the conditions that must exist for each benefit to actually be achieved The section on Benefits on pp. 8-9 omits some benefits that are identified in Clarke (2012) at (10) The list of potential benefits needs to be reviewed to ensure comprehensiveness 4.3 Barriers The section on Barriers on pp is wrongly pitched. Service-providers are interested in barriers to adoption. But these are not terms of relevance to small organisations and consumers, who are instead concerned about Disbenefits (or 'Financial and Other Costs') and Risks. Xamax Consultancy Pty Ltd, Version of 12 August 2013

7 (11) The notion of 'barriers' needs to be replaced with notions such as 'disbenefits' and 'risks' The section on Barriers on pp omits a great many important Disbenefits and Risks. See the comprehensive list published in Clarke (2010, 2012), and specifically at (12) The list of disbenefits and risks needs to be reviewed to ensure comprehensiveness The section on Barriers on pp reads as an excusatory piece, and is focussed on allaying fears, rather than on providing useful information for small organisations and consumers. (13) The section on disbenefits and risks needs to: identify and calmly and soberly explain all of the many factors that give rise to a lack of trust and confidence identify and analyse existing safeguards identify additional safeguards that are needed in order to solve the remaining problems, and phrase the additional safeguards in ways that generate momentum among service-providers, industry associations, policy agencies and regulators towards the delivery of solutions 4.4 Guidance The text as it stands could be seen to be irresponsibly goading small organisations and consumers into adopting cloudsourcing, whether or not it is appropriate for them to do so. The Directors of incorporated organisations have a legal obligation to their shareholders or members to make reasoned decisions, and hence to identify and evaluate options. Clarke (2012) provides a framework for evaluation, and Clarke (2013) specifically examines data risks. Even consumers owe it to themselves, but sometimes also to their families and householders, to take at least a modicum of care with such things as their address books, financial and taxation information, family history and scans of family photographs. Clarke (2011) provides a framework for the assessment of consumer needs and the evaluation of particular services. As presently contemplated, the document fails to communicate this need, and fails to provide guidance. (14) The Protocol needs to contain: an outline of a process for the assessment by users of their requirements an outline of a process for the evaluation by users of cloudsourcing proposals checklists of factors to be considered circumstances in which each factor is of particular importance, and an indication of categories of application for which cloudsourcing may be appropriate, even where disbenefits and risks are not satisfactorily addressed by safeguards Xamax Consultancy Pty Ltd, Version of 12 August 2013

8 5. The Undertakings For an instrument of this nature to have much impact, it has to be not merely a glossy document released with a fanfare. It must provide, and be seen to provide, concrete assurances to the relevant market segments, which address the impediments to adoption, and thereby generate confidence. The undertakings that the Discussion Paper contemplates service-providers giving to small organisations and consumers are expressed within a section headed 'Disclosures' rather than 'Undertakings' (pp ). And 10 of the 13 heads are indeed limited to disclosure. Disclosure is of value. On the other hand, some of the disclosures are required by law, and many are little more than statements that 'there's a problem here'. This will not achieve confidence or trust. For only 3 of the 13 heads are substantive undertakings contemplated. These are: 3. Security: "a good set of standards and practice" and "security standards and platforms... accredited to or [complied] with" 7. SLA and Support: "standard support mechanisms and SLAs" 9. Data Portability: "data portability is a prerequisite for users..." However, the wording is hedged in ways that reduce them from an undertaking to a mere aspiration: 3. Security is undermined by the use of the qualifier 'could' 7. SLA and Support is undermined by the use of the qualifier 'could' 9. Data Portability contains no actual commitment (15) The Protocol needs to contain substantive Undertakings by service-providers, well beyond disclosures, in respect of the 13 factors listed on pp of the Discussion Paper Further, there are many disbenefits and risks that are omitted from the list on pp A cursory scan of Clarke (2012) identifies the following further heads: Reliability (Availability, Accessibility, Robustness, Resilience, Recoverability) Accessibility Data Survival Forward-, Backward- and Lateral Compatibility Warranties and Indemnities in relation to the Service Legal Jurisdiction Changes to the Service Auditability Management of Incidents and Complaints A cursory scan of ACCAN (2012) identifies the following further heads: Accessibility for All Consumers Privacy (e.g. the current list omits at least Collection, and Subject Access and Correction) Redress Simplicity of Presentation of the Service Consumer Protection Standards Xamax Consultancy Pty Ltd, Version of 12 August 2013

9 (16) The Undertakings need to be comprehensive, such that all factors that represent significant disbenefits, risks, and trust and confidence barriers are the subject of substantive Undertakings by service-providers 6. The Code Complaints Process The Discussion Paper on pp discusses a Complaints process. It is unclear whether these complaints are to be made to the service-provider or to some other party, and if some other party, then: how that other party is to be constituted whether it is required that the complaint first be submitted to the service-provider (17) The Protocol needs to: include an undertaking by service-providers to operate a complaints-handling scheme that is consistent with relevant Standards, including AS ISO , and good industry practices provide for an independent complaints-handler that operates a scheme that is also consistent with such Standards and practices, and provide that complaints must first be submitted to the relevant serviceprovider 7. The NZ CloudCode Based on a brief review of the NZ CloudCode v.2.0 of July 2013, it is clear that the document suffers many of the same deficiencies as an Australian Protocol would if it followed the line of thinking in the Discussion Paper. In particular: the undertakings are about disclosure and nothing more (p. 1, p. 2 at 1.2, p. 3 at 3.1). For example: 5.4 Security does not require adoption of any standard, or certification, or audit 5.9 SLA and Support does not specify a standard, but merely requires disclosure of whatever the service-provider's normal offering is which is a requirement of contract law in any case 5.13 Customer Engagement does not require auditability or the existence of a Privacy Policy Statement, but merely a statement about whether or not they are provided 5.15 Data Breaches does not require notification of data breaches 5.16 Law Enforcement is not merely empty, but also objectionable, because it contemplates compliance with mere 'requests', whether or not accompanied by a legal authority such as a court order or search warrant the Complaints Mechanism is only about false statements, not about breaches of substance, and the Complaints-Handler may suppress reports on breaches the last of the Core Principles undermines the vital function of the Code to generate momentum towards solutions to problems. This is because it places a high value on limiting compliance costs (p. 2); whereas safeguards to overcome significant user disbenefits and risks, and enhance confidence and trust, will inevitably cost money Xamax Consultancy Pty Ltd, Version of 12 August 2013

10 The NZ CloudCode would have only a very marginal positive impact on confidence and trust, because the obligations entered into by signatories are very limited, and many of them are already legal requirements in any case. (18) Adoption of the NZ Cloud Code would not satisfy the aims of the present initiative 8. The Role of the A.C.S. The issues identified above are serious in their own right. A further consideration is whether it is appropriate for the ACS to adopt positions of the kinds contemplated in the Discussion Paper. It would have been unsurprising if a document of this kind had emanated from an industry association such as AIIA or IIA. ACS, on the other hand, is a professional association not an industry association, and the ACS Code begins with: 1. The Primacy of the Public Interest You will place the interests of the public above those of personal, business or sectional interests. Several of the changes proposed in the above submissions are accordingly of the nature of imperatives rather than optional measures, necessary in order to adjust the ACS's role in this matter to one consistent with its mission. Conclusions It is not appropriate for the Protocol to be prepared in the form envisaged in the Discussion Paper. It is not appropriate for the Protocol to adopt or reflect the NZ CloudCode v.2.0. It is very important that the matters identified in the numbered submissions above be addressed. Xamax Consultancy Pty Ltd, Version of 12 August 2013

11 Appendix: Resources The analysis in this paper is based on consultancy and research undertaken by the author over the last 5 years, and documented in a series of papers, which are indexed at: The most relevant of the papers to the question of a Consumer Protocol are these: Clarke R. (2010) 'User Requirements for Cloud Computing Architecture' Proc. 2nd International Symposium on Cloud Computing, Melbourne, May 2010, Published in Parashar M. & Buyya R. (2010) Proc. 10th IEEE/ACM International Conference on Cluster, Cloud and Grid Computing, Melbourne, Australia, May 2010, pp , at Clarke R. (2011) 'The Cloudy Future of Consumer Computing' Proc. 24th Bled econference, June 2011, at Clarke R. (2012) 'A Framework for the Evaluation of CloudSourcing Proposals' Proc. 25th Bled econference, June 2012, at Clarke R. (2013) 'Data Risks in the Cloud Forthcoming, Journal of Theoretical and Applied Electronic Commerce Research 8, 4 (Dec 2013), at See also: ACCAN (2012) 'What consumers need from cloud computing' Position Statement, Australian Communications Consumers Action Network, 11 December 2012, at Xamax Consultancy Pty Ltd, Version of 12 August 2013