NOTE: This is still a work-in-progress and far from finished. It is free to use and not sold or monetized in any way. 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!
I usually post along the lines of "promoting my project". I'm aiming for this post to be more technical. I hope to make it clear how the project works and some features/capabilities I will be working on. Feel free to reach out for clarity.
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 with multidevice-sync. 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
FAQs:
Why are there closed source parts? - This project comes in 2 flavours; open-source and close-source. To view the open source version see here. ive tried several grants applications and places that provide funding for open source project. im aware they exist… unfortunately they rejected this project for funding. Im sure many are inundated with project submissions that have a more professional quality and able to articulate details better than myself. Continuing with open source only seems to put me at a competative disadvantage.
Monetization - Im investigating introducing clerk. I hope to use that to create a subscription model. I would like to charge $1 per-month as per the minimum allowed by clerk. I started off thinking i could avoid charging users entirely given it seems a norm for secure messaging apps to be free. but given the grant rejects and the lack of donations on github sponsors (completely understandable), but its clear that it wont be able to sustain the project. I tried Google adsense on the website/blog but it was making practically nothing; so i disabled it because it wasnt a good look when it goes against the whole “degoogling” angle. This project is currently not funded or monnetized in any way. (Its not for lack of trying)
How does it compare against signal, simpleX, element, etc? - The project is far from finished and it woudnt make sense to create something as clear as a comparison table. Especially because core features like group-messaging isnt working. Some technical details can be seen here if your want to draw your own comparison.
Javascript over the internet is not secure - im investigating the to use service workers to cache the file. this is working to some degree, but needs improvement before i fully roll it out… i would like to aim for something like a button on the UI called “Update” that would invalidate the service-worker cache to trigger an update. I hope to have something more elegant than selfhosting on localhost or using a dedicated app. its possible to provide a static bundle that can work from running index.html in a browser without the need to run a static server. The static bundle of the open source version can be seen and tested to work from this directory: https://github.com/positive-intentions/chat/tree/staging/Frontend . When i reach a reasonable level of stability on the app, i would like to investigate things like a dedicated app as is possible on the open source version. https://positive-intentions.com/blog/docker-ios-android-desktop
How is this different to any other messaging app? - the key distinction between this project and other like it like signal and simpleX is that its presented as a PWA. A key cybersecurity feature of this form-factor is that it can avoid installation and registration. its understandable that such a feature doesnt appeal to everyone, but along with the native build, it should cover all bases depending on your threat model.
What about Chat Control? - I see a lot a fear mongering in the cybersecurity community around chat-control. I aim to create something that doesn't have the censorship pitfalls of a traditional architecture. A previous post on the matter: https://www.reddit.com/r/europrivacy/comments/1ndbkxn/help_me_understand_if_chatcontrol_could_affect_my
Is it vibecoded? - AI is being used appropriately to help me in various aspects. I hope it doesnt undermine the time and effort i put into the project.
Aiming to provide industry grade security encapsulated into a standalone webapp. Feel free to reach out for clarity on any details or check out the following links:
IMPORTANT NOTE: It's worth repeating, this is still a work in progress and not ready to replace any existing solution. many core features like group-messaging are not working. Provided for testing, demo and feedback purposes only.
i agree. those (and many more) are better choices for a number of reasons. i work on this because its interesting. its open source for transparency.