The Great Consent Wranglin’
A Privacy Co-op Article on Consent
Executive Description
There’s sometimes confusion inside organizations regarding privacy and consent. Some businesses are huge, and many people are collaterally working to evolve their businesses in different directions at the same time, often with competing rights to the same information rights. This resulted in different establishments, sometimes unavoidably with the same words being used to describe wildly different things.
Consider this line that’s an opt-out covered by one privacy policy for Relevant Advertising…
“Delivering customized content, Relevant Advertising and personalized offers for products and services that may be of interest to you”
Now compare that to an opt-in covered in a different product offered by the same company for Internet Preferences in regards to Personal Advertising…
“…to provide you relevant offers and advertising from an enterprise and its participating providers tailored to your online interests.“
Confused? If so, you’re not alone.
Confusion inside companies results in confusion outside for their customers. An unclear set of different messages creates wrinkles which become likely fodder for bloggers, editorialists, and their competition potentially driving a wedge between them and their customers.
Goal
This article attempts to take one constructive step towards removing some portion of confusion by establishing clear corrals of consent, their attributes and precepts, making way for clearer product velocity while helping to avoid competing interpretations on privacy requirements.
A Word about Information
Events in our lives and how we move through them creates information in a primary way. An enterprise collects that information as an innate part of a service. There can be 70 million pieces of such information or more that are generated and collected across an enterprise in a second. Today, most businesses understand about 30% of them or less well enough to say with certainty what they are. Only a portion of the rest may still have meaning to only software and machines, but a large portion of it remains completely meaningless to all. The human understanding of them remains to be rediscovered.
A large portion of this data is also available for developers to directly access through technology known as Application Program Interfaces (API).
There are times when we will need to communicate with the customer, and some of those times will be the result of using some of this information, other times will be for other purposes.
There are secondary uses for some or all of this information that create additional profit opportunities for an enterprise if the customer agrees to share their information for such secondary uses.
The various profitable bolt-on uses of all this information, as well as many of the types of direct communications with the customer requires consent. This article promotes that each of these consents can be neatly sorted into only one of a few corrals, with citations herein that are not exhaustive, but are intended to cast each specific associated context as required.
Corrals
There are really big ecosystems of consent — so big that some groups may focus only on one of them for years without ever needing to know about, or even be aware of the others. They have been largely self-contained, often with organizational and platform borders and sometimes even having different business unit ownership within an enterprise.
These ecosystems organically sprang up from the necessity to consciously grant and initiate a use of information. These uses naturally originated from three different types of desired information events — the accessing, sending, or sharing of information. Sometimes the information event initiator was an enterprise, and an enterprise was leveraging a prior grant from a previous agreement such as a privacy policy (stated as something like, “this enterprise will use your information in this way until you tell us not to”), and other times it was initiated by the customer (“I grant that the enterprise may now use my information in this way”). Irrespective of the initiator, ecosystems sprang up and evolved around these three information events.
Only in recent history, as products became more sophisticated in order to compete in a rapidly changing market, and with the advent of Big Data, did combined uses of the different ecosystems by a single product become a near daily discussion point.
In order to describe these ecosystems and what makes them the same, and more importantly…how they are different, this article will use the word, “corrals” to describe them. It’s critical to define sufficient differentiation between them so that no individual functionality involving privacy will be difficult to sort into just one of them.
As of the writing of this article, it is felt that there are exactly three corrals for consent that can be cleanly separated without confusing overlap — Accessing, Sending, and Sharing.
Accessing My Information
I installed some apps or signed up for offers from companies that told me what they were going to access about me, but now I want to view and manage all that.
· Anchor: Accessing my device, browser, or data connections for information.
· Scope: Only information made available by API’s, controllable at the API level for each App ID.
· End Result: Other parties will get my information and use it per their agreement with the 3rd Party Developer Ecosystem relationship.
The legal language is largely presented at time of app installation or a registration for some company benefit like a rewards program, but we could do a better job of making that also available in a common location after the fact to support revocation. For all server-to-server API access, this will be essential. Building a custom UI object for each new Application ID is not practical or scalable. In some cases it will be a necessary evil to do some custom coding, but our approach needs to be more standardized and scalable in as many cases as we can manage. Regrettably, this means things like grouping credit cards together or separating games from office products may be an expensive challenge, and our expectations should be set very low to start with. It will probably initially be just a long list of names that have been associated with Application ID’s that may in turn have several elections each.
Sending Information to Me
I know an enterprise and its partners will want to communicate with me. I want to manage general rules and exceptions for how communications like ads, amber alerts, weather warnings, and helpful tips find their way to me.
· Anchor: Sending information to specified end points.
· Scope: All types of communications, regardless of how they may have been generated.
· End Result: Global Do Nots will apply unless specific exceptions are individually in place. Platforms that use these consents will have to be provided direction on which consent system to use for their needs. In some cases communications will use only the Do Nots, others will use exception systems, and still others may require some hybrid.
General Rules (Do Not Disturb)
Legal language is in many different places, but it is distinctly different, and broader than most, often dealing with antiquated words like “robo-dialers,” that continue to be used in regard to modern technology and approaches that still require compliance. Here the customer will benefit greatly from being provided links beside choices to the various representations of that language with our own descriptions as well.
Exceptions
The legal language is sprinkled throughout regulations, guidelines, and law. We can probably do a better job of culling this language out and presenting it in close proximity to the various controls. For example Ghostery has some language on their website, federal regulations have other language. We could probably put links to that language beside a common list of checkboxes that visually group choices for customers from all the various required internal and external platforms.
Sharing My Information
All of my {enterprise name like my Telco} information, as an individual or part of a crowd, will be additionally shared for other features and benefits, and I want to understand and manage each.
· Anchor: Information that is generated for some primary purpose is used for a secondary one.
· Scope: All information that is generated for a specific service is used for a narrowly defined secondary purpose.
· End Result: Transactional use, Big Data or some other technology will use an intersection of Organization and Program. For example, all data feeds associated in any way with my Mobility account can be used for Personalized Fraud Analysis or Direct Marketing as two different choices.
Legal language should be modular for each feature and benefit, and shared by various marketing uses. The best approach found so far is a Master Agreement (MA) that the customer only has to agree to once, and schedules for each use. The MA establishes the anchor for each in the customer’s individual services, and the scope is set to all data generated by those services. The schedules detail the various uses that can be quickly read, and turned off and on with clear understanding of the consequences.
Corral Precepts
So, how do we tell these three corrals apart? How do we create a culture where people can hear a new idea and immediately know which corral it clearly belongs to?
First we have to remove what makes them similar so we don’t complicate their descriptions by trying to explain nuanced differences between similarities. We simply don’t mention their similarities at all in their descriptions. Below we examine the few clean differentiators, and then we’ll look into the similarities and why we shouldn’t attempt to use those to describe the corrals.
Differentiators
So what is it that makes these corrals different?
You’ll notice that each one of these differentiators was used in the previous section to describe the corrals so that they are very clear from the beginning. Differentiators have to be cogent, indisputable descriptions that can be conveyed without any subject matter expertise required, and most of all — focused on the customer’s perspective.
· Anchor: must have a core subject that can be legally defined.
· Scope: must have clear boundaries of what information is included within its jurisdiction.
· End Result: must have a unique net result or purpose for its scope.
· Legal Language: must have a consistent approach to legal language for all consents contained within, but that legal language, and its overall style or approach, will differ greatly from corral to corral.
Similarities
These should be examined after a specific consent has been placed in a corral and used to set the values for their various attributes. Therefore, as we define what makes the corrals different, let’s eliminate all the similarities one at a time so they will not confuse our crisp definition of the three corrals. The following similarities should be considered as defining attribute settings for each product in each corral after they have been defined and not as defining properties of the corrals themselves. Conclusion: all corrals will need to support all of these similarities.
Opt
Here’s the definition of the word opt.
Opt: to make a choice; choose (often followed by out or in).
All three corrals can require opt outs or opt ins. Remember that these corrals represent three different types of desired information events — accessing, sending, and sharing. These events need to be consciously granted and the application of that grant must be initiated as uses of information. Therefore, the type of Opt required for a particular information event is based on which party initiates the application of this particular use.
In some cases one single use that requires consent may need to support initiation by either an enterprise or the customer in pretty much the same exact way depending on whether or not a grant already exists — like if the customer viewing it is currently covered by an enterprise’s privacy policy or not. An example would be two customers, one a subscribing customer, and the other a non-subscribing customer, both wanting to use their copy of the same app that requires consent. For the subscribing customer, conditions might already exist for it to be an opt-out, but it would be an opt-in for the non-subscribing customer as the company can’t initiate the use of information without it. The consent language could be exactly the same for both customers, as long as the opt-in also included additional language like the grant.
As such, all corrals will need to support opt-in as well as opt-out, and the idea that some corrals are mostly opt-ins and others are mostly opt-outs is more of a blurry similarity that can change rather than a differentiator, and therefore should be avoided in their primary descriptions. It leads to unnecessary confusion during initial conversations of governance attempting to understand the types of consent that may be needed for a particular product.
While Opt-in or out is very important to get right, it shouldn’t be the first topic of discussion when first evaluating ideas in a new product. Rather, they are one of many similar configurations that need to be properly set after we understand what the information event (consent corral) is for each idea.
Let’s look at some more similar configurations settings.
Positive vs. Negative
All three of these corrals can be presented positively or negatively to the customer. Let’s look at examples of what a customer might see:
Accessing
- Opt-out of Fortnite using your location information.
+ This check represents the use of your location information by Fortnite.
Sending
- Don’t tell me a tornado is behind me.
+ an enterprise is using your information to alert you of tornadoes.
Sharing
- I want to not have my information used for ads providing me with a discount.
+ This check mark means I’m getting a discount, and I’m getting ads to support it.
In all cases, what would a check mark before each of these things mean to you? Each one of us will have our preference, and in recent customer testing, so do our customers! In other words, the only right answer may be to pick one approach and apply it consistently across all consent corrals so that customers at least know what all the check marks mean at a first glance.
The take-away is that if all three corrals can each be presented in positive or negative language, then the ability to be positive vs. negative is something that they have in common, and it’s probably not a strong differentiator to be used for defining the various corrals.
Groups vs. Individuals
Within the Sharing Corral, some consent elections apply to groups of people and others apply to individuals. This is largely based on coverage of some of them by the Privacy Policy, and that can change. In the Access corral, consents can apply to devices, some of which might be shared by groups or used by individuals. In the Sending corral, consents can apply to residences (even mail boxes) or endpoints shared by groups or used by individuals.
All corrals support Groups and Individuals alike.
Therefore, the concepts of groups vs. individuals, and a corral’s ability to support them are similar, and even blurry within corrals, and don’t make for a crisp differentiator at all. Therefore, group data vs. individual data should not be used to describe the corrals.
Anonymous vs. Personal
Within the Sharing Corral, some consent elections are focused on anonymized data that is also aggregated into large groups. Others focus on personal data.
This also applies to Sending and Accessing where sometimes messages are sent to groups of anonymous people like IPTV Targeted Advertising (commercials sent to anyone in Cleveland) and obfuscated location information where some API’s get generalized information about your whereabouts.
All corrals support the concept of Anonymous and Personal to some degree.
Therefore, the concepts of anonymity vs personal information and the corral ability to support them are similar, don’t make for a clear differentiator between corrals, and shouldn’t be used in descriptions.
Services and the UX Grid
Our customers have stated they want a grid. Believe it or not, when asked to draw what they would like to see, more times than not, they drew something that looked like a grid. This indicated that they probably crave consistency across services. Advertising is advertising — they probably don’t want differences they have to figure out between mobile advertising and IPTV advertising. And we have already establish that we are saddled with the necessary evil of maintaining at least two different types of advertising for enterprises to have to best future and not disrupt existing profit centers in attempts to add new ones (Crowd Ads to protect existing revenue and Personal Ads for new products).
Because people want a grid, consent for all three corrals must apply consistently across services. That means “services” are probably not strong differentiators for defining the various corrals.
Viability
The legal lives of agreements (their viability) are different for different types of consent, even from state to state, and especially country to country. Some are for the life of a contract, others are more persistent, and still others are so brief that they may expire within a single transaction. This is true for all consent across all corrals, and it’s probably more of a similarity than a differentiator — there’s no clear universal viability standard for each corral.
Why Each Corral is an Absolute Necessity
Accessing — Application Program Interface (API)
If primary events create, and cause the collection of information, and secondary uses of that information are based upon the customer’s consent to subsequently share that information for some additional specified uses, then tertiary may be the best way to describe API Access consent.
Let’s use an example — Fortnite. This fun game from Epic Games is not essential for a cell phone to work (although admittedly it may be the primary reason some customers upgrade their phones!). And the location of the phone is not really essential for Fortnite to work. But announcing that you made level forty-two while standing in line at Starbucks could be priceless! And certainly that ability is a product-sweetener to all involved. The OS provider benefits, the transport provider benefits, Epic Games’s Fortnite benefits, and the customer benefits. This app’s ability to access the location information is sometimes done by the use of API either hosted by the carrier (an enterprise) or made available directly on the phone. Enterprises have spent a lot of money and time making these API available to the developer ecosystem at large through different platforms.
Companies and individual developers sign up by the thousands for Application ID’s to access these API directly. Some companies may even have thousands of Application ID’s covering various services. They all should disclose what information they are accessing via these API for certain types of information such as CPNI[1], children[2], and overall protection of consumer privacy[3], but in some cases it’s up to the apps, various app stores, or company registration flows to do so. In some cases, the entity that initiates a request for this type of access will be an app that’s installed on a device that may or may not be communicating through a 3rd Party server, and in other cases it might be a corporation accessing the same API from a platform in their data center via the same type of server. These calls may actually be handled by two different enterprise platforms with varying consent capabilities for the same API call.
3rd Party Ecosystem Next Gen External Access Gateway (EAG), and other API platforms have attempted to develop consistent types of consent controls to tell the difference between an app on your phone vs. a server in a data center (like a credit card company). In a nutshell, it’s impossible. So the scope for this type of consent has to be at the level of the API name that is being accessed for each Application ID.
For example, think about the Application ID “Fortnite” accessing your location by Epic Games vs. the Application ID “MasterCard0001” accessing your same location by a credit card wholesaler. Other than their registered name, there’s no clean way to differentiate them, nor is there much by way of complete life-cycle management for them (how long they can continue to access that information, what they do with it afterward and what an act of revocation might look like or even how to honor it).
In truth, we have not found many, if any, 3rd Party Ecosystems at a telco level that allow you to review what your cell phone number has opted into — even before you owned your current number! That means that it’s likely that if your number is newer than 2007, your data is likely being accessed through API for uses you are not even aware of.
The general rule has been, “if you don’t want a company to access your information any longer, delete the app from your phone.” There is no ability for customers to explicitly revoke access by an app after the fact, and there’s no guarantee that revocation will be triggered when an app is uninstalled, nor is there typically customer understanding that further action is required to stop ongoing access by that company. There are also some serious issues that still need to be addressed for server-to-server lifecycle like Next Gen EAG, where no app is installed and there’s no native ability to revoke access consent.
Sending
Sending — General Rules
As a general rule, the ability to block communications sent to a person is the focus of the often misunderstood world of the “Do Nots.” Different rules have created a series of consents over time for things like “Do Not Mail Me[4],” “Do Not Email Me[5],” or “Do Not Call Me[6],” etc.
These elections are thought to be fairly broad and thin elections. Their existence allows for a number of profit centers to leverage the fact that we have not heard from the customer to monetize some additional aspect of their experience. This is an “opt-out regime” and many products rely only on one of these consent checks in order to make money every day for the company…
…and we mustn’t negatively impact that by anything new that we add.
However, other products with different legal language can, by narrow and deep definition, override these types of elections as exceptions. In other words, we should think of the broad and thin Do Nots as, “If you don’t hear otherwise from me, this is the general rule I wish to follow.”
For example, if a person says they don’t want text messages from an enterprise (Do Not Text), but then they register for an ad program in order to get concert tickets…
· The enterprise may not text them for things like Amber Alerts
· The enterprise won’t text them for any platforms that solely use that Do Not election value
· They will probably get tornado warnings if they signed up for Weather.com alerts
· They certainly will get ads that subsidize their concert tickets
The groups in charge of the Do Nots have spent considerable time and money on analyzing ways that an enterprise might be able to use automation to supersede other election platforms, or in turn be superseded by them, based upon one unifying, rules-based engine. In a nutshell, it’s impossible. So, the Do Nots will need to continue to be very broad and thin elections that serve as general rules for only the platforms that pay attention to their values before communicating with the customer in order to keep existing profit centers going.
A good way to think about them may be like a “Do Not Disturb” message on a door. As a general rule, the hotel will leave you alone. But if you request a wakeup call, order room service, or if there’s a fire, then you may have a reasonable expectation that they will knock or call.
Sending — Exceptions
For the general rules[7], there are many reasons to have exceptions in order to send customers specific information[8]. Some of them are sales related, others aren’t. Some are informational in nature, and some are life and death matters. In some of these cases, this consent has to be in writing beforehand. In others, it can be more passive, and an enterprise may be allowed to communicate for certain purposes until the customer says not to.
Where a great amount of confusion arises are crossover events — a function governed by consent from one type of corral, say, like one created by the Sharing corral defined below, sometimes generates the need to communicate with the customer, and therefore another corral, such as Sending, may be involved in controlling how and even when we can make that contact happen. One need might result in several choices of communication, each governed by a different Sending type of consent.
It’s easy in your mind to combine multiple cross-over consents into just one consent election for a product if you are reviewing a new idea in a vacuum; that is to consider consents from two different corrals as one and the same thing.
For example, if I say the words “Relevant Mobile Advertising,” am I talking about ads that are determined to be suitable for you based on all the information gleaned from your use of a cell phone account, or am I talking about any ad sent to your cell phone regardless of origin? It’s easy to have one person picture one thing in their mind, and another person picture something completely different. Later when another marketing team wants to use only one-half of that same equation — to just formulate ads, or to just send different ads that were formulated by some other means to the same cell phone…
This is where confusion starts.
Therefore, consent regarding Sending information to you as an exception must be very explicit and very narrow in definition to avoid such confusing overlap inside the company. Here are some examples of this type of narrow definition…
· Regulations dictate that an enterprise can’t send text messages about technician visits to your Cable TV premise to cells from unknown carriers without prior written consent.
· Other regulations state that an enterprise can’t send email advertising which may reach that same mobile phone without a clear way to opt-out at the bottom of each email that adheres to government standards in message content and subsequent functionality.
· Voluntary global communities have standards for when an enterprise can send ads to that same cell phone’s browser, and even that is different from the consent to send the same ads to apps running on the same cell phone.
That’s just covering a fraction of the ways that govern how we can send communications to just one device.
We’ve evaluated the feasibility of controlling end-point delivery of sent message by categories — particularly in the area of Convergent Services, and how to create user experience standards of control over devices. But with so many hardware vendors, and such rapid explosions and evolutions of platforms and Operating Systems, in a nutshell, it’s impossible. Therefore the scope of these elections must be very narrow, even sometimes dividing delivery of the same messages by different protocols — such as SMS messages to a phone as opposed to the same message being formulated into a chat messages, an in-app ads, or browser banners sent to that same device.
The Sending corral must define the precepts for general rules for sending (the Do Nots) as well as exceptions that allow contact by way of a specified end point for a specified purpose, regardless of what created the need for that contact in the first place. The contact is its own thing.
Sharing
an enterprise collects information in a number of different ways. That information usually starts out as individual, and personal. In this native state, it can serve many secondary purposes that would be profitable to the company, but they would need that customer’s explicit consent before doing so.[9]
Later this information can be obfuscated (changed at the field level — like social security number, phone number, last name, etc.), where it’s made less personal. In this anonymized and yet still individual state, it can serve many more secondary purposes, some requiring the customer’s consent, but there may be times where they simply inform the customer and allow them to opt-out.
Even later, this information can be combined with the information of a sufficiently large number of other people for it to become general behavioral or trend descriptions of a faceless crowd that shares some number of common traits. There are many different secondary uses of this information that can be profitable. Exactly two of them (some form of external marketing and analytics reports and relative advertising) are currently in most Privacy Policies today, but others are not and enterprises would need the customers’ consent before using their information in this way[10]. Even though these two uses are covered by a Privacy Policy, don’t mistake them for automatic for all humans on the planet. A customer has to take some action in order to be covered by any privacy policy — buy a product, lease a service, or otherwise engage in some experience such as a website. By any one business, 100 million customers may be so covered.
7 billion are not.
In the world of Big Data, we evaluated the technical feasibility to separate out field-level data, or otherwise segment different types of data within a service for the purpose of using this Sharing type of consent for different purposes. In a nutshell, it’s impossible. Enterprises can have millions of fields of data and only understand a fraction of them well enough to keep their word on a customer’s consent. Therefore, when we speak about the Sharing type of consent, the scope of the information covered by the consent must be “all data for a service or account.” It will be impossible at this stage to offer consent for something like a specific type of location or a social security number. It’s doable to offer consent for all of that data being used for a specific purpose such as advertising.
Largely these type of secondary uses occur after the primary purpose and collection, but some occur coincident and in near-real-time use of it, such as geo-fencing. Therefore timing isn’t necessarily a solid characteristic to help differential the Sharing corral from the other corrals.
All secondary uses of data (Sharing) stem from an enterprise’s customers consenting to share their information with the enterprise for some stated purpose[11] other than the primary use that created/collected it in the first place.
Conclusions
By defining, and ratifying three corrals for consent, that are easy to describe, and that support easy sorting for new ideas, we will go a long way to removing confusion, engendering faster development and deployment of products across even huge companies. This article has established a list of three clear corrals of consent — Accessing, Sending, and Sharing. It has established their attributes and their precepts. This article has further set forth guiding ideas to help various types of subsequent work such as creating consistent Bitmap Consent DNA for use by a Consent Management Service in much the same way that the DNS (Domain Name Service) regularly solves for IP addresses from URL name standards, as well as User Experience design or legal approaches to have clearer trajectories while avoiding competing interpretations.
[1] 47 C.F.R. Subpart U and Section 222 of the Communications Act (e.g., Enterprises must deploy safeguards for CPNI, notifications to breach, etc)
[2] COPPA (Children’s Online Privacy Act of 1998) (15 USC 6501–6506)
[3] FTC Report: Protecting Consumer Privacy in an Era of Rapid Change: Recommendations for Business and Policy Makers (2012)
[4] Do Not Mail Policy (Privacy Policy Commitment); 15 USC 45
[5] CAN-SPAM Act (Email) FCC Report and Order FCC 04–194; Public Law 108–187, 117 Stat. 2699;15 USC 7701–7713
[6] FCC Telephone Consumer Protection Act (TCPA) 47 CFR 64.1200; Do Not Call Implementation Act (DNC) FCC Report and Order FCC 03–153; PUBLIC LAW 108–10 — MAR. 11, 2003 117 STAT. 557
[7] Privacy Policy Commitments include: Email, Text messaging, Enterprise Consumer Telemarketing, Enterprise Business Telemarketing, Federal Do Not Call, Postal Mail. An enterprise’s practices are designed to satisfy state/fed legal requirements limiting marketing contacts. Those laws/regs generally permit companies to contact their own customers and in some cases, former customers, even when those customers are listed on the federal/state Do Not Call lists.
[8] There are exceptions (primary purpose, exigent circumstances, etc.) but generally may pivot off consent.
[9] Subject to a stay and possible further rulemaking, Title II has reclassified broadband internet access services such as mobile providers’ customer location and account/demographic information derived from CPNI (BIAS) under the same restrictions as telecommunication services. Beyond concern about CPNI (and new CPNI), Section 222(a) of the Communications Act also imposes on carriers a general “duty to protect the confidentiality of proprietary information of, and relating to, customers”. Enterprises have to care for sensitive data under a “just a reasonable” standard when the FCC has jurisdiction In its recent Terracom opinion, the FCC found that this provision requires carriers to protect the confidentiality of all of their customers’ “proprietary information”, even if it doesn’t constitute CPNI (In the Matter of TerraCom, Inc. and YourTel America, Inc. Apparent Liability for Forfeiture, Notice of Apparent Liability for Forfeiture, at 17, available at https://apps.fcc.gov/edocs_public/attachmatch/fcc-14-173A1.pdf (Oct. 24, 2014)
[10] Privacy Policy Commitments example: We don’t sell PII / CPNI to anyone and only share it, we may provide PII / CPNI to third party agents only for access and use to perform the obligations of the agreement, and customers have a right to opt out of EMAR and RA (not metric reports and first party marketing).
[11] Section 5 of the FTC Act — unfair or deceptive acts.
