Why It’s Getting Harder to Trust the Software We Use

Every piece of software we use requires some degree of trust. Whether it’s a content management system, an office suite, or an operating system – each app we install is a small leap of faith.

We have to trust, for example, that it’s secure, respects our privacy, and works as expected. In other words: we need to believe that the developer has created an app with good intentions and that using it won’t result in any intentional harm.

That belief is tested daily. Security flaws, malicious attacks, and all manner of bugs pose huge challenges. And so much of an app’s reputation depends on how the developer responds to these crises.

But as we are seeing more frequently, trust isn’t solely dependent on an app’s primary developer. That responsibility also spreads to any third-party scripts and libraries their product utilizes.

One prime example is the Log4j vulnerability. A flaw in this popular logging library from Apache made it possible for an actor to arbitrarily run malicious code. Its effects could be devastating.

As if this weren’t bad enough, patching the vulnerability became incredibly complex due to how many other apps and service providers utilize Log4j. This meant that each app had to upgrade its copy of the library, then distribute the fix to users. The process has to repeat again and again.

For web designers, this hits home on several levels. We put our trust into many apps (particularly open-source). And many have third-party dependencies. It puts us and our clients at risk.

Let’s take a deeper look at the issue and what web designers can do to stay safe.

Open-Source Software Is of Special Concern

The saga of Log4j has opened up a proverbial can of worms regarding open-source software in particular. In the United States, the White House held a meeting with top tech firms regarding the security of widely-used foundational software that is maintained by volunteers.

Popular examples include WordPress, Node.js, React Native, and OpenSSL. Beyond that, Google has published a list of over 100,000 projects that are deemed “critical”. They’re relied on by everyone from governments, corporations, educational institutions – right down to personal and small business websites.

This does not mean that any of the items on the list are inherently insecure. Rather, it’s a measure of the potential impact a security flaw could have. As the OpenSSF Securing Critical Projects Working Group (WG) states:

“For our purposes, a critical OSS (open-source software) project is an OSS project that can have an especially large impact if it has a significant unintentional vulnerability, or if it is subverted in either its source repository or distribution package(s).”

Volunteers and Limited Resources

To state the obvious, security holes are not limited to open-source software. Big proprietary projects from the likes of Apple, Microsoft, and other behemoths of tech also have their fair share.

The difference is that these companies have the resources to ensure any issues, once discovered, are promptly fixed. Projects that rely on volunteers may not have such luxuries. Some may need to scramble to find someone knowledgeable who can take appropriate action in a timely manner.

And if a project is no longer maintained? It places a huge target on anyone using that software – whether they know it or not.

The beauty of these projects is that their volunteers are incredibly dedicated. We’ve often saluted those who work behind the scenes of WordPress, for example. The willingness of people to contribute their time and talents is a wonderful thing.

But as Morten Rand-Hendriksen points out, some major systemic issues need to be addressed:

“We are acting as if these are still little hobby projects we’re hacking away at in our parents basements. In reality, they are mission-critical, often at government levels, and what got us here is no longer sufficient to get us anywhere but chaos.”

It’s admirable that a group of people, no matter how small or far-flung, can build an app that makes an impact on the world. But there are no assurances that the project will be sustainable over the long term. That can be problematic.

What Can Web Designers Do?

As web designers, we are in an awkward position. So much of what we do these days relies on open-source projects. And we reap the benefits of them every day.

The good news is that none of the issues outlined above means we have to abandon open source – nor should we. There is too much value in simply turning our backs on our favorite projects. If enough of us did so, that would likely make the situation worse.

Instead, we should carefully consider the apps we are using. Gain an understanding of the project, who’s involved, and the challenges they face. Look at its reputation within the industry and its longevity. Examine its changelog and see how often updates are released. Consider volunteering your time if you are able.

It’s also important to look at which third-party dependencies are associated with a project. This can be difficult to discern, but worth the effort.

Then there’s the role of service providers such as web hosts and APIs. They are additional links in this chain. Because, even if we’re certain that an app we installed is safe, we also need to rely on these providers to maintain their systems as well. Monitor them as best you can and don’t be afraid to ask questions.

Placing blind trust in software is not a wise choice. And while it may feel nearly impossible to keep up with all of this, it’s now a necessary part of the job.

Truthfully, we won’t be able to catch every issue before it becomes something bigger. But we can keep an ear to the ground and be proactive about the software we’re using.

The post Why It’s Getting Harder to Trust the Software We Use appeared first on Speckyboy Design Magazine.

Request bodies in GET requests

12 years ago I asked on Stack Overflow: Are HTTP GET requests allowed to have request bodies?. This got a 2626 upvotes and a whopping 1.6 million views, so clearly it’s something lots of people are still curious about, and in some cases disagree with the accepted answer.

Because it keeps popping up in my Stack Overflow notifications (and I compulsively visit the site), the question has lived in my head rent-free. I keep adding context in my head, and I’ve been meaning to write some of this down for a few years now and hopefully evict it.

Anyway, if you’re just looking for a quick answer, it’s ‘No, you shouldn’t do this.’, you should probably use QUERY.

Undefined behavior

A number of people (most famously ElasticSearch) have gotten this wrong, but why? I think it’s because of this sentence in the HTTP Spec:

A payload within a GET request message has no defined semantics

That sentence could easily suggest that there’s no specific behavior associated to request bodies with GET requests, and that the behavior is left up to the implementor.

The reality is that this is more like Undefined behavior from languages like C/C++. My understanding is that leaving certain aspects of the C language undefined (instead of for example requiring an error to be thrown) leaves room for compiler implementations to make certain optimizations. Some compilers also have fun with this; GCC hilariously starts a video game in a specific case of undefined behavior which really brings home this point.

If you were to write a C program that relies on how a compiler dealt with specific undefined behavior, it means your program is no longer a portable C program, but it’s written in variant of C that only works on some compilers.

The same applies for HTTP as well. It’s true that undefined behavior means that you as a server developer can define it, but you are not an island!

When working with HTTP, there’s servers but also load balancers, proxies, browsers and other clients that all need to work together. The behavior isn’t just undefined server-side, a load balancer might choose to silently drop bodies or throw errors. There’s many real-world examples of this. fetch() for example will throw an error.

This hasn’t stopped people from doing this anyway. OpenAPI removed support for describing GET request bodies in version 3.0 (and DELETE, which has the same issue!), but was quitely added back in 3.1 to not prevent people from documenting their arguably broken APIs.

Why it’s not defined

The best source I have is this quote from Roy Fielding in 2007. Roy Fielding coined REST is and is one of the main authors of the HTTP/1.1 RFCs.

Yes. In other words, any HTTP request message is allowed to contain a message body, and thus must parse messages with that in mind. Server semantics for GET, however, are restricted such that a body, if any, has no semantic meaning to the request. The requirements on parsing are separate from the requirements on method semantics. So, yes, you can send a body with GET, and no, it is never useful to do so. This is part of the layered design of HTTP/1.1 that will become clear again once the spec is partitioned (work in progress).

….Roy

(His message was originally sent to the now-dead rest-discuss group on Yahoo Groups, but I found an archive in JSON format)

However, I always found this answer unsatisfying. I understand that you might want a low-level protocol design that just passes messages containing headers, bodies,

Truncated by Planet PHP, read more at the original (another 9288 bytes)

Weekly News for Designers № 628

Git Cheat Sheet (50 commands + Free PDF and poster) – This handy reference contains plenty of common Git commands spanning a variety of categories.

Spatial Web Browsing – A look at browsing apps that arrange objects in space to create groupings, indicate relationships, and build hierarchies.

Animate Anything Along an SVG Path – This tutorial will show you how to create animations using SVG paths and the getPointAtLength() function.

50 Free High-Resolution Photoshop Brushes for 2022 – Add these amazing brushes to your Photoshop toolkit.

Shapefest – Grab this library of 160k+ transparent PNG shapes.

Crafting Component Libraries: The Elements – Learn the process for crafting the foundational elements that make up a component library.

An Introduction to WordPress Block Themes – Block themes are set to become the future of WordPress. Here’s a look at how they compare and contrast with “classic” themes.

The breakpoints we tested in 2021, and the ones to test in 2022 – Choosing the right breakpoints for effective responsive design.

Hoosierland – FREE FONT – Get your copy of this free decorative font for use in your projects.

Why ‘Grumpy Designer’ Is the Only Title I Want – How to stop worrying about job titles and focus on what matters.

Frontend Predictions for 2022 – A look at some not-so-obvious trends for the new year.

Scenarios Where the WordPress Gutenberg Block Editor Replaces Custom Code – Why the need for custom code has been greatly reduced by the block editor.

DevToys – An offline Windows app that helps developers in daily tasks.

The Podcast Font – A collection of font icons geared towards podcasters.

10 Free Syntax Highlighter WordPress Plugins – Display and edit code beautifully with these handy plugins.

The post Weekly News for Designers № 628 appeared first on Speckyboy Design Magazine.

10 Free Plugins to Help Improve WordPress Content Creation

WordPress offers plenty of content creation capabilities out-of-the-box. The Gutenberg block editor is a big help when it comes to layouts, but still lacks some more advanced items. That’s where the vast library of available plugins comes to the rescue.

No matter what type of site you’re running, there’s bound to be a plugin to enhance your ability to add and edit content more powerfully. That results in content that fits your specific needs but doesn’t require you to jump through hoops.

Here’s a look at 10 free plugins that will help you create better and more complex content.

Pricing Tables WordPress Plugin – Easy Pricing Tables

If you’re selling products or services through your website, pricing tables are a must. However, they’re not a design feature that’s easily built in a default WordPress installation.

That’s where Easy Pricing Tables comes in handy. It’s built for the block editor and provides a visual UI for creating attractive, easy-to-read tables. A premium version adds more bells and whistles – including premade table themes.

Cool Timeline

Cool Timeline offers an interesting way to arrange a given set of posts. Turn them into an attractive timeline, complete with dates and featured images.

Colors can be tweaked to match your site’s look. Plus, the plugin works via both the block and classic editors.

Embed PDF Viewer

PDF files are a staple of the web. Yet, WordPress doesn’t offer dead-simple ways to embed or link to them. Embed PDF Viewer makes it easy, with a custom block built just for this purpose.

Even better is that it works with any valid PDF URL – whether it’s hosted directly on your website or not.

Visual Link Preview

Sometimes, standard text hyperlinks don’t provide enough context. Visual Link Preview offers a social-media-like means to preview links.

The plugin lets you create a custom link preview template that uses images and descriptive text. It’s perfect for showcasing affiliate links or other important resources.

Advanced Editor Tools (previously TinyMCE Advanced)

The WordPress Classic Editor uses an open-source software package called TinyMCE. Advanced Editor Tools is an all-around powerhouse – allowing you to add/remove/rearrange toolbar icons, utilize TinyMCE features that aren’t available in the standard WordPress install (like creating tables), along with some other advanced options.

It’s a great way to customize WP’s visual editor to fit the tasks you do the most. Even better is that it also enhances the Gutenberg block editor as well.

TablePress

If you need to create complex, feature-packed HTML tables, check out TablePress. Its editor is reminiscent of a spreadsheet, making the chore of adding or editing content simple.

You can even import data from several sources. Best of all, some JavaScript magic allows users to sort and filter tables.

Widget Content Blocks

The standard WordPress Text Widget is not so user-friendly. Replace it with Widget Content Blocks, which will let you create widgets with WYSIWYG – the same way you already create pages and posts.

A custom post type is added to WordPress, where you can create and edit “widget blocks.” Format text, add images – basically anything you can do with a page or post. When done, head over to the Appearance > Widgets screen to add your new widgets to a sidebar.

YouTube Embed Plugin

While you can already use WordPress oembed to add YouTube videos to your site, the YouTube Embed Plugin adds further capabilities. The plugin adds a visual search for YouTube videos, channels, and playlists.

You can then easily embed them into any page or post. There are also several useful features, like volume initialization, iOS playback settings, and HTTPS support.

Advanced Excerpt

A well-made post excerpt is now within your reach with Advanced Excerpt. You’ll be able to control the length of auto-generated excerpts, retain HTML formatting, and more.

HTML Editor Syntax Highlighter

Editing code in the WordPress text editor leaves a lot to be desired. Using HTML Editor Syntax Highlighter will result in a much better UI for code editing.

Code is highlighted, indented, and is a lot easier to browse than the default setup.

Make WordPress Work for You

The backend of a WordPress website should enable you to work the way you want. Instead of learning to deal with any shortcomings, it’s important to set up a work environment that requires as few workarounds as possible.

With the plugins mentioned above, you’ll have the power to make content creation more efficient and fun.

The post 10 Free Plugins to Help Improve WordPress Content Creation appeared first on Speckyboy Design Magazine.

PHP Internals News: Episode 97: Redacting Parameters

Truncated by Planet PHP, read more at the original (another 17418 bytes)