Atom54: Invert the Scope
Privacy and Security
Privacy
The more users rely on software in their daily lives, the more personal data they share with various applications and services.
Is it good for the users?
To access new, exciting features users are forced to give away personal information. A constant tension exists between functionality and privacy. The more powerful and attractive the functionality becomes, the greater the compromise on users' privacy.
Let’s explore an example.
I’m using “CinemApp” - an application for keeping track of all movies I’ve watched. This application requires registration and will store my watched movies record. It would ask me about my personal taste, and location, in order to provide better recommendations for movies in theatres nearby that I might like. It would ask for access to my calendar and credit card details in order to book tickets.
This is a really narrow use-case application, but it already knows manifold of information about me.
What if I want to try an alternative application that stores records of movies watched and in addition these of attended concerts? Will I be able to migrate my data?
How about planning a movies night out together with a group of friends? Will they all be required to install the app and register as well? Will we all be obliged to share our personal information to allow the app coordinate planning and scheduling?
What if the application ceases to exist or is no longer maintained? Will my movies records be lost?
The users not only grant access to their personal data, they don’t have control over how this data is used and stored.
Is it good for the developers?
User data is a prerequisite for software, especially a modern AI-powered one, to deliver quality services. However, personal data is not only problematic for users to give out, it is also challenging for developers to gather, manage, and protect. Instead of focusing on the key differentiating feature in their product, the developers have to address tasks related to data collection, storage, and implementation of data access and security.
These fundamental tasks, common to all software products, become a significant barrier to the adoption of new software, especially for smaller companies and individual developers. With great power comes great responsibility. Acquiring user data allows developers to provide innovative and unique services, but also imposes maintenance and security requirements and obligations, which are costly in terms of both - time and effort.
Summary
All the above constitutes the same problem with different possible angles to look at:
Users are forced to grant excessive access to their personal information and lost control over their data
Developers are forced to engage in repetitive, exhaustive and costly efforts of gaining user trust, collecting, and maintaining user data
The very same user data is scattered and replicated in multiple silos, over and over again on various servers for various purposes.
Code comes to data
Atom54 addresses the set of challenges described above by adopting and implementing the “code comes to data” paradigm. In this paradigm all data is stored at the user’s medium of choice. The user maintains full ownership of their data. It is the user who decides how and where this data is being stored, and it is the user who decides what code is to run on it and when.
Upon user’s request, a corresponding code module can be executed on the data, without exfiltrating any personal information to third parties. The action is only finalized with the user’s approval.
An Atomic component has no direct access to data. The Atomic code units are stateless and cannot communicate with one another. The inputs and outputs of the Atoms are declarative and managed by the framework.
This way the Atomic software is fully defined by its data flow, and access to data is governed by the framework. The data flow can be analyzed and privacy policy rules can be enforced.
Data privacy is built-in into the very core of the Atomic software.
Security: Isolation
Privacy guarantees are only as good as the security is. Atoms or compounds of Atoms can be executed in isolation from each other:
Each code component is a pure JavaScript object and is sanitized and frozen at load time. Each component can be executed in a sandbox.
Depending on the execution environment (web, browser extension, server API, etc), different security/isolation solutions can be selected. The levels of security can be adjusted, and made suitable for sensitive data as needed, for example, to handle financial or medical information.
Due to its composable architecture (please, read the post below, if you haven’t already), Atom54 can compose complex and meaningful software solutions from stateless code components in a privacy preserving and secure manner.
To learn more about Atom54, please visit our website, repository, read our blog or get in touch.