The @platform FAQs
3 minute read
Now’s your chance to bring your app idea to life. Our free, open source platform makes it easy to create end-to-end encrypted apps that are surveillance-free and private by design — no backend infrastructure required. Our entire community is here to help you build, launch and monetize an amazing app experience for your customers.
Why should I trust you (The @ Company) and your systems?
Trust certainly has to be earned, so we have started with an open protocol specification and an open source reference implementation for the full stack platform that everyone can evaluate and contribute to. As a company, the only thing we are uniquely responsible for is the integrity of the namespace, which does not hold any private information.
The only thing that we have centralized is the verified location of where to go to request permission for access to information from someone. Our basis for trust in our company and the systems and services we provide relies on the fact that we do not have access by any means to anyone’s private data.
What makes the @platform secure?
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 The @ Company cannot access your private information without your explicit permission.”
The owners of @signs hold the keys for both access and encryption, and nobody else—including The @ Company—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.
What’s to prevent a malicious app from misusing the data produced through my app?
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 @protocol spec and reference implementation.
Who would you regard as your main competitors and how are you different?
Notionally the blockchain cohort making similar claims would be the main ones, but we believe that they are more likely to become adopters over time to provide non-repudiation and to eliminate username/password authentication which has proven to be so risky. Technically, Solid/Inrupt is somewhat similar with their data pods, but they curiously have no built-in encryption at all and are enterprise focused where we are developer/apps/consumer focused.