We store Outside School and in-school data separately. These are separate areas, but we also incorporate a variety of technical practices to further the separation.
There are times we combine the data in experiences, as listed below.
How do we ensure Outside School and in-school data segregation?
Integration Tests
The majority of our tests are Integration Tests—tests that exercise multiple software components as a group to ensure they're doing the right thing. Our testing strategy focuses heavily on verisimilitude—we want our test environment to match our production environment as accurately as possible.
- We test against real databases that we run locally with comprehensive fixture data. This is a uniquely rigorous testing strategy—most advice is to "stub" (fake) the databases for most local tests because testing against real databases can be much slower. Our team has put a lot of effort into making sure this testing style is fast enough because we highly value accuracy in our tests.
- We have more than 11,000 tests for our backend servers that talk to our databases. We have more lines of test code than application code. The majority, 6,000+, of these tests focus on the resource level and verifying that the correct people have appropriate access to data. We have another 4,000+ tests focused on validating the code that fetches data from our database.
- We run regular code-coverage reports to ensure that our code has a high level of test coverage.
Engineer Privacy & Security Training
All full-time employees go through a privacy & security training session run by our CTO that covers how to keep data safe & what we need to do to keep data private for our users.
We also run regular engineer training on our data schema and how entities related to one another. This training focuses on the data in our MySQL-shared-users-data database, the relationships between those tables, and how that data can be used.
Code Separation
Apart from tests, coding patterns can make issues more or less likely. We rely on several code patterns to keep user data safe:
- Writing focused http resources that return one thing for one type of user. We avoid creating resources that combine multiple types of data in a single resource.
- We have standardized test patterns for how we test our resources that ensure that we're testing access rules.
- We have standardized required middleware that we use for every resource to ensure safe access.
- We set up focused models & query-builders that handle all of our data querying. These models and query-builders focus on single tables, and they encode rules for how data can be queried.
Bug Bounty Program
We run a Bug Bounty program through BugCrowd. The penetration testers we work with look for situations where invalid users are able to access data that they're not supposed to.
Data shared between Outside School and in-school data
Some data is shared between in-school and Outside school products. For example, there is the data shared in Dojo Islands Class and Home use as detailed here.
In Family Messaging there is the list of classmates in class, along with their family members, used so family members can coordinate experiences outside of school.