7 ms·

Good work. Though I have to say I've seen so many of these web-based "secure, private, anonymous" chat services now, I've lost track. What we need is end-to-en

Good work. Though I have to say I've seen so many of these web-based "secure, private, anonymous" chat services now, I've lost track. What we need is end-to-end encryption and with an open source client that just has to be downloaded and built/installed once (and in such a way that it's verifiably secure, think reproducible builds).

knadh 11y ago
Author here. This is meant to be something super simple and instantly accessible. Start and finish a conversation in mere seconds if need be with no traces. I am sure downloaded clients with end to end encryptions exist, but it's definitely outside the scope of something as simple as Niltalk.
- bhayden 11y ago
  >no traces Is a secure platform really worth anything if it's unverifiable as secure? We have no way of knowing there are no traces left.
new299 11y ago
why does the client need to be built locally? Are you inherently suspicious of anything delivered over HTTPS? I'm genuinely interested in why people feel local clients are more secure than something running in a browser. It's something I came across when writing an ssh client in browser (www.minaterm.com). I guess it's the potential for a HTML page to updated overtime so it no longer reflects an audited version. However it seems that it's really a failing in our browsers that this is the case. Perhaps an external service that verifies the hash of a page would help? But this would need browser support of course. The only thing I could think of that could be implemented in current browsers was a small stub page which calculates and displays a hash of the HTML/Javascript to be launched. The stub would need to be small enough that a user could manually check that nothing malicious has been added here.
- icebraining 11y ago
  If the code can't change, what's the point of having it be delivered through the browser each time? Aren't you better off saving the bandwidth by downloading it once?
- pjc50 11y ago
  Users fall into two categories: 1) Don't really care about privacy. Might not want their chat on the front page of the papers, but aren't going to go to great lengths to achieve that. 2) Actually care about privacy and are informed. There's not many of these people, but they're trained to be wary of every outside dependency and opportunity for hostile code injection. Crypto running in the browser can be replaced any time you load it if the host is compromised - either in the technical sense or the legal sense. Yes, it could be hashed, but it isn't and there's no mechanism for this nor plans to build one. Not to mention that the browser itself presents a pretty large attack surface.
  - new299 11y ago
    > Yes, it could be hashed, but it isn't and there's no mechanism for this nor plans to build one. That's kind of a shame. It would be nice if apps distributed over the web could be signed the same way they are from repositories. > Not to mention that the browser itself presents a pretty large attack surface. As does the operating system itself. I would have thought with a local (likely native) client, you just have one less layer to get through.
    - lukeschlather 11y ago
      > That's kind of a shame. It would be nice if apps distributed over the web could be signed the same way they are from repositories. This sounds like a theoretical impossibility. The server's source code is by nature closed, and while the server could provide you a copy of the source with a signature, there's really no way for you to verify that the code you've been promised is the code that is running.
      - 11y ago

knadh 11y ago

Author here. This is meant to be something super simple and instantly accessible. Start and finish a conversation in mere seconds if need be with no traces. I am sure downloaded clients with end to end encryptions exist, but it's definitely outside the scope of something as simple as Niltalk.

bhayden 11y ago
>no traces Is a secure platform really worth anything if it's unverifiable as secure? We have no way of knowing there are no traces left.

new299 11y ago

why does the client need to be built locally? Are you inherently suspicious of anything delivered over HTTPS? I'm genuinely interested in why people feel local clients are more secure than something running in a browser. It's something I came across when writing an ssh client in browser (www.minaterm.com). I guess it's the potential for a HTML page to updated overtime so it no longer reflects an audited version. However it seems that it's really a failing in our browsers that this is the case. Perhaps an external service that verifies the hash of a page would help? But this would need browser support of course. The only thing I could think of that could be implemented in current browsers was a small stub page which calculates and displays a hash of the HTML/Javascript to be launched. The stub would need to be small enough that a user could manually check that nothing malicious has been added here.

icebraining 11y ago
If the code can't change, what's the point of having it be delivered through the browser each time? Aren't you better off saving the bandwidth by downloading it once?
pjc50 11y ago
Users fall into two categories: 1) Don't really care about privacy. Might not want their chat on the front page of the papers, but aren't going to go to great lengths to achieve that. 2) Actually care about privacy and are informed. There's not many of these people, but they're trained to be wary of every outside dependency and opportunity for hostile code injection. Crypto running in the browser can be replaced any time you load it if the host is compromised - either in the technical sense or the legal sense. Yes, it could be hashed, but it isn't and there's no mechanism for this nor plans to build one. Not to mention that the browser itself presents a pretty large attack surface.
- new299 11y ago
  > Yes, it could be hashed, but it isn't and there's no mechanism for this nor plans to build one. That's kind of a shame. It would be nice if apps distributed over the web could be signed the same way they are from repositories. > Not to mention that the browser itself presents a pretty large attack surface. As does the operating system itself. I would have thought with a local (likely native) client, you just have one less layer to get through.
  - lukeschlather 11y ago
    > That's kind of a shame. It would be nice if apps distributed over the web could be signed the same way they are from repositories. This sounds like a theoretical impossibility. The server's source code is by nature closed, and while the server could provide you a copy of the source with a signature, there's really no way for you to verify that the code you've been promised is the code that is running.
    - 11y ago