thanks! will delete.
positive_intentions
Thanks. I've com across it before. You can find the corresponding security audit online.
Ive tried to address those concerns and I try to give details about it here: https://lemmy.ml/post/18497337
Thanks for the tip. WebRTC is using aes-128, I see in my code I'm using RSA. It sounds like a good idea like to create a cascading cypher with aes-256 which seems to be regarded as "military grade" (but it seems there is no official spec definition for this).
thanks! i'll make a note of that to add. it looks reletively simple to implement in JS, i'll need to check more about browser compatability. tls 1.3 is already in use. i otherwise have wording throughout that users must trust who they connect to.
as for browser extensions, there are CSP headers set to prevent them from accessing personal details.
impossible to update the software
considering the app amounts to a bunch of statics. they wint update themselves if you dont want it to. the app works in many different forms because all form factors can have nuanced security details. its better for security that if people have the ability to selfhost, then they also have the option to choose the form-factor they use based on their preferences.
All nice ideas! I'll take a note. I'd like to make time to make it so on each initial connection it generates new keys too. This should be what I think is forward-secrecy. (Let me know if I'm wrong.)
I don't know the specifics of VPN and it's implication with webrtc, I tried testing and sharing my observations here. I'm open to advice here.
You asked about native builds... Tbh I don't know much about it. I did a short search-engine search and these seem to be well regarded. (Currently?) As a pwa I have a lot of flexibility in the apps form-factor. I was thinking about how easy it would be to make it into a browser extension. (It's not about it being useful, but just providing that extra option.)
I think for my app to be regarded well in security I think it's important for people to use their own instances. The "live app" as I call it is an experimental proof of concept. I wondering about the idea that the app is run on your own forks, but occasionally sync from upstream. As it stands my app is too garbage for anyone to want a copy, but that should eliminate those concerns.
It's also an offline first pwa. Right now it fetches the latest version, but I don't see why I can't create a toggle on the UI to not fetch if there is cache... Again the app is unstable and experimental. I'm working on fixes and improvements as I see it to make a better app. It's a while away from being able to advocate selfhosting to users. But in theory it could address your concerns?
Many attack vectors still indeed exist. With P2P web tech it seems that this allows for an interesting approach and could help reduce the attack-surface. The app is available for iOS, android and desktop. Let me know if you have more concerns.
My bad. I noticed the ego sometimes inflates which seems to stem for naive confidence.
I have observed pitfalls of other apps like mine. In particular one called crypto cat. I'm sure I can't ever be exhaustive enough in learning from other examples.
Reducing metadata is indeed the goal of security and I think I have it reduced to a level where I can exchange webrtc connection data over QR codes or plain text. The IP is exposed at this point but I think this can be further scrubbed with a VPN. Perhaps this is interesting for you. It the minimum example of establishing a webrtc connection with plain text. Not user friendly, but it work without a peer-broker service. In the app I'd like to frame this around exchanging data over QR code.
As for the bitcoin wallet thing, I would think so if it's well tested and ironed out well. As long as I can facilitate the downloading of the data (for backup) and the data syncing between devices then it would be doing that without registering to any backend. There are countless examples of bitcoin exchanges collapsing and taking people's assets. The same could be said with the quality of security provided by chat app providers.
alas, we circle back around to "javascript is inherently insecure".
especially the ones that run inside web browsers like this one does
i dont think this is a valid assersion. it seems wrapped in vagueness about the attack vector. as a webapp it has to be sandboxed in a browser. any vulnerabilities will be related to that. i often hear about browsers having backdoors (which is possible), but theyd be saying that in a world where their operating system is more likely the attack surface. id like to discuss that as a webapp, (and a suitable security stack), this app is secure. take for example any existing secure app (signal/simplex/whatsapp?). they can have all the required bells and whistles for secure/private functionality. but all that encryption can be undermined if a typical low-end phone+os is more than capable of snooping your screen. the same as would apply for my app running in a browser. my arguament is if you dont trust google, you shouldnt use chrome. with a lot of those native offering, your choice is limited to something like apple or android.
this app is also contains builds for iOS, Android and desktop. i dont promote them because im simply not convinced that these native builds are better than what web-technology can provide. a recurring concern is the reliablity of the statics served... it seems thats easy to eliminate if i make it open source and selfhostable. it puts me at a competative disadvantage, but consequently it is unparalelled in the devices it can run on.
APT are a valid concern as any. if this is something youre worried about, i think using this app with a trusted VPN in combination to using disposable profiles, it should be easy to achieve. the mitigation for APT seems simple if that is a concern, but let me know if im overlooking something. webrtc can leak ip addresses and after investigating this, i think you can achieve a reasonable degree of "hiding your personal IP address" based on the information here.
compared with dedicated solutions
the purpose of this project is to create a secure chat app. i want this app to be one of those 'dedicated solutions'. as it stands, its created by a baboon sat in front of chatgpt. but the goal is indeed to create something with unparalelled security. people always seems to avert the idea of this app being secure on the grounds that its JS, but i havent come across any credible way to undermine its security without having compromised the stack above the app (browser/os/peer/network) if any of those are a concern, the app is presented in various distributions from website to native builds.
i hope im not coming across as stubborn here. i really think this app represents a different paradigm in security that nobody is exploring. i dont think ive noticed any lack of interest in decentralized or p2p technology, but nobody seems to be working on this kind of app as a webapp. i find that its not only possible, but i think its relatively trivial to get basic functionality together. i understand that the user-experience isnt great at the moment and will limit the people who want to use it, but on the security grounds alone, i think i could be a real-contender for secure chat.
You conern is well placed. This is why the project has to be open source and I encourage selfhosters.
If this is your concern, I think the offering from other apps is much more shady. While many projects are open source, when provided from an app store you have much less ability to verify the binaries involved match the available source code. It's at this point backdoors can be introduced. (It may be noteworthy that my app serves code unminified for transparency)
As it stands for me app. It's unstable and so I suggest always using the latest version because I will be adding fixes. It is an offline-first pwa. It's possible to make it so it doesn't fetch statics if it already has a cached vopy. At this early stage it doesn't make sense to use this feature because the project is unstable and recieving various fixes and improvements throughout. (There is no audited version of the app.)
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.
Thanks for the advice. I'll try set aside some time for this.
Yes.