💾 Archived View for rawtext.club › ~sloum › geminilist › 001535.gmi captured on 2020-11-07 at 02:17:33. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

authority's userinfo?

solderpunk solderpunk at SDF.ORG

Thu Jun 11 10:02:54 BST 2020

- - - - - - - - - - - - - - - - - - -

On Thu, Jun 11, 2020 at 02:20:17AM +0200, Petite Abeille wrote:

On Jun 11, 2020, at 01:54, Thomas Karpiniec <tkarpiniec at icloud.com> wrote:

This is possible regardless using query strings, or even more

obnoxiously, dynamic paths/links.

Very true. They are all equivalent:

gemini://cookie@mozz.us/beer/

gemini://mozz.us/beer/?cookie

gemini://mozz.us/beer/#cookie

gemini://mozz.us/beer/cookie

But the userinfo case seems to be clearly the worst. If a server uses aredeirect to attach a "cookie" token to the client's URL using a queryor a fragment, that won't get carried across when relative links areabsolutised, so the scope is limited to that one document, unless theclient somehow plays along by recognising the cookie and propagating ititself (which no sane client will do). The path option *will* surviveabsolutisation, (well, if you gemini://mozz.us/beer/cookie/, with a trailing slash) but to give every visitor a unique cookie and track themacross the site this way (and, yes, I've always known this isunavoidable, it's mentioned in some of the very earliest Geminiwritings, from before the project even had a name) requires all contentat the site to be dynamically generated. Which is possible, of course,but it's a barrier of sorts, at least.

The userinfo approach both survives absolutisation *and* works with aperfectly static text/gemini file using relative links. It's anextremely easy and lightweight way to unambiguously track users withinone server, and unlike guessing based off IP (which is also of courseunavoidable) it is robust against multiple users sharing an IP at once.Of the four approaches outlined above, userinfo clearly has a muchhigher "damage inflicted to effort required" ratio than the others.

I don't yet have a clear idea of to what extent URI schemes arepermitted to "pick and choose" from the components of the generic URIscheme as presented in RFC3986. It is clear that the "authority"component (what normal people think of as the hostname and port) is notrequired, but if a scheme does require an authority does it also *need*to permit the userinfo? The gopher URI scheme (RFC4266) a defintionclearly does not allow one, but URIs for gopher are a tacked onafter-thought and I don't know how carefully that scheme was designed.But if it's legitimate for me to declare that the gemini:// URI schemedoes not support userinfo, I'll do it in a flash. This cookie redirectthought experiment proves that it's far too dangerous, it's just barelybetter than an actual HTTP cookie (in that it's not easily sent to thirdparties).

Of course, just saying it's unsupported isn't enough, because serverscan try to do it anyway, so every client now needs to explicitly checkfor this and either error out or remove the userinfo.

"URIs were a mistake", as the kids say. Gopher's menu item format mightbe a total PITA for users, but you know exactly what the valid scope ofeach component is and there are no "side channels".

At the end of the day all you can do

is call out dodgy behaviour, and if site owners tried it anyway,

attempt to make this sort of thing visible to client users.

Sure.

Ultimately, yes, but one can try to reduce the number of placesdodginess is possible to be as few as possible to reduce the burden ofplaying this whack-a-mole game.

Same as 6x (CLIENT CERTIFICATE REQUIRED), but less ceremonial.

And also less consensual. The ceremony is there for a reason. Geminiis supposed to be as close to anonymous by default as the limitations ofrunning it over TCP/IP allow. Turning that off, to partake of anapplication which maintains state, is *supposed* to be a song and dance.It should be impossible to not realise you're doing it. I don't evenmind if doing it is slightly inconvenient, because it should always be aconscious and considered choice. It should also be extremely easy towrite a client which is obviously totally incapable of doing it.

Yes, this rules out the notion of "lightweight content-negotiation". Sowhat? Has anybody ever once missed that concept in Gopherspace, or innascent Geminispace? How much value does that idea have for a networkwhere the majority of content is very minimally formatted plaintext?Could it ever possibly be worth the risk of introducing something whichcan be twisted to act as a cookie?

Sometimes taking a strong stand against very clearly very bad things(pervasive and uncontrollable tracking) means choosing to live withoutsome nice things that seem harmless on the surface. It's a shame, butthat's the way it is. Thankfully it turns out most nice things areactually pretty easy to do without once you get rid of it.

I.e. automated cookie tagging is the equivalent of server driven 61 TRANSIENT CERTIFICATE REQUESTED.

Characterising 6x status codes as "server driven" is extremelymisleading. The server can only issue *requests* for a certificate.There is no mechanism for the server to just ram one down the client'sthroat. The client has to opt in, and they can at any point opt-out.If I delete the private key matching a certificate, that's the end ofthat identity. I'd call that "client driven". If I delete one of youruserinfo cookies, the server can recognise my IP and feed me the samevalue again, resurrecting it. Yes, there's a risk they'll get it wrongif that IP is a pubnix or VPN address, but probabilistic persistenttracking is better than no tracking at all, so they'll try it, and willbe right some of the time.

Minus the yak shaving.

I guess some yaks are our friends.

Cheers,Solderpunk