Open Private Data Architecture
In Open Private Data Architecture (OPDA), application data is managed by the user and not by the app developer as common in today’s Software-as-a-Services (SaaS) products.
The principles of the architecture are:
- The user is responsible for their data, including storage provisioning and costs.
- The user controls the access to their data, e.g., via cryptography, and no third party is allowed full access to the data.
- An OPDA-compliant app keeps all user data in that user’s storage, no information is sent to the developer or any other third party. As a corollary, no third party authorization or verification is required for using the app (e.g., phone number verification).
- When an OPDA-compliant app obtains services from a third party, e.g., maps, or shopping, the app may send some user data for the purpose of obtaining the service, but has to clearly inform the user of the data being sent, and obtain their consent.
Software-as-a-Services and the Thin-client model
Many online products such as web-based email, messaging, online shopping, and social networks, follow the thin-client architecture (SaaS). The client (mobile app or web page) is a thin presentation layer, while most application logic and data is managed by a backend run by the product operator.
This model is used almost universally due to its technical and business advantages. On the technical side, it allows delegating computationally and bandwidth intensive functions to powerful servers, supports continuous deployment and hot fixes without frequent client updates. On the business side, it allows aggregating user data and extracting business insights that can be monetized (e.g., via ads). Monetization allows funding development and maintenance, which often allows leaving the product free for the user.
Recently, the drawbacks of the SaaS model have been coming to the attention - even though the app may be free, an indirect cost to users is their exposure to tracking by service providers. The content users produce, their behavior in using the app, locations being visited, communication, etc., are being recorded and retained by the operators. The server code and deployments being proprietary, users have no visibility into the volume and granularity of tracking, data security and retention policies, sharing with third parties. By using any SaaS products, the user places blind trust in its operators and admits to unrestricted and unaudited control of their data - both the data contributed directly (e.g., messages, purchase activity) or collected indirectly (e.g., locations, page views).
For products that involve private communication and collaboration between user, there are currently no solid non-SaaS technologies. The developer has to maintain a backend and is forced to become product operator. As operator, the developer carries the burden of being custodian of the user data, and the technical and legal responsibilities associated with it, from paying for storage and securing user data, to moderating the content, preventing spam and other kinds of abuse of its resources. While some of these do benefit the user, it is often hard to strike the balance between the true needs of the heterogeneous user base, including privacy, and operator’s own interests.
The coupling between developing and operating the product disincentivizes opening the architecture and protocols, to avoid losing lucrative tracking data and monetization opportunities, to alternative clients. This in turn reduces competition and increase barriers of entry.
Open Private Data Architecture
OPDA is an alternative architecture to SaaS, attempting to address the above drawbacks by moving the responsibility for user data from the developer to the end user. Users become responsible for hosting their data, not unlike how they procure their internet access today. A user explicitly authorizes an app to host their (user’s) data in the user’s own storage, and can revoke the authorization from an app at any time.
An advantage, for the app developer, is that data ownership, liability, and storage costs are no longer their concern. The developer no longer needs to operate a backend and can focus on building the best user experience. In other words, while in SaaS the client is a thin extension of the developer-operated backend, in OPDA it is the other way around - the app is client-heavy, and the user-provided storage is a lightweight extension of it.
Note that we have potentially lost some advantages of the SaaS architecture, such as the ease of deployment and hotfixes, and the ability to monetize the product and its continuous development - however controversial is monetization via ads and tracking, it is what allowed many of today’s free products. Until good solutions are found, OPDA approach may not be broadly applicable.
Some operators maintain, in addition to the app itself, related services that may naturally be better operated in a centralized fashion. For example a curated directory of users or services, or a payment system. In the OPDA approach, such services would be decoupled from the core app, and an OPDA app would access them via an API, potentially sharing the relevant user data (with user’s consent).
SaaS vs OPDA mobile messaging
SaaS Thin Client Architecture
OPDA Architecture
