NOTE: This is still a work-in-progress and partially a close-source project. To view the open source version see here. It has NOT been audited or reviewed. For testing purposes only, not a replacement for your current messaging app. I have open source examples of various part of the app and im sure more investigation needs to be done for all details of this project. USE RESPONSIBLY!

Im aiming to create the “theoretically” most secure messaging app. This has to be entirely theoretical because its impossible to create the “most secure messaging app”. Cyber-security is a constantly evolving field and no system can be completely secure.

If you’d humor me, i tried to create an exhaustive list of features and practices that could help make my messaging app as secure as possible. Id like to open it up to scrutiny.

Demo

(Im grouping into green, orange and red because i coudnt think of a more appropriate title for the grouping.)

Green

• P2P - so that it can be decentralized and not rely on a central server for exchanging messages. The project is using WebRTC to establish a p2p connection between browsers.
• End to end encryption - so that even if the messages are intercepted, they cannot be read. The project is using an application-level cascading cipher on top of the encryption provided by WebRTC. the key sub-protocols involves in the approach are Signal, MLS and AES. while there has been pushback on the cascading cipher, rest-assured that this is functioning on and application-level and the purpose of the cipher is that it guarantees that the “stronger” algoritm comes up on top. any failure will result in a cascading failure… ultimately redundent on top of the mandated WebRTC encryption. i would plan to add more protocols into this cascade to investigate post-quantum solutions.
• Perfect forward secrecy - so that if a key is compromised, past messages cannot be decrypted. WebRTC already provides a reasonable support for this in firefox. but the signal and mls protocol in the cascading cipher also contribute resiliance in this regard.
• Key management - so that users can manage their own keys and not rely on a central authority. there is key focus on having local-only encryption keys. sets of keys are generated for each new connection and resued in future sessions.
• Secure signaling - so that the initial connection between peers is established securely. there are many approaches to secure signaling and while a good approach could be exchanging connection data offline, i would also be further improving this by providing more options. its possible to establish a webrtc connection without a connection-broker like this.
• Minimal infrastructure - so that there are fewer points of failure and attack. in the Webrtc approach, messages can be sent without the need of a central server and would also work in an offline hotspot network.
• Support multimedia - so that users can share animations and videos. this is important to provide an experience to users that makes the project appraling. there is progress made on the ui component library to provide various features and functionality users expect in a messaging app.
• Minimize metadata - so no one knows who’s messaging who or when. i think the metadata is faily minimal, but ultimately is reletive to how feature-rich i want the application. things like notification that a “user is typing” can be disabled, but its a common offering in normal messaging apps. similarly i things read-reciepts can be a useful feature but comes with metadata overhead. i hope to discuss these feature more in the future and ultimately provide the ability to disable this.

Orange

• Open source - moving towards a hybrid approach where relevent repositories are open source.
• Remove registration - creating a messaging app that eliminates the need for users to register is a feature that i think is desired in the cybersec space. the webapp approach seems to offer the capabilities and is working. as i move towards trying to figure out monetization, im unable to see how registration can be avoided.
• Encrypted storage - browser based cryptography is fairly capable and its possible to have important data like encryption keys encrypted at rest. this is working well when using passkeys to derive a password. this approach is still not complete because there will be improvements to take advantage of the filesystem API in order to have better persistence. passkeys wont be able to address this easily because they get cleared when you clear the site-data (and you lose the password for decrypting the data).
• User education - the app is faily technical and i could use a lot more time to provide better information to users. the current website has a lot of technical details… but i think its a mess if you want to find information. this needs to be improved.
• Offline messaging - p2p messaging has its limitations, but i have an idea in mind for addressing this, by being able to spin up a selfhosted version that will remain online and proxy messages to users when they come online. this is still in the early stages of development and is yet to be demonstrated.
• Self-destructing messages - this is a common offering from secure messaging apps. it should be relatively simple to provide and will be added as a feature “soon”.
• Javascript - there is a lot of rhetiric against using javascript for a project like this because of conerns about it being served over the internet. this is undestandable, but i think concerns can be mitigated. i can provide a selfhostable static-bundle to avoid fetching statics from the intetnet. there is additional investigation towards using service workers to cache the nessesary files for offline. i would like to make an explicit button to “fetch latests statics”. the functionality is working, but more nees to be done before rolling out this functionality.
• Decentralized profile: users will want to be able to continue conversations across devices. It’s possible to implement a p2p solution for this. This is an ongoing investigation.

Red

• Regular security audits - this could be important so that vulnerabilities can be identified and fixed promptly. security audits are very expensive and until there is any funding, this wont be possible. a spicier alternative here is an in-house security audit. i have made attempts to create such audits for the signal protocols and MLS. im sure i can dive into more details, but ultimately an in-house audit in invalidated by any bias i might impart.
• Anonymity - so that users can communicate without revealing their identity is a feature many privacy-advocates want. p2p messages has nuanced trandoffs. id like to further investigate onion style routing, so that the origins can be hidden, but i also notice that webrtc is generally discourage when using the TOR network. it could help if users user a VPN, but that strays further from what i can offer as part of my app. this is an ongoing investigation.

Demo

Aiming to provide industry grade security encapsulated into a standalone webapp. Feel free to reach out for clarity on any detailsor check out the following links:

• Docs: https://positive-intentions.com/
• Reddit: https://www.reddit.com/r/positive//_intentions
• Mastodon: https://infosec.exchange/@xoron

IMPORTANT NOTE: It’s worth repeating, this is still a work in progress and not ready to replace any existing solution. Provided for testing, demo and feedback purposes only.