The Red Sift platform creates a sandbox for your Sift to deal with the activities of processing and presenting data. Processing of the data happens in a Docker container and presentation occurs, as expected, in a frontend.
By design, there are some limitations around processing time, data access and restrictions on the process:
The sandboxes for your backend nodes are Docker containers. The local file system is therefore not persisted. You should not make assumptions that relate to the preservation of the state of your executing environment. If you need to read and write to the file-system you should use our Large Storage feature.
These restrictions are predominantly in service of the security model and performance and scaling requirements for the service. Our goal is to give you a simple way of assembling granular services to create really interesting and valuable functionality that can operate on large amounts of streaming data in a performant, safe way.
Securing our services and our user’s data is an integral part of our platform. In our digital era, nothing is more personal than our conversation channels. That’s why we are following all the current best practices to ensure a safe handling of your data. Here are some key aspects of our platform:
- We will never request or store your account credentials. Authentication is achieved through OAuth to trusted providers such as Google, Github, etc.
- After you authenticate we receive a token from those providers to represent your identity in our system. Tokens expire in short amounts of time and you can revoke them at any given moment in time through the settings of your provider and through our sign in service.
- In addition, all account information is encrypted with AES 128-bit keys.
- Red Sift’s staff doesn’t have access to your keys. We use encrypted JWT tokens.
- All the tokens we might generate internally for you are encrypted at rest.
- All data generated by a Sift are encrypted at rest with a set of rotating AES 128-bit keys.
- All communication runs through SSL/TLS to safeguard against man-in-the-middle attacks.
Updated about 5 years ago