Skip to content

Notes

This is my microblog, containing short informal entries. They’re longer than most posts on microblogging networks (some would call this a “miniblog” instead), but a fraction of the size of the longer entries on my blog. Most posts are under 300 words.

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. Noted by . Last updated .

    The four most popular ways to use RDF-based metadata on websites are RDFa-Core, RDFa-Lite, Microdata, and inline JSON-LD.

    I can’t use RDFa-Lite because I need rel HTML attributes. rel silently upgrades RDFa-Lite to RDFa-Core, which parses differently. I doubt all parsers upgrade correctly; some will try to parse RDFa-Core as RDFa-Lite. Conformant RDFa parsers upgrade RDFa-Lite pages to RDFa-Core despite many authors only being familiar with RDFa-Lite. I suppose resources like Schema.org and Google’s documentation only documenting RDFa-Lite markup worsens the confusion. Update : has clarified on the Fediverse that this is the behavior of one faulty parser; rel only triggers an upgrade when used with an RDFa namespace. I may re-evaluate RDFa.

    With RDFa split between two incompatible alternatives with a confusing upgrade mechanism, the alternatives are Microdata and JSON-LD. I use structured data extensively; JSON-LD would duplicate most of the page. Let’s use this relatively short article as an example. Exruct can convert the embedded Microdata into a massive JSON document featuring JSON-LD. Take a look at the JSON-LD and HTML side by side. Microdata attributes take a fraction of the footprint, encode the same information, and don’t require duplicating nearly the entire page.

  2. Noted by .

    I agree wholeheartedly with Google’s Page Annotations being an absolutely awful antifeature, and recommend that others opt-out and/or protest the feature. I want to make a clarification that doesn’t invalidate your main points:

    Clicking annotations doesn’t navigate away from your site to a Google search; it triggers an overlay with infoboxes about the term you selected. It’s similar to the iOS “Look Up” option for selected text. It’s wrong to do because this obfuscates what is and isn’t a link the author placed on the page. Inserting what appears to be links into the page crosses the line from user-agent interventions, such as adblocking or turning off certain unsafe features (acceptable) to editing an author’s words in a way that isn’t required for people to read them (unacceptable).

    Editing page contents is fine if it’s necessary for people to read them, e.g. translations or the WAI-Adapt standards. Both ideally inform the user that the page has been modified. Page Annotations go well beyond that.

  3. Noted by . Last updated .

    Real time collaboration software and text boxes that rapidly save drafts to the cloud essentially log your fingerprintable typing behavior. The industry refers to this information as “keystroke dynamics” or “typing biometrics”.

    Other modern “operator signatures” are easier to minimize. A user can learn to obfuscate writing style, or can use keyboard navigation with different pointing devices to limit fingerprinting of mouse behavior. Update: switched link to Kloak to Whonix’ updated fork.

    Keystroke biometrics are difficult to anonymize without installing software such as kloak or browser extensions (the latter of which may add fingerprintable vectors) designed to cloak some of your typing habits. Signature typos, approximate typing speed, etc. will still leak. Alternatively, we could normalize typing messages out in a simple offline editors that don’t store revision history before pasting them into other input fields.

  4. Noted by .

    I don’t think most people realize how Firefox and Safari depend on Google for more than “just” revenue from default search engine deals and prototyping new web platform features.

    Off the top of my head, Safari and Firefox use the following Chromium libraries: libwebrtc, libbrotli, libvpx, libwebp, some color management libraries, libjxl (Chromium may eventually contribute a Rust JPEG-XL implementation to Firefox; it’s a hard image format to implement!), much of Safari’s cryptography (from BoringSSL), Firefox’s 2D renderer (Skia)…the list goes on. Much of Firefox’s security overhaul in recent years (process isolation, site isolation, user namespace sandboxes, effort on building with ControlFlowIntegrity) is directly inspired by Chromium’s architecture.

    Interdependence for independent components can be mutually beneficial. For something to be part of Chromium, it needs to build and test with a battery of sanitizers and receive continuous fuzzing. Mozilla and Safari do something similar. All benefit from libraries getting patched to meet each others’ security requirements. Without Google, Mozilla and Apple must assume responsibility to maintain these libraries to a browser-grade standard.

    I see many advocates for Chromium alternatives say the Web would be better without Chromium. That may be true, but Chromium alternatives may also be worse.

    For completeness: Firefox and Safari’s influence on Chromium in recent years includes the addition of memory-safe languages, partitioned site storage, declarative content blocking (from Safari), and a vague multi-year repeatedly-delayed intent to phase out third-party cookies. Chromium would be no better off without other browser projects.

  5. Noted by .

    In opsec, duress (“rubber-hose”) attacks are famously hard to address. Cryptographic keys that cannot be lost have poor protections against duress.

    Travelers can leave key fobs at home should they be accosted. A victim of a break-in can conveniently “lose” or smash a hardware key, erasing any encrypted data. Yes, I know about cold-boot attacks; I don’t recommend at-risk people to leave things decrypted for long durations. I like the idea of spring-loaded key fobs that can’t be left plugged in.

    People talking about key fob body implants don’t usually plan for removing them in seconds with plausible deniability.

  6. Noted by . Last updated .

    Common Crawl is the closest thing we have to an open index, though it doesn’t meet your requirement of ignoring robots.txt for corporate websites while obeying it for personal sites. Unfortunately, being open and publicly available means that people use it to train LLMs. Google did this for initial versions of Bard, so a lot of sites block its crawler. Most robots.txt guides for blocking GenAI crawlers include an entry for it now.

    Common Crawl powers Alexandria Search and was the basis of Stract’s initial index, both of which are upstart FOSS engines.

    A similar EU-focused project is OpenWebSearch/Owler.

  7. Noted by . Last updated .

    Selectivity is long overdue. Marginalia, Stract, and Teclis feel like a breath of fresh air for broad short-tail queries because they downrank or skip pages full of ads, trackers, scripts, and even SEO. However, Google’s selectivity can’t penalise such criteria as that would conflict with its ad business.

    Google has a bias against new sites. This makes sense, given their spam potential. I disagree with your argument that a bias against new sites is a pivot away from Experience, Expertise, authoritativeness, and trustworthiness (EEAT): it takes time for a website to become an authority and earn trust. If delayed indexing of new sites is wrong, then the problem lies with EEAT. I argue that EEAT is a good framework for an answer-focused engine, but a bad framework for a discovery- or surfing-focused engine like Marginalia or Wiby, respectively.

  8. Noted by .

    In the wake of a certain ad-funded browser company bundling adtech into its browser yet again, some people have been recommending Ungoogled-Chromium (UGC). I think it’s fine to recommend UGC with caveats, such as the fact that it disables component updates that include:

    • Certificate revocation. Chromium uses downloaded CRLSets for revocation; it does not support OCSP.

    • Out of band security patches. When browser components have exploits in the wild, they need to be patched ASAP; updating billions of installations within time-frames measured in hours often means restartless out-of-band updates.

    • Out of band certificate bundle updates.

    If you assume Google uses its component update server logs maliciously, you may wish to consider a fork that still offers component updates provided by a different party’s servers.

    UGC disabled mDNS at one point. This exposed local IP addresses over WebRTC for years, but they seem to have shipped a fix in May 2023 to disable non-proxied UDP.

    UGC also disables the Chrome Web Store in favor of installing extensions out of band. Make sure you regularly update your extensions installed out-of-band, since UGC won’t do it on its own. Some scripts and a special extension re-implement some of this functionality.

    Overall, UGC is still safer than QtWebEngine despite making heavy compromises to security for privacy (though I can’t see how either benefited from disabling mDNS: I’m not aware of threat models under which revealing a local IP to every application is preferable to revealing it to just Google). Running UGC is fine if you understand these trade-offs and have accounted for them. I use it in headless mode to run accessibility and performance tests.

  9. Noted by .

    Switching a site to XHTML5 is only a lot of work at first, because it may have latent bugs. For instance, you may have a stray tag that the HTML parser auto-closes but an XHTML parser won’t. I find this effort worthwhile because some of these bugs will eventually visibly manifest.

    One thing I’ve noticed is that some tools are incompatible with an XHTML5 MIME type. Site auditors like Lighthouse are only provisionally compatible, and some browser extensions are rather buggy. You can compare them yourself on seirdy.one: switch the MIME type by appending /index.xhtml to a URL. You may have to disable the CSP sandbox by appending ?sandbox=off to the URL to get Lighthouse to work. I keep my site polygot and serve with the text/html MIME type by default for maximum compatibility.

  10. Noted by .

    This page at the time of writing grades websites’ progressive enhancement based on their ability to work without JavaScript. Everything, not just JavaScript, should be progressive enhancements.

    HTML elements already have progressive enhancement built-in. CSS, JS, and embedded content should be progressively enhanced too. The page should make sense without scripts and styles, alt-text should be available in the absence of embedded media, etc. We shouldn’t put scripting on a pedestal above everything else.

    I suggest replacing references to JavaScript with references to non-HTML content. See also: “curlable” on the IndieWeb wiki.

    A more minor piece of feedback: I’d suggest re-sizing the badges to 88-by-31 pixels if possible. It’s a very popular size for badges; at these dimensions, they would look good alongside others of the same size (examples from the W3C).

  11. Noted by .

    My search engine article blew up recently, as yet another major publication linked it (yay! /gen), so I made some fixes:

    • Moved a couple engines to the graveyard. h/t to for telling me about moose.at’s demise, and to my broken link checker for telling me about Siik being down for a while now.
    • Updated my methodology section to emphasize how I now use word-substitutions to fingerprint an engine’s source. Queries that lend themselves to word-substitution are now my primary approach to uncovering which provider an engine uses for search results, followed by some long-tail queries and search operator support.

    The full list of changes is in the Git log. Things I should add in the future:

    • I ought to add a section to describe why I don’t personally like metasearch engines as much as I used to. TLDR: each engine has its own quirks and search operators that I learn to use, and throwing them all on one page forces me to use whatever quirks they have in common. This is really bad for long-tail queries.
    • I should put more effort into categorizing engines by strength as well as index size. I’ll have to come up with appropriate terms for things like “ability to find specific pages with specific topics” (less aggressive word substitutions, less focus on semantic search: Mojeek is one of the best at this, Yep is terrible), or “ability to discover pages about a given broad topic” (Yep is good at this once you learn to use it well, but Mojeek isn’t).

    That second bullet point is really important. Part of the point of this article is to show that nobody can beat Google at being Google (except perhaps Bing), but we can beat Google at more specific niches.

  12. Noted by . Last updated .

    The best ways to improve opsec against coercion are to:

    • Limit what can be taken (reduce what’s stored on a device).
    • Fake what you do have: use duress passwords or secondary devices.
    • Last resort: use a hardware key that’s deliberately easy to lose or break, so there’s potentially no key to give up in a rubber-hose attack.

    There’s overlap between the three. A duress password temporarily limits what’s stored on a device, and losing a decryption key is more or less the same as instantly wiping encrypted data to reduce what you have to offer. All come down to having less data to give when coerced into giving what you have. Operating systems should also obey this principle by storing as little offline data as possible, and providing duress safeguards for what must be stored.

    Windows Recall captures an amount of offline telemetry comparable to parental-control apps often used to control human trafficking victims: the data encompass everything potential victims do on their machines, without any duress protections. Presenting such a feature as opt-out seems like it’s almost designed to hurt victims.

    The decision-makers behind features like Recall, or invasive child-monitoring spyware, have likely never experienced this type of abuse. Or perhaps they are the abusive party at home.

  13. Noted by .

    My previous response to similar concerns is relevant. To elaborate:

    If nothing prevents bad behavior from an ISP, and it has happened before, then you should assume it’s happening. This extends to injecting JavaScript apps into insecure connections.

    Unless you trust every hop from your browser to the destination server (and back), assume anything unencrypted can and will be inspected (and potentially tampered with). Encrypt everything you can.

  14. Noted by .

    For CSS Naked Day, I decided to do something a little different. I didn’t want to actually disable my stylesheet: very long lines of small text aren’t terribly accessible, and fingerprinting-averse readers of my Onion site may not wish to zoom in (I know for a fact that these people exist; I’ve spoken to them, and I don’t like reducing my readers to numbers in an analytics dashboard).

    Instead, I made CSS Naked Day participation opt-in with a new a query parameter to the URLs: Just add ?sandbox=broken to the end of any URL on seirdy.one. This query parameter sets a maximally-restrictive Content-Security-Policy header, instructing your browser to block CSS, images, media, and more from loading. The only thing that the CSP will allow is submitting forms (Webmentions). See my CSP Bug Reproduction page for other values you can give the sandbox parameter on seirdy.one and its Onion location.

    This does not apply to mirrors of my site, such as the envs.net mirror.

  15. Noted by . Last updated .

    I use a quick crypto.FNV32a-based fix for short cache-busting fingerprints that doesn’t directly rely on the unstable .Key method.

    Code snippet 1 (Go template): I use Hugo’s crypto.FNV32a to generate a short hash, then copy the resource to a new path with that fingerprint. 
    {{ $resource := resources.Get . -}}
{{- $target_path_formatStr := (replaceRE `(\.[^\.]*)$` ".%d$1" .) -}}
{{- $cacheBuster := $resource.Content | crypto.FNV32a -}}
{{- $target_path := printf $target_path_formatStr $cacheBuster -}}
{{- return resources.Copy $target_path $resource -}}
    Code snippet 2 (Go template): You can see it used in my site’s head element. I invoke it using partialCached so the fingerprinting only happens once per resource: 
    {{ $icon_svg := partialCached "cache-bust.html" "/favicon.svg" "/favicon.svg" }}
{{- printf `<link rel="icon" sizes="any" href="%s" type="image/svg+xml" />` $icon_svg.RelPermalink | safeHTML }}
    Code snippet 3 (HTML): Here’s a snippet of the final rendered result: 
    <link rel="icon" sizes="any" href="/favicon.2229316949.svg" type="image/svg+xml"/>

    Encoding it to a higher base and using alphanumerics could shave off 1-2 ch.

  16. Noted by .

    Using neural nets trained on other people’s work to create (and often profit from) new work in their style without compensation is problematic. I don’t think that doing the same for upscaling algorithms is.

    Upscalers can reduce the hardware requirements for games, support remastering old media, etc. which isn’t really the same as laundering someone else’s creativity and profiting from it at their expense. Upscalers feel more like bicycles for the mind than crude replacements for them.

    I haven’t thought through this fully, and I’m open to being proven wrong.

  17. Noted by .

    Sourcehut and Codeberg are experiencing reliability issues due to an ongoing layer-3 DDoS attack.

    I managed to continue working on this site uninterrupted:

    • I practice Hydra Hosting by simultaneously pushing to at least four remotes (git.sr.ht, codeberg.org, github.com, gitlab.com, git.envs.net, and a private one).

    • My CI manifests are thin wrappers around shell scripts, Makefiles, and other portable tooling.

    • My CI dependencies are mostly statically-linked binaries in a tarball that I host at multiple locations.

    • My CI jobs can all run locally.

    • I use email-based contributions: I accept pull-requests on other forges with email notifications, and formatted patches through email.

    I don’t ever want to be limited by a single provider’s uptime if I can help it.

  18. Noted by . Last updated .

    I admit that I feel salty about the word “enshittification” taking off instead of my phrase for the same thing: “user domestication”. I prefer the latter because it emphasizes the gross disrespect so many platforms show their users, and how the lack of autonomy/mobility naturally leads to enshittification.

    Any platform able to get away with enshittification will do so when given the incentive. Enshittification emphasizes the process of a platform’s downfall; we should be taking steps to prevent that from happening in the first place by keeping platforms open. Vigilance against enshittification is misplaced when better spent against user domestication.

  19. Noted by .

    An alternative to controversial recommendation algorithms is timeline-filtering algorithms. Feeling pressured to scroll through too much is unhealthy and lends itself to addiction; filtering things down once a user scrolls down far enough should be a welcome opt-in feature.

    For example, a mutuals-only filter combined with a minimum-interaction-count filter could be a good way to “catch up” quickly after a long absence. Only showing posts common across a set of timelines is another; for example, I would like to see a filtered view of Akkoma’s bubble timeline restricted to what’s on my home timeline.

    Conditionally showing reblogs is another way to filter. Unread reblogs from mutuals should be the only visible reblogs I have scrolled down far enough.

  20. Noted by .

    I continue to work on my site over break. Today I got the build time down to 3.5 seconds for the Hugo build and just under 3 seconds for post-processing and syntax-checking (mostly using xmllint). I’m not parallelizing the post-processing since my laptop just has two cores (no simultaneous multithreading) and CI has one.

    Seven seconds is still too slow for changes to feel instant, though. I can’t just rebuild on save. It’s especially slow for a site with only <200 pages.

    Hugo’s profiler tells me that a lot of the time is spent searching for Webmentions that match the current page. Perhaps I should do that server-side ahead of time; right now, I download all my Webmentions as one big fat JSON file and load it into memory once. I should also move some post-processing back into Hugo.

    I also re-used xmllint to minify my feeds and check their syntax. The minification worked particularly well since my feeds contain raw, un-escaped XHTML. Some clients still fetch my full-text feeds without transparent compression.

  21. Noted by . Last updated .

    Whenever I discover a new GUI toolkit, my first question is always “is it more native than the Web?” For reference, here are some ways Web apps have better system integration than Flutter:

    • System fonts, font hinting settings, and font fallback settings.
    • System text navigation shortcuts.
    • System scrollbar visibility, thickness, and click settings/behavior.
    • System highlight menus and controls (on touchscreens).
    • System display scaling settings.
    • System reduced-motion settings (An API is documented, but I have never used a Flutter app that actually disables animations. I may be wrong).
    • System reduced-transparency settings.
    • System forced-colors mode (Windows High Contrast Mode).
    • System color palettes (some browsers support setting default colors without necessarily forcing the palette).
    • System media controls (play/pause/skip, current track, e.g. using MPRIS on freedesktop platforms).

    It’s an easier question to answer than my second question: “What WCAG conformance level can I hope for?

  22. Noted by . Last updated .

    The three most popular DNS protocols with transit encryption are DNS-over-HTTPS (DoH), DNS-over-TLS (DoT), and DNS-over-QUIC (DoQ). This should help you choose what to use:

    1. Do you actually need to override OS DNS support? If not, or if you’re unsure, go to 6.
    2. Are you ready to implement DNS protocols correctly, or add a dependency that does so? If you’re not, go to 5.
    3. Does the network filter DNS traffic? If it does, go to 5.
    4. Do you already have QUIC support? If not, use DoT. If you do, use DoQ.
    5. Do you have an HTTPS stack? If you do, use DoH.
    6. Give up and delegate to the OS.

    Let your HTTPS stack handle HTTP/1.1 vs. HTTP/2 vs. HTTP/3 support; don’t treat DNS-over-HTTP/3 as a separate protocol. I don’t know enough about DNSCrypt to make an informed recommendation about it, but DoQ and DoH meet my needs well enough.

  23. Noted by . Last updated .

    Webrings are alive and well; they don’t need to be “brought back” because they’re already here.

    I’m in 14 webrings. If you think that’s a lot, foreverkeith.is has a growing list of 100 or so.

    Some have gotten quite large. The Hotline Webring is close to 700 members. The Yesterweb Webring recently shut down because it got too large, past 800 members! Some of the people behind the larger Yesterweb community felt that the webring had gone too mainstream and become a venue for SEO and traffic-boosting rather than a chill network of friendly like-minded people.

    At this point, webrings aren’t some dated concept that’s become tiny and niche. They’re quite mainstream outside of the commercial web.

  24. Noted by .

    It looks like the Tor Browser is finally addressing some of the accessibility issues inherent to its fingerprinting resistance, starting with Issue 42226: Reduce Customisability of default fonts and colours. The propsed fix of curating common “sets” of settings would add some entropy to everybody’s fingerprint but allow more people to use the browser overall, as it would support some degree of personalization (e.g. dark mode).

    I welcome the change. Anonymity should be accessible.

  25. Noted by . Last updated .

    The primary, hopefully-unintended function of a “real-name policy” is to exclude people and make people less genuine. Many aren’t at home with the name deemed by society to be “real”.

    There’s plural systems. And trans users who haven’t made a full break from their deadname(s) yet. And at-risk users who would be doxed by such a policy. And folks who simply feel more comfortable with online handles than meatspace names, for no special reason in particular.

    What incredible benefits could be worth shafting all these people? Assuming you even manage to pull it off; see by .

  26. Noted by . Last updated .

    Firefox 120 appears to have regressed to its older WebKit-like blue focus outlines; it briefly had dual-color white-and-blue outlines.

    I’d previously advised certain sites (sites with background colors that have poor contrast against the focus-ring’s blue color) to override the default focus indicators. I planned to temper that advice since Chromium and Firefox adopted focus indicators that appeared visible on a variety of background colors; I suppose I should cancel those plans.

    As long as people have to use defaults they didn’t choose (e.g. Tor Browser users are stuck with default settings), we have to override them when they’re inaccessible. We can’t count on users to always have the means to do this: fingerprinting concerns and device-borrowing are facts of life.

    Update : it appears that as of Firefox 121, the issue only appears in forced-colors mode (e.g. when toggling color overrides in the color settings of about:preferences). Input elements are unaffected. With forced-colors disabled, Firefox uses the better two-tone indicator.

  27. Noted by .

    What I consider:

    • Is an offending post a property of the instance or the user? It may reflect the instance if it’s written or reblogged by a staff member or part of a large pattern.

    • If it’s a property of the user but reporting doesn’t work, do I have the spoons to moderate their instance on a user-by-case basis? I usually do this only if there are existing connections or if the instance is run by and for marginalized groups.

    • If I see slur usage: is there plausible deniability for the slurs to be used in a reclaimed context, or for the users in question to not be native speakers? Glossing over this once earned a subsection in my blocklists’ “Mistakes Made” section.

    • If there’s harassment, I might want to check in with the victim to see if it’s okay to save a receipt featuring them and if I should make a callout.

    • Do staff members run other instances? I could treat all their instances collectively.

    Minor factors that do not directly inform the decision to defederate, but do inform the decision to look deeper before dismissing the instance:

    • Is the instance staff close to sufficiently bad actors? If so, the staff members almost certainly post similar content. It’s worth the extra time to find the receipts.
    • If the instance is brand-new, I might re-visit it in a week or two to see if it cleaned up.

    Steps I perform:

    • Save receipts with multiple archiving services. Sometimes one service doesn’t render an archive properly, so it’s good to have alternatives.
    • Describe reasons with those links, and make it detailed enough for readers to understand the reason without visiting any links. Archived links are for proof more than understanding.

    I don’t consider whether the domain is still alive, assuming I have receipts saved from when it was online. Dead instances do sometimes come back, and blocking dead instances is harmless.

  28. Noted by . Last updated .

    Fedora is a stable distro now, with three levels of pre-release: Rawhide is unstable, Branched is sort of like an alpha release, and Beta is for early adopters.

    Fedora is just semi-rolling, with a combination of soft-frozen and rolling packages. Each release gets just over a year of support, so you can double-upgrade on alternate releases if you wish.

    It’s obviously no Debian but it’s not the bleeding edge distro it once was. Each release has the latest toolchains and runtimes but it’s not generally as bleeding edge as e.g. Arch.

    Strictly speaking, Fedora stable releases technically aren’t even upstream RHEL anymore; CentOS Stream pulls right from Rawhide.

  29. Noted by . Last updated .

    WCAG 2.2 removed SC 4.1.1, Parsing (Level A). I maintain that valid markup has important benefits despite no longer being required. We may find it possible to write good software without static analysis, construct a building without blueprints, or make an accessible website without validation. They remain good practices.

    WCAG’s normative text describes outcomes, not how to achieve them. Validation is but one part of the process of achieving the necessary outcomes.

    Let’s not interpret the removal of SC 4.1.1 as permission to ship known errors.

  30. Noted by .

    I propose an alternative to the Dead Internet Theory called the Living Dead Internet Theory, an exaggerated version of my actual beliefs:

    1. Any content written to optimize against algorithmic curation is as bad as algorithmically generated content.
    2. Algorithmically-curated content is disproportionally biased towards content optimized for said algorithm.
    3. The most accessible content might as well be written by bots.

    Don’t use short-tail search queries for discovery.

  31. Noted by . Last updated .

    Interesting proposal! Some thoughts:

    • I’d suggest looking into the doc-notice, doc-tip, and doc-example DPUB-ARIA roles. I’m a big fan of DPUB-ARIA and I do not think it is used enough. I believe Google’s Talkback has the most robust support for it put of any AT I’m familiar with.

    • I’m not convinced that a cot element is necessary. I think a heading with aria-labelledby would work better as a way to name a callout, and an attribute (or DPUB-ARIA role) could better specify the type of callout.

    Funnily enough, I’m thinking about my own proposal for a spoiler element which also has similar structure to—but different semantics from—the details element.

  32. Noted by .

    It’s hard to target browsers’ secure profiles. Safari’s Lockdown Mode disables a dozen or so APIs and a handful of other features; the Tor Browser disables another handful of features; Microsoft Edge will likely land more changes to Enhanced Security mode in the coming years. Barely any of this is documented.

    I filed a bug in MDN’s BCD tracker to fill this gap, listing what I knew. We can’t expect developers to navigate the dozens of WebKit blog posts and Tor Browser JSM files to figure out which features are disabled. Of course, progressive enhancement should be the norm, but it’s helpful to have a real baseline.

  33. Noted by .

    These addons work by injecting or altering stylesheets in the page, and are trivially detectable. A good rule of thumb is that if it can trigger a CSP violation in the developer console, it is trivial to detect with JavaScript.

    (FWIW: I believe the Tor Browser does disable the Reporting API, so I think some JavaScript will be necessary).

    On “safest” mode with remote JavaScript disabled, certain “dark mode” addons might be safe. I think a better long-term solution would be the ability to “freeze” a page: a button or something to prevent the current page from initiating further requests (it’s already loaded), running scripts, accessing storage, etc. In this state, a user could use any addons or fingerprinting-compromising settings without risk.

    A good point of comparison is Reader Mode: a user’s preferred Reader Mode fonts, line-width, color scheme, etc. aren’t fingerprinting vectors. It should be able to stop a site from phoning home or writing to client-side storage to allow for similar levels of customization outside Reader Mode.

    Other sources of inspiration could be the expected behavior for the scripting: initial-only media query, and Firefox’s built-in “Work Offline” setting.

  34. Noted by . Last updated .

    De-facto standard extensions for recursion and variable-length look-arounds have existed for ages; the word “regular” in most regular-expression engines is there for historical reasons. I first read about this in by (he loves his biblical terminology).

    I would like to just use Raku rules for a concise way to describe more advanced grammars; I’d then just keep my regexes to the PCRE subset that’s common between Google’s RE2 and the Rust regex crate. I doubt they’re both “regular” but both guarantee linear time matching. Part of the reason I don’t do this is portability. Not everything runs Raku, but almost every platform has a regex engine with the features I need.

  35. Noted by . Last updated .

    There is no such agreement on the web:

    • On the users’s end, we don’t have advance notice that a link destination will contain malware (such as ads). The page has already downloaded; the content is already on our device before we agreed to anything. We were handed the goods and only told they had a price after leaving the store.
    • On a site owner’s end, Terms of Service should not a shield to enable discrimination. ToS that discriminate against marginalized groups have historically warranted civil disobedience and lawsuits ending in legal reform that outlawed such practices; why should ToS discriminating against neurodivergent users be any different?

    I have ADHD and overstimulation sensitivity. Requiring me to view ads is discriminatory. So yes, I would violate the fuck out of such a ToS with a clearer conscience than the site owners, and side with the plaintiffs should the site ever face an accessibility lawsuit.

  36. Noted by .

    CNET actually didn’t have to delete old articles to improve ranking. If CNET simply removed those articles from its sitemap, used WebSub to inform Google (and IndexNow to inform Bing, Seznam, and Yandex) of new higher-priority pages, and maybe used robots.txt to disallow crawling of stale pages: CNET could keep old content but prioritize the crawling of recent content. Nothing I just described is Google-specific; these are all agreed-upon standards that work across several search engines.

    I suppose it’s easier to just delete pages, though. Less labor means fewer expenses. After all, this is the outlet that cut costs with algorithmically-generated articles.

  37. Noted by .

    I just tried Chromium’s “Screen2x” article distiller (experimental in chrome://flags).

    Before, the DOM Distiller removed elements far too aggressively. The new Screen2x implementation has gone in the opposite direction: it barely removes any of the page’s non-navigation structure. It does, however, remove all the images. figure elements that aren’t images (e.g. block-quotes with citations in figcaption children, or code snippets with descriptions in their captions) lose their captions. Inline code and samp elements lose their semantics and styling, becoming plain inline text (code blocks in pre blocks remain preserved).

    In other words, it’s replaced one set of false-positives with another, and now removes too little of the page structure. An improvement, but not enough to compete with alternatives.

    Reading Mode now opens in a sidebar on desktop, instead of replacing the page. Users are expected to use the Reading Mode and the regular page side-by-side now, so it won’t replace ads. I smell infighting between ads and browser teams.

  38. Noted by . Last updated .

    I’m a browser “with the latest in header compression”, fetching a web page. I race a TCP-based ALPN run against an HTTPS record lookup (Chromium’s behavior). Either the HTTP/2 ALPN wins the race, or the HTTPS DNS record does not exist. Both are, and will remain, common scenarios. So I fetch the page over HTTP/2. This is the initial request; dynamic HPACK hasn’t kicked in. I download a 1.56kb HTTP response header:

    Permissions-Policy: accelerometer=(),ambient-light-sensor=(),attribution-reporting=(),autoplay=(),battery=(),bluetooth=(),browsing-topics=(),camera=(),ch-device-memory=(),ch-downlink=(),ch-dpr=(),ch-ect=(),ch-lang=(),ch-partitioned-cookies=(),ch-prefers-color-scheme=(),ch-prefers-reduced-motion=(),ch-rtt=(),ch-save-data=(),ch-ua=(),ch-ua-arch=(),ch-ua-bitness=(),ch-ua-form-factor=(),ch-ua-full=(),ch-ua-full-version=(),ch-ua-full-version-list=(),ch-ua-mobile=(),ch-ua-model=(),ch-ua-platform=(),ch-ua-platform=(),ch-ua-platform-version=(),ch-ua-reduced=(),ch-ua-wow64=(),ch-viewport-height=(),ch-viewport-width=(),ch-width=(),clipboard-read=(),clipboard-write=(),compute-pressure=(),conversion-measurement=(),cross-origin-isolated=(),direct-sockets=(),display-capture=(),document-domain=(),encrypted-media=(),execution-while-not-rendered=(),execution-while-out-of-viewport=(),federated-credentials=(),focus-without-user-activation=(),fullscreen=(),gamepad=(),geolocation=(),gyroscope=(),hid=(),identity-credentials-get=(),idle-detection=(),interest-cohort=(),join-ad-interest-group=(),keyboard-map=(),local-fonts=(),magnetometer=(),microphone=(),midi=(),navigation-override=(),otp-credentials=(),payment=(),picture-in-picture=(),private-state-token-issuance=(),private-state-token-redemption=(),publickey-credentials-get=(),run-ad-auction=(),screen-wake-lock=(),serial=(),shared-autofill=(),shared-storage=(),smart-card=(),speaker-selection=(),storage-access=(),storage-access-api=(),sync-script=(),sync-xhr=(),trust-token-redemption=(),unload=(),usb=(),vertical-scroll=(),wake-lock=(),web-share=(),window-placement=(),xr-spatial-tracking=()

    Now, through Alt-Svc or an HTTPS record lookup, I discover HTTP/3 support. I download a render-blocking asset over an upgraded HTTP/3 connection. This is the first HTTP/3 request; dynamic QPACK compression hasn’t kicked in. I download a 1.56kb HTTP response header:

    Permissions-Policy: accelerometer=(),ambient-light-sensor=(),attribution-reporting=(),autoplay=(),battery=(),bluetooth=(),browsing-topics=(),camera=(),ch-device-memory=(),ch-downlink=(),ch-dpr=(),ch-ect=(),ch-lang=(),ch-partitioned-cookies=(),ch-prefers-color-scheme=(),ch-prefers-reduced-motion=(),ch-rtt=(),ch-save-data=(),ch-ua=(),ch-ua-arch=(),ch-ua-bitness=(),ch-ua-form-factor=(),ch-ua-full=(),ch-ua-full-version=(),ch-ua-full-version-list=(),ch-ua-mobile=(),ch-ua-model=(),ch-ua-platform=(),ch-ua-platform=(),ch-ua-platform-version=(),ch-ua-reduced=(),ch-ua-wow64=(),ch-viewport-height=(),ch-viewport-width=(),ch-width=(),clipboard-read=(),clipboard-write=(),compute-pressure=(),conversion-measurement=(),cross-origin-isolated=(),direct-sockets=(),display-capture=(),document-domain=(),encrypted-media=(),execution-while-not-rendered=(),execution-while-out-of-viewport=(),federated-credentials=(),focus-without-user-activation=(),fullscreen=(),gamepad=(),geolocation=(),gyroscope=(),hid=(),identity-credentials-get=(),idle-detection=(),interest-cohort=(),join-ad-interest-group=(),keyboard-map=(),local-fonts=(),magnetometer=(),microphone=(),midi=(),navigation-override=(),otp-credentials=(),payment=(),picture-in-picture=(),private-state-token-issuance=(),private-state-token-redemption=(),publickey-credentials-get=(),run-ad-auction=(),screen-wake-lock=(),serial=(),shared-autofill=(),shared-storage=(),smart-card=(),speaker-selection=(),storage-access=(),storage-access-api=(),sync-script=(),sync-xhr=(),trust-token-redemption=(),unload=(),usb=(),vertical-scroll=(),wake-lock=(),web-share=(),window-placement=(),xr-spatial-tracking=()

    I’ve burned 3.2kb on what may be a small page, for one header. Rendering hasn’t started yet. Add headers this is meant to complement (Document-Policy, CSP, etc.), all with an expanding list of directives, and header size becomes a problem. This is before we consider clients that lack HPACK/QPACK support (nearly all HTTP libraries I’ve used), or resources on other domains.

    CSP had a good solution: grouping the fetch directives that existed at the time under default-src. Similarly, we can try defining a large set of permissions to group under one directive. Every few years, we could add a new meta-directive to keep forward- and backward-compatibility while also keeping header size from growing out of control.

  39. Noted by .

    The Open-Source Initiative (OSI) is planning to form a definition of “Open Artificial Intelligence” (not to be confused with OpenAI, a company selling proprietary autocomplete software whose technical details only grow less open with each iteration). Unfortunately, odds of the definition requiring the release of training data are slim: the OSI’s executive director isn’t keen on the idea himself.

    I see libre/open-source software as a means to reduce dependence on a vendor, and mitigate the risk of user domestication. As long as training data is out of the community’s reach, it’s impossible for the vendor to be replaced. Yes, it’s possible to customize or re-train the model, but the vendor remains in control of its future development.

    Recent decades have tested the effectiveness of liberating source code as a defense against user domestication, as I explain in another blog post. But to re-define Open Source to allow labelling a model that is impossible to competitively fork would be to miss the whole value of FOSS in my eyes: to allow users to own not just their tools, but those tools’ futures.

  40. Noted by .

    Why is my site’s markup polygot XHTML5? I have had to deal with some really awful user-agents:

    • Bespoke markup parsers in RSS readers.
    • Link previews in obscure messaging apps.
    • A reader-mode bookmarklet-turned-browser-extension that hasn’t been updated in twelve years.
    • Various search engines trying to parse the page without using a compliant parser.

    Most of my issues were solved by running my generated markup through both xmllint (XML syntax) and the Nu HTML Checker (HTML5). Optional elements tend to cause issues the most.

    Overly-aggressive validation tends to spot latent bugs. Even if something is valid without an optional closing tag, I may have meant to include one in my templates. If that becomes an issue when I change something else later, it’ll be hard to track down the bug when it passes more lax validation.

  41. Noted by .

    We need semantic markup for sarcasm for the best of both worlds! Style sarcasm with CSS and have your client/browser indicate it to you however you prefer.

    The WAI-Adapt task force at the W3C is working on the to, among many other things, annotate in markup the literal interpretation of metaphorical statements, jokes, and sarcasm so you can style and switch between them. Lots of planning, vocabulary, and proof-of-concept work is done. It’ll take some years for real implementations to roll out and for it to mature; implementation-wise, they’re focused on really basic stuff like adding an attribute to HTML.

    Spending time on an HTML attribute sounds petty but this is the HTML Standard we’re talking about! Every browser, e-reader, screen reader, tutorial, course, Samsung Smart Fridge (ok that last one was a joke), etc. will have to support it forever. It takes time to figure out what to do so it doesn’t have to get re-done.

    Once that happens, we’ll need authoring tools to let people annotate sarcasm and such before posting. We’ll need to normalize a “write then edit” workflow, where “edit” includes adding alt-text, semantic tone indicators, content-warnings, etc.

  42. Noted by . Last updated .

    I don’t want my content on those sites in any form and I don’t want my content to feed their algorithms. Using robot.txt assumes they will ‘obey’ it. But they may choose not to.

    So you’d like to block the scrapers used by some large companies, most of which appear well-behaved (i.e. they observe robots.txt and noindex directives). Some organizations disclose IPs they use, but you are banking on their honesty.

    If we assume that trillion-dollar organizations are dishonest about how they scrape: they can spoof their user-agent, TLS fingerprint, IPs, etc. and use a headless browser very easily. There isn’t really a way to protect yourself from this without also excluding real users (e.g. invasive/inaccessible CAPTCHAs for which workarounds exist).

    They can get your content without scraping by downloading other data sets like the Common Crawl (Google did this for Bard), purchasing data sets from other vendors, or acquiring other companies with their own indexes.

    The alternative is to assume they’re at least somewhat honest about scraping content. If you use a noindex robots directive in your markup and HTTP headers but allow crawling, their crawlers will visit but won’t index your site no matter what user-agent or data set they use. Check their webmaster documentation to double-check their support for these features.

  43. Noted by .

    When I use my legal rights to request an organization to delete my data…

    1. Do they also un-teach their ML models everything they learned from my data?
    2. Can they infer the missing information from that model without storing it?
    3. Do they also have data that isn’t currently attributed to me, but can be attributed to me in the future?

    These are rhetorical questions because you can probably guess the answers. Simple data deletion is a cop-out from the impossible task of un-learning. Consent isn’t as meaningful if it isn’t fully revocable.

  44. Noted by .

    When I talk about website accessibility, I think a lot of people get stressed out and wonder if their personal site passes a really high bar. Some feel pressure to pass every single accessibility requirement they can.

    Take a deep breath.

    Your beautiful hand-coded personal site is probably better than the vast majority of sites I’ve complained about. Do not feel ashamed of what you’ve made. You’ve built your own pedestal to share yourself with the world, and nothing I say can take that from you because it is yours.

    Trying to pass WCAG guidelines is a really noble goal, but don’t make it turn your personal site into a source of panic and stress. Take things slowly. Look at one criterion a day. One criterion a week. Ask people for feedback instead of doing it all on your own.

  45. Noted by .

    Everything about Brand Indicators for Message Identification (BIMI) feels so half-baked.

    Lukewarm take: BIMI should mandate DMARC with DKIM and just ignore SPF. It could also require supporting TLS 1.3+. After all, one of the stated goals of BIMI was to increase adoption of better email standards like DMARC. This could have entirely prevented recent spoofing issues.

    Putting the HTTPS URL of an SVG icon in a new DNS TXT record to associate a whole domain with a logo makes no sense. Several better standards exist for associating a user@domain with an image, allowing different logos for different emails at the same domain. Webfinger and Libravatar come to mind.

    Hell, even its special SVG Tiny Portable/Secure standard could be simplified further. usvg can convert nearly any SVG to a tiny subset of the SVG Tiny P/S standard while preserving their appearance.

    Of course, none of this is too relevant to the BIMI group. The real purpose of BIMI was always to give certificate authorities a new source of income after their losses from Let’s Encrypt’s (lack of) pricing, the rise of ACME-based automation, and browsers’ deprecation of EV features.

  46. Noted by .

    I don’t think trademarks are, in principal, evil. But anything that has billions of dollars riding behind its ability to get twisted out of proportion will be ruined.

    Trademarks are like a cross between a signature on an art piece, or a regulatory badge. They tell you where something’s from and who said it meets their standards, but are only relevant if the issuer doesn’t let others issue it. The trademark itself ideally isn’t much of a creative work, so managing it doesn’t stifle much creativity.

    But then fictional characters became brands, and their likenesses started getting trademarked to create overlap with copyright; this formed the foundation of modern media franchises, and everything went to hell. This is part of why I’ve grown a wary of official brand mascots in general.

  47. Noted by .

    I’ve previously been an advocate of making websites with long-form body text increase the default size just a bit, since their text should be larger than the one-size-fits-all browser default; interfaces and navigation can be smaller. I didn’t think we should expect users to change their default zoom levels, as that’s a potential JavaScript-free fingerprinting vector.

    I’m thinking about revising this stance after using increased display zoom levels on mobile OSes for several months; with those modes, sites with large text are irritating to read: one line of text can barely fit a few words. Browser zoom increments are coarse, possibly forcing readers to choose between “too large” and “too small”.

    I removed the base font-size settings from the seirdy.one stylesheet (Codeberg mirror), and I made sure that my stylesheet and meta tags don’t result in any requests influenced by zoom level. While having to increase the zoom level may inconvenience readers who prefer large text, it should also make the site massively more convenient to readers with increased display zoom levels. I’m open to feedback.

  48. Noted by .

    Federation is a revocable privilege contingent upon instance staff maintaining a community that other instances feel safe connecting to. If staff fails to meet that obligation, the privilege is revoked. This allows moderation to scale across millions of users.

    If users are unhappy with their social circle getting broken, they should demand better from their admins or choose an instance that aligns with their values.

    Instances aren’t just infrastructure and vanity domain names: they’re the building blocks of communities, and their moderation actions—including defederations—are affirmations of shared community values.

  49. Noted by .

    instant.page (mentioned in another response) is popular, but it’s not the only game in town. Google Chrome Labs made an alternative called quicklink which also attempts to optimize CPU time by preloading in-viewport pages during idle time. instant.page generally expects you to be using a mouse; results on touchscreens are pretty minimal and probably not worth the extra JS.

    Speculation rules are being standardized for a JavaScript-free alternative. Figuring out which pages to preload will be the hard part. I like this because it’ll be easy to globally disable the behavior if I need to save data (or if it helps reduce fingerprinting).

    If your backend isn’t too slow and your payload is small, simpler optimizations are probably better.

  50. Noted by .

    I added an entry to my robots.txt to block ChatGPT’s crawler, but blocking crawling isn’t the same as blocking indexing; it looks like Google chose to use the Common Crawl for this and sidestep the need to do crawling of its own. That’s a strange decision; after all, Google has a much larger proprietary index at its disposal.

    A “secret list of websites” was an ironic choice of words, given that this originates from the Common Crawl. It’s sad to see Common Crawl (ab)used for this, but I suppose we should have seen it coming.

    I know Google tells authors how to qualify/disqualify from rich results, but I don’t see any docs for opting a site out of LLM/Bard training.

  51. Noted by .

    This is so similar to my setup! I run Stylelint and v.Nu too. I send v.Nu output through a JQ filter to filter out false-positives (after reporting them upstream); you might eventually do something similar, since there are a lot of these. Your blog post reminds me that I need something better than regex substitutions for customizing footnote and section links; Hugo’s parallel nature prevents it from doing post-processing of fully-assembled pages. Other tools I use:

    • xmllint to validate that the markup is well-formed XHTML5 syntax; it runs much more quickly than v.Nu and does light auto-formatting, but is also more limited.

    • There’s also a W3C feed validator written in Python worth checking out; I send my Atom feeds through that.

    • I run axe-core, IBM Equal Access checker, and Webhint on every page with headless browsers.

    • In the future: I’ll need to figure out a good workflow for easily validating JSON according to a schema, and adding some Microformats + Microdata validation too (maybe using Schemara?).

    The whole thing takes several minutes to run, so I don’t run it every commit; just building my site (no linting or validation) requires only a tarball with some statically-linked binaries. It’s more in line with the “built to last” philosophy; I’m curious if you have any thoughts about it.

  52. Noted by .

    Here’s a compiler flag that slipped my notice: Clear Linux has -fzero-call-used-regs=used in its CFLAGS for security-sensitive x86_64 packages, wiping call-used registers on return to protect against ROP exploits. In my benchmarks, there was almost no perf difference between skip, used-gpr and used which is surprising; I thought that this would really hurt instruction cache optimization.

    Either optimizing compilers have rendered even more of my coursework on computer architecture unusable, or there’s a reason why this is x86_64-only (I’m only familiar with RISC).

    Anyway: Alpine’s Clang-16 seems to have finally implemented this GCC-11 feature (it was supposed to be in Clang-15), so I can use it in my build scripts. Now seirdy.one is now served with an Nginx built with fzero-call-used-regs=used-gpr (including all linked libraries). Let’s see if I notice a difference. If I don’t, I’ll switch from used-gpr to used and repeat.

  53. Noted by .

    To limit ossification, Mozilla and Google have begun randomizing the order of TLS ClientHello extensions (as of Chromium 110 and NSS 3.84).

    I see this as a nice temporary solution to limit ossification introduced by corporate (in)security measures and middleboxes, but I’m not too optimistic about its impact on the CAPTCHA hell brought about by TLS fingerprinting. Increasingly, it looks like hosting providers will just treat any statistical anomalies in their logs as hostile traffic; any variance is a cause for suspicion, when it should be treated as an invitation to make sites more robust and compatible with different user agents. I don’t see Google rolling out more aggressive measures since it likely leverages similar approaches for click-fraud detection.

    Current approaches to click-fraud- and bot-detection encourage homogeneity, and thus user domestication.

  54. Noted by .

    Indexing Fediverse posts should be “mandatory opt”, not opt-in or opt-out. Account creation should offer a few checkboxes: indexing could be done by “your instance”, “all federating instances”, and “traditional search engine crawlers”; for each of these, users should be able to choose “none”, “public posts only”, and “all”. Alternatively: there should be a “discoverable” post visibility option that opts you into more advanced discovery options like search or appearance in “trending”.

    An instance indexing its local users is fine if they were told about it before signing up, so they could weigh that into their decision to pick that instance. It still needs to be a user-configurable toggle, since consent should be easily revocable without requiring a full migration.

    I think hashtags are intended as a way to opt-into being searched for by specific terms only, so advanced hashtag search (e.g. hashtag1 AND hashtag2, (hashtag1 OR hashtag2) AND NOT hashtag3) should be fine.

  55. Noted by .

    Making links recognizable in ways besides color is a basic accessibility requirement; in body text, underlining them makes their starting and ending locations obvious. I’ve recently decided to make a very personal exception:

    Wikipedia articles are full of interesting links. While this is great for letting me discover new topics, the links tend to let my ADHD take the wheel. Speaking strictly for myself: removing link underlines on Wikipedia articles actually improves accessibility. De-emphasizing links helps me stay focused on the current article.

    I think this speaks to the need for customizability by end-users. Users should be able to dictate link appearance, and pages should be robust enough to handle these changes. Of course, this is a bad idea in a world with JavaScript enabled by default (and with an ever-growing number of poorly-documented client hints) because it will only increase fingerprinting. This is why we can’t have nice things.

  56. Noted by . Last updated .

    Designing tools to make people feel convenienced (the opposite of inconvenienced) is sometimes different from designing tools to make people’s lives better.

    ChatGPT is very useful for tasks such as re-phrasing ideas and coherently assembling scattered thoughts, assuming that’s the sort of thing you’re willing to outsource. But current language models are detrimental for ideation: they’re designed to generate the least interesting, most obvious response to a prompt. That’s not my opinion; the GPT family of language models analyzes patterns in language, and generates predictable outputs. It’s often “correct” when a correct answer is the most predictable, least noteworthy response. Unfortunately, it’s often convincingly incorrect: it even defends wrong answers.

    Use it to think, and your ideas will be disposable. Don’t live your life by a model with billions of parameters optimized to help you be as predictable as possible. It’s the equivalent of sending your thoughts through a smoothing algorithm that treats interesting ideas as anomalies.

    People have worried about certain trends in investor-backed technology helping normalize helplessness to create captive consumers ripe for domestication. This is the logical conclusion of that process. Language models are often developed by and for companies who sell access to the means to change preferences at scale. What happens when people ask such a language model for its preferences?

    Use ChatGPT as a cop-out. Sometimes, it’s okay to cop out. But don’t cop-out of what you love to do, or want to do well.

  57. Noted by . Last updated .

    How does Warp stack against other toolkits when it comes to accessibility and system integration?

    In my system settings I set colors, default fonts (with fallback and hinting settings), animation preferences (reduce/eliminate animations), disable overlay scrollbars, set buttons to include text where possible, enable dark mode, configure keyboard shortcuts, and sometimes enable a screen reader. Windows users can enable High Contrast Mode to force their preferred palettes. To what degree will this toolkit respect these settings?

    On Linux: the only options I know of with decent system integration, accessibility, and some presence outside the Freedesktop.org ecosystem are are Qt, GTK, and the Web. Flutter falls flat, with outstanding WCAG level A blockers like functional keyboard navigation and basic levels of customization (e.g. disabling animation); relevant issues typically get de-prioritized. This is despite its massive funding and development efforts, so I’m not optimistic about other contenders.

    AccessKit looks like a start for cross-platform interoperability between accessibility APIs. Until it’s ready, support for each platform’s accessibility APIs and screen readers will need to be implemented and tested. It’s a monumental task. I worry that releasing yet another inaccessible toolkit will merely increase the disability gap.

  58. Noted by . Last updated .

    I just discovered Yuescript, which is like MoonScript with more features. I have mixed feelings.

    I like features like pipelines (much cleaner than repeated assignment or nested parentheses in function calls) and compile-time macros. The sugar for multiple and destructuring assignment is handy.

    I find the additional operators unnecessary, and not worth their cognitive overhead. It re-uses some operators for different purposes, creating confusion. The [] operator could easily have been a function in a library instead.

    One of the trade-offs for this much syntactic sugar is some syntactic ambiguity. An opinionated formatter could resolve some of this.

  59. Noted by .

    MoonScript (a language with a CoffeeScript-like syntax that transpiles to Lua) continues to be the most enjoyable programming language I have ever used.

    It’s not the most practical choice for everything; I probably would choose something else for a big collaborative project. But it’s an absolute joy to use something that truly feels like “executable pseudocode”, like a simpler Python alternative with a bias towards functional programming. If you can grok Lua’s “tables for everything” model, then the MoonScript language guide should help you pick up the language in minutes.

    If we had a “gradually typed” MoonScript to target Luau instead of Lua, I’d probably use it for everything.

  60. Noted by . Last updated .

    I do find their decision to drop JPEG-XL from Chromium problematic because it was clearly an example of them ignoring everyone else, showing the limits of Chromium’s collaborative decision making. However, “pushing their own formats” wasn’t one of their reasons:

    • Google also dropped plans to make its WebP2 project a real image format at around the same time
    • Google helped define the JPEG-XL spec
    • Google developed the Butteraugli project, which was incorporated into JPEG-XL
    • The reference implementation (libjxl) is mostly a Google project

    Google is a big part of JPEG-XL, yet Google dropped it along with its own WebP2 a while after seeing AVIF gain widespread support.

    I previously shared my thoughts on the issue in this post: Google drops Webp2 and JPEG-XL.

  61. Noted by .

    Going forward, the CSS Speech Module seems like a better place for auditory tonal indicators. The CSS we’ve already had for years should be a better place for visual presentation.

    This leaves only a minuscule semantic difference between <i> and <em>, or <b> and <strong>, as outlined in the HTML Living Standard. I don’t think that difference warrants extra elements in the HTML standard: the extra elements likely create more confusion than actual benefit. Over the past decade, I’m unaware of any user-agents treating them differently enough, in a way that aligns with author intent, to matter.

    I personally just avoid <i> and <b> when authoring. The complexity is more trouble than it’s worth.

  62. Noted by .

    I encourage people who fetch my keys to verify over multiple bands; for instance, they can fetch it over both Web Key Directory and DANE. They can also use something like Keyoxide to verify that it is associated with many other online accounts, perhaps including the account I was using when I first met that person. The later isn’t exactly verifying “out of band”, but it’s super helpful.

    If you’re willing to do some of that (a big “if”: good communication protocols should make key exchange easier than this), then I’d argue that the initial leap of faith associated with Trust-On-First-Use (TOFU) is mostly a non-issue. However, PGP has its own larger set of issues that make it a poor candidate for communication protocols (complexity/configuration-hell with too many footguns, no forward secrecy, long-lived secrets, etc).

  63. Noted by . Last updated .

    I see a lot of discussion about the fear that corporations and VCs will take over the fediverse. The thing is, Mastodon going mainstream will require a lot of capital and development of new products and innovations for this ecosystem…Let’s also allow VC-backed startups to flourish building services for all of us.

    This isn’t Silicon Valley. We’re not trying to “innovate” or “scale” or “go mainstream”. We’re avoiding that culture. Granted, most of us aren’t opposed to the idea of going mainstream, but we’re not chasing that goal for its own end.

    The kind of growth I’m interested in is being welcoming to new marginalized users (e.g. those from BIPoC, neurodiverse, and queer communities). Venture capital, however, chases growth for a return on investment; this isn’t guaranteed to be in alignment with the extant community’s goals, and will likely come in conflict with time. The history of every “successful” VC-backed social media platform to date (Reddit, Twitter, Facebook, TikTok, etc) says as much.

    The protocols are open; you’re free to do what you will. I only ask that you loudly announce all instances run by people subscribing to your vision whenever you find them, so we can contain the spread.

  64. Noted by . Last updated .

    I run Lighthouse and WAVE as a “Hey, let’s see what I have ahead of me” kind of thing. A baseline of sorts. Then I go into manual testing

    I strongly disagree with running automated tests first if you have the means to do manual tests. People get too hung up on automated tests revealing only N percent of issues; the reality is that they end up encouraging people to spend their time fixing those issues instead of more critical errors.

    Less than a minute with the “inspector” tool in most browser DevTools (not even the Accessibility Inspector!) will quickly reveal poor use of semantic HTML, poorly-written alt-text, site titles that shouldn’t be headings, non-descriptive names, and conflation of semantics with presentation. Fixing these is probably a better use of your time than hunting down every duplicate link name in a page that an automated checker finds.

    I prefer running an automated checker after catching low-hanging fruit manually.

  65. Noted by .

    The fact that I have to have a full WebKit process and actual JS running just to view an EPUB is really infuriating.

    Can’t anything just be a ruddy DOCUMENT format anymore‽

    To be fair: EPUB is actually a good use-case for semantic XHTML5, WAI-ARIA, DPUB-ARIA, MathML, and RDF serializations. This does call for some sort of web engine, but not necessarily a complete browser engine capable of running web apps.

    Most of the rest of the Web platform beyond semantic markup and simple stylesheets should probably be stripped away from a typical EPUB reader. Unfortunately, few “slim” engines actually support enough of the features I described. Engines like Ultralight (proprietary) and litehtml come to mind, but I don’t know how good the latter’s accessibility support is.

    I very much agree that JavaScript support in EPUB was a mistake; fortunately, it’s seldom necessary. Signed JIT-less JavaScript as part of the e-reader program should be okay, as the user consented to run it.

  66. Noted by . Last updated .

    You said something I’d like to draw attention to:

    I have been banned from LinkedIn temporarily myself 4 times for “looking at too many profiles”. It is in their Terms and Conditions that they can ban you for that.

    LinkedIn is aggressively anti-scraping for all the wrong reasons. Bing (obviously), Google, Yandex, and some others get preferential treatment; Microsoft is incentivised to keep the number of non-Bing web indexes low. Companies that are both search engines and platforms for user-generated content are incentivized to monopolize access to said content.

    Unfortunately, its anti-scraping tactics blow back on users whose behavior is not sufficiently different from scrapers. Users with unreliable connections, who open many pages in advance while good connection lasts. Spoonies who take the “open now, review later” route. Privacy-conscious users on anonymized connections. The list goes on. It’s funny how hoarding privilege tends to blow back on those without.

    A diverse group of users will browse in diverse ways. Normalizing that behavior has consequences that show how Microsoft’s pro-diversity messaging is, unsurprisingly, only as shallow as its bottom line.

  67. Noted by .

    This was originally a reply to another post. That post has been deleted.

    Can we agree to rewrite all the GNU utilities in Rust

    The advantage of POSIX coreutils is their portability and universality; I can expect them to be present on any POSIX system. If re-writing will sacrifice portability, we might as well do a clean break from POSIX and seek to improve upon existing coreutils rather than replace them. I listed some on my “uses” page: Zsh+DASH, ripgrep, sd, and fd. Three of those are written in Rust.

    release them with a better licence

    I actually do like copyleft for more substantial works. However, POSIX shell utilities have been implemented many times over: Busybox, Toybox, and FreeBSD utilities come to mind. The specific free license they use is no longer important.

  68. Noted by .

    There’s no real “recommendation algorithm” here. Mastodon 4.x has a “trending” feature, but that’s it.

    Users that your instance members follow have their content pushed to your instance, and their repeated posts reach your instance too. When content reaches your instance, you can reblog it to help it reach your followers’ instances.

    Federation is a privilege. If “Instance A” members repeat or reply to “Instance B” members, they increase Instance B’s reach. If Instance B starts using that reach for e.g. harassment: Instance A may revoke that privilege with a block, and members may make a FediBlock post to alert other moderators on other instances so they too may suspend Instance B. This reduces Instance B’s reach, protecting the people Instance B was harming.

    The Fediverse doesn’t have a “moderation committee”. Volunteer admins and moderators are supposed to moderate their own instances. When an instance is not moderated, it’s not other instances’ moderators’ jobs to moderate that instance. Instead, they just silence or block the instance.

    Hopefully that explains why people use the FediBlock hashtag.

  69. Noted by . Last updated .

    Last year, 37signals employees shared the “pyramid of hate” in a work chat in response to seeing a list of “funny Asian names” of customers. Upper management responded by banning discussion of politics at work (I presume “politics” means “anything that creates a sense of social responsibility beyond investor value”). Its handling of the situation caused a third of its employees to resign.

    However, I don’t think this policy is in effect anymore: 37signals leadership is using a company blog for railing against diversity and inclusion, and then doubling down after criticism. Is the “no politics” rule lifted, is upper management exempt, or does “no politics” only refer to politics that challenges David Heinemeier Hansson to change his behavior? I look forward to hearing a clarification on this rule.

    Update : tells me that this isn’t a company blog; however, I do think this likely reflects a current or future political stance from 37signals against diversity, equity, and inclusion.

    37signals is known for creating Basecamp, Hey.com (an email service with bespoke email filters that are somehow incompatible with IMAP), and for creating Ruby on Rails. It appears to remain a key member of the Rails Foundation. For now.

  70. Noted by . Last updated .

    The “Don’t Repeat Yourself” (DRY) principle is my main motivation for adding content to my site—especially to my “notes” section. I’ve gone as far as linking my own website in online class discussions (not as a citation; just for DRY).

    This also combines really well with the Publish on your Own Site, Syndicate Elsewhere (POSSE) principle. Often, a post of mine syndicates well to multiple destinations. I might reply to a forum on my site and syndicate it to both that forum and to the Fediverse. People reply in both places, and Webmentions aggregate them together on my site (though I often have to send myself those mentions). I only have to write something once.

  71. Noted by .

    I love this blog post. Thank you for writing it. I must add one thing: every accessibility audit needs to test with forced colors. Countless sites claim to be accessible but fail this basic check.

    For those less familiar: forced colors is a standard feature defined in the CSS Color Adjustment Module Level 1. It overrides colors with a user-preferred palette. Implementations include Windows High Contrast Mode and Firefox on all supported desktop platforms (I’m not sure about mobile).

    Forced colors reveals violations of the Web Content Accessibility Guidelines level A success criterion 1.4.1, Use of Color. I use forced colors in Firefox every day, and often face issues. For examples: see Can I Use issue 6527, or this Kagi search feedback

    Section 2.3 of the CSS Color Adjustment Module leaves much room for non-standard user-agent-specific behavior beyond the standard forced colors. Chromium, mobile Firefox, and Samsung Internet have their own “auto dark modes” which intelligently and selectively adjust colors on light-themed websites. Testing on all these configurations is hard; forced colors is a simpler, predictable place to get started.

  72. Noted by . Last updated .

    Synapse is incredibly slow, which is why I run the Conduit matrix server. Server performance is the main price paid for Matrix’ history replication.

    This also gives Matrix a spam DDoS problem: sometimes people mass-create accounts on hundreds of servers with open registration, and mass-join rooms. The flood of thousands of join-events will OOM most connected servers. My Conduit server (RocksDB backend, 1 vCPU, 1GB RAM) is actually fast and light enough to ride some of these out and go back to normal speeds a couple hours after the floods die down.

    You generally don’t want to join a room like Matrix-HQ unless you have good hardware. A new Postgres backend is coming to Conduit soon, which should improve the situation.

    Once Conduit implements a few missing features (federated backfill, spaces hierarchy and room discovery), and once better spam controls roll out (e.g. automatically restricting joins to under N per second and/or automatically blocking open-registration servers during high join frequencies), I’d say the worst performance problems will be gone.

  73. Noted by .

    I just learned that dedicated IndieWeb clients do exist! Sharing for those less familiar:

    Social readers fetch your feeds (RSS, Atom, h-feed, WebSub) from a MicroSub server and post replies to your site with MicroPub. Your site sends Webmentions. The result resembles the pre-ActivityPub, OStatus-based Fediverse but with single-user instances. RSS/Atom feeds for Fediverse accounts and POSSE connect the IndieWeb and Fediverse; alternatively, your site can implement both. POSSE’s advantage over PESOS is directing people towards your site, where they can see Webmentions from places besides their silo. It allows interoperability.

    I prefer the classic static site approach. I only need a static file server and a Webmention receiver; a post-push git hook sends Webmentions and semi-automatically POSSEs to the Fediverse. When I finally set up WebSub, it’ll ping my publisher. My approach slows me down enough to think through what I say. I want my site to feature my best content; my non-POSSE silo content should be more disposable or context-specific.

    I don’t have the context of everyone else’s tweets

    Reply-contexts help, but I prefer combining one-sentence titles with interleaved quoting.

  74. Noted by .

    This is an idea I’ve seen repeated before. I need to push back on it.

    Assistive technology (AT) interfaces with an operating system’s accessibility APIs. A browser converts the Document Object Model (DOM) into an assistive tree, and sends that to the OS accessibility API.

    Now, some screen readers actually do hook into the browser; NVDA does this with Firefox and Chromium. But this isn’t always the case. ATs need to crawl an accessibility tree for the entire desktop environment, and the browser is one of many windows present. They don’t just convert markup to text.

    A semantic screen-reader friendly site may look awful in Lynx. A Lynx-friendly site may have terrible semantics and navigate poorly in a screen reader. To work well in both scenarios, deliver content with semantic markup and make non-markup resources optional.

  75. Noted by .

    Progressive enhancement is a wonderful thing. I try to make sites usable in browsers of that era (with a TLS terminator) despite using several HTML 5 and bleeding-edge CSS features. Every feature possible should be progressive.

    Here’s the compatibility statement for seirdy.one

    I’m not asking anything too radical: when you want to use a feature, just try to make support optional. If there are two ways to do something, have a bias towards the older way. Without trying, you’ll get good support for these browsers and for extensions that modify pages.

    As a baseline, I recommend starting with the subset of the HTML Living Standard that appears in the abandoned HTML 5.1 standard. CSS should be optional. This tends to progressively degrade fairly well.

  76. Noted by .

    The Accessible Platform Architectures (APA) working group hopes to designate adapt- as a reserved prefix in HTML 5. You can read the draft proposal on the public-adapt mailing list.

    The “Adapt” family of specifications will allow pages to expose generic meanings behind elements, and allow users to “switch” these to versions they understand. A sarcastic sentence could have a literal alternative; words can be swapped with symbols. Like RDFa and Microdata, this will also allow authors to describe meanings behind page elements; unlike prior art, these meanings will be intended for humans and have close synergy with the surrounding markup.

    Personalization semantics make pages easier for users to understand, especially neurodivergent users. I like to think of it as primarily—but not exclusively—adding semantic meaning to the page rather than extract data from it.

    Enshrining this prefix in HTML could be a huge boon for cognitive accessibility and customization on the Web by hopefully guaranteeing much greater adoption.

  77. Noted by . Last updated .

    Large organizations’ choices influence my decisions in only one way: by telling me what users are familiar with. For instance: when building a search-results page, it might make sense to borrow the basic semantics of existing search engines (Google, Bing, etc.) so the interface is familiar.

    It doesn’t make sense to blatantly violate WCAG (especially at the “A” level!) just because big companies do. The companies you cite know they won’t get sued over link underlines, even though removing them without replacement is an accessibility hazard. Every time someone jumps onto Flutter because Google said it’s accessible, I feel tempted to file yet another accessibility issue.

  78. Noted by . Last updated .

    Speaking generally: I think most website security scanners (Webbkoll, Observatory, et al) lend themselves to cargo-cults. You don’t need most Content Security Policy directives for a PNG file, for instance. Warning against a missing X-Frame-Options feels wrong: even the latest version of iOS 9—the oldest iOS release to support secure TLS 1.2 ECDSA ciphers—seems to support frame-ancestors (correct me if I’m wrong).

    Internet.nl is a bit better: it doesn’t penalize you for not using security headers. Instead, it just educates you about why you should consider them. Internet.nl only penalizes you for lacking features that universally apply, like proper TLS. I also like the approach of ssh-audit: it lets you set a policy that works for your endpoint, and validate against that policy.

  79. Noted by . Last updated .

    Earlier this month, Google re-branded its WebP2 repository to clarify that WebP 2 will not be released as an image format.. This week, Google deprecated Chromium’s off-by-default JPEG-XL support, citing a lack of interest and improvement over existing formats. Most commits to libjxl, the reference JPEG-XL implementation, are from “google.com” email addresses; I imagine that this decision could impact libjxl development.

    I doubt we’ll be seeing new image formats on the Web for the next few years: there’s very incomplete JPEG-XL support in Firefox and Safari only just got AVIF support

    JPEG-XL and WebP2 would have been great for lossless compression. The best lossless compression we currently have is WebP-lossless, which doesn’t support e.g. higher color depths. For that, we’re stuck with PNG.

  80. Noted by . Last updated .

    Despite BoringSSL’s “not intended for general use” warning, it’s used by many projects:

    • The “ring” rust crate’s crypto primitives (used by Rustls)
    • Cloudflare: used everywhere, including Quiche.
    • Apple’s Secure Transport (it’s in both major mobile OSes!)
    • Optionally: Nginx, libcurl
    • (Update ) Apple’s SwiftNIO SSL
    • (Update ) AWS libcrypto is based on BoringSSL
    • (Update ) the Envoy proxy uses BoringSSL

    I use nginx-quic with BoringSSL without issue, although I did have to use a separate script to manage the OCSP cache. The script manages the cache better than Nginx ever did, so I recommend it; it should be trivial to switch it from OpenSSL to LibreSSL.

  81. Noted by .

    Assuming we have transit encryption, the main result of Border Gateway Patrol (BGP) errors is mass downtime. Downtime for a typical service is a headache; downtime for a CA can be disastrous. BGP hijacking also enables certificate mis-issuance by messing with weak domain control validation. Route authorization is an important mitigation!

    That said: TLS is our last line of defense against BGP attacks that re-direct HTTPS requests.

    Users wouldn’t have been robbed if Celer Bridge used HSTS preloading. Victims were greeted by a TLS error and chose to add a security exception; a payment platform shouldn’t offer that choice. HSTS instructs browsers to remove this option, and HSTS preloading prevents HSTS stripping (and TLS stripping).

    HTTP Public Key Pinning (HPKP) makes such attacks even harder, but HPKP had its own list of issues preventing adoption.

  82. Noted by .

    Three reasons to declare a font size in a page’s CSS:

    1. Not all browsers support all types of zoom (standard, pinch-to-zoom, and text-only zoom). Some mobile browsers still don’t support any type of zoom.

    2. Different use-cases call for different sizes. Long-form text should be bigger than text in user-interface controls.

    3. WCAG guidelines recommend sizing tap-targets to at least 44-by-44 CSS pixels, with the exception of inline links. Google recommends 48-by-48 CSS pixels, with no overlap across a 56-by-56 pixel range. Increasing my root font size makes non-inline links and buttons bigger.

    Combining the first and second points, we see that the base font size on the Web is not a “one-size-fits-all” solution. It’s now a reference point for relative font sizes (e.g. em, rem, percents). Relative font sizes scale with the base font instead of “overriding” it.

    My browser’s default size is perfect for a typical Fediverse microblog or information-dense discussion-forum, not for reading an article. My website’s stylesheet defines a font that is 9.375% larger than default, whatever that may be.

  83. Noted by . Last updated .

    Many open standards can support profile hydration:

    Ariadne
    Map an email identifier to supported verified accounts.
    The IndieWeb
    Map a webpage with h-card to any account. This can pair with other forms of authentication, such as RelMeAuth.
    WebFinger
    Map an email-like identifier (an acct: URI) to a list of links.
    vCard
    Mpload a vCard containing profile information, possibly with “share contact”.

    I think h-card-based hydration is the best place to start. We can later add support for more options:

    • Keyoxide profiles already contain h-card microformats, so we get that for free.
    • h-card microformats can have u-key properties, potentially triggering an Ariadne-based verification of accounts enumerated by the h-card.
    • h-card can map to vCard4

    Depending on how keyoxide-web issue 141 goes, WebFinger could also indirectly give Keyoxide support.

  84. Noted by . Last updated .

    SVCB DNS resource records (RRs) were introduced somewhat recently. They inform user-agents that a given resource exists at another endpoint, possibly with extra parameters. Functionality closely mirrors the Alt-Svc standard. A profile of SVCB exists in HTTPS RRs; Encrypted Client Hello and HTTP/3 are the main use-cases today.

    To give IPNS-accessible services familiar names, I think SVCB is a better long-term solution than DNSLink.

    A related issue for the InterPlanetary Name System is Issue 144 for the IPFS web browsers integration group; it discusses the viability of using Alt-Svc for this.

    Syndicated to the DNSLink discussion forum and the Fediverse.

  85. Noted by .

    I face lossy connections, and QUIC noticeably improves latency: connections establish in just one or zero round-trips and loss doesn’t cause as much re-transmission. Add forward error correction and QUIC makes lossy connections much less painful. This isn’t just for “adtech websites streaming video”: the biggest beneficiaries are networks like Matrix and XMPP.

    There are much bigger things to worry about regarding Google’s control of standards: advertising identifiers, high-entropy client hints, etc. all rolling out before the Privacy Budget is what I’d rather focus on. I think there’s a lot of misplaced negative attention on a transport protocol that gives tangible benefits to people with worse connections.

  86. Noted by .

    A rough timeline of QUIC support in OpenSSL-like libraries:

    1. BoringSSL implements QUIC.

    2. Quiche, a QUIC library, requires BoringSSL. Nginx can be patched to use Quiche for HTTP/3.

    3. Nginx’s experimental QUIC branch (nginx-quic) is released. It requires BoringSSL.

    4. Some organizations (mostly Akamai) fork OpenSSL to implement the BoringSSL QUIC API, calling their fork QuicTLS. They plan to upstream changes.

    5. nginx-quic supports building with QuicTLS too.

    6. OpenSSL decides against the BoringSSL API and declines QuicTLS patches, preferring to write their own incompatible implementation.

    7. LibreSSL implements the BoringSSL QUIC API.

    8. nginx-quic can link against LibreSSL as well as BoringSSL and QuicTLS; they all use similar APIs.

    (I believe wolfSSL is mostly compatible with the BoringSSL QUIC API, but I might be wrong.)

    Developers will have a harder time supporting multiple TLS implementations, hurting the viability of e.g. LibreSSL-based distributions.

  87. Noted by .

    Avoid kexec if you don’t need it: it opens new vulnerabilities, and is better left disabled for most use-cases. Redundancy and failover should eliminate the need when hosting a typical service. Even without the risks, there are other reasons to reboot: updates to shared libraries, SELinux policies, and init systems often warrant one.

    One use-case that benefits from kexec is pubnix systems with many logged-in users. If you need to apply an unscheduled security patch while causing minimal disruption, then live-patching makes sense.

    With some boot optimization, I can hit 99.9% uptime even if I reboot 2-3 times per week on Fedora. With failover, these reboots should have negligible impact.

  88. Noted by . Last updated .

    Here is how I propose browsers address web bloat:

    1. Stop adding features unrelated to accessibility, security, privacy, and internationalization.

    2. Adopt a default document policy that restricts oversized assets and download size.

    3. Make JIT-compilation a per-site opt-in permission. That should rein in over-reliance on JS.

    This should mostly contain the bloat problem without significantly inconveniencing most users, which is why it will never happen.

  89. Noted by . Last updated .

    Key management guides should also cover key distribution.

    Secure distribution happens over at least two bands with two different sources of trust. Having my own domain name lets me combine DANE (trust the DNS trust anchors) and Web Key Directory (trust the WebPKI and CA system). Clients can fetch keys both ways and ensure they match. Prospective senders may also request public keys over modern encrypted messengers.

    This guide covers the client side. Users need providers and name servers to adopt email security standards (DKIM, SPF, DMARC, ARC, DANE, MTA-STS).

  90. Noted by . Last updated .

    I know of two Intel ME rootkits that didn’t involve Intel AMT; the latter can be enabled/disabled on “vPro” chips. One rootkit was from 2009 and seems less relevant now; the more recent of the two was by and at Black Hat Europe 2017: (application/pdf).

    Without AMT, they required physical access. Most PCs are woefully unprepared against the sorts of attacks enabled by physical access, and ME is only one entry in a long list of issues.

  91. Noted by .

    in my opinion, self-signatures should have been treated as something normal, with a warning only triggered if the site has been visited before and the signing key has changed

    Two problems with self-signed Trust On First Use (TOFU):

    1. Long-lived secrets without a revocation mechanism. Current approaches—OCSP and client-side CRL checking—all use the certificate authority (CA) system.

    2. Zero defense against TLS stripping attacks during the initial connection. You need to know the connection is authentic without taking the response at its word.

    You could implement revocation with your own server, but stripping attacks make it absolutely trivial for an intermediary to compromise a connection. Your initial connection is as authentic as an HTTP site, and all subsequent connections are only as secure as your initial connection. Hostile networks are increasingly the norm, so this isn’t a solid foundation.

    A key-pinning system only works when backed by a separate source of trust. Examples include a CA or DNSSEC trust anchor (for DANE).

    Unfortunately, HTTP Public Key Pinning never took off since admin errors could irrevocably nuke a site, and browser devs don’t want DANE without pinning.

    banks and other sites needing higher-than-usual trust would still use authority-signed certificates

    I disagree that good security should be limited to “big important players” rather than being the default behavior. “Normal” sites often feature popular interception targets such as donation links, contact methods, log-ins, etc.

    If we’re going to get rid of the CA system, we should replace it first. Tor and Yggdrasil seem like interesting alternatives, though lacking domain names.

  92. Noted by .

    I have a few thoughts on these findings:

    1. The Almanac says skip links commonly skip to the <main> element; I consider large focusable containers an anti-pattern since they ruin keyboard navigability, and recommend skipping to a heading instead.

    2. The Almanac identifies accessible live regions by role="live". I’d suggest also looking into role="feed", which represents a common type of live region.

    Some common accessibility issues I’d be interested in for future editions:

    • Contrast that’s too high
    • Setting custom foregrounds but not custom backgrounds, and vice versa
    • Removing link underlines
    • Focusable containers
    • Using icon fonts without accessible names

    Overall, it’s a good look at the small subset of accessibility issues that are automatically detectable (most of which are far less critical than manually-detectable issues).

  93. Noted by .

    The most common and major accessibility (a11y) issues tend to be documented and well-known among a11y practitioners; however, “smaller” or “niche” issues (for lack of a better term) tend to go unnoticed. For instance, I recently learned that over-use of soft-hyphens can trip up the speech synthesis of the NVDA screen reader, and styling superscripts/subscripts a certain way can stop screen readers from announcing them. I also learned about how performance issues can cause delays in screen readers, making content exposed to screen readers fall out-of-sync with the actual page. We won’t learn about this in accessibility tutorials or W3C documentation! The only way to discover these issues is to use many screen readers for a long time.

    What are some accessibility hazards—or even mild annoyances—you experience, that you don’t think most a11y practitioners learn about? Is there a common annoyance you wouldn’t normally bring up because it seems “too minor”?

  94. Noted by .

    Compare the two scenarios:

    Scenario A: “We received a piece of user feedback to change this design to avoid errors; their suggestion was well received by other users. Let’s collect some telemetry from that component to see is these issues are representative of the larger population; based on that, we’ll know whether it warrants a re-design of that component.”

    Scenario B: “Telemetry says users never use this feature; we can remove it.”

    In Scenario B, telemetry prompted a decision; in Scenario A, telemetry helped understand a real specific problem. Telemetry should be used to clarify an existing insight rather than make discoveries on its own. Metrics should not be collected lightly; they should be collected with intention (and, of course, prior informed consent).

  95. Noted by .

    Assuming data is a liability, how limited should data collection be to not require consent?

    I think temporary storage (a week or less) of access logs combined with low-entropy binary information (dark mode, is viewport narrower than what I test with, etc) is reasonable for a small operation. This holds if the data collection is clearly documented in a privacy policy, is Tor-friendly, and obeys signals like GPC. These access logs should exclude high-entropy headers like client hints.

    Larger operations should store even less since they have the means to correlate information from many sources. ipscrub comes to mind.

    The only long-term storage that should happen without consent is of bot traffic.

  96. Noted by . Last updated .

    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.

  97. Noted by . Last updated .

    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 102 ESR 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.

    Update : since Firefox 102 became the latest ESR, over since Firefox 91 ESR reached end-of-life, the latest stable Tor Browser desktop release (11.5.8) is still based on Firefox 91 ESR. Five CVEs fixes from v102 were backported a while ago, and another 13 were backported this week; the situation is worse on Android. It’s reasonable to assume that v91 has issues of its own that won’t be addressed. Until the v102-based 12.x hits stable: if you don’t use “safest”, you might want to re-consider that with this information in mind.

  98. Noted by . Last updated .

    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.

  99. Noted by .

    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 seirdy.one. Strictly speaking, both syntaxes are made of HTML; however, I’ve certainly found the microformats approach to feel more “HTML-native” than Microdata.

  100. Noted by . Last 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.

    Update : the Content module has since been re-named to the Symbols module; I’ve updated the link in the this post.

  101. Noted by . Last updated .

    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)

  102. Noted by . Last 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.

  103. Noted by .

    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 Itch.io, much of Taobao, and some of the most popular API gateways (including Kong) in the category of “Internet-scale software written by ‘people’”.

  104. Noted by .

    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.

  105. Noted by .

    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.

  106. Noted by .

    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.

  107. Noted by .

    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.

  108. Noted by .

    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.

  109. Noted by .

    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.

  110. Noted by .

    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.

  111. Noted by .

    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.

  112. Noted by . Last 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.

  113. Noted by . Last 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.

  114. Noted by .

    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.

  115. Noted by . Last updated .

    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.

  116. Noted by .

    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.

  117. Noted by . Last updated .

    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.

  118. Noted by .

    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.

  119. Noted by .

    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.

  120. Noted by . Last updated .

    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.

  121. Noted by .

    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.

  122. Noted by .

    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.

  123. Noted by .

    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.

  124. Noted by . Last updated .

    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.

  125. Noted by .

    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.

  126. Noted by . Last 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).

  127. Noted by . Last updated .

    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.

  128. Noted by .

    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.

  129. Noted by .

    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.

  130. Noted by . Last updated .

    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.

  131. Noted by . Last updated .

    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.

  132. Noted by .

    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.

  133. Noted by .

    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.

  134. Noted by . Last updated .

    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 gitlab.com, 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.

  135. Noted by .

    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.

  136. Noted by .

    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.

  137. Noted by .

    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.

  138. Noted by .

    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.

  139. Noted by . Last 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.

  140. Noted by .

    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.

  141. Noted by .

    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.

  142. Noted by . Last updated .

    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.

    Update: this post was originally a reply to a Fediverse post by @garbados@herd.bovid.space, which has since been deleted.

  143. Noted by . Last updated .

    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 :

  144. Noted by . Last 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.

  146. Noted by .

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

  147. Noted by . Last 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.

    Update : This is also the reason why the Vivaldi team won’t publish a (verified) Flatpak of Vivaldi.

  148. Noted by . Last updated .

    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.

  149. Noted by . Last 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.

  150. Noted by . Last 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.

  151. Noted by . Last updated .

    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.

  152. Noted by . Last 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.

  153. Noted by . Last 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.

  154. Noted by . Last 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.

  155. Noted by . Last 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. “html.duckduckgo.com” 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.

  156. Noted by . Last 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

  157. Noted by . Last 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.

  158. Noted by .

    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.

  159. Noted by .

    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.

  160. Noted by . Last 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 Schema.org 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.

  161. Noted by .

    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.

  162. Noted by . Last updated .

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

  163. Noted by .

    I just made a massive internal overhaul of my website, seirdy.one. 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 seirdy.one/notes/ could have an index.html, index.xml (RSS), index.md, 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.

  164. Noted by . Last 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 gov.uk; 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).

  165. Noted by .

    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.

  166. Noted by .

    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.

  167. Noted by .

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

  168. Noted by .

    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.