Onion Information

Page Clicks: 0

First Seen: 03/11/2024

Last Indexed: 10/21/2024

Domain Index Total: 190

Notes This is my microblog, containing short informal entries. They’re longer than most posts on microblogging networks (some would call this a “miniblog” instead), but a fraction of the size of the longer entries on my blog . Most posts are under 300 words. An Atom feed contains the full text of all my notes. If that has any problems, I also have a legacy RSS feed . Timestamp format: YYYY-MM-DD HH:MM , as per RFC 3339 . Sorted newest to oldest. Chromium’s influence on Chromium alternatives Noted 2024-10-06 by Rohan “ Seirdy ” Kumar . I don’t think most people realize how Firefox and Safari depend on Google for more than “just” revenue from default search engine deals and prototyping new web platform features. Off the top of my head, Safari and Firefox use the following Chromium libraries: libwebrtc, libbrotli, libvpx, libwebp, some color management libraries, libjxl ( Chromium may eventually contribute a Rust JPEG-XL implementation to Firefox ; it’s a hard image format to implement!), much of Safari’s cryptography (from BoringSSL), Firefox’s 2D renderer (Skia)…the list goes on. Much of Firefox’s security overhaul in recent years (process isolation, site isolation, user namespace sandboxes, effort on building with ControlFlowIntegrity) is directly inspired by Chromium’s architecture. Interdependence for independent components can be mutually beneficial. For something to be part of Chromium, it needs to build and test with a battery of sanitizers and receive continuous fuzzing. Mozilla and Safari do something similar. All benefit from libraries getting patched to meet each others’ security requirements. Without Google, Mozilla and Apple must assume responsibility to maintain these libraries to a browser-grade standard. I see many advocates for Chromium alternatives say the Web would be better without Chromium. That may be true, but Chromium alternatives may also be worse. For completeness: Firefox and Safari’s influence on Chromium in recent years includes the addition of memory-safe languages, partitioned site storage, declarative content blocking (from Safari), and a vague multi-year repeatedly-delayed intent to phase out third-party cookies. Chromium would be no better off without other browser projects. Lose-able keys are a feature Noted 2024-09-13 by Rohan “ Seirdy ” Kumar . In opsec, duress (“rubber-hose”) attacks are famously hard to address . Cryptographic keys that cannot be lost have poor protections against duress. Travelers can leave key fobs at home should they be accosted. A victim of a break-in can conveniently “lose” or smash a hardware key, erasing any encrypted data. Yes, I know about cold-boot attacks; I don’t recommend at-risk people to leave things decrypted for long durations. I like the idea of spring-loaded key fobs that can’t be left plugged in. People talking about key fob body implants don’t usually plan for removing them in seconds with plausible deniability. Common Crawl and search engines Noted 2024-07-24 by Rohan “ Seirdy ” Kumar . Last updated 2024-07-25 . Common Crawl is the closest thing we have to an open index, though it doesn’t meet your requirement of ignoring robots.txt for corporate websites while obeying it for personal sites. Unfortunately, being open and publicly available means that people use it to train LLMs. Google did this for initial versions of Bard , so a lot of sites block its crawler. Most robots.txt guides for blocking GenAI crawlers include an entry for it now. Common Crawl powers Alexandria Search and was the basis of Stract’s initial index , both of which are upstart FOSS engines. A similar EU-focused project is OpenWebSearch/Owler . On a more selective Google Noted 2024-07-19 by Rohan “ Seirdy ” Kumar . Last updated 2024-07-19 . Selectivity is long overdue. Marginalia, Stract, and Teclis feel like a breath of fresh air for broad short-tail queries because they downrank or skip pages full of ads, trackers, scripts, and even SEO. However, Google’s selectivity can’t penalise such criteria as that would conflict with its ad business. Google has a bias against new sites. This makes sense, given their spam potential. I disagree with your argument that a bias against new sites is a pivot away from Experience, Expertise, authoritativeness, and trustworthiness ( EEAT ) : it takes time for a website to become an authority and earn trust. If delayed indexing of new sites is wrong, then the problem lies with EEAT . I argue that EEAT is a good framework for an answer-focused engine, but a bad framework for a discovery- or surfing-focused engine like Marginalia or Wiby, respectively. Caveats to Ungoogled Chromium recommendations Noted 2024-07-15 by Rohan “ Seirdy ” Kumar . In the wake of a certain ad-funded browser company bundling adtech into its browser yet again, some people have been recommending Ungoogled-Chromium ( UGC ). I think it’s fine to recommend UGC with caveats, such as the fact that it disables component updates that include: Certificate revocation. Chromium uses downloaded CRLSets for revocation; it does not support OCSP. Out of band security patches. When browser components have exploits in the wild, they need to be patched ASAP; updating billions of installations within time-frames measured in hours often means restartless out-of-band updates. Out of band certificate bundle updates. If you assume Google uses its component update server logs maliciously, you may wish to consider a fork that still offers component updates provided by a different party’s servers. UGC disabled mDNS at one point. This exposed local IP addresses over WebRTC for years, but they seem to have shipped a fix in May 2023 to disable non-proxied UDP. UGC also disables the Chrome Web Store in favor of installing extensions out of band. Make sure you regularly update your extensions installed out-of-band, since UGC won’t do it on its own. Some scripts and a special extension re-implement some of this functionality. Overall, UGC is still safer than QtWebEngine despite making heavy compromises to security for privacy (though I can’t see how either benefited from disabling mDNS: I’m not aware of threat models under which revealing a local IP to every application is preferable to revealing it to just Google). Running UGC is fine if you understand these trade-offs and have accounted for them. I use it in headless mode to run accessibility and performance tests. On valid XHTML5 again Noted 2024-06-23 by Rohan “ Seirdy ” Kumar . Switching a site to XHTML5 is only a lot of work at first, because it may have latent bugs. For instance, you may have a stray tag that the HTML parser auto-closes but an XHTML parser won’t. I find this effort worthwhile because some of these bugs will eventually visibly manifest . One thing I’ve noticed is that some tools are incompatible with an XHTML5 MIME type. Site auditors like Lighthouse are only provisionally compatible, and some browser extensions are rather buggy. You can compare them yourself on seirdy.one: switch the MIME type by appending /index.xhtml to a URL. You may have to disable the CSP sandbox by appending ?sandbox=off to the URL to get Lighthouse to work. I keep my site polygot and serve with the text/html MIME type by default for maximum compatibility. Progressive enhancement class feedback Noted 2024-06-23 by Rohan “ Seirdy ” Kumar . This page at the time of writing grades websites’ progressive enhancement based on their ability to work without JavaScript. Everything, not just JavaScript, should be progressive enhancements. HTML elements already have progressive enhancement built-in. CSS, JS, and embedded content should be progressively enhanced too. The page should make sense without scripts and styles, alt-text should be available in the absence of embedded media, etc. We shouldn’t put scripting on a pedestal above everything else. I suggest replacing references to JavaScript with references to non-HTML content. See also: “curlable” on the IndieWeb wiki . A more minor piece of feedback: I’d suggest re-sizing the badges to 88-by-31 pixels if possible. It’s a very popular size for badges; at these dimensions, they would look good alongside others of the same size ( examples from the W3C ). Next steps for my search engine collection Noted 2024-05-24 by Rohan “ Seirdy ” Kumar . My search engine article blew up recently, as yet another major publication linked it (yay! /gen), so I made some fixes: Moved a couple engines to the graveyard. h/t to dequbed for telling me about moose.at’s demise, and to my broken link checker for telling me about Siik being down for a while now. Updated my methodology section to emphasize how I now use word-substitutions to fingerprint an engine’s source. Queries that lend themselves to word-substitution are now my primary approach to uncovering which provider an engine uses for search results, followed by some long-tail queries and search operator support. The full list of changes is in the Git log . Things I should add in the future: I ought to add a section to describe why I don’t personally like metasearch engines as much as I used to. TLDR: each engine has its own quirks and search operators that I learn to use, and throwing them all on one page forces me to use whatever quirks they have in common. This is really bad for long-tail queries. I should put more effort into categorizing engines by strength as well as index size. I’ll have to come up with appropriate terms for things like “ability to find specific pages with specific topics” (less aggressive word substitutions, less focus on semantic search: Mojeek is one of the best at this, Yep is terrible), or “ability to discover pages about a given broad topic” (Yep is good at this once you learn to use it well, but Mojeek isn’t). That second bullet point is really important. Part of the point of this article is to show that nobody can beat Google at being Google (except perhaps Bing), but we can beat Google at more specific niches. Coercion and Windows Recall Noted 2024-05-22 by Rohan “ Seirdy ” Kumar . Last updated 2024-06-23 . The best ways to improve opsec against coercion are to: Limit what can be taken (reduce what’s stored on a device). Fake what you do have: use duress passwords or secondary devices. Last resort: use a hardware key that’s deliberately easy to lose or break, so there’s potentially no key to give up in a rubber-hose attack. There’s overlap between the three. A duress password temporarily limits what’s stored on a device, and losing a decryption key is more or less the same as instantly wiping encrypted data to reduce what you have to offer. All come down to having less data to give when coerced into giving what you have. Operating systems should also obey this principle by storing as little offline data as possible, and providing duress safeguards for what must be store...