k_sze

The author says that "In a perfect world, RMSDK would just stop living in the CSS stone-ages or at least provide some kind of error handling instead of dropping the whole book, but I’m not holding my breath."

This is blatantly wrong.

In a perfect world, RMSDK wouldn't exist in the first place and Adobe would have gone bankrupt and become history at least 10 years ago.

Nice work!

Is there a sensible way to add a cooldown to Docker/Podman image pulling?

Another shameless plug for my PeerAuth project, which can also tackle this problem. https://ksze.github.io/PeerAuth/

And this is when we realize that the title deserves a [2019] tag.

Wrong layout. The Xbox layout is the only correct layout. I’ll die on this hill. :P

Erm, so why wouldn’t I just use WhatsApp as a PWA? I wouldn’t even need to waste the disk space for yet another browser runtime.

I was very confused, too. I mean, I do have a YubiKey but Twitter/X has never (or for a very very very long time not) asked me to use my YubiKey to authenticate. As far as I could remember, I only need to use OTP from Authy as 2FA to login. So the whole thing smelled really fishy.

It's interesting how they use "Gundam" in their variant names. I gather that Gundam-M and Gundam are their most powerful ones.

It's odd. It seems like this is not the first Japanese team to have developped artificial blood. I did a quick search and it seems there was another team at least as early as 2019 (https://web.archive.org/web/20201111233217/http://www.asahi....)

So what's different this time?

(Upon further examination, the 2019 team at the National Defense Medical College also had Dr Hiromi Sakai. So why is this news now?)

Why did Apple call it M3 Ultra when it's supposed to be more performant than the current top of the line M4 Max? Why not just call it M4 Ultra?

Oddly, the Chinese LLM host SiliconFlow only makes it available with 32k context, which is even smaller than their DeepSeek-R1 offering.

You're confusing Kaspersky with Kasparov, perhaps?

I'm in Canada and I just get auto-redirected to the kaspersky.ca home page when I try to visit the link.

One thing I don't understand is how the surgeon ensures the lens is positioned correctly. We're talking about a rigid lens that can no longer be controlled via muscles, right? Doesn't any misalignment mean you get a fuzzy image at best? And even if you can get a sharp image for some given, fixed distance, you still can't control whether to focus on near things or far things when you look, right??

Practically speaking, is it possible for NVIDIA to "pull the rug" later, intentionally or otherwise, by subtly changing the behaviour of this out-of-doc instruction on new architectures?

I think that the scenario you describe requires one of two conditions:

  1. The attacker knows the time and medium through which the two persons call each other, and have control over the medium, being able to inject themselves;
  2. The attacker coerces one of the two persons to perform authentication.

That sounds interesting! I'm looking forward to seeing what you build.

I'll try to find an SVG-based QR code library.

I asked Google Gemini 2.0 Flash and Perplexity.ai, the QR code display problem on Tor Browser for desktop appears to have to do with the browser's anti-fingerprinting mechanism.

This is the explanation that the AIs gave me:

# begin explanation The issue you're experiencing with QR codes showing up as vertical stripes in the Tor browser when using QRCode.js is due to Tor Browser's anti-fingerprinting feature.

Tor Browser is designed to protect user privacy, and one of the ways it does this is by randomizing the output of the HTML5 Canvas API. QRCode.js uses the Canvas API to draw QR codes. When Tor Browser randomizes the Canvas output, it distorts the QR code image, causing it to appear as vertical stripes instead of a readable QR code.

This is a known issue and is intentional behavior in Tor Browser to prevent fingerprinting. Fingerprinting is a technique websites use to uniquely identify and track users based on various browser characteristics, including how the browser renders content like Canvas elements.

Here are the solutions based on my research:

Lower Tor Browser's Security Level: The simplest workaround is to temporarily lower Tor Browser's security level from "Safer" or "Safest" to "Standard". You can do this in Tor Browser's settings under "Privacy & Security" -> "Security Level". Setting it to "Standard" disables the Canvas fingerprinting protection, which should allow QRCode.js to render QR codes correctly. However, this will slightly reduce your privacy while using Tor Browser.

Use a Different Browser: If you need to generate QR codes reliably and use them, the most straightforward solution is to use a different browser like Safari, Firefox, or Chrome, as you've already observed that the QR codes work correctly in these browsers. You can use a non-Tor browser specifically for generating and scanning QR codes, and then switch back to Tor Browser for your privacy-sensitive browsing.

Advanced Configuration (Not Recommended for Most Users): For advanced users, it might be possible to modify Tor Browser's about:config settings to disable specific anti-fingerprinting measures related to Canvas, such as canvas.poison or privacy.resistFingerprinting. However, this is strongly discouraged unless you fully understand the privacy implications, as it can weaken Tor Browser's privacy protections. It's generally better to use one of the first two options.

In summary, the striped QR code issue is a trade-off between strong privacy protection and website functionality in Tor Browser. Tor prioritizes privacy by randomizing Canvas output, which unfortunately breaks some features like QR code generation using libraries like QRCode.js. The recommended solutions are to either temporarily lower the security level in Tor Browser or use a different browser for QR code related tasks. # end explanation

As well as the proposed solution: # begin solution The issue with QR codes appearing as vertical stripes in Tor Browser when using QRCode.js is due to Tor Browser's anti-fingerprinting feature, which randomizes the Canvas API output. This intentional behavior to protect privacy disrupts QRCode.js's ability to render QR codes correctly.

Solutions include:

1. Lowering Tor Browser's security level to "Standard".

2. Using a different browser for QR code generation.

3. Advanced users can modify `about:config` settings, but this is not recommended.

The recommended solutions are to temporarily lower the security level in Tor Browser or use a different browser for QR code related tasks. # end solution

Looks like the problem is with the desktop Tor browser. I can see that the QR codes are displayed as two square images with coloured vertical stripes instead of real QR codes. That's such as weird problem.

In any case, I have just added the display of the base32 secret key.

OK, I can make it output the secret as text.

Desktop or mobile?

This has been fixed. After every click of the "Generate" button: 1. any existing QR codes are replaced; 2. the new QR codes scroll into view automatically.

Actually the QR codes should be replaced if you click "Generate" multiple times. I guess that also needs to be fixed.

Yes, that's what I had in mind. Wait at most 30 seconds, the code will then have rotated and the roles can be reversed.

Hmm, I wanted to require less fiddling around by the user once the QR code is scanned, which is why I generate two QR codes that encode the same secret but with different labels.

Thank you for the feedback! I’ll try to see what I can do about it. Perhaps make the QR codes display in a modal in front of the original content. Alternatively, I can try having the page automatically scroll (with ease-in and ease-out) to the QR codes.

I’m glad you like it. The whole thing might be a bit paranoid, but it was a fun exercise trying to get an LLM to code for me (I used DeepSeek to code the base, and then manually fixed some stuff, and then asked DeepSeek to add i18n for me).

This is a little stupid project that I created after seeing what AI can do nowadays.

In an "ideal" world:

- everybody should start using public/private key cryptography to authenticate each other, but that's still rather unwieldy nowadays. I'm not aware of any solution with a good UX;

- people would stop posting their photos/videos/audio recordings on the web, and also scrub anything that have been uploaded in the past.

We don't live in an "ideal" world, and TOTP is pretty widespread now, and you can easily read the TOTP code over the phone, etc. So this solution was born.

Right off the bat, 小念頭, siu2 lim6 tau4 seems to be incorrectly romanized. 念 should be nim6, not lim6.

lim6 is what we call 懶音 (literally "lazy pronunciation").

The statement that "Cantonese has no formal standardization for its phonetic and writing systems" deserves a better explanation. There are in fact multiple standards, as can be seen on the website of the Multi-function Chinese Character Database developed by the Chinese University of Hong Kong:

- https://humanum.arts.cuhk.edu.hk/Lexis/lexi-mf/initials.php

- https://humanum.arts.cuhk.edu.hk/Lexis/lexi-mf/finals.php

- https://humanum.arts.cuhk.edu.hk/Lexis/lexi-mf/tones.php

When you search for a Chinese character on the Multi-function Chinese Character Database website, by default, it will give you the jyutping (粵拼) romanization (you can select a different romanization system from the drop-down at the bottom left of the screen).