Some really impressive work from my old team here: https://forums.swift.org/t/the-future-of-serialization-deserialization-apis/78585

If you care about Codable and/or serialization in Swift in general, definitely check it out

#swiftlang #swiftevolution

[RSS] Dubious security vulnerability: A program does not run correctly if you run it the wrong way

https://devblogs.microsoft.com/oldnewthing/20250317-00/?p=110970

[RSS] STAR Labs Windows Exploitation Challenge 2025 Writeup

https://starlabs.sg/blog/2025/03-star-labs-windows-exploitation-challenge-2025-writeup/

Exciting: The Ghost team has just released the beta version of its ActivityPub support for people using their hosted service

https://activitypub.ghost.org/social-web-beta/

Just spent ~an hour figuring out why a code path wasn't hit.

Turns out it was, only my log messages were configured to a level too low to appear...

#fail

Get your speaker submissions in TODAY for early consideration at this year's HOPE conference! @hopeconf https://www.2600.com/content/early-deadline-hope-talk-submissions-monday

I'm kinda getting used to Space Emacs but eshell quickly became my arch nemesis

Project: mpengine-x64-pdb 1.1.24090.11
File: mpengine.dll
Address: 75a1eaec0

load_page

SVG:
dark https://tmr232.github.io/function-graph-overview/render/?graph=https%3A%2F%2Fraw.githubusercontent.com%2Fv-p-b%2Fghidra-function-graph-datasets%2Frefs%2Fheads%2Fmain%2F%2Fmpengine-x64-pdb%2F75a1eaec0.json&colors=dark
light https://tmr232.github.io/function-graph-overview/render/?graph=https%3A%2F%2Fraw.githubusercontent.com%2Fv-p-b%2Fghidra-function-graph-datasets%2Frefs%2Fheads%2Fmain%2F%2Fmpengine-x64-pdb%2F75a1eaec0.json&colors=light

Of all the #StarTrekProdigy memes I’ve seen, this one hits the hardest for me.

@cy @cR0w If you read carefully you'll see that I applied Hanlon's Razor to the blog post, not the operational practices. On that part my argument is that they'd need to go far out of their way to do evil, which doesn't mean they don't do it, but I'm pretty sure they won't do it for a security-awareness blog post.

@cR0w @mark Yes, a MitM-as-a-Service provider *may* see and misuse your passwords.

Does this particular stat make any difference to that equation? No.

Validating Leaked Passwords with k-Anonymity - from #CloudFlare blog, 2018:

https://blog.cloudflare.com/validating-leaked-passwords-with-k-anonymity/

@cR0w @mark In fact, it was CF that contributed k-anonymity to HIBP:

https://blog.cloudflare.com/validating-leaked-passwords-with-k-anonymity/

@cR0w @mark As I see what needs clarification here is the security/privacy guarantees of the HIBP system (that's been around for some time), as that is the one accessing sensitive data. In a good architecture it should be impossible for that data to leak during/after real-time analysis, making the dispute about this particular statistic mute.

And again, let's not forget that participating origins agreed to this type of data use (hell, they may even need to configure what fields to snoop on!) - I wonder if their end-user privacy policies include this detail...

@cR0w I agree the post is far from optimal, but try to look at it this way: in a system as big as CF's you rarely see individual request data, but you can correlate HIBP alerts with status codes and write a blog post with big %s about password stuffing. You don't write about anonymization because you never saw anything that'd need anonymizing so there's nothing you did that's worth writing about. Again, I agree this should've been flagged by PR, but we've seen bigger blunders from that department...

#HanlonsRazor

@wdormann fulldisclosure () seclists org

I simply cannot. even.

@cR0w Mishandling the data is surely a concern, but I don't think this particular case is an indicator of such misuse:
HIBP API is anonymized in the first place. They must already have an "even more" anonymized yes/no signal from their detection service (whether it's using the anon API or a full HIBP copy), and at CF's scale I don't think anyone wants to receive all the non-anonymized request fragments for perf/bandwidth reasons alone.

Sure there may be an evil team at CF who secretly look at creds, but this stat is not an evidence of that.

This was one of the instances of insecure openid connect keys I blogged about recently https://blog.hboeck.de/archives/909-Mixing-up-Public-and-Private-Keys-in-OpenID-Connect-deployments.html the host auth.univie.ac.at has an openid connect configuration file. It points to https[://]auth.univie.ac.at/jwk for its jwks_uri that contains the public keys. Apparently, one of those keys is an example key used in the software "OpenID-Connect-Java-Spring-Server". Therefore, the private key is what I like to call a "Public Private Key".

@cR0w I mean users seem to have explicitly asked CF to look at the credentials passing through them. I don't get how workstations come to the picture, please clarify!