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.
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).”
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.
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.
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.
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.
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)
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.