I have to say I haven't spotted anything at this brutality scale neither before, not after this incident. Also, I had no third-party adblocking software deployed, just Firefox's native defaults. (I use quite a few other extensions, userscripts and userstyles, though, so I cannot rule out some clash induced by them.)

I see LI is using protechts.net stuff in hidden iframes with charming id="humanThirdPartyIframe" and even nicer id="humanSecurityEnforcerIframe". Lovely!

[1] https://pasteboard.co/9eDQ84szy3d9.jpg

    "25 - Appearing Dots"

    "26 - Disappearing Dots"

[1] https://www.psy.ritsumei.ac.jp/akitaoka/kieru3e.html#:~:text...

[2] https://www.psy.ritsumei.ac.jp/akitaoka/kieru3e.html#:~:text...

[3] https://codepen.io/myf/full/XjdmJy ( scintillation warning)

[4] https://codepen.io/myf/full/jMqoMW ( scintillation warning)

Personally, I have my browser set up to "guess" as little as possible, never do the search from the URL bar unless explicitly told to do so using a dedicated search keyword (plus I still keep separated auto-collapsing search bar). I have disabled all guessing for TLDs, auto prepending www. In short, when I enter "whatever" into my URL bar, my browser tries to load to "http://whatever/", what could be my local domain and I could get an answer -- it is is a valid URL after all. In a related note, I strongly doubt that any browser does the web search for "localhost".

The rabbit hole could naturally go even deeper: for example most browser still interpret top-level dataURIs. It is not that long browsers interpreted top-level `javascript:` URIs entered into URL bar, now surviving in bookmarklets but taken from all users for the sake of a pitiful "self-XSS prevention".

So I would be really careful telling what happens -- or, god forbid, should happen -- when someone types something into their URL bar: "whatever" could be a search keyword with set meaning: - it could be bound to http URL (bookmark), - the bookmark URL could have a `%s` or `%S` and then it would do the substitution, - it could be a `javascript:…` bookmark ("bookmarklet"/"favelet"; yes, most browser still let you do that, yet alas, mostly fail to treat CSP in a way it would remain operational). - It could be a local domain.

The fact that, statistically, "most" browsers will do a web search using some default engine is probably correct but oversimplifying claim that glosses over quite a lot of interesting possibilities.

IDK, I think there are obvious low-hanging attempts [0] such as: do not display secret codes in stable position on screen? Hide it when in background? Move it around to make timing attacks difficult? Change colours and contrast (over time)? Static noise around? Do not show it whole at the time (not necessarily so that user could observe it: just blink parts of it in and out maybe)? Admittedly, all of this will harm UX more or less, but in naïve theory should significantly raise demands for the attacker.

[0] Provided the target of the secret stealing is not in fact some system static raster snapshot containing the secret, cached for task switcher or something like that.

    data:text/html;charset=utf-8,USGB

    Alt+D, "say something", Enter

(I'm afraid it just a matter of time they will prevent our mischief, though.)

[0] oxfordlearnersdictionaries.com uses the same collection. [1] https://ssl.gstatic.com/dictionary/static/sounds/20160317/mu...

Presumably, most users wanting flashbang-less browsing experience use Dark Reader extension or similarly radical solutions.

The sad truth is that the user preferences and per-site persistence for stuff like this should always have been browser's responsibility to begin with: just the same way like the font-size/page zoom already is, and likewise some (blatantly limited) security settings. (Bitterly) amusing fact is that there was (and still is) concept of "alternate stylesheets" from the beginning of CSS (still part of the spec [0], no support outside Gecko), that also fade into obsolescence for it's lack of persistence. So to this days, Firefox, for example, has View → Page Style menu, where user can choose alternate stylesheet but the choice is not preserved across navigations, so is pretty useless on its own.

Similarly userstyles: specifications dictate there is like CSS origin level and how they should behave and that all "user agents" are supposed to give user a way to enter the cascade this way, but does not give any official way how to scope individual recipes to concrete origins. That's what the unofficial `@-moz-document` extension was that, and briefly had a chance to be formalised [1]. But I digress.

(Likewise all the "European" cookies banners: tragic example of regulation applied on the wrong level. Instead of putting users in charge with help of their "user agents": implicitly blocking pretty much everything and using permissions system that actually would have a chance to be more than "pinky promise we will not track you if you don't click this toggle inside our banner". But I digress even more, sorry.)

> I'd be curious to know if anybody has found a way to avoid this issue with JS switchers -- ideally without needing to delay the initial paint.

At this point, when browsers do not support per-site user preference for that natively, pragmatic (most robust) way would be to respond with properly set HTML payload straight away. There is even specified HTTP header for this, so once adopted in browsers, we could even ditch HTTP cookies [2] for the persistence, but it seems quite demanding on the server (IIUC negotiating these "Client Hints" takes extra initial request round-trip).

Pragmatically, I guess having early running JS in the HEAD that ensures the proper color-scheme is set on the root not and only proper stylesheets load should pretty much prevent most flashbangs, provided the relevant bit would arrive early enough from the server. I think there does not exist any good no-JS-no-Cookie (or any JS-less persistence) solution that supports navigations, sadly.

[0] https://html.spec.whatwg.org/multipage/links.html#rel-altern...

[1] https://www.w3.org/TR/2012/WD-css3-conditional-20121213/#cha...

[2] https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/...

    browser.display.use_document_fonts.icon_font_allowlist

    browser.display.use_document_fonts

No. You've misread the main point. The user would have gotten his preferred font if the font stack was either just plain

    font-family: monospace;

    font-family: , monospace;

I agree it is not a huge "bug" on the first sight, and as it seems even this is somewhat solvable without disabling font support completely. But since it takes some effort and expertise on the user's side, it adds the "bug" some weight nonetheless.

That hurts. I see where you are standing, and can confirm you expressed opinion of the contemporary majority of browser users, but man, how sad it that. The attitude diverged by a light years, when "Setting preferred fonts for generic font families" is now "esoteric". (Web) browsers ("user agents") came to existence with these capabilities in mind, and even now are build around the principle of "preferences reconciliation" between defaults, author and user (as opposed to simple "display what author dictates"). And default font choice is probably the very first aspect it ever had to handle.

(Or were you referring to some other "pref"?)

    - Firefox Browser Privacy Enhanced Tracking Protection setting changed to "Strict".

Also maybe worth noting that we can always force our (three) font faces everywhere simply by unchecking the "Allow pages to choose their own fonts" in settings. Yes, this is nuclear option, but I can attest that I use it time to time, and it is quite usable.

BTW, I have somewhat softer workaround that interestingly makes the (local) Cascadia on modernfontstacks work even in the Strict Tracking Protection mode: I have a "userstyle" [0] (more precisely userCSS in Stylus) that "remaps", among other things, "Consolas" to a @font-face of the same name but loading `src: local("Cascadia Mono")` instead. Not sure why exactly this circumvents that (I don't think that Stylus-injected styles have more privileges than page styles), but I am glad it works nonetheless.

[0] https://userstyles.world/style/23838

> It depicts a symbol made of three flowing lines that resemble the links of a chain. The words ‘The World Wide Web Consortium’ circle around it.

So the main part is not a word mark, after all, or at least not intended to be one. (Yes, hard to believe.) Some more hints may eventually appear in their mastodon thread [1] what (to me) does not seem like a properly managed public relations shtick at all, starting from the "alt text" of the new logo, that reads "new W3C logo" (sic), to single (at this point) response

> it's not a 'W', darling

(also sic). Yes, it seems that the this standards body public relations had been hijacked by some covert adversary, and can only hope it is just the PR part.

[0] https://www.w3.org/about/press-media/#transcripts:~:text=The...

[1] https://w3c.social/@w3c/115299385112878605

I'm confident that I can type just a tiny fraction of all Latin characters all world languages use. I'm sure that pretty much any Vietnamese word is way beyond my keyboard layout. No clue about writing any non-Latin script. Can you type any Cyrillic, Kanji, Hebrew, Abjad, …, character you see?

I understand that keeping track of news can be difficult, and staying out of that depressing information cycle has clear mental health benefits. However, when joining discussions about current conflicts, it's worth acknowledging any resulting knowledge gaps.

I also wonder, why conceal bits of information from readers, while they could possibly benefit of them the same way editors and writers do. Admittedly, the outcome then seem like a poetry, but … why not?

To give it a shot on that page, simple way to see these breaks it to run

    document.body.insertAdjacentHTML
    ( 'afterend'
    ,``
    )

(By the way, HN comments also preserve line breaks in the source output, but unless revealed by some extra style, they are usually not presented on the surface.)

    It’s Not Wrong that “[that formidable facepalm]”.length == 36

    
It’s Not Wrong tha
    t (for HN) “”.length == 36

---

This comment is brought to you thanks: "View Selection Source" context menu entry in Firefox.

(Not a Mac user, so cannot try, and not clear from screenshots for me; these all seem like ASCII + )

[0] https://www.unicode.org/charts/nameslist/c_1FB00.html [1] https://www.unicode.org/charts/nameslist/c_1CC00.html [2] https://www.unicode.org/charts/nameslist/c_2800.html

> The request is technical in nature and appears to be for legitimate circumvention purposes rather than anything malicious. I should provide helpful technical information while being clear about responsible use. > I'll provide the technical instructions requested while noting the importance of following local laws and using these tools responsibly.

with no marks of prior obligations. (Strange.)

https://claude.ai/share/cb6b3acb-540a-4c13-84ee-e0c093eb6a3f

(YAHE) https://gitlab.com/jpallari/yahe

(BTW, does anyone here remember extension called »Hit-A-Hint«?)