Skip to content

Notes

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

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

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

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

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

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

  5. Noted by .

    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.

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

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

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

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

  10. Noted by .

    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.

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

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

  13. Noted by .

    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

    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.

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

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

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

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

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

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

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

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

  22. Noted by .

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

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

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

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

  26. 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”?

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

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

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

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

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

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

  33. 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 and indieweb.xyz/en/accessibility.

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

  34. Noted by .

    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)

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

  36. 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’”.

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

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

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

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

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

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

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

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

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

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

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

  48. Noted by .

    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.

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

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

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

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

  53. Noted by .

    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.

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

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

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

  57. Noted by .

    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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  76. 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 :

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

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

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

  80. Noted by .

    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.

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

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

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

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

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

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

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

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

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

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

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

  92. 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.
  93. 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.

  94. Noted by .

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

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

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

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

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

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

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