probably not... Because I'm comparing it to everything... but id like to share some details about how my app works so you can tell me what im missing. id like to have wording in my app to say something like "most secure chat app in the world"... i probably cant do that because it doesnt qualify... but i want to understand why?
im not an expert on cyber security. im sure there are many gaps in my knowlege in this domain.
using javascript, i created a chat app. it is using peerjs-server to create an encrypted webrtc connection. this is then used to exchange additional encryption keys from cryptography functions built into browsers to add a redundent layer of encryption. the key exchange is done like diffie-helman over webrtc (which can be considered secure when exchanged over public channels)
i sometimes recieve feedback like "javascript is inherently insecure". i disagree with this and have opened sourced my cryptography module. its basically a thin wrapper around vanilla crypto functions of a browser. a prev post on the matter.
another concern for my kind of app (PWA) is that the developer may introduce malicious code. this is an important point for which i open sourced the project and give instructions for selfhosting. selhosting this app has some unique features. unlike many other selfhosted projects, this app can be hosted on github-pages for free (instructions are provided in the readme). im also working on introducing a way that users can selfhost federated modules. a prev post on the matter.
to prevent things like browser extensions, the app uses strict CSP headers to prevent unauthorised code from running. selfhosting users should take note of this when setting up their own instance.
i received feedback the Signal/Simplex protocol is great, etc. id like to compare that opinion to the observation in how my todo app demo works. (the work is all experimental work-in-progress and far from finished). the demo shows a simple functionality for a basic decentralized todo list. this should already be reasonably secure. i could add a few extra endpoints for exchanging keys diffie-helman style. which at this point is relatively trivial to implement. I think it's simplicity could be a security feature.
the key detail that makes this approach unique, is because as a webapp, unlike other solutions, users have a choice of using any device/os/browser.
i think if i stick to the principle of avoiding using any kind of "required" service provider (myself included) and allowing the frontend and the peerjs-server to be hosted independently, im on track for creating a chat system with the "fewest moving parts". im hope you will agree this is true p2p and i hope i can use this as a step towards true privacy and security. security might be further improved by using a trusted VPN.
i created a threat-model for the app in hopes that i could get a pro-bono security assessment, but understandable the project is too complicated for pro-bono work.
while there are several similar apps out there like mine. i think mine is distinctly a different approach. so its hard to find best practices for the functionalities i want to achieve. in particular security practices to use when using p2p technology.
(note: this app is an unstable, experiment, proof of concept and not ready to replace any other app or service. It's far from finished and provided for testing and demo purposes only. This post is to get feedback on the app to determine if i'm going in the right direction for a secure chat app)
Whats with the huge amount of commented out code? Why does the huge comment at the top read like its a prompt to an LLM?
Before even considering whether the implementation is secure, you really should clean up the huge number of commented out lines. That doesn’t make it insecure by itself but holy shit does it make code impossible to review and audit.
I wouldn’t include random keys, even if noted as not being suitable for production. Installing CLI tools to generate them should be the expectation, not using provided certs/keys. Part of the setup of the development environment should include how to generate the required certificates.
there is a tonne of garbage code throughout as i have iterated and improved. its terrible practice for collabboration, but at the moment im just trying things out. in the case of the cryptography module, it was previsously part of the main chat app repo before being refactored into a federated module. its commented it out because i was testing out by toggling the functionality. of course it would be cleaner to remove, but i havent quite finished refactoring the crytography module. it needs things like unit testing. as a sideproject im fairly liberal with my coding practices to achieve what i want to test and things that read like LLM promps, likly are. various LLMs have been used to create the app as you see it. that isnt to say i didnt check and test the code being introduced.
the module federated version of the cryptography module that will replace the crypto functions done in the app can be found here
i started work on a p2p framework similarly to the crypto module (as seen here), i would make it into a federated module. it would make sense to get a review and security audit for that first.
i have asked in the cryptography communities to get feedback about the random generation and i think this implementation works. that isnt to dismiss your concerns, but its important to note the purpose of this is to be unpredictable random when connecting to peerjs-server. such a randomization is possible out of the box with a typical browser. these functions are already audited to be secure (otherwise youre on the wrong browser/os for this app). this is then combined with what can be considered as user-generated entropy (which is arguably redundent). this is my answer to what you elude to about a CLI tool to generate a value... in the app there is something you might see called "crypto signature". this is a htm5 canvas you can draw on. this input gets truned into base64 string and passed through a sha256 hashing function. this value is reasonably unpredictable when combined to the browser-provided random value. (if you try to do your own signature again, its unlikly it would be identical pixel-for-pixel).
i hope that answers some concerns. let me know if something is still unclear or i didnt answer clearly enough.
I understand where you are coming from, but if you want any real useful feedback, your repo main/master branch needs to be clean and tidy. It does look like you have some branches?
If you want to try things out and then remove it again, commit it to a different branch. The moment I see a single file like the cryptography one with so much random commented code, its a massive red flag for me.
Source - 15 years in professional software engineering
To reiterate the other comment about code maintainability, I'd suggest removing all commented out code as your next commit. With git, that information isn't lost and you can always go back to it on commit d4c981a. The easiest time to create a clean codebase is when you start the project, and the second easiest time is now. Also might be a good idea to use a pre-commit hook to check if commented code is being committed, to stop you from introducing mess in the future.
If this is web chat where the JS is coming from the server like on normal web pages, that's the death of security right there. The attacker takes over the server and replaces the JS with a backdoored version, which the users receive next time they reload the page, and that's all she wrote. That's what "JS is inherently insecure" refers to, not to the language itself, although that has plenty of its own problems. (Self-hosted servers aren't especially immune to takeover, if that's what you're thinking).
This post is to get feedback on the app to determine if i’m going in the right direction for a secure chat app
You are going in the wrong direction, sorry to say.
Before going further I'd encourage you to spend some time with the wonderful book "Security Engineering" by Ross Anderson. The 2nd edition is online as free pdf's on the author's home page, and parts of the 3rd edition are there too. Don't treat it as something super technical, but rather, as a manual on how to be paranoid.
So, assuming there is once a trusted loaded version (which HAS to be the case anyway otherwise you can't start, the same as one would do with a native executable) then there can't be an arbitrary version loaded next without it being validated first.
PS: I'm not saying this what OP does, I'm saying executing code (Javascript or not) that must be downloaded first is not in itself a security problem.
Ok, I looked at the Mozilla page. If I understand it right, it lets the server specify a hash that the client checks against a remote resource such as script from a CDN. So that can help notice a compromised CDN, but not a compromised server. If the hash is permanently stored in the browser, that is better, but there are also browser updates to say nothing of exploits. This approach just seems doomed.
Added: hmm maybe you could load the page from a local page or bookmarklet containing the hash. But then the whole app might as well be local. It was once possible to sign JS with a code signing certificate but I haven't heard about those in ages.
What you're looking for is called remote attestation but again, many attacks possible.
thanks for your thoughts. im sure others would have similar concerns.
The attacker takes over the server and replaces the JS with a backdoored version
this is a core concern why the app is open source and selfhostable. details are provided in the readme to create a selfhosted fork that runs on github pages. there are several ways around this concern described here.
You are going in the wrong direction
thats unfortunate if you still think so, but id like to hear any other concerns if you have any.
Why do you expect that the JS that the server sent you this time is the same as what you audited earlier? Self hosting doesn't help against unfriendly takeover. I will look at the other post about hashing. Maybe that helps, depending.
For it to be the most secure app in the world, you'd need to understand the main attack vectors, and how to mitigate them. You'd have to understand them and how you mitigate them better than how Signal or Element mitigate them. Finally, you'd have to get it audited by a reputable security auditor than will validate your claims.
If you do not have the money, best bet is to have a donation method or 2, like Liberapay, Open Collective etc. and fund raise for it. Active users are more likely to donate, so get folk using it. Focus more on what it is and it's advantages. "A secure chat app that can be run regardless of hardware out of your browser*. Long term aims to be the most secure app in the world. Join us on that adventure."
If you do not know, learn. If you really want to create the most secure chat app in the world, you have to become a subject matter expert, know the challenges and rivals. There is no shortcut in this. Depends how much you want this.
Oh, and yeah, JS, if you're using node, keep your app and dependencies scanned and up to date constantly.
in the post is my learnings of possible attack vectors and how to mitigate them. i try to go into more into exhaustive details in the threat model. do you think something is missing?
unfortunaly i think i may be illiterate in funding and business side of things. i have tried to set up serveral donation platforms as seen on the repo. nobody has ever donated. this isnt a shock, considering its experiemental and unstable. i also dont know how to really ask for donations. is it something like saying "support us on Liberapay" at the end of a post? at best i can only hope to get a spike in donation and not enough for a security audit. ive asked around and it seems a decent assesment would cost a decent amount.
i also tried applying for several grants. this was an exhausing experience and so i stopped. it seems the advice is too keep applying until bingo, but from the onset it isnt something i know anything about so no doubt several more rejections. (one particular rejection mentioned it wasnt as innovative as simplex). the whole process here is not understood, enjoyable or fruitful. i think its sometimes hard to explain concepts about the app on reddit and lemmy... im sure those concepts are further difficult to communicate and understand in an appealing grant application.
i think the jorney to get the app to where it is has been a learning experience. not just about the apps technical details, but how to communicate about it publicly. ive regularly seeked advice on the approach. i dont have any qualifications in the field, which is an important challenge many point to. when can it be said that im a subject matter expert? i can create this app and i can answer questions about it, but im not ready for any cryptography exam.
I think saying someone is stunted when they are learning is pretty out of line. OP has asked for feedback on his project and has been polite and cordial.
I think my writing is radically improved and maybe even more clear when I use an LLM. In my experience, when I do this, it seems people are more reluctant to reply to a wall of LLM text as it's seen as low-effort.
I think my app has some strange concepts which are hard enough to explain in my own words. Im sure it must look like bs when it's clearly LLM output.
I think just learning to write better can be achieved with more thought and care, but for me it can become a bit obsessive over the use of words and how they might be interpreted. So I usually just go off the cuff.
As organizations become bigger, I think they can get a better marketing team. The main heavyweight in chat-apps is whatsapp. I think we can agree that it isn't transparent.