Seeking Input on App Data Sync Process and API
- I am seeking feedback on my approach to creating a data sync process and supporting API for an app I am developing. Here are the core principles guiding my app and API:
- Free: The app/API will be available for use at no cost.
- Open source: Both the app and API source code will be openly accessible for public use.
- Decentralised: Users can run the API service on any server and share it with other users, promoting autonomy and flexibility.
- Anonymous: User information will not be collected or stored alongside their data to prioritize privacy.
- Secure: User data will be encrypted before transmission, ensuring data security and confidentiality.
The plan is to set up a default instance of the API on a public server for initial user syncing. However, if the app gains popularity, users can create their own instances for personal use or share with others to ensure uninterrupted service availability. This model encourages self-sufficiency and independence among users for privacy, reliability, and cost-saving purposes.
User Sync Journey Overview:
- User downloads the app and generates data during app usage.
- When ready to sync for the first time, user enters a "password" used to encrypt their data locally without sending the password to the server.
- User clicks "Sync," sending encrypted data along with a unique ID to the selected API instance for storage.
- Subsequent syncs involve locally encrypting data using the saved password before updating on the server with the unique ID.
- To retrieve synced data, the unique ID is sent to the API for encrypted data retrieval, decrypted locally using the user's password.
The app is built in javascript, while the API uses Node.js (restify) with MongoDB as the backend. A typical sync interaction with the server appears like this:
1. Initial Sync
POST /api/data
Post body:
{
"data":"DWCx6wR9ggPqPRrhU4O4oLN5P09onApoAULX4Xt+ckxswtFNH/QQ+Y/RgxdU+8+8/muo4jo/jKnHssSezvjq6aPvYK+EAzAoRmXenAgUwHOjbiAXFqF8gScbbuLRlF0MsTKn/puIyFnvJd..."
}
Response:
{
"id":"507f191e810c19729de860ea",
"lastUpdated":"2016-07-06T12:43:16.866Z"
}
2. Get Sync Data
GET /api/data/507f191e810c19729de860ea
Response:
{
"data":"DWCx6wR9ggPqPRrhU4O4oLN5P09onApoAULX4Xt+ckxswtFNH/QQ+Y/RgxdU+8+8/muo4jo/jKnHssSezvjq6aPvYK+EAzAoRmXenAgUwHOjbiAXFqF8gScbbuLRlF0MsTKn/puIyFnvJd...",
"lastUpdated":"2016-07-06T12:43:16.866Z"
}
3. Update Synced Data
POST /api/data/507f191e810c19729de860ea
Post body:
{
"data":"DWCx6wR9ggPqPRrhU4O4oLN5P09onApoAULX4Xt+ckxswtFNH/QQ+Y/RgxdU+8+8/muo4jo/jKnHssSezvjq6aPvYK+EAzAoRmXenAgUwHOjbiAXFqF8gScbbuLRlF0MsTKn/puIyFnvJd..."
}
Response:
{
"lastUpdated":"2016-07-06T13:21:23.837Z"
}
Data storage in MongoDB format:
{
"id":"507f191e810c19729de860ea",
"data":"DWCx6wR9ggPqPRrhU4O4oLN5P09onApoAULX4Xt+ckxswtFNH/QQ+Y/RgxdU+8+8/muo4jo/jKnHssSezvjq6aPvYK+EAzAoRmXenAgUwHOjbiAXFqF8gScbbuLRlF0MsTKn/puIyFnvJd...",
"lastUpdated":"2016-07-06T13:21:23.837Z"
}
Data encryption utilizes CryptoJS's AES implementation, generating a 256-bit key from the user's password for secure data transmission. Concerns to address include potential data breaches and safeguarding against abuse of the service.
- CryptoJS AES Security: Is the level of encryption provided by CryptoJS AES strong enough to prevent unauthorized decryption of sensitive data?
- Data Submission Control: How can data integrity be ensured when allowing open access submission within the API? Implement practical measures without compromising guiding principles.
- Service Abuse Prevention: Sustain server space efficiency by monitoring and limiting user actions such as spamming sync requests and excessive data storage.
Your insights and suggestions on improving this approach while upholding core principles are appreciated, especially if you know of similar implementations worth referencing.