Categories
Computers

IndieWeb

As the tech giants attempt to consolidate control of everything from logins, services and the way we communicate, small pockets of resistance have emerged. Tools like WordPress, Jekyll and other blogging platforms have long been the mainstay of online publishing. Allowing the common man to get a presence online. Now the task before us is to expand this pocket of freedom. Enter: IndieWeb.

IndieWeb is a series of tools and concepts designed to allow for the creative expansion, promotion and even the authentication of user content. These components allow you to build an ever growing spider’s web of content that all links together. This web provides ways for other users to see what you’ve posted, follow you in different locations and generally “authenticate” your work by providing links to and from it back to other content you control.

IndieWeb Authentication

Another method of controlling your stuff is signing in through your own identity provider. IDP is not a new concept. Services and protocols like OpenID, Kerberos, Shibboleth, LDAP, and Oauth have been around for a while. Many of these tools are either defunct, hard to setup and maintain, or are not really suited for web-based Single Sign On (sso). Enter IndieAuth.

IndieAuth allows for you to setup your own Oauth (kind of) setup that authenticates you against your own domain. For instance, if you use the WordPress IndieAuth plugin, you can use the built-in login tools in WordPress to log into other sites. You’ve probably already seen this in action with “Login with Google/Facebook/Github/Twitter/Microsoft/iCloud/etc”. The concept is the same, but now you control it.

Microformats

In part, all of this functionality works by implementing Microformats. These bits of information, invisibly embedded in the HTML of your site, provide extra information to other tools. Some of these tools will parse out your contact information, if provided. Others will parse out article information on your blog, or parse out connections to where the content has been posted elsewhere, like on LinkedIn or whatnot.

Like IndieAuth, Microformats are from days past. While they’ve evolved into a much more rich framework of properties, I was implementing them in the early 2000’s on Florida Coastal School of Law’s website.

Why I Don’t Use It

Excuse me? I’ve just gone on, gushing about how good the IndieWeb is and how we’re taking back the power from the man. What gives?

Simply put: I don’t need it. Most of my posts on social media are just short thoughts that don’t deserve blog level exposition. I don’t access any services that allow for IndieAuth logins, and honestly tearing apart twentytwenty to implement proper Microformats is enough to make me want to do actual productive work on something else.

I personally endorse the IndieWeb. It needs more people, more eyeballs and more implementations to succeed. The tools it has are well done, but could use some polish. Microformats, Semantic Linkbacks and other features are awesome and, if you’re up to it, not hard to simply add to your site (YMMV). If I were setting up a static site with one of those newfangled generators, I’d totally implement as much as I could. It’s easy. The problem for me is that I’m lazy, old and too pragmatic to break something that isn’t broken.

Categories
Computers

Broken Programming

I think something is wrong with me. I have, in the past, been an avid programmer. Programming was something I could do and it made me happy because I was able to affect change in the world, even at a small level. I spent many-a-year debating text editors, programming languages and generally being in it.

I don’t anymore. What I mean by that is that I don’t care for, or find programming fun or satisfying anymore. Even with this blog, I’m using the default twentytwenty theme with some modifications for color and other minor tweaks. I used to write my own themes and build my own components. I would labor endlessly over the smallest details, and tweak things until it was made “correct” in my eyes.

Now? Now I can’t be bothered to even open a text editor except out of novelty. I banged out a couple of lines of code that I modified from Kev for old posts, I dropped in some CSS to make it look okay and I was done. Opening a modern theme is like wading into a jungle of templates, CSS, JavaScript, Node.js, build systems and more. Even with IDEs like PHPStorm, I just can’t muster the energy to work on it.

I think I’m broken. Or at least I’ve broken my desire to code. I wonder if I wore it out, or if it’s a “young man’s game” and I’ve just past my prime. I don’t think that is the case, since I threw together a 500-line collection script for work that I was plenty interested in a week or two ago. No, I think my problem is it’s all so complicated now. The barrier to entry is high. Really high. You need to have gigabytes of compilers, build tools and linkers to just even bang out a “Hello World”. I feel like we’ve built this digital Tower of Babel and it’s looking a little creaky at this height.

Back in My Day!

The wonders that modern-day systems have brought is amazing. When I was a kid, using computers meant you knew something. It was a talent. Most people either did basic data entry on it or were programmers. Anything in between was hard to find. I guess that makes me an old man yelling at a cloud.

A screen grab from a Simpsons episode. A hand is holding a cut out from a news paper. On the clipping, a picture can be seen of an old man shaking his fist and yelling angrily at a cloud. The article is entitled "Old Man Yells at Cloud"
Back in my day, clouds were just clouds, not other people’s computers!

Maybe I should pick up C, or Python and kick around some simple programs. Get an idea for something and work on it until completion. A sort of hobby project. I’m fighting for time less with video games as of late, so I might be able to squeeze in something like that.

Categories
Computers

Content-Security-Policy

Inspired by a post made by Sheogorath from Shivering Isles (yes, that Sheogorath, from those Shivering Isles), I recently implemented a Content Security Policy on my site to help frustrate third-party tracking systems and reduce reliance on externally hosted tools. There are some exceptions to this policy, like ShortPixel’s CDN, or WordPress.org (w.org in this case) that I allow for better performance. The idea is that I can advise the browser to not allow connections outside this website (and the above exceptions), which means that there is less likelihood that a piece of malicious content could start sending data to someone else.

How I Implemented It

Previously, I implemented these rules with a WordPress plugin called “HTTP headers to improve web site security“. This long-named plugin allowed me to set various options for these security rules, all I had to do was provide them. One of the biggest issues I found with the tool was that it lacked a “Report URI” directive. This directive allows me to have the browser report a flagged piece of content on my site, which in turn allows me to fix or remove it.

Since I’m no stranger to PHP and plugin development, I downloaded a copy and cracked open PHPStorm to inspect it. I was not impressed.

While the plugin works, it’s a mess of spaghetti code and one-off statements that don’t make much sense. In this moment I briefly thought of cleaning this up and releasing my own plugin to improve upon this. That moment faded when I realized what I was actually looking to do. Add a single header to the request. This could be done much more simply.

Content Security Policy in functions.php

I had some changes to the TwentyTwenty theme that I wanted to port from the modifications I had made to the TwentyFifteen theme I was using prior. Namely the ‘old content’ banner. This was a perfect time to implement a child theme for TwentyTwenty and add my header information.

Once I added the bare-bones child configuration, and the old content banner, I set to work adding headers. Headers can be kind of tricky in PHP. If you add them ‘too late’ in the script, they can be missed as PHP tries to get all the content out to the user as fast as possible. That means if your headers are buried in some deep dark section of a theme… well, you’re likely to miss it.

Thankfully, WordPress has a ‘send_headers‘ hook that allows you to ensure that your modifications get sent to the user in a timely fashion. With all that said, here’s the final product:

function twentytwenty_child_csp() { header( "Content-Security-Policy: connect-src 'self';default-src 'none';font-src data: 'self';frame-src 'self'; img-src data: 'self' cdn.shortpixel.ai s.w.org; media-src data: 'self'; object-src data: 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; worker-src 'self'; base-uri; form-action 'self'; block-all-mixed-content; upgrade-insecure-requests; report-uri https://degruchy.report-uri.com/r/d/csp/enforce" ); } add_action( 'send_headers', 'twentytwenty_child_csp' );

Yes, that big mess of a CSP is a single line of data. Ugly, but that’s the spec. As you can see, I added a report URI to the end so I can keep tabs on anything suspicious.

Privacy Concerns?

The nice thing about Report-URI and CSP, no IP addresses or other information is logged. When I get a hit, this is what I see logged:

{ "csp-report": { "blocked-uri": "https://s.w.org/images/core/emoji/12.0.0-1/svg/1f600.svg", "document-uri": "https://degruchy.org/2006/03/", "original-policy": "connect-src 'self'; default-src 'none'; font-src data: 'self'; frame-src 'self'; img-src data: 'self' https://cdn.shortpixel.ai; media-src data: 'self'; object-src data: 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; worker-src 'self'; base-uri 'none'; form-action 'self'; block-all-mixed-content; upgrade-insecure-requests; report-uri https://degruchy.report-uri.com/r/d/csp/enforce", "violated-directive": "img-src" } }

Just the facts.

I honestly don’t like logging more than I have to. This is more of a security context thing, so I’ll allow it. Plus it’s up to the browser to actually take action on. All entirely voluntary.

Categories
Computers

ClassicPress

ClassicPress is a fork of the WordPress platform from version 4.9. Nominally designed to be a line in the sand regarding the new block editor known as “Gutenberg“. Clearly, some are not happy with the direction of WordPress, but how fervent they are remains to be seen.

I have been a long time WordPress user and administrator. I’ve seen it from it’s nascent betas, up to current. The block editor is the largest, most seismic change in the platform, and it’s way overdue. The old process of using the plain text box, or goodness forbid: TinyMCE.

ClassicPress, such as it is, wants to retain that editing framework while backporting security fixes and keeping as much plugin compatibility as possible. This is a noble endeavor, even if I disagree with the project, as it’s not easy to make this kind of sea change. That is, of course, if the project actually had any life to it.

Since it’s inception, they released a change.org petition that, after two years, has not managed to break 2000 signatures. Additionally, despite the low scores of the Gutenberg experimental branch plugin on WP.org, the team has stuck with it, building it into a much more powerful editor. Going so far as to begin looking at expanding it into full-site building functionality.

ClassicPress is Forking Disappointing

The reality is that Gutenberg, and blocks as a whole, are here to stay. Like it or leave it. Unless some technical hurdle is so insurmountable that the block editor is unable to be continued, it’s a settled argument.

When you fork a project like WordPress, you need to hit the ground running. Especially if you brand yourself “business focused”. You need to be backporting security fixes. You need to be moving forward. Right now, it seems the project is trying to just throw something together. It’s been three months since any substantive update.

Change is Hard

I get it. Change is hard. Especially one as large and disruptive as Gutenberg. However, instead of working through those changes, understanding things and getting used to the new normal. These people are just plugging their ears and screaming so they can try and ignore the future.

Categories
Computers

SEO Tomfoolery

Since starting this 100 days of offloading project, I’ve been monkeying around with my website much more often. To that end, I’ve enabled SEO tools (Yoast), Koko (Analytics) and ShortPixel (image optimization). These are all things that most website setup in some form or fashion. While I’m familiar with the latter two, the first one has been regarded by me as snake oil. I’m plan on testing that.

A Little History of Me and SEO

Some time in the distant past of 2008 to 2013, I was a webmaster. It was a great job and something I had wanted to do since I was in high school. I knew the components (PHP, HTML, CSS, JS…), but I had no experience with a lot of the rest. Most of this I learned on the job. The one sticking point was SEO. SEO stands for Search Engine Optimization. The primary aim is to use SEO techniques and technologies to be as search algorithm friendly as possible. The better your SEO, the more likely Google, DuckDuckGo and even Bing will find your content and rank it.

When I started my webmaster job, SEO was kind of a murky subject. You often had to pay for it, and often what you got was a bunch of keyword stuffing and other nefarious tactics. All of which would eventually back fire in the days and years leading up to my departure.

While working on my site, I had noticed and implemented some of the techniques that were being talked about under the banner of “Good SEO”. Many of these were already things I did:

  • Valid HTML/CSS
  • Content matches the URL
  • Lots of relevant data
  • Links to reputable sites, also with good information
    • rel="nofollow" to places you didn’t trust as much
  • Metadata and other meta information baked into the source code
  • Use the same page for both visitors and crawlers
  • Rightsize images
    • Accessibility features like alt text and more

None of this was rocket science. As someone who was passionate about HTML and CSS being valid and working smoothly, SEO was just part of what I did. I didn’t care about the more nebulous stuff like good writing. I wasn’t taking care of the content so much as shepherding it onto someone screen.

Marketing Takeover

Around 2010, the organization I was with had a large shift in the working/political landscape. More emphasis was placed on marketing and branding. These things were now more critical and things needed to be on point across all our outlets. Naturally, the website began to fall more and more under their control.

As an IT person, we tend to be pretty … weird with things we control. Sometimes, we could care less about an application or service, so long as it’s running, have it at. Sometimes, like a website, we’ve poured more than just sweat and time into it. We’ve crafted every brace and tag. The image carousel is bespoke JS, CSS and HTML. This is our baby. That was me.

I spent a fairly contentious few years allowing the nascent, bumbling marketing department in on the website decisions, crafting brand, color, messages. While I didn’t make those decisions by fiat before, I was now being directly ordered to make changes on what seemed like whims.

It was around this time we had an adjunct professor come in, get bored of being in her profession, switch to marketing and being a mommy blogger. She was… difficult to work with. She pushed for blogging instead of our tried and true CMS (Drupal) and wanted drastic changes to SEO and other tooling to fit with what she was doing outside in her personal blogosphere.

SEO vs SEO

Working with this person was also kind of instructive. Having not been a marketing person, I didn’t really understand the terms and usefulness of them. Sure, I could tell you what a CTR was, but I had never used it for anything. With the new blogging platform online, our marketing person jumped on adding plugins, themes and other tools. All the while, I was struggling to understand what the point was.

My SEO felt a lot different from hers. Her SEO felt like a gimmick or a game to win. Massage data and knobs to get it to be just the right recipe to make your rank go up. Mine felt like just making the site technically the best it could be, and let the ranking sort itself out.

Looking Back

I look back on that and realize that both approaches were kind of correct. The technical underpinning is very important. A slow or disorganized site will get pushed down the rankings. Similarly if a site has bad keywords, poorly formatted or written articles with poor link management, it will get the shaft, too.

Coming full circle, I’ve made the underlying architecture as good as I know how, now I get to be the one fiddling with the knobs and adjusting the formula. Fortunately, I know I can do it better and lighter and more efficiently than she ever did…

Here’s to better SEO in 2020!