TOTAL: {[ getCartTotalCost() | currencyFilter ]} Update cart for total shopping_basket Checkout

Privacy Perspectives | Privacy Policies Are Not Enough: We Need Software Transparency Related reading: Delta sues chatbot provider over role in 2017 data breach




Information and communications technologies (ICTs) intermediate our transactions and lives. How are we to trust the many devices, sensors, operating systems, apps, modules, APIs, platforms, ecosystems, clouds and other networks that surround us and collect, process, share and retain so much personal data?

As we become enmeshed in the Internet of Things, surrounded by cloud computing and big data, transparency and accountability issues have risen to public prominence. Organizations of all kinds are increasingly required to show that they are keeping privacy promises and avoiding privacy harms.

It is difficult for anyone to validate the privacy claims made by technology developers and service providers. A privacy policy or transparency statement is a good starting point but, by itself, only expresses aspirations and intentions. It stands to reason that documented and independently verifiable privacy claims should enhance compliance, credibility and trust goals. To achieve this, we need standardized methods and tools.

Transparency and Accountability Foster Confidence and Trust

In 1999, Lawrence Lessig wrote in Code and Other Laws of Cyberspace that value, interests and policy decisions are embedded in software code, which in turn shapes users in profound ways. The significance of Lessig’s observations are more urgent than ever before, especially as software “code” is so much more complex and opaque today, relying on user confidence for adoption.

“Code” needs to be more transparent and accountable in order to be trusted.

The OASIS Privacy by Design for Software Engineers (PbD-SE) Technical Committee has developed a draft specification to help document software engineering privacy decisions that are consistent with Privacy by Design (PbD) and the Fair Information Practice Principles (FIPPs).

Since the 1990s, there have been many efforts worldwide in developing standardized methods to design and evaluate the privacy properties of technologies that embody privacy interests. Those efforts have expanded, along with technological developments and the rise of privacy professionals as a distinct, multidisciplinary practice.

Notable examples of third-party evaluation and certification programs for software include the Federal Information Processing Standard Publication 140-2 for cryptographic modules, the Office of the National Coordinator for Health Information Technology Certification Program for electronic health record technologies and the European Privacy Seal (EuroPrise) for IT products and IT-based services.

Ideally, privacy should have its own globally-recognized trustmark.

Transparency and Accountability Are for Everyone

Transparency and accountability must be demonstrable to an increasing range of interested stakeholders, not just consumers/citizens and marketplace regulators but also to internal project participants and shareholders, business partners, industry groups, attentive civil and consumer rights groups and to the public at large.

In the information-security domain, evaluation, audit and certification standards for organizations have matured rapidly, especially since the advent of breach disclosure requirements. The general trend emphasizes transparency and accountability of whole operations, enterprises, even ecosystems. Security is becoming a property that can be measured and maximized. Now privacy must catch up.

Privacy by Design Offers a Framework for Best in Class

Developed over the past decade and a half, in response to an evolving world, and unanimously approved in 2010 as an international standard by the International Assembly of Privacy and Data Protection Authorities, the seven foundational principles of PbD build upon the FIPPs but go beyond them to prescribe the highest possible standard of privacy protection.

Since PbD principles are universal in scope, the main challenge since 2010 has been to operationalize the PbD framework in specific domains, much like the ISO 17799 security framework is operationalized by the 27000 series of controls.

Created in late 2012, the OASIS PbD Documentation for Software Engineers Technical Committee has developed a draft specification of a methodology to help engineers model and document PbD requirements, translate the PbD principles to conformance requirements within software engineering tasks and produce artifacts as evidence of compliance.

The intended audience is primarily software engineers tasked with implementing and documenting functional privacy requirements to show compliance to PbD principles. However, as software engineers operate in larger contexts, this specification should also be of interest to their project managers, business managers and executives, privacy policymakers, privacy and security consultants, auditors, regulators, IT systems architects and analysts and other designers of systems that collect, store, process, use, share transport across borders, exchange, secure, retain or destroy personal information. We believe it will have a wide reach.


If you want to comment on this post, you need to login.