Said people are trusting the intel from the AI. Those who provide that intel possible should shoulder responsibility for its effects, or at least its efficacy.
HN user
Seirdy
Website and blog: https://seirdy.one
I've reduced my use of HN. I mostly interact with HN to collect and respond to feedback, correct misinfo, and ask questions.
[Verifying my OpenPGP key: openpgp4fpr:AC6AF1F838DF3DCC2E47A6CF1E892DB2A5F84479]
Shortly after you posted this, it looks like their TLS certs expired. Checking my TLS-RPT bundles reveals 5 failures in the last couple days from Google.
Correction: this was not a case of accidental misgendering. The post refers to someone abusing mod privileges to edit someone's pronouns to "who/cares".
It's a very common Markdown extension supported by PHP-Markdown-Extra, Goldmark, Pandoc, Kramdown, and dozens of others. Several of these have supported it for almost ten years now, with the same syntax.
PHP-Markdown-Extra is the closest thing to a standard with more than GitHub-Flavored-Markdown; several other Markdown engines use its featureset as a baseline for compatibility for anything not present in GFM, even blocking the shipping of new features until after PME agrees on a syntax. So you can think of CommonMark as the lowest common denominator, GFM for an intermediate version, and PHP-Markdown-Extra as something suitable for building more advanced websites.
Goldmark (Hugo) and many Markdown extensions do support description lists. Hugo also supports render hooks which make adding support for attributes, picture elements, etc trivial. And the vast majority of advanced markdown engines support a front matter, typically YAML although Hugo supports TOML and JSON as well.
I'm trying to adopt as much IndieWeb as I can while still remaining a static JS-free site (except for the crappy search results page). Comments are Webmentions.
I test compatibility with a lot more than just mainstream browsers: the Tor Browser's safest mode, various article extractors, NetSurf, Ladybird, w3m, and a dozen other user-agents work well. Accessibility-wise, I'm close to WCAG 2.2 AAA compliance, and have already passed AA; I consider WCAG a starting rather than a stopping point. More on its design is in the "Meta" section.
It has long-form blog articles and short-form notes (microblogs).
My best posts are on the homepage, followed by a bunch of webrings.
Gleason is an influential member of the fediverse because of Soapbox. Soapbox adoption generally makes him more relevant and more popular. This clout amplifies his transmisiac message.
It's similar to JK Rowling getting famous off the Harry Potter franchise and using that clout in a way that causes harm, prompting others to stop promoting her works and thus stop feeding her positive attention. Having read one of those books or having watched one of her movies doesn't make you a transophobe, but promoting her works gives her the means to do harm.
Moreover, the majority of soapbox instances tend to be freeze peach servers that either contain or amplify other harassers. Good soapbox instances tend to be the exception rather than the norm.
The devs are especially interested in a distribution of musl with hardened_malloc integrated for easy static linking.
Until then, LD_PRELOAD is your friend (assuming you build with semantic interposition).
QUIC does not require a CA. Self-signed or DANE-backed TLS certificates work fine. Try using cURL built with HTTP/3 support to see for yourself.
Requiring CAs and not implementing support for other anchors of trust is an implementation decision, and is not mandated by the spec. The spec mandates TLS 1.3, not "the version of TLS 1.3 used by these three web browsers". QUIC was designed with non-browser use in mind too; it's for any situation where you want to maintain connection integrity in an unreliable network.
Many worried about what Twitter's changes would mean for under-represented groups. Given this news and Twitter also cutting its accessibility department, I think we can see their new attitude towards minorities isn't particularly friendly.
How's the accessibility of these interfaces? I believe you mentioned an intent to target the Web some time ago, implying that Web interfaces could expose semantics to assistive technologies. Is this still on the roadmap?
Nor can I. That's why progressive enhancement is common sense: it's way less effort, less complexity, and easier to make accessible.
I concur on using an adblocker to block modals, cookie notices, dickbars, related articles, author profile pictures, etc. In fact, I never dismiss modals because doing so may imply consent to tracking cookies (you never know these days…). I just block them with a quick cosmetic selector-based filter.
Unless it's a personal site/blog I typically open a site to find information I came for, and close it as soon as that task is done. Anything that makes this take longer than it needs to gets blocked. Sites should strive to stay open for as few seconds/minutes as possible while still giving me the requested information.
Regarding text/image-focused sites that require JS: I generally find sites made by people who haven't figured out how to send text over HTTPS to have low-quality content befitting of their low-quality stacks. I'm all the better for using my adblocker to block them from my search results page forever; it saves me time in the long run.
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: https://seirdy.one/notes/2022/08/12/user-agents-set-the-term...
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.
POSSE (Publish on Own Site, Syndicate Elsewhere) note from https://seirdy.one/notes/2022/09/10/in-defense-of-content-bl...
I recommend users who link against OpenSSL to enable padding to multiples of at least 1024 bytes if they want to impede traffic analysis. The Nginx devs aren't interested in implementing random record padding or supporting the feature in BoringSSL/LibreSSL, unfortunately.
Can Caddy leverage either form of padding? If so, I might need to give it another look!
And regarding modules: most are written in C and dynamically loaded as shared objects or statically linked during compile-time. A bunch are listed at https://www.nginx.com/resources/wiki/modules/. The ones for live streaming and VODs are the hardest to replace, IMO. IPScrub was my favorite but I haven't used it for a few years.
Personally, I think live streaming and ffmpeg-based encoding are specialized enough to warrant a specialized server (like a custom Nginx build) and are a bit out of scope for a general-purpose user-friendly server like Caddy.
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'".
POSSE (Publish on Own Site, Syndicate Elsewhere) note from https://seirdy.one/notes/2022/09/09/reasons-to-use-nginx/
In the experimental Document-Policy HTTP header, "bpp" does seem to signify bytes per pixel.
Document-Policy explainer: https://github.com/wicg/document-policy/blob/main/document-p...
I tried it out on my own site, and through trial-and-error I found that Chromium does in fact treat the "max-bpp" Document-Policy directives as bytes-per-pixel.
I could be wrong; my memory has faded. Please correct me if this is the case.
Yes, I listed several. Scroll down a bit.
Thanks, added. Diff: https://git.sr.ht/~seirdy/seirdy.one/commit/ae3e26e5928a9f0f...
Xe is phasing out that name in favor of "Xe". Xer domain name change was a part of that shift.
Thank you for the kind words. You made my day.
Yep is the official engine; FairSearch was the "pre-release" version.
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.
(POSSE from https://seirdy.one/notes/2022/06/03/opt-in-telemetry/)
Chromium and dreivatives had this for years. Firefox's isolation is making progress, but it has a ways to go before it matches Chromium.
FF devs are finalizing a utility process overhaul and laying the groundwork for CFI; for years, Chromium has had both with a much more thorough implementation than FF will in the near future. However, the browser space desperately needs competition so I'll take what I can get. Sigh.
No, it's not native; it looks like it uses Flutter, which implements its own UI behavior.
IMO, flutter feels even less native than web apps. At least the latter uses system font rendering, supports system-set color palettes (an option in Firefox prefs), supports system preferred keybinds for text editing, system scrollbars, etc.
They both parse untrusted content content without any sandboxing.
I typically send content through rdrview[0] before piping through w3m-sandbox[1], which should be pretty safe. I also only browse one site per w3m instance.
[0] https://github.com/eafer/rdrview
[1] https://git.sr.ht/~seirdy/bwrap-scripts/tree/trunk/item/w3m-...
I offset these impacts by actively avoiding brands I recognize from unsolicited ads, and I encourage everyone to do the same.
Seems like a really simple site that uses a mix of browser defaults with light CSS enhancements, but I put about 13k words of thought into it:
https://seirdy.one/2020/11/23/website-best-practices.html
It's really hard to get a site to work well on a <2-inch (<5cm) viewport with switch access for astigmatic colorblind users on a feature phone experiencing packet loss, but I think I pulled it off nicely. CSS-optional, no JS (blocked by CSP).
Also has mirrors to a Tor hidden Web service and a Gemini capsule, all hosted on the same VPS.
I like the "small web" and joined a few webrings (and Gemini orbits), and try to make this static site a member of the IndieWeb.
Bookmarks are generated from my bookmarks manager, WIP music ratings from MPD coming soon.
An incomplete list of use-cases I tried to accommodate:
- Screen readers
- Switch access
- Keyboard navigation, with the Tab key or caret navigation
- Navigating with hand-tremors
- Content extraction (e.g. “Reader Mode”)
- Low-bandwidth connections
- Unreliable, lossy connections
- Metered connections
- Hostile networks
- Downloading offline copies
- Very narrow viewports (much narrower than a phablet)
- Mobile devices in landscape mode
- Frequent window-resizers (e.g. users of tiled-window setups)
- Printouts, especially when paper and ink are rationed (common in schools)
- Textual browsers
- Uncommon graphical browsers
- the Tor Browser (separate from “uncommon browsers” because of how “safest” mode is often incompatible with progressive enhancement and graceful degradation)
- Disabling JavaScript (overlaps with the Tor Browser)
- Non-default color palettes
- Aggressive content blocking (e.g. blocking all third-party content, frames, images, and cookies)
- User-selected custom fonts
- Stylesheet removal, alteration, or replacement
- Machine translation to right-to-left languages
I'd pick Graphene over Calyx on privacy and security grounds, and Lineage over Calyx on device support or tweakability grounds.
Graphene is honestly ahead on the security and privacy front. MicroG requires very strong privileges and weakens the comprehensive privsep you'd otherwise have; GrapheneOS offers sandboxed play services with the standard SELinux policies for unprivileged Android software.
GrapheneOS also has hardened_malloc, which seems to have the best design for malloc hardening out of any alternatives I'm aware of.
On the userspace side, Graphene uses several of its own apps. One is Vanadium for its webview and browser; it's a hardened fork of Chromium. Check the patchset; it's got a bunch of security improvements and cross-pollenates with Bromite. The most interesting feature they've been working on is per-site JIT toggles.
The list goes on. Few other OSes come close.
Now, if you want to tinker with your phone at the expense of security, Lineage is actually a great option. It has a big community of tweakers and ricers who root their phones and come up with some cool experiments. It also supports a wider variety of devices, including devices abandoned by their manufacturers. Don't expect security updates, though.
They do have their own index, Teclis. You can use it independently: https://teclis.com/
The "non-commercial" lens in Kagi is mostly powered by Teclis, and the main SERPs include some non-commercial lens results mixed in.