Skip to content


This is my microblog, containing short informal entries. See my blog for longer entries. An Atom feed contains the full text of all my notes. If that has any problems, I also have a legacy RSS feed.

Timestamp format: YYYY-MM-DD HH:MM, as per RFC 3339. Sorted newest to oldest.

  1. Posted

    I’d rather make a notice a <section> with a heading, or an <aside> if it’s not related to the surrounding content.

    You could even add a more specific ARIA (or DPUB-ARIA) role like role="note", role="doc-pullquote", role="doc-tip", etc. But don’t use them unless you have multiple kinds of aside elements and need to help people skim.

    Most of these roles actually map to the section superclass rather than the complementary role of aside, which isn’t always a problem: the aside element tells reader-mode implementations to remove the element, but the role tells assistive technologies more useful information. I use a similar hack for my in-page section permalinks.

    If the notice is important to the surrounding content and reader-mode shouldn’t remove it, use a section.

  2. Posted

    Currently, the Tor Browser is based on Firefox Extended Support Release (ESR); it lags behind stable releases by up to and only receives the subset of security backports deemed to be a high-enough priority.

    The Tor Uplift project is an initiative to upstream all the Tor Browser’s patches into Firefox. Its goal is to make re-basing the Tor browser patches easy enough for the Tor Browser to track Firefox’s stable release channel. The Tor Uplift has been in progress for , with several of the Tor Browser’s biggest modifications successfully upstreamed (first-party isolation, fingerprinting resistance, and more robust proxy support).

    On , Firefox 102 ESR was released. Today, on , Firefox 91 ESR will lose support. That gave a window of about three months (the duration of three Firefox stable releases) to re-base Tor Browser patches.

    The first stable release of the Tor Browser based on ESR 102 hasn’t yet shipped (it’s close; an alpha version is available). Seven years into the Tor uplift, the Tor Project isn’t able to keep up with the Firefox ESR release calendar. I don’t think the Tor Uplift will succeed at getting the Tor Browser to track Firefox’s stable channel; at best, it’s keeping the Tor Browser from falling too far behind ESR.

  3. Posted

    A “more sophisticated” scenario can consist of manually routing all the victim’s traffic to an external server. The attackers can also create fake networks or routers. In other words, it’s possible to act as a proxy under certain conditions without any knowledge from the victims who wouldn’t change their behavior, as nothing would look wrong.

    This attack allows intercepting cleartext communication. However, simply proxying traffic does not allow decryption.

    Decryption as you describe requires compromising the host OS, which would allow an attacker to do anything a user can. A compromised OS has no expectation of security, regardless of which measures you put in place.

    A better attack would be to add an additional CA to the OS and browser CA bundles. This would let an attacker add their own TLS certificates to sites without getting rejected by the browser. However, once again, this requires an attacker to compromise the host OS.

    The only convincing HTTPS-compromise mentioned is interception of an unencrypted initial connection before it’s upgraded to HTTPS; this is a valid concern for sites not on the HSTS-Preload lists or lacking HTTPS service-binding DNS records.

    A better argument would be that TLS doesn’t normally encrypt Server Name Indication (SNI) or obfuscate record sizes; SNI-sniffing or traffic analysis could reveal domain names or pages, respectively.

    I’d say that HTTPS combined with random record padding and Encrypted Client Hello (TLS 1.3 extensions) and a form of encrypted DNS (DoT, DoH, DoQ) can offer pretty good privacy protections against a MITM: the only reliable information leakage with these measures in place is at the IP layer. IP addresses are less specific than hostnames, since one IP can correspond to multiple hostnames.

  4. Posted

    microdata and rdfa both directly mark up existing html content.

    Only on a syntactical level. Beyond that, it’s the other way around: Microdata and RDFa let you build RDF triples by taking content from HTML elements. They don’t exist to add information to HTML elements.

    HTML and Microdata/RDFa syntaxes being mixed into the same document doesn’t change this. They’re only combined so human- and machine-readable data can remain identical without repetition, not to create more linked-data than the sum of its parts. You could re-write the very same RDFa data in e.g. Turtle syntax, with the HTML discarded. That’s why I wasn’t particularly fond of the (rejected) Microdata/RDFa approach to WAI-Adapt. (I think this was one of the major criticism raised, but I can’t seem to find it)

    An @id in JSON-LD takes information from, rather than adding information to, the HTML document; HTML-parsing user-agents should ignore it unless they’re extracting RDF data from Microdata/RDFa.

    there’s also itemid…the page can define multiple different resources on it, give a uri to the different bits of content on it.

    itemid is just a way to refer to add to another object instead of creating a new one. Again, it’s a way to extract information from different parts of an HTML document (or different HTML documents altogether) rather than a way to add to HTML elements.

    Microformats sometimes use HTML itself rather than extracting data from it (see the e- prefix). This puts microformats in a sort of gray area, extracting data from HTML but also integrating with it.

    I make extensive use of Microdata and microformats on Strictly speaking, both syntaxes are made of HTML; however, I’ve certainly found the microformats approach to feel more “HTML-native” than Microdata.

  5. Posted , updated

    I noticed that the Comparison of ways to use vocabulary in content page on the personalization-semantics wiki didn’t mention Microformats. Microformats add semantic meaning to individual HTML elements; this is in contrast to document-level semantic formats like Microdata, RDFa, and JSON-LD.

    There’s a 1-1 mapping between many microformats and values in the WAI-Adapt Content Module. Several values under section 4.3.4 (values for “purpose”) are already specified in h-card microformats2, for instance. You can find plenty of live h-card implementations on the IndieWeb Webring directory.

    w3c/coga Issue 69 also references overlap between “destination” vocabulary and rel values. Microformats leverage rel attributes like rel="license" and rel="home"; these seem equivalent to the “terms” and “home” values for destination attributes.

    I propose the addition of microformats2 to the comparison wiki page, and would support either merging the content module with microformats or specifying a mapping for fallback.

    Syndicated to the GitHub w3c/adapt bug tracker and

  6. Posted

    I have mixed feelings about infographics that reduce ecological footprints to single scalar non-fungible values.

    Infographics like these should have a second metric for “average rainfall in areas producing required ingredients”, since water isn’t fungible. Chocolate wouldn’t look as bad then.

    And a third metric for fuel required to import the food and ingredients during production. Chocolate would look bad again, since it’s typically produced far away from where cacao grows. Maybe this should be generated based on a viewer’s approximate location, to better account for shipping.

    Also, this infographic ignores serving size by measuring the same mass of all these different foods. I’m not sure who buys equal masses of chocolate and rice.

    (Original infographic source)

  7. Posted , updated

    First off, some of your comments have referred to ad-blocking being wrong due to conflict with existing business models.

    Businesses are not entitled to the success of their business models. If a business model fails due to consumer behavior, the business was in the wrong for expecting different behavior.

    I would be fine with ad blockers that only blocked ads, as long as publishers could chose to refuse service to users running ad blockers or ask them to turn their ad blocker off.

    Distracting content (most ads), color schemes with bad contrast, bright images on dark pages, etc. are accessibility hazards (particularly cognitive accessibility hazards). Restricting the use of page-alteration software (e.g. color and font alteration, disabling images, and blocking frames) is therefore a discriminatory practice.

    In a sibling subthread:

    The part of your analogy where you say people who want burgers don’t have any other choice seems not to fit: you can eat other foods which don’t have this requirement, just like there are lots of places on the internet where you can exchange money for ad-free content.

    The default behavior on the Web is one in which user-agents set their terms, and websites must agree to them.

    The libertarian perspective is a two-way street. Nobody is forcing a person to publish content on the Web. If the “comply with the user’s wishes” model of the Web is problematic to a content creator, they don’t need to participate in the Web.

  8. Posted

    I generally recommend Caddy over Nginx, but Nginx does still have certain advantages:

    • Nginx supports OpenSSL commands that enable features like TLS record padding.

    • Performance: better latency and scalability to more connections. Not everyone uses a CDN for static/cached content

    • Kernel-accelerated TLS offload on Linux and FreeBSD

    • Many existing modules provide unique functionality. The many modules for live video streaming and image processing are good examples.

    • An ecosystem of patches with features like HPACK static dictionaries, dynamic TLS record sizing, etce

    …has terrible language integration.

    Generally, “language integration” isn’t really a use-case for vanilla Nginx; it’s a use-case for Nginx Unit, an Nginx language-specific module, or OpenResty. I personally prefer the reverse-proxy route since it lets me use whatever language I want regardless of server support: Go, Rust, Python, C, etc.

    If none of these are that important then I absolutely would not recommend Nginx; Caddy would be the better tool.

    People aren’t writing internet scale software in lua for a reason.

    I’d include, much of Taobao, and some of the most popular API gateways (including Kong) in the category of “Internet-scale software written by ‘people’”.

  9. Posted

    You can run TLS 1.2 and 1.3 on plenty of 90s-era setups. A typical Gemini page is small, so you might have to blink twice while ChaCha-POLY1305 does its thing. TLS might exclude retro servers, but not clients.

    If Gemini had these changes, I’d be happy:

    • Use something better than TOFU-based TLS for transit encryption (Tor, Yggdrasil, DANE-based-TLS, etc.)

    • If using TLS: use a small subset of TLS 1.3. Maybe just stick to ECDSA + ChaCha-POLY1305.

    • Drop ASCII art: overloading programming-language indicators and ASCII-art alt-text is an accessibility hazard

    • Add some sort of “download finished without aborting early” indicator (e.g. something like Content-Length)

    • Add some way to reliably work with a larger page, e.g. using compression or range-requests with pagination. My full-text Atom feed is almost 1 mb uncompressed, but under 200 kb with Brotli compression. Downloading a full-text export of my Gemini capsule without a content-length header or compression sounds bad.

    The main thing I like about Gemtext is links on their own lines. This gets people to use longer/descriptive link text and also makes them serve as navigational aids better than their HTML counterparts.

    Honestly, I’m less interested in the technology than the community. Gemini Space is a comfy change of pace.

  10. Posted

    Whether or not increasing a user’s fingerprint (potentially crossing the uniquely-identifiable threshold) is “worth it” is something for the user to decide, not a webmaster. Studies need the consent of all subjects involved, even if researchers believe that it’s in the subjects’ best interests. Users can make informed consent after being informed of the scope of telemetry, how it will be used, and how it will be shared.

    A user (like me) who visits a website one time probably doesn’t care if the website “improves their experience” if they don’t intend to re-visit it. They probably wouldn’t consider “collect and share information about your setup, in exchange for a better site in the future” a fair trade. From the perspective of a one-time user, the Reporting API serves only to fingerprint.

  11. Posted

    On Windows, NVDA is more capable but Narrator + Edge is more secure. Narrator and Edge were designed to work without giving Narrator access to the content process, using the UI Automation API (UIA). Edge’s UIA was merged into upstream Chromium but it was only enabled in Edge. Matt Campbell wrote about it on the orange site in January 2021; I don’t know if the situation has changed since then.

    Try both. If Narrator works for you I’d stick to that. My main issue isn’t the lack of functionality, but the speech synthesizer delays (when it starts reading, the first words get dropped).

    Mobile screen readers (Android TalkBack, iOS VoiceOver, KaiOS Readout) are more beginner-friendly but also much more limited.

  12. Posted

    Client-side storage (cookies, cache, etc.) is one of many things worth disabling during site testing. The Tor Browser’s “safest” level blocks SVG, remote fonts, JS, and other features; many textual browsers don’t support anything besides a subset of (X)HTML. Most non-mainstream search engines are similar.

    Personally, I try to keep sites curlable. It should be possible to use a plain curl URL command to get all the necessary markup, complete with visible contents. If the main content of the page is text, then everything else should be a progressive enhancement.

  13. Posted

    Since these are being boosted again, I wanted to say that my views have changed. I do not recommend most people learn Vim (well, sysadmins should know basic insert, write, quit, and undo).

    I think that modal editing is a niche. It’s fine for people like me: I can barely keep a train of thought going and I constantly forget what I was thinking (It’s a huge problem I have and I didn’t realize this until recently; it’s why I constantly need to write things down). For people like me, time is not fungible and spending a long time learning something non-intuitive just to save a few milliseconds later makes sense, since failure to get an idea down ASAP could kill the idea.

    For most people, @zensaiyuki was right. Modality should not be a tool we reach for outside of specialized circumstances. It has its place but it’s overrated.

  14. Posted

    I added a section on supporting older browsers to my web best practices article.

    I explain why old browsers are more prevalent than we think, and how to most easily support them.

    I think the simplest way to do this well is to subset modern standards, not to explicitly use older standards. That is: we should target the subset of the HTML Living Standard that appears in e.g. HTML 5.1, so we get the important corrections in the Living Standard while still having a slower-moving target. Recent additions are totally fine if they’re strictly-optional, progressive enhancements.

    I think requiring a modern TLS cipher suite is fine (TLS 1.3 and the secure subset of TLS 1.2), since even 90s-era hardware can do TLS 1.3’s ChaCha20-Poly1305 well enough. My personal rule of thumb is that if I support computers older than I am (22+ years old), I’m not contributing to planned obsolescence and consumerism in the hardware market.

    I find a lot of overlap between supporting non-mainstream engines and supporting older browsers. Both benefit from ignoring new additions to the HTML Living Standard unrelated to accessibility, security, and performance. Catching up with a moving target is hard.

  15. Posted

    Interaction between the Document-Policy *-images-max-bpp directive and a user-agent’s supported image formats is currently unspecified.

    Next-gen image formats of the present and future include WebP, AVIF, JPEG-XL, and WebP2. With every new format, new compression ratios become possible; however, cross-browser support is inconsistent. That means possible compression ratios also vary by browser. Fewer supported image formats should allow a less aggressive compression ratio in the Document Policy. Unfortunately, browsers’ Accept request headers don’t always report supported image formats, so servers can’t easily compute the best policy for a given browser.

    Specifying a per-mimetype compression ratio isn’t ideal. Sometimes a PNG can beat AVIF or come close enough to not justify the extra bytes of a <picture> element. On a browser with AVIF and PNG support, loaded PNGs should be held to AVIF-level compression expectations.

    I think the most robust solution would be to offer multiple image-compression policies to a browser; the browser can then pick the policy that matches its supported image formats. For instance: a server could offer a max-bpp-supports-webp, max-bpp-supports-webp-avif, max-bpp-supports-webp-avif-jxl, etc. Unfortunately, this is really wordy and will only grow more complex as browsers adopt new image formats.

    TLDR: in a web where supported image formats can vary, it’s unclear how *-images-max-bpp and a UA’s supported image formats should interact. This variance warrants a policy more complex than a single global value.

  16. Posted

    The Web is not built around advance informed consent; there’s no agreement to terms before downloading a public file (besides basic protocol negotiations). This is one reason why “by using this site, you agree to our cookies, privacy policy, kidney harvesting, etc” notices won’t fly under the GDPR.

    A website admin can’t set terms for downloading a linked document; the user-agent just makes a request and the server works with that data to deny or accept it. There’s no obligation for the UA to be honest or accurate.

    Ultimately, nobody is forcing you to run a Web server; however, plenty of people have to use the Web. Respect for the UA is part of the agreement you make when joining a UA-centric network.

    Should you disagree with the precedent set by the HTML Living Standard, nearly every Web Accessibility Initiative standard (users must be able to override and replace stylesheets, colors, distracting elements), the exceptions to e.g. the Content Security Policy in Webappsec standards to allow UA-initiated script injection, etc.: you’re always free to build your own alternative to the Web with your own server-centric standards.

  17. Posted , updated

    Many people are worried about Amazon Web Services and especially Cloudflare centralizing the Web. I generally share their concerns, with one exception.

    Hot take: it’s fine to use a “Big Tech” provider as a name server, provided you can handle the 24-hour delay involved in a migration. Of all things, using a name server doesn’t have nearly the same the drawbacks as other types of centralization. It’s super easy to migrate, and DNSSEC keep name servers honest. There are more important things to worry about.

    I’ll switch to Cloudflare just for DNS, because it’s one of the only providers that supports DNSSEC and the new HTTPS records. The latter will be useful once a web server finally gains Encrypted Client Hello support; I’m watching Nginx, OpenLiteSpeed, H2O, redbean, and Caddy.

    Update: I switched my name servers from Cloudflare to deSEC.

  18. Posted , updated

    Web development fuzzes browsers and developer tools with the side-effect of occasionally producing decent Web content. My site has broken enough things to give me plenty of bugs to file, or cause others to file on my behalf. Despite all the fuss I make about maintaining compatibility, I do make exceptions for simple fixable bugs and broken developer tools.

    My strict Content Security Policy (CSP) has broken various developer tools (Axe, Lighthouse), Brave’s Reader Mode (allowing styles with a CSP hash blocks reader-mode CSS), WebKit media controls (I relax the CSP on the affected page), Chromium DevTools’ console, and various parts of Epiphany. Recent directives like navigate-to and webrtc were unsupported by Google’s CSP evaluator (and by proxy, Lighthouse) until I pushed a trivial fix.

    Recent features like CSS containment, media attributes in <meta name="theme-color"> elements, the @supports selector() CSS at-rule, and prefers-contrast: less expose several false positives in the W3C’s CSS and Nu HTML validators; I fixed a couple of the simpler issues.

    My use of <source media=...> children of <picture> elements for alternate images on print/screen media types doesn’t get picked up by Chromium’s print-preview.

    My use of DPUB-ARIA triggers false-positives in accessibility tools such as AInspector and ARC Toolkit.

    There are billions of websites; some of these issues should have been discovered long ago. If you have a few minutes to spare: please, file detailed bug reports when something breaks! It’s better to let developers know sooner than later; most bugs get harder to fix with time.

  19. Posted

    There’s always the possibility of including SerenityOS data in the MDN BCD tables, but not displaying it on MDN just yet. This could give other projects a chance to use these tables for their own purposes. I think a lack of information on feature compatibility is one of the things holding back website compatibility with non-mainstream engines.

    Non-mainstream engines are in a bit of a “catch-22” situation: enthusiast developers don’t support them because there’s not enough compatibility info; users stick with mainstream engines due to better compatibility; and other developers don’t support alternative engines because nobody uses them. Introducing some docs won’t break this cycle, but it could disrupt the cycle ever so slightly.

    I would love to see feature comparisons of alternative engines (SerenityOS LibWeb, NetSurf, litehtml, Flow Browser, Servo, et. al.). Maybe including just one alternative engine could be a step in that direction, and the SerenityOS browser looks like the most active of the bunch.

  20. Posted

    I’ve used many textual browsers, but I’m interested in more hardened options. Browsers parse untrusted content from the Internet but no textual browsers employ sandboxing, continuous fuzzing, or other security measures. Check CVEs for Lynx or w3m and you’ll see what I mean.

    I’m also looking at alternatives to my w3m-sandbox script to show HTML emails. Pandoc with commonmark-raw_html output is an option; Haskell seems like a better choice than un-fuzzed C for this. I’d like a more battle-hardened library for networking, like libcurl (used in Edbrowse).

    I considered Offpunk, which uses Readability to extract articles. I’d rather pipe rdrview output to w3m-sandbox. rdrview does some sandboxing, and sanitizes input to a subset of HTML.

  21. Posted

    This is a great post to illustrate the utility of detailed alt-text when an image is the primary content. I think it’s less relevant for the more common use of images: as illustrative examples or supplements to surrounding text.

    Take an image embedded in an article. Sighted users are capable of viewing a detailed image and instantly filtering for the information that’s relevant to the surrounding content. It’s harder to do this with a blurb of text, so this situation would call for more a more brief description.

    The opposite extreme: the most detailed textual alternatives I work with are image transcripts (e.g. for comics). Flat text is a poor fit; semantic HTML works better. I’m hoping aria-details gains traction in the future and settling for short alt + long aria-describedby text in the meantime.

  22. Posted

    One thing this article misses is the fact that webpages are delivered over the Web to Web browsers.

    The vast majority of browsers are application runtime environments. Serving pages to users’ browsers creates a software distribution platform. Serving pages in cleartext is a way to give permission to users’ ISPs, network administrators, and governments to serve their malware instead, under your name, whether or not your page includes any scripts of your own.

    People can’t always choose their networks, service providers, or governments. They aren’t always equipped to deal with content injection and page alteration.

    This isn’t a “fear-based tactic”. It’s an acknowledgement of our reality: networks are hostile. There are no robust measures to stop an intermediary from altering unencrypted traffic, yet there are strong incentives for all able parties to do so. That makes malware injection a perfectly reasonable concern. Moreover: multiple ISPs, including Comcast and Vodafone, have been caught injecting JavaScript apps into unencrypted pages. Governments are no stranger to content injection either.

    If you want to serve in cleartext, pick a protocol that’s not part of an application delivery platform. Gopher is a popular option.

  23. Posted

    Search engine indexes like Google, Yandex, and Bing now favor mobile-friendly sites. This has encouraged many sites to invest in mobile-friendliness. If we overlook toxic developments like Google AMP and Yandex Turbo pages, this is an example of search engines creating incentives to improve the state of the Web. Smaller indexes like Teclis and Marginalia create different incentives: they penalize tracking and toxic forms of SEO.

    I wonder how this could apply to accessibility. Currently, Google rewards the use of alt-text and penalizes small text, small tap-targets, bad link text, and missing language metadata. Rewarding alt-text has created perverse incentives to be overly descriptive, but on the whole these incentives have been helpful. Can we do better?

    For starters: on searches with many results, search engines could stick to keywords that show up in both the DOM and significant landmarks of the accessible tree. They could gently penalize easily-detectable accessibility issues such as missing labels, landmarks, or heading-levels. Search engines that use these heuristics should develop or endorse tools to detect issues using the same logic. Automated tools only detect a tiny fraction of issues; saying “we plan to roll out more accessibility checks in the future” could get people to do more than merely meet current checks.

    I also think it’s worth exposing some metadata in search results to describe fixable issues. Something as simple as “This result has detectable accessibility issues: missing landmarks” with a “more info” link could go a long way.

  24. Posted

    For personal reasons, I am stepping away from or reducing my involvement in some communities to better focus on other things. You will likely hear from me less.

    My site will probably update less frequently too. Some timed posts may fire, but I won’t be actively writing much. I most likely won’t POSSE those timed posts.

    I’ll probably be back eventually, but not for a while.

  25. Posted

    IMO: the main benefit of DNS-over-HTTPS (DoH) is that it’s a stepping stone to Oblivious DNS over HTTPS (RFC 9230).

    i distrust how much more this encourages centralization

    I don’t see how it’s more centralized than DNS-over-TLS (DoT). On the client side, QUIC is already present on just about every Android phone.

    On the server side: I don’t think this update forces you to use any given provider, nor does it remove DoT. The default provider is whatever your phone vendor puts in (otherwise the default is Google DNS, just like before). They’re even adding DDR so you can switch to DoT if your preferred resolver doesn’t support DoH.

  26. Posted

    Imagine asking a team of human auditors and disabled users to list all the accessibility issues they notice on a site. These people may list some WCAG failures, but might also list unique accessibility issues that aren’t documented anywhere. They may phrase a single issue in a way that could cover a number of more specific issues (e.g. “this font makes my head hurt”).

    Then, run an automated scan on the same site. Combine the valid automated reported issues with the humans’ reported issues. What percentage of this total could be addressed by the automated scan?

    Repeat the exercise for a sample of sites, throw out the outliers, and average out the percentage. That’s what “our tool catches X% of issues” could mean.

    Now, I don’t think most tools literally follow the process I described. I just described this example to illustrate the broader point that you don’t need a “global list of issues” documented somewhere to make such a claim.

  27. Posted

    I think h-feed and h-entry should be implemented manually by Hugo theme and/or site authors. Microformats add class names to a page, but someone still has to design a page. There’s way more diversity in h-feed design than RSS, Atom, or JSON-feed design because h-feeds are webpages meant for humans first, machines second. Providing built-in h-feed templates would be akin to providing a default incomplete theme.

    That being said, I could imagine other microformats getting shortcodes and templates. A shortcode and/or partial for h-cite, h-card, etc. could work. I’ve made a few microformats shortcodes and could upstream simplified versions if there is sufficient interest.

  28. Posted

    They are like workers that are hired.

    Laws around “works for hire” come with their own copyright baggage that assumes workers are actual people; for instance, these laws include mechanisms by which workers can claim copyright themselves.

    I’m not opposed to the general principle of training a model on copyrighted works potentially being fair use; however, the generated works would need to be sufficiently novel or seemingly “creative” by human standards for it to work. Otherwise, you’re in “derived work” territory. This, I think, is a major difference between the likes of DALL-E and Midjourney, and the likes of Copilot.

    I personally found all the discourse way too hilarious, and wrote a satirical article on it only to get clobbered by Poe’s Law: An experiment to test GitHub Copilot’s legality.

  29. Posted

    I always like having at least two ways to visually express meaning:

    • Code blocks should have a change in font, and have a border.
    • Description lists should have a hanging indent, and have bold described-terms.
    • Hyperlinks should have color, and an underline.

    For sentences: punctuation, and capitalization. It also makes initialisms less likely to be confused with the end of a sentence, e.g. this one.

  30. Posted

    IMHO, your implementation seems just right.

    Thanks! I based my approach off of Amber Wilson’s section permalinks

    One key difference: I wanted CSS to be an optional cosmetic enhancement, and not something that changes the content that people see (except for print media). I want my markup to only define structure/semantics, when possible (i.e. ideally no cosmetic div wrappers). That meant displaying the section permalink as a readable link. I used aria-labelledby to give each section permalink a unique accessible name.

    I’ve heard positive feedback from both screen-reader and textual-browser users.

    As for how this relates to reading mode implementations:

    The point of reading-mode tools is to reduce clutter and focus on reading an article, without the author’s supplied user-interface. Section permalinks feel like a part of a “user interface” and should be removed; the interface should only be provided by the reading-mode. On the other hand, most reading modes don’t provide a document outline or a way to get a link to the current section, and users might want that functionality without having to leave reading-mode. On a third hand: if I include section permalinks in reading mode, then it’d end up looking almost identical to the un-distilled page. That’d make reading mode almost useless.

  31. Posted , updated

    In the past couple of years, Firefox made significant security-related progress.

    Firefox’s multi-process architecture was overhauled, starting with a utility process overhaul. This has improved privilege separation by moving networking, audio, and other ancillary functions to a separate process. They also enable Arbitrary Code Guard (ACG) for the utility process on Windows, and plan to do something similar on macOS. They don’t (yet) emulate ACG on Linux.

    They’ve rolled out a separate GPU process on some platforms; the roll-out will likely finish this year.

    Regarding toolchain hardening: Chromium official builds use Clang’s CFI sanitizer; Firefox doesn’t. However, a subset of Firefox’s libraries support RLBox sandboxing. This isn’t a complete solution, but is still a welcome change. The Tor Browser disables libgraphite on the “safer” security level due to security concerns which RLBox may have addressed.

    I’m looking forward to seeing PID namespace isolation at some point.

    Regarding JIT-related exploit mitigations, Firefox is still quite far behind; I recommend Firefox users to disable JIT in about:config (see note 25 of Best practices for inclusive textual websites). This is partly related to malloc differences: JavaScriptCore has a malloc with a virtual memory cage, and V8 is currently working on one. As long as Firefox users are better served by disabling JIT: I’d like to see ACG enabled in the JIT-less content process (Chromium does this), and emulated on Linux (Edge does this, and so did Hexavalent).

  32. Posted

    I think that using a dedicated air-gapped machine just for opening PDFs is a bit much if you don’t rely on assistive technologies to read PDFs. A much less nuclear option: Qubes OS has an excellent PDF converter to convert PDFs to safe bitmaps, and back into PDFs. The results are completely inaccessible, so I wouldn’t recommend sharing the final artifacts; however, this approach is fine for personal use.

    The Qubes blog covers this in more detail: , by

    SaaS can actually be helpful when it comes to processing potentially-malicious files. In high school, we had to make heavy use of Google Drive. One approach that I used to use was to open a PDF with Google Docs and export the resulting Google Doc.

  33. Posted

    Most of these are pages that blur the line between “document” and “app”, containing many interactive controls. Being concerned about them is valid; however, I think the concern is misplaced at this stage.

    For an independent engine, I’m more interested in simple “web documents”. Those need to work well before tackling “Web 2.0” territory. Specifically: articles progressively enhanced with images, stylesheets, and maybe a script or two. Understanding how well Web 2.0 sites render isn’t really useful to me without first understanding how well documents render.

    When testing my site, my main pain points are: a lack of support for <details>, misplaced <figcaption> elements, my SVG profile photo not rendering (it renders when I open it in a new tab), and occasional overlapping text. The only non-mainstream independent engine I know of that supports <details> is Servo.

  34. Posted

    I just rolled out breadcrumbs for my website. Now, any page that is not linked directly from the navbar or site footer will have a breadcrumb list in its header. The breadcrumb list shows how to reach the page, starting from a navbar link. The first item is the navbar or footer link; the second link is the current page.

    I made this change because simply emphasizing a navigation link with <strong> isn’t enough to convey the current section to assistive technologies. With this change, I’ve done more than the bare minimum to meet WCAG 2.2 SC 2.4.8: Location.

    With the presence of breadcrumbs, there are now more navigation-related links before the main content. Before, adding a skip-link would have saved a user five keystrokes; now, it could save a user seven. I’ll probably add a skip-link next.

  35. Posted

    Are you referring to making an OpenSSL-compatible API, so OpenSSL-only programs can link against BearSSL?

    I really like BearSSL for TLS 1.2: it’s tiny, runs well on old hardware, and has no dynamic memory allocation. I do have serious doubts for making it the default TLS library when it doesn’t support TLS 1.3. Looking at commit logs, I doubt it’ll get 1.3 anytime soon.

    mbedTLS, LibreSSL, WolfSSL, s2n-tls, MatrixSSL, GnuTLS (eww), BoringSSL, picotls, NSS, even Fizz and Rustls (just including these two for completeness) all support 1.3 and can be linked in C programs; picking the one high-profile implementation lacking it seems like a bad idea. Perhaps wrapping BearSSL and a TLS 1.3 implementation (like picotls) could work?

    Personally, I’d like to see adoption of more 1.3 extensions to reduce information leakage, such as Encrypted Client Hello or random padding.

  36. Posted

    This feedback has been helpful for me too; I incorporated the discussion around the Helmholtz–Kohlrausch effect into the “contrast is complex” section of my web best practices article.

    I think the Helmholtz-Kohlrausch effect also ties into my concerns regarding overstimulation, also described in the same section of that article. Over-saturation of perceptually “light” colors that also look like “warning” colors (e.g. yellow, which contains the perceptually-bright green along with red) can be psychologically stressful.

    I’m beginning to think that a single scalar value might not be the best way to represent all these different axes. Designers should try to strike different balances between different sets of values, depending on responses to media queries.

    On the other hand, the “default” values should still try to “even-out” potential harms and conform to existing norms, because fingerprinting-averse users (and users who just need to borrow someone else’s un-personalized machine) should still receive some accommodation.

  37. Posted

    I won’t pretend that the Sourcehut accessibility situation ideal, but it’s usable for the most part with assistive technologies IME. From what I can tell, it doesn’t have critical issues like hidden/un-focusable items, interactive widgets that don’t change states, keyboard traps, etc. The only other forge that generally passes that is GitHub.

    Core functionality all works, but ancillary functionality and quality-of-life could use some significant improvements. I’ll file some tickets later today; they’re generally easy to fix. Some that come to mind are using additional <nav> elements with different labels, and naming in-page heading anchors.

    Edit: just saw your thread on Sourcehut accessiblity, I’ll take a look.

  38. Posted

    Balancing the needs of many users is hard. The gift of having a quirky setup is it improves inclusivity by default. In addition to using mainstream browsers with and without screen readers, I browse through other means: I often read by piping Readability output (using rdrview) through a textual browser, using non-mainstream browser engines (e.g. NetSurf), using a textual feed reader with a bespoke markup renderer (Newsboat), and using the Tor Browser’s “safest” mode.

    Simply getting my content to work for me will automatically make it work for a wide range of audiences. Of course, this alone isn’t enough; there are others still excluded that I need to account for.

    Web devs: make your setup weird. It encourages you to make your site robust, less dependent on a narrow range of implementation quirks or poorly-followed standards.

  39. Posted

    I might drop GitHub mirrors for new projects, but I worry that this could disproportionately cause friction among disabled users.

    The main reason I currently mirror to GitHub is accessibility. The only other forge I know of that’s usable with assistive technologies is Sourcehut, my primary forge. Many feel uncomfortable with Sourcehut’s style of contribution and the other FOSS forges are severely lacking, so that leaves GitHub.

    GitLab requires JavaScript for basic functionality, which itself is a little problematic from a FOSS perspective and very problematic from a privacy perspective: there’s a reason why the Tor Browser disables JavaScript on its “Safest” mode.

    the GitLab Enterprise Edition, which is provided to the public on, is (like GitHub) trade-secret, proprietary, vendor-lock-in software

    I agree with this statement except for the “trade-secret” choice of words. The “Enterprise Edition” is source-available proprietary software.

    Some things I think you should consider adding:

    • Notes on CI solutions. While SourceHut and GitLab provide excellent CI, Gitea does not. Codeberg offers CI in the form of Woodpecker CI. I don’t know how good Woodpecker is from an accessibility perspective, but Sourcehut’s “builds” service is excellent.

    • Notes on measures taken by forges to escape vendor lock-in through the network effect (I like to call this “user domestication”). Sourcehut uses mailing lists and does not require making an account; Gitea is working on ActivityPub-based federation.

  40. Posted

    Would love to see something that conforms properly to the WAI Authoring practices and supports microformats2. That could combine well with a stylesheet that doesn’t use any custom classes, just microformats classes and role attribute selectors.

    My current site doesn’t actually use any classes in the CSS apart from image-rendering utility classes; I use POSH, ARIA and microformats selectors for everything else.

    The great thing about a purely semantic stylesheet is re-usability across other websites.

  41. Posted

    The core elements of a people-focused (as opposed to a community-focused) social network are subscribing to people for content and interacting with their content. Atom (and RSS) feeds already provide “subscription” functionality; what if we went further?

    Atom feeds can serve as the foundation for distributed social media. The OStatus protocol suite describes how Salmon, ActivityStreams, and threading extensions can turn an Atom feed into a “social media feed” that people can interact with. Throw in WebSub for real-time push-based updates. This OStatus + WebSub system was the precursor to the current ActivityPub-based Fediverse.

    The IndieWeb has similar concepts. The IndieWeb community uses microformats for metadata, including the h-feed feed format. It also uses Webmentions for interaction between sites.

    Just out of curiosity, I implemented everything except for the Salmon protocol and WebSub. I prefer Webmentions to Salmon, though extensions to the former seem to overlap with the latter. I’ve tried and failed to get WebSub working in the past; I might have to run my own hub (perhaps using the websub-server Go package).

    The best part of this approach is the simplicity. Besides a Webmention receiver and a WebSub hub, all you need is a static server to deliver markup files. A separate program on your machine (i.e. not necessarily your server) can ping your WebSub hub and send Webmentions; I happen to like the command-line program Pushl. Once all the pieces come together, you start to wonder why we let social media companies flourish instead of lowering the barrier to join something like the IndieWeb. This is what the Web is made for.

    I wrote more about this site’s social features in a section of the site design page.

  42. Posted

    Many users who need a significant degree of privacy will also be excluded, as JavaScript is a major fingerprinting vector. Users of the Tor Browser are encouraged to stick to the “Safest” security level. That security level disables dangerous features such as:

    • Just-in-time compilation
    • JavaScript
    • SVG
    • MathML
    • Graphite font rendering
    • automatic media playback

    Even if it were purely a choice in user hands, I’d still feel inclined to respect it. Of course, accommodating needs should come before accommodation of wants; that doesn’t mean we should ignore the latter.

    Personally, I’d rather treat any features that disadvantage a marginalized group as a last-resort. I prefer selectively using <details> as it was intended—as a disclosure widget—and would rather come up with other creative alternatives to accordion patterns. Only when there’s no other option would I try a progressively-enhanced JS-enabled option. I’m actually a little ambivalent about <details> since I try to support alternative browser engines (beyond Blink, Gecko, and WebKit). Out of all the independent engines I’ve tried, the only one that supports <details> seems to be Servo.

    JavaScript, CSS, and—where sensible—images are optional enhancements to pages. For “apps”, progressive enhancement still applies: something informative (e.g. a skeleton with an error message explaining why JS is required) should be shown and overridden with JS.

  43. Posted

    Mullvad’s recent audit by Assured AB was a bit concerning to me. Fail2ban and user-writable scripts running as root is not the sort of thing I’d expect in a service whose only job is to provide a secure relay.

    Avoiding and guarding root should be Sysadmin 101 material.

    I recommend any amateur Linux admins read audit reports like this. While some low-priority recommendations are a but cargo-cultish, most advice is pretty solid. Frankly, much of this is the sort of thing a good admin should catch well before a proper audit.

  44. Posted , updated

    Following the recent SCOTUS ruling, many have been trying to publish resources to help people find reproductive healthcare. They often wish to do this anonymously, to avoid doxxing.

    There’s no shortage of guides on how to stay anonymous online. I recommend using the Tor Browser in a disposable Whonix VM. The Whonix Wiki has a good guide to anonymous publishing.

    Few guides cover stylometric fingerprinting. Stylometric fingerprinting is one of the most common techniques for de-anonymization, used by adversaries ranging from trolls to law enforcement.

    Common advice is to use offline machine translation to translate works to and from another language. Argos Translate and Marian are two options that come to mind.

    shows that machine translation alone isn’t nearly as strong a method as manual approaches: obfuscation (hiding your writing style) or imitation (mimicking another author). These approaches have excellent success rates, even among amateur writers. The aforementioned Whonix wiki page lists common stylometric fingerprinting vectors for manual approaches to address.

    Limiting unusual vocabulary and sentence structure make for a good start. Using a comprehensive and highly-opinionated style-guide should also help. The Economist has a good one that was specifically written to make all authors sound the same: , 12th edition (application/pdf).

    For any inexperienced writers: opinionated offline grammar checkers such as LanguageTool and RedPen may supplement a manual approach by normalizing any distinguishing “errors” in your language, but nothing beats a human editor.

    Further reading: , by OrphAnalytics SA.

  45. Posted

    I’m thinking about coining a term to reflect a non-toxic alternative to “search engine optimization” (SEO). Working name: “agent optimization”.

    MDN has SEO guidelines because people often find MDN articles through general-purpose search engines. I noticed that a subset of their advice is directly beneficial to readers.

    For example: imagine two pages have almost the same content (e.g. pages on the width and height CSS properties). Nearly-identical pages confuse search engines. To avoid duplicate content, authors are encouraged to differentiate the pages by using different examples. This is actually great for readers: when a reader navigates from one page to the next, it’d be unhelpful to present the same example again. Perhaps the width example could describe adaptation to a narrow viewport, while the height example could describe the trick for handling image aspect ratios with height: auto.

    Lots of SEO is actually just basic design and accessibility guidelines: use good link names, remember alt-text, be mobile-friendly, use headings, don’t require tons of JS to display content, prefer semantic HTML, etc. Stuff like structured data also helps improve reader-mode implementations and makes content-blocking easier.

    SEO gets toxic when it veers into copywriting guidelines, tricks like adding the current year to your heading (“Best products to buy in CURRENT_YEAR”), backlink-building, etc. Much of this does include so-called “white-hat SEO”. I think that I should distinguish “agent optimization” from “search engine optimization” by making it about accommodating the tools people use to find information, rather than about ranking high in search results or getting clicks. Once I finish my current WIP blog post (it’s about how to make privacy recommendations for different audiences), I think I’ll write about this. In the meantime, any ideas you have are welcome; please share them.

  46. Posted

    Welcome to the IndieWeb, Miriam!

    I’ve struggled to categorize what on my wite is a “post” worth syndicating vs a “page” vs ???

    I had this struggle too, and solved it with per-section and combined feeds. My combined feed contains every page on my site that includes a publication date in its metadata; my sections for articles and notes have their own respective feeds.

    If I want live updates (this is a static site) there’s still more to learn.

    Remember that pretty much all IndieWeb features are optional. You only have to implement what interests you. You can get really far when it comes to bringing a static site to the IndieWeb, so I’d suggest against jumping onto a dynamic site immediately.

    You can also push live updates using WebSub. Your main site can still be static, but you can pint a (first- or third-party) WebSub hub to push content as soon as you update your site. I plan on using this approach soon.

    I like the “static site with ancillary services” model: it keeps the core fast and simple, and makes extra modules easy to add and replace.

  47. Posted

    Preact is better than React for most use cases IMO. I think its small size can make it really powerful when you combine it with something like partial rehydration to make a view load instantly but reduce the time it takes to load the “interactivity” atop the static components.

    When the delay between loading the static components and interactivity is small, the app feels fast. When the delay is long, it would have been better to just block the rendering in the first place. Small frameworks like Preact and Svelte shine here.

    People used to think that shrinking payload sizes would become less of an issue as infrastructure improved, but the opposite thing happened with hydration-related technologies. Heh.

    I still think Vanilla is the least bad option for a good chunk of web apps.

  48. Posted

    What if Firefox and Chromium placed a year-long moratorium on all new browser features unrelated to security, accessibility, and internationalization? Effort not spent on those initiatives could be re-directed towards bugfixes.

    Defining the word “major” might be hard but I think it’s an interesting idea.

    I’m not too worried about including Safari since it could spend those months catching up.

    Inspired by a similar article by :

  49. Posted , updated

    I want to agree, with one caveat: if you’re a government or healthcare website you might still want to test with IE-mode to make sure critical functionality is at least usable. There are still companies that require you to use their sites in Internet Explorer with compatibility mode (emulates either IE 7 or IE 5, depending on some properties of the markup/headers). QuickBooks Desktop 2022 and PEACH. And as long as some software requires IE and there exist people who want to use one browser for everything, there will be people who set it as their default browser.

    You’ll probably need to support it if you have a log-in page that can be summoned when someone uses you as an OAuth provider; lots of software uses IE libraries to render the log-in window, and those aren’t going anywhere. Internet Explorer isn’t in Windows 11, but the .dll files for this are.

    IE is still supported for LTSC and government editions of Windows, and on Windows 7 ESU.

    I’m not really concerned with IE support, but I test with IE-mode in Edge sometimes. I look up any breakages to see whether they are known to be non-standard IE quirks. If they aren’t known quirks, I try to land a standards-compliant fix. The main thing I look for isn’t nonstandard behavior, but missing features.

    In other words, I test in IE to make sure my site is robust and uses progressive enhancement, not because I actually want it to work perfectly in IE. The only IE problem in my site is SVG rendering (a perfectly compliant SVG shrunk to a smaller size in HTML retains its original size in IE, but cropped with hidden overflow) and a lack of support for <details>. Turns out, basically every independent, non-mainstream, currently-active browser engine lacks <details> support except for Servo, so I might have to start looking into fallback approaches.

    Update: apparently Microsoft Outlook renders HTML emails and the entries of RSS/Atom feeds using Microsoft Word’s HTML renderer. That renderer is based on Internet Explorer’s MSHTML (Trident). So I guess IE lives on, in a way.

  50. Posted

    Armchair speculation: how can we learn from Reddit, Lemmy, “Hacker” “News”, et al?

    1. A vote should be part of a reply with at least N words. N could be increased by mods and admins. Instances could federate votes conditionally based on the length or activity of a comment. Word counts can be problematic; I don’t know a better alternative (maybe clause-count?). Flagging doesn’t need a minimum word count.

    2. Forums shouldn’t host their own top-level posts and comments. Those should be links from authors’ own websites with microformats (think IndieWeb). The forum should be Webmention-enabled.

    3. Larger communities should have ephemeral chatrooms (“ephemeral” in that public history has a retention limit if it exists at all) to incubate posts. Authors (yes, original authors) could share their work and collect feedback/improve it before it’s “ready”. They could then post with increased visibility.

    4. One reason to flag a top-level comment could be “didn’t look at the post”. I say “look at” instead of “read” because certain posts are huge essays that could take hours to read. Top level commenters should at least be expected to skim.

    These qualities will make a forum less active, since the quality of content will be higher and some validation and attention-seeking will be filtered out. Low activity means higher visibility for good content. Forums could “get of the ground” by starting invite-only, gradually enabling these rules one-by-one before opening to the public.

    (psst: I might be working on “a thing”).

  51. Posted , updated

    You might want to provision namespace-based isolation for your browsers. But that could throw a wrench into Flatpak-based distribution.

    When distributing browsers through Flatpak, things get a bit…weird. Nesting sandboxes in Flatpak doesn’t really work, since Flatpak forbids access to user namespaces.

    For Chromium, they worked around this by patching Chromium zygote process (the process that provisions sandboxes) to call a Flatpak supervisor to create additional sandboxes. This is called the “spawn strategy”. Chromium uses a two-layer sandbox: layer-2 is a syscall allow-list and layer-1 is everything else. The only problem is that Flatpak’s layer-1 sandboxes are more permissive than Chromium’s native layer-1 sandboxes, so the Chromium Flatpak has weaker sandboxing.

    Firefox’s sandboxing isn’t entirely dependent on user namespaces, but it is weakened a bit without them; there’s no “spawn strategy” implemented at the moment. More info is on Bugzilla.

    Now, whether this matters is something I can’t decide for you. My personal opinion is that Flatpak serves as a tool to package, deliver, and sandbox native applications; Web browsers are tools that deliver and sandbox Web applications. Distributing a browser through Flatpak is like distributing Flatpak itself through Flatpak. Web browsers are an alternative to Flatpak; they have their own sandboxing and updating mechanisms.

  52. Posted

    xml:space would make whitespace issues easier to handle and simplify my current solution, but not everything supports XML namespaces; I want to keep this polygot HTML5 and XHTML5 markup for now.

    Eventually I’ll offer certain enhancements to the XHTML version (add index.xhtml to the URLs or remove text/html form your Accept header but include application/xhtml+xml) and I’ve already made my Atom feeds a bit simpler, but there’s a lot to do before then.

    I’ve added ActivityStreams, OStatus, and friends to my Atom feeds; maybe I could add them to my XHTML pages using namespaces, if RDFa doesn’t work out. First I wanna try my hand at writing an ontology for webrings so people can mark up their webrings with RDFa/microdata. That’ll make it easy to do things like check for broken webrings or build cool visualizations of overlapping rings.

    I should also try my hand at XSLT for the Atom feeds to get a baseline browser preview.

  53. Posted , updated

    ncurses is fine for certain specific purposes, like querying terminal characteristics.

    I think if you’re building a TUI it should generally be one of multiple options that share a library/backend or it should be something with many alternatives that are at least equivalent, given the poor accessibility of TUIs in general. If one of those things is true, then it should be fine to use ncurses for the TUI.

    There’s a Python library called “Textualize” for building TUIs and CLI shells. They’re working on a web target which they claim can get much better accessibility.

  54. Posted , updated

    My current approach to “responsiveness” is to increase the font sizes on screens. User interfaces should generally have smaller text while article bodies should prioritize readability and be larger. Default stylesheets are take a (literal) one-size-fits-all approach, trying to optimize for both. But I only use percentages for font sizes, to respect user preferences.

    I also increase the default font size to make it easier to increase tap target sizes to Google’s recommended 48x48 px sizes, without overlapping other targets in a 56x56 px radius. A size of 108.75% was the minimum necessary to achieve my goals in all combinations of major browsers and their default stylesheets across operating systems. Since scrollbars and screen edges are often tap targets, I also set minimum margin sizes.

    I reduce the font size to the default 100% and eliminate the extra margins on extremely narrow screens (think KaiOS devices and smartwatches) where the screen is too small to fit several touch-friendly elements. I do the same on print.

    My rationale:

    • If you use a smart feature phone, then you navigate with a keypad. The interface does not need to be touch-friendly.

    • If you use a smartwatch (like the Apple Watch) it should auto enable reading mode for long-form text, so compromising a little on readability might be worth improving navigation.

    • If you want to read in a sidebar then you are likely reading the article alongside some other text. My page’s text should match most other content instead of “sticking out”.

    • If you print it out then font sizes are already optimized for readability rather than for user interfaces.

  55. Posted

    People have mostly moved on from DTDs. In HTML-land, they use the Living Standard; in XML land, they stick to boring existing parsing rules and use XML namespaces. In both, they use RDF vocabularies to describe RDF-based structured data.

    I’m curious as to why you’re interested in creating a new DTD. I think that unless you plan on creating a new SGML-based language, you’re better served by namespaces.

  56. Posted , updated

    This is a good article on the difference between SC 1.4.4 and 1.4.10. However, I don’t think these criteria go far enough:

    Even narrower viewports exist. KaiOS devices tend to have 240 px viewports; smartwatches tend to have half the width of a phone while emulating a phone width (Apple Watches can be instructed not to do this with a proprietary meta tag). Of course, making sites watch-compatible is a stretch, but support for feature phones running KaiOS should be reasonable. I wrote about this more in Best practices for inclusive textual websites.

    Another thing worth remembering is that users can change default fonts or override sire-set fonts. Don’t just test with default default fonts; test with something wider. These criteria should specify some font metrics or (royalty free) representative wide fonts to use for testing.

  57. Posted , updated

    I think this post is correct, strictly speaking. I also feel like it misses the point of tracker blocking (or at least, what I think the point should be). Many people have a relatively casual threat model when they do their typical browsing.

    Lots of people are less concerned with avoiding identification than they are with reducing the amount of data collected about them. For example, if they sign into an account that’s linked to their real identity, they fully expect to be identified by the site. However, if the site contains Facebook and Google trackers, they would rather not run those because they harm the user rather than help.

    To say that this is not a perfect solution would be an understatement. But when it comes to meeting the goals of such a user, content blocking isn’t useless. It straddles the gray area between quality-of-life improvements (blocking content makes pages less unpleasant and heavy) and slight unobtrusive privacy improvements (the majority of sites nowadays still outsource most of their tracking to well-known third parties).

    The ideal approach is obviously to use something like the Tor Browser’s “Safest” mode (or perhaps the “safer” mode in a Whonix VM), which doesn’t rely on badness enumeration. On that I agree. I personally switch between the Tor Browser for anonymous browsing (anonymity), Chromium for Web apps (security), and Firefox for general non-anonymous browsing (convenience and quality-of-life). Blocking trackers would not make sense for browsing anonymously, but is a slight improvement for non-anonymous browsing. Badness enumeration is of course counterproductive when trying to be fully anonymous.

    In practice, content blocking reduces someone’s online footprint. It doesn’t prevent it from being created in the first place, and it can be circumvented. But footprint reduction is all that many are interested in, especially when it also offers unrelated perks like less ads and lighter pages.

  58. Posted , updated

    Being enrolled in a study should require prior informed consent. Terms of the data collection, including what data can be collected and how that data will be used, must be presented to all participants in language they can understand. Only then can they provide informed consent.

    Harvesting data without permission is just exploitation. Software improvements and user engagement are not more important than basic respect for user agency.

    Moreover, not everyone is like you. People who do have reason to care about data collection should not have their critical needs outweighed for the mere convenience of the majority. This type of rhetoric is often used to dismiss accessibility concerns, which is why we have to turn to legislation.

  59. Posted , updated

    I was referring to crawlers that build indexes for search engines to use. DuckDuckGo does have a crawler—DuckDuckBot—but it’s only used for fetching favicons and scraping certain sites for infoboxes (“instant answers”, the fancy widgets next to/above the classic link results).

    DuckDuckGo and other engines that use Bing’s commercial API have contractual arrangements that typically include a clause that says something like “don’t you dare change our results, we don’t want to create a competitor to Bing that has better results than us”. Very few companies manage to negotiate an exception; DuckDuckGo is not one of those companies, to my knowledge.

    So to answer your question: it’s irrelevant. “” is a JS-free front-end to DuckDuckGo’s backend, and mostly serves as a proxy to Bing results.

    For the record, Google isn’t any different when it comes to their API. That’s why Ixquick shut down and pivoted to Startpage; Google wasn’t happy with Ixquick integrating multiple sources.

    More info on search engines.

  60. Posted , updated

    The only engines I know of that run JavaScript are Google, Bing, and maybe Petal. None of the other engines in my list appear to support it. I don’t even think Yandex does.

    It’s common practice for sites to give a JavaScript-lite version to search engines, though if the content differs heavily you run the risk of hitting a manual action. I’d imagine that search-crawler-exclusive editions would become the norm if crawlers stopped handling JavaScript.

    Marginalia actually seems to penalize its use.

    Update: Yep (formerly FairSearch) also seems to evaluate JavaScript

  61. Posted , updated

    Pale Moon’s inception pre-dates Firefox 57 by many years; before its notoriety following the removal of XUL/XPCOM, it was popular among people who didn’t like Electrolysis.

    I hate that Pale Moon is so behind on security because it also has nice stuff that Mozilla axed. Some things were axed for good reason, like extensions with the ability to alter browser functionality. Others were axed without good reason, like built-in RSS/Atom support.

    WebExtensions that fill in missing functionality often require content injection which is problematic for a variety of reasons. To name a few: try visiting a page that has a sandbox CSP directive without allow-same-origin or allow-scripts and see how well it works, saving a page and noticing it has extra scripts or iframes, or seeing addon scripts activate too late when your underpowered machine is under load. It’s better than giving them access to browser functionality but nothing beats having features in the actual browser.

    I still wouldn’t recommend it due to extremely weak sandboxing and a naive approach to security. The devs respond to sandboxing queries by saying it’s secure because “it separates the content and application” which tells you how little they care or understand; untrusted content needs isolation not just from the browser but from other untrusted content. Given the scope of a browser, even Firefox isn’t where it should be (even given their commendable progress on Fission, RLBox, and their utility process overhaul), let alone caught up to the mitigations in Chromium’s Blink or WebKit’s JavaScriptCore but I digress.

    It’d be totally fine if they described their browser as a complement to a more airtight one or as a dev tool (it’s honestly a great dev tool given some addons, I’ll happily concede that). But when you describe yourself as a replacement to other browsers but lack the security architecture to back it up, you’re being irresponsible.

  62. Posted

    Commodification means something else; I’m assuming you’re referring to “commoditize”, as in “commoditize your complement”. Although in this context the words have some really interesting overlap, which is why I brought it up. See by .

    We are first commodified by being made a complement to a product, then gradually commoditized as complements ideally are.

  63. Posted

    I’m in partial agreement with this take.

    On one hand, expectations change with time. Most people outside my bubble look at interfaces I like using and say they look “ugly” and that they’re “weird” (their words); they wouldn’t have said that when I was younger.

    On the other hand, some “annoyances” are actually removable barriers. Accessibility comes to mind. If you take software that does not work with assistive technologies (ATs) and fix it, AT-users might move on to the next accessibility issue. But they’ll be markedly happier than before, when they just couldn’t use it.

    Similar examples include localization and compatibility.

    Man, positive takes like this feel really out of character for me.

  64. Posted , updated

    I’ve been planning on writing a big “meta” post explaining how this site is built, but first I want to reach a few milestones, most of which are IndieWeb-related. Here’s what I’ve already done:

    • Microformats
    • More semantic markup: Creative Commons and vocabularies
    • Web sign-in (using an IndieAuth service)
    • multiple types of posts
    • Sending Webmentions
    • Displaying Webmentions
    • User-sendable Webmentions with a form
    • RSS feeds for posts and notes
    • Atom feed for posts and notes with ActivityStreams metadata
    • Automatic POSSE of bookmarks to TinyGem (bookmarking service)

    However, I still have a ways to go. Here’s what I plan on adding:

    • Add some semantic markup to list online “friends”, probably using FOAF ontology
    • Preview Webmention entry contents
    • Related to previous point: create a blogroll
    • Automatic POSSE of notes to Fedi (it’s mostly manual right now)
    • Combined Atom feed
    • WebSub
    • Permalinks for bookmarks
    • Atom feed for bookmarks
    • Automatic POSSE of bookmarks to Fedi
    • Time-period based pagination and navigation on notes/posts page.

    Once I finish the above, I’ll be ready for a “meta” post. Some more tasks after that:

    • Run my own WebSub hub.
    • Add my own front-end for search results (my first non-static content).
    • Pingback support
    • Create a webring. What I’ve learned while doing the above will inform inclusion criteria.
  65. Posted

    Some of my posts are long. My longest post is almost 20k words as of right now (60-80 pages printed out), and will get longer as I update it.

    Length is an imperfect yet useful measure of the amount of detail one can expect. There are many “lists of practices” on the Web about web design. By communicating that mine would take an hour and a half to read, I communicate that my list has some more thought put into it.

    This also signals to some people that they should probably bookmark the article for later so they can read it properly, or helps them prioritize shorter articles first.

    Someone who may end up reading an entire post after going through a paragraph or two may be scared away if they know it’ll take them 30 minutes to go through it.

    I think these people would be scared off regardless, simply by seeing how much they have to scroll through. They might also feel overwhelmed by the number of entries in the table of contents. That’s why I include a “TLDR” or explicitly recommend skipping from the introduction straight to the conclusion for readers in a hurry.

  66. Posted

    One thing I don’t like is faux corporate support for pride month. Think rainbow branding for large organizations that don’t actually do much to improve the systems they benefit from.

    A good smoke test to see if rainbow-flag/BLM-repping organizations actually give a shit: test their website’s accessibility. If they ignore disabled users because they’re a minority with different needs, well, that probably speaks volumes regarding their attitudes towards any minority. Actions speak louder than words.

    They don’t care about minorities; they’re only in if for the branding. When a soulless organization uses your symbols, it remains soulless.

    Soulless organizations don’t have good or evil intent. put this best in his talk (starts at ).

  67. Posted

    I just made a massive internal overhaul of my website, I prettified all the URLs to remove the trailing “.html” suffixes. I added re-directs from the old locations to the new ones, so your links won’t break.

    The reason I did this was because I plan on making alternative content types share the same index URL, except for the suffix. So could have an index.html, index.xml (RSS),, index.gmi…you get the picture.

    I removed the RSS feed from my Gemini capsule in favor of just supporting gmisub.

    I also added Atom feeds to keep my existing RSS feed company:

    Those make for the first step towards supporting WebSub. I’ll have to look into ActivityStreams documentation to figure out which markup to add to my Atom feeds first. I’ll probably add a curl command to my CI job to get a WebSub endpoint to re-read my Atom feeds whenever I push a change.

    I need to figure out how to get Hugo to do a “combined” feed for everything.

  68. Posted , updated

    I decided my site had enough content to warrant a search form, so I added one to the footer. I kanged the CSS from; I liked how their search box was adaptive yet compatible with legacy browsers. This is a static site so I made it point to Search My Site, which regularly crawls my whole website.

    Eventually I’ll add a dynamic page for search results (probably using the Search My Site API), and add an ATOM feed for posts and notes (I currently have an RSS feed for posts, and that’s not going anywhere). If I get those two, I’ll be ready for the next step of setting up WebSub and starting on IndieMark 4 (I’ve decided not to POSSE all my microblog posts, to maintain some separation between my “Rohan” and “Seirdy” identities).

  69. Posted

    What do you mean by “false sense of security”? Signal’s cryptography is pretty solid. It’s one of the only messengers with such a lack of metadata leakage; if you combine it with Tor you can add enough noise to the network-layer metadata to be more private than almost any alternative.

    Don’t get me wrong, I dislike it on the grounds of being a closed platform, but few alternatives exist that support both offline messaging and have such little metadata leakage. I’m willing to hear suggested alternatives that do not bake a “cryptographically-secure, decentralized pyramid scheme” (cryptocurrency) into the protocol. I’m not aware of any such alternative at the moment.

  70. Posted

    I read your article and share similar concerns. Using Microsoft Bing and Google Search’s commercial APIs generally requires accepting some harsh terms, including a ban on mixing SERPs from multiple sources (this is why Ixquick shut down and the company pivoted to the Google-exclusive Startpage search service). But the requirement to allow trackers in a companion web browser was new to me.

    Most of these agreements are confidential, so users don’t really get transparency. On rare occasions, certain engines have successfully negotiated exceptions to result-mixing, but we don’t know what other terms are involved in these agreements.

    I’ve catalogued some other engines in my post , and there are many alternatives that don’t have this conflict of interest.

    Most of these are not as good as Google/Bing when it comes to finding specific pieces of information, but many are far better when it comes to website discovery under a particular topic. Mainstream engines always seem to serve up webpages carefully designed to answer a specific question when I’m really just trying to learn about a larger topic. When using an engine like Marginalia or Alexandria, I can find “webpages about a topic” rather than “webpages designed to show up for a particular query”.

    One example: I was using Ansible at work just before my lunch break and I wanted to find examples of idempotent Ansible playbooks. Searching for “Ansible idempotent” on mainstream search engines shows blog posts and forums trying to answer the question “how to make playbooks idempotent”. Searching on Alexandria and source code forges turns up actual examples of playbooks and snippets that feature idempotency.

    SEO is a major culprit, but it’s not the only one. Forums posters are often just trying to get a question answered, but search engines rank them well because they are optimized to find answers rather than find general resources.

    In short: DuckDuckGo and other Google/Bing/Yandex competitors are tools for answering questions, not tools to learn about something. I’ve tried to reduce my reliance on them.

  71. Posted

    I try to have limited reliance on CSS media queries in favor of being inclusive by as many people as possible by default, including fingerprinting-averse readers. Unfortunately, I have concluded that it is impossible to set one single website color palette that ticks all of the following boxes:

    • Familiar: colors aren’t particularly “novel” and don’t impose a learning curve. The difference between a visited and unvisited link should be clear enough from the get-go.
    • Friendly to various types of color blindness
    • Sufficient contrast for high-contrast needs
    • Autism-friendly, anxiety-friendly colors that do not trigger overstimulation or imply a warning.
    • Related: sensitive to cultural norms (is red actually a “warning” to everyone?).

    I set a custom palette for my site’s dark theme. Since its contrast is a bit high, I made it respond to the prefers-contrast: less media query. Now, My 108% body text typically renders at 17.4 px, which should have an absolute value below 90 Lc on the APCA lookup table. I dropped my link contrast to 90 Lc and my body text to something slightly higher (article body text should have at least as much contrast as link text and buttons to avoid the “piercing glare” effect interactive elements can have; I should add that to my website best practices article sometime).

  72. Posted

    This is first “note” on my IndieWeb Site. Notes will be shorter and less formal than typical blog posts; this is a microblog, not a typical weblog.

    Once this is working correctly, I’ll need to figure out a solution to POSSE these notes to the Fediverse.