Frequently Asked Questions about our private, open-source protocol
When it comes to understanding the atPlatform and the atSign, our developers are very good at raising questions about parts of our technology that are not so obvious. Although we intended to abstract most of the atPlatform away for the developers, there are many within our community who are eager to learn much more! “Ask the Founders” is dedicated to questions from our developer community for Atsign founders to answer. In this installment, Paul Armstrong, who first appeared as “paulvipond” on our Discord server, is back with more questions for two of our co-founders, Kevin Nickels and Colin Constable.
P: If you become the Google of identity, every hacker and his dog is going to want to crack you. How do you plan to prevent this and are your systems 3rd party audited?
K & C: We do not want to be the Google of identity. We want each person to be able to own and control access to their own data. The first principle for us is:
“It is provably true that Atsign cannot access your private information without your explicit permission.”
The owners of atSigns hold the keys for both access and encryption, and nobody else — including Atsign — has access to them. Thus, only two entities in the universe — the entity that shares information and the entity that receives it — can access private information that is shared between them.
P: What happens when I have shared data and my friend is offline but e.g. needs my contact details?
K & C: The reason for having cloud microservices is to provide a point of presence that can be reliably accessed over the Internet. This ensures that data that has been shared can be accessed by others even if they are offline.
It also provides a means for synchronizing your data across all your devices.
P: How do you manage the user life cycle? E.g. losing devices, logging on across devices.
K & C: We have a reasonable onboarding process at the moment that involves first connecting the mobile device with the cloud microservice using a shared symmetric key and then generating two asymmetric key pairs on the mobile device (one for access to the atSign owner’s secondary server and another for encrypting data shared with others). We first use the shared symmetric key to pair with the cloud microservice; once this is done, the symmetric key is deleted from the cloud microservice. The keys are stored in the device’s secure enclave, and a backup key is generated that needs to be stored in a memorable place for restoration and pairing with other applications and devices.
We are constantly working on improving this flow.
P: What’s to prevent a malicious app from screwing with the data produced through my app? E.g. an admin user has access to sensitive information from a company @name, but then installs a malicious app.
K & C: Our strategy for preventing a malicious app from screwing with data at the moment is to review and certify applications to eliminate such behavior. We also have an ambition to automate the process as much as we can. We are currently evaluating how to control app level access (read and write) to data using a namespace convention, which is already a part of the atProtocol spec and reference implementation.
P: What happens if I don’t renew my atSign? Does my data disappear from view across all apps?
K & C: That would be terrible! We do back up your data as part of the cloud microservice services so that in any event, data can be restored (remember, it is impossible for us to access your private data, so the backups are safe and only you can restore the data and make it useful).
In addition, we are actively working on a method to migrate keys and data between atSigns in a safe manner. This means that if someone does not want to renew their custom atSign, then they will be able to migrate to a free one and not lose any data.
Atsign is a tech startup committed to transforming how the modern Internet treats people’s data. To learn more about Atsign and their mission, check out their website.
