I hope to post more on this when there’s more data to post, but I thought I’d throw up a quick note stating that the latest episode of the Security Now! “netcast” features a question posed by yours truly. (The best part was listening to Leo Laporte stumble over my long-winded rambling. ) The high-quality version of the show can be found at the previous link; a low-bandwidth version as well as a text-only transcript can be found at the corresponding page at GRC.com. A search in the transcript for “Darlington” will take you to the beginning of my question; in the netcast, it starts around 38 minutes, 22 seconds in. (Of course, I encourage everyone to read/listen to the entire thing.)

For the full effect, though, you’ll also need to listen to/read the previous two non-Q&A episodes of the show, #149 and #151. (Low-bandwidth and trascriptions can be found here and here.) The entire dialog concerns the recent trend of ISPs selling out their customers to allow third-party advertisers to come in and install hardware at the ISP to facilitate tracking the ISPs’ customers’ surfing habits across sites. While the ad companies in question claim to not be recording personally identifyable information about the ISPs’ customers, the capability is there and the possibilities for abuse are enormous. It brings back many shades of the DoubleClick controversies of the late 1990s-early 2000s, only much more ominous. I provided a unqiue standpoint to the discussion: that of a Web developer hosting a site and encountering similiar mysterious “first party” cookies set for my domain but not set by me.

The full body my question is present, but I’m not completely satisfied with the answer. Let’s just say I think Steve Gibson made an assumption about the GPF site that’s not 100% true. I’ve replied to his response with additional information. I don’t necessarily expect another response (he does, after all, have his own agenda to follow on his show), and even if he does it will likely be in episode #154, the next scheduled Q&A episode. If anyone is interested, I’ll post updates if and when this occurs. If I don’t get a response, I’ll post my response here, especially since it contains some disturbing observations about “first party” cookies that have mildly paranoid folks like me nervous. (I’d hate to see what it does to really paranoid people.)

I’ve picked up an interesting new job function to add to my résumé: voice-over narrator. Nobody could be more surprised about this than I am.

The primary project I work on at my day job is a series of interactive, computer-based training initiatives for the U.S. Navy Reserve. Until recently, my work has mostly been software development, building a Web-based learning management system through which reservists can take CBTs online and receive the appropriate credit. My time has since been split among several other projects, such as a custom content management system for our digital artists, but it’s largely been in the programming arena. That is, after all, what that fancy paper that hangs on the wall in my office says I’m good at.

As hinted at above, we also have a full digital creative team filled with artists, animators, and specialists in instructional design. While my team builds the nuts-and-bolts front end to serve the training content and keep track of the results, our creative folks actually build the training content itself. This can range from the individual diagrams and 3D models used in illustrations to complex animation sequences and all the way up to the final Flash-based instructional GUI. We’ve got some incredibly talented folks who work here, and I’m pretty proud of some of the things I’ve seen each of them do.

Lately, I’ve found myself crossing the line between coder and creative type. My managers took note with great interest during my initial interview that I’m both an artist and a programmer. My first year or so here, though, I’ve spent most of my time in front of Microsoft Visual Studio, bashing out C# code. Recently, however, I’ve found myself being pulled into more creative endeavors on our team, such as writing the storyboard for a promotional video that will be shown at a major defense contracting conference in December.

The biggest surprise came several months ago when my boss pulled me into a meeting that I normally don’t attend. During that meeting—in which I spent most of my time doodling in a notebook because nothing seemed to apply to me—my ears perked up when it was announced that I would be doing the narration for our interactive security scenario builder demo to be released at that year’s conference. I was a bewildered to say the least.

Later, my boss recounted how my name came up in a previous meeting between several people involved with that project. You see, one minor problem we tend to have here is that the overwhelming majority of us at this site are natives to the region. Well, that’s not exactly a problem from the “mining the local talent pool and supporting the local economy” standpoint. It is a problem when the vast majority of us have noticeable West Virginia “hillbilly” accents. As much as I hate stereotypes, this was is pretty darn close to true. Almost everyone here has a noticeable accent, some so far to the point that they sound like caricatures. It’s almost laughable, really.

During this meeting, the team was musing over this problem. They didn’t exactly want a backwoods hick accent talking about how to report potential corporate security violations. It was then when my boss proffered: “Have you ever heard Jeff Darlington’s voice mail message?” I was apparently out of the office at the time because he called my desk and played my outgoing message over the speakerphone. The consensus was undoubtedly unanimous.

And that’s where I am now. In addition to the aforementioned security scenario demo, I’ve recorded narrations for multiple training sessions surrounding shipboard computer administration within the Navy. I can’t really say much more about those lessons, largely because I don’t know how sensitive the material is. It’s not top secret by any means as I don’t have the necessary clearance. Still, it’s probably sensitive enough that I can’t share any samples. However, below you’ll find a link to an early draft of the security scenario builder demo. We’ve reworked it multiple times so the final outcome sounds much better than this one. Nonetheless, it allows you to hear my melodious tones. Enjoy.

Sample Interactive Learning Narration (MP3, 277k, 23 seconds)

I still find it bizarre to be doing this. It’s not something I’ve foreseen myself doing. I’ve been told that I don’t really have an accent, although I can hear it in my own voice especially when I’m tired or when I’m around others with more pronounced accents. My biggest concern right now is for our poor test team, who has to listen to my voice over and over again for hours while debugging the lessons.

So ICANN, the organization that oversees the doling out of domain names on the Internet, has approved the relaxation of the rules for top-level domains (TLDs) to allow for arbitrary TLDs for whoever has the money and technical capability to grab it. If things go according to plan, by the middle of next year you may be able to just type into your browser something like http://search.google/ rather than http://www.google.com/, or perhaps you’d rather http://drink.coke/ or http://drive.ford/ or even http://have.crazy.monkey.sex/.

To quote virtually ever character in the Star Wars universe, I have a bad feeling about this.

I am so sitting on the fence on this one. My initial gut reaction is this can’t be a good thing. I know far too many non-techies who are confused by Internet addressing as it is, so let’s confuse them some more by adding even more things for them to figure out. JD Fraizer over at User Friendly hit the nail on the head; anyone who has ever used Usenet is probably rolling their eyes a lot more lately. The potential for cybersquatting and trademark dilution is enormous. ICANN insists that an “objection-based mechanism” will be in place to prevent such things, but how much red tape (and legal dollars) will someone have to go through to protect their brand? Every day that a squatter sits on a domain equates to valuable time, money, and reputation that can be lost, something big corporations may be able to wait out but little guys like me can’t afford. It’s been hard enough right now for me to keep up with all the variants of gpf-comics.something out there. And let’s not get into the discussion of what “offensive” TLDs creative individuals might come up with….

Of course, it’s not like I’m going to be registering .gpf anytime soon anyway. I suppose that’s one thing ICANN did right: to create your own TLD, you’ll need a truck load of money first. The CBC is reporting an estimated $100,000 per TLD—I have no idea if that’s Canadian dollars or not—but ICANN only says for now that “fee information is not yet available”. Ordinary domain names are dirt cheap nowadays, which is a blessing to small-time operators like me but a curse in that squatters with cash to burn can snap up thousands at a time and hold them for ransom. At least starting a new TLD will take capital, making it a serious investment. It will also be quite a technical undertaking; owning a TLD also means you have to build the infrastructure support it. So if Google were to grab .google with their pocket change, they’ll also need to pony up the hardware and bandwidth to maintain the root server. Google may be a bad example (they’ve got servers to spare, I’m sure), but for organizations not used to maintaining that kind of “big iron” it will be a significant learning curve.

But then it occurred to me… how awesome would it be if all your favorite comics or comic-related sites could found at “something dot comics”?

Imagine if you will that some philanthropic comics creator/reader with a hundred grand in “mad money” under his bed were to snatch up .comics and register that with ICANN. Being philanthropic, this individual would charge a minimal fee to register a domain there, just enough to cover operational costs and maybe make a modest living in the process, aggregated out to anticipated demand (of which I’m sure there’d be plenty). There would be only one additional requirement for application beyond the current standard (ethical) process: the domain must be used for a site publishing, promoting, or discussing comics in some way, shape, or form. Consideration for approval would require proof of content, such as a preview development site, previously published work, portfolios, etc.—just enough to prove the site really will be used for something comic-related. Individual titles would be encouraged to register at the root level (dilbert.comics, gpf.comics, x-men.comics) while companies would register their names (dc.comics, marvel.comics, keenspot.comics) and potentially use sub-domains for their own titles (x-men.marvel.comics). Our hypothetical philanthropic registrar would also be fair and balanced as to not let big conglomerates dominate the little guys. Disputes over domains would come down to traditional copyright and trademark resolutions, requiring proof of prior art, etc.

Wouldn’t that be just grand?

Of course, what will really happen will be that some big company will come along and buy up .comics with far more misanthropic intentions (and we know such an obvious TLD wouldn’t sit dormant for long). They’d either squirrel it away selfishly for promoting their own works and no one else’s, or they’ll charge such an exorbitant “premium” price for registrations that only big publishing houses like DC, Marvel, etc. will be able to afford it, shutting out the little independents and webcomics. Even if they price it fairly and keep it open, I’d bet it would get so swamped with squatters that the novelty of the whole TLD would become as diluted .info is today. Maybe it’s just that I’m pessimistic… or that I’ve been annoyed for so long that some jerk had been holding gpf-comics.org hostage for years… but I just don’t see this turning into as promising a possibility as I think it could be.

Oh, well. I’ve been waiting for gpf.com for nearly a decade now. I guess I can just add gpf.comics to the list. Wishful thinking….

For both of you out there who care, WinHasher has now been bumped to version 1.3. The changes are very minor, so there’s no need to upgrade unless you find the following two new features useful:

• There’s now a drop-down box to choose between hexadecimal output and Base64 (RFC 2045, although without line wrapping). I personally like using Base64 because it’s more compact than hex and more “obscure-looking”; even non-coders are familiar with hex, seeing it in error messages all the time, but are less familiar with Base64, which looks more like “random noise”. The default output is still hex, so you only need to switch modes if you really find Base64 more useful.
• There’s now a tab in the GUI to hash arbitrary text. I added this feature because there was an extension to Firefox that I used all the time to do this—which I used frequently to generate “random-looking” passwords by hashing simpler plain text and using the hash as the “real” password—but the extension hasn’t been updated in forever and is no longer working in Firefox 3. So to keep myself from getting locked out of the accounts where I used hashed passwords, I threw this feature in WinHasher. The backbone was already there, so all that needed to be added was a GUI.  There’s also an encoding drop-down box that lets you change the text encoding if you so desire/need. To be honest, I don’t think it’s really necessary because I think .NET uses Unicode internally all the time, but it does have a nice side-effect: if you enter text in one encoding and change the encoding setting to something radically different (say you enter Western European Windows text but change the encoding to IBM EBCDIC Japanese), you’ll end up with a very different hash than you would have had if you used the “right” encoding. This isn’t encryption by any means as it could be easily reverse engineered if you knew what encodings were used, but it does significantly scramble things to the point that it makes it much harder to figure out exactly what you did.

I had originally started adding support for HMAC signed hashes but have abandoned that for now. If there’s anyone out there who might actually find that useful, drop me a line and I’ll revisit the code to see what I might be able to add. Downloads can be found at the first link above.

Sorry for the silence for the past… good golly… has it really been almost three months? Yeep.

Life’s been a little bit hectic on the GPF Farm. The good news is that GPF has been doing the best it’s done in years, and that alone has kept me hopping so much I haven’t had time to do much else. The bad news is that we’ve also had a lot of personal things going on to keep those few fleeting moments of free time from becoming truly free: several illnesses have swept through the house, hitting each of us individually in turn; we’ve had to fire a nanny and introduce Ben to the immunity-boosting powers of day care (see the previous item); and things have really picked up at work, where I’m currently multitasking on at least four projects. The post title says it all.

I did have a nice little anecdote started for you about the real life events that inspired the recent “iDilemma” stroy in GPF. Unfortunately, I got heavily distracted (see the previous paragraph) and never got around to finishing it. You can get the gist of the backstory in the “RIP PDA” thread on the GPF Forum. GPF Premium subscribers will likely have this condensed and repackaged into the Author’s Notes accompanying the story once I finally get around to it.

I do have a few things I’ve been meaning to blog about, so hopefully I’ll be able to get to those very soon. Again, sorry for the silence.

The following is a specification proposal for a new pseudo-random character generator (PRCG), tentatively called the “Tiny Tots PRCG”. This specification is to be considered open and royalty free; everyone is free to implement and extend this specification, although attribution is appreciated. It usefulness, however, may be limited and may only be of interest to cryptographic and mathematical academics or really bored parents.

System Requirements:

• An organic, biological processing core based on an early revision of the Homo sapien architecture, commonly referred to as a “toddler”. The processor must be upgraded from the base “infant” model, but must not have been upgraded to the “grade schooler” patch.
• A significant amount of liquid. Water (dihydrogen oxide or hydrogen hydroxide) is highly recommended, although any fluid that will not cause damage to the processor core or the other physical components of the system may be a possible substitute. Excess liquid is not recommended as it increases the risk of permanent damage to the processor. Be aware that the original and final volumes of liquid may vary during the process due to evaporation, splashing, ingestion, and liquid waste excretion.
• A collection of foam characters and/or digits comprising the alphabet from which random characters will be selected.
• A entropy pool capable of containing the processor, the liquid, and the character set. Material composition is not significant so long that characters from the character set immersed in the liquid will be able to adhere to the side of the pool if placed there.

Implementation:

1. Fill entropy pool with liquid. Adjust temperature for optimal operating environment for processor core. (Over- or under-heating may result in processor malfunction.)
2. Introduce character set to entropy pool. Stir vigorously.
3. Introduce processor to entropy pool. Note that some processors function well in the entropy pool environment while others produce various errors. Performance may vary based on processor model.
4. Optional: introduce processor-safe detergent and remove dirt and debris for the outer casing. Periodic cleaning will improve overall processor performance over time.
5. Initiate the pseudo-random character generation process by removing one character from the entropy pool and placing it on the casing of the pool. This casing will act both as a display device and as a character array to hold the final generated value. The initial character in the array will serve as the seed value.
6. Encourage the processor to repeat the process. Additional seed characters may be required to initiate independent processing, although be aware that a larger seed will result in less overall entropy in the final result.
7. Allow processor to operate on the task. The removal of characters from the result array and reintroduction to the entropy pool is expected, encouraged, and pretty much unavoidable. This should improve the entropy of the final value.
8. Continue process until the processor swaps threads for another program, begins to malfunction, or it is time for the processor’s sleep cycle. Be aware that if process swapping occurs, the processor may swap back to the PRCG task unaided. Once execution is deemed complete, extract the processor from the entropy pool and remove excess liquid. If characters remain in the pool, leave them; do not introduce them to the result array or you may taint the entropy.
9. Secure the processor to ensure proper ongoing function. Never leave the processor unattended without placing it in hibernation mode.
10. Once the processor is secure and you have an opportunity to return to the entropy pool, read and record the result from the character array. Be aware that characters will likely be oriented in unconventional and non-standard notation. Pick one corner of the display device and read the values in an organized fashion. For example, pick the upper left corner and read the characters left to right, returning to the left at the end of a row and repeating with the next row. Continue until all characters are read from the array. Ignore any characters that remain in the pool.
11. Store the result for later use.

Caveats, Limitations, and Additional Notes:

• The processor has a limited lifespan during which the pseudo-random functionality is optimal. It must have been upgraded sufficiently to execute crude motor skills, but not so far as to initiate higher pattern recognition skills such as character recognition, color matching, etc. that may taint the randomness of the result (i.e. an upgraded processor may inherently group characters of the same color).
• Most foam character sets have limited unique character values, such as the standard English alphabet or Arabic digits (0-9). Many times these characters sets only contain a single entry per character, eliminating the possibility of repeat characters in the final sequence and reducing the overall entropy of the result. Introducing additional character sets may increase entropy but may overwhelm the processor.
• Some foam character sets come with additional non-standard glyphs, often in the shape of iconic characters from animated television series. Before initiating the pseudo-random generation process, map standard characters, digits, symbols for the non-standard glyphs (Spongebob = asterisk, Patrick = pound hash, etc.).
• Sequence generation by this process is inherently slow and is likely not practical for everyday use. However, it does make for an entertaining thought exercise and will likely prove entertaining to owner/operators of the processor.

Just a head’s up to say I’ll be guest hosting Friday’s installment of the Jesus Geek podcast. I apologize in advance for any static or artifacts in the audio; chalk that up to my podcasting inexperience and not as an overall indicator of the quality of Jesus Geek as a whole. I’ll post a direct link to the download page as soon as I see that it goes live.

Update March 21: Aaaand… here it is.

The new GPF site has been running live for half a month now, and I’m proud to say things have been running incredibly smoothly. That is, at least, from my perspective; I haven’t seen any major glitches, and aside from a few typos in the comic (which are obviously independent of the site code), nobody has written me about any problems. This is especially heartening because the new site was pretty much entirely coded by hand by me, sans a few bits and pieces. (I can’t take credit for the OS, the web server software, the database engine, or the forum. But everything else… yep, that was me.)

There were a lot of motivations for writing my own archiving system, but the primary one was efficiency. While I considered trying something off-the-shelf, so to speak, like ComicPress or Drupal, I really wanted something that would be blazingly fast yet still dynamically generated to let me do things like GPF Premium on the server side, primarily for security reasons. (Server-side processing means no messy JavaScript is required by the users, thus exposing them to less risks, while Premium content doesn’t even get sent to the browser at all if Premium isn’t enabled.) So the GPF site is optimized out the wahzoo, with certain high-volume pages built once by nightly crons while others that require more interactivity reduce database queries to simple selects as much as possible. I’m never one to brag and toot my own horn, but I’m actually pretty proud of the new site and how responsive it is.

Of course, I can’t really take all the credit. I do have to give some serious props to XCache.

For those unfamiliar with PHP, it is one of many server-side, interpreted scripting languages commonly used for dynamic Web site development. The caveat, however, to any interpreted language is that on each request the source script must be read, parsed, compiled, and executed before anything is set back to the end user’s browser. This is one reason why dynamic sites are and will always be slower than serving purely static HTML files. Static HTML just needs to be read and regurgitated; anything that requires the Web server to actually think takes more time. Add to that the fact that there could be hundreds or even thousands of requests all competing at once for content and it’s a miracle anything get served at all.

XCache is one of several opcode caching extensions for PHP. Essentially, when the first request for a script is made, the script is parsed and compiled as usual. However, XCache stores the compiled code so subsequent requests can skip the parsing and compilation steps and go directly to executing the code. This significantly increases the speed of execution by eliminating one of the costliest parts of the process (except perhaps database connections). In addition, XCache also includes the ability to cache variables and objects, so commonly repeated and expensive variable generation–such as the cryptographic hashes I use for salting cookie hashes or database look-ups for common elements like the Premium subscription levels–can be stored in the cache rather rebuilt on each request.

I was first introduced to XCache by the XCache for WordPress plugin, which was probably mentioned in one of the development feeds built into the WordPress dashboard. I’ve been running this combination here on the blog for a little while with moderate success; I’m still trying to find a good balance of configuration settings to get the best results, but I’ve been happy with the results so far. Without putting much thought into it, I went ahead and installed XCache on the GPF server, hoping that it would help even if I never got a chance to optimize it. Fortunately, it has helped, and now that I’ve optimized the settings it’s exceeded most of my expectations. I’m not sure if there’s something about my code that caches better than WordPress, but GPF has done much better with XCache than the blog has.

Admittedly, I haven’t compared it to any other opcode cachers, nor have I benchmarked it against any of the competition. That said, however, I heartily recommend it to anybody running PHP applications. To get the greatest benefit, you may need to modify some code (or install a plugin if you’re using a prepackaged application) to take advantage of the variable/object caching. But even without modification the opcode caching alone makes for a vast improvement.

Not sure if anyone noticed, but both the blog and the new GPF beta test site were down last night. Our hosting service, Slicehost, informed us that a breaker blew in their data center and they were forced to bring a number of machines down to protect them. In addition, the blog server (which also hosts a number other private sites I run) stopped responding, so they had to reboot it again.

Unfortunately, while Slicehost was very informative and sent me several e-mails to keep me apprised of the situation, the sites continued to be down until early this morning. That’s when I discovered that for some bizarre reason the MySQL and Apache services were not configured to start at boot time. This is baffling, in my opinion, as I thought this was automatic with Fedora. You install the application package and, if it’s a service like this, it also installs the appropriate links in the init directories to make sure the services start on boot. Not so, apparently. I’m not sure if this is Fedora’s fault, Slicehost’s, or mine, to be honest, but it should be fixed now.

There’s one part of me thinks that this outage is an ominous sign on the eve of my leaving Keenspot. Then again, it also helped me catch a critical flaw that would have been extremely annoying if it happened a week later, after the move when thousands of readers would be hitting the new site. So I don’t know whether to be paranoid or relieved. (O_O)

Anyone interested in the history of webcomics should check out this week’s episode of the This Week in Tech (TWiT) podcast. Especially since it has nothing to do with webcomics.

Here’s my line of reasoning: In this episode, Leo Laporte and his unusual round of suspects are joined by Jonathan Coulton, geek musician extraordinaire. Aside from discussing a few topics of current note (like the death of HD DVD), they discuss a recent concert by Coulton where Leo and company joined him to play Rock Band before a nerd-filled audience. They go on to talk about the “new” Internet phenomena of niche entertainment targeting–skipping the big, mass-market blitzkrieg typically used by music, TV, and movie studios and canvasing thousands or millions of potential customers, to instead go directly to your core fans, the few dedicated people who are the ones that will really appreciate what you do. Coulton talks of making a living catering to a small handful of hard-core fans and how this is much more fulfilling that the big media alternative, where both the artist and the audience are faceless statistics on the bottom line of a balance sheet. And they discuss this with such freshness and enthusiasm, as if this is were the next new thing, some epiphany that no one has yet uncovered.

What I find so funny about it is… those of us in webcomics have already been doing this… for years.

I’ve noticed this a lot over the past near-decade of GPF’s existence. Blogs, podcasts, and other forms of grass-roots media have all cropped up during that time, putting publishing power in the hands of the masses, becoming “innovative” and “groundbreaking” in bringing content production to the people. But a fair number of “new” trends (and problems) associated with these technologies are things I remember seeing crop up among webcartoonists several years before. Long before the term “blog” was coined, I remember chatting with other cartoonists on mailing lists and news groups, swapping ideas about search engine optimization (before that term was coined as well), getting and retaining readers, how to monetize your site, etc. It’s entertaining now to watch many tech headlines to see “fresh” ideas crop up that I’ve personally tried–and abandoned–a couple years before. It’s like the wheel reinventing itself every couple of years, only with different colors and/or materials.

Of course, I would never be so conceited to believe webcomics “did it first.” Webcomics themselves borrow heavily from the underground comics movement of the 1950s, 60s, and 70s, where small independent publishers ducked under government sensors to push out innovated and controversial content directly to the people who wanted them. What changed between then and now is that the interconnectivity of the Internet moved this from basements and back rooms to hidden mailing lists and chat rooms, eventually making its way to the mainstream, all while expanding the sphere of availability from isolated pockets of common interest to global reach. It would also be naive to believe this flow of “innovation” is one-way; RSS and other syndication technologies took off first in the blogosphere, and was only later ret-conned and shoe-horned into webcomic automation systems as a handy update notification system.

Perhaps one of the reasons bloggers and podcasters didn’t learn any lessons from webcartoonists is the difference between skill level–real or perceived, take your pick–required for entry. Cartooning obviously requires some level of artistic talent as cartooning, in all of its myriad of forms, is a form of art. It’s often a commercial art, intended more to generate revenue than anything else, but an art nonetheless, conveying ideas and emotions graphically. And while a well-crafted blog certainly requires a talent for writing, that is often easier to come by than the ability to both write and draw. Thus the critical mass of webcartoonists is much smaller than that of bloggers and podcasters, making it less noticeable to the mainstream. That’s also why “break-out” blogs now seem to be a dime a dozen, but it’s still major news when an online comic gets noticed by big media and gets optioned for TV/movie deals. Everyone knows about blogs and maybe even reads a few, but there are other comics on the “intraweb” besides Dilbert?

I’m not sure if there’s anything useful to these observations, other than the fact that they amuse me occasionally and it gives me something to post about. I’m not sure if anyone else has made these kinds of observations or, for that matter, anybody else cares. But I’ve often wondered if those underground cartoonists of yesteryear thought to same way about us webcartoonists as I have about bloggers. I’d like to think so, just because it creates a nice symmetry. I can’t wait for bloggers to sit around in the old bloggers’ home, thinking such thoughts about whatever comes next. “Those kids with their holocasts… if they had learned the lessons we did about AI search, they’d be raking the quatloos by now….”