| 15 Aug 2019 |
| *  mhnoyes looks at kernel.unprivileged_userns_clone | 14:56:36 |
| mhnoyes | J. Ryan Stinnett: So enabling unprivileged user namespaces globaly is safer than chmod on chrome-sandbox? | 14:59:06 |
 J. Ryan Stinnett | I have not done a thorough security analysis myself. I would recommending reading about these options and deciding what is best for you. | 15:00:21 |
| J. Ryan Stinnett | Hopefully Linux distros can settle on a single path of securing Electron apps, but at moment I am not sure what the path forward will be... | 15:01:10 |
| mhnoyes | J. Ryan Stinnett: That is whu I'm asking. The other option is running riot-web with --no-sandbox. | 15:01:27 |
| mhnoyes | J. Ryan Stinnett: Thanks for the help. I'll investigate further. | 15:01:57 |
| J. Ryan Stinnett | From what I can tell, giving unpriviledged users access to user namespaces should be safe enough as long as that technology itself is secure, but of course any API can have bugs and security flaws. For a single user desktop system, it seems safe enough to enable it to me (and indeed Ubuntu has done so), but of course choose what's best for you. | 15:07:08 |
| mhnoyes | J. Ryan Stinnett: Thanks again. I reverted to riot-web --no-sandbox while I look into the security implicatons. | 15:13:15 |
 Dave | honestly I would say that is the worst of all possible options | 15:15:42 |
| mhnoyes | Dave: Thanks. Do you lean toward the kernel change or the chmod change? | 15:16:59 |
| Dave | I would probably chmod, personally | 15:18:23 |
| mhnoyes | Dave: Thanks. Done again. I'll evaluate the three options later today. | 15:21:23 |
| J. Ryan Stinnett | Yeah, depends whether you want to trust user namespaces as an API or just Chrome / Electron. | 16:07:28 |
| mhnoyes | J. Ryan Stinnett: That being the case, your potential attack surface should be smaller when trusting Electron. | 16:40:44 |
| J. Ryan Stinnett | Yeah. I think the pyschological calculation is a bit different for distro already enabling user namespaces, since there you have to think of it as disabling a default feature if you decide it's too risky. | 16:42:27 |
| J. Ryan Stinnett | * Yeah. I think the psychological calculation is a bit different for distros already enabling user namespaces, since there you have to think of it as disabling a default feature if you decide it's too risky. | 16:42:41 |
| mhnoyes | J. Ryan Stinnett: True. Ubuntu vs. Debian | 16:43:08 |
|  伯翼💩텞㕙䭃굫陖럏緌 changed their display name from munfred to 伯翼💩텞㕙䭃굫陖럏緌. | 16:51:02 |
| mhnoyes | J. Ryan Stinnett: Anyway, it looks like we will have to deal with these types of issues periodically for the foreseeable future.
https://wiki.debian.org/Matrix | 16:55:44 |
| J. Ryan Stinnett | Right, probably so. | 16:57:01 |
|  jbbr joined the room. | 17:22:51 |
 Jose | if the desktop all is closed to the taskbar, is there anyway to easily answer an incoming video call from the notification popup? right now I have to click show on the icon, and then answer or reject the call | 17:25:20 |
| Jose | * if the desktop app is closed to the taskbar, is there anyway to easily answer an incoming video call from the notification popup? right now I have to click show on the icon, and then answer or reject the call | 17:25:41 |
|  @jason.oliveira:matrix.org joined the room. | 17:35:04 |
| @jason.oliveira:matrix.org | is anyone else having issues sending an mp4 file over riot now? | 17:35:51 |
| @jason.oliveira:matrix.org | webm and avi both work. | 17:35:56 |
| @jason.oliveira:matrix.org | sits at 0B | 17:36:09 |
| @jason.oliveira:matrix.org | I've been trying to upload an mp4 since I joined the room. | 17:46:41 |
| @jason.oliveira:matrix.org | 
Download image.png | 17:47:21 |
 AutismSandwich | Will this version of the room replace the old one in +community:matrix.org ? | 17:53:32 |
