Data Security & Privacy

Founders are obsessive-compulsive about security

Both of tipi's founder are digital natives and have been running big community and online shops in their past life. Being hackers themselves they have a track record of enforcing development practices and designing systems designed to limit and avoid data breaches.

Before running tipi.build, Damien was the cybersecurity lead for the product development of a swiss IoT company, whose product were massively deployed in the research & development offices of major laboratories, big pharma, nuclear powerplant and the most famout internet search engine providers.

Yannic has an obsessive-compulsive passion for cryptography, is a former security bounty hunter and was responsible for the for the cybersecurity assurance of numerous systems.

tipi.build founders share a true passion building software with security in mind and have prior experience dealing with high priority CVEs reported by the U.S. Department of Homeland Security towards their own software.

Website data

The first data tipi.build gets are from visitors and user of the tipi.build webapp. As you might have noted, tipi doesn't require submitting cookie preferences. It's because we don't use any third party cookies to track users and tipi doesn't share any user data to a separate analytics platform or third parties.

The tipi.build web platform is a fully custom implementation and does not relly on 3rd party services (except for cloud server hosting obviously). The data that we log is anonymized and used only for short-term debugging purposes.

Authenticating registered users

We rely on external OAUTH providers like Github.com to authenticate users, and only ask access to the user name and email. We use these information and store them in our database along with a generated unique identifier to authenticate actions on the website.

User's source code

To guarantee full data privacy and security the tipi.build cloud has no access to the user's source code outside of interactive sessions.

Indeed only the tipi cli tool scans user source code and it does this either locally or remotely within a short-lived build runner instance ( i.e. A freshly provisioned virtual machine ) started for the current build session.

The local tipi cli encrypts the source code folder as encrypted+compressed AES 256/CBC blocks that are transmitted via tipi's storage server to the short-lived build runner over a TLS connection.

The tipi storage server only ever sees an encrypted block, while the short-lived build runner decrypts it into an hard disk encrypted storage to run the build.

The storage server encrypted+compressed AES 256/CBC blocks and the short lived build runner are deleted after a timeout at the end of the build session.

The short-lived remote build runner is made accessible only trough asymetric cryptography generated on each new build session, which means that only the local machine sending the source code and initiating the session has the data to access the short-lived remote build runner and the decrypted sources.

tipi's secure vault : private repositories

On the first registration tipi.build users are asked to create a so-called tipi vault. The tipi.build vault is a cryptographically secure container that stores access tokens to user's private repositories hosted elsewhere ( e.g. on Github.com ).

These tokens are encrypted and decrypted using the user's vault passphrase by an open source C++ client-side only software library that is run in webassembly in the browser and natively in the build nodes. The vault passphrase is never shared to the tipi.build cloud.

The vault is uploaded by the user's browser as a purely encrypted binary blob, which means that even if our always up-to-date, 24/7 monitored website gets hacked and someone steals the tipi.build database, it will find at best user emails and encrypted blob that would take him more than 20 years for today's supercomputer to bruteforce the information.

No serious attacker would actually choose this road, as the encrypted token after such a databreach would all be revoked by tipi.

tipi computer pairing

To use tipi.build remote compilation and execution capabilities, it is possible to locally save a vault for use on the user computer. That means if the computer is attacked or at risk, the tokens in the vault might get stolen ( they are not saved in clear-text though ).

If an user ever suspect that his computer was subject of an attack or a data breach, it is possible to revoke access anytime and regenerate the vault and it's tokens.

On premise

Building your software with tipi.build doesn't require to use our cloud infrastructure, however making use of our extensive cross-platform capabilities and using powerful cloud nodes to accelerate the development cycle are core to our offering.

To enable organizations with strict rules about physical source code location to use tipi to its fullest we offer on-premise and private cloud deployments of the whole tipi backend guaranteeing full isolation. Don't hesitate to contact us for more info about these options !

Security by transparency

Security issues that can arise in different software components are handled and watched by the tipi team and kept up-to-date following a Live at HEAD philosophy.

Don't hesitate to connect to tipi.build, to review the tipi.build vault webassembly library fork it and review it's implementation.

We are very open and welcome critics and feedback on our architecture