https://github.com/positive-intentions/chat

probably not… 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 a cyber security expert. im sure there are many gaps in my knowlege of 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 (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 and instructions are provided. 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 think if 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 hoping this will lead to true p2p and i hope i can use this as a step towards true privacy and security.

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.

i created a decentralized todo list demo using the p2p framework used in the chat app. this is to demonstrate the bare-minimum functionality of decentralised messaging and state management.

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.

  • Arthur Besse@lemmy.mlEnglish
    6·
    3 months ago

    Regarding your browser-based thing: what are the specific capabilities of the “threat agents” (in your threat model’s terminology) which your e2ee is intended to protect against?

    It seems like the e2ee is not needed against an attacker who (a) cannot circumvent HTTPS and (b) cannot compromise the server; HTTPS and an honest server will prevent them from seeing plaintext. But, if an attacker can do one of those things, does your e2ee actually stop them?

    The purpose of e2ee is to protect against a malicious server, but, re-fetching JavaScript from the server each time they use the thing means that users must actually rely on the server’s honesty (and HTTPS) completely. There is no way (in a normal web browser) for users to verify that the JavaScript they’re executing is the correct JavaScript.

    If you run a browser-based e2ee service like this and it becomes popular, you should be prepared that somebody might eventually try to compel you to serve malicious JavaScript to specific users. Search “lavabit” or “hushmail” for some well-documented cases where this has happened.

    • positive_intentions@lemmy.mlOPEnglish
      1·
      3 months ago

      thanks for the info.

      threat agents

      in a p2p system the key components seem to be things like the network, peer, device, os, browser. all those things can be compromised either on yourside or on the peer’s side. its critically important for security that these components are secured to a reasonable degree. threat agents could mean things like device manufacturer, ISP or even someone looking over your shoulder taking notes. not sure how exhaustively to describe threat agents here but these are the components that make up the system and have understandable nuances to thier vulnerabilities.

      HTTPS and an honest server

      this is true but it critically depends on your definition of these. there are many decentralised chat apps out there like matrix. unlike matrix, a selfhosted solution on my app is something that is easier to setup that others because its basically a website on a url. this might lead to less technical people using my app with ease. these are the users that may not be able to distinguish on these security relevent information.

      verify that the JavaScript they’re executing is the correct JavaScript

      the app is a offline-first PWA. its practically works offline. im sure its possible to make it so that fetching new statics can be done explicitly. the app otherwise is already able to do things like startup while offline from the cache (sometime it takes a couple refreshes (a bug for another time)). i prefer for it to take the latest javascript because especially at this early stage, it something im actively working on and fixing. i can imagine if the project isnt abandoned, it would make sense to have certain security assessed version to use.

      compel you to serve malicious JavaScript to specific users

      i think there isnt a way to implement something like this in this app. firstly im taking a hard stance on external javascript. that isnt to say my due-diligence is perfect… thats to be indentified from it being open source. the app doesnt have anything like tra traditional registration system. data is stored locally in browser storage and user ID’s are cryptographically random. if there is concern about seving a different script to certain regions by IP, here is a prev post on the matter. ultimately users have to be responsible with how they use the app. “do not connect to people you dont trust” is the general advice.

  • sugar_in_your_tea@sh.itjust.worksEnglish
    3·
    3 months ago

    Probably not, it’s probably “secure enough” though. I haven’t read through the code, just glanced at some of your top-level docs. I’ll browse through it later. :)

    If you want something really secure, check out Simplex Chat, it’s P2P and built on really solid tech. You essentially have a separate keypair exchange for every “channel,” which would be a 1:1 or group chat, and knowing the key, username, ID, etc to one channel doesn’t help you at all with another channel because there’s no shared, constant information at all. So if I’m chatting with users A, B, and C, and an attacker compromises A and B, there’s nothing to link me to both A and B, nor a way for them to know about C. The only way for an attacker to know about C is if they compromised my device, but then they wouldn’t know anything about C other than what they sent to me.

    You could probably build something on top of simplex and go to town with your own UX and whatnot on top, or study the Haskell code and figure out how they’re doing it. I’m working on a P2P lemmy/reddit clone, and I’m planning on using simplex for DMs and live chat, and perhaps as part of my trust network (I want distributed moderation as well).

    I’m not a cyber security expert either, just a hobbyist, and it’s the best I’ve found so far.

    • positive_intentions@lemmy.mlOPEnglish
      2·
      3 months ago

      thanks for the reply! im actively looking for a way to compare it to simplex chat. i hope you can offer some advice.

      here is a prev post about it. i think signal is a good app and works similarly to mine in many ways. but mine is distinct in that its provided as a PWA. the goal is specifically to create a secure chat app on a browser. simple provides all other offerings and perhaps came across feedback like i did that javascript is inherently insecure (to which, this app is my disagreement).

      my app works similarly to how to derscribe simplex to work. in my app what you see as a “pod” is basically a chat room. the app doesnt have the group-chat functionality working as expected, but its a work in progress. the following is an attempt to explain how it works. it will work in a way that a room has an id to which users can send messages p2p. this is how it works for regular chat. it works with a slight different that the messages are stored on a blockchain structure. it isnt related to cryptocurrencies or anything. just blockchain as a dastructure. this becomes useful for group chat because it could allow for offlike messaging by something like user A, B and C have a group chat. C goes offline while A and B continue to chat. then A goes offline and C comes online to talk to B. when C connects to B for the second time, the messages from A will be shared and resolved via the blockchain functionality. i make an attempt to explain the benefit of the blockchain structure here. it isnt something i can advocate as an approach. its more something i was trying out and it seems to work better than i thought.

      id like to hear more about your approach to distributed moderation. i was trying to investigate something like this and couldnt settle on an approach that would be useful. it would be great to hear your ideas if you want to share.

  • vzqEnglish
    2·
    1 month ago

    deleted by creator

    • positive_intentions@lemmy.mlOPEnglish
      1·
      3 months ago

      thanks!

      it’s hard for an app like this to surpass the value that popular apps like signal and WhatsApp

      i agree. i dont think my app can compete with these mainstream apps because there are limitations in what a webapp can do. at this stage in the project, the apps general instability is not good for user experience. i am conceding that my app is not as nice-to-use like many other apps. however, i dont think these other offering can be as secure as mine.

      i often get touted things like the Signal protocol is amazing and 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)

      https://github.com/positive-intentions/p2p/blob/staging/src/stories/TodoDemo.stories.js

      at around line 147 you have something like an API with endpoints between peers. the demo shows a simple functionality for a decentralized todo. this should already be reasonable secure. then consider in the main app. i simply add a few extra endpoints for exchanging keys diffie-helman style. which at this point is relatively trivial to implement. some of the concerns ive heard about doing this with the javascript and webrtc, is leaked IP addresses. a prev post on the matter and i think its better to use the app with a trusted VPN. (note: this app is not intended for anonymous chat this is just to mask the IP address. strangers cannot connect with ungussable ID’s. IDs are also disposable if needed).

      your right about it being my big caveat. i noticed as my app got more complicated, i got further away from being able to describe it as secure/private/encrypted and this seems to be related to the complexity to understand. i would like to make the time to create something like the todo list demo, but a bare minimum chat app. it wont compete with things like whatsapp, signal or simplex, but by virtue of its simplicity it surely must qualify to be something like “the most secure chat app in the world”.

      i find that while i can create what i think is a secure app, education is an important factor. by that i mean for it to be secure, it is nessesary for it to be open source. perhaps it can only be considered secure if you fork it instead of using my hosted version?

      as for the target audience, im currently limiting my communication of the app on things like reddit specifically on relevent subreddits for things like crytpgraphy. im faily new to lemmy. the lemmy community seems to give “better” advice.