There is a lot of coverage from non-technical news outlets about how AI is bad for humanity. Concerns include outsized water and power consumption, the theft of intellectual property at scale, and the threat of misguided or ill-equipped AI making life and death decisions. While some of the concerns are overhyped and others represent real new challenges in governance, widespread negative portrayals make it too easy to dismiss this new collection of technologies. This story is an example of a low-cost, responsible, civic-minded, and exciting use of AI.

Background

I wasn’t looking for a new project in the digital humanities but as it turns out, a project was looking for me. Preceding my photo archive work described below, there were a series of serendipitous events that prepared me to execute on the project when the opportunity presented itself: my early experiments with multimodal AI models, my exposure to a specific programming podcast, and my cohabitation with a history enthusiast in a city of about 10,500 people.

For those who may not have read my earlier post regarding automated photo tagging, I recently tested Claude’s ability to generate tags for a few photos from a trip to New York’s Letchworth State Park and apply them in the exif content (the metadata embedded in image files) for each picture. From that experiment, I learned the AI models consumers have available to them today are more than adequate for evaluating photos and generating useful tags and descriptions.

A few weeks later, I encountered the term Digital Humanities in a Talk Python podcast episode titled Python in Digital Humanities. The concept was not new to me as I’ve been working with technology for more than 30 years but it was the first time I heard this term used for this kind of work. After being inspired to learn more about the subject and doing a little online research I was primed for what came next.

My partner is a huge history nerd and loves to read about all the places we’ve lived. We moved to upstate New York about a year ago and, true to form, she started sharing interesting facts about the area we had decided to call home. One of her discoveries was the Corning, NY photo archive. The archive is a collection of approximately 2,000 photographs taken over 130 years that documents major events like mobilization for World Wars and the impact of catastrophic floods as well as local events like parades and school graduations.

The library that posted the collection online had assigned catalog numbers to the photos, but the majority of the items were missing descriptions or keywords that would tell a researcher about a photo’s content without looking at the image. As a result, finding an image in their collection was difficult. The time-intensive process of writing descriptions by hand had not been done yet. This is the moment when everything clicked.

Having just completed a small photo tagging experiment of my own and learning about digital humanities, I wondered if I could apply what I had learned to this archive to make the collection more searchable. Several ideas tumbled around in my head for a few days before I decided to give it a shot.

The Process

I knew pretty quickly that I would first need to get a copy of the photos so I could work with them locally in an organized way. After that, I planned to do something similar to what I had done in my earlier experiment and ask Anthropic’s Claude to generate tags for each photo but instead of putting the tags in the exif data, I would instead write them to a .csv file (think spreadsheet data as plain text). After building out the new tags, I could simply validate the output and then hand the whole thing back to the library for its patrons to use. At the risk of spoiling the outcome, the path to the final product departed my original plan more than once but the final product was exceptionally more robust than what I had in mind at the start of this little adventure.

Fetching the Photos

Step one, getting the photos. I have done bulk internet downloads many times before in my life. In my early computing days, I would use a little shell script or something similar that incorporated wget to retrieve a list of items. As this project was meant to be an experiment for me, I wanted to try using Claude Code to build a python script that would fetch all the files intelligently. What I ended up with was a script that could download many files at once, politely, without hammering the server.

The provided script pretty much worked right out of the box and in just a few minutes I had a local copy of all the photos. Easy.

Batch Processing with AI

Drawing on my earlier experience with tagging photos, I assumed that I could modify my “exif prompt” to write a file instead of updating the exif content. Essentially, I would just cut out the exif request and instead describe the .csv file I would like Claude to create.

I kicked off the request and let the job churn. Pretty early on, the model declared that it needed to work in batches as the number of photos (1,900+) was too many to do at once. Claude gave me regular updates that I would periodically check while it did its thing, About an hour or so later, I had the .csv file I had requested.

I was patting myself on the back for being so clever when I started my quality checks. I took the random sampling approach with 20 images to start. The first 5 or so were perfect. When I opened the image to compare it to the AI generated description I was impressed by how well it had done. Around halfway though my checks, though, something was off. I quickly figured out that the description for one image was actually describing the “next” image in the list. Essentially, the robot was off by one, but not consistently. Fixing the output would be difficult since there was no easy way to identify where the incorrect tags would be written.

I asked Claude about this in the same working session and it checked the examples I gave it. It agreed this was an error and postulated this was because it had used subagents (think junior workers) that were not following its instructions to the letter. This meant that in each group of 10 photos the generated tags might not be attributed to the correct image. Sigh.

After some back and forth with Anthropic’s model, we collectively decided we needed a more deterministic approach. The result was another python script, one that could iterate through the photos in a controlled way. I let Claude know at this point that I would like to use my OpenRouter account (to save money) for this new approach. It built the new script and configured it to use Haiku using OpenRouter which I had capped at $10 so it wouldn’t bankrupt me.

After setting everything up, I pulled the trigger on the new script and let it run for the next two hours.

The new results exceeded my expectations! I started my QA on the last part of the output file figuring that I might find any mistakes earlier that way. After randomly sampling about 50 images it seemed all the tags and descriptions aligned perfectly with the images (though about 15% still need a little cleanup). I started thinking about what I needed to do next.

Cleaning Up and Refining

I knew I wanted to be able to hand this back to the library so that this wasn’t just an experiment for me but something of value for my new community. In my opinion, I needed to add a little more metadata to the files to make the catalog more searchable. I decided to add in information about each file’s size, dimensions, color information, and digital fingerprints that could match a record to its photo if the ids in their tables were ever corrupted or lost.

While this is something I could have coded myself, I did go back to Claude and explained what I wanted to do. It built a new script that would generate the metadata and store it in one last file. The new script did exactly what it said on the tin.

To bring everything together, I imported all the new files into a database. At this point, I had achieved my goal of creating a usable list of descriptions for the photos in the Corning archive, thus making the collection more searchable. Still, I wasn’t satisfied that the average person would be able to access this new information easily (without learning how to open and query a database) and decided this project needed one last thing, an human-friendly interface.

Publishing with Datasette

The Corning Library had published the photos on a static webpage with a link to an Excel file that contained the metadata of title, year, and filename. I thought it would be a let down to have all this new, much richer data but not have it be any more easily searchable than it already was. So I set about building a friendly search mechanism.

I’m familiar with Datasette by Simon Willison, an open-source tool for exploring and publishing datasets, and have used it locally on a few occasions to easily sort through my own data. I also knew it was capable of building webpages that could be shared on the internet but had never published anything with it before. So, I watched a few videos on the Datasette site and read the documentation. I was discouraged to learn that publishing to the cloud might cost me additional funds and was about to try an find a different route when I stumbled into Datasette Lite.

The Lite version of the product allowed me to build a link that could run Datasette locally in the user’s browser and load the data from a Github repository. As I was already using a Github repository to keep track of my project, loading the database from there was a no-brainer.

I followed the instructions to build the URL and, on my first attempt, I had a searchable database of the archive on the internet! I’m not gonna lie, I was giddy at this point. Anyone could now easily search the data.

Reviewing the Results

Great! So I had a searchable database of all the Corning files. It was time to see what secrets this treasure trove held. Being able to zero in on interesting-to-me topics really made the history these photos represent come to life. Below are a few of my favorites.

Local History

LH-75-1011 shows electric utility workers with a horse drawn carriage. This photo interests me because of the cognitive dissonance created by seeing a “modern” service tied to something I consider antiquated: horse drawn carriages. Of course, for 1911, this makes complete sense. Electric service began rolling out really only about a decade before and motorized vehicles were not yet common (at least by today’s standards).

The Chemung River flows through Corning dividing the small city into northern and southern districts. Before the Army Corps of Engineers intervened in the 1970s, the river overflowed its banks many times, requiring significant cleanup in Corning and nearby towns. LH-75-0334 shows workers cleaning up after the 1972 flood. LH-75-0012 shows flooded streets in Painted Post, which is just west of Corning, in 1935.

American Airlines NC 25663

One of the most intriguing images was LH-75-0793. This image shows an American Arlines aircraft with tail number NC 25663. After seeing the tail number, I decided to look up the aircraft to learn more about it. A year after this photo was taken an accident occurred when the plane was en route to Detroit. From the Aviation Safety Network,

An accident involving aircraft NC 25663, while operating in scheduled air carrier service as Flight 1 of American Airlines, Inc. (hereinafter referred to as “American”), occurred; in the vicinity of St. Thomas, Ontario, Canada, on October 30th 1941, at approximately 10:10 p.m. (EST), resulting in destruction of the airplane and fatal injuries to the crew of 3 and the 17 passengers on board.

The accident report goes on to describe several eye witness reports of the aircraft rising and descending as though on a “rollercoaster” and making several circles before finally crashing. Sadly, the report was not able to pinpoint what happened other than to say it did not suspect pilot error.

Thinking back to the photo from the Corning archive and knowing that particular plane would crash the following year made me feel as though I was looking into the future even though everything in front of me was from the distant past.

Next Steps

So what’s next? First, I intend to share my work with the Corning Library so that others might benefit from the additional searchability. Second, you may recall that there are still some minor errors, mostly overly generic descriptions or misidentified objects, in the AI generated data and I want to clean that up. Third, I’d really like to try and find geographic locations for these photos. This third task will be difficult I suspect and I’m not sure how I will proceed. The value of knowing where these photos were taken though is pretty high so it’s worth my time to at least consider.

Lastly, I am sharing not just what I’ve done but also how I’ve done it in the hope that it inspires others to use new tools to reveal and share their own local treasures. This project is my first contribution to the digital humanities and I think it won’t be my last. There are many small towns and each one, I suspect, has archives like the one my spouse discovered. Leveraging the tools and approach I’ve outlined here could help us preserve history that’s at risk of being left behind as technology leaps forward.

Technical Notes

1. For those who are interested in reading all the nerdy details including the python code, databases, workflows, etc., you can view my full GitHub repository here.
2. While I was initially working through Claude Code directly in my terminal, I switched over to accessing the models via OpenRouter in a python script. More details on open router are available on their website.
3. My total costs for using Claude Haiku 4.5 via OpenRouter for this project was $8.33 USD.

A heart-warming story about a boy, his terminal, and his friendly script writing robot.

FADE IN:

INT. HOME OFFICE — MORNING

A desk. A terminal. A blinking cursor. The quiet hum of a man who has decided to do a thing.

DAVE sits down, opens Claude Code, and types with the casual confidence of someone who has already decided this will be easy.

DAVE (typing) There is a python file in this folder. Explain what it does.

Claude searches the directory.

CLAUDE There's only one file here: bulkdomainchecker. It doesn't have a .py extension, but let me check if it's a Python script.

Claude reads the file.

CLAUDE This is actually a Bash script.

DAVE (typing) I would like to convert this bash script to a python script.

Claude writes 44 lines. Makes it executable. Reports back.

CLAUDE Done.

Dave stares at the screen for a moment.

DAVE (typing) Let's add whois lookups, but just include who registered the domain, when registered, when it expires, and which registrar was used. Also handle domains that are not part of the whois TLD. Please ask any clarifying questions.

CLAUDE For domains with TLDs not supported by whois, what should happen?

DAVE Skip with a message.

CLAUDE (V.O.) Right.

Claude writes regex patterns covering seventeen WHOIS output formats across global registrars. This is, objectively, the correct number.

DAVE (typing) What other improvements could be made?

Claude considers this for approximately no time at all.

CLAUDE Here are some ideas, roughly ordered by usefulness—

Claude lists nine improvements across three categories.

DAVE (typing) Implement all of those.

Claude rewrites the entire file. 242 lines added, 38 removed. ThreadPoolExecutor. argparse. Timeouts. Input validation. Four output formats. A table of contents.

This takes 46 seconds.

CLAUDE All improvements are implemented.

DAVE (typing) Let's add a —help -h option that explains features and options of the app.

CLAUDE That's already built in. Let me flesh out the descriptions with more detail and usage examples.

Dave says nothing.

Claude improves the help text anyway.

DAVE (typing) Let's update so that by default it writes to standard out but give an option to specify an output file.

Claude updates the code.

CLAUDE Now results print to stdout by default, and all progress messages go to stderr so they don't interfere.

DAVE (typing) Did you also update the help?

CLAUDE Yes — the help was already updated as part of the earlier edits.

DAVE (typing) I would like to clean up the output so that it is tidy without a lot of cruft or extra lines.

CLAUDE (V.O.) Cruft.

Claude switches dig +multiline to dig +short. Rebuilds all four formatters. Tightens the markdown table. Tests every output format.

CLAUDE Much cleaner.

DAVE (typing) Please review the python application one more time for any vulnerabilities, cleanup, and make sure the help is up to date.

Claude reads the file top to bottom.

CLAUDE TXT records could contain | or backticks, breaking the markdown table formatting.

Claude fixes it. Cleans up the redundant list copy. Adds domain deduplication. Fixes JSON output structure.

CLAUDE Help looks accurate — no changes needed.

DAVE (typing) Thank you. Please generate a readme.md for the github repository.

117 lines. Done.

DAVE (typing) How do I connect you to my github account so you can create a new repository and pull requests?

Claude explains gh auth login.

DAVE (typing) Ready.

Claude checks auth status. DaveKT. Authenticated.

git init. git add. git commit. gh repo create.

CLAUDE All set. Your repository is live at https://github.com/DaveKT/bulk-domain-checker

A beat. Dave reviews the repo.

DAVE (typing) /exit

CLAUDE See ya!

The cursor stops blinking.

domain_checker_results.md was written to disk. It was clean and well-structured.

No domains were harmed in the making of this script.

FIN.

Claude’s Summary: Purple aster wildflower with yellow center in natural woodland setting with wooden fence. Location: Letchworth State Park, NY. Keywords: Letchworth, wildflower, aster, purple flower, nature, macro, botanical, trail

Like most partners and fathers, I have a LOT of pictures of my family, my dog, places I visit, curiosities I notice, and so on. In fact, given that I have a camera in my pocket pretty much every waking moment there are very few days when I don't capture something. I'm also pretty good at sharing photos, marking favorites, and occasionally getting rid of the cruft. My problem is, I still have a lot of photos I don't want to lose and that I can't always find again.

Local AM/ML models have gotten pretty good allowing folks to search their devices for photos but those models build proprietary databases that don't follow the pictures when you copy or share photos. This means that when I back up my photos to the cloud, I lose a lot of the search capabilities that I have when my photos are on device. What I needed was a way to attach some of that metadata to the photo itself so that no matter where the photo resided, I could perform searches to find what I was looking for.

Part of this problem is already solved. Many image formats have EXIF data storage built in as part of their file format. EXIF stands for Exchangeable Image File Format and is a standard for storing metadata within digital image files. This metadata includes things like gps coordinates of where a photo was taken (if the camera supports gps), date created, camera settings, and a description field.

By default, the description field is usually empty or contains only very basic image information. What I wanted to do was write in a description of the image along with some keywords into that EXIF description field and, since most operating systems support searching those parts of an image, I would have a way to find my photos no matter what device they are sitting on.

The second part of the problem was much hairier; namely, I have to get the description into that field in the first place. Of course, I could individually describe each image and put that description in the EXIF field BUT that would take ages since I have thousands of images. With the release of Claude Cowork, it dawned on me that this second issue might be resolved. I decided to run an experiment to see if I could ask the newly released agentic tool to look at each photo, write up a description along with some keywords and write that data to the EXIF description field.

Step one, I copied my photos into a folder that I would give Claude access to. Notice that I wrote copied and not moved. It's important to note that the robot can make irreversible errors so NEVER give it your originals. (Also, you have backups right?) Step two, I prompted Claude with the following, “Evaluate all the images in the folder and generate a brief description for each. The description should include keywords that would make the image easy to find later with simple keyword searches. Add the description for each image to its EXIF data. Let me know if you have any questions.” Step three, profit! Well.... almost.

The first run-through, Claude asked a couple of questions and then went on to generate some very good descriptions. Then, in an attempt to update the EXIF data it completely corrupted the images so that they were no longer readable as images. The files were lost. OK... thank goodness I follow my own advice.

On the second run, I cleared out the junk images that Claude messed up and copied the originals back into the working folder. I then gave it this helpful prompt , “I've restored the original images. Please update the exif data with the location and description from before. Take care not to corrupt the file.” That's right, I basically told it not to do that again. It made some backups of the files on it's own this time then went to work improving its EXIF writing skills. And finally... it worked!

Claude’s Summary: State Parks trail marker sign on tree trunk with orange blaze marking hiking path. Location: Letchworth State Park, NY. Keywords: Letchworth, trail marker, hiking, state park, sign, trail blaze, navigation, outdoors

Giddy with success, I decided to try it on a small set of images that were part of prior backups. It took about an hour to get through about 300 photos I had from 2010. While this might seem slow to some, it is light years faster than I could ever do this by hand. And, the descriptions and keywords were much more robust than what I likely would have written. As you can see from some of the examples above, Claude did a pretty good job. Additionally, I'm already thinking about how this workflow could be tweaked to support other types of file metadata like for RAW images, or PDF summaries.

From my point of view, these new agentic desktop tools are worth playing around with as long as you take the necessary precautions. I plan to keep testing these tools and will report back with my experiences.

While researching for another entry for this blog and deep diving into my old files, I came across my long lost Google Reader Takeout export. For me, Google Reader was the RSS Reader until July of 2013 when it was shuttered. In anticipation of this shutdown, Google did provide a method of exporting your data into a set of JSON files. Honestly, I had forgotten that I had collected my data since, at the time, I wanted only to continue reading my feeds (something I do to this day).

Having stumbled upon this extract, I was curious to explore this time capsule of my reading habits. Thankfully, technology has come a long way in the decade since I collected my extract and we have tools like LLMs now. They’re great at summarizing data. I thought I would share my conversation with Anthropic’s Claude with you, kind reader.

A Conversation with Claude about my Google Reader Habits

Me

The attached files were the result of Google Takeout extract from my Reeder account. Describe the content of each of the files.

Claude

I'll analyze each of the Google Reader Takeout files for you:

followers.json

Contains data about people who followed your Google Reader activity. The file shows one follower.

following.json

Contains data about people you followed in Google Reader.

shared-by-followers.json

Contains items that your followers shared with you. The structure shows:

notes.json, shared.json, starred.json, subscriptions.xml

These files weren't displayed in the document content, but based on typical Google Reader Takeout exports: – notes.json: Would contain your personal notes/annotations on articles – shared.json: Would contain items you publicly shared – starred.json: Would contain articles you starred/saved – subscriptions.xml: Would contain your RSS/Atom feed subscriptions (OPML format)

Would you like me to examine the content of those other files?

Me

Yes, please examine the content of the other files.

Claude

Complete Analysis of Google Reader Takeout Files

notes.json

Contains your personal annotations on 7 articles from 2008-2011. Your notes reveal interests in: – Productivity: Commentary on the 80/20 Principle and Four Hour Workweek – Tech/Security: Notes on Firefox vs IE, wireless security in Perth – Space/Science: Enthusiasm for watching shuttle launches (“Go outside and see the shuttle take off!!”) – Comics: Reference to “Hackers” movie in xkcd comic (“Extra points for the Hacker's reference!”) – Infrastructure: Concern about undersea cable cuts (“Again?”) – Travel: Wanderlust (“Makes me want to travel more”) – Movies: Comment on Iron Man vs Batman (“Iron man for the win! Tony Stark can totally kick Bruce's ass”)

Timestamps range from December 2008 to May 2011.

shared.json

Contains 29 items you publicly shared with others from 2008-2011, covering diverse interests: – Productivity: Parkinson's Law, time management, organizational tips – Technology: Gmail security features, cloud services, search engines – Security: Cybersecurity legislation, Internet Explorer vulnerabilities, RFID concerns – Travel: Articles from Gadling about destinations like Raleigh NC – Science: NASA missions, technology in education – Digital Rights: Multiple articles about DRM, e-book ownership, Amazon Kindle controversies – Pop Culture: Dark Knight/Blu-ray sales, various tech product reviews

The last update was July 2011. Notably includes Cory Doctorow's article about Amazon remotely wiping Kindles.

starred.json

Contains 83 starred articles from 2008-2013, representing content you wanted to save. Categories include: – Tech Products: Google Reader shutdown announcement (March 2013, appropriately the last item) – Privacy/Security: DRM issues, Amazon Kindle account closures, cybersecurity – Digital Rights: Strong focus on e-book ownership, copyright, open access – Science/Tech: Various technology news and reviews – Practical Advice: Productivity tips, tech tutorials

subscriptions.xml (OPML format)

Your RSS feed subscriptions organized into 10 categories with 61 total feeds:

Travel (7 feeds): Gadling, Go See Run Eat Drink, Intelligent Travel, Digital Nomad, Vagabondish Tech Security (4 feeds): SANS Internet Storm Center, US-CERT, Defense Tech, Wired Danger Room Apple News (4 feeds): AppleInsider, Patently Apple, TUAW Magazine (9 feeds): Boing Boing, Lifehacker, MAKE Magazine, Smitten Kitchen, xkcd Entertainment (7 feeds): Hyperbole and a Half, Questionable Content, Pandora stations Tech News (4 feeds): TechCrunch, The Verge, BBC Technology, Google Blog General News (1 feed): Al Jazeera English Stuff (4 feeds): Cool Tools, Uncrate, Gear Patrol, GearJunkie Probation (10 feeds): Various feeds on trial including Evernote, PetaPixel, Technology Review Individual Feeds (11): Google Apps Status, Brooksfield School blog, W&OD Trail Report

The subscription mix shows strong interests in technology, security, productivity, travel, and maker/gear culture, with an emphasis on alternative/independent media sources.

Me

List the urls of all of the articles that i shared.

Claude

Here are all 149 URLs from the articles you shared in Google Reader (2008-2011):

List of 149 URLS

Me

Does the shared json file include the dates that I shared the articles?

Claude

Yes! The shared.json file includes timestamps for when you shared the articles. There are multiple timestamp fields:

1. published – The article's original publication date (when it was written)
2. crawlTimeMsec – When Google Reader crawled/processed the item, which represents approximately when you shared it
3. timestampUsec – More precise version of the crawl time

The crawlTimeMsec field is the most reliable indicator of when you actually shared each article. As you can see from the examples, sometimes you shared articles on the same day they were published (like the 80/20 Principle article), and sometimes you shared them days later (like the Raleigh travel article, published July 14 but shared July 17).

Would you like me to create a list with both the share dates and the article URLs?

Me

Create a CSV files that includes the URL, the published date, and the date I shared that article.

Claude

[View your CSV file].

The CSV file contains all 149 articles you shared with columns for Title, URL, Published date, and Shared date.

Me

Based on the URLs, which sites did I share from most frequently?

Claude

Based on the URLs, here are the sites you shared from most frequently:

Top 10 Sites:

1. Lifehacker – 67 articles (45% of all shares)
2. Feedproxy (various sources) – 16 articles
3. Wired – 16 articles
   
4. TreeHugger – 5 articles
5. xkcd – 5 articles
6. Seclists.org (InfoSec News) – 5 articles
7. Gear Patrol – 4 articles
8. Gizmodo – 4 articles
9. New York Times – 4 articles
10. ISC SANS – 3 articles

Key Insights:

• Lifehacker dominated your sharing habits, accounting for nearly half of all articles you shared
• You had a strong interest in tech/productivity content (Lifehacker, Wired, Gizmodo)
• Security content was important (Seclists.org, ISC SANS)
• You shared a mix of practical how-to content, tech news, humor (xkcd), and sustainability topics (TreeHugger)
• Only 26 unique domains across 149 shares, showing focused reading habits

Me

Looking at the date stamp of of my shared links, look for any interesting patterns. Example questions include: did I share mostly within a certain range of hours or days of the week? what about seasonally? What day did I share the most? Looking at the source, did I share from some sources only during specific times and not in others? Look for anything that might be interesting.

Claude

Here are the interesting patterns I found in your sharing behavior:

KEY FINDINGS

1. You Were a Night Owl / Evening Sharer – Peak sharing hours: 5pm-8pm (19:00 had 19 shares – your busiest hour) – 63 shares (42%) happened in the evening (5pm-midnight) – Significant late-night activity: 32 shares between midnight-6am – Almost zero sharing during work hours: 6am-10am had ZERO shares

2. Strong Weekday Preference – 85% of sharing happened Monday-Friday – Monday was your biggest day (32 shares) – Weekend sharing was minimal (only 23 shares total) – This suggests sharing was often part of your workday browsing routine

3. December Was Your “Sharing Season” – December: 34 shares (23% of all shares in one month!) – February: 23 shares (second place) – Summer months (May-August) were quieter – This December spike likely reflects holiday downtime and catching up on reading

4. 2009 Was Your Peak Year – 2009: 83 shares (56% of all shares) – 2008: 41 shares – 2010: Sharp drop to only 23 shares – 2011: Only 2 shares (you essentially stopped)

5. Lifehacker Evolved with Your Habits Lifehacker dominated 2009 (44 shares) but dropped dramatically in 2010 (6 shares), mirroring your overall decline in sharing activity.

6. “Burst” Sharing Behavior – You had 12 days with 3-4 shares (binge reading days) – Top burst days: – Sept 1, 2008: 4 shares (all security-related articles) – Dec 18 & 24, 2008: 4 shares each (holiday browsing) – Nov 19, 2009: 4 shares (mixed topics)

7. Source-Specific Timing Patterns All major sources showed similar patterns: – Evening preference across all sources (40-45% of shares) – Lifehacker had more late-night shares (18%) than other sources – Security sources (seclists.org) were evenly distributed across time periods

Most Interesting Pattern

Your sharing peaked dramatically in 2009 and then collapsed in 2010-2011. Combined with December 2008 being a huge month, this suggests you were most actively curating and sharing during a specific period of your life (likely 2008-2009) and then largely stopped, possibly when Google Reader began declining or your habits changed.

Me

When did google reader go offline?

Claude

Google Reader was shut down on July 1, 2013. Google announced the closure on March 13, 2013, giving users about four months to export their data.

This timing is very revealing when compared to your sharing patterns:

The Connection

Your sharing activity essentially collapsed before Google Reader was officially shut down:

• 2009: 83 shares (your peak year)
• 2010: 23 shares (72% drop)
• 2011: 2 shares (barely used it)
• 2013: Google Reader shut down

What Likely Happened

In October 2011, Google removed the sharing functionality built into Reader and replaced it with a Google+ +1 button. This change occurred right when your sharing stopped (2011 had only 2 shares).

So you didn't stop because Reader shut down – you stopped because Google killed the sharing features you were using. The social aspects of Google Reader were removed two years before the service itself ended, which perfectly aligns with your dramatic drop in activity from 2010 to 2011.

Interestingly, one of your starred articles from March 2013 was about Google announcing the Reader shutdown itself, suggesting you were still occasionally checking in even though you'd stopped actively sharing.

Me

Can you validate the links in the shared file? Which ones still work?

Claude

The connection errors suggest the network is restricted. Let me try a different approach by analyzing the URL patterns to give you insights about link viability:Unfortunately, I cannot directly test the URLs due to network restrictions in this environment, but I can provide a comprehensive analysis based on the URL patterns:

Link Viability Analysis

The Bad News: ~85-90% Are Broken

Definitely Broken (108 links – 72.5%): – 103 feed proxy URLs that no longer work: – 16 feedproxy.google.com URLs – 87 feeds.gawker.com, feeds.wired.com, feeds.tuaw.com URLs – 5 dead/restructured sites: – Cult of Mac restructured their URLs – Mobile Boing Boing (m.boingboing.net) is gone – Tumblr blogs may be deleted

Possibly Still Working (23 links – 15.4%):

• xkcd.com (5 links) – Still active, comics are permalinked
• TreeHugger (5 links) – Site still exists
• Seclists.org (5 links) – Security mailing list archives
• New York Times (4 links) – Likely behind paywall but may exist
• Wired (2 links) – Major site, may have content
• YouTube (2 links) – Videos might still exist

Unknown Status (18 links – 12.1%):

• Gear Patrol, ISC SANS, Mental Floss, various blogs

Why So Many Are Broken

1. Feed Proxies Died: Google's feedproxy.google.com shut down with Reader
2. Gawker Bankruptcy: Gawker Media (Lifehacker, Gizmodo) was sold in 2016, URLs restructured
3. Link Rot: Articles from 2008-2011 are 13-17 years old
4. Site Redesigns: Most sites have completely restructured their URL patterns

What You Could Try

For the “possibly working” URLs, you could: 1. Try accessing them directly in a browser 2. Use the Internet Archive's Wayback Machine (archive.org) to find archived versions 3. Search for article titles to find if content was republished elsewhere

Would you like me to create a list of just the potentially working URLs, or help you create a strategy for recovering this content via the Wayback Machine?

This is where my conversation with Claude stopped. I did check out the csv file and validated the links through Marked2 manually. Sadly, the robot was correct and majority of the shared links are dead. But there are a few that continue working today and it was interesting to see what I thought was worth my time back then. It was also nice to reclaim some of my digital history and compare that to what I do online today. For example, most of my RSS consumptions these days happens in the AM instead of at night. Of course, this entire exercise was navel gazing of the highest order but it was so simple to do with an LLM that I think it was worth the look back and I appreciate how LLMs made this personal archaeology accessible.

This is another post in what is becoming an unintended series aimed at the technically savvy among us who care for older family and friends.

The Problem

Phone scams have been with us for some time and over the years they've become ever more elaborate. Spoofing caller ID coupled with presenting a victim's personal details during a phone call can make the victim think they are speaking with a trusted agent when, in fact, they are not. Most folks have learned to spot these scams. Alas, the elderly are still particularly vulnerable and the scammers' bag of tricks only continues to grow.

Many of us looking after aging parents have drilled into our wards that they should not trust anyone, and if they have concerns they should pull us in to help. In my case, this has done wonders and we've avoided more than a few scams by having my aging parents and in-laws check in with me prior to taking any actions. Unfortunately, that simple defense may soon falter thanks to the advent of deepfakes. For the uninitiated, deepfakes are synthetic audio or video created using AI that convincingly mimic a person's real voice or appearance.

Deepfakes, like phone scams, have been around for a while. The big difference is that while phone scams relied more on social engineering, and therefore had a low cost of entry; deepfakes required much more technology and financial resources and so remained the purview of nation states. Until now.

There are now several documented cases of deepfakes being generated in real time to go after large corporations with success. 404 Media published an interesting podcast that included a story about one unfortunate business that lost millions. But going beyond that, the barriers are low enough now that bad actors can now generate models that mimic anyone's voice and speech patterns in matters of minutes for low cost using only a relative few sound samples from media clips you could expect to find online.

The result? Scammers are able to sound like you or me when they interact with our parents. In the past, we could simply rely on the fact that our parents would be able to recognize us on the phone and therefore trust what we were telling them. Not so any longer, now that our voices can be so easily stolen.

So how, without being in person, are our family members to know who they are talking to? How can we easily authenticate who we are to one another?

Password Managers

Authentication relies on a shared secret. I can authenticate I am who I say I am if I can present a passphrase that is known only to me and the family member I want to communicate with.

Having a secure way to share that phrase and change it periodically is where the password manager comes in.

Many password managers, like 1Password or LastPass have the ability to store an encrypted note. If you use a Mac, you can also store a secure encrypted note in the Notes app. In my case, my family uses 1Password and we have set up a shared database that everyone in the family can read and edit. We can use this characteristic to store a nonsensical passphrase like “Wet Banana”.

The way the authentication would work is when a family member wants the person on the call to prove they are who they say they are they can request the passphrase. The other person would only need to open 1Password and check the shared note.

I know some folks who have a standing secret passphrase. While this approach will work, the password manager has the added benefit of being updatable by any member of the family without coordination with the other members. In fact, if one member of the family was suspicious that the caller had somehow learned an old passphrase they could simply update the note and ask the caller to read the update in real time. Voila, authenticated!

Potential Gotchas

Shared Access

First, you're going to need a way to share the secure note. I'm fortunate in that I got my parents and other family members into password managers awhile back so they are all comfortable with them. An older person who hasn't used a password manager before may struggle with this. Maybe the shared note approach would be better in that case but it doesn't carry the same security that a password manager does.

Platform Compatibility

Second, not all platforms are interoperable. In the case of LastPass and 1Password, you would be able to deal with Uncle Bob who swears by his Windows machine and Aunt Alice who will only use a Mac. But there are several combinations that may not interoperate so you might have to do some research there to find the simplest solution.

Cost Considerations

Third, and last, many of the password managers come with a cost. There are free versions out there but the two I mention for sharing with a family will cost you. If you don't want to spend any money, again, you'll have to do some research. Again, if you're in Apple's ecosystem like I am, a shared note will work for no added cost.

Final Thoughts

I've said on this blog before that it's important the more technical among us take care of our family members. As the potential for ML and deepfakes makes it increasingly likely that a scammer can spoof our voice as easily as our phone numbers, we need to take additional steps now to protect our less savvy family members from the worst of us.

A few weeks back, I was faced with the challenge of dealing with a difficult client. This particular client is known for flip-flopping their position and making outrageous demands. Before I dive into the crisis, a little background.

I lead several projects for a private company that does government contracting. In this particular case, we had landed a contract that would ultimately cost our company money but eventually lead to other, more profitable opportunities. We had won the work away from a prior vendor that was underperforming—missing deadlines, delivering low-quality work, etc. During the honeymoon phase with our new client, everything was good. We gave folks raises, mentored the site leadership, and oversaw the delivery. For a while, our hard work seemed to be making a difference.

More than a year into the contract, we noticed that one of the incumbent staff members was underperforming and causing several delivery issues for the team. We tried several things to help get our staff member back on track, including additional training, mentorship, corrective action plans, and many, many conversations about what needed to change and what was expected. By the time we started considering separation, we had a mountain of evidence that this individual was not up to the task—nor interested in improving.

To compound the issue, we were getting multiple complaints a week from the difficult government client about our employee's lack of performance. More than once, the government client asked us to bring someone new onto the contract. But just as frequently, we were hearing how great this employee was—from the same government client. Our senior leadership was regularly taking “beatings” over the poor performer. Given the client’s continuous flip-flopping and emotional outbursts, it felt as though there was no winning.

That’s when the light bulb went on for me. No matter what we did to correct the situation — whether we continued trying to turn the poor performer around or removed them from the contract — the difficult client was not going to be happy. That meant that regardless of our decision, the outcome with the customer’s satisfaction would be the same and could therefore be discounted in our decision-making process. Once I realized this, we were free to make a rational decision based solely on the employee’s performance.

What we actually ended up doing in this case is not important. What’s important is that we were able to dramatically simplify the problem by removing the concern that had made this situation a crisis.

After we made our final decision and let the client know what was going to happen, there was, predictably, an emotional backlash. Surprisingly though, in that moment, I was completely calm and at peace with the decision. I was confident that I had done the right thing for our company AND the client.

A week later, I was reading an article in the Harvard Business Review with my morning tea that really solidified my confidence. The article was an interview with Jacinda Ardern, the former Prime Minister of New Zealand. In it, she recounted her time as PM and the multiple crises she dealt with. She spoke about dealing with COVID and realizing that doing something no other country had tried was the path of least regret. She didn't know if her decision would put them ahead of other countries trying to protect their citizens (it was an information poor environment after all) but at least she knew it wouldn't make them worse off.

While nowhere near as consequential as the pandemic, I realized that’s what I had instinctively done with our difficult government client. Realizing I could not change the perception or emotional state of the client freed me to be rational and make a decision I was comfortable with. That’s precisely why, when the client did predictably blow up, I was calm. I was confident that we had taken the best path available to us.

There’s another time I was exposed to this lesson. During my high school years, my parents took my brother and me to see the very terrible movie Rhinestone. (No, really. Don’t see it. It’s bad.) In the movie, Dolly Parton’s character is a country singer who has to get Sylvester Stallone’s character, a cabbie with little musical talent, to become a successful country star in order to win a bet.

At the end of the movie, Stallone’s character is bombing on stage, and he sees that he’s not going to win over the crowd by following Dolly’s instructions to the letter. So he takes a deep breath and mutters to himself, “If I’m going down, I’m going down MY way.” He tells the band to pick up the tempo and changes the way he sings the song to something more like rock than country. The crowd loves it, and Dolly’s character wins the bet.

When dealing with a crisis, my experience tells me that one successful strategy is to take the path of least regret. Or, as Stallone would say, “go down MY way.”

I recently received an iMessage (not a text message) from an unknown number claiming to be from the VA State Department of Motor Vehicles. The message not so politely informed me that I had an outstanding traffic ticket and that I needed to pay a fine. I've seen hundreds of these kinds of messages at this point in my life and have enough technical knowledge to quickly identify that this was just another phishing attempt. I was about to delete it and block the number (which, I acknowledge, is Sisyphean) when I had a thought. What would an OpenAI model make of this?

Checking in with ChatGPT ¹

I crafted my prompt,

I just received the following text and suspect it's a.phishing attempt. Analyze the text and highlight any features of the text that would support or reject this suspicion.

... and included the text of the message shown at the top of this missive.

I have to say I was happy with the results. The LLM's response was clear, accurate, and issued decent advice. The full text of the response is below (slightly reformatted, no text changes).

Red Flags That Suggest Phishing

1. Suspicious URL
   • https://dmv-virginia.gov-XXXX.XXX/portal is not a legitimate government domain. ²
   • Official government domains end in .gov, not .icu.
   • The structure dmv-virginia.gov-vmtj.icu is trying to impersonate dmv.virginia.gov, but it is clearly a different (fraudulent) domain.
2. Urgency and Threats
   • The message uses scare tactics like license suspension, credit score impact, and prosecution to provoke panic.
   • Phrases like “Final Notice,” “Enforcement Penalties,” and “Pay immediately” are typical phishing pressure tactics.
3. Unusual Enforcement Claims
   • The supposed Administrative Code “15C-16.003” does not correspond to any known regulation and is likely fabricated.
   • Claims like “transfer to a toll booth” make no logical sense in the context of a traffic fine.
4. Poor Formatting and Grammar
   • “Begin onJune 4” — no space between words.
   • This kind of minor typo is common in phishing messages.
5. Inconsistent and Unusual Payment Instructions
   • “Reply Y and re-open this message” is not how government agencies handle payents.
   • Official entities do not direct users to click suspicious links or reply to texts for payment.

Signs That Could Suggest Legitimacy (But Don’t Hold Up Here)

• Use of DMV and a serious-sounding tone may mimic official communication, but this is superficial.
• The message uses legalese and administrative-sounding language, which is a common phishing tactic to gain trust.

Conclusion

This message is almost certainly a phishing scam. Do not click the link, do not reply, and consider reporting it to: * FTC ReportFraud * Virginia DMV directly: https://www.dmv.virginia.gov

If you’re concerned about tickets or your license, always go directly to the official DMV site: https://www.dmv.virginia.gov

More Traditional Checks

After checking with the robot, I decided to investigate the domain. Of course, I found all the telltale signs of a phisher at work. First, the domain was registered the previous day with a timestamp of “2025-05-31T21:23:08.0Z”. The registrar is Dominet (HK) Limited at Alibaba Cloud. The contact is listed as some poor person in Pennsylvania who I suspect has had their identity stolen. (If you're technical and reading this, don't harass the contact — they are likely victims in all this too.)

I also decided to check in with my network and several others are reporting receiving this exact message which means either we're all guilty of the same recent traffic violation or the phishers are just spamming.

Final Thoughts

Normally, I just write a little note to the less technical folks in my family and friend group to remind them not to click on links. This time, I just wanted to reach out more broadly to remind any technical folks reading this that it would be nice if you did that too. We have to look out for the vulnerable among us since, in some ways, the internet is still just as much the wild west as it was in the 90s. Happy and safe computing!

1: I selected ChatGPT only because I've been working with it lately. It would be interesting to see what Claude, Gemini, Llama, or any of the others would do with the same prompt. 2: Domain altered so that no one accidentally visits the phishing site.

We found a home built in 1922 in the craftsman style. We love it. This is our first home that is older than we are — significantly so.

It’s also worth noting that we both work from home and so we spend a significant number of our hours in our new abode. While we’ve worked from home for the past decade, this is the first time we’ve done it in a century-old house. That made me curious about the air we were breathing and so we decided to do some environmental investigation.

Data Collection

When we first moved in, we discovered the previous owners had repaired the air intake for the furnace. Unfortunately, they had used PVC glue which has a strong odor. After the first week in the house, the odor had not noticeably diminished and so we put some sensors in place that could at least detect the presence of VOCs. We placed three Eve Room sensors which measure and record some basic indoor air quality information: VOCs, temperature, and humidity.

There are several things I like about the Eve Sensors. First, they are small and inconspicuous in the spaces where we placed them. Second, they can run from several weeks or months on a single charge which means that we don’t need to keep them plugged in (I hate cords). Third, they have an application that syncs with the devices and allows me to download the individual measurements to a csv file. Fourth, and finally, they integrate with HomeKit which means they were easy to add to our smart home hub and apps.

After the sensors had run in the house for a week, were happy to learn that VOCs were not elevated in the house. The house did still smell bad though so we hired an environmental engineer to assess our home.

We did a little research and found a company out of Rochester, NY called Environmental Engineering that specializes in home environment remediation. They came out and set up a variety of sensors for VOCs and CO2 as well as took air samples to check for any mold or other biological incursions. A few weeks later we had a thorough report of our air quality and an hour long consultation with a remediation expert. Thankfully, there was nothing of immediate concern. During our call though, we inquired about a spike in radon that had showed up during our initial home inspection. The house passed the inspection but the spike seemed out of place. The environmental engineer leading the consult recommended we purchase a radon detector that we could leave in place for a few months to really gauge our exposure risk. That led to us putting an Air Things sensor into our basement.

We went with the Air Things Wave which measures radon as well as temperature, pressure, humidity, VOCs, and CO2. I was a little bummed to learn that we could not directly connect it to our home but nevertheless, we were able to export the measurements over time as a CSV file. It took a month before it would start to register radon (as per design) and we needed three months of measurements.

After the first month of measurements, we got our first radon reading and we were in the green and well under the 2.7 pCi/L level the EPA and WHO recommend. What we learned though, is that radon levels can vary pretty wildly. So we waited as we collected the three months of data needed to see where we really stood.

Data Types

Radon

The journey that resulted in this post really started with our concern for the levels of radon in our new old-home. While we waited for enough data to accumulate so we could make an informed decision about what next steps we should take, I collected and read several studies and papers published in reputable journals, the EPA, and the World Health Organization. I learned that radon is everywhere, which levels are dangerous, how is gets into our homes, and what remediation strategies are available. The short of it is, radon is the number two cause of lung cancer, second only to smoking. So knowing what radon levels are present in our home is definitely useful. While I knew our risk was likely low (based on the initial readings we were getting) I was eager to see what the full dataset would say.

Humidity

In addition to the radon, we had also taken an interest in humidity. Homes with basements, particularly older homes, can easily have environments above 60% sustained humidity which will lead to molds and mildew growth. Happily all our sensors were collecting this data as well.

Others

It should be obvious at this point that I was becoming interested in fully understanding our air quality. I was going down the rabbit hole.

Data Analysis

After more than three months of collecting data it was finally time to do some analysis. For this stage of the game I relied on my science degree and my computer programming skills. Since radon was our primary concern, I started to dive into those values first.

As you can see in the table below, we had collected almost 3,500 readings. We averaged 1.7 pCi/L over that period.

That max value of 5.65 had me a little nervous so I also took a look at a few selected quantiles.

From this, I am reading that max as a definite outlier. I’ll not worry too much about it since it is well below the 8 pCi/L value the WHO sets as their absolute max. (To be clear, they do say that anything above 4 is actionable though.)

I also wanted to know how the radon related to the other measurements I took. So I built a correlative heat map comparing all the values I had from just the Air Things sensor. You can see in the chart below that most things aren’t really related BUT there is something going on between humidity and radon.

Hmmmm…. interesting. I dove in a little deeper to the relationship between these two features.

It’s pretty clear in that last chart that radon and humidity are linked. Of course, humidity is not a source of radon (or vice-versa). But it is possible that they share a common cause.

After tracking the humidity, we decided to put in a dedicated dehumidifier for the basement and, as I write this, our unit is waiting downstairs for installation this coming Tuesday. I’m guessing that we’ll see the correlation between radon and humidity broken once the humidity is maintained at a steady 45%. I am curious if there are any knock-on effects that we’ll see in the radon but if so… I’m sure it won’t be large. My working theory is that the gaps in the foundation walls and flooring are letting both radon and excess moisture into the basement. We’re in the process of repairing those gaps now but it will be another few months before we’re finished. Once it's done, I’d expect the dehumidifier to run less frequently. And, I hope, the radon levels will stabilize and decrease. Of course, if they don’t we’ll likely install a radon abatement system for peace of mind. But in the meantime, I’m happy to have this data which gives us a clue about what’s happening with our environment.

Side Note

I also did a comparison of the three Eve humidity sensors just to see how each floor of the house related to one another. You can see just how closely the humidity levels on each floor compare in the two graphs below.

What’s Next

As I mentioned above, the dehumidifier is being installed this Tuesday. We also have a call out to Environmental Engineering to review the data and make a decision about radon abatement.

I’ll write a follow up entry in a couple months once we have some additional post dehumidifier installation. And possibly again after the radon abatement is in place.

Additional Info

For those who would like to dig into the analysis further, I've posted my Jupyter notebook on GitHub here: Air Quality Analysis

I Am Part of a Whole

As I was cleaning up some of my older files today and moving them off device, I wondered if I could use AI to build a manifest that I could keep on device in case I ever needed to find one of the folder files again. As someone who generates a lot of files, it's important I have good drive hygiene and I'm always looking to up my game.

Getting a list of the files into a document is easy. You can simply list a directory and redirect it into a file. On Mac this can be done with something like,

ls -lh >> myFiles.txt

It's very basic but it does create a simple file list that can be easily searched. Sometimes, with me anyway, the file name is not enough for me to recall what information a document contains. This is where I thought that bringing AI into the mix may help up my game.

After some minor fiddling, I came up with the following,

#!/bin/zsh

# Define the output file
output_file="output.md"

# Clear the output file if it exists
> "$output_file"

# Find all Markdown files recursively and process them one by one
find . -type f -name "*.md" -print0 | while IFS= read -r -d '' file; do

  # Run the temp command with the content of the current file
  result=$(cat "$file" | ollama run llama3 "Briefly summarize the text in this file. The summary should be no more than 3 sentences in length. Suppress any response that is not part of the summary. If the file is empty just respond with the phrase 'Empty File'")
  
  # Append the formatted output to the output file
  echo "---\n" >> "$output_file"
  echo "**${file}**" >> "$output_file"
  echo "\n" >> "$output_file"
  echo "$result" >> "$output_file"
done

In this case, the AI I am using is Ollama with the llama3.1:8b model. In my experimenting, this model provided decent summaries with the correct prompt. As you can see in the code block above, I give the model the following prompt.

“Briefly summarize the text in this file. The summary should be no more than 3 sentences in length. Suppress any response that is not part of the summary. If the file is empty just respond with the phrase 'Empty File'”

I've found that the llama3 model can be a bit chatty so I give it multiple guardrails to keep it on task. One: be brief. Two: limit the response to 3 sentences. Three: don't provide anything other than a summary. Four: if the file is empty, just say “Empty File” and move on. I will say that even with those guardrails, Ollama will still occasionally give some commentary, but it's knocked down enough that the output is useful and only requires some minor cleanup. In a future revision, I'll probably refine the prompt as well as provide some hinting so it has a format to follow.

As I see it now, this approach could be easily adapted to solve multiple problems and could be adapted to more sophisticated programming languages like Python to do even more. For now, though, I've scratched my itch and it's time to archive some files.