| Time |
Nick |
Message |
| 00:12 |
|
citrons joined #luanti-dev |
| 00:13 |
|
v-rob joined #luanti-dev |
| 02:21 |
|
aliasalreadytake joined #luanti-dev |
| 03:29 |
|
SFENCE_arch joined #luanti-dev |
| 04:00 |
|
MTDiscord joined #luanti-dev |
| 05:16 |
|
SFENCE joined #luanti-dev |
| 05:48 |
|
fluxionary joined #luanti-dev |
| 05:54 |
|
v-rob joined #luanti-dev |
| 06:16 |
|
SFENCE_arch joined #luanti-dev |
| 10:06 |
|
SingleDigitIq joined #luanti-dev |
| 10:40 |
|
SingleDigitIq joined #luanti-dev |
| 13:13 |
[MatrxMT] |
<Zughy> does it make sense to keep `secure.http_mods` inside advanced settings? It's very useful e.g. to copy-paste Block Echange schematics and, speaking about teachers, I suggest the tool quite a lot in school |
| 13:13 |
|
SFENCE_arch joined #luanti-dev |
| 13:13 |
[MatrxMT] |
<Zughy> *to load Block Exchange schematics from the Internet |
| 15:45 |
MTDiscord |
<exe_virus> Yes, if only to slightly protect our users. Breaking default security is an advanced feature, no matter how useful. |
| 15:46 |
rubenwardy |
for http, I'd like to see a permissions dialog perhaps in the Select Mods dialog for granting permission |
| 15:47 |
rubenwardy |
also should probably support virtual paths in secure.http_mods |
| 15:47 |
rubenwardy |
and trusted_mods |
| 16:12 |
|
fluxionary joined #luanti-dev |
| 16:16 |
sfan5 |
permission dialogs are bad because they reinforce the "click yes to continue pattern" |
| 16:16 |
sfan5 |
instead we should make it easy for users to enable trust for certain mods in the content list |
| 16:22 |
MTDiscord |
<exe_virus> Yeah, I love the idea of easily sharable trust lists, so that if I do a review and someone trusts my review, they can just point to my trust list |
| 16:23 |
celeron55 |
maybe cdb should distribute a reasonable trust list. would it be too much extra moderation work there? |
| 16:24 |
sfan5 |
uhh that sounds like a bad idea. why move the responsibility to someone else in an automated fashion? |
| 16:25 |
celeron55 |
well, it's one way to avoid annoying user interaction |
| 16:26 |
rubenwardy |
I don't think http access is hugely impacting |
| 16:27 |
rubenwardy |
rather than a dialog, could add some indication in the select mods screen which is nonblocking |
| 16:28 |
rubenwardy |
I'd be against this for trusted_mods however |
| 16:28 |
sfan5 |
mods should not routinely need elevated privileges, so if we find ourselves outsourcing and automating trust then something is definitely wrong |
| 16:28 |
celeron55 |
regardless of where a trust list might come from, could a trust list be a list of allowed domains to connect to, instead of a list of mods that are allowed to connect to anywhere they want? |
| 16:28 |
celeron55 |
or really, there could be both, mods that are allowed to connect anywhere, and domains that any mods is allowed to connect to |
| 16:29 |
celeron55 |
-s |
| 16:30 |
celeron55 |
really the question is, what is the threat model |
| 16:30 |
rubenwardy |
was about to say |
| 16:31 |
rubenwardy |
there's privacy - allowing the user to check which mods are making http requests |
| 16:31 |
rubenwardy |
a mod could use http to access local unsecured resources |
| 16:31 |
rubenwardy |
DDoS |
| 16:31 |
rubenwardy |
those last two could be solved by respecting CORS |
| 16:32 |
celeron55 |
well, DDoS is quite specific. really any kind of "using your client to connect to places that have nothing to do with yourself or the game" |
| 16:32 |
sfan5 |
I'm not sure which problem we are solving here tbh |
| 16:33 |
rubenwardy |
I think it's mainly privacy |
| 16:34 |
celeron55 |
so if the threat model is privacy and DDoS, is it ok for the mod to be allowed HTTP access by default, i.e. it will be able to make some initial requests, and the user is simultaneously shown a corner pop-up or something like that saying "this mod connected there, click this button to disallow it from making connections" |
| 16:35 |
rubenwardy |
so yeah - I don't think it's a huge problem if users just click through a prompt |
| 16:36 |
rubenwardy |
In terms of implementation, I'd add a new mod.conf key like "http_rationale" which is set to a human readable justification |
| 16:36 |
celeron55 |
that'll need to be translated. is it a problem? |
| 16:37 |
rubenwardy |
It can use the same system as title and description |
| 16:39 |
celeron55 |
and you're saying, as the user clicks "allow", the mod will be permanently trusted |
| 16:40 |
rubenwardy |
Yeah it would be added to the http_mods list. There should also be a badge in Select Mods and CDB for it where they can revoke |
| 16:41 |
celeron55 |
if you don't allow, then will the mod be permanently untrusted, or will it work like web browsers today where you'll be asked again and again until you eventually allow and websites almost have a competition in who can ask at the shortest interval to break the user? |
| 16:41 |
celeron55 |
(ok, i guess browsers actually changed that in the past years) |
| 16:42 |
rubenwardy |
A pop up would only appear once - on install or first enable (idk). Select mods would have something like HTTP: Not allowed which you can click to grant |
| 16:43 |
rubenwardy |
There's two cases - game mod or third party mod. WIth the latter, you have select mods to enable it. With the former, it's part of the game so would need to be in ContentDB |
| 16:45 |
celeron55 |
so, when a user installs a mod (or a game, really) from contentdb, they basically know, as they click the install button, whether they think it should connect somewhere or not, and thus it's the right time to ask whether to allow it to do that. but if you install a mod from another source, then first enable is the only reasonable place to do it, and at that point the user should also have an idea |
| 16:45 |
celeron55 |
about what they're wishing the mod to end up doing |
| 16:46 |
celeron55 |
of course some users have no idea, ever, and we can really only hope for the best (unless a trust list is gotten from somewhere) |
| 16:49 |
celeron55 |
one option for the contentdb UI could be that if a mod wants to use HTTP, the install button will read "install and allow making connections". whether there then is another install button which says "install and don't allow" is the next question |
| 16:51 |
MTDiscord |
<nathan4220776> It's only a "DDoS" if it's coming in from multiple places. ;) |
| 16:52 |
MTDiscord |
<nathan4220776> If it's just one person, it's just a "DoS". |
| 16:52 |
MTDiscord |
<nathan4220776> Having said that, I will admit that "DoS" is very hard to search for online... |
| 17:13 |
|
SingleDigitIq joined #luanti-dev |
| 17:27 |
|
SingleDigitIq joined #luanti-dev |
| 18:17 |
rubenwardy |
nathan4220776: if you have a mod installed on 10,000 computers and release an update to spam some website, that would be a DDoS |
| 18:17 |
MTDiscord |
<nathan4220776> Yes. |
| 18:18 |
MTDiscord |
<nathan4220776> But if it's just one computer doing it, then it's a DoS. |
| 18:18 |
rubenwardy |
673ab7Does anyone know why the flatpak EoL failed https://github.com/flathub/net.minetest.Minetest/issues/104 |
| 18:57 |
|
YuGiOhJCJ joined #luanti-dev |
| 20:02 |
sfan5 |
the flatpak people probably? |
| 20:02 |
|
v-rob joined #luanti-dev |
| 20:10 |
|
SFENCE_arch joined #luanti-dev |
| 20:13 |
|
v-rob joined #luanti-dev |
| 22:15 |
|
luk3yx joined #luanti-dev |
| 22:33 |
|
panwolfram joined #luanti-dev |
| 22:53 |
|
v-rob joined #luanti-dev |
| 23:05 |
|
Eragon joined #luanti-dev |
