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

thanks for taking interest.

maybe you can help me understand what capabilities youre interested in. i can take a look at what featured to prioritize. the project is presented as a testable demo. its useful for getting feedback. im making several changes to improve features and stability. im sure there is alot more to do.

its reponsible to maintain the wording along the lines of “work-in-progress” because as a cybersecurity project, there is a lot of scrutiny around calling it “ready” (as there should be), especially without code reviews and security audits.

the hold-up could be related not spending enough time to work on the project. as a pet-project i dont burden myself with deadlines and can spend more time on condsidering various approaches.

Not only can you avoid installation, you aren’t locked to a platform like android and iOS.

with the browser based version something similar to signing can be achieved with https://developer.mozilla.org/en-US/docs/Web/Security/Defenses/Subresource_Integrity … the update can be done with the unique hash being updated

i think along with the native build of the app, it should cover the bases for all users depending on their needs.

id like it browser-first, but its isnt limited. the features from the open source version can also be applied to the new version. but only worth doing when it reaches a reasonable level of stability.

https://positive-intentions.com/blog/docker-ios-android-desktop

versions control is especially important for cybersecurity and so details will be investigated for the best way to approach this. it would be particularly important to have locked versions that have a third-party security audit, but the project seems far from that.

in an ideal world where i manage to get the main project to be open source sustainably. it would make things more decentralized we can remove having the statics served from the internet like its possible on the opensource version. 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

not true

care to elaborate for my benefit? i could stand to learn something if you have some insight. ive tried several grants applications and places that provide funding for open source project. im aware they exist… all rejected me. im sure many are inundated with project submissions that have a more professional quality and able to articulate details better than myself.

don’t trust anything else you say

this is the way. i have open source code so i dont have to ask you to trust me. its why its important for the MVP to remain open source.

the key distinction between this project and other is that its presented as a PWA. A key cybersecurity feature of this form-factor is that it can avoid installation and registration.

why are there closed source parts?

because open source wont pay the bills.

the javascript-over-the-internet is indeed a concern that has always been mentioned about this project. to address this, 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.

as for selhosting, i hope to have something more elegant than selfhosting on localhost or using a dedicated app. the capabilities are demonstrated on the open source version and are transferrable. 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

Yes. 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 also 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.

thats right. the key distinction between this project and other like it like simpleX is that its presented as a PWA. A key cybersecurity feature of this form-factor is that it can avoid installation and registration.

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.

If you have features youd like me to compare, feel free to ask and i can tell you how it it compares.

Some technical details can be seen here if your want to draw your own comparison.

• https://positive-intentions.com/docs/projects/chat
• https://positive-intentions.com/docs/category/sparcle

Its important for things like the cryptography module to remain open source for transparency and clarity (kerkhofs principles). Open sourcing things like the p2p framework would only put me at a competative disadvantage.

The open-spource version of the project is fully functional and has always been open source. I keep it open because the project demonstrate a unique concept, which is useful to demonstrate with transparency. After seeking support for that version of the project, it is clear that there is no support for a one-man-band and so i deprecated it (and now call it an MVP). i am proceeding in a close source direction as i improve various details like UX and features.

There are several modules involved in the project. Some key parts are listed below

Open source:

• Cryptography module
• Signal protocol
• MVP version
• Various experiements / blog / website

Close source:

• P2P framework
• PWA boilerplate
• UI Components
• Storage manager

Thanks for the tip.

It would be ideal if I could find a way to interface with the tor network with Client-Side JavaScript. I’ve come across something interesting here which id like to investigate further. https://github.com/Ayms/node-Tor

threat model

It’s client side JavaScript. I think a webrtc connections is reasonably audited and encrypted. When using webrtc, ip addresses have to be shared. If the IP address could be hidden, it would improve “privacy” on my app.

It would be ideal if I could find a way to interface with the tor network with Client-Side JavaScript. I’ve come across something interesting here which id like to investigate further. https://github.com/Ayms/node-Tor

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).