💾 Archived View for gemi.dev › gemini-mailing-list › 000227.gmi captured on 2024-08-25 at 10:15:55. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
Hi all, I just posted a (long!) entry at my Corned Beef Sandwiches gemlog outlining my vision for applications in Geminispace: gemini://gemini.circumlunar.space/users/solderpunk/cornedbeef/a-vision-for- gemini-applications.gmi Note that my vision does not need to be everybody's vision. I am benevolent dictator of the protocol, but not what people build on top of it. I do hope people will give it some thought, though. I'd like to think there are good ideas in there. It ties in many things which have been discussed on the list recently, including Tomasino's "streaming" idea and the issue of all our nice simple apps being vulnerable to CSRF. Cheers, Solderpunk
Hey all, I like many of the ideas you expressed in your post but wanted to discuss one thing. You mentioned that you would like to see *no* cross-domain linking, in order to remove the complexities of having to do some sort of CSRF-style validation. The thing is, I think cross-domain linking is useful. It's useful when replying to someone's Gemlog post, it's useful when creating lists of links you would like to recommend to visitors of your capsule, and for linking to sources of truth that may live elsewhere (especially if linking against the web). How about a relaxed version of this, where all clients that wish to "follow" cross-domain links *must* strip out any query params. For basic clients, that would be as simple as a regex that strips the "?" used to start a query string, and everything that comes after. For more sophisticated clients that have access to URL processing libraries, this should be as simple as parsing the URL, removing any query strings, and hydrating this URL again. Now cross-domain requests cannot contain any sort of "payload" that the server would mutate state with. Of course, there is the possibility that a page view for an URL even without a query param would mutate state on the server, but that is already an issue now. Thanks, meff On 6/16/20 12:53 PM, solderpunk wrote: > Hi all, > > I just posted a (long!) entry at my Corned Beef Sandwiches gemlog > outlining my vision for applications in Geminispace: > > gemini://gemini.circumlunar.space/users/solderpunk/cornedbeef/a-vision-fo r-gemini-applications.gmi > > Note that my vision does not need to be everybody's vision. I am > benevolent dictator of the protocol, but not what people build on top of > it. I do hope people will give it some thought, though. I'd like to > think there are good ideas in there. It ties in many things which have > been discussed on the list recently, including Tomasino's "streaming" > idea and the issue of all our nice simple apps being vulnerable to CSRF. > > Cheers, > Solderpunk >
On Wed, Jun 17, 2020 at 12:53:32AM -0700, Meff wrote: > You mentioned that you would like to see *no* cross-domain linking, in order > to remove the complexities of having to do some sort of CSRF-style > validation. The thing is, I think cross-domain linking is useful. It's > useful when replying to someone's Gemlog post, it's useful when creating > lists of links you would like to recommend to visitors of your capsule, and > for linking to sources of truth that may live elsewhere (especially if > linking against the web). You have misunderstood! The stuff about no cross-domain linking was strictly in the context of a "safety client" for very safely using a certificate-secured app. In the context of a reading-oriented client for browsing gemlogs etc., *of course* cross-domain linking is absolutely essential and a client which didn't allow it would be useless. > How about a relaxed version of this, where all clients that wish to "follow" > cross-domain links *must* strip out any query params. For basic clients, > that would be as simple as a regex that strips the "?" used to start a query > string, and everything that comes after. For more sophisticated clients that > have access to URL processing libraries, this should be as simple as parsing > the URL, removing any query strings, and hydrating this URL again. Now > cross-domain requests cannot contain any sort of "payload" that the server > would mutate state with. Of course, there is the possibility that a page > view for an URL even without a query param would mutate state on the server, > but that is already an issue now. This is a perfectly good idea for "everyday" clients to implement, in order to make life a bit easier for people who really want to build and use apps that don't hide behind a certificate requirement. It would make it impossible to, e.g., link to a GUS search result page, though. That could be fixed if gemini://gus.guru/search?foo redirected to gemini://gus.guru/search/marbles, but maybe it's not worth it. In general, requiring all non-idempotent requests to use a query and recommending clients to strip (or ask for confirmation of) queries found in links and redirects, might be enough to solve the worst of the problem. It would make applications quite a bit clunkier to use (I guess they would need to use status code 10 to ask "Are you sure?" to every non-idempotent request), but some people might find that less clunky than using certs, I guess. Cheers, Solderpunk
On Wed, Jun 17, 2020 at 10:02:21AM +0000, solderpunk wrote: > In general, requiring all non-idempotent requests to use a query and > recommending clients to strip (or ask for confirmation of) queries found > in links and redirects, might be enough to solve the worst of the > problem. Of course, it only takes *one* popular client not bothering to do this to make all apps relying on it vulnerable, so really robust ones are probably going to have to faff about with nonces anyway. Cheers, Solderpunk
solderpunk <solderpunk at SDF.ORG> writes: > On Wed, Jun 17, 2020 at 10:02:21AM +0000, solderpunk wrote: > >> In general, requiring all non-idempotent requests to use a query and >> recommending clients to strip (or ask for confirmation of) queries found >> in links and redirects, might be enough to solve the worst of the >> problem. > > Of course, it only takes *one* popular client not bothering to do this > to make all apps relying on it vulnerable, so really robust ones are > probably going to have to faff about with nonces anyway. I hope to write a fuller response to your vision post later today, if I get a chance. But quickly one thought: What if, as you suggest, non-idempotent requests are required to use certificates, and further, that general-purpose clients are required to make cross-site requests *without a client certificate*, even if they have a certificate for the target in their store? -- +-----------------------------------------------------------+ | Jason F. McBrayer jmcbray at carcosa.net | | If someone conquers a thousand times a thousand others in | | battle, and someone else conquers himself, the latter one | | is the greatest of all conquerors. --- The Dhammapada |
On Wed, Jun 17, 2020 at 08:01:23AM -0400, Jason McBrayer wrote: > What if, as you suggest, non-idempotent requests are required to use > certificates, and further, that general-purpose clients are required to > make cross-site requests *without a client certificate*, even if they > have a certificate for the target in their store? Yes, that would definitely be possible (AV-98 almost does this, but it explicitly asks you if you want to reactivate a previously used certificate when you cross back to a domain). I didn't mean to say that I think it's impossible to build a general purpose client that's optimised for reading static text but also certificate aware enough to use apps, and to do so in a careful way that avoids CSRF attacks or accidental "leakage" of identities. I don't doubt it can be done! And people are genuinely welcome to try. It just seemed to me that a client like that is going to be at the very least more fiddly work for developers to write and test, and perhaps also a bit more confusing for users to use, compared to either a client which just has no concept of client certificates, or one which does but is bound to a single domain. Two simple programs which each do one thing and do it well will be simpler and safer, and it plays well to one of our core strengths, which is that usable clients can be extremely lightweight so running one per app is very feasible. Cheers, Solderpunk
On Wed, Jun 17, 2020 at 08:01:23AM -0400, Jason McBrayer wrote: > >> What if, as you suggest, non-idempotent requests are required to use >> certificates, and further, that general-purpose clients are required to >> make cross-site requests *without a client certificate*, even if they >> have a certificate for the target in their store? I feel that this is too restrictive. Just offhand, things like a site counter are not idempotent but are quite useful. I think the server should be smart and gate non-trivial non-idempotent logic behind a certificate. On 6/17/20 5:29 AM, solderpunk wrote: > It just seemed to me that a client > like that is going to be at the very least more fiddly work for > developers to write and test, and perhaps also a bit more confusing for > users to use, compared to either a client which just has no concept of > client certificates, or one which does but is bound to a single domain. > Two simple programs which each do one thing and do it well will be > simpler and safer, and it plays well to one of our core strengths, which > is that usable clients can be extremely lightweight so running one per > app is very feasible. Do you visualize separate clients per application, an application-optimized client, or both? Just curious about the destination of this vision. - meff
On Wed, Jun 17, 2020 at 02:34:53PM -0700, Koushik Roy wrote: > Do you visualize separate clients per application, an application-optimized > client, or both? Just curious about the destination of this vision. General purpose, application-optimised clients. Application specific clients would be nothing to get excited about. To quote my post: > Yes, you can build tiny little remote command line apps which use HTTP > to talk to an API somewhere, but every one of them is its own separate > app, wedded to its own specific API and not useful for anything else. > The Gemini-based solution sketched above lets you use *one* client > program for *all* apps, which is clearly far superior, and does so > without any risk of the apps being able to interact with one another. I have an in-development proof-of-concept implementation of this here: https://tildegit.org/solderpunk/alphonse It is basically AV-98 with half the code ripped out (and more ripping to be done!). It requires a URL, TLS cert and TLS key as compulsory command line options. The cert is used unconditionally for all requests, and it will refuse to visit any URL which is not at the same domain and the same path or lower as the provided starting URL. The "go" command, all bookmarking stuff, "tour" command and any other interface elements that allow the user to specify somewhere to go have been removed. You just use the internal links of the apps you point it at upon startup and can't go anywhere else. I have aliased `astrobotany` in my shell to fire up Alphonse, pointed at astrobotany.mozz.us/app and feeding in my existing cert/key, and it's now how I water my plant. As intended, it basically gives the remote Gemini app the appearance of a local command line application. Now I can use any Gemini client I like for my day to day reading of gemlogs, without it needing to support client certificates or, if it does support them, without me having told it where to find my astrobotany certs, and thus my little space plant is now totally invulnerable to CSRF attacks. This is not only a safer way to use astrobotany, it is much more convenient than opening a general purpose client, opening my bookmarks, choosing astrobotany, selecting my cert from a list that is brought up when it sees the 6x status code, and then playing. I just open a new terminal, type `astro`, hit tab, hit enter and then I'm in, authenticated, ready to go. I can't imagine wanting to go back to the old way. If more applications built around long-lived certificates appear in Geminispace, I will add new aliases for the ones that interest me. It's a really great approach, IMHO. It is not foolproof - it cannot protect against application-internal CSRF attacks, e.g. some kind of multi-user application where one user can post text/gemini content which is rendered by another user of the same application. But for single-user applications or applications where different users cannot interact with one another via means of unfiltered text/gemini, this is great. App developers do not need to bother with tedious nonce code, and users can click on any link they like in their everyday client knowing the apps they use via their app-specific client are totally safe. Cheers, Solderpunk
---