The effect of AI on growing security /crypto conferences: "I have published more papers in top tier security and crypto venues then all 5 of my r1 co-reviewers for usenix COMBINED"--junior collaborator of mine. IMHO, at best , we will get boring nitpick free papers out of this.

In a few months we will have: "Muse: Hey girl, I know you still think about him, want to see where he's been?" And guides like we got with Venmo:

She thought she had nothing to hide, flock and the police thought otherwise.

Meanwhile the only phishing I get on LinkedIn is someone trying to get me into a data science master's. Which might actually be more financially damaging.....

If someone finds a side channel on this, is it a vampire attack?

My 2018 talk "Satoshi Has No Clothes: Failures in On-Chain Privacy" is still a decent summary of bad privacy designs for blockchains. slideslive.com/38911785/sato… New since then: FHE shielded pools. They make some sense for dark pools, but the global decryption key FHE requires, even if split over n servers, makes them a bad fit for pure payments. Monero went from 10 to 15 decoys and plans to move to full-chain membership proofs (FCMP++) at some point. Oh, and Zcash proving went from 2 seconds on desktop to <400ms on an iPhone.

Privacy isn't dead. AI didn't kill it. AI killed "I have nothing to hide." It's never too late to start hiding new things. You might want to criticize your government someday. Or book a vacation at the everyday price, not the one made just for you and your recent promotion.

What happens to Crypto/Eurocrypt when a proof of security becomes easy? Everyone's first instinct with AI papers is to raise standards, reject misformatted or technically incorrect papers. But it won't work forever. How do you define taste if those (poor) proxies are gone?

Are STARKs zk yet? In theory zk by blinding is easy. In practice, implementations didn't do it, leading a few of my colleagues to wonder about feasibility. Claude tells me: "StarkWare has Shieldnet, a private payment pool, proven with Stwo. But I can't find the documentation for the zk part — no blinding parameters published, and their Lean verification work targets soundness."

“Who’s a good boy?!” Hackers just dumped the contents of a Flock camera. They found: 🔴Software explicitly detecting people, not just plates 🔴1.6 million images logged in 21 days 🔴Key to decrypt files stored on the device itself. Finds directly contradict Flock, which claims someone with physical access can't access images. Making it worse,@GainSec warned about the physical access issue more than a year ago & Flock downplayed it. And yeah, the Flock camera logged “Who’s a good boy?!” about every 2 minutes, all while plagued with errors, crashes & reboots. By @dmehro & @josephfcox wired.com/story/hackers-floc…

Apple's new "Reference Image" design suggests something Apple won't say out loud: they don't actually trust the iPhone's Secure Enclave that much. They're probably right, and that has implications both for other proposals to stop deepfakes and for privacy-preserving identity, if it ever gets beyond stopping kids from looking at porn. Reference Image is a mode in the iPhone camera where Apple's servers sign a photo as genuine. The phone sends the raw data, signed by its trusted hardware, to Apple's Private Cloud Compute (PCC) servers, which process it, apply edits, and sign the result. It hides who took the photo, though Apple appears to keep identifying data so it can revoke photos from hacked phones. But why involve Apple's servers at all? It costs money and adds risk for Apple, like demands to deanonymize journalists, so they really have to get Private Compute Right. Maybe Apple couldn't get the image pipeline running inside the Secure Enclave. I doubt it. They could have, or could have with some work. But iPhones get jailbroken, and keys can be extracted from the Secure Enclave. If your threat model includes nation states making deepfakes, assume they'll do it. So I think Apple is using PCC as a trusted man-in-the-middle: it sees everything, so it can try to block exploited devices, and adapt as they see what attackers do. The other thing that relies on secure hardware is privacy-preserving credentials. Google's zk-id proposal uses hardware device binding to prevent credential sharing, and you might want to verify biometrics at enrollment too. But if we start using this for privacy-preserving KYC in banking and cryptocurrency, or for proof of personhood and deepfake prevention on social media, attackers will try to steal credentials or buy and borrow legit accounts. Device binding is meant to stop this. Apple's design suggests they think it can't.

“KYC” isn't a defined reg term. It's people combining parts of CIP, CDD, EDD, OFAC & recordkeeping rules w/ different req’s. Some allow reliance, non-documentary verification, or risk-based procedures that don't inherently require full clear-text PII, let alone direct escrow.