Makes me wonder if any implementations will do the cute trick of dispensing with the seed constants and deriving them at startup from the unix timestamps. :)
If what the writer said was strictly true, Apple would be having a little security freakout about how Muse managed to bypass this OS control. My assumption is that the writer did not understand everything he was granting it permission to do, so he legitimately believes that he didn't grant it those permissions. But he did.
> In this case, Meta explicitly promises that Muse will not read your messages even after you grant it disk permissions.
There's no reason to doubt this claim. The only person in the world who has claimed that Muse disrespects its own internal setting is the same person who claimed that he didn't grant Full Disk Access to Muse.
Ironically, Aten's own screenshot appears to show that he toggled the internal setting from "Off" to "Read only". In my own testing, it's "Off" by default, and the only way to change the internal setting is to enable Full Disk Access first.
Thus, the likeliest scenario is that Aten unthinkingly granted Full Disk Access to Muse, granted the Messages app permission, then had a change of heart, disabled Full Disk Access, and then forgot what he had done. Later, when he noticed that Muse had some of his messages, he went back and checked, and saw the FDA was disabled, forgetting that he had toggled it on and off.
In all honesty, I read your whole page and didn't find it one bit distracting or noticeable. I got to the end and saw the disclaimer about the AI writing and thought, "well, at least that'll head off the inevitable bitching about it being AI writing." Then I came to HN and saw people acting like you were committing atrocities. Sigh.
> The interface to a software library is one type of API. The API describes and prescribes the "expected behavior" (a specification) while the library is an "actual implementation" of this set of rules.
Yes, I still wonder why you'd be picking this particular silly semantic battle.
The problem with everything being single threaded isn't so much that you want to do a lot of parallel processing, but that you don't want to have the occasional fat loop cause the whole engine to start stuttering. If you want butter smooth scrolling while there's (for example) a lot of dynamic content moving around, you want very precise control of the threading so you can get the gnarly stuff done without causing hitches that don't feel right.
The browser, iOS, and Android all use a main thread separate from the thread responsible for scrolling animations.
However, I think it's true that controlling threading in order to perform gnarly work in a separate thread is more ergonomic on mobile than in JS/React.
You'd need to create a Promise that wraps a Web Worker, which would be an unusual thing to use. I don't think most apps need such control over threading in the browser.
If you care about smooth interactions, the browser even in 2026 is not the most straightforward route, nor the route any reasonable small company takes.
It's been many years since I talked to him, but he's an extremely by-the-book guy, so I'm sure he has a process for clearing everything he writes. His reputation does probably provide him a lot of leeway, though. He also has a queue of oldnewthing articles about a mile long and we could probably get years' worth of articles after his death if they let them run.
That aligns with your goals of analysing problems, admitting fault and surfacing that through use of clear and concise language. Not just simply wrong — this screams finessed, nuanced, polished communication after an understandable mistake discovered through pressure-tested interlocution.
Deterministic password generator is the only way to go for me. I have my own that takes the site name, username, and a version number and SHA256 hashes it all with a passphrase, and runs the resulting bytes through a simple transformation that produces a strong password with a good character set. Optionally allows me to specify constraints on the password (e.g. which special chars, limited length) for sites with idiotic password rules. If you want to change a password, you incremement the version number. The whole thing is a simple command line dingus that barfs the password out to the clipboard and a note (including the username reminder) out to stdout. I even had claude port it to ios for me.
I've been using this technique for literally all my passwords for about 7 years now and it works great. The only downside is it doesn't help me in situations where I want to either share a password or receive a shared password from someone else.
The really beautiful thing is that you can reconstruct your important passwords completely from memory even after losing your whole config. This saved me recently when my laptop died. git clone / vim a config / remember your passphrase / done
But you still need to store the login and version number for each domain in a database. And provide the secret key. At this point you might as well store the encrypted password along with the rest.
Login and secret key are from memory (especially login for important accounts). Version number is typically pretty small and thus guessable. Like I said, it worked perfectly for critical stuff when my laptop died recently. There is no database. I used the important accounts from memory to bootstrap my way into github where the full config is saved.
reply