The History of the ISL Safe Software Specification

 

Building a Safe Spec – Turn 1: The Behavior of Technology

When the Me2B Alliance first began work on a specification in 2019, it was called a “Code of Practice” for Respectful Tech”. It was intended for makers of technology, businesses (or “B-s” as we call them). Our specification working group was correspondingly called the Good CoPs WG. We commenced work on developing use cases and the code of practice, but it wasn’t long before we realized a couple of things:  

1. We were more interested in testing the behavior of technology and not the processes by which it is developed, and 
2. we needed a much more fine-grained instrument—or set of tests,    

Focusing strictly on the behavior of technology was an important reorientation for the specification working group and for the Me2B Alliance.  

Our premise has always been that people are in intimate “Me2B” [aka individuals to businesses] relationships with digital products and services. In many ways, these products/services are autonomous ambassadors or agents of the organizations that built them. Therefore, these products and services should treat us “like a good friend, or at the very least a polite stranger.” Thus, our safety criteria needed to focus strictly on the behavior of the product/service. We needed to turn away from a code of practice for businesses, and toward objectively measuring the behavior of technology.   

Building a Safe Spec – Turn 2: Creating Context 

As we turned our sights on specifying the behavior of technology, we quickly encountered the importance of the contextual nature of the test cases we were composing. As we attempted to characterize passing and failing behavior, we often found ourselves saying, “It depends.” We needed adequate context to reflect the reality that acceptable/passing behavior changes over the arc of the lifecycle of the Me2B Relationship. Just as acceptable behavior organically evolves in our personal relationships, it evolves in our relationships with digital products and services. 

We needed adequate context to reflect the reality that acceptable/passing behavior changes over the arc of the lifecycle of the Me2B Relationship. 

Around this time, our Me2B Relationship lifecycle model and Me2B commitments came into full clarity.  

Building a Safe Spec – Turn 3: The Aha Moment – Safety not Privacy

In our third and most recent turn, we rearchitected the entire spec around key Me2B Relationship transactions we refer to as Me2B Commitments. These commitments are points in the user experience where we are asked things like if we accept cookies, if we’ll share our location, or if we’d like to create an account. After developing tests for each of the typical commitments encountered in most digital technology, we observed common themes in our identified tests.  

We distilled the themes present in all commitments, resulting in our first formal recommendation, “10 Attributes for Safe and Respectful Me2B Commitments”. Most of our Specification now consists of tests evaluating the safety and respectfulness of each Me2B commitment found in the UX of the website or mobile app. It was also during this third turn of the wheel when we also became acutely aware that we were building a safety standard.  

Since our founding, we have never been satisfied with “privacy” as the sole scope of concern. Abuse of privacy is not the only abuse humans experience when using connected technology. As our Digital Harms Dictionary illustrates, we experience myriad other harms such as coercion, manipulation, algorithmic bias (racism, sexism, ageism, etc.). We suggest that privacy is just one category of harm, one aspect of human safety. And it is too narrow a focus of concern; our scope is safety in the digital world. 

When we look back through history, the commercial launch of every innovative technology is followed by the development of safety standards and practices. For example, seatbelts, airbags, windshield wipers, and headlights were all developed after the first commercial automobiles were in use. This pattern makes sense, as widespread adoption and practical use of new technology are required to fully comprehend the scope and nature of all the potential harms and risks. 

However, safety standards for the internet are notably lagging —likely because the harms are not as immediately obvious as those of physical products such as cars. The long delay and elusive connections between cause and effect hamper the visibility and recognition of these harms. Also, ideas of “safety” on the internet quickly turn to questions of ethics, complicating the task due to the absence of a universal ethic.. 

 At the Me2B Alliance, we hold the view that connected technology is not just “tools we wield”, it is a collection of intimate and interactive relationships that we maintain—as alive and immediate as the relationships we maintain with the people and institutions in our lives. 

At the Me2B Alliance, we hold the view that connected technology is not just “tools we wield”, it is a collection of intimate and interactive relationships that we maintain—as alive and immediate as the relationships we maintain with the people and institutions in our lives. Using this foundational perspective of the interactive Me2B Relationship, we can look to interpersonal/social norms to provide a universal ethic: technology should treat us safely and with respect. We can hold technology to the same standards we hold people (mostly).  

Rules of Engagement for the Digital World 

As social animals, we humans have social norms developed over millennia; collective, co-created agreements (“Social Contracts”) on how we agree to treat each other in community. The Me2BA has our own interpretation of a global social contract between Me-s and B-s called the Me2B Rules of Engagement.   

Organizations like the UN have the Universal Declaration of Human Rights describing universal, inherent rights for all humans. But the internet sadly was not architected to support all these rights. The creators of the internet were world-building but didn’t fully realize they were world-building, building a new medium in which to live in community. The important thing is that we are here now, and we must, for the benefit of the health of humankind and our planet, come to a clear-eyed, inclusive, and collective view on the full spectrum of harms and potential risks that are inherent in our myriad and ever-increasing digital Me2B Relationships.  

A Baseline Safety Spec 

And that’s where our current offering, the Me2B Safe Spec for Respectful Technology for Websites and Mobile Apps comes in.  This spec is the first of several and provides a minimal viable product for baseline safe behavior of mobile apps and websites. This open spec is a living document and will continue to be updated by the Respectful Tech Spec Working Group to address ever more of the harms identified in the Digital Harms Dictionary. We will also be working to provide specs for all connected platforms, including routers, smart TVs, smart homes, wearables, etc. 

In Conclusion & Thanks  

Our primary thesis is that safer, more respectful technology isn’t just better for people (users of technology), it’s also better for the makers of technology, resulting in stronger, more meaningful Me2B Relationships. Because that is what they are, relationships. The days of treating customers as endless sources of extractive, exploitable (monetizable) data are quickly drawing to a close as the world wakes up to the harms and price of “free” services.  

Our safety yardstick is unwaveringly on the side of keeping Me-s safe, but it is for naught if makers of technology do not embrace and value more meaningful Me2B relationships, through safe and respectful products.  

We know there is much more work to do, more harms and platforms for which tests must be developed. We look forward to hearing from all makers of technology and welcome your comments as you apply this standard to your mobile apps and websites. Please tell us where you think we’ve got it wrong. The behavioral bar may feel uncomfortably high. And in some cases, perhaps it is too high—but we welcome the feedback and are willing to conduct validation testing to ensure that our passing behavior criteria accurately reflect the needs of everyday people.  

This baseline spec is the fruit of several years and countless volunteer hours working to establish the through-line from ethical principles to objectively measurable behavior. I would like to express heartfelt thanks to the Respectful Tech Spec Working Group (nee Good CoPs WG), and all the people who have generously contributed their time and wisdom so that we now have a solid foundation for what safety is in the digital world.  

P.S. We’re fast at work at adding in GDPR and CPRA mapping against our test suite and will be launching version 1.1 as quickly as we can.  

The Internet Safety Labs Safety Spec for Websites & Mobile Apps v1.0