End to End Encryption

[SpookySkeletons]

Is there any point in implementing end to end layer before FOSScord has properly settled on a battle tested solution?
(Other than using discord safely in the immediate term)

There are already some end to end modifications of the official client if adaptations of the following src repos are an option.
https://github.com/leogx9r/DiscordCrypt
https://gitlab.com/An0/SimpleDiscordCrypt
(How might I go about adapting these for personal use if not desireable for mainline? I'm not exactly a webdev)

Is an end to end webRTC channel a possibility on top of this, using some kind of handshake?

[SpacingBat3]

Is there any point in implementing end to end layer before FOSScord has properly settled on a battle tested solution?

I had some plans for that, but maybe it is worth to think about implementing extensions first?
Encrypting text in Discord should be easy, with the safeStorage it would also be possible to encrypt private key using the host-specific key (I had plans to implement encryption using PGP communication; WebCord would then automatically generate a private key and allow to share public keys)... I'm not sure however how I would implement encrypting the files; maybe it would be possible to catch it before the upload and modify, but I don't know if Discord would know the type of the specific file and if WebCord would know how to decrypt files on-the-fly (maybe it could by prepending a custom header to the files and use that to detect whenever the file was encrypted or not).

There's also a possibility to use SimpleDiscordCrypt in WebCord as it supports loading some unpacked Chrome extensions (i.e. it may or may not work based if Electron supports all APIs used in the extension). Please refer to the documentation (Features.md) where you should put your unpacked extensions in WebCord.

Is an end to end webRTC channel a possibility on top of this, using some kind of handshake?

I don't think so... Maybe it could be done in some tricky way like encrypting and decrypting audio input and output in a way they still remain understandable by the encoders/decoders (i.e. it still follows the specific encoding/decoding format of the stream like h264), but I doubt that's worth it: people using regular Discord clients would probably hear that as annoying gibberish + I don't know how WebCord would know if given stream is encrypted or not (maybe some kind of magic bytes that would be received on each chunk? 🤷🏽‍♂️). I'm also not sure how key exchange would work in that case...

You should also know WebCord uses standard WebRTC implementation from Chromium browser, so it has similar limitations and probably can't be tinkered with that much.

[SpookySkeletons]

IMO the transparent encryption of everything from files to WebRTC would be a godsend. I shouldn't have to put any thought into passing data through Discord's servers being unsafe in the slightest if all works well. SDC also encrypts all files and images uploaded.

SimpleDiscordCrypt is very good to use however when used it complains that 'Webpack' is missing and the extension doesn't load. Would love to use SDC between me and my friends if you could point me in the direction of enabling Webpack for extensions in your electron build.

[SpacingBat3]

IMO the transparent encryption of everything from files to WebRTC would be a godsend. I shouldn't have to put any thought into passing data through Discord's servers being unsafe in the slightest if all works well. SDC also encrypts all files and images uploaded.

SimpleDiscordCrypt is very good to use however when used it complains that 'Webpack' is missing and the extension doesn't load. Would love to use SDC between me and my friends if you could point me in the direction of enabling Webpack for extensions in your electron build.

I see SDC tries to replace headers to remove Content Security Policy and that is something which isn't going to work. However seeing a lot of issues due to both Discord's and WebCord's CSP makes me to rethink if not to add it for a sake of being able to make most mods functional at cost of the code security (CSP is important as acts as a whitelist for the pages allowed to load; it can prevent RCS as it is designed to block untrusted pages to even load and removing it opens a gate for untrusted pages to load) and WebCord's CSP is actually more restrictive than Discord's as it blocks some unnecessary third-party services like Google Fonts and can be tweaked to block all third-party services providers for a maximum privacy and security at cost of breakage with some functionalities. Of course, I would warn users about consequences of disabling CSP if I would add that option to WebCord.

And I think this option would be rather a dirty workaround until a proper mod API will be implemented and CSS styles will start supporting CSP modifications.

[SpookySkeletons]

We get full tailoring of access controls as I understand it? Can we whitelist the E2E temp integration in an extremely targeted way As I really understand that you dont want to just execute any odd bins that discord shoves onto your box over HTTP which is why I gravitated to webcord to begin with...

You up for integrating SDC with a user toggle how you see fit in a decently secure way or do you have to compromise to actually integrate?

OG SD has easier vanilla modding and android support to friends AKA BetterDiscord and a bit less vauge mod UI, however I have no idea how rotted it is at this point... Would be preferable but not sure how many SD issues you would be cleaning up for them instead of just heaping it in vs SDC.

[SpacingBat3]

We get full tailoring of access controls as I understand it? Can we whitelist the E2E temp integration in an extremely targeted way As I really understand that you dont want to just execute any odd bins that discord shoves onto your box over HTTP which is why I gravitated to webcord to begin with...

I don't really want targeted integration, but disabling CSP entirely is something SDC does by the default. However with CSP disabled some tracking might be back (mostly in third-party sites; known Discord tracking should still be blocked).

---

FYI: Also, in way of thinking about the security problems on implementing the end-to-end encryption, I would consider these questions:

• How key exchange will be handled?
• How can we be sure the keys were generated by the specific person?
• In case of PGP communication, couldn't the public key got simply replaced by malicious vector in order to perform man-in-the-middle attack to compromise the encryption?

This, among many considerations are why ideally secure end-to-end encryption with automatic key exchange might not be possible without just trusting a key server – if you don't trust Discord after all for any kind of the communication, why would you trust it for the key exchange?

From what I've found about SimpleDiscordCrypt is that it seems to be using Discord for key exchange for automatic key exchange, at least by looking at these lines of code in GitLab and these lines in fork on GitHub. I'm not a security expert through so no guarantees that what I say is correct, but with my understanding on how key exchange works, I think Discord could just replace sent public keys with their own as long as they capture the entire communication, can manipulate it and have a reason to do so. Of course, I believe it could be possible to verify the keys further (e.g. using another server or by locally transmitting the key by a mass storage device) and detect such malicious activity, but as far as I know this isn't something done automatically.

[SpookySkeletons]

Key exchange is handled automatically in most cases but a comm channel hard to fake like VoIP can be used to relay a visual signature. Telegram for instance uses emojis so you can verify with the other party the channel is untampered.
Again this is always a major issue but providing clear guidance in visual easy to compare form is an acceptable solution for most E2E providers.
It's always a risk but this is why its important to verify with the other side your keys over a channel better tied to true identity like VoIP.

As long as the initial key exchange is done in a secure fashion you can check for any identity changes and warn the e2e end user.

I believe SDC did have a mechanism for visual identity built in and verification when I used it... so long as you utilize an offline or hard to spoof sidechannel to confirm your identities.

Perhaps one of those lower chat toast messages on init of encrypted channel strongly prompting the user to verify their identity signatures until dismissed or manually confirmed by typing in proof of the other key's visual client identity.

The solution as is for SDC as it stands, is workable, but has known attack surface.
Going from unknown limits & risks comm channel to known limits and risks would be a load off.

[SpookySkeletons]

Got questions for you, assuming this can be done cleanly in a native modestly portable TS tree within the src. Will this violate CSP? Willing to merge if it's quality?

[SpacingBat3]

I've rethought the way of implemented the plugins and I think I'll allow injecting unsandboxed rendered scripts that are distributed with the WebCord itself (e.g. next to webcord binary in resources/userMods/*.js). This shouldn't affect the security, because if anyone has a write access to resources folder, that person is probably capable of modifying the app.asar anyway and injecting their own code there. However, I won't support any client injecting the scripts, for obvious reasons.

That should be enough to actually implement a mod loader for WebCord, because scripts there should be able to store data the same way as Discord does. I might also add an option to disable CSP entirely (i.e. allow for ALL messages send and received, including those malicious ones), but I'm not sure about that. As an alternative, I could consider adding a yet another field for writing custom CSP inside the configuration, but I would probably have to work about the config implementation first (I want to prepare it for the encryption, so there won't be any way to modify CSP by any third-party software; I would seperate config to two files, in the first data would be unencrypted and could be used before WebCord does fully initialize and in the second data would be encrypted, but WebCord wouldn't be able to read it earlier than after ready event gets emitted)…

---

Will this violate CSP?

Any code doing requests outside of domain / URL list of Content-Security-Policy will be blocked. You should be however fine if entire code will be saved locally (on the renderer side) and no requests will be done outside of CSP (or code will be prepared that those requests could fail).

Willing to merge if it's quality?

I think I shouldn't go to far in modifications in WebCord, but neither should prevent them. Personally I think WebCord should stay as close to vanilla Discord experience as possible when it comes to the client implementation and not provide any options directly going against Discord policies (I don't want to accept, at least for now, changes that would add any additional feature to Discord or reimplement the nitro-only features for non-nitro users). For now I don't really want to make WebCord by itself tweak how Discord would function, but on the other hand I don't want to prevent people to tinker with it if they want to.

This is why I would prefer to let anyone implement this as an addon or modification.

[SpookySkeletons]

Thankyou! This is a much better bridge for quite a number of addons I had a liking for too
Should I hold tight for the js injector given your schedule?