$200 - encrypt data

[louis030195]

please do not start working on this task until we have some clarity on the specific subtasks to be done

can you suggest different "milestones"?

random things i think of:

• encrypt data at rest and somehow still be able to query (look how supabase/pgsql does it)
• encrypt data in http requests
• bitwarden or crypto wallet like you need a password or fingerprint to open screenpipe
• native apple, microsoft, OS encryption feature (vault etc)

any other feature that increase security (better PII removal ...)

also if anyone know how hard it would be to implement this in rust: https://github.com/mediar-ai/screenpipe/tree/main/examples/python/local-llm-pii-removal

then we can write down subtasks accordingly and start the bounty!

/bounty 200

[linear[bot]]

MED-177 $300 - encrypt data

[algora-pbc[bot]]

💎 $200 bounty • Screenpi.pe

Steps to solve:

1. Start working: Comment /attempt #466 with your implementation plan
2. Submit work: Create a pull request including /claim #466 in the PR body to claim the bounty
3. Receive payment: 100% of the bounty is received 2-5 days post-reward. Make sure you are eligible for payouts

Thank you for contributing to mediar-ai/screenpipe!

Add a bounty • Share on socials

[Saturn225]

@louis030195 After reviewing the Screenpipe repository and considering security requirements, here is a detailed breakdown of the proposed milestones and subtasks for encrypting data in my mind

Milestone 1: Data at Rest Encryption

• Encrypt MP4 files on disk as soon as they are written using AES or similar encryption methods
• Implement database encryption to secure sensitive data stored locally following examples like Supabase or PostgreSQL for queryable encrypted data
• Provide a way for users to unlock/decrypt files programmatically using native OS features like Apple’s Secure Enclave or BitLocker.

Milestone 2: Encrypt Data in HTTP Requests

• HTTP requests are encrypted using SSL/TLS and consider additional payload encryption for extra security
• Test and validate all encrypted transmissions to ensure no data is exposed during transport.

Milestone 3: Bitwarden/Crypto Wallet-like Security

• Implement a password/biometric authentication system (e.g., Apple/Windows APIs) for users to unlock encrypted data.
• Design a secure key management system to store encryption keys

Milestone 4: OS-Level Encryption Integration

• Use native OS encryption features like Apple Secure Enclave or BitLocker to enhance security.
• Implement fallbacks for unsupported OS by utilizing Rust-based encryption libraries.

Milestone 5: PII Removal & Data Obfuscation

• Integrate a PII detection and removal tool to sanitize sensitive data before storage.
• Implement logging mechanisms to flag detected PII and ensure its removal.

Milestone 6: Investigate Rust for Encryption & PII Removal

• Make Some research, explore and document Rust libraries for encryption e.g. RustCrypto and PII removal.
• Provide a proof-of-concept implementation showing Rust’s performance benefits for these tasks.

[Saturn225]

For a $300 bounty, implementing all six milestones might be too ambitious as each milestone could involve significant research, coding and testing . Maybe we can tackle other milestones in follow-up issues if considered.

After reviewing the effort involved, I propose focusing on two tasks that are feasible within the bounty scope. Here's the breakdown of tasks I am thinking to do if it aligns well

Task 1: Encrypt Data in HTTP Requests

This is as outlined above

Task 2: Investigate Rust for Encryption & PII Removal

• Research Rust libraries that support encryption and PII removal.
• Document the feasibility and complexity of implementing these libraries in Screenpipe.
• Provide initial examples for proof-of-concept code to show how Rust could handle encryption/PII removal.

[louis030195]

Here are 50 potential solutions to enhance screenpipe's security while maintaining API, file, and database access:

1. implement end-to-end encryption for all data
2. use hardware-backed key storage (e.g. TPM, Secure Enclave)
3. add multi-factor authentication for app access
4. implement certificate pinning for API connections
5. use encrypted databases like SQLCipher
6. implement file-level encryption for stored data
7. use secure random number generators for all crypto operations
8. implement robust input validation and sanitization
9. use prepared statements to prevent SQL injection
10. implement rate limiting on API endpoints
11. use HTTPS for all network communications
12. implement proper session management and token handling
13. use secure coding practices to prevent buffer overflows
14. implement secure key rotation policies
15. use sandboxing for plugin execution
16. implement secure boot and code signing
17. use memory encryption techniques
18. implement secure logging practices
19. use secure deletion methods for sensitive data
20. implement network segmentation for different components
21. use obfuscation techniques for sensitive code
22. implement secure update mechanisms
23. use runtime application self-protection (RASP)
24. implement secure inter-process communication
25. use trusted execution environments where available
26. implement secure key derivation functions
27. use secure random password generation
28. implement secure backup and recovery processes
29. use secure time synchronization
30. implement secure error handling and logging
31. use security headers in API responses
32. implement API versioning for better security control
33. use OAuth 2.0 or OpenID Connect for authentication
34. implement IP whitelisting for API access
35. use JSON Web Tokens (JWT) for secure data exchange
36. implement secure websocket connections
37. use content security policy (CSP) headers
38. implement subresource integrity checks
39. use HSTS to enforce HTTPS
40. implement API request signing
41. use secure random IDs for resources
42. implement secure file upload handling
43. use secure cookie attributes
44. implement secure cross-origin resource sharing (CORS) policies
45. use security scanners and static analysis tools
46. implement secure configuration management
47. use secure defaults for all settings
48. implement secure password reset mechanisms
49. use secure session storage techniques
50. implement secure data erasure methods for end-of-life

remember, the key is to implement these solutions in a way that balances security with usability and performance. some of these may require careful consideration and testing to ensure they don't negatively impact the user experience or system performance.

[ologbonowiwi]

A possible first step would be to encrypt the database. There are a few alternatives, like Turso, SQLCypher, or whatever we are less resistant to implementing on our codebase. We can use this keyring implementation. It's compliant with Linux, Mac, Windows, and more.

From what I see since launchbadge/sqlx#2014 we may be able to get encryption on sqlx out of the box.

My implementation plan:

• on the first initialization of the app without the key (to support this on who was using screenpipe before without deleting any data), generate a safe key and use native keyrings/vaults to hold the key
• use the keyring lib to fetch the key
• use the to encrypt/decrypt the db (when opening/closing the connection or something)

Handling media (file encryption) and using HTTPS on the API will each require its own issue. Doing everything at once, given its uncertainty, is a too-broad scope, and it is bug-prone. Because of that, I recommend keeping separate PRs for each of these things.

If you agree with the implementation plan, the first step will be to write some integration tests, ensure the API is accessing the database, interact with the API, check the values on the database, and so on. In this way, we can change the core implementation with confidence it'll not break (and if it breaks, we'll see it quickly on the PRs). But that's not on the scope of the 200$ bounty, so let me know what you think @louis030195.

[louis030195]

A possible first step would be to encrypt the database. There are a few alternatives, like Turso, SQLCypher, or whatever we are less resistant to implementing on our codebase. We can use this keyring implementation. It's compliant with Linux, Mac, Windows, and more.

From what I see since launchbadge/sqlx#2014 we may be able to get encryption on sqlx out of the box.

My implementation plan:

• on the first initialization of the app without the key (to support this on who was using screenpipe before without deleting any data), generate a safe key and use native keyrings/vaults to hold the key
• use the keyring lib to fetch the key
• use the to encrypt/decrypt the db (when opening/closing the connection or something)

Handling media (file encryption) and using HTTPS on the API will each require its own issue. Doing everything at once, given its uncertainty, is a too-broad scope, and it is bug-prone. Because of that, I recommend keeping separate PRs for each of these things.

If you agree with the implementation plan, the first step will be to write some integration tests, ensure the API is accessing the database, interact with the API, check the values on the database, and so on. In this way, we can change the core implementation with confidence it'll not break (and if it breaks, we'll see it quickly on the PRs). But that's not on the scope of the 200$ bounty, so let me know what you think @louis030195.

nice, yeah, that sounds good plan, can you take notes on overhead it adds in terms of resource usage also?

[louis030195]

https://github.com/microsoft/windows-rs/blob/master/crates/samples/windows/data_protection/src/main.rs