• 10 Posts
  • 40 Comments
Joined 3 months ago
cake
Cake day: June 13th, 2024

help-circle


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





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


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


  • it started of as another branch “staging” and then i just stuck that that as the main branch. the whole app at this point can be considered experiemental. i guess the code isnt good enough to collab at the moment.

    as a side project, i dont have much time to work on it and so some things have to fall by the wayside such as code-quality, unit tests, documentation. i think the project isnt mature enough to burden myself with some details as i create this POC. the app as you see it is being used to understand how something like this app can tie together. a proper version will be in the form of the various federated modules which i am creating in a way to address issues seen in the main app.

    it might not be an approach other will agree with, but code quality issues are to be resolved in what im aiming for with a microfrontend architecture as described here. i think ive reached a point that i can plan how things can be broken up and it makes sense to have code separated in this way where it can also contain its own documentation.

    thanks for your input. its certainly good to understand how others feel about my work and process. and hopefully i can make things more clear as i go along.


  • thanks for the advice and insights.

    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.

    thanks again for you input.


  • positive_intentions@lemmy.mlOPtoPrivacy@lemmy.mlIs this a secure messaging app?
    link
    fedilink
    English
    arrow-up
    3
    arrow-down
    1
    ·
    1 month ago

    thanks for taking a look.

    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.



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


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


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



  • positive_intentions@lemmy.mlOPtoPrivacy@lemmy.mlWebRTC IP Leaking
    link
    fedilink
    English
    arrow-up
    4
    ·
    2 months ago

    Thanks! As a webapp I generally have no choice but advise that users select a device/os/browser combo they trust.

    It’s important to note “disabling webRTC” is not a goal here. My app critically relies on it.

    The webapp form factor is important for accesability. While things likes Qubes are secure by design, that isn’t something I can suggest to potential users. VPN however is a lot more commonly used in today’s digital scene, so I think that’s a step that easier to advocate to users.





  • positive_intentions@lemmy.mlOPtoOpen Source@lemmy.mlP2P Framework
    link
    fedilink
    English
    arrow-up
    1
    ·
    3 months ago

    Thanks. I’ve come across tox before. It’s a good implementation. The aim of my project is not to compete, but more to demonstrate a different approach to P2P technology.

    A key detail in mine is that it’s made to work in a typical web browser. While things like chat functionality can be demonstrated in our app. The app is capable to do things like shared xr spaces and shared filesystems… Unfortunately those features are still in need of refinement before they become appealing to users, but it works for a proof-of-concept.