Notices by Hazelnoot ALT (hazelnoot@enby.life)

@malle_yeno@tech.lgbt @soatok@furry.engineer that's how I felt about the bitwarden auto-enrollment vuln!

Server: pls can I has ur user key? :neofox_bottom:
Client: sure thing bb, here u go! :aqua_happy:

:puppy_dead:

@soatok@furry.engineer Reading this article revealed just how much I've learned from your blogs, because I actually understood all of it!
(my formal cryptography education predates most "modern" cryptography like KDFs and anything newer, so I often struggle with formal papers like this.)

It's not end-to-end encryption if the keys are stored plaintext on the server :neofox_woozy:

@soatok@furry.engineer ok since I don't want to bash on someone who's probably a novice developer trying their best, I want to applaud them for working so hard on this. They've clearly put in a lot of effort and I don't see any signs of AI slop. This project certainly could become something in the future, but right now it should remain a personal learning project. It's just not ready for production use.

@soatok@furry.engineer one-click arbitrary HTML injection with no CSP

@soatok@furry.engineer preliminary audit report:Do not use this.
Fin.

@soatok@furry.engineer yep, just found one :neofox_woozy:

@soatok@furry.engineer I'm 99% sure there's at least one XSS vuln in here, since the client seems to use innerHTML all over the place

@soatok@furry.engineer eyyy and it's also got the exact same CSS injection vuln I reported in Misskey last year :neofox_laugh_tears:

@soatok@furry.engineer I started looking into their app and immediately ran into this pre-compiled EXE that's vendored into the source tree. It has an included readme, but the wording is... odd, to say the least.

I'll share more details about the chat project later, but in summary:
- Targeting discord's niche - non-encrypted, media-rich, and user-friendly "just works" realtime chat.
- Not targeting chat-adjacent features like streaming and voice chat.
- Federated design, with aspects of "true" decentralization to improve reliability and resist censorship. (Comes at the cost of technical complexity.)
- No technical knowledge required to join a community.
- No technical knowledge required to host a community.
- Minimal risk and cost to host online components of the network ("repeaters" and "online communities").
- Encryption across the network (including repeaters), but not full E2E - communities will have a decrypted copy of the full chat history.
- Temporary signatures - communication is signed for authentication, but signatures are trashed after verification. This protects against scrapers and provides repudiation in case a community database is compromised.

oh I almost forgot a big one:
- Support for strong moderation - It should be trivial to run moderation bots, and staff should have access to full chat history. Since moderation runs on the Community server, and the community has sole access to both signed messages and all past decrypted state, it's possible to implement very strong moderation tooling without hacks or workarounds.

(this is in response to Matrix making moderation annoying as fuck, Discord making it hard for bots to reference past state, and Fedi making it impossible to get a full view of anything)

Incoming SMS and RCS audio attachments received by Google Messages are now automatically decoded with no user interaction. As a result, audio decoders are now in the 0-click attack surface of most Android phones.are you kidding me

RE: https://infosec.exchange/users/natashenka/statuses/115901124481157929

Get told "you're using a deprecated library, it needs to be removed".Check GitHub, see that deprecation is because "these features are now widely supported on all browser platforms, so there's no need for polyfill."Check MDN, see that most browsers only got support for those APIs this year and some mobile devices don't ship with a compatible browser.Yeah, this is why we've got an e-waste problem :puppy_dead:

see this is why you don't put hashtags in your ActivityPub object IDs!
WARN [ap] Error validating activity from 81.201.202.98: Cannot re-fetch activity https://mk.absturztau.be/users/a2l8lkf5m7tt003q#updates/1765511014068: returned object is not an activity type { userAgent: 'Misskey/2025.4.4 (https://mk.absturztau.be)', signature: 'keyId="https://mk.absturztau.be/users/a2l8lkf5m7tt003q#main-key",algorithm="rsa-sha256",headers="(request-target) date host digest",signature="Wm4D7XzgV0BvdiGpNlGi++J+zRXl9XUwONXC5Scw4CgjHiIfjBUtx++WnvGOPxYhpe0xnF7a+iT0bI+LTltZjjm0F21L9T4o1PT423+z3LZTm2Dekbogfelw4bUgn3dxP/zt5+4DwQi/V8AxYH38G3WoGh09vvAxAqfirq42iEvOtZorc7ouimWBA7+BdADBXJf/TX7XF4YEOzfvX+2qXJyy+fePXOd2pkqpzdwC3B9pY8e9j6MLYy6Di2ackmtjo+GkEAr1IMeagCArYBhSS0yi8iyvBoNku9uSki6unuJE34s9qJLg6qEJwCb8z+Z8MHuScBMLcA953VVX+0aDZw=="' }
It works great for a bit, then you run into edge cases like this:
1. Instance A generates an activity https://a.example.com/some-object#activity
2. A sends that activity to instance B, which is Mastodon or a Relay.
3. B forwards the activity to C, which validates the signature but doesn't trust the activity since it came from B instead of A.
4. C tries to resolve a canonical copy of the activity, but because hashtags aren't allowed in HTTP the actual request goes to https://a.example.com/some-object.
5. Since A doesn't realize that C wants the activity, it (correctly) returns the actual object some-object.
6. C determines that the returned object does not match the activity forwarded by B, and (correctly) rejects it.

The final result: B is unable to forward the activity from A to C, even though it meets all security criteria, because A's activity ID is unresolveable.

test post, please ignore :)

The domain gimmeloli.cc has been suspended (defederated) from enby.life for hosting lolicon and MAPs. The instance frontend is locked down, but screenshots of the rules and active federation are included. Additionally, the instances uses a fork of Sharkey that was originally created for use by pediverse instances.

#BlockRecommendation #FediBlock

@puniko@mk.absturztau.be Wait, is there actually no mechanism at all to remove a delivery job after an exception? It really just retries forever??? Please tell me I misread that code :neofox_shocked:

@evan@cosocial.ca IMO, the number of replies is irrelevant. The conversation should be made private if/when the content becomes too sensitive to share publicly, and unlisted/soft-private when it becomes irrelevant to anyone outside of the conversation.