- 16 Posts
- 16 Comments
11·18 days agoit seems clear that i dont have enough on the project to convince/inspire confidence in you, which is understandable and respectable. i dont want you to “trust me bro”… its why i keep the open-source versions separate, its useful to be able to point to open source examples when discussing details online as i refine the implementation. you should use what you are comfortable with and you clearly know your way around cybersecurity, so i expect your judgement in how you securely communicate is better than most.
So is it about convenience, or security?
it isnt about convenience or security. while security is clearly important, the “convienience” is important for helping users to get started. from experience, pointing to a github repo is simply not enough. it has to be easy for users to get started. convinience and security both need a great deal of attention. the quality of either is dependent how much time i put into them.
expect users to audit…
i dont expect users to audit the code. at this stage in the project when im still putting it together, i can confirm this code isnt good enough to audit… third-party audits are important to have, but they are prohibitively expensive so dont expect one any time soon.
There’s nothing the browser can do to protect its data if the OS falls into the hands of an attacker
thats just wrong. its possible to combine the filesystem api and the crypto api. a previous post on the matter: https://programming.dev/post/33435342 … in this app i have a working version of passkey-encryption-at-rest. so a user has to register a passkey on their device and all the data is then encrypted at rest in indexedDB… users didnt like that every time they reload the page, the webapp was asking for a fingerprint to unlock… so that feature is disabled for now untill i make it so it can be disabled if the user wants. there is much more to think about there and that could be a whole separate discussion as we consider things like devices supporting passkeys PRF and how “recovery” could work.
censor your app
the frontend (this project), the backend (peerjs-server) and stun/turn servers can be selfhosted. but that moves away from what i can offer. id also like to investigate options for onion-style routing which the stray further from “minimal infrastructure” of p2p commmunication. https://programming.dev/post/41521230
low latency/high bandwidth the protocol was designed for
ive been working on this project for a while. it started off as a p2p messaging framework. i created a simple video calling app and the functionality naturally started leaning towards file transfer and messaging. the logical progression of the framework was to wrap it in a messaging app where you would want low latency/high bandwidth video calls and file transfer. these functionalities are in contrast to tasks like moving files between computers using some cloud service.
people need to stay fae away when security is involved
ive had this kind of fear-mongering/gatekeeping a lot in the cyber security community. its understandable to have high standard and expectation for things like security. but if kerhof’s principles are worth anything, they would apply to this project. in the open source version the concept is resonably demonstrated and there is documentation about how it works on the website. spicier things like “how the crytography works” are actively discussed online (like this). its clear that the code is too complicated for anyone to use their spare time review, buts its at least an option. i have recieved good feedback and iterated over what you see.
For anyone reading this thread looking for a secure chat app, just use Delta Chat, or even Signal (which has some issues, but it’s better than nothing).
agreed. my project is far from finished.
What is not secure here?
javascript over the internet can be be intercepted by a network admin or ISP. if acting maliciously, then it could swap the static js files for their own. particularly concern for webapps because every time you load the webpage, it would load the latest statics, which could have been altered on the network level to provide comprimised functionality. id like to have the service worker cache the statics to avoid that issue. it might be also worth repeating that you can just run the index.html in a browser to avoid fetching new statics. the app is ultimately provided as a webapp to help users get started… because it doesnt rely on knowing seemingly basic things like “how to run the index.html file in a browser” (which, im sure i know many people who dont… and i suspect thats the majority of the users)
PWA security is entirely at the mercy of whatever browser you installed it in
thats the whole point. we step away from “iOS and Android” and enable users to run this on their platform-of-choice. generally, all “modern” operating systems support browsers out-the-box. users should be responsible with how they run this app: e.g. if you trust firefox more than chrome.
they can block your TURN/STUN servers pretty easily
im using the metered.ca turn servers because they have a free plan (more than enough when i limit it to only brokering p2p connections). you have the option to use your own api key to do things like enable a “relay-mode”, which will proxy all messages. using the api key is simple UI abstraction for users to configure a TURN/STUN server. im open to make this as configurable as nessesary if users want to add multiple of their own servers.
P2P is inherently less reliable
“reliable” is a relative term. its entirely possible a centralized backend goes down. its a known fact that in a p2p architecture, peers have to be online to recieve messages… while you dont have things like the ability to send messages offline, there is no backend server in the p2p architecture to go down.
meshtastic
meshtastic is a great solution. i bought a couple units to try it out to integrated their app into my webapp: https://chat.positive-intentions.com/#/meshtastic … its basically a wrapper within my app. i wouldnt plan for go “all in” on meshtastic at all, but i see that it could be useful for smaller payloads (loads more investigation needs to be done to have anything usable). my app is speciafically based on webrtc, which has unparalelled transfer speeds; which is especially useful when sending large files. meshtastic could struggle to exchange a gif. meshtastics has a good reputation in cyber-sec, but i suspect it isnt more popular because people want modern messaging app multimedia capabilities. my app is presented as a webapp specifically for the average joe to get started.
ultimately, its always worth repeating that this is a work in progress and not redy to replace any of the existing app or services.
the ID being used is cryptographically random. its generated automatically client-side and should have good conflict resilience so someone cant guess the ID to connect to you.
that ID is used with the peerjs-server (open source, selfhostable), which is being used as the connection broker to establish a webrtc connection. Webrtc is a browser-to-browser connection and avoids routing through a central server. encryption keys are established in the initial connection on client-side. this can be used to achieve p2p authentication (without centralisation) for future sessions.
ongoing investigation: its also possible to bypass the peerjs-server entirely by acting as your own peer-broker, but i havent figured out a nice user experience for me to roll this out anytime soon. id like to investigate about exchanging the information needed over QR codes, BLE or NFC. the key tradoff is that users have to be in the same physical location. https://github.com/positive-intentions/chat/issues/6
the org can be found here: https://github.com/positive-intentions
the prerelease demo linked in the post is not open source.
do you perhaps have something running on localhost at those ports? i was trying something out, but i will disable it so it doesnt have this issue when users try to selfhost themselves.
it isnt well explained or demonstrated, but i was trying to do something as described in the link below, where i could connect a selfhosted federated module and have it work as a drop-in replacement.
https://positive-intentions.com/blog/statics-as-a-chat-app-infrastructure
the purpose was to see if there is any benefit to allowing users to host their own federated modules. i think there isnt a distinct advantage so it looks like i will remove that feature entirely.
im still think of a better name for the project before i promote it properly as stable and secure. “positive-intentions” is understandably not well recieved.
i call it a “whatsapp clone” to better describe what it can be used for. this is in contrast to calling it a “p2p instant messaging app”… that just sounds too verbose.
thanks for letting me know, i’ll take a look.
edit: perhaps this could be your issue… consider that your user-ID is the same one used when you reload the page or open it on another tab. if you open a new browser tab, it will try to connect to the peerjs server with an ID thats already in use… instead try with one incognito browser window (or a separate device).
Not ideal, but a professional audit is not an option.
To be clear, my prompt was not “create me a security audit”. it took time and effort with several stages of refinement. I suspect more effort than writing that article.
It’s open source for you to critique in a more involved way. The AI audit is intended to get to there faster. If you see any details that are wrong, I’ll be happy to take a look and update appropriately.
youre right that embarrassment is no reason to not open source it. i simply am investigating a close source direction to create a competative product.
if you interested in how this mechanics work, a very complicated version of it can be seen in: https://github.com/positive-intentions/chat (maybe you can get some AI on it.) … the p2p call demo is a module im creating to be refinement of the old p2p functionality.
im aware that security and privacy doesnt easily fit with close-source, so id like to eventually open source it when i can figure out funding. open source from the onset didnt work out how i naively thought it would in the old version.
thanks.
thats unfortunate it doesnt work. maybe a direct link to the storybook can help: https://p2p.positive-intentions.com/?path=%2Fstory%2Fdemo-p2p-call--video-call
i didnt clarify… the glitr app is a ui with hard-coded dara. the functionality in this p2p calls demo is what would be integrated into that ui. its far from finished and doesnt really “work”
my code and documentation website needs much more work before i can point to it for clarity. but i open sourced the poc version here: https://github.com/positive-intentions/chat … you may see that the UI isnt very unintuitive to use and why im going in a different direction with the UI.
pardon for copying from another reply…
i agree. they are all better and more secure when selfhosted.
my project so far is an early preview into the p2p framework in my project. with feedback i can improve the functionality as i integrate it into my messaging app.
these are good points. with peerjs this is easily configurable.
can i pick your brain about a config like the following:
const newPeer = new Peer(`blah`, { config: { iceServers: [ { url: "stun:stun.l.google.com:19302" }, { url: "stun:stun1.l.google.com:19302" }, { url: "stun:stun2.l.google.com:19302" }, { url: "stun:stun3.l.google.com:19302" }, { url: "stun:stun4.l.google.com:19302" }, ], }, });perhaps you would prefer to manually set your own config there with input fields?
id appriciate any insights into what you think users with that particular issue would like or find useful.
i agree. better and more secure.
my project so far is an early preview into the p2p framework in my project. with feedback i can improve the functionality as i integrate it into my messaging app.
its a work in progress and far from ready to be open sourced.
id like to work towards making it open source eventually.
its largely peerjs and peerjs-sever which themselves are reasonably well documented.
my app is a sideproject. its aiming to be a regular messaging app (like whatsapp, signal, etc). im not breaking any rules by being a webdeveloper developing a webapp (i already asked this question on reddit). im actively trying to turn this into something that can support me.
i dont see myself moving my work away from github. i dont know what benefits it could bring. being anonymous is not something i see as valuable when trying to create a product.
i mentioned it in the post. ‘Im aiming to create the “theoretically” most secure messaging app’… that is the goal. im not aiming for “more secure that whatsapp/signal”… but something fundamentally different in how it works. while things like webrtc and interest decentralized technology has been around for a long time, there wasnt something as general-purpose like what im aiming for.
it started as a sideproject and i kept building on it. i hope to make money out of it and have something that can support me (because ya know… bills to pay). i started off open source; naively thinking i would get open-source funding support if i demonstrated the concept to develop it further. i did several exhausting rounds of grant applications. it was an horrible experience on something outside my competence and towards the end i was dreading applying for grants knowing that they were going to reject my project. i also set up github sponsors, but nobody has donated… completely understandable for something that looks like a weekend project, but its clear that it isnt going to pay any bills.
you are fear-mongering again… its important for anyone reading this, the app works differently with user data. its all client-side. you dont need to add any personal info for it to work. ive linked how the data can be encrypted at rest. there are irresponsible ways to use any app, your data is not inherently at risk because of this implementation. if you are going to make such claims, you should make it against the code examples i’ve provided… or at least an example of what could go wrong.
i work hard on this project, so of course i promote the project on reddit and the fediverse, but you failed to mention that i also advise caution in all of my posts (including this). i hope its clear that such wording like “work-in-progress” works against marketing/promoting… i include it because its responsible to do on a project like this at its current stage.
its 2026 and AI is very prominent. people are indeed vibcoding some serious stuff. there is clearly a new wave of “developers” that dont have a concept of unit-testing, let alone the appriciation for them. ive been a developer for 10+ years and know how to do this “old-school”, but using AI is clearly a huge enhacement so it understandably looks very vibecoded. its important to study, test and review what is produced. when people get hung up on “OmG YoU’rE UsInG AI”, that seems to be an indicator for me that im not really having a real discussion. especially when i have code examples and unit tests… that doesnt mean my approach is without issues, but the code is right there. your concerns are well placed so i have some questions for you.
while you have no obligation to do anything for me, my point is that the code has been openly discussed for a while and other people have reached out about issues and i addressed them to get the project to where it is now. i have a lot more to do on the project before i can remove wording like “work-in-progress” in my communication about the project. the project is working as expected and i expect it will continue to improve.