njsg

Also see https://news.ycombinator.com/item?id=39705936 for a few links on this that I put here last time I saw this happening.

I suspect the problem might be some people at Cloudflare writing code for the checks who are not aware of how to make it work for most browsers, and e.g. demand/expect some header behaviour that's only seen in a small number of browsers (say, Origin:, which has been involved in the past). So the issue would manifest itself no matter the kind of approach involved. At one point, the issue was even that such a header behaviour was requested in the fallback code intended for other browsers, causing a redirect to step zero and a DDoS against Cloudflare.

I haven't tried to debug the issue yet this time, and I'm not sure I want to, because that'd be the (at least) third time I'd get deep into the network inspector to try to compare headers and identify the issue in the middle of obfuscated and/or minified JS, and a chain of requests that are probably intended to defeat this kind of analysis (making it more difficult to identify what is causing the issue). If this was one occurrence every two years or so and Cloudflare were willing to help, and receptive to comments about it breaking in some configurations, the matter would be different (one of the times, their support kept dismissing reports as "unsupported!" and it might have been solved only because someone from Cloudflare saw it here on HN).

On top of that, I'm dealing with a hardware issue that means I don't have enough memory to do the debugging comfortably now...

A sad thing about the Github situation is that, until some months ago, it was perfectly fine for browsing directory tres and clicking to view files on the web, all that worked without javascript. Now it doesn't, except perhaps for the top-level and its README.

That's a shame, I used that a lot for quick browsing, checking and/or comparison of code in repositories hosted by Github.

Some may even be just CSS. I'm still waiting for a way to toggle the CSS ones off for all websites, without breaking them.

These often even look sluggish, but maybe it is a relative thing and some see the prompt movement of UI elements as unpleasant and call the animations "smooth". Or maybe it really takes a very powerful GPU on the right hardware to fully experience animations without feeling annoyed? Or both?

There are sites which load the content dynamically using javascript, there are even sites where this is done with the content already in the served HTML document, as JSON.

There are sites that blank the viewport until scripts change css rules or class names, or load stylesheets.

The latter is especially noticeable when such a site has absolutely no error checking or fallback and stops on some javascript error, leaving the page "blank".

> Regardless if you feel that the web was made only for documents it has become the only truly cross platform runtime you can always expect users to have installed. That's incredibly valuable. Why would we throw that away?

That's not much better than "everyone runs Windows" (but is a good way to view this). (And yes, you cover choosing an OS later in the post.)

What happens is that a select few browsers have what's considered at this point the runtime. So you are always leaving people out. Maybe the runtime price tag in itself isn't a problem now, but the hardware might be. The interface. And there will certainly be users who just want to avoid the low-contrast always-animating nature of some sites, for example.

Nowadays to me the environment is pretty much like Microsoft in the late 90s, early 2000s with their Windows+Office monopoly, and cultures that saw no problem is assuming that was available. But now, instead of these two, we're all expected to be running one of the select browsers that implement a recent enough version of the "living standards", and with powerful enough hardware and graphics acceleration.

But still, in some cases it has to be more complicated to make sites incompatible with other browsers and in the absence of javascript. Recently, I think I read something attributing trends in loading and rendering using javascript to the way Google ranks entries in search results.

IMHO you need to step back and consider that there are more views of design, you think some newer look is "more modern" and better in itself, you say "outdated past vision". But those concepts are subjective too.

I like the Modern SeaMonkey theme. I also like the look of the classic theme (not default, but the old default, sometimes called "XPFE Classic"). Not sure if just out of nostalgia or because it looks neat to me. What I value more is that SeaMonkey's looks are customizable. I don't know if it's customizable enough to make a theme that behaves in the way you prefer, but at least there is room for customization. (I'm mentioning this because I do think this is an interesting feature to have.)

So, please consider relativizing your position, it seems you're insisting on a bias against the design just because it is not recent enough, but also wording that as an absolute.

To me that sounds like people who say some train models "look old" and "have to be replaced" just because they feature Budd-style corrugated stainless steel.

That makes me wonder, regarding AOL/Yahoo/Verizon/... what's the story behind "8 BITMIME" and their mail server's broken 8-bit handling ([0],[1])? Did they just get server software with bugs in one of the acquisitions/mergers? Or is it some incompatibility or configuration issue comparable to the 500-mile e-mail story [2]?

(Note: I had no idea they hadn't fixed it yet (at least the utf8 part)... I tested just now, and, sure, it's still broken... currently it is operating in "State 2".)

[0] https://wiki.mozilla.org/User:Jorgk/8-bit_bytes_and_e-mail_c... [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1435903 [2] https://www.ibiblio.org/harris/500milemail.html

User interface design is about designing interfaces that can be used by users.

You can prefer a style, you can customize it to your liking if themes are available (in this case, they are), but if you just replace the whole UI design field with "design is supposed to look nice", what you get might be an aberration. It might be pleasing to some people (but then still some, I really doubt you can find something that is universally pleasant?), but what good is that without being usable? Or if it makes usage much more difficult?

Now there's also Enigmail, which supports SeaMonkey again.

Distro build hosts and distro package maintainers might not be a bad guess. Depends on whether getting this shipped was the final goal. It might have been just the beginning, part of some bootstrapping.

Update: this has been meanwhile fixed by Cloudflare, see [1] and [2]; I can also confirm that turnstile now works here with SeaMonkey.

[1] https://forum.palemoon.org/viewtopic.php?p=249856#p249856

[2] https://community.cloudflare.com/t/browser-integrity-check-b...

Sadly comments like [3] are realistic observations here; as I said, it's not the first time this happens. At least the support conversation at [2] isn't full of "your browser is outdated" like [4] from 2022 (when Cloudflare's servers were requiring Origin: on all requests, which I think is also what the hackernews thread at [5] was about).

[3] https://forum.palemoon.org/viewtopic.php?p=249864#p249864

[4] https://community.cloudflare.com/t/browser-integrity-check-b...

[5] https://news.ycombinator.com/item?id=31317886

The issue is on CloudFlare's side. It is possibly related to lack of Origin: or References: in a POST request that is part of the turnstile workflow.

On a previous occasion, their support staff kept telling people their browsers were unsupported, until the matter was noticed by someone inside CloudFlare, and the issue then got fixed.

This time, their response to Moonchild chalks this down to "suspicious activity" or some custom rule, but does not even mention any kind of browser version limit. No, what is happening (and I've tested this enough to be sure of it) is that they are requiring a behaviour that was only implemented in (for the mozilla codebase) Firefox 70.0, and it is failing for browsers that don't behave in that way.

Let me state it clearly: CloudFlare checks (at least those of "turnstile"?) are rejecting legitimate browsers and users.

CloudFlare may as well have decided they want to reject all but a few browsers - it's their business - but then they should clearly advertise this. Their potential and current customers should be clearly told entering a deal with CloudFlare means they are limiting their user base to those using CloudFlare-approved browsers.

In the past, what happened with their "browser integrity check" appeared to be an error on CloudFlare's side which required such a behaviour (in that case, the Origin: header had to be always present) from all browsers even in fallbacks clearly meant for browsers that did not implement such behaviour. Now is this the case here too with turnstile or has CloudFlare decided to significantly change the purpose of their "protections" to do more than just banning e.g. bots?

This is affecting at least SeaMonkey and Pale Moon.

I guess one must ask El Reg to write about it. I think that might have been how it got solved a couple years ago when comp.lang.c and others were affected by this [1].

Currently, at least mozilla.support.seamonkey (not a USENET group, but from news.mozilla.org - which was shut down, but whose archived content would certainly be useful) is in that state at Google Groups. And yes, IIRC the only SPAM in recent times in that group had been posted via Google Groups...

[1] https://www.theregister.com/2021/06/01/google_usenet/

Gopher by itself is actually not hard to extend, as far as people standardize on how to extend it. That is why most of the discussions on "gopher enhancement" never resulted in big changes. Several ideas must be spread across the gopher project mailing list (now hosted at alioth, see archives at gmane), and some of them are quite good. The only consensus, though, seems to be that any extension is going to be done over plain gopher, not gopher+.

You are criticizing gopher from the point of view of "it must have the same features as HTTP". Some of the things you call "problems" are just different ways of doing it.

And if the TCP sliding window is an issue for you, why not fix TCP?

Why should the server send any kind of header?

Doesn't TCP do checksums, already?

And you need more because...

Let's be honest, you just need to know how are you going to deal with the file, not what kind of file it is.

You need something along the lines of - this resource is readable text - this resource is binary data - this resource is an image

Older, gopher-specific clients, can be interesting, too. Some day I should try to get gopherVR running on my machines.

Stop trying to compare it to HTTP, maybe?