shiomiru

Another POSIX shell in Rust I remember: https://github.com/nuta/nsh

But it no longer seems to be in active development.

> Let's not go blaming vulnerabilities on those exploiting them. Exploitation is also bad but being exploitable is a problem in and of itself.

There's "vulnerabilities" and there's "inherent properties of a complex protocol that is used to transfer data securely". One of the latter is that metadata may differ from client to client for various reasons, inside the bounds accepted in the standard. If you discriminate based on such metadata, you have effectively invented a new proprietary protocol that certain existing browsers just so happen to implement.

It's like the UA string, but instead of just copying a single HTTP header, new browsers now have to reverse engineer the network stack of existing ones to get an identical user experience.

Chrome has randomized its ClientHello extension order for two years now.[0]

The companies to blame here are solely the ones employing these fingerprinting techniques, and those relying on services of these companies (which is a worryingly large chunk of the web). For example, after the Chrome change, Cloudflare just switched to a fingerprinter that doesn't check the order.[1]

[0]: https://chromestatus.com/feature/5124606246518784

[1]: https://blog.cloudflare.com/ja4-signals/

Among less technologically literate acquaintances, getting a gazillion browser notifications on startup seems to be the modern equivalent of accidentally installing tons of useless toolbars.

The problem is that the very purpose of a textbox is to submit data. So you'll have to add the caption to every single textbox.

(I've actually tried to do something similar in my browser, but it was an eyesore so I removed it.)

htcrack.ai is available...

> Besides, throwing an exception is a terrible way to do range checking. There's a huge number of projects out there banning exceptions that would benefit from safe interfaces.

I thought "banning exceptions" would mean fno-exceptions, turning the throw into an abort - that's pretty good for a systems programming language, no?

What other way would you propose?

> Sure, but the same is true for unsigned commits as well, isn't it?

Yes, I think so. As I understand, GP's idea was to sign your commits proactively.

> git does allow you to rewrite history arbitrarily.

Technically yes, but the price is too great - everybody who has cloned the repos will now have to nuke their local copies too.

> Would you expect a "privacy focused" browser to offer you networking disabled by default

Obviously not, because at that point it can no longer be used to browse the web. (That said, "do no network requests" should be the default idle state of the browser until appropriate user interaction. Allowing CORS is also a horrible default but that ship has long sailed.)

I also disable WebGL in my Firefox profile and this does not inconvenience me in any way. So I do not think WebGL support is as instrumental to browsing the web as you claim; it entirely depends on what sites you visit. (And let's be honest here, a very significant majority of websites does not need WebGL.)

Developers can use whatever features they want, but users can only watch as their computer uses up more and more energy because it suddenly has to perform yet another build step that previously was done on the server.

Another solution for the pre-command part is "trap 'some command' DEBUG".

Another option I'm working on: https://sr.ht/~bptato/chawan

Chawan also renders CSS + images, but unlike the above two, it comes with its own browser engine (from scratch). It also does JS with QuickJS - if you're lucky :P (Lately I got Transmission's web UI to load, quite happy about that.)

It seems well-intentioned, but not particularly well informed...

* It mixes concerns of HTML and CSS - e.g. <pre> eating newlines is a result of the HTML parser, but whitespace collapsing is specified in CSS.

* It suggests turning HTML from a markup language into... whatever incompatible thing the author came up with. Arguably it's not much worse than XHTML, but I don't expect better adoption.

* The final suggestion is to add a character reference to CSS - the sole issue being that CSS does not see character references, those are turned by HTML into Unicode codepoints. Also, the set of character references is closed, for good reasons.[0]

* (Nit, but "block formatting context" does not mean what the author thinks it means. Flex items behave like blocks because they become blockified - BFCs solve a separate, similarly hairy issue (floats & margin collapsing.))

[0]: https://github.com/whatwg/html/blob/main/FAQ.md#html-should-...

Throwing any codepoint sequence at two separate compliant HTML5 parsers will result in the same DOM, and to my knowledge, all major browsers use compliant parsers.

In my text browser I came up with a way to implement these that doesn't move boxes around the page.[0] In short: treat "position: fixed" as an absolute child of the root box, and ignore "position: sticky" (mostly).

This doesn't completely eliminate sticky headers/footers (problematic when you actually want to use them), but they behave like normal elements at the start/end of the page (instead of the screen).

I initially did it this way for technical reasons, but now I kind of prefer it to what mainstream browsers do.

[0]: https://git.sr.ht/~bptato/chawan/tree/e56399f92d2323f9af95e0... (not a great explanation - it says "bottom", but like "position: absolute" it's placed at the top if only "top" is specified, etc.)

> * Author claims to speak English very poorly, but writes incredibly well! Maybe they leaned on LLMs, but this seems pretty good even for an LLM.

The author claims their pronunciation is poor. Writing is a completely different skill. (Especially in English with its insane spelling rules.)

> * Author says they have 2 years of work experience in a company that doesn't use Typescript, but then proceeds to create a solution ad-hoc that requires incredibly deep knowledge of the type system. Certainly not impossible, but I don't know anyone that could pull this off.

Self-study?

Sixel is a fun side quest as well, if you want to encode it on your own. You get to work on a color quantization and/or dithering algorithm in $CURRENT_YEAR.

And if you're doing text with images, integrating both Sixel and Kitty is especially painful because they have completely different display models.

(In particular, Sixel is cell based, so you get Z-ordering for free - with the caveat that writing text on top of images destroys the cells.

Meanwhile, Kitty has Z-ordering, but it's per-image, so e.g. to draw a menu on top of an image that partially covers text, you must send a new image with space for the menu erased...)

For those who are interested, the best resource I've found on this is the notcurses author's wiki: https://nick-black.com/dankwiki/index.php/Theory_and_Practic...

So that's why they broke loading issue comments without JS. As if the (post-M$) UI hadn't been sluggish enough before...

> "Why didn't they do it earlier?" is a fallacious argument.

I never said that, but admittedly I could have worded my argument better: "In my opinion, shadow banning non-JS clients from result computation would be similarly (if not more) effective at preventing SEO bots from poisoning results, and I would be surprised if they hadn't already done that."

Naturally, this doesn't fix the problem of having to spend resources on serving unsuccessful SEO bots that the existing blocking mechanisms (which I think are based on IP-address rate limiting and the UA's HTTPS fingerprint) failed to filter out.

> Yes, that kind of thing is very easy to just assert. But just think about it for like two seconds. How much more revenue are you going to make per user? None. Users without JS are still shown ads. JS is not necessary for ad targeting either.

Is JS necessary for ads? No. Does JS make it easier to control what the user is seeing? Sure it does.

If you've been following the developments on YouTube concerning ad-blockers, you should understand my suspicion that Search is going in a similar direction. Of course, it's all speculation; maybe they really just want to make sure we all get to experience the JS-based enhancements they have been working on :)

If it's such a common issue, I would've thought Google already ignored searches from clients that do not enable JavaScript when computing results?

Besides, you already got auto-blocked when using it in a slightly unusual way. Google hasn't worked on Tor since forever, and recently I also got blocked a few times just for using it through my text browser that uses libcurl for its network stack. So I imagine a botnet using curl wouldn't last very long either.

My guess is it had more to do with squeezing out more profit from that supposed 0.1% of users.

And it hijacks my back button. It took two clicks to get back to HN. (Fennec/Android)

> The goal with Ladybird is to be "independent" in the sense that nobody influences their decisions. However, they have no desire to be independent from a technology stand-point (other than being Open Source).

Wouldn't a hard fork Blink instead of LibWeb still achieve this goal?

The sad part is that it's trivial to get around CF's bot protection if you're writing a bot (just use curl-impersonate and buy residential IPs), but it's pretty much impossible to bypass as a human if their magical black box doesn't like your browser and/or IP address.

I believe Netscape worked like this back in the day. (ETA: as in, resizing the window would reload the page.)

> string parsing: innerHTML, querySelectors, console.log

I don't have numbers, but I doubt an in-browser JS implementation without these APIs would be useful on many websites. Even HN uses innerHTML.

> when the same people simultaneously moan and complain any time Mozilla tries to branch out and cultivate independent revenue streams.

I don't know what "same people" you're talking about, but the criticism I see is typically about a) Mozilla's attempts to branch out which failed, b) Mozilla's "branching out" attempts that are just as bad as their reliance on Google (like how they bought an ad company and are pushing their form of "anonymous tracking" or whatnot.)

> Have you considered what happens if not-utf8 data winds up in an environment variable that you are writing to stdout? What if it contains malicious VT commands?

Unless you're talking about terminal bugs in parsing invalid UTF-8 - and parsing invalid UTF-8 is easier than rendering valid UTF-8 - VT commands are UTF-8 compatible. You just need to embed an ASCII escape character.

> As any good programmer knows, division is slow, it’s a serializing instruction, and we want to avoid it as much as possible. The favourite programmer tricks to avoid division are to use bit shifts (for division by multiples of two) or flip it into a multiplication — for example, to multiply by 0.333 instead of dividing by 3. In this case though, we are dividing by the alpha, so we can’t know what number we will be dividing by in advance.

> However, because the channels are 8-bit, we will only ever be dividing numbers from 1 to 255 (yes, some values will be zero — but we sure won’t be dividing by them then!) That means there are only about 65K possible combinations, so we can use another classic solution: a lookup table! This is a perfect place to use constexpr to bake the array directly into the compiled result.

Interestingly, when I benchmarked this same problem, three integer divisions would easily beat the LUT on my computer. Maybe because the it's easier on the cache? (Or I did something wrong.)

For best ergonomics, both should be well supported.

If I'm programming and want to look up something in the docs, then it's annoying to switch to the mouse and then back, but I pretty much have to with traditional browser UI. (Or tab through a million links to find the right button to click, use cursor keys to scroll, etc.)

Similarly, if I'm just scrolling around with the mouse, then I should be able to do everything that I can with the keyboard (apart from text input). The context menu is good for discoverability, but being context-dependent makes it impossible to rely on muscle memory.