<output>; JWE; BygoneSSL

It has been a week. Last Friday, a new anomaly detection pipeline I’m building for $WORK caught wind of a very noisy, multi-day, bruteforce attack against all internet-facing Palo Alto Networks devices that continued through to today. The same attacker added a Fortinet device bruteforce to the mix this week. It has consumed most of my waking hours (partly due to a foolish & fruitless “Captain America” attempt to have providers help stop the attacks). That’s been unfortunately combined with a resurgence of whatever this non-covid/flu plague is.

Now that the attacks are abating (and I’m re-stocked up on symptom relievers), we’ve got time to sneak in a Friday Drop.

---

TL;DR

(This is an LLM/GPT-generated summary of today’s Drop using Qwen/Qwen3-8B-MLX-8bit with /no_think via MLX, a custom prompt, and a Zed custom task.)

• The <output> element in HTML is designed to represent results of calculations or client actions in forms and can only contain phrasing content, with examples and a showcase available at https://rud.is/drop/output.html
• The Journal of Web Engineering (JWE) aims to establish web development as a disciplined field, offering research and best practices for building high-quality web applications, with articles accessible at https://rud.is/drop/jwe.html
• BygoneSSL highlights the risk of inheriting old SSL certificates when registering a domain, demonstrating vulnerabilities through tools like CertGraph and the BygoneSSL scanner, available at https://insecure.design/

---

<output>

This post by Den Odell was a delightful find, especially since it is about an HTML element that was added to the HTML specification in W3C’s HTML 5 Working Draft 12 in February 2009. Before that, it was initially defined in Web Forms 2.0 and was referenced in HTML 5 but linked to that earlier specification.

Said element is <output>, and was designed to represent the result of calculations or client actions in forms, and has remained part of the HTML specification since then, eventually being included in the HTML5 recommendation (2014) and the current HTML Living Standard.

Den’s article is well-crafted, so I won’t steal any of that thunder with an attempt at a summary. Please hit that up before continuing, since the rest of this section is additive, but does require that context to make the most sense.

…taps fingers on desk…

Back? Great!

So, you cannot just stick anything in an <output> block. The specification notes it can only contain phrasing content. Said content is basically the text-level bits you’d use inside a paragraph—things like regular text, links, bold or italic text, images, buttons, and other inline elements. It’s what flows naturally in a sentence, as opposed to bigger structural elements like headings, divs, or lists that break up the flow of text.

The <output> element can be put inside a <form> but the specification is pretty clear that the contents of the block will never be sent to the server. I’m pretty sure it’s the only HTML form element that works this way, and it further makes me wonder why I’ve never seen it used in any examples until coming across Den’s post.

It further differs from other HTML form elements in that there is no value attribute (the “value” is what is wrapped in the tag), and that it is meant to be styled with CSS, meaning there’s no shadow DOM or other weird browser styling to fight against.

I took some of the concept examples from Den’s post and threw together a very vanilla showcase of how to use the element. If you’re a macOS user, you can fire that up in Safari and press Command (⌘) + F5 to turn VoiceOver on/off to hear it in action (on newer Macs with Touch ID you can also press Command (⌘) + Touch ID button three times to turn VoiceOver on/off).

---

JWE

Another recent find (due to someone sharing this with me) has been the Journal of Web Engineering, and I cannot believe I did not know about this publication before this week.

The JWE was created to address a growing problem: most web applications were being developed in ad hoc ways, leading to issues with maintainability, quality, and reliability. The journal launched in October 2002 to establish web development as a disciplined, systematic field rather than just informal coding.

Its purpose is to advance the scientific understanding of how to build web-based systems properly—applying rigorous, systematic approaches to creating high-quality web applications across everything from simple websites to complex systems like supply chains, financial platforms, and e-learning.

The journal recognizes that web engineering draws from computer science but also pulls in knowledge from information systems, business management, and other fields. It’s now published by River Publishers and provides a forum for researchers and practitioners to share advances in web development methods, frameworks, and best practices—essentially treating web applications as serious software artifacts that deserve the same engineering discipline as any other complex system.

Most folks today who produce web content or apps recognize that doing so is an engineering discipline, but all it takes is for one to remember traipsing through GeoCities to grok that wasn’t always the case.

It’s not a super popular destination, but I skimmed over a list of popular papers from it and felt it was worth creating a larger index of all articles up to this month. You can hit up that very basic web page or download the index JSON and use the scraper R code to refresh the index.

---

BygoneSSL

Imagine you obtain a domain name that someone else used to own. That’s a pretty common occurrence and seems fine on the surface. But there’s one small, potential problem: the previous owner might still have a valid SSL certificate that was issued when they owned the domain. And SSL certificates can last for years.

There are two fundamental reasons why this is Not Great™:

1. Person-in-the-Middle attacks: The old owner could intercept and spy on secure traffic to your new domain using their old certificate.
2. Denial-of-Service attacks: If that old certificate includes multiple domains (called “alt-names”), someone could get the whole certificate revoked. This would take down not just your site, but potentially other legitimate sites that are still using that shared certificate.

The Indecure Design/BygoneSSL site demonstrates this vulnerability by actually exploiting it! The creators registered insecure.design, obtained an SSL certificate, then transferred the domain to someone else while keeping the original certificate valid.

They also built some tools to help us find these vulnerable certificates in the wild, like CertGraph and the BygoneSSL scanner.

It’s not often that an important cybersecurity lesson can be wrapped in a small live demo, and this effort sheds light on something most folks don’t think about (since most of us aren’t trying to hack other people/sites).

---

FIN

Remember, you can follow and interact with the full text of The Daily Drop’s free posts on:

• 🐘 Mastodon via @dailydrop.hrbrmstr.dev@dailydrop.hrbrmstr.dev
• 🦋 Bluesky via https://bsky.app/profile/dailydrop.hrbrmstr.dev.web.brid.gy

☮️