“Oh my! The freeway may be an incredible invention, but it was never designed for two objects to occupy the same space at the same time!”
“Physics wasn't designed that way either!”
“What was that term you just used?”
“Yes. What does it mean?”
“It's a ‘Three Letter Acronym.’”
“Yes, but what does it mean?”
“A ‘Three Letter Acronym.’”
“… and it means … ?”
“Tee—three, el—letter, ay—acronym.”
“But what does … oooooooh!”
“Thank God I didn't mention ETLA …”
So we have this new project at work, ERAS. It's an ETLA that stands for “ECID ReST API Service,” which itself contains a few ETLAs that, when fully expanded, becomes “Enhanced Caller Identification Representational State Transfer Application Programming Interface Service.” If you have to ask, it's not worth knowing, and if you don't have to ask, I'm sorry.
I don't know whether to laugh or cry.
I received the following email today:
- Trevor Clarke <XXXXXXXXXXXXXXXXXX>
- Secure gopher comment
- Tue, 28 Sep 2021 16:21:10 -0400
I just read your post http://boston.conman.org/2019/03/31.1
About the difficultly of adding TLS to gopher. I don't think it's as bleak as you suggest. A client supporting secure gopher simply sends a TLS client hello packet when first connecting to the server. If it receives nothing or receives something that is not a valid server hello it drops the connection and switches to regular gopher for that server. To minimize the number of failed attempts the client can cache the type of server during a session or persist the status for a period of time before trying again.
As I wrote back, this is already being done by clients as can be seen from my gopher logs:
Sep 28 09:10:44 daemon info 126.96.36.199 gopher remote=XXXXXX.1.36 status=false request="223120101…" bytes=82 Sep 28 09:10:44 daemon info 188.8.131.52 gopher remote=XXXXXX.1.36 status=true request="Gopher:Src:port70/handlers/" bytes=505 Sep 28 16:44:41 daemon info 184.108.40.206 gopher remote=XXXXXX.1.36 status=false request="223120101…" bytes=82 Sep 28 16:44:41 daemon info 220.127.116.11 gopher remote=XXXXXX.1.36 status=true request="Phlog:2004" bytes=533 Sep 28 18:04:43 daemon info 18.104.22.168 gopher remote=XXXXXX.1.36 status=false request="223120101…" bytes=82 Sep 28 18:04:43 daemon info 22.214.171.124 gopher remote=XXXXXX.1.36 status=true request="Bible:" bytes=10647
There's also a trick that servers can do to “seamlessly” support TLS—peek at the initial packet for the start of a TLS connection, and if it doesn't match, then fall back to the normal TCP routine. There's also the posibility of a downgrade attack to prevent the client from successfully using TLS.
I'm not a fan of either of these approaches. On the client side, it makes (potentially annoying) extra requests that for the most part, will be a waste of time as not many gopher servers (to my knowledge) support TLS. And on the server side, it's a hack to peek the initial packet of data (it can be done on some systems, but I don't know if all TCP stacks support peeking at the data before reading the data).
I also mentioned that one of the major complaints about the Gemini protocol, a somewhat reimagining of gopher but with mandatory TLS, is its use of TLS. Go figure—there are people who want to add TLS to gopher, and people who want to remove TLS from Gemini.
It's time for another reorganization at The Corporation! Woot!
I've lost count of the number of reorganizations and for the most part, they rarely affect me, but this time it's different—I'm getting a new manager! It's only been eleven months since my last new manager.
This will be … um … carry the one … the eighth manager I've had at the Ft. Lauderdale Office of the Corporation since starting. And that works out to be … goes into … carry … subtract … 18 months per manager. Not quite to the level of the Defense Against The Dark Arts position, but close enough to leave me worried. I have to wonder if some malevolent force cursed my department's manager position.
“There! Your flu shot is over with. That wasn't so bad, was it?”
“What? You didn't hear my blood-curdling screams?”
“Hrm. They must have good sound-proofing in the stabity-stab room.”
“I bet it didn't hurt at all. I didn't feel it when I got my flu shot.”
“It was the pain of a thousand suns searing through my skin.”
“That was just the alcohol wipe.”
I finally have closure.
Sixteen years ago [Sixteen years‽ Yikes!] I did some experiments with my car's keyless entry fob and found that yes, increased the effective distance of said fob out to about 90′ (30m for those who are Imperially challenged). At the time, I had no clue as to why, but this video (which was released yesterday) has a decent explanation for the phenomenon.
In addition to expanding the output of an old program, I have also been expanding the mapping of the chaotic system (and like the last post, this post will have a very limited audience but again, I don't care). So this image:
is generated by iterating these two equations:
xi+1 = (Ayi + B) xi (1 - xi)
yi+1 = (Cxi + D) yi (1 - yi)
with the following values:
- A = +2.4376
- B = +1.5624
- C = -0.8659
- D = +4.0000
is a type of map where one can find chaotic attractors. It's a 2-dimensional slice of a 4-dimension space, where the horizontal axis is A, which runs from -4 (on the left) to 4, and the vertical axis is B, which also runs from -4 (on the bottom) to 4. If you look closely, you can make out a small red cross in the upper right hand area that marks the spot where the chaotic attractor above can be found in said space. Along the bottom, you'll see the four values listed above, with “Ax” marking the attractor location along the horizontal axis, and “By” marking the location along the vertical axis. The brighter the area, the more … um … expansive the chaotic attractor becomes.
But unlike thirty years ago, I decided to slice this a few different ways. If you imaging the above image as a slice through a 3-dimentional cube, this is the image you'd see if you were looking straight down on the cube at a horizontal slice through the cube. Shifting your view to the front, where A still runs left-to-right, C now runs up-down, and we get a vertical slice through the cube:
Looking at the cube from the left side—B values now run along the horizontal, C is still up-down and we get another vertical slice:
In each of those images, you should find a small red cross that marks the location of the attractor.
There are still three more planes we can cut through, although in this case, I can't quite make out the front, side or top. One is the A-D slice (and in each of the following images, you can make out the cross along the top edge):
The second is the B-D slice:
And the final one is the C-D slice:
Yeah … D ends up being vertical in all three … and that … kind of … makes sense … to me. Or am I going crazy? This is 4-dimensional space we're talking about.
I will start with a disclaimer: this post might be of interest to only two other people, neither of which read my blog (as far as I know). But it's my blog, and I don't care. I find it interesting. Anyway, on with the post.
I was playing around with an old program that plots a chaotic attractor. I won't pretent to know what the chaotic attractor is supposed to represent, but I find it fun to poke around the program from time to time. It revolves around two equations that interact with each other:
xi+1 = (Ayi + B) xi (1 - xi)
yi+1 = (Cxi + D) yi (1 - yi)
with the resulting image x and y values plotted on the graph between 0,0 and 1,1:
But then I got wondering—why the unit square? Thirty years ago I never questioned that. It should be easy enough to find out—just change the output range a bit:
Cool! I now have the range from -1,-1 to 1,1 working. So whereas before, I would have seen:
I can now see the full extent of this particular result:
And otherwise dull plots in the 0,0 to 1,1 range are now full of detail:
I am now left to wonder if this would have affected the research this program supported?