💾 Archived View for makeworld.space › cgi-bin › gemini-irc captured on 2022-04-28 at 18:49:40.
⬅️ Previous capture (2022-03-01)
-=-=-=-=-=-=-
Logs from #gemini on tilde.chat
The most recent 100 lines.
Scroll to the bottom for the latest.
-----------------------------------------
[2022-04-28T16:00:55.651Z] <@tomasino> astrobotany has this in practice and i walk through it in my gemini app video
[2022-04-28T16:01:27.855Z] <TomDotTom> Bouncing of tomasino's point, this is why I view them as session ids and not a username/password.
[2022-04-28T16:01:42.112Z] <@tomasino> they are IDs with key-based authentication
[2022-04-28T16:01:50.009Z] <@tomasino> better than passwords! :)
[2022-04-28T16:02:20.474Z] <antiphase> You have to ensure no reuse between sites or we're back to tracking again, so every site needs a self-signed certificate issuing per client (because you wouldn't duplicate private keys)
[2022-04-28T16:02:36.856Z] <@tomasino> a feature of many clients already, yep!
[2022-04-28T16:03:01.592Z] <antiphase> And is someone going to decide if it's actually a session key (and thus destroyed and the associated account lost after each visit or even TCP connection) or a persistent bearer token
[2022-04-28T16:03:14.889Z] <@tomasino> also an option in many clients
[2022-04-28T16:03:49.031Z] <@tomasino> key management, backups, and whatnot are a growth area for gemini
[2022-04-28T16:03:59.031Z] <@tomasino> people aren't as used to that as passwords, but it's the same concept
[2022-04-28T16:05:06.376Z] <TomDotTom> Can one of you two fine gentleman help clear something up for me.
[2022-04-28T16:05:25.547Z] <@tomasino> whats up?
[2022-04-28T16:05:29.174Z] <TomDotTom> How much custom metadata can a client embed in a client certificate when it creates it?
[2022-04-28T16:06:02.427Z] <TomDotTom> Basically, have client certificates worked around the non-extensibility principle of the gemini protocol?
[2022-04-28T16:06:35.366Z] <@tomasino> oh, i see
[2022-04-28T16:06:42.765Z] <antiphase> There are no end of predefined extensions to X509 which allow various fields to be added to certificates; the best known of those might be Subject Alternate Name
[2022-04-28T16:06:52.867Z] <antiphase> and then there the DN itself
[2022-04-28T16:07:30.971Z] <antiphase> or subject if you prefer
[2022-04-28T16:08:03.944Z] <@tomasino> so you're wondering could someone stuff some extra data in there, like content length, into metadata for the cert? i mean... technically it's possible if the server is set up to read it, but it's a weird thing since certs may be throw-away or they may be ident carrying.
[2022-04-28T16:08:04.701Z] <antiphase> It's a giant inbuilt tracking token, as you would expect the public key and its fingerprint to be globally unique, within reason
[2022-04-28T16:08:06.503Z] <TomDotTom> So, if I were to create a faithless user-agent, it could embed a unique user-id, user-agent-id, and other identifying information. Servers would then be able to read this. Is this right?
[2022-04-28T16:08:32.561Z] <TomDotTom> anitphase: I'm trying to determine if it's much worse than just fingerprinting.
[2022-04-28T16:09:30.079Z] <@tomasino> if you wrote a naughty gemini client that shoved lots of extra identifying info into TLS that's sent to the server, and then wrote a custom gemini server designed to read that info and store it, then theoretically it's possible
[2022-04-28T16:09:49.654Z] <@tomasino> but at that point you could also be sending non-standard meta info in the header
[2022-04-28T16:10:23.358Z] <antiphase> I think if people follow the idea that they get a temporary token that they use to create an account on a system when they first visit, then they can add their own certificate (akin to password reuse) for simplicity and to log in again later, you've created a perfect system for persistently identifying individuals if they aren't aware that keys must never be reused
[2022-04-28T16:10:38.716Z] <TomDotTom> Cookie's were never designed to be used the way they are. But that didn't stop servers, and clients driven by commercial interests.
[2022-04-28T16:12:05.252Z] <@tomasino> https://ttm.sh/bKU.png
[2022-04-28T16:12:14.532Z] <@tomasino> here's Kristall's cert window
[2022-04-28T16:12:21.852Z] <@tomasino> need a transient one? they expire after a short time
[2022-04-28T16:12:38.978Z] <@tomasino> creating a new identity prompts to attach it to a domain by default
[2022-04-28T16:14:49.772Z] <TomDotTom> The one thing in favour of gemini is that it is relatively simple to create a new user-agent. At least for the usecase of navigating gemtext files. However, I do wonder if we get a repeat of the HTTP/HTML Browser were servers dynamically inform you that you client does support needed features to use the site, namely the addition of non-standard metadata in the client cert.
[2022-04-28T16:16:13.603Z] <@tomasino> the plethora of clients and servers helps avoid the situation where one can demand a non-standard feature because of its dominance. that's the fastest pathway to ignoring the non-extensibility clause
[2022-04-28T16:18:30.667Z] <TomDotTom> I worry that it was an assumption that could also have been applied to HTTP/HTML browsers, and we all know how that turned out.
[2022-04-28T16:22:57.543Z] <@tomasino> the browser wars led to an arms race that complicated things, which led ultimately to a place where a new entrant is nearly impossible. gemini's goal of actively avoiding that pitfall through enforced simplicity is a good one. how long it will work is a question. it doesn't have any other safeguards in place to enforce the rule
[2022-04-28T16:23:14.053Z] <@tomasino> lagrange is a great example of the threat
[2022-04-28T16:23:38.009Z] <TomDotTom> In which way?
[2022-04-28T16:23:48.267Z] <@tomasino> it's a run-away popular client. if it starts allowing non-standard things and people start adding those things to their gemini capsules, that's extensibility in exactly the way we're trying to avoid
[2022-04-28T16:24:29.246Z] <@tomasino> its dominance gives it power
[2022-04-28T16:24:49.807Z] <TomDotTom> I see. If it adds support for it's own custom mimetype which happens to support scripting, then it's HTML/Javascript chaos all over again.
[2022-04-28T16:25:48.429Z] <@tomasino> it doesn't even need to go that far. if it decides to allow inline links and renders them as clickable, or to bold things surrounded by asterisks, those little things can set new expectations in authors
[2022-04-28T16:26:17.044Z] <dimkr> Lagrange defaults to using one certificate for all pages of a capsule and I already see one capsule that assumes that
[2022-04-28T16:26:54.735Z] <dimkr> in some sense, popular clients are dangerous to the stability of the protocol
[2022-04-28T16:27:01.953Z] <TomDotTom> Rather than a pegging the cert to the full path and dirs below it.
[2022-04-28T16:27:32.511Z] <@tomasino> gemini allows arbitrary mimetypes. you can serve html content over gemini. nobody has tested the line there yet. because it's on gemini should it respect the single document request and not also fetch stylesheets or javascript? what about inline images?
[2022-04-28T16:27:55.944Z] <@tomasino> gemtext says no, but what about html? or markdown?
[2022-04-28T16:28:48.728Z] <@tomasino> i use and promote Kristall instead of Lagrange to try and diversify the client choices
[2022-04-28T16:29:27.749Z] <@tomasino> we have several good clients, but lagrange is sexy too and has a lot of bells and whistles people love
[2022-04-28T16:29:30.165Z] <november> I prefer Kristall's customization options. Lagrange seems very... specific on how it wants to display pages
[2022-04-28T16:30:23.883Z] <@tomasino> but anyway, i think our community threat vector is with the popular client rather than the sneaky one trying to abuse TLS certs
[2022-04-28T16:31:27.248Z] <@tomasino> Jaakko doesn't seem to want to break things, thankfully
[2022-04-28T16:31:37.882Z] <@tomasino> and the community still has pretty strong "don't break it" vibes
[2022-04-28T16:31:59.462Z] <@tomasino> but we'll see in a couple years
[2022-04-28T16:33:12.742Z] <@tomasino> he's done fantastic things with his client as a solo dev. if a small group or company went at it with a proper design team and put together a rockstar client that put lagrange to shame then we might face the issue again but with people that don't care to keep to spec
[2022-04-28T16:34:24.727Z] <TomDotTom> If protocols cannot guarantee the behaviour of user-agents, and community standards have shown not to scale (a la HTTP/HTML Browser), then what other options are there for preventing bad user-agents?
[2022-04-28T16:36:31.953Z] <november> Wouldn't the only option be community pressure? There's no way of blocking only a specific browser (and no one wants a way of doing that either)
[2022-04-28T16:37:34.074Z] <TomDotTom> I think you're right in that the only way to add pressure would be for servers to refuse to serve content to bad actors.
[2022-04-28T16:38:41.866Z] <TomDotTom> This was done for HTTP/HTML browsers, which is why all user-agent headers where the same for a long while. Identification would have to be based on some cryptographic proof.
[2022-04-28T16:38:55.505Z] <TomDotTom> It does indeed sound horrible.
[2022-04-28T16:43:23.729Z] <november> yeahhh
[2022-04-28T17:10:51.972Z] <ew0k> TomDotTom: could any protocol or standard ever guarantee compliant use by adopters?
[2022-04-28T17:17:16.166Z] <kelbot> Doubtful. I think at some point it will always come down to people working together to get the overall desired outcome. I don't know if there is any way to every completely guard against people behaving in an unexpected or unwanted way.
[2022-04-28T17:31:53.793Z] *** toby (~pi@41.144.82.32) joined
[2022-04-28T17:32:36.205Z] *** Akrax (~Akrax@h83-174-227-134.static.bashtel.ru) quit (quit: leaving)
[2022-04-28T17:40:40.631Z] *** toby (~pi@41.144.82.32) quit (quit: leaving)
[2022-04-28T18:05:14.958Z] *** zer0 (~zer0@n00t.top) quit (quit: au revoir)
[2022-04-28T18:08:06.265Z] *** zer0 (~zer0@n00t.top) joined
[2022-04-28T18:15:42.042Z] *** nagitsu (~nagitsu@r186-49-50-23.dialup.adsl.anteldata.net.uy) joined
[2022-04-28T18:29:02.800Z] *** grufwub (~grufwub@static.148.168.119.168.clients.your-server.de) quit (Ping timeout: 120 seconds)
[2022-04-28T18:39:18.499Z] *** nagitsu (~nagitsu@r186-49-50-23.dialup.adsl.anteldata.net.uy) quit (Connection closed)
[2022-04-28T18:39:33.293Z] <TomDotTom> ew0k: A protocol is really just a data transport mechanism. I would say it defines very little that is standard and non-standard behaviour on part of the user-agent. A user-agent's behaviour can be codified and outlined in RFCs, but it's ultimitely takes the community of user-agent builders to adhere correctly to standards.
[2022-04-28T18:40:36.283Z] <TomDotTom> To drive home my point. Cookie's are not part of the HTTP spec, they are defined in their own RFC which covers standard HTTP headers and expected user-agent behaviour.
[2022-04-28T18:42:54.301Z] <TomDotTom> The early, and obsolete, RFC contained a dedicated section to privacy along with expected user-agent behaviour to allow a user to manage their privacy. I can't remember browsers ever implementing the privacy management recommendations. And in the newest 2011 RFC these privacy recommendations have almost completely disappeared.
[2022-04-28T18:43:37.571Z] <antiphase> The Host request header is a pretty fundamental part of HTTP/1.0+ but that wouldn't have been in the original I guess
[2022-04-28T18:45:10.328Z] <TomDotTom> You're right in that there are headers that are part of the protocol. Content-Length is another crucial header. But of the headers been passed in HTTP request not that many are needed for the accurate transport between server to client and vice-versa.
[2022-04-28T18:45:51.173Z] <TomDotTom> One of my biggest gripes about HTTP/1.{0,1} is that it mixed transport headers and client configuration headers.
[2022-04-28T18:47:03.713Z] <TomDotTom> HTTP/2 elevates some of these headers, but they are still just part of the same header key-value store.
[2022-04-28T18:59:22.486Z] *** lukaso666 (~lukaso666@193.106.209.236) joined
[2022-04-28T19:26:59.568Z] * epoch never uses Content-Length for HTTP server responses
[2022-04-28T20:00:48.869Z] <ew0k> "content-bmi-category: obese"
[2022-04-28T20:01:25.119Z] <ew0k> "content-rating: 3/5 would read again"
[2022-04-28T20:01:41.599Z] <ew0k> "content-emotion: stressed out"
[2022-04-28T20:02:08.616Z] <ew0k> "content-opinion: it's all your fault!"
[2022-04-28T20:07:54.346Z] *** xq (~xq@v43666.php-friends.de) quit (Ping timeout: 120 seconds)
[2022-04-28T20:22:46.310Z] <mhj> Man... I would love if pandoc got a gemini conversion thing. Pandoc can already convert to so many other formats...
[2022-04-28T20:46:51.269Z] <kelbot> I hear great things about pandoc. I've had a couple uses for it but it apparently doesn't run on arm which is where I want to use it.
[2022-04-28T21:08:00.741Z] <mhj> Are you trying to run it on a pi kelbot ?
[2022-04-28T21:08:09.699Z] <mhj> Or some other ARM device?
[2022-04-28T21:08:26.122Z] *** leomd (dbb090cfd64@tilde.team) joined
[2022-04-28T21:11:59.127Z] *** dimkr (~dimkr@5.22.128.168) quit (Ping timeout: 120 seconds)
[2022-04-28T21:21:11.694Z] <sysrq> pandoc is bloated
[2022-04-28T21:33:28.119Z] *** leomd (dbb090cfd64@tilde.team) left (#gemini)
[2022-04-28T21:46:25.738Z] <nihilazo> pandoc is cool
[2022-04-28T21:46:34.666Z] <nihilazo> it's big because it does so much stuff
[2022-04-28T21:47:25.820Z] <nihilazo> I'd only say it's "bloated" in that for some stupid reason arch linux packages it as a non-compiled haskell program by default and you need all the haskell deps instead of just a static binary
[2022-04-28T21:47:32.527Z] <nihilazo> but that's an arch problem not a pandoc problem
[2022-04-28T21:48:12.669Z] <nihilazo> and it should run on ARM, ghc runs on ARM so there is no reason pandoc shouldn't
[2022-04-28T21:49:59.166Z] *** jtecca (jtecca@tilde.institute) joined
[2022-04-28T22:35:51.332Z] *** santiago (~Santiago39@2800:a4:1596:1500::cd0) quit (Ping timeout: 120 seconds)
[2022-04-28T22:38:34.291Z] *** jtecca (jtecca@tilde.institute) quit (quit: WeeChat 2.9)
[2022-04-28T22:48:30.889Z] *** santiago (~Santiago39@2800:a4:15f0:4200::cd0) joined