The Law You Didn’t Know You Need
Over-The-Top Application Program Interface Privacy (OTTAPIP)
What’s the problem?
When you bought your last mobile device, there’s a strong likelihood that businesses you don’t even know immediately began collecting and exploiting your sensitive personal information because a total stranger gave them permission to do so years ago…
…and you have no way to make them stop.
How did this start?
There are businesses that provide services across all industries, such as telephone companies, social media platforms, operating systems, app stores, and other businesses like banks and insurance companies, and even healthcare providers and automobile manufacturers. These Services span across all sectors. For example, hotels and even mining companies.
In 2007, it became wildly popular for Services to open up layers of Application Program Interfaces (API) to 3rd Party Developers (e.g. makers of apps…we all love apps). They did this in a heated battle for market domination in their various industries. Virtually every industry participated to some degree.
For example, your healthcare insurance company is likely accessing your weight from your car dashboard.
(gotta love that!)
You know what an app is. You love them. And when you install them, they ask you if they can access any range of data on you: location, contacts, and even your camera and microphone. But how does that app actually access and use that data?
In part, they leverage the 3rd Party Developer Ecosystem, or API that the Services provide to them, typically for a low monthly fee they charge the app developers. That is the business model that became wildly popular over 10 years ago.
Yet there was a problem. Operating Systems started shutting down what apps could collect directly from devices. So Service API’s became more important. But, in order for an app to securely call a Service directly, the Service would need to issue a some sort of security certification. That’s expensive and hard. And even if they solved all of that technical mess, the performance to you would be awful and you would hate it. So, the logical thing to do for the app developers was to have copies of their app call their own home server, which in turn would call the Service’s API…en masse through a single pipe.
But performance was still an issue, so those Services (phone companies, social media sites, etc.) allow the app home servers to just call whenever they like to store a copy of your information in their own servers. Now the apps can more quickly access your info from their own home server.
Did you get that? Once you install an app and agree to their terms in order to use it, their home server is likely calling any number of Services day and night collecting and storing data on you, whether you’re using the app or not!
Is that as bad as it gets? Not on your nelly!
If you delete the app, there is no ability for that app to “notify their own home server” that the app has been deleted. Which means the app home server never stops gather data on you forever.
But it gets worse (I know!).
The only thing that might prohibit the 3rd Party that owns that app home server from outright selling your information to hundreds/thousands of other businesses, or worse — even governments, is that in some cases, the Service required them to sign a piece of paper saying they wouldn’t do that.
(yeah…right)
But that piece of paper is there more to protect the Service than the app provider. A large number of app providers get into business just so they can sell your data.
Think about that the next time you install a flashlight app on your phone.
As bad as all that is, now the story takes a decidedly darker turn…
If someone in 2009 had a cell phone and installed dozens of apps (e.g. flashlight), they likely gave all those apps access to their sensitive, personal information. And if that same person cancelled their cell phone service two years later, after 90 days their phone number was returned to a pool. If you purchased a phone in 2011 and got assigned that same number, your data started getting collected by dozens? hundreds of 3rd Parties?
“When you bought your latest device, there’s a strong likelihood that businesses you don’t even know immediately began collecting and exploiting your sensitive personal information because a stranger gave them permission years ago…and you have no way to make them stop.”
There is no way for you to know and no way for you to shut it off.
Now try to sleep at night. We need a new law!
How do we fix this?
Firstly, you don’t want to stop using the Services you know and love. You just want them to stop their use of your information for what is called “secondary purposes”, or exploitation of your information.
Today, you can go to the Services directly and demand they stop all secondary uses of your information, but this will likely require you to navigate their privacy policy and in many cases require you to take several additional steps, all of which are different for each Service Provider.
It can take a long, long time.
Secondly, you should go to a trusted privacy or information rights licensing agent, such as PrivacyCo-op.com. Search up each of these direct Services exploiting your information and terminate all secondary uses. This will stop their direct ability to do so.
But in either case, in theory, telling a Service to stop should also extend to all access from their own 3rd Party Developer Ecosystem. But don’t count on it. Most Services don’t include that shut off voluntarily because that would cost money, in some cases a great deal of money because they never envisioned it in their architecture to begin with.
Therefore, they need to be compelled to take further steps, and unfortunately that means some legal action.
What kind of legal action is needed?
While Privacy Agents like PrivacyCo-op.com can and will bring class action suits on behalf of their own members, this still doesn’t scale well across all industries. And as more and more of these suits are won, some pressure will be felt by these Services to mitigate their own liability, and in acts of self-preservation, they might voluntarily implement some solution. But again, it will be different for each Service, which again will cause you hassle to terminate secondary uses.
What is the real and best solution?
We can solve this problem rapidly once and for all. All we need is a simple, direct legislation. It can be easily written into a clean, unencumbered bill that includes the following provisions.
1. Penalties for Services that do not implement these OTTAPIP API.
2. Safe Harbor for Services that do implement these OTTAPIP API.
3. Simple Registries (lists) for Privacy Agents and Services
4. The actual OTTAPIP controls that are provided by each Service so you can easily make them stop.
You can see Appendix A for more technical details on these items. It’s really not that complicated, and any junior developer can stand these up in a matter of days.
What is the expected user experience?
Independent watchdog groups can pull lists from various registries for self-stated Privacy Agents and/or Services. Governments can audit Privacy Agents and/or Services using existing privacy regulations.
You can do your own research, find a Privacy Agent you trust, and use them once to select an individual Service or all Services and shut off all OTTAPIP uses of data from a particular device. You simply enter an identifier, such as a phone number, email address, or an account number, and agree to some terms. You would then receive a secondary authentication request on your cell phone or in email, and follow the instructions from the Privacy Agent.
That’s it! That’s all you would have to do. You would then receive back information from the Privacy Agent that includes confirmation or error messages from all Services included in your request.
By this law, it would be legally required for all Services to terminate all secondary uses of your information as defined by the request from the Privacy Agent.
How does this solve the initial problem?
If you carry a device with an identifier, such as a cell phone with a phone number or SIM card, or a computer or tablet with a MACID, you now have a trustworthy way, in one step, to request all registered Services to immediately terminate all secondary uses of sensitive and personal information that is likely being gathered and exploited by other businesses you don’t even know about.
Conclusion
Join us in demanding that champion legislators in various nations sponsor this bill and see it through to law.
Appendix A — Technical Specifications
1. Registries: that can be easily created in a decentralized mechanism initially hosted by Privacy Agents, trusted privacy or information rights agents (non-profits or cooperative associations established that speak on behalf of the privacy of their participants and members, as defined by any number of existing regulations internationally, such as GDPR and others) and/or some other trusted entity such as blockchain or registry providers. These registries will start out simple and easy to implement in a matter of days, can evolve via existing standards bodies over time, and must be fronted by standardized API defined by this bill
a. A Privacy Agent Registry that includes but is not limited to:
i. A request for the complete registry.
ii. A post for other Privacy Agents to be added with all required supporting fields of data.
1. Each Privacy Agent record must include but is not limited to:
a. agent ID
b. agent Name
c. website
d. responsible officer
e. contact information
b. Service Registry that includes but is not limited to:
i. A request for the complete registry.
ii. A post for Services to be added with all required supporting fields of data.
1. Each Service record must include but is not limited to:
a. Service Name
b. website
c. responsible officer
d. contact information
e. exposure URI root for the required Service API
2. Standard Privacy API’s: that must be exposed by Services and can be called by registered Privacy Agents per Service’s exposed URI root. These secure API include, but may not be limited to,
a. authReq: A secondary authentication request for a stated identifier. Most Services already have such and it should be easy and inexpensive to repurpose it. This secondary authentication will only send a verification out if the stated identifier is known by the Service, is found void of fraud, and which includes securely sending into the Service:
i. an agent ID
ii. an agent session ID
iii. an identifier for the individual person or device, such as a phone number, email address, or account number.
iv. the type of that identifier (i.e. phone number, email, or account)
v. a verification contact point (typically a phone number or email address for a PIN)
vi. RETURN JSON:
1. a string limited to 355 characters (used as a session token for the Service, for example)
2. error code, if any.
b. authPost: A secondary authentication post which includes:
i. an agent ID
ii. an agent session ID`
iii. a string limited to 355 characters (used as a session token for the Service, for example)
iv. RETURN JSON:
1. boolean approved/rejected
2. error code, if any.
c. termPost: A post to terminate secondary uses of information by type.
i. an agent ID
ii. an agent session ID
iii. a string limited to 355 characters (used as a session token for the Service, for example)
iv. termination type:
1. all secondary uses listed in the Service’s Privacy Policy, including all 3rd Party Access
2. granular standard use type per standard data use registry, such as but not limited to:
a. 3rd Party API access
b. Relevant Advertising
c. Targeted Advertising
d. External Marketing and Analytics Reports
e. Health Studies
f. Epidemic Tracking
g. Traffic Studies
v. RETURN JSON:
1. boolean approved/rejected
2. confirmation JSON, which includes but is not limited to
a. confirmation number
b. date
c. pertinent log information
3. error code, if any.