I know logging isn't popular here, but I still do it anyway, in order to track down issues that might come up, either bugs in the server. Early on, I decided also log certificates that might be used to hit the "/private" directory on my server. I'm seeing a bit more activity there, which is nice, the latest one being: remote=---.---.---.--- status=20 request="gemini://gemini.conman.org/private/" bytes=213 subject="/CN=AV-98 cert test" issuer="/CN=AV-98 cert test" But the following requests had me seriously puzzled: remote=---.---.---.--- status=20 request="gemini://gemini.conman.org/private/" bytes=213 subject="" issuer="" remote=---.---.---.--- status=20 request="gemini://gemini.conman.org/private/mondrian.gif" bytes=3082 subject="" issuer="" After quite a bit of testing and thinking on this, I can only conclude that whomever sent this request did have a certificate, but the certificate did not include the issuer or subject fields. As I stated, I accept any certificate (as long as the dates are valid). I did not expect a certificate sans issuer/subject could be valid as well. Perhaps it's not, I don't actually know, but kudos to the requestor. I was not expecting this. -spc
Haha, this was me! In order to get a 1.0.0 release of AV-98 out the door and into PyPI quickly so that there's an easy to install client for curious newcomers, I spent some time yesterday hacking away on client certificate support. Mozz added some basic support a few weeks back to facilitate the astrobotany game, but I am working on something slightly more user-friendly. As long as the `openssl` command line tool is installed, it will soon be possible to generate certs from within AV-98 in response to status codes wanting them. Once you navigate to a different domain other than the one for which the cert was generated, you'll get a privacy warning and the option to stop using that cert. It's certainly still rough around the edges, but it's usable enough and will facilitate more experimentation on the server side with client certificates. I'll post lots more about this work here in the near future. Anyway, at some point yesterday I got tired of filling out `openssl`s prompts when making new certs and just gave blank answers to everything, which would be the requests you noticed. Are you quite sure that your server handled them just fine as the logs indicate? If I remember rightly the SSL handshake seemed to fail when I did this so I quickly reverted to putting something non-zero in there. We should talk about logging formats some time. Molly Brown keeps logs too (I keep meaning to make a nice graph showing the wave of traffice that came in after we hit HN), in an ad-hoc format that doesn't match yours below at all (unsurprisingly). Having a standard format would facilitate tools to monitor/visualise logs. Cheers, Solderpunk On Sun, May 10, 2020 at 08:18:21PM -0400, Sean Conner wrote: > > I know logging isn't popular here, but I still do it anyway, in order to > track down issues that might come up, either bugs in the server. Early on, > I decided also log certificates that might be used to hit the "/private" > directory on my server. I'm seeing a bit more activity there, which is > nice, the latest one being: > > remote=---.---.---.--- status=20 request="gemini://gemini.conman.org/private/" bytes=213 subject="/CN=AV-98 cert test" issuer="/CN=AV-98 cert test" > > But the following requests had me seriously puzzled: > > remote=---.---.---.--- status=20 request="gemini://gemini.conman.org/private/" bytes=213 subject="" issuer="" > remote=---.---.---.--- status=20 request="gemini://gemini.conman.org/private/mondrian.gif" bytes=3082 subject="" issuer="" > > After quite a bit of testing and thinking on this, I can only conclude > that whomever sent this request did have a certificate, but the certificate > did not include the issuer or subject fields. As I stated, I accept any > certificate (as long as the dates are valid). I did not expect a > certificate sans issuer/subject could be valid as well. Perhaps it's not, I > don't actually know, but kudos to the requestor. I was not expecting this. > > -spc > >
It was thus said that the Great solderpunk once stated: > > Anyway, at some point yesterday I got tired of filling out `openssl`s > prompts when making new certs and just gave blank answers to everything, > which would be the requests you noticed. Are you quite sure that your > server handled them just fine as the logs indicate? If it doesn't, I have bigger issues. But I was unable to reproduce what I was seeing, but I didn't actually get around to producing a certificate with an empty issuer and subject field. > If I remember > rightly the SSL handshake seemed to fail when I did this so I quickly > reverted to putting something non-zero in there. Well, I told the TLS layer that I didn't want *it* to verify the certificate, and the only validation *I* do prior to request specific checks, is to check the date. And for my "/private" subdirectory, all I do is return 'true'---I don't bother checking the actual certificate. > We should talk about logging formats some time. Molly Brown keeps logs > too (I keep meaning to make a nice graph showing the wave of traffice > that came in after we hit HN), in an ad-hoc format that doesn't match > yours below at all (unsurprisingly). Having a standard format would > facilitate tools to monitor/visualise logs. I log via syslog(), which handles the timestamps for me (and log rotation, and a whole bunch of other stuff related to logging). I place the name of the fields to make later processing a bit easier, but as far as I can tell, the only thing I log that you don't is the issuer and subject from any certificates presented, and that was to satisfy my own curiousity (and to potentially troubleshoot any issues). But there's really not much to log, other than remote address, request, status, and potentially the issuer/subject of any given certificate (and even that might be optional). -spc
On Mon, May 11, 2020, at 2:21 AM, Sean Conner wrote: > > We should talk about logging formats some time. Molly Brown keeps logs > > too (I keep meaning to make a nice graph showing the wave of traffice > > that came in after we hit HN), in an ad-hoc format that doesn't match > > yours below at all (unsurprisingly). Having a standard format would > > facilitate tools to monitor/visualise logs. > > I log via syslog(), which handles the timestamps for me (and log rotation, > and a whole bunch of other stuff related to logging). I place the name of > the fields to make later processing a bit easier, but as far as I can tell, > the only thing I log that you don't is the issuer and subject from any > certificates presented, and that was to satisfy my own curiousity (and to > potentially troubleshoot any issues). I think by default, any logging we do should be at a bare minimum and not contain the IP address of the client or any other data that would link the log line to them. I added logging to my hacked up version of Pollux but it only logs which page was loaded and when. My purpose was to track basic traffic and any errors that occur and nothing else. Dave
It was thus said that the Great Dave Huseby once stated: > On Mon, May 11, 2020, at 2:21 AM, Sean Conner wrote: > > > We should talk about logging formats some time. Molly Brown keeps logs > > > too (I keep meaning to make a nice graph showing the wave of traffice > > > that came in after we hit HN), in an ad-hoc format that doesn't match > > > yours below at all (unsurprisingly). Having a standard format would > > > facilitate tools to monitor/visualise logs. > > > > I log via syslog(), which handles the timestamps for me (and log rotation, > > and a whole bunch of other stuff related to logging). I place the name of > > the fields to make later processing a bit easier, but as far as I can tell, > > the only thing I log that you don't is the issuer and subject from any > > certificates presented, and that was to satisfy my own curiousity (and to > > potentially troubleshoot any issues). > > I think by default, any logging we do should be at a bare minimum and not > contain the IP address of the client or any other data that would link the > log line to them. I added logging to my hacked up version of Pollux but it > only logs which page was loaded and when. My purpose was to track basic > traffic and any errors that occur and nothing else. One misbehaving client on an IP address can present a headache by repeated making requests and (especially if it's behind a larger pipe than yours) sawmp the server. By recording the IP address, it can be identified and blocked. Or a mishevaving client always makes the same request to a non-existant resource. I had this happen on my gopher server---some web bot kept trying to fetch the main index.html page. Very annoying. Again, easy to block if you have the IP. -spc (Oooh, that reminds me, I have a bug to patch in GLV-1.12556 ... )
On Mon, May 11, 2020 at 05:21:01AM -0400, Sean Conner wrote: > But there's really not much to log, other than remote address, request, > status, and potentially the issuer/subject of any given certificate (and > even that might be optional). I agree, there's not much to log, far less than HTTP. But there's some real utility in having, err, utilities which can parse a log and generate basic statistics an admin might like to know: most popular resources, frequent requests resulting in 51 Not Found responses, average requests per day. And people are more likely to write things like this if there's one format to worry about and not one per server. This isn't a hard side-project by any means. Something very simple and easy to read into existing data processing tools, like a comma separated or tab separated value file with standardised names and/or order for the columns and an agreed-upon representation of time would do the trick. I am understanding of and sympathetic towards both admins who want to log IPs for debugging or abuse-detection purposes and towards those who don't want to so they can (rightfully) boast about their severs' respect for privacy. So the standard format should include a column for remote IP and also have a clearly defined behaviour for anonymised logs which log analysers can recognise and handle gracefully (as simple as specifying a standard character, like "-", to be placed in that column). We could also define a half-way format, where a compact hash of the IP is logged, so that unique visitor statistics can be calcualted for those who want them, or e.g. malfunctioning bots can be spotted, but nothing. Cheers, Solderpunk
It was thus said that the Great solderpunk once stated: > On Mon, May 11, 2020 at 05:21:01AM -0400, Sean Conner wrote: > > > But there's really not much to log, other than remote address, request, > > status, and potentially the issuer/subject of any given certificate (and > > even that might be optional). > > I agree, there's not much to log, far less than HTTP. But there's some > real utility in having, err, utilities which can parse a log and > generate basic statistics an admin might like to know: most popular > resources, frequent requests resulting in 51 Not Found responses, > average requests per day. And people are more likely to write things > like this if there's one format to worry about and not one per server. > > This isn't a hard side-project by any means. Something very simple and > easy to read into existing data processing tools, like a comma separated > or tab separated value file with standardised names and/or order for the > columns and an agreed-upon representation of time would do the trick. > > I am understanding of and sympathetic towards both admins who want to > log IPs for debugging or abuse-detection purposes and towards those who > don't want to so they can (rightfully) boast about their severs' respect > for privacy. So the standard format should include a column for remote > IP and also have a clearly defined behaviour for anonymised logs which > log analysers can recognise and handle gracefully (as simple as > specifying a standard character, like "-", to be placed in that column). > We could also define a half-way format, where a compact hash of the IP is > logged, so that unique visitor statistics can be calcualted for those > who want them, or e.g. malfunctioning bots can be spotted, but nothing. Okay, here's the format I'm using, and some notes about it: remote=---.---.---.--- status=20 request="gemini://gemini.conman.org/private/" bytes=213 subject="/CN=AV-98 cert test" issuer="/CN=AV-98 cert test" remote=---.---.---.--- status=20 request="gemini://gemini.conman.org/" bytes=3026 subject="" issuer="" (NOTE: I'm blanking out the IP address) As stated before, I'm using syslog() for logging, so I'm not logging the time since that's added by syslog(). The request, subject and issuer fields are quoted, so any double quote that appears inside has to be escaped with '\' [1]. The fields are named, so they are (assuming you know English) self-describing (to a degree). I include bytes, but that's because I have that information (even for dynamic output) due to how I wrote the server. Aside from the time field (which could be added, but for me, would be redundant since syslog() does that for me), I would say the pros of format is: * it's self describing * technically, the fields could be in any order * the fields could be made optional * new fields can be added (parsers should ignore fields they don't know) * there are tools that already exist tha can handle field=value data (for example, Splunk, which we use at work) The cons: * it takes more space due to the field names * it's slightly more complex to parse [2] * the double quote will need to be escaped in some fields [2] Thinking about it, a tool to process logs could require a module (or plugin) to handle reading the data, so for instance, I write a module for this tool to handle GLV-1.12556, and you could write one for Molly Brown. The data these modules include should be (and format): timestamp ISO-8601 format, e.g. 2020-05-12T17:33-0500 remote address opaque token (could be IPv4, IPv6, hash value) request string bytes number and optionally: client certificate issuer string client certificate subject string -spc (refuses to give up syslog) [1] Which for me, is handled automatically by Lua, the language my server is written in. [2] But not horrible either. If you use a CSV format, you have to deal with escaping commas that might appear in a field *anyway* [3]. At least with a TSV (tab-separated values) there's less chance of actual tabs being in the data, but you have to be careful when parsing to handle two consecutive tabs (or two consecutive commas when using CSV). [3] And if you think CSV is a well-defined format, you haven't been out much.
On Tue, May 12, 2020, at 11:23 AM, solderpunk wrote: > I am understanding of and sympathetic towards both admins who want to > log IPs for debugging or abuse-detection purposes and towards those who > don't want to so they can (rightfully) boast about their severs' respect > for privacy. Thanks. This is how the HTTP protocol conversation should have gone back in 1989. > We could also define a half-way format, where a compact hash of the IP is > logged, so that unique visitor statistics can be calcualted for those > who want them, or e.g. malfunctioning bots can be spotted, but nothing. I think it may help to consider that the IP address of a sender is personally identifiable information and is not the server operator's to collect without consent. Right now the only thing we can do is willfully blind our servers. Eventually though, if all goes according to plan, Gemini servers will be running on a mixnet of some kind and they won't be able to track IP addresses because the source isn't mapped to anything in the real world. Users will appear to the server as first time users on every request. The only balance to be struck will be if the user offers a correlation identifier to the server for some reason, say to access some stored state they have on the server (e.g. their own plant in the cyber garden or whatever). Accessing permissioned resources (i.e. 6X response codes) doesn't necessarily imply correlation of the user. Certainly the user can present the same cryptographic credentials on subsequent requests but a better design is to allow for pair-wise credentials that are ephemeral to each session and potentially ephemeral to each request. Currently TLS doesn?t allow for this mode of operation. Something like CurveCP with decentralized verifiable credentials is a superior solution for uncorrelatable confidentiality. Anyway, back to logging. I don't think it is our place as server operators to collect IP addresses without consent since it isn't our data. It is an unfortunate legacy of the existing IP network layer that will hopefully be overcome soon. I think the hashing of IP addresses for correlation is fine but I think it is fair to expect all server operators to notify their users that they are doing so. I may sound extreme but if we want to make the internet better, our thinking has to first shift. Cheers! Dave
It was thus said that the Great Dave Huseby once stated: > On Tue, May 12, 2020, at 11:23 AM, solderpunk wrote: > > I am understanding of and sympathetic towards both admins who want to > > log IPs for debugging or abuse-detection purposes and towards those who > > don't want to so they can (rightfully) boast about their severs' respect > > for privacy. > > Thanks. This is how the HTTP protocol conversation should have gone back > in 1989. Back in 1989, the Internet as we know it was still five years away. Commerical activity was against the rules and the only people who were on the Internet back then where largely academics (students, instructors, professors) at universities and a few researchers at some select companies (like IBM, Sun or Symbolics). I would think that had you seriously presented this argument at the time, people might have looked at you strangely. While people were still largely trustful of other users, the Morris Worm of Nov 1988 was still quite recent and if not for logging, it would have taken much longer to stop. > > We could also define a half-way format, where a compact hash of the IP is > > logged, so that unique visitor statistics can be calcualted for those > > who want them, or e.g. malfunctioning bots can be spotted, but nothing. > > I think it may help to consider that the IP address of a sender is > personally identifiable information and is not the server operator's to > collect without consent. So a not-so-hypothetical situation here---if I were to put on my Gemini server "I LOG ALL THE IPS!", honestly, how could I get your consent (or non-consent)? I can't get it from you prior to your connection, because I don't know you will connect. I can't get your concent afterwards because I already have your IP. And would such a disclaimer have to be added to every page? How can you know prior to requesting a Gemini page that the server will log your IP address? I'm not under the delusion that security is possible on the Internet, nor privacy. I've always operated under the assumption that anything I put on a public server, *even with access controls,* is public [1]. Yes, I'm a bit antagonistic towards such goals because I don't believe that one can have a truly anonymous exchange of data over *any* medium, but unfortunately, I don't have such a proof, other than---you need two endpoints who of of each other such that data can be exchanged, and how do you prove your identities (or repudate an identity, such as "I am NOT a FBI agent")? I think you can exchange data anonymously but you won't know who is actually on the other end, or you can know, but so will an observer. I don't think you can get both. > Right now the only thing we can do is willfully > blind our servers. Eventually though, if all goes according to plan, > Gemini servers will be running on a mixnet of some kind Really? I don't recall seeing such a plan myself. Solderpunk, are you holding out on me? > and they won't be > able to track IP addresses because the source isn't mapped to anything in > the real world. I know a lot of people use TOR for anonimity, but I feel that it's still not 100% secure and that a state actor (like, oh, I don't know, China or the United States) can, with enough resources, do a correlation attack on both ingress and egress TOR points. I mean, the authorities *say* they caught the Dread Pirate Roberts on one mistake he made a few years earlier, but I feel that the mistake was found *after* they knew who we really was, because the US threw enough resources (legal and otherwise) into finding him. > Accessing permissioned resources (i.e. 6X response codes) doesn't > necessarily imply correlation of the user. Certainly the user can present > the same cryptographic credentials on subsequent requests but a better > design is to allow for pair-wise credentials that are ephemeral to each > session and potentially ephemeral to each request. Currently TLS doesn?t > allow for this mode of operation. Something like CurveCP with > decentralized verifiable credentials is a superior solution for > uncorrelatable confidentiality. So go ahead and implement it if you think it's possible. > Anyway, back to logging. I don't think it is our place as server operators > to collect IP addresses without consent since it isn't our data. Technically, the IP address you use to access a server isn't yours either. It's the providers. They are just letting you use it. > It is an > unfortunate legacy of the existing IP network layer that will hopefully be > overcome soon. TOR? Content addressible stuff with names like 9a793f67-3df1-45e2-a3f5-4b3166800102? Yeah, I'm not sold on that stuff. > I think the hashing of IP addresses for correlation is fine > but I think it is fair to expect all server operators to notify their > users that they are doing so. Again, how? -spc [1] A few days ago, I was informed of a bug in my server where you could by-pass the certificate check with a malformed, but still accepted, request.
I love your enthusiasm Sean. I'm going to reply in kind and call out when I'm trolling you. Just remember that I appreciate your position and thank you for sharing your perspective. I'm sincere as Fred Rogers when I say that. Now...let the trolling begin! Let's see who can flame each other better. ; ) On Tue, May 12, 2020, at 8:06 PM, Sean Conner wrote: > Back in 1989, the Internet as we know it was still five years away. > Commerical activity was against the rules and the only people who were on > the Internet back then where largely academics (students, instructors, > professors) at universities and a few researchers at some select companies > (like IBM, Sun or Symbolics). I would think that had you seriously > presented this argument at the time, people might have looked at you > strangely. While people were still largely trustful of other users, the > Morris Worm of Nov 1988 was still quite recent and if not for logging, it > would have taken much longer to stop. You're not wrong. I was. It was 1991, not 1989: => http://ksi.cpsc.ucalgary.ca/archives/WWW-TALK/www-talk-1991.messages/1.html Dismissive troll: The rest of what you said above is irrelevant, missing the point, and distracting. > So a not-so-hypothetical situation here---if I were to put on my Gemini > server "I LOG ALL THE IPS!", honestly, how could I get your consent (or > non-consent)? I can't get it from you prior to your connection, because I > don't know you will connect. I can't get your concent afterwards because I > already have your IP. And would such a disclaimer have to be added to every > page? How can you know prior to requesting a Gemini page that the server > will log your IP address? You're not wrong. IP is what we have. You seemed to have completely missed that I'm making philosophical arguments. > I'm not under the delusion that security is possible on the Internet, nor > privacy. I've always operated under the assumption that anything I put on a > public server, *even with access controls,* is public [1]. Humble swagger troll: Write better software. I'd be happy to teach you how you can have strong enough security without logging. You wrote your server in Lua. You put a lot of trust in the underlying C code. I personally wouldn't be comfortable with that situation. I'd also be willing to help you learn a real programming language like Rust. ; ) > Yes, I'm a bit antagonistic towards such goals because I don't believe > that one can have a truly anonymous exchange of data over *any* medium, but > unfortunately, I don't have such a proof, other than---you need two > endpoints who of of each other such that data can be exchanged, and how do > you prove your identities (or repudate an identity, such as "I am NOT a FBI > agent")? I think you can exchange data anonymously but you won't know who > is actually on the other end, or you can know, but so will an observer. I > don't think you can get both. You're not wrong with what you think is the state of the world, so I understand why you're black pilled. However, it is theoretically possible to achieve both uncorrelatable and correlatable pseudonimity using stochastic mixnets as the routing mechanism on top of IP. I'll also soon publish my paper on what I call "Anon's Triangle" where I show that cryptographically provable contributions to open source projects can serve as a human-scale proof-of-work system for bootstrapping actual trust in a pseudonymous identity. If you throw in there, zero-knowledge proofs for verifiable claims, it's possible to shift authorization to be focused on
On Wed, May 13, 2020 at 09:07:00AM -0700, Dave Huseby wrote: > Now...let the trolling begin! Let's see who can flame each other better. ; ) It would be great if we could just refrain from trolling or flaming each other entirely -- even weird, happy-smiley pseudo-trolling -- and just have normal conversations, which can of course include polite and adult disagreement! Just weighing in on a few points quickly: > > > Right now the only thing we can do is willfully > > > blind our servers. Eventually though, if all goes according to plan, > > > Gemini servers will be running on a mixnet of some kind > > > > Really? I don't recall seeing such a plan myself. Solderpunk, are you > > holding out on me? > > You're not wrong. I made a mistake implying the Gemini had *anything* to do > with my efforts fix the Internet status quo. I'll admit that I've never given serious thought to alternative transports, but the spec *does* take care to say "When Gemini is served over TCP/IP, servers should listen on port 1965", implying that it might be done over things other than TCP/IP. I could have *sworn* I also explicitly called it an "application layer" protocol, but apparently not. I *will* fix that, it's always been my intent. If people want to run Gemini over some sort of new-fangled mixnet transport layer that's absolutely fine by me, and I'd regard such experiments with keen interest. But as far as I'm concerned that's largely orthogonal to the Gemini spec proper. To some extent, the spec privileges TCP/IP, or rather transport and internet layer protocols which don't provide any encryption. TLS is designed in deeply enough that removing it would be problematic, which means means that there is guaranteed to be some redundancy if the higher layers provide security features of their own. I would rather address this when and if any such alternative layers achieve significant traction by introducing a separate, relatively simple new specification - in the spirit of DNS over TLS or HTTP - rather than trying to totally generalise the spec now. If these new layers are so radically different that refactoring Gemini to work over them isn't trivial, then people can just define a new protocol native to that transport which is heavily Gemini-inspired, in the way that Gemini is heavily Gopher-inspired. This reflects my general stance on the appropriate balance for Gemini to strike between philosophical and technical considerations. I don't think it will come as a surprise to anybody that I'm an idealist. I am interested in making the internet a better place, and I consider Gemini to be doing precisely that. However, I have pretty humble ambitions with this project. By the standards of a lot of projects concerned with "making the internet a better place", Gemini looks decidedly old-fashioned or conservative. It's client-server and not peer-to-peer, content is hosted in one place on the originating server and is not replicated across requesting clients, and stuff is addressed by location and not content. Heck, it doesn't even have a blockchain in it! These decisions obviously place a limit on just how revolutionary we can be in fixing the ills of the web. But I also think these decisions are one of Gemini's great strengths. Gemini should feel overwhelmingly familiar to most technical people, both in terms of the primitives it's built from (URLs, MIME types, TLS) and the conceptual ideas that join them together. I think this fact is in no small part responsible for Gemini, despite being small and young, already having no shortage of implementations. Meanwhile, the internet is full of - and has been for a long, long time - more ambitious, radical projects with a lot more "cognitive friction" which haven't taken off. I welcome input from hardcore idealists and philosophers, because I think it's good to keep one eye on the stars (an appropriate metaphor for this project!). But I'm going to meet those ideals only as far as I think we can while keeping Gemini conceptually light and easy for people to pickup and begin working with. We won't completely solve every single problem with the web this way, but we'll make real improvements. Incremental progress is still progress, and widely-deployed progress is the best kind. Cheers, Solderpunk
It was thus said that the Great Dave Huseby once stated: > I love your enthusiasm Sean. I'm going to reply in kind and call out when > I'm trolling you. Just remember that I appreciate your position and thank > you for sharing your perspective. I'm sincere as Fred Rogers when I say > that. Now...let the trolling begin! Let's see who can flame each other > better. ; ) > > On Tue, May 12, 2020, at 8:06 PM, Sean Conner wrote: > > Back in 1989, the Internet as we know it was still five years away. > > Commerical activity was against the rules and the only people who were on > > the Internet back then where largely academics (students, instructors, > > professors) at universities and a few researchers at some select companies > > (like IBM, Sun or Symbolics). I would think that had you seriously > > presented this argument at the time, people might have looked at you > > strangely. While people were still largely trustful of other users, the > > Morris Worm of Nov 1988 was still quite recent and if not for logging, it > > would have taken much longer to stop. > > You're not wrong. I was. It was 1991, not 1989: > > => http://ksi.cpsc.ucalgary.ca/archives/WWW-TALK/www-talk-1991.messages/1.html > > Dismissive troll: The rest of what you said above is irrelevant, missing > the point, and distracting. > > > So a not-so-hypothetical situation here---if I were to put on my Gemini > > server "I LOG ALL THE IPS!", honestly, how could I get your consent (or > > non-consent)? I can't get it from you prior to your connection, because I > > don't know you will connect. I can't get your concent afterwards because I > > already have your IP. And would such a disclaimer have to be added to every > > page? How can you know prior to requesting a Gemini page that the server > > will log your IP address? > > You're not wrong. IP is what we have. You seemed to have completely missed > that I'm making philosophical arguments. I come across people who make grand statements like yours. Such as Stanislav: The Loper OS Project aims to remake computing. I am aware that others have tried and failed. Laughing? The job is not nearly as difficult as it sounds. Much of the complexity found in modern systems software is accidental, rather than inherent. A large portion of my thinking has gone into figuring out what parts of an operating system are non-axiomatic - vestiges from a computational Stone Age which could safely be swept away. http://www.loper-os.org/?p=4#selection-33.0-41.338 (written in 2007; he's still writing at his blog today, but no Loper OS). There was Fran?ois-Ren? Rideau Dang-Vu B?n with his TUNES operating system: TUNES is a project to replace existing Operating Systems, Languages, and User Interfaces by a completely rethought Computing System, based on a correctness-proof-secure higher-order reflective self-extensible fine-grained distributed persistent fault-tolerant version-aware decentralized (no-kernel) object system. http://tunes.org/papers/WhyNewOS/WhyNewOS.html (I recall when it was first announced in 1992---I thought it was silly back then; again, TUNES is no longer). Then there's Richard Kulisz: PlanNine has modularity, composability, distribution and half of uniformity. You can also include reliability. Unix has only modularity and many people seem to act like it's the "best OS of all time." ErosOs satisfies Reliability, TransparentPersistence and most of security. It doesn't seem to give very practical security. BlueAbyss aims to satisfy all of the principles to the utmost, except for Correctness Proofs, which I see as a costly fad that adds little value. https://wiki.c2.com/?OperatingSystemsDesignPrinciples (again, grand plans and not much to show for it years later). And finally to round out these examples, I present Curtis Yarvin and Urbit---and I still can't decide if it's an elaborate troll or an earnest endevour, but Urbit was introduced with this: This spec defines one function, Nock. 2 Structures A noun is an atom or a cell. An atom is any unsigned integer. A cell is an ordered pair of any two nouns. 3 Pseudocode Brackets enclose cells. [a b c] is [a [b c]]. *a is Nock(a). Reductions match top-down. 4 Reductions ?[a b] => 0 ?a => 1 ^[a b] => ^[a b] ^a => (a + 1) =[a a] => 0 =[a b] => 1 =a => =a /[1 a] => a /[2 a b] => a /[3 a b] => b /[(a + a) b] => /[2 /[a b]] /[(a + a + 1) b] => /[3 /[a b]] /a => /a *[a 0 b] => /[b a] *[a 1 b] => b *[a 2 b c d] => *[a 3 [0 1] 3 [1 c d] [1 0] 3 [1 2 3] [1 0] 5 5 b] *[a 3 b] => **[a b] *[a 4 b] => ?*[a b] *[a 5 b] => ^*[a b] *[a 6 b] => =*[a b] *[a [b c] d] => [*[a b c] *[a d]] *a => *a https://www.unqualified-reservations.org/2010/01/maxwells-equations-of-software/ And further elaborates: Urbit is a static functional namespace: a programming environment specified as a single stateless, frozen function. The Urbit function is Maxwellian: formally defined by a small system of axioms. Urbit, while a cool toy, is designed for practical computing. https://moronlab.blogspot.com/2010/01/urbit-functional-programming-from.html (and it seems to have become A Thing at https://urbit.org/, although Curtis is no longer associated with the project). I present these examples (and there are more I have saved) as a means of explanation---I come across these grand sweeping statements that we're doing this all wrong and we must, MUST! change how it all works because the current way is (to be charitable) not optimum! And in all these cases, it's all words, no implementation (except for Urbit, but even they cheat by not using Nock but "optimizing" it with native code). Your message came across exactly like that to me---IP is bad, we must use this other technology now! And I will admit that my reply might have been a bit incendiary. > Time for you to catch up with the rest of us Sean. It's only a matter of > time now. People--including me--are already working on a mixnet that > leverages this. Once we unlock that achievement, Gemini will be able to > stop relying on IP entirely. I'll patiently await the results. <troll>Hopefully it won't take as long as TUNES, Loper OS, Blue Abyss, or Urbit.</troll> > Concern troll: I'm worried about you. Hopefully post-mixnet you'll have a > better attitude about the state of the world. Stress kills y'know ; ) I know. Thanks. > You're not wrong. I made a mistake implying the Gemini had *anything* to > do with my efforts fix the Internet status quo. i gave three, one-hour > presentations last week at the Internet Identity Workshop and decided I > was going to walk the walk and *not* publish my papers on the web. Good for you. At least now I know you are serious enough to work on this. > My support for pseudonimity is a philosophical line in the sand. The only > way for users to maintain leverage against surveillance capitalism to do > all they can to maintain pseudonimity and privacy. My contributions to the > Gemini community are mostly philosophical. There's no reason we have to do > things the same way just because that's how it's always been done. True enough, but the issue I have is people questioning the design and declaring it should have been done another way, *without doing any work*. Not even a proof-of-concept. When solderpunk first designed the protocol, I had a problem with the then defined status codes. I ignored that aspect when writing the first server, opting instead to reuse HTTP codes. That lead to a long discussion and finally the design we have. But the crutial point is that *there was code!* > > > Anyway, back to logging. I don't think it is our place as server operators > > > to collect IP addresses without consent since it isn't our data. > > > > Technically, the IP address you use to access a server isn't yours either. > > It's the providers. They are just letting you use it. > > You're not wrong. > > Troll: Again, you're answering a philosophical argument with a technical > one. I'm starting to think you're uncomfortable discussing philosophy and > always run to the comfort of black and white, right angles and straight > jackets....I mean straight walls. ; ) My best friend has a degree in Philosophy, so I'm not unconfortable with it. But there comes a time when Reality comes knocking at the door ... > When I send you a packet, my computer fills in the source IP address. That > source IP address is personally identifiable information the vast majority > of the time. It's the same as me filling in my address on an envelope. I > may rent, and not own, the house--and therefore the address--that I live > in but legally, my address is considered personally identifiable > information (PII) and protected under the GDPR and CCPA. I'm suggesting > that to gain a consistent and coherent philosophy about user sovereignty > to make the internet better with truly decentralized systems, we should > all start thinking of IP addresses as PII and build/configure systems > accordingly. And that's easy to say. It's another thing to implement it. > Thanks for your reply Sean. You're welcome. > It was fun replying to you. I understand what > you're saying and you're not wrong with all of your technical details. But > I was speaking in philosophical terms as guiding principles for making > decisions going forward. I reject the current status quo. I only look back > to remind myself of what went wrong but all of my energy is focused ahead > of me. I think Aaron's quote is apropos here: > > "What is the most important thing you could be working on in the world > right now? ... And if you're not working on that, why aren't you?" Was that Aaron Swartz? > Troll: maybe you should work on learning Rust and meditating ; ) Rusty meditation? What are you on about? 8-P -spc
Thanks for clearing things up a bit, and dialing the troll level down. As someone who's played around a fair bit with alternative networks, I just want to point out (more to Dave than you) that TCP/IP, and therefore Gemini, really shouldn't conflict with the idea of an alternative, private, "mixnet" network. If I think about encrypted mesh networks like CJDNS or Yggdrasil (maybe even TOR?), Gemini will work completely out of the box on those networks, as long as your servers and clients support IPv6. No need to redefine new protocols or spec. The only inefficiency is that you also have TLS, when those networks already mandate encryption, but that's not such an issue. I'm happy that Gemini mandates it anyway, because most of its use will be on the regular Internet. > Meanwhile, the internet is full of - and has been for > a long, long time - more ambitious, radical projects with a lot more > "cognitive friction" which haven't taken off. I like this point about cognitive friction a lot. The best kind of technology is one that gets out of your way, and I think Gemini is on its way to doing that. I like the simplicity of it, I think it'll allow it to achieve so much. makeworld ??????? Original Message ??????? On Wednesday, May 13, 2020 5:10 PM, solderpunk <solderpunk at SDF.ORG> wrote: > On Wed, May 13, 2020 at 09:07:00AM -0700, Dave Huseby wrote: > > > Now...let the trolling begin! Let's see who can flame each other better. ; ) > > It would be great if we could just refrain from trolling or flaming > each other entirely -- even weird, happy-smiley pseudo-trolling -- and > just have normal conversations, which can of course include polite and > adult disagreement! > > Just weighing in on a few points quickly: > > > > > Right now the only thing we can do is willfully > > > > blind our servers. Eventually though, if all goes according to plan, > > > > Gemini servers will be running on a mixnet of some kind > > > > > > Really? I don't recall seeing such a plan myself. Solderpunk, are you > > > holding out on me? > > > > You're not wrong. I made a mistake implying the Gemini had anything to do > > with my efforts fix the Internet status quo. > > I'll admit that I've never given serious thought to alternative > transports, but the spec does take care to say "When Gemini is served > over TCP/IP, servers should listen on port 1965", implying that it might > be done over things other than TCP/IP. I could have sworn I also > explicitly called it an "application layer" protocol, but apparently not. > I will fix that, it's always been my intent. > > If people want to run Gemini over some sort of new-fangled mixnet > transport layer that's absolutely fine by me, and I'd regard such > experiments with keen interest. But as far as I'm concerned that's > largely orthogonal to the Gemini spec proper. > > To some extent, the spec privileges TCP/IP, or rather transport and > internet layer protocols which don't provide any encryption. TLS is > designed in deeply enough that removing it would be problematic, which > means means that there is guaranteed to be some redundancy if the > higher layers provide security features of their own. > > I would rather address this when and if any such alternative layers > achieve significant traction by introducing a separate, relatively > simple new specification - in the spirit of DNS over TLS or HTTP - > rather than trying to totally generalise the spec now. If these new > layers are so radically different that refactoring Gemini to work over > them isn't trivial, then people can just define a new protocol native to > that transport which is heavily Gemini-inspired, in the way that Gemini > is heavily Gopher-inspired. > > This reflects my general stance on the appropriate balance for Gemini > to strike between philosophical and technical considerations. I don't > think it will come as a surprise to anybody that I'm an idealist. I am > interested in making the internet a better place, and I consider Gemini > to be doing precisely that. However, I have pretty humble ambitions > with this project. > > By the standards of a lot of projects concerned with "making the > internet a better place", Gemini looks decidedly old-fashioned or > conservative. It's client-server and not peer-to-peer, content is > hosted in one place on the originating server and is not replicated > across requesting clients, and stuff is addressed by location and not > content. Heck, it doesn't even have a blockchain in it! > > These decisions obviously place a limit on just how revolutionary we can > be in fixing the ills of the web. But I also think these decisions are > one of Gemini's great strengths. Gemini should feel overwhelmingly > familiar to most technical people, both in terms of the primitives it's > built from (URLs, MIME types, TLS) and the conceptual ideas that join > them together. I think this fact is in no small part responsible for > Gemini, despite being small and young, already having no shortage of > implementations. Meanwhile, the internet is full of - and has been for > a long, long time - more ambitious, radical projects with a lot more > "cognitive friction" which haven't taken off. > > I welcome input from hardcore idealists and philosophers, because I > think it's good to keep one eye on the stars (an appropriate > metaphor for this project!). But I'm going to meet those ideals > only as far as I think we can while keeping Gemini conceptually light > and easy for people to pickup and begin working with. We won't > completely solve every single problem with the web this way, but > we'll make real improvements. Incremental progress is still progress, > and widely-deployed progress is the best kind. > > Cheers, > Solderpunk
This is a great reply. I never troll, I was just trying humor to dissuade Sean but he didn't catch the hint and doubled down. I have no patience for people who cannot be bothered to be neighborly. I've been around in open source long enough to know that trolls like Sean are like graffiti. If you tolerate them, the trolling only gets worse and eventually leads to ruining the neighborhood. I want to point out that the *only* reason I'm using Gemini at all is because it respects the sovereignty of users more than the web. You guys are going to get tired of me talking about it. Gemini is no where near fully user sovereign though. Frankly the software and research I'm doing doesn't really need something like Gemini. It was my mistake to mix up the ideas of what I'm publishing on my Gemini space with Gemini. My only real criticism for Gemini is that it relies on TLS. I personally believe that all communications should be encrypted by default. Gemini insisting on encryption is good but going with TLS is bad when there are much better choices such as CurveCP. I don't trust TLS because of this: => https://arstechnica.com/information-technology/2013/01/turkish-governmen t-agency-spoofed-google-certificate-accidentally/ I know, I know, but what about OCSP stapling and the global issuance observatory that were created to address this? The fact that the CA system is centralized and top-down combined with the fact that applications just blindly trust the root certs in the file that Mozilla puts on all of our computers leaves too many attack vectors for me to trust it over the long term. Gemini allows for self-signed certs, if you're going that far, why not use a better sign-after-encrypt protocol that actually increases security. CurveCP is much simpler that TLS at all levels. Why shouldn't Gemini avoid relying on centralized solutions such as TLS and the CA system? If the stated goal of Gemini is to be better than the web, why make the same mistakes as the web? If the stated goal is to just keep the code simple, fine, but why TLS then, CurveCP is simpler? What is are the goals of Gemini? Cheers! Dave
On Thu, May 14, 2020, at 1:27 PM, Dave Huseby wrote: > This is a great reply. I meant that Colecmac's reply was great. Not mine. Dave
On Thu, May 14, 2020 at 01:27:55PM -0700, Dave Huseby wrote: > This is a great reply. I never troll, I was just trying humor to dissuade Sean but he didn't catch the hint and doubled down. I have no patience for people who cannot be bothered to be neighborly. I've been around in open source long enough to know that trolls like Sean are like graffiti. If you tolerate them, the trolling only gets worse and eventually leads to ruining the neighborhood. I have to admit to being really confused by this. I thought that Sean absolutely took your post in the spirit it was intended and replied well, in that same spirit, and better than I'd hoped. I felt like I'd stepped in prematurely to try to settle things down. If this is as bad as the trolling gets around here, I'll be pretty happy. And for the record, Sean has done a lot to *improve* this neighbourhood so far. > My only real criticism for Gemini is that it relies on TLS. I personally believe that all communications should be encrypted by default. Gemini insisting on encryption is good but going with TLS is bad when there are much better choices such as CurveCP. I'm writing a gemlog post right now which talks about a whole lot of things related to TLS, including some attempt to justify the decision to use it. It'll be up soon, and I hope you'll read it. > Why shouldn't Gemini avoid relying on centralized solutions such as TLS and the CA system? It's true that not everybody (including myself) has properly implemented it yet, but Gemini *does* deliberately and explicitly try to avoid relying on the CA system by permitting clients to use a TOFU security model. Surely you read that in the spec? Cheers, Solderpunk
It was thus said that the Great Dave Huseby once stated: > > Why shouldn't Gemini avoid relying on centralized solutions such as TLS > and the CA system? If the stated goal of Gemini is to be better than the > web, why make the same mistakes as the web? If the stated goal is to just > keep the code simple, fine, but why TLS then, CurveCP is simpler? So implement a Gemini server and client using the technology you think is better so others can see it, play with it, and see how easy, secure, whatever, it is. -spc
On Thu, May 14, 2020 at 08:57:53PM +0000, solderpunk wrote: > I'm writing a gemlog post right now which talks about a whole lot of > things related to TLS, including some attempt to justify the decision to > use it. It'll be up soon, and I hope you'll read it. It's up! gemini://gemini.circumlunar.space/users/solderpunk/cornedbeef/tls-musings.gmi Cheers, Solderpunk
On Thu, May 14, 2020, at 1:57 PM, solderpunk wrote: > On Thu, May 14, 2020 at 01:27:55PM -0700, Dave Huseby wrote: > > > This is a great reply. I never troll, I was just trying humor to dissuade Sean but he didn't catch the hint and doubled down. I have no patience for people who cannot be bothered to be neighborly. I've been around in open source long enough to know that trolls like Sean are like graffiti. If you tolerate them, the trolling only gets worse and eventually leads to ruining the neighborhood. > > I have to admit to being really confused by this. I thought that Sean > absolutely took your post in the spirit it was intended and replied > well, in that same spirit, and better than I'd hoped. I felt like I'd > stepped in prematurely to try to settle things down. If this is as bad > as the trolling gets around here, I'll be pretty happy. Noted. Moving on : ) > And for the record, Sean has done a lot to *improve* this neighbourhood > so far. I did notice this. > > My only real criticism for Gemini is that it relies on TLS. I personally believe that all communications should be encrypted by default. Gemini insisting on encryption is good but going with TLS is bad when there are much better choices such as CurveCP. > > I'm writing a gemlog post right now which talks about a whole lot of > things related to TLS, including some attempt to justify the decision to > use it. It'll be up soon, and I hope you'll read it. I surely will. I'm curious about your thinking. > > Why shouldn't Gemini avoid relying on centralized solutions such as TLS and the CA system? > > It's true that not everybody (including myself) has properly implemented > it yet, but Gemini *does* deliberately and explicitly try to avoid > relying on the CA system by permitting clients to use a TOFU security > model. Surely you read that in the spec? Oops, I deleted some largely irrelevant parts of my reply that included me saying, "I get it that Gemini allows for self-signed certs but if you're going with TOFU as a primary requirement then why not Noise? CurveCP does have some TOFU limintations around knowing public keys ahead of time and through secure independent distribution." Looking forward to your gemlog. I wish we were using the term "mission log" instead, but meh, I'm indifferent. Cheers! Dave
On Thu, May 14, 2020 at 02:09:04PM -0700, Dave Huseby wrote: > I surely will. I'm curious about your thinking. I'm not sure you'll be completely sold, but I hope you'll see where I'm coming from. To try to boil it all down: I absolutely agree that TLS has problems and I don't doubt that other things, like CurveCP, might overcome or avoid a lot of them. But I believe something built on TLS is overwhelmingly more likely to be widely implemented and deployed than something based on literally anything else, and at the end of the day a I think a good but not perfect protocol which becomes widely used and supported will do a lot more good for the internet than a "perfect" protocol which never becomes more than a curiosity for a small community of enthusiasts. This is not to say I don't think anything "strange and new" can *ever* "catch on" or that I think any such efforts are a waste of time. I wish all the radical projects aiming at lofty goals all the luck in the world, sincerely. But there's a valid niche for something not quite so radical which can still be a real and valuable improvement over the status quo with very low barriers to adoption. Cheers, Solderpunk
On Thu, May 14, 2020 at 01:27:55PM -0700, Dave Huseby wrote: >Why shouldn't Gemini avoid relying on centralized solutions such as TLS and the CA system? If the stated goal of Gemini is to be better than the web, why make the same mistakes as the web? If the stated goal is to just keep the code simple, fine, but why TLS then, CurveCP is simpler? afaik Gemini doesn't use the CA system. It's just TOFU. If it does use CAs then this should be considered a design fault. Avoid anything centralized. The future will thank us for it.
I totally understand. The next version of TLS is using something like Noise/CurveCP as the default protocol. What I don't like the most about TLS is the complexity due to backwards compatibility and protocol negotiation. Using TLS properly requires lots of tweaking of complicated parameters that very few people understand. I still look forward to your post. Cheers! Dave On Thu, May 14, 2020, at 2:23 PM, solderpunk wrote: > On Thu, May 14, 2020 at 02:09:04PM -0700, Dave Huseby wrote: > > > I surely will. I'm curious about your thinking. > > I'm not sure you'll be completely sold, but I hope you'll see where I'm > coming from. > > To try to boil it all down: I absolutely agree that TLS has problems > and I don't doubt that other things, like CurveCP, might overcome or > avoid a lot of them. But I believe something built on TLS is > overwhelmingly more likely to be widely implemented and deployed than > something based on literally anything else, and at the end of the day a > I think a good but not perfect protocol which becomes widely used and > supported will do a lot more good for the internet than a "perfect" > protocol which never becomes more than a curiosity for a small > community of enthusiasts. > > This is not to say I don't think anything "strange and new" can *ever* > "catch on" or that I think any such efforts are a waste of time. I wish > all the radical projects aiming at lofty goals all the luck in the > world, sincerely. But there's a valid niche for something not quite so > radical which can still be a real and valuable improvement over the > status quo with very low barriers to adoption. > > Cheers, > Solderpunk > >
On Thu, May 14, 2020 at 04:27:25PM -0700, Dave Huseby wrote: > What I don't like the most about TLS is the complexity due to backwards compatibility and protocol negotiation. I totally get this. I really want to spec TLS 1.3 as the bare minimum permitted for Gemini because it gets rid of a lot of that complexity. Web browsers can't afford to do this because they need to support all the old servers out there. We don't have that legacy and could start with a clean slate of a simpler, less fiddly TLS. All that holds me back is that this would rule out a lot of otherwise very compelling TLS libraries which don't yet have TLS 1.3 support. Cheers, Solderpunk > I still look forward to your post. > > Cheers! > Dave > > On Thu, May 14, 2020, at 2:23 PM, solderpunk wrote: > > On Thu, May 14, 2020 at 02:09:04PM -0700, Dave Huseby wrote: > > > > > I surely will. I'm curious about your thinking. > > > > I'm not sure you'll be completely sold, but I hope you'll see where I'm > > coming from. > > > > To try to boil it all down: I absolutely agree that TLS has problems > > and I don't doubt that other things, like CurveCP, might overcome or > > avoid a lot of them. But I believe something built on TLS is > > overwhelmingly more likely to be widely implemented and deployed than > > something based on literally anything else, and at the end of the day a > > I think a good but not perfect protocol which becomes widely used and > > supported will do a lot more good for the internet than a "perfect" > > protocol which never becomes more than a curiosity for a small > > community of enthusiasts. > > > > This is not to say I don't think anything "strange and new" can *ever* > > "catch on" or that I think any such efforts are a waste of time. I wish > > all the radical projects aiming at lofty goals all the luck in the > > world, sincerely. But there's a valid niche for something not quite so > > radical which can still be a real and valuable improvement over the > > status quo with very low barriers to adoption. > > > > Cheers, > > Solderpunk > > > >
It was thus said that the Great Dave Huseby once stated: > > I think by default, any logging we do should be at a bare minimum and not > contain the IP address of the client or any other data that would link the > log line to them. I added logging to my hacked up version of Pollux but it > only logs which page was loaded and when. My purpose was to track basic > traffic and any errors that occur and nothing else. I am not trolling here. The scenaio I'll describe is *actually* happening to me as I write this message. Over the past hour, I've over 2,700 requests in my client torture test, specifically, test #22, leading into the "Redirect From Hell" portion. If it was going any faster, I'd probably block it with the firewall, but my question to Dave is, what happens on your server when something like this happens? You don't log the IP, so now what? -spc (I'll go under my bridge now ... )
Sean Conner <sean at conman.org> writes: > Over the past hour, I've over 2,700 requests in my client torture test, > specifically, test #22, leading into the "Redirect From Hell" portion. If > it was going any faster, I'd probably block it with the firewall, but my > question to Dave is, what happens on your server when something like this > happens? You don't log the IP, so now what? Yeah, IMO you need to log IP addresses in case you need to blacklist them either in the server or the firewall, in cases of abuse. If you only kept hashes of addresses, you could check them in the server for blocking, but it would not be as fast. -- +-----------------------------------------------------------+ | 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 |
---