Decide what GUI to use

[felipedau]

As mentioned in #5, I am not too happy with Tkinter and we should find a better tool for the GUI. Many popular apps have been offering WebUIs (Signal, Riot, Wire) and I think unMessage should too. I would like to see unMessage running on Electron.

@HulaHoopWhonix raised a good point about how WebUIs can be insecure, and I agree, but I believe there must be a way to solve that.

Another important point to be considered is how mobile friendly the framework is, in case we make unMessage work on those devices.

[james-see]

Agree that tkinter sucks, but not sure what other options are decent. You can use Electron if you use the Brave fork that has sandboxed browser back into it, but probably a PITA to compile correctly. I have A Tor Browser called Elector that is in my github if you want to check out the code for it where I discuss this issue as well.

[felipedau]

Agree that tkinter sucks, but not sure what other options are decent. You can use Electron if you use the Brave fork that has sandboxed browser back into it, but probably a PITA to compile correctly. I have A Tor Browser called Elector that is in my github if you want to check out the code for it where I discuss this issue as well.

Very interesting. I agree and now that you mentioned, I think we should only consider options that offer sandboxing (or wait until they support it).

Thanks, I will take a look into Elector and the Brave fork!

[felipedau]

Useful info from a tweet by @diracdeltas (Brave dev):

Checklist from the security tutorial:

This is not bulletproof, but at the least, you should attempt the following:

• Only display secure (https) content
• Disable the Node integration in all renderers that display remote content (setting nodeIntegration to false in webPreferences)
• Enable context isolation in all renderers that display remote content (setting contextIsolation to true in webPreferences)
• Use ses.setPermissionRequestHandler() in all sessions that load remote content
• Do not disable webSecurity. Disabling it will disable the same-origin policy.
• Define a Content-Security-Policy , and use restrictive rules (i.e. script-src 'self')
• Override and disable eval , which allows strings to be executed as code.
• Do not set allowRunningInsecureContent to true.
• Do not enable experimentalFeatures or experimentalCanvasFeatures unless you know what you're doing.
• Do not use blinkFeatures unless you know what you're doing.
• WebViews: Do not add the nodeintegration attribute.
• WebViews: Do not use disablewebsecurity
• WebViews: Do not use allowpopups
• WebViews: Do not use insertCSS or executeJavaScript with remote CSS/JS.

Again, this list merely minimizes the risk, it does not remove it. If your goal is to display a website, a browser will be a more secure option.

new BrowserWindow([options]) from the API:

• options Object (optional)
  • webPreferences Object (optional) - Settings of web page's features.
  • webSecurity Boolean (optional) - When false, it will disable the same-origin policy (usually using testing websites by people), and set allowRunningInsecureContent to true if this options has not been set by user. Default is true.
  • allowRunningInsecureContent Boolean (optional) - Allow an https page to run JavaScript, CSS or plugins from http URLs. Default is false.
  • sandbox Boolean (optional) - Whether to enable Chromium OS-level sandbox.