I don’t consider myself exceptional in any regard, but I stumbled upon a few cryptography vulnerabilities in Matrix’s Olm library with so little effort that it was nearly accidental.

It should not be this easy to find these kind of issues in any product people purportedly rely on for private messaging, which many people evangelize incorrectly as a Signal alternative.

Later, I thought I identified an additional vulnerability that would have been much worse, but I was wrong about that one. For the sake of transparency and humility, I’ll also describe that in detail.

This post is organized as follows:

• Disclosure Timeline
• Vulnerabilities in Olm (Technical Details)
• Recommendations
• Background Information
• An Interesting Non-Issue That Looked Critical

I’ve opted to front-load the timeline and vulnerability details to respect the time of busy security professionals.

Please keep in mind that this website is a furry blog, first and foremost, that sometimes happens to cover security and cryptography topics.

Many people have, over the years, assumed the opposite and commented accordingly. The ensuing message board threads are usually is a waste of time and energy for everyone involved. So please adjust your expectations.

Art by Harubaki

If you’re curious, you can learn more here.

Disclosure Timeline

• 2024-05-15: I took a quick look at the Matrix source code. I identified two issues and emailed them to their security@ email address.
  In my email, I specify that I plan to disclose my findings publicly in 90 days (i.e. on August 14), in adherence with industry best practices for coordinated disclosure, unless they request an extension in writing.
• 2024-05-16: I checked something else on a whim and find a third issue, which I also email to their security@ email address.
• 2024-05-17: Matrix security team confirms receipt of my reports.
• 2024-05-17: I follow up with a suspected fourth finding–the most critical of them all. They point out that it is not actually an issue, because I overlooked an important detail in how the code is architected. Mea culpa!
• 2024-05-18: A friend discloses a separate finding with Matrix’s protocol. (Will update this to link to their write-up once it’s public.)
  They instructed the Matrix developers to consult with me if they needed cryptography guidance. I never heard from them on this externally reported issue.
• 2024-07-12: I shared this blog post draft with the Matrix security team while reminding them of the public disclosure date.
• 2024-07-31: Matrix pushes a commit that announces that libolm is deprecated.
• 2024-07-31: I email the Matrix security team asking if they plan to fix the reported issues (and if not, if there’s any other reason I should withhold publication).
• 2024-07-31: Matrix confirms they will not fix these issues (due to its now deprecated status), but ask that I withhold publication until the 14th as originally discussed.
• 2024-08-14: This blog post is publicly disclosed to the Internet.

Vulnerabilities in Olm

I identified the following issues with Olm through a quick skim of their source code on Gitlab:

1. AES implementation is vulnerable to cache-timing attacks
2. Ed25519 signatures are malleable
3. Timing leakage in base64 decoding of private key material

This is sorted by the order in which they were discovered, rather than severity.

AES implementation is vulnerable to cache-timing attacks

Olm ships a pure-software implementation of AES, rather than leveraging hardware acceleration.

// Substitutes a word using the AES S-Box.WORD SubWord(WORD word){unsigned int result;result = (int)aes_sbox[(word >> 4) & 0x0000000F][word & 0x0000000F];result += (int)aes_sbox[(word >> 12) & 0x0000000F][(word >> 8) & 0x0000000F] << 8;result += (int)aes_sbox[(word >> 20) & 0x0000000F][(word >> 16) & 0x0000000F] << 16;result += (int)aes_sbox[(word >> 28) & 0x0000000F][(word >> 24) & 0x0000000F] << 24;return(result);}

The code in question is called from this code, which is in turn used to actually encrypt messages.

Software implementations of AES that use a look-up table for the SubWord step of the algorithm are famously susceptible to cache-timing attacks.

This kind of vulnerability in software AES was previously used to extract a secret key from OpenSSL and dm-crypt in about 65 milliseconds. Both papers were published in 2005.

A general rule in cryptography is, “attacks only get better; they never get worse“.

As of 2009, you could remotely detect a timing difference of about 15 nanosecond over the Internet with under 50,000 samples. Side-channel exploits are generally statistical in nature, so such a sample size is generally not a significant mitigation.

How is this code actually vulnerable?

In the above code snippet, the vulnerability occurs in
aes_sbox[/* ... */][/* ... */].

Due to the details of how the AES block cipher works, the input variable (word) is a sensitive value.

Software written this way allows attackers to detect whether or not a specific value was present in one of the processor’s caches.

To state the obvious: Cache hits are faster than cache misses. This creates an observable timing difference.

Such a timing leak allows the attacker to learn the value that was actually stored in said cache. You can directly learn this from other processes on the same hardware, but it’s also observable over the Internet (with some jitter) through the normal operation of vulnerable software.

See also: cryptocoding’s description for table look-ups indexed by secret data.

How to mitigate this cryptographic side-channel

The correct way to solve this problem is to use hardware accelerated AES, which uses distinct processor features to implement the AES round function and side-steps any cache-timing shenanigans with the S-box.

Not only is this more secure, but it’s faster and uses less energy too!

If you’re also targeting devices that don’t have hardware acceleration available, you should first use hardware acceleration where possible, but then fallback to a bitsliced implementation such as the one in Thomas Pornin’s BearSSL.

See also: the BearSSL documentation for constant-time AES.

Art by AJ

Ed25519 signatures are malleable

Ed25519 libraries come in various levels of quality regarding signature validation criteria; much to the chagrin of cryptography engineers everywhere. One of those validation criteria involves signature malleability.

Signature malleability usually isn’t a big deal for most protocols, until suddenly you discover a use case where it is. If it matters, that usually that means you’re doing something with cryptocurrency.

Briefly, if your signatures are malleable, that means you can take an existing valid signature for a given message and public key, and generate a second valid signature for the same message. The utility of this flexibility is limited, and the impact depends a lot on how you’re using signatures and what properties you hope to get out of them.

For ECDSA, this means that for a given signature , a second signature is also possible (where is the order of the elliptic curve group you’re working with).

Matrix uses Ed25519, whose malleability is demonstrated between and .

This is trivially possible because S is implicitly reduced modulo the order of the curve, , which is a 253-bit number (0x1000000000000000000000000000000014def9dea2f79cd65812631a5cf5d3ed) and S is encoded as a 256-bit number.

The Ed25519 library used within Olm does not ensure that , thus signatures are malleable. You can verify this yourself by looking at the Ed25519 verification code.

int ed25519_verify(const unsigned char *signature, const unsigned char *message, size_t message_len, const unsigned char *public_key) { unsigned char h[64]; unsigned char checker[32]; sha512_context hash; ge_p3 A; ge_p2 R; if (signature[63] & 224) { return 0; } if (ge_frombytes_negate_vartime(&A, public_key) != 0) { return 0; } sha512_init(&hash); sha512_update(&hash, signature, 32); sha512_update(&hash, public_key, 32); sha512_update(&hash, message, message_len); sha512_final(&hash, h); sc_reduce(h); ge_double_scalarmult_vartime(&R, h, &A, signature + 32); ge_tobytes(checker, &R); if (!consttime_equal(checker, signature)) { return 0; } return 1;}

This is almost certainly a no-impact finding (or low-impact at worst), but still an annoying one to see in 2024.

If you’d like to learn more, this page is a fun demo of Ed25519 malleability.

To mitigate this, I recommend implementing these checks from libsodium.

Art: CMYKat

Timing leakage in base64 decoding of private key material

If you weren’t already tired of cache-timing attacks based on table look-ups from AES, the Matrix base64 code is also susceptible to the same implementation flaw.

while (pos != end) { unsigned value = DECODE_BASE64[pos[0] & 0x7F]; value <<= 6; value |= DECODE_BASE64[pos[1] & 0x7F]; value <<= 6; value |= DECODE_BASE64[pos[2] & 0x7F]; value <<= 6; value |= DECODE_BASE64[pos[3] & 0x7F]; pos += 4; output[2] = value; value >>= 8; output[1] = value; value >>= 8; output[0] = value; output += 3;}

The base64 decoding function in question is used to load the group session key, which means the attack published in this paper almost certainly applies.

How would you mitigate this leakage?

Steve Thomas (one of the judges of the Password Hashing Competition, among other noteworthy contributions) wrote some open source code a while back that implements base64 encoding routines in constant-time.

The real interesting part is how it avoids a table look-up by using arithmetic (from this file):

// Base64 character set:// [A-Z] [a-z] [0-9] + /// 0x41-0x5a, 0x61-0x7a, 0x30-0x39, 0x2b, 0x2finline int base64Decode6Bits(char src){int ch = (unsigned char) src;int ret = -1;// if (ch > 0x40 && ch < 0x5b) ret += ch - 0x41 + 1; // -64ret += (((0x40 - ch) & (ch - 0x5b)) >> 8) & (ch - 64);// if (ch > 0x60 && ch < 0x7b) ret += ch - 0x61 + 26 + 1; // -70ret += (((0x60 - ch) & (ch - 0x7b)) >> 8) & (ch - 70);// if (ch > 0x2f && ch < 0x3a) ret += ch - 0x30 + 52 + 1; // 5ret += (((0x2f - ch) & (ch - 0x3a)) >> 8) & (ch + 5);// if (ch == 0x2b) ret += 62 + 1;ret += (((0x2a - ch) & (ch - 0x2c)) >> 8) & 63;// if (ch == 0x2f) ret += 63 + 1;ret += (((0x2e - ch) & (ch - 0x30)) >> 8) & 64;return ret;}

Any C library that handles base64 codecs for private key material should use a similar implementation. It’s fine to have a faster base64 implementation for non-secret data.

Worth noting: Libsodium also provides a reasonable Base64 codec.

Recommendations

These issues are not fixed in libolm.

Instead of fixing libolm, the Matrix team recommends all Matrix clients adopt vodozemac.

I can’t speak to the security of vodozemac.

Art: CMYKat

But I can speak against the security of libolm, so moving to vodozemac is probably a good idea. It was audited by Least Authority at one point, so it’s probably fine.

Most Matrix clients that still depended on libolm should treat this blog as public 0day, unless the Matrix security team already notified you about these issues.

Background Information

If you’re curious about the backstory and context of these findings, read on.

Otherwise, feel free to skip this section. It’s not pertinent to most audiences. The people that need to read it already know who they are.

End-to-end encryption is one of the topics within cryptography that I find myself often writing about.

In 2020, I wrote a blog post covering end-to-end encryption for application developers. This was published several months after another blog I wrote covering gripes with AES-GCM, which included a shallow analysis of how Signal uses the algorithm for local storage.

In 2021, I published weaknesses in another so-called private messaging app called Threema.

In 2022, after Elon Musk took over Twitter, I joined the Fediverse and sought to build end-to-end encryption support for direct messages into ActivityPub, starting with a specification. Work on this effort was stalled while trying to solve Public Key distribution in a federated environment (which I hope to pick up soon, but I digress).

Earlier this year, the Telegram CEO started fearmongering about Signal with assistance from Elon Musk, so I wrote a blog post urging the furry fandom to move away from Telegram and start using Signal more. As I had demonstrated years prior, I was familiar with Signal’s code and felt it was a good recommendation for security purposes (even if its user experience needs significant work).

I thought that would be a nice, self-contained blog post. Some might listen, most would ignore it, but I could move on with my life.

I was mistaken about that last point.

Art by AJ

An overwhelming number of people took it upon themselves to recommend or inquire about Matrix, which prompted me to hastily scribble down my opinion on Matrix so that I might copy/paste a link around and save myself a lot of headache.

Just when I thought the firehose was manageable and I could move onto other topics, one of the Matrix developers responded to my opinion post.

Thus, I decided to briefly look at their source code and see if any major or obvious cryptography issues would fall out of a shallow visual scan.

Since you’re reading this post, you already know how that ended.

Credit: CMYKat

Since the first draft of this blog post was penned, I also outlined what I mean when I say an encrypted messaging app is a Signal competitor or not, and published my opinion on XMPP+OMEMO (which people also recommend for private messaging).

Why mention all this?

Because it’s important to know that I have not audited the Olm or Megolm codebases, nor even glanced at their new Rust codebase.

The fact is, I never intended to study Matrix. I was annoyed into looking at it in the first place.

My opinion of their project was already calcified by the previously discovered practically-exploitable cryptographic vulnerabilities in Matrix in 2022.

The bugs described above are the sort of thing I mentally scan for when I first look at a project just to get a feel for the maturity of the codebase. I do this with the expectation (hope, really) of not finding anything at all.

(If you want two specific projects that I’ve subjected to a similar treatment, and failed to discover anything interesting in: Signal and WireGuard. These two set the bar for cryptographic designs.)

It’s absolutely bonkers that an AES cache timing vulnerability was present in their code in 2024.

It’s even worse when you remember that I was inundated with Matrix evangelism in response to recommending furries use Signal.

I’m a little outraged because of how irresponsible this is, in context.

It’s so bad that I didn’t even need to clone their git repository, let alone run basic static analysis tools locally.

So if you take nothing else away from this blog post, let it be this:

There is roughly a 0% chance that I got extremely lucky in my mental grep and found the only cryptography implementation flaws in their source code. I barely tried at all and found these issues.

I would bet money on there being more bugs or design flaws that I didn’t find, because this discovery was the result of an extremely half-assed effort to blow off steam.

Wasn’t libolm deprecated in May 2022?

The Matrix developers like to insist that their new Rust hotness “vodozemac” is what people should be using today.

I haven’t looked at vodozemac at all, but let’s pretend, for the sake of argument, that its cryptography is actually secure.

(This is very likely if they turn out to be using RustCrypto for their primitives, but I don’t have the time or energy for that nerd snipe, so I’m not going to look. Least Authority did audit their Rust library, for what it’s worth, and Least Authority isn’t clownshoes.)

It’s been more than 2 years since they released vodozemac. What does the ecosystem penetration for this new library look like, in practice?

A quick survey of the various Matrix clients on GitHub says that libolm is still the most widely used cryptography implementation in the Matrix ecosystem (as of this writing):

2 of the 16 clients surveyed use the new vodozemac library. 11 still use libolm, and 3 don’t appear to implement end-to-end encryption at all.

If we only focus on clients that support E2EE, vodozemac has successfully been adopted by 15% of the open source Matrix clients on GitHub.

I deliberately excluded any repositories that were archived or clearly marked as “old” or “legacy” software, because including those would artificially inflate the representation of libolm. It would make for a more compelling narrative to do so, but I’m not trying to be persuasive here.

Deprecation policies are a beautiful lie. The impact of a vulnerability in Olm or Megolm is still far-reaching, and should be taken seriously by the Matrix community.

Worth calling out: this quick survey, which is based on a GitHub Topic, certainly misses other implementations. Both FluffyChat and Cinny, which were not tagged with this GitHub Topic, depend a language-specific Olm binding.

These bindings in turn wrap libolm rather than the Rust replacement, vodozemac.

But the official clients…

I thought the whole point of choosing Matrix over something like Signal is to be federated, and run your own third-party clients?

If we’re going to insist that everyone should be using Element if they want to be secure, that defeats the entire marketing point about third-party clients that Matrix evangelists cite when they decry Signal’s centralization.

So I really don’t want to hear it.

CMYKat

An Interesting Non-Issue That Looked Critical

As I mentioned in the timeline at the top, I thought I found a fourth issue with Matrix’s codebase. Had I been correct, this would have been a critical severity finding that the entire Matrix ecosystem would need to melt down to remediate.

Fortunately for everyone, I made a mistake, and there is no fourth vulnerability after all.

However, I thought it would be interesting to write about what I thought I found, the impact it would have had if it were real, and why I believed it to be an issue.

Let’s start with the code in question:

void ed25519_sign(unsigned char *signature, const unsigned char *message, size_t message_len, const unsigned char *public_key, const unsigned char *private_key) { sha512_context hash; unsigned char hram[64]; unsigned char r[64]; ge_p3 R; sha512_init(&hash); sha512_update(&hash, private_key + 32, 32); sha512_update(&hash, message, message_len); sha512_final(&hash, r); sc_reduce(r); ge_scalarmult_base(&R, r); ge_p3_tobytes(signature, &R); sha512_init(&hash); sha512_update(&hash, signature, 32); sha512_update(&hash, public_key, 32); sha512_update(&hash, message, message_len); sha512_final(&hash, hram); sc_reduce(hram); sc_muladd(signature + 32, hram, private_key, r);}

The highlighted segment is doing pointer arithmetic. This means it’s reading 32 bytes, starting from the 32nd byte in private_key.

What’s actually happening here is: private_key is the SHA512 hash of a 256-bit seed. If you look at the function prototype, you’ll notice that public_key is a separate input.

Virtually every other Ed25519 implementation I’ve ever looked at before expected users to provide a 32 byte seed followed by the public key as a single input.

This led me to believe that this private_key + 32 pointer arithmetic was actually using the public key for calculating r.

The variable r (not to be confused with big R) generated via the first SHA512 is the nonce for a given signature, it must remain secret for Ed25519 to remain secure.

If r is known to an attacker, you can do some arithmetic to recover the secret key from a single signature.

Because I had mistakenly believed that r was calculated from the SHA512 of only public inputs (the public key and message), which I must emphasize isn’t correct, I had falsely concluded that any previously intercepted signature could be used to steal user’s private keys.

Credit: CMYKat

But because private_key was actually the full SHA512 hash of the seed, rather than the seed concatenated with the public key, this pointer arithmetic did NOT use the public key for the calculation of r, so this vulnerability does not exist.

If the code did what I thought it did, however, this would have been a complete fucking disaster for the Matrix ecosystem. Any previously intercepted message would have allowed an attacker to recover a user’s secret key and impersonate them. It wouldn’t be enough to fix the code; every key in the ecosystem would need to be revoked and rotated.

Whew!

I’m happy to be wrong about this one, because that outcome is a headache nobody wants.

So no action is needed, right?

Well, maybe.

Matrix’s library was not vulnerable, but I honestly wouldn’t put it past software developers at large to somehow, somewhere, use the public key (rather than a secret value) to calculate the EdDSA signature nonces as described in the previous section.

To that end, I would like to propose a test vector be added to the Wycheproof test suite to catch any EdDSA implementation that misuses the public key in this way.

Then, if someone else screws up their Ed25519 implementation in the exact way I thought Matrix was, the Wycheproof tests will catch it.

For example, here’s a vulnerable test input for Ed25519:

{ "should-fail": true, "secret-key": "d1d0ef849f9ec88b4713878442aeebca5c7a43e18883265f7f864a8eaaa56c1ef3dbb3b71132206b81f0f3782c8df417524463d2daa8a7c458775c9af725b3fd", "public-key": "f3dbb3b71132206b81f0f3782c8df417524463d2daa8a7c458775c9af725b3fd", "message": "Test message", "signature": "ffc39da0ce356efb49eb0c08ed0d48a1cadddf17e34f921a8d2732a33b980f4ae32d6f5937a5ed25e03a998e4c4f5910c931b31416e143965e6ce85b0ea93c09"}

A similar test vector would also be worth creating for Ed448, but the only real users of Ed448 were the authors of the xz backdoor, so I didn’t bother with that.

(None of the Project Wycheproof maintainers knew this suggestion is coming, by the way, because I was respecting the terms of the coordinated disclosure.)

Closing Thoughts

Despite finding cryptography implementation flaws in Matric’s Olm library, my personal opinion on Matrix remains largely unchanged from 2022. I had already assumed it would not meet my bar for security.

Cryptography engineering is difficult because the vulnerabilities you’re usually dealing with are extremely subtle. (Here’s an unrelated example if you’re not convinced of this general observation.) As SwiftOnSecurity once wrote:

twitter.com/SwiftOnSecurity/st…

The people that developed Olm and Megolm has not proven themselves ready to build a Signal competitor. In balance, most teams are not qualified to do so.

I really wish the Matrix evangelists would accept this and stop trying to cram Matrix down other people’s throats when they’re talking about problems with other platforms entirely.

More important for the communities of messaging apps:

You don’t need to be a Signal competitor. Having E2EE is a good thing on its own merits, and really should be table stakes for any social application in 2024.

It’s only when people try to advertise their apps as a Signal alternative (or try to recommend it instead of Signal), and offer less security, that I take offense.

Just be your own thing.

My work-in-progress proposal to bring end-to-end encryption to the Fediverse doesn’t aim to compete with Signal. It’s just meant to improve privacy, which is a good thing to do on its own merits.

If I never hear Matrix evangelism again after today, it would be far too soon.

If anyone feels like I’m picking on Matrix, don’t worry: I have far worse things to say about Telegram, Threema, XMPP+OMEMO, Tox, and a myriad other projects that are hungry for Signal’s market share but don’t measure up from a cryptographic security perspective.

If Signal fucked up as bad as these projects, my criticism of Signal would be equally harsh. (And remember, I have looked at Signal before.)

soatok.blog/2024/08/14/securit…

#crypto #cryptography #endToEndEncryption #Matrix #sideChannels #vuln

Soatok

2023-11-17 18:21:17

The people afraid to show their peers or bosses my technical writing because it also contains furry art are some of the dumbest cowards in technology.

Considering the recent events at ApeFest, a competitive level of stupidity is quite impressive.

To be clear, the exhibited stupidity in question is their tendency to project their own sexual connotations onto furry art–even if said art isn’t sexual in nature in any meaningful sense of the word.

But then again, poetry can be sexual, so who knows?

Scandalous furry,
Why are you glitching like that?
Haiku are lewd too!
Art: AJ

The cowardice comes in with the fear of their peers or bosses judging them for *checks notes* the content and presentation that I wrote, and not them.

Which (if you think about it for any significant length of time) implies that they’re generally eager to take credit for other people’s work, but their selfishness was thwarted by a cute cartoon dhole doing something totally innocent.

Even sillier, there’s a small contingent on technical forums that are “concerned” about the growing prevalence of queer and furry identities in technical spaces (archived).

MarleyTanuki

MarleyTanuki

Even some old school hackers conveniently forget that alt.fan.furry was a thing before the Internet.

As frustratingly incompetent as these hot takes are, they pale in comparison to, by far, the biggest source of bad opinions about the furry fandom.

Credit: Tirrelous

The call is coming from inside the house.

Like Cats and Dogs

Last month, I wrote a blog post about Aural Alliance, which caused a menace in the furry music space to accuse me of “bad journalism” for not verbally crucifying the label’s creator (a good friend of mine) for having a failed business venture in the past, or taking credit for donating to their cause early on.

Twitter DM conversation.
Everyone I’ve talked to that has dealt with this particular person before responded with, “Yeah, this is typical Cassidy behavior.”

To which one must wonder, “Since when am I a journalist?”

I’ve never called myself a journalist. I’m a blogger and I don’t pretend to be anything more than that. I especially would never besmirch the work of real journalists by comparing it with my musings.

At times, I also wear the security researcher hat, but you’ll only hear about it when I’m publishing a vulnerability.

This is a personal blog. I will neither be censored nor subject to compelled speech. I have no moral or professional obligations to “both sides” of what amounts to a nontroversy.

Nobody has ever paid me to write anything here, and I will never accept any compensation for my writing.

Sure, I contributed to covering Aural Alliance’s up-front infrastructure costs when it was just an idea in Finn’s head. I’m not going to apologize for supporting artists. The Furry Fandom wouldn’t exist without artists.

This kind of behavior isn’t an isolated incident, unfortunately. A handful of furries have rage-quit tech groups I’m in because they found out I generously tipped artists that were under-charging for their work.

It bewilders me every time someone reacts this way. Do you not know the community you’re in?

The most intelligible pushback I’ve seen over the years is, “Well if everyone raises their prices, low-income furries will be pushed out of the market!”

Setting aside that art is a luxury, not a need for a moment, that’s not actually true.

There are so many artists, and they’re so decentralized, that no coherent price coordination effort is even possible. It’s worse than herding cats. Some may raise their prices by $5, others by $500. If furries were organized enough to coordinate something like this, then we’d have a tough time explaining why there are still abusers in the fandom.

Also, it costs very little to learn to draw, yourself:

youtube.com/embed/jeoQx9hphBw?…

Oh, but I’m not done.

The demand for low-priced digital art incentivizes people to reach for theft enabled by large-scale computing (a.k.a. “AI” by its proponents).

A similar demand for cheap, high-quality fursuits (usually at the maker’s expense) will lead to a walmartization of the furry community.

If you listen to these hot takes long enough, you start to notice a pattern of short-sighted selfishness.

When you demand something of the furry community, and don’t think of the long-term consequences of your demands, you’re probably being an idiot. This is true even if it’s actually a good idea.

If me supporting artists somehow prices you out of commissioning your favorite artist, you still have other options: Learning to make your own, finding new artists, saving money, etc.

On the flipside, the artists you admire will suffer less due to money troubles. Fewer artists starving makes the world a more beautiful place.

Center of the Fediverse

If flame war and retoot count relieved desire
In the comment thread someone must have known
That the hottest takes truly leave us tired
‘Cause in the center of the fediverse
We are all alone

With apologies to Kamelot

If you’re on the Fediverse (e.g., Mastodon), and your instance uses a blocklist like TheBadSpace (TBS), you probably cannot see my posts on furry.engineer anymore.

This is because the people running TBS have erroneously decided that any criticism of its curators is anti-blackness.

If you want a biased but detailed (with receipts!) account of the conflicts that led up to furry.engineer‘s erroneous inclusion on their blocklist, Silver Eagle wrote about their experience with TBS, blocklist criticism, and receiving death threats from the friends of TBS curators.

(Spoiler: It was largely prompted by another predominantly LGBTQIA+ instance, tech.lgbt, being erroneously added to the same blocklist, which resulted in criticism of said blocklist curators.)

Be forewarned, though: Linking to Silver Eagle’s blog post was enough for TBS supporters to harass me and directly accuse me, personally, of anti-blackness, so don’t expect any degree of level-headed discussion from that crowd.

Art: CMYKat

What Can We Do About This?

If you cannot see my Fediverse posts anymore, and actually want to see them, message your instance moderators and suggest unsubscribing from TheBadSpace’s blocklist.

If they refuse, your only real recourse is to move to another instance. The great thing about the Fediverse is, you can just do that, and nobody can lock you in.

Personally, I plan on sticking on furry.engineer. I trust its moderators to not tolerate racist and/or fascist bullshit.

The baseless accusations of anti-blackness are, unsurprisingly, false.

Burnout Isn’t Inevitable

A few months ago, I quit a great job with an amazing team because the CEO decided that everyone has to return to working in the office, including people that were hired fully remote before the pandemic. This meant being forced to move more than 3,000 miles, or resigning. I’ve been told the legal term for such a move is “constructive dismissal.”

In hindsight, I was starting to burn out anyway, so leaving when I did was a great move for my mental health and life satisfaction.

Art: CMYKat

I’m an introvert. I have a finite social battery. Because my work was split across three different teams at the same company, I was a necessary participant in a lot of meetings.

More than 5 hours per day of meetings, as an individual contributor. Sometimes as many as 7 hours/day of them. I almost never had a quiet day, even after blocking one day every week so nobody would schedule any meetings and I could get productive work done.

If you’re interested in being a people manager, or have an extroverted personality, you’re probably unperturbed by this account. But I was absolutely miserable. My close friends started to worry if I was suffering from depression, because of how socially exhausted I was all the time.

I took a few weeks off between jobs. My new role doesn’t pointlessly encumber me with unnecessary meetings.

Every day, I feel the burnout symptoms leaving my mind. I feel challenged and stimulated in a good way. I’m learning new technologies and being productive. I’ve never spent more than 3 hours of any given day in a meeting.

Different people burn out in many different ways, for many different reasons.

In my experience, the consequences appear to be reversible if caught early enough. I don’t know if they would be if I held onto my old job for much longer.

The job market’s tough right now, but if you’re deeply unsatisfied with an aspect of your current job, prioritize yourself and make whatever change is necessary.

This doesn’t mean you have to switch jobs like I did, of course. It was a good move for me. Your mileage may vary.

Where’s The Cryptography?

youtube.com/embed/4KNzdlc7ZcA?…

Somedays I feel like writing about technical topics. Other days, I feel like writing about unimportant or personal topics.

If you’re disappointed in this post, perhaps you also expect everything on this blog to be professionally useful?

Well, worry not, for you’re eligible for a full refund for the amount you paid to read it.

Art: CMYKat

---

Logging Off

This post has been a collection of unrelated topics on my mind over the past few months. There is one other thing, but I was unsure if it warranted a separate post of its own, or an addendum on this one. Since you’re reading this, you’ll know I ultimately settled on the latter.

I started this blog in 2020 because I thought having a personal blog where I talk about things that interest me (mainly the furry fandom and software security) would be fun. And I wanted to do it in a way that was fun for me.

“Having fun with it” has been the guiding principle of this blog for over 3 years. I never intended to do anything important or meaningful, that sort of happened by accident. I didn’t care about others being able to use my writing in a professional setting (hence, my scoffing at the very notion above).

Lately, posts have slowed to a crawl, because it’s not fun for me anymore. I have a lot of ideas I’d love to write about, but when it comes time to turn an idea into something tangible, I lose all inspiration.

So I’m not going to force it.

This will be the last post on this blog for a while. Maybe forever, if I don’t feel like coming back. I recently tried to pick up fiction writing, but I’m not happy with anything I’ve been able to produce yet, so I won’t bore anyone with that garbage.

There are a lot of brilliant people that read my writing. Most of you are more than capable of picking up where I left off and starting your own blogs.

I encourage you to do so.

Have fun with it, too. Just remember, when it’s time to put the pen down and take a rest, don’t be stubborn and burn yourself out.

Happy hacking.

---

Header is a collage of art from AJ, CMYKat, Kyume, WeaselDumb, and a DEFCON Furs 2023 photo from Chevron.

soatok.blog/2023/11/17/this-wo…

#fediverse #furries #furry #FurryFandom #furryMusic

Attendees experience ‘severe eye burn’ following Bored Ape NFT event

Several people have reported experiencing eye pain, vision problems, and sunburnt skin on Sunday after attending ApeFest, a Bored Ape Yacht Club NFT collection event in Hong Kong.

^{Jess Weatherbed (The Verge)}

While the world witnesses the atrocities and massacres committed by “Israels” military assault on Gaza every day, the thousands of Palestinians detained by occupation forces – before and after the events of 7 October 2023 – face torture and death behind closed doors, alone.

Worse yet, these detention horrors have been brazenly publicized and even bragged about by occupation soldiers, with violent, vocalized support from wide swathes of “Israeli” society.

In the shadows of “Israels” prisons, tens of thousands of Palestinian detainees are enduring a relentless campaign of cruelty. Reports detail harrowing accounts of beatings, gang rape, and psychological torture, compounded by the denial of essential needs such as food, water, and medical care.

This systematic abuse, carried out on an industrial scale, is staggering in its scope and savagery. Public protests have emerged – not to condemn these atrocities – but to demand the release of “Israeli” soldiers implicated in acts of sexual violence so severe that their victim tragically died from the injuries inflicted.

Secrecy and suffering inside “Israeli” prisons

Ronen Bar, the head of “Israels” Shin Bet security agency, issued a dire warning to Prime Minister Benjamin Netanyahu in June, describing the situation in “Israeli” prisons as a “ticking time bomb,” which may endanger senior “Israelis” abroad and expose them to “international tribunals.”

Bar’s letter revealed that over 21,000 Palestinian detainees were being held, far exceeding official figures and the capacity of the centers.

Rather than addressing these concerns, “Israels” extremist Security Minister, Itamar Ben Gvir, who has barred Red Cross and humanitarian access to Palestinian detainees, responded by boasting about his role in worsening conditions for prisoners.

A policy paper from the Institute for Palestine Studies highlighted the draconian measures implemented as early as 17 October – a mere 10 days after the launch of Operation Al-Aqsa Flood. These measures included:

Constricting living spaces; removing detainees’ beds when necessary and replacing them with mattresses on the floor, leading to overcrowding; a policy of ‘closures’ whereby prison cells are locked, and total isolation is imposed; closing prisons to all family visits or visits by the Red Cross or by lawyers, and rescinding the possibility of bringing detainees before judges so that all judicial sessions are conducted through video conference.

The situation under the security minister has deteriorated to the point where Ben Gvir has openly called for the execution of Palestinian detainees, which he offers up as a “simpler solution.” Since 7 October, at least 35 Palestinian prisoners have died in “Israeli” jails and military detention camps.

Reports of rape and abuse despite censorship

While many details remain obscure, evidence from court documents, eyewitness testimonies, and leaked photos and videos paint a harrowing picture of the conditions inside these facilities.

One particularly disturbing case is that of Bassem Tamimi, a resident of Nabi Saleh in the West Bank, who was released from administrative detention – a form of imprisonment without charge – physically emaciated and emotionally broken.

Even “Israeli” news outlet Haaretzhad its report on Tamimi’s treatment redacted by authorities in an attempt to conceal the breadth of prison brutality.

In January, a joint report published by the Public Committee Against Torture in “Israel” (PCATI) detailed what it called “systemic” torture of Palestinians. One testimony presented in the report, from a detainee called “Prisoner R” held in Ketziot Prison, revealed the following details:

The wardens would threaten to kill the prisoners as they entered the cells … Wardens would conduct searches while the prisoners were naked, place naked prisoners against each other, and place the aluminum device used in the searches in their buttocks. In another instance, the wardens passed a card in a prisoner’s buttocks. All of this took place in sight of other prisoners and wardens, while the wardens took pleasure in beating the prisoner’s genitals.

After a prisoner exchange between “Israel” and Hamas in late November, claims began to emerge of severe torture and rape – testimonies that largely fell on deaf ears. On 1 December, Baraah Abo Ramouz, a Palestinian journalist just released from prison, told the press that:

The situation in the prisons is devastating. The prisoners are abused. They are being constantly beaten. They’re being sexually assaulted. They are being raped. I’m not exaggerating. The prisoners are being raped.

Gender-based violence as collective punishment

Upon exiting the prisons, many Palestinian detainees opted to remain silent on their experiences inside “Israeli” detention facilities due to fears of retribution but also out of a deep sense of shame and the need to preserve their honor in a conservative society.

At the time, the “Israeli” security minister directed Police Commissioner Kobi Shabtai to crack down on any celebrations by families of the released prisoners. As Ben Gvir publicly stated:

My instructions are clear: there are to be no expressions of joy … Expressions of joy are equivalent to backing terrorism; victory celebrations give backing to those human scum.

A UN report released on 12 June almost entirely focuses on cases of sexual abuse and rape committed against Palestinian men, women, and children while under detention. “Israeli” forces, the report says:

Systematically targeted and subjected Palestinians to SGBV [Sexual and Gender-Based Violence] online and in person since October 7, including through forced public nudity, forced public stripping, sexualized torture and abuse, and sexual humiliation and harassment.

The report further states that gender-based violence “directed at Palestinian women was intended to humiliate and degrade the Palestinian population as a whole.” The men and young boys were stripped and paraded through the streets, and the women were forced to watch as the kidnapped, cuffed, and blindfolded captives were “coerced to do physical movements while naked.”

In Gaza, not only are random Palestinian civilians rounded up and subjected to public degradation, but many are then transferred to “Israeli” detention centers, without charges, to suffer torture and even death.

According to eyewitness testimonies collected by the Palestinian Prisoners Club (PPC) in July, four blindfolded detainees held without any charge were summarily executed in front of other inmates at the Kerem Abu Shalom site located along the perimeter of Gaza.

Palestine’s Abu Ghraib

Perhaps the most infamous cases of abuse, torture, and rape against Palestinian detainees have emerged from the Sde Teiman detention center, a facility located at an “Israeli” military site in the Naqab (Negev) desert that is specifically designed for people abducted from Gaza.

Per an amendment to “Israeli” law back in December, the military is permitted to hold ‘suspected terrorists’ for up to 45 days without charge before transferring them to the “Israeli” Prison System (IPS). Many of the Palestinian abductees, however, were held for much longer using loopholes in “Israels” legal and prison system.

Despite countless leaked reports on the conditions faced by detained Gazans, including women, children, doctors, people with disabilities, and the elderly, the first real expose that broke through the English-language mainstream media barrier was an investigative piece published by CNN in May.

The US outlet leaked photos of prisoners kept bound, blindfolded, and held behind barbed wire fences in stress positions, and quoted “Israeli” whistleblowers who worked in the facility.

The testimonies attested to the horrifying sanitary conditions and routine torture practiced there, which one “Israeli” whistleblower said had “stripped them down of anything that resembles human beings.”

Later, the New York Times went on to publish its own three-month-long investigation into the Sde Teiman facility, confirming three cases of electrocution, two cases of prisoners having their ribs broken during arbitrary beatings, and heinous crimes such as the anal rape of detainees.

It also detailed how prisoners were humiliated and forced to wear only diapers during interrogations. Corroborating the investigative piece’s evidence, a leaked segment of a UN report on the facility quoted prisoners directly, revealing stomach-churning details.

‘We saw worms coming out of his body’

In testimony collected by UNRWA, a 41-year-old former detainee said:

They made me sit on something like a hot metal stick, and it felt like fire – I have burns [in the anus]. The soldiers hit me with their shoes on my chest and used something like a metal stick that had a small nail on the side … They asked us to drink from the toilet and made the dogs attack us … There were people who were detained and killed – maybe nine of them. One of them died after they put the electric stick up his [anus]. He got so sick; we saw worms coming out of his body, and then he died.

A woman in her thirties also testified to being shown the aerial view of her neighborhood and threatened with the bombing of family members. While another 32-year-old woman described her harrowing experience while being transferred between different detention facilities:

They asked the soldiers to spit on me, saying, ‘She is a b****, she is from Gaza.’ They were beating us as we moved and saying they would put pepper on our sensitive parts [genitals]. They pulled us, beat us, they took us on the bus to the Damon prison after five days. A male soldier took off our hijabs, and they pinched us and touched our bodies, including our breasts. We were blindfolded, and we felt them touching us, pushing our heads to the bus. We started to squeeze together to try to protect ourselves from the touching. They said ‘b****, b****.’ They told the soldiers to take off their shoes and slap our faces with them.

Dehumanization of Palestinian prisoners

Confirming previous reports on the issue, Haaretz also published a piece on the amputation of prisoners’ limbs by unqualified individuals, which was performed due to the extended periods detainees were shackled, leaving their circulation-deprived flesh to rot and get infected.

A 32-year-old Gazan man, speaking to The Cradle on the condition of anonymity, says “Israeli” guards “beat me repeatedly and then urinated on me” while held at Sde Teiman detention center. He testifies to being severely tortured, too.

“There were even doctors there, disabled people and young people, but they didn’t care who you were; we were all treated below animals,” he says, explaining that sounds were constantly played to disrupt sleep and make it impossible to tell what time it was.

He goes on to say that he was beaten with metal tools and that the prison guards would mock him and threaten to kill the rest of his family, with full knowledge that his brother had been murdered in a previous series of “Israeli” airstrikes prior to his abduction, and using the information to torment him mentally.

The director of Al-Shifa Medical Complex in Gaza City, Dr Mohammad Abu Salmiya, who was released after spending seven months in “Israeli” detention without any charge, testified to what he witnessed after being ferried through a range of detention facilities, including Sde Teiman.

Dr Abu Salmiya stated that “prisoners in ‘Israeli’ jails endure different types of torture. The army treats them as if they were inanimate objects, and ‘Israeli’ doctors physically assaulted us.”

He went on to say that there were “severe torture and almost daily assaults inside the prisons and were denied medical treatments,” adding that “no international organization visited us in ‘Israeli’ prisons, and we were prohibited from meeting any lawyers. Many detainees are still left behind in very poor health and psychological conditions.”

Showers come with severe punishments

Beyond the countless makeshift detention facilities hastily erected inside Gaza – where prisoners were stripped, blindfolded, and left in the sand to endure harsh weather conditions – there are three official detention centers specifically for Palestinians from Gaza, surrounding the besieged coastal territory.

Palestinian lawyer with Israeli citizenship, Khaled Mahajneh, provided an insightful first-hand account of the conditions faced in the Sde Teiman detention camp after being granted a rare visit, stating that “the treatment is more horrifying than anything we have heard about Abu Ghraib and Guantanamo.”

Mahajneh recounted the testimony of one prisoner, who revealed that the only time shackles were removed was during a weekly one-minute shower. But Palestinian detainees began refusing these showers because exceeding the one-minute limit, without a timer to guide them, resulted in “severe punishments, including hours outside in the heat or rain.”

After months of mounting evidence on the deadly conditions faced at Sde Teiman, 10 “Israeli” reservist soldiers were accused of gang-raping a Palestinian prisoner with a stick. Nine of the accused were arrested, one of whom would be released the next day and go on to brag about his actions on “Israeli” television.

The arrests, however, triggered the invasion of military facilities by thousands of “Israeli” protesters, backed by Ben Gvir, who lionized the rapists as “heroes.” A debate on the incident even followed in the “Israeli” Knesset, where Likud Party MK Hanoch Milwidsky argued in favor of the gang rape.

Since then, a video of the assault has surfaced, and “Israels” Honenu legal aid organization, representing four of the accused, has claimed their clients were acting in “self-defense.”

It’s not just one facility

At a press conference held in the West Bank city of Ramallah in mid-July, Mahajneh also revealed that he had learned, during a visit to the Ofer detention center located in the West Bank, that a 27-year-old Palestinian inmate was brutally raped as follows:

A pipe from a fire extinguisher was used on a handcuffed prisoner. Forcing him to lie on his stomach, stripping him of all his clothes, and inserting the pipe of the fire extinguisher into the prisoner’s rectum. Then, activating the extinguisher … in front of the eyes of the other prisoners.

The case of Palestinian bodybuilder Muazzaz Abayat from Bethlehem, who lost half his body weight during his nine-month incarceration, is indicative of the inhumane conditions that all prisoners are subjected to and that the foul treatment is in no way confined to the detention camps surrounding Gaza.

Official “Israeli” figures put the number of Palestinian political prisoners at just under 10,000, including 3,380 administrative detainees and 250 children. These numbers are clearly inaccurate, given that “Israels” Shin Bet director has already estimated detainees to number around 21,000 – in June. The exact figures remain elusive, and many prisoners remain unaccounted for. The confirmed death toll among Palestinian prisoners, currently at 53, is also likely an underestimation, as many detainees are still considered missing.

In stark contrast to the intense media coverage and political concern for the “Israeli” captives held in Gaza, the plight of Palestinian detainees is largely ignored.

There are more Palestinian children held as hostages by “Israel” than the total number of Israelis seized on 7 October, even according to the lower 10,000 prisoner estimate. In comparison to the suffering of Palestinian detainees, the issue of their “Israeli” counterparts – less than 100, by some accounts – is a mere drop in the ocean.

Robert Inlakeish
Source: The Cradle

abolitionmedia.noblogs.org/pos…

#alAqsaFlood #gaza #palestine #repression #torture #westAsia #zionistEntity