regarding metadata on Signal

I bought some cheap Chinese 2-way radios. The packaging has a big American flag and a “Designed in U.S.A.” claim, which I suspect is bullshit given the company involved. Also, there are two Bible verses referenced. This smacks of pandering to a particular slice of conservative Americans. All I want is cheap radios for skiing with my kids next winter, not a reminder of my country’s socio-political bullshit.

This bullshit is not from the well-known Chinese radio maker Baofeng (baofengradio.com) but rather from a US company called “BTech” which has the deceptive URL BaoFengTech.com.

something from the “stable ports” list at https://www.rockbox.org/

Can someone tell me what vibe coding is?

a term coined 6 months ago for writing software using an LLM https://en.wikipedia.org/wiki/Vibe_coding

No evidence of this happened. Blocked.

lol what? it is a pretty well-sourced article, with the main source being remarks in a video which it helpfully links to.

it is 10h long but on youtube one can search the transcript and easily find the parts that form the basis of this article: here are Secretary Burgam’s comments and here is Porat referencing them later.

all emails are checked for accuracy. Closed AI is not publicly accessible and has better privacy and security than “open AI” systems.

🤔

1, 2

I’m pretty ignorant of encryption algorithms. This article doesn’t seem to mention side-channel or GPU cracking attack resistance, which Argon2 addresses. KeepassXC’s default right now in ChaCha20-Argon2id.

The key space of a high-entropy 256-bit key is not brute-forceable. Generating a 256-bit key from a lower-entropy string like a passphrase is where you need to be concerned about resisting brute force attacks, but that is orthogonal to the question of how to do encryption using that key.

When KeepassXC says it uses “ChaCha20-Argon2id” i assume this actually means that they are using ChaCha20-Poly1305 with a key derived from the user’s password by Argon2id.

The ChaCha part is the symmetric encryption, while the Poly1305 is for the MAC.

This proposal is, for performance reasons, to replace ChaCha20 with ChaCha12 (which is believed to still provide an adequate amount of security) and to replace the Poly1305 MAC with BLAKE3. The performance gains aren’t particularly relevant for applications like KeepassXC which only needs to encrypt a small amount of data at a time, but as you can see from their benchmarks they’re substantial for applications like TLS where a lot of data needs to be encrypted.

Part of the reason they don’t mention Argon2 here is because in the sort of setting they’re designing for, you don’t typically derive keys from lower-entropy strings like passphrases. But, if you did want to key ChaCha12-BLAKE3 using a passphrase, it would still be a good idea to derive the key using Argon2id!

paywall bypass: https://archive.is/mdi9x

paywall bypass: https://archive.is/mdi9x

some context.

(tldr: libxslt is a significant source of vulnerabilities and it should absolutely be removed from browsers ASAP.)

some context.

(tldr: libxslt is a significant source of vulnerabilities and it should absolutely be removed from browsers ASAP.)

if they do something, it’s not in your interest

this is often true, but sometimes (like in this case) they are actually doing things that are in (almost) everyone’s interest: making browsers more secure 🙄

(see my other comment in this thread for details)

if they do something, it’s not in your interest

this is often true, but sometimes (like in this case) they are actually doing things that are in (almost) everyone’s interest: making browsers more secure 🙄

(see my other comment in this thread for details)

fuck google generally, but in this case that mastodon post’s characterization that “Respondents overwhelmingly reject the suggestion” is not accurate - lots of people in that thread are in favor of removing it and those who aren’t aren’t making a strong case to keep it.

imo client-side XSLT never needed to be implemented; afaict its primary use is styling RSS feeds and I doubt many people ever actually read RSS feeds styled that way even if millions of feeds are/were.

tldr: This obscure “feature” is a significant source of vulnerabilities which attackers are able to compromise endpoints with right now. The GNOME project’s libxslt is used by all modern browsers and has been largely unmaintained for a long time, and it is a pretty sure bet that it has lots more remotely-exploitable bugs (in addition to those which have already been discovered and not yet fixed, or for which fixes are not yet widely distributed).

it sounds like there is also a mostly-working JS replacement for this C++ code; if it is actually possible to ship that and avoid breaking any sites it would be preferable, but, otherwise, i for one would certainly be in favor of dropping browsers’ XSLT support (which was only ever for XSLT 1.0 anyway!) completely ASAP.