infosex.exchange <3

You are probably looking for the infosec.exchange Mastodon instance

This host is mostly for my random stuff, and in little part acts like a well-intentioned placeholder for the typosquatted domain.

Discoverability and Archiving

Currently I'm using this host for saving the items from my own feeds to the Wayback Machine and provide in-links for search engines. I hate that I have to do this, but the non-sense ideology of Mastodon pretty much ruined the search feature for Fediverse as a whole, and this wasn't changed by the fact that they owned their mistake and implemented search eventually.

Yes, I (or anyone else) could do similar things with other peoples published feeds, regardless of the tantrum. No, you can't defederate this, because the process doesn't rely on an instance.

Gluttony Section for Search Engines

[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
this post | permalink
[RSS] STAR Labs Windows Exploitation Challenge 2025 Writeup

https://starlabs.sg/blog/2025/03-star-labs-windows-exploitation-challenge-2025-writeup/
this post | permalink
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
this post | permalink
I'm kinda getting used to Space Emacs but eshell quickly became my arch nemesis
this post | permalink
@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.
this post | permalink
@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.
this post | permalink
Validating Leaked Passwords with k-Anonymity - from #CloudFlare blog, 2018:

https://blog.cloudflare.com/validating-leaked-passwords-with-k-anonymity/
this post | permalink
@cR0w @mark In fact, it was CF that contributed k-anonymity to HIBP:

https://blog.cloudflare.com/validating-leaked-passwords-with-k-anonymity/
this post | permalink
@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...
this post | permalink
@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
this post | permalink
Next Page