IRC channel logs

2019-10-17.log

back to list of logs

<nisstyre>amz3: fwiw, CSRF is a special case of the "confused deputy problem" which is definitely not unique to the web
<nisstyre>but it is a bigger problem because it's a more common issue I guess now
<nisstyre>but it can happen even in totally non-web contexts, like for example https://seclists.org/oss-sec/2019/q2/131
<nisstyre>(the analogy there is that you're trusting a path given to you by some entity with its own authority, but it's being used by another entity with their authority)
<nisstyre>it's also why linux doesn't let you suid root on shell scripts
<nisstyre>because it could execute the wrong thing maliciously
*stis does some math ... hmm can I link QED with GUTCP ideas (GUTCP is assumed to ne a fringe theory by the masses)
<spk121>hi guile
***malaclyps2 is now known as malaclyps
<manumanumanu>Good morning fellow guilers!
<wingo>good morning :)
<heisenberg-25>wingo: good morning :)
<wleslie>amz3 and nisstyre: of course, as a website, it was already really easy to avoid CSRF as a vulnerability, even before CORS was a thing: simply make authority-carrying resource names unguessable (make it a crypto-cap)
<amz3>weinholt and nisstyre: thanks for the input. The security issues were not the only reason I prefer not to rely on the webstack for my "project". It might seem far-fetched, but the client-server paradigm does not represent the world like I would like it to be. I call it the star-system in the sense where a small set of well-known-peers dictate what you can do and can not do. To that paradigm, I prefer the
<amz3>peer-to-peer model, where everybody has the chance to play an equal role.
<amz3>oops wleslie ^
<wleslie>ah, that's what you meant by "gave up on the web"
<amz3>yes
<amz3>also, there is this quote that I find inspiring: "Personal Mastery: If a system is to serve the creative spirit, it must be entirely comprehensible to a single individual."
<amz3>taken from: https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html
<amz3>partly because of legacy, and because the problem the web stack try to solve is too difficult (maybe too big), the web stack namely browsers is difficult to create and maintain (html parser, css parser, layout algorithm, javascript-wasm vm, network, crypto, on-disk persistence, prolly others...).
<wingo>haha at work i am literally in a presentation about web specification work (tc39, html, etc); indeed the only way to understand a whole is to restrict yourself to a subset
<wingo>the web is like C++ i guess :)
<wleslie>I have less of an issue with complexity, and more of an issue with there being no way to DTRT
<wleslie>I work at a place that does web development - django and react you know - but convincing people to design apps with actual working security or concurrency is a hard sell
<amz3>those things are already solved, and maitained mostly in parallel and programming language standard libraries, that is there is effort duplication, which not bad in itself, but what if there was another way to have a similar creative freedom when it comes to internet application while avoid that much complexity.
*wingo nods
<rain1>hey
<wingo>hej
<nisstyre>amz3: I agree with that sentiment kinda
<nisstyre>decentralized is the way to go
<wingo>janneke: regarding mixed definitions and expressions in mes: there is a straightforward translation to letrec*
<wingo>i.e. (let () (foo) (define x 42) (bar x)) => (let () (letrec* ((_ (begin (foo) #f)) (x 42)) (bar x)))
<wingo>does that make sense to you?
<wingo>i also don't know precisely what mes would need; mixed definitions and expressions is a macro-expansion thing; i would guess that eventually you would load psyntax or something?
<wingo>dunno
<janneke>wingo: thanks ... i also don't really know. mes has an experimental option to load psyntax, but that is not working all that great.
<janneke>it's good to know this solution even though i don't know how to integrate it just yet, it does take away most of my worries :-)
<wingo>:)
<wingo>well, it's just layers. mixed definitions and expressions is a layer that is above letrec*, which can be a layer on top of let and set!
<wingo>so from a mes perspective i think there's probably not an issue but i am not sure of all the tradeoffs
<janneke>i'm starting to understand that, now that mes works :)
<janneke>currently, mes handles macro expansion (define-macro) in C and builds from that
<janneke>letrec* is defined as a define-macro...so eh, i don't see a very simple drop-in fix. however, this inspires me to revisit this; iwbn to do macro expansion in scheme but i could not get that to work/perform earlier
***Server sets mode: +nt
<wingo>janneke: here's another incremental thought. i understand that mes right now can do (let () (define x 42) (* x x))
<wingo>the idea would be to turn
<wingo>(let () (foo) (define x 42) (* x x))
<wingo>into
<wingo>(let () (define _ (begin (foo) #f)) (define x 42) (* x x))
<wingo>where _ is a fresh identifier
<wingo>so basically, transform all expressions in a body that aren't in tail position to (define _ (begin expr #f))
<janneke>wingo: that's a nice trick!
<janneke>yes, that should work
<janneke>i'm happy with this wingo, it takes away all my worries :)
<wingo>cool :)
***Server sets mode: +nt
***Server sets mode: +nt
***Server sets mode: +nt