myfonj

I think that the domain knowledge still matters: if for nothing else, then at least it can make the communication both with savvy AI tools and savvy humans more effective compared to "outsiders": acquired vocabulary, truly grokked concepts in the field of target expertise etc… -- that all seem like a huge competitive advantage over folks having to learn all that "on the go", constantly struggling to pick the right nomenclature or using wrong or vague terms. It's mostly that domain knowledge what makes experts understand problems faster or at all, even.

myfonj

2 か月前議論

> Chasing enemies is much more annoying than them coming to you, so that would be a punishment to the player.

It seems I've failed to express myself clearly. The idea was that at some point, "low-level" adversaries simply stand no chance against a "high-level" PC, which should be obvious to both sides -- so acting accordingly on both sides would make sense without taking the fun out of the game, because -- and hear me out -- at that point in the game, chasing the low-level minions should be the last mechanic the player is forced to endure. When you are going for a dragon, you should not be forced to stomp your way past overly self-confident "newts" or mow down swarms of goblin youngsters…

Naturally, if the PC chooses to chase minions fleeing in terror after they took out the most courageous (or silly) third of their clan, that should be an option… and arguably it could even bring some satisfaction after the PC's low-level struggles, perhaps. But should this be the main mechanic? Definitely not -- at least not in the kind of game my thought experiment addressed.

myfonj

2 か月前議論

Sure, but I don't think they must be mutually exclusive; on the contrary: in the late stages when your character is a tank, swarms of minions that posed a challenge in early stages become just a nuisance, mostly. You are walking legend slaying dragons for breakfast, everybody and their dog knows about your invincibility … but instead of giving you some respect, they try to bite your heels on the first sight. I guess the "fun aspect" of seeing them flee and not restraining your movement at all could be slightly more satisfying than taking them down in a single hit one-by-one for the thousand time.

myfonj

2 か月前議論

> As a result, the game offers no easy satisfaction of hacking and slashing through weaker opponents.

Besides the questionable morality of kill=experience=progress in typical hack'n'slash or roguelike, what started to irritate me in there as I grew older as well, was the stupid mechanics where crowds of enemies described as intelligent humanoids (i.e. not animals or robots) facing clearly overpowered high-level PC (famous, even) never surrendered, almost never tried to flee, attacked one-by-one, and shoved no sign of tactical thinking or self-preservation instinct. Despite being armed and (by description) organised, PC could enter a narrow corridor, defeat dozen of them without taking any damage, yet there will be a waiting line eager for demise by a single hit -- even actively advancing towards it. No attempt to regroup, to take advantage of the number superiority, wait in open space, ambush from all directions, or anything like that. Same applies to most FPS: there is a Doomguy running around at unprecedented pace, slaughtering everything that moves, but we will all keep our scattered positions. (This led me to a thought, whether it would be possible to rearrange enemies in canonical Doom map so that all would attack at once at some appropriate spot and whether it would guarantee their victory or not.)

myfonj

2 か月前議論

Haha, blushing in awkward uncertainty that I've failed to detect irony …? (Is this HN, right?) But even if, thanks anyway! I'm glad I could vent the lore I've spent gathering in unhealthy amount of unproductive research; I cannot imagine better place to finally bury that than deep in super-tangential HN discussion…

myfonj

2 か月前議論

Someone here. OP most certainly knows that precisely, but for the rest: It was Netscape® Communicator, which interpreted everything after `<` up to either white-space or `>` as a tag name. Technically that wasn't even that much incorrect, but amusingly, since the HTML "specs" then still stemmed from SGML, the really correct outcome of ` ` (and even ` ` with a space before the "closing" solidus) back then should have been to both emit the (empty, by definition) BR element (⁕) and a dangling `>` text node after that. No consumer-facing HTML client really implemented that. Netscape simply took it as unknown "BR/" tag and didn't render anything in its place.

In the late '90s Netscape was a niche browser with negligible 80% market share. The real and eternal XHTML enlightenment had begun a few years later, in the early 2000s and reached near eternal duration of seven years.

Also, https://jakearchibald.com/2023/against-self-closing-tags-in-... provides a broad perspective on the topic (but I guess it is very unlikely anyone reading this hasn't seen that article already).

Practically, using ` ` in HTML with space was safe, like, forever, except for original W3C validator and Amaya. Using ` ` is safe since around 2002-2008 when Netscape was dying. In 2026, you can throw basically anything at current browsers and it will repair it to something meaningful, as per the living HTML spec. You can go `</br/r/r>`, if you are really into solidi, and it will work the same as ` `.

Disclosure: I also clearly see how having stupid simple "XML-like" syntactic rules would be beneficial in the grand scheme of things compared to what HTML became: memorising the "VOID" HTML elements by heart, and having to implement this in every HTML processing product clearly creates significant mental and processing overhead. But FMPoV, it's just one inconvenience we should begrudgingly accept at this point, rather than fight it.

(⁕) In reality, the way browsers treat ` ` in the document flow is more like a text node than element node, but it's just an implementation detail orthogonal to this topic.

myfonj

2 か月前議論

[dead]

myfonj

2 か月前議論

Plus, when curious about formal syntactic correctness, there is the validator.w3.org [1].

[1] https://validator.w3.org/nu/?showsource=yes&showoutline=yes&...

myfonj

2 か月前議論

Fair point, though /DT and /DD are also optional just like /TH, /TD and /TR are. So in effect, def…scription list could structurally save you one TR for each entry and two "BLE"s:

    <table><tr><th>Term 1<td>Definition 1
           <tr><th>Term 2<td>Definition 2
    </table>
    <dl><dt>Term 1<dd>Definition 1
        <dt>Term 2<dd>Definition 2
    </dl>

myfonj

2 か月前議論

Ran into this discrepancy myself. On top that, what seemed also odd to me were the "dots" (tittle, period, semicolon) where oversized becomes hollow in the middle, like it cancels out itself. No other shape I've tried did that. And browsers surprisingly agreed on this.

Made few shots and playground for that back then: https://x.com/myfonj/status/1870178380831732160

myfonj

3 か月前議論

When (rarely) using hex editors, one thing constantly comes to my mind: isn't base 16 arabic-roman numerals a bit awkward for "skimmable" overview? Color-coding indeed helps immensely there, but wouldn't simply letting bits and bops shine in eight bit clusters, resembling the "physical" shape of the eight-bit byte, be somewhat more readable?

We even have characters in the Unicode for representing 0..255 variations, actually two distinct groups: Braille (arguably a bit misuse for binary) and octants (accompanied by older predecessors). So what would be

    |65|97|66|98|67|99|32|126|32|72|101|108|108|111|44|32|109|111|109|33|32|240|159|166|132|

in base-10 or

    |41|61|42|62|43|63|20|7e|20|48|65|6c|6c|6f|2c|20|6d|6f|6d|21|20|f0|9f|a6|84|

in base-16, could be

    |⢈|⢊|⡈|⡊|⣈|⣊|⠂|⡾|⠂|⠌|⢪|⠮|⠮|⣮|⠦|⠂|⢮|⣮|⢮|⢂|⠂|⠛|⣵|⡣|⠡|

in Braille, or

    |𜵲|𜵶|𜴷|𜴻|𜶭|𜶱|𜴀|𜵯|𜴀|𜴋|𜶔|𜴭|𜴭|𜷟|𜴫|𜴀|𜶢|𜷟|𜶢|𜵴|𜴀|(⁕)|𜷢|𜵖|𜴙|

using octants.

Most significant bit is at the top left here, the least one is bottom right -- it felt somewhat intuitive to me this way, your intuition may differ, obviously.

Or, naturally, "AaBbCc ~ Hello, mom! <Unicorn Emoji>" as a "UTF-8" text.

Try: http://myfonj.github.io/tst/byte-dec-hex-braille-octant.html) Test (with added "CSS" variant and "highlight" of empty dots): http://myfonj.github.io/tst/byte-visualisation-exploration.h...

(⁕) HN apparently eats upper-half block. Amusing that only this particular ("old", as referred earlier) one got filtered out…

Also caveat: Android phones have messed-up Braille block due outdated broken embedded font, so all patterns with dots in the left half appear in the right instead. Long reported, not fixed, IIRC.

myfonj

3 か月前議論

That's peanuts. LI's third-party bot prevention service, "protechts.net", took 42 GB RAM on my laptop with 32 GB the other day. Obviously found out because it got suspiciously slow and wheezing, and Firefox swapping like crazy seemed to be the culprit. Looking at its performance, this scare jump happened: [1].

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

myfonj

6 か月前議論

These "dots appearing only while (not) focused" are known as "extinction illusions", namely

    "25 - Appearing Dots"

is "McAnany's type" [1], and

    "26 - Disappearing Dots"

is known as "Ninio's type" [2], according Akiyoshi Kitaoka's materials. (I have recreated them too few years ago [3][4], before getting to the source.)

[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)

myfonj

6 か月前議論

The "guesswork" done by browsers is actually pretty nuanced and not standardised in a slightest way. Some defaults are pretty common, and could be maybe considered de-facto standard, but I wouldn't want to draw the line where "most" browsers agree or should agree.

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.

myfonj

9 か月前議論

> I am an app developer. How do I protect my users? > We are not aware of mitigation strategies to protect apps against Pixnapping. If you have any insights into mitigations, please let us know and we will update this section.

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.

myfonj

9 か月前議論

Ha ha, really glad to hear that. (The fact is, I am kinda freak/junkie about human voices, and that particular one stands really high on my list of irresistible tingles-inducing specimens. So happy to hear I am not alone.)

myfonj

9 か月前議論

I've made something (probably) very similar for quick GB vs US pronunciation check that also leeches on Google's snapshot of what I believe is a licensed copy of the Oxford collection the same way the shell script does, but mine "runs in browser's URL bar" instead. It's a super tiny dataURI HTML document, intended to be bookmarked with a keyword (say, "say"):

    data:text/html;charset=utf-8,<title>US-GB pronunciation 2.0.2</title><body text=snow bgcolor=black><button id=i placeholder=(shift+)tab value="%s"><button id=a

so when I do

    Alt+D, "say something", Enter

then hitting Tab plays it in British and Shift+Tab plays it in US English. It uses older 2016 batch, because I totally adore the US voice in it: just listen to "music" [1] and tell it isn't pure ASMR.

(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...

myfonj

9 か月前議論

> I do think an interesting approach would be a browser extension that lets you override the prefers-color-scheme property on a per-domain basis, similar to the toggle in dev tools.

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/...

myfonj

9 か月前議論

Good question! Actually (to my minor dismay): not completely. Disabling "font support" in Firefox surprisingly still has a hatch for "well-known" icon fonts, with intention to prevent "blind" icons in webpages. I believe it is driven by the pref

    browser.display.use_document_fonts.icon_font_allowlist

that contains "FontAwesome" and (Google) Material Icons and Symbols (many, presumably all, variants). So to truly disable all "non-preferred" fonts, we have to both wipe that pref and also change for the

    browser.display.use_document_fonts

to zero. But that's what the GUI checkbox controls, so no need to go to about:config for this one.

myfonj

9 か月前議論

> Great! Then the user gets his preferred font, as requested, instead of the one the page specified.

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: <list of fonts their system does *not* support or does *not* allow to be used>, monospace;

. But the case is that the suggested font stack contains some "unwanted" font that their system both supports and allows to be used, that precedes the generic `monospace` font family the user actually prefers, or, more precisely, have assigned their typeface to. Is it more clear now?

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.

投稿

CSP: Bookmarklets should bypass pages' policies (2013 → Infeasible 2026)

Who's Running Last.fm Now?

コメント