My response to a Mozilla employee making false claims about my work to promote their own:
lists.torproject.org/pipermail/tor-
Mozilla has serious issues with the lack of ethics and honesty among their employees. There's something about the company that attracts these people like moths.
Conversation
Mozilla's approach to marketing and promotion is making dishonest attacks on others while misleading people about the capabilities of their own software. You can see that in full effect in this thread. This scumbag attacks my work without even bothering to read through a README.
1
2
9
Combine that with Mozilla's business model being explicitly based around exploiting contributors as free labour. It's official Mozilla policy to manipulate people into giving time to the project at their expense of their well being while employees look down on them and harm them.
1
4
This is the thanks I get for spending thousands of hours contributing to Mozilla projects. Manipulation / gaslighting to trick me into continuing to give my time to them, followed by years of Mozilla employees attacking my character and my work with dishonest claims / attacks.
1
5
On a positive note, I learned how to send replies to a mailing list without having been subscribed. Download a mailbox archive from somewhere like lists.torproject.org/pipermail/tor- ([ Gzip'd Text 28 KB ]) decompress it, use `mutt -f 2019-August.txt.gz` then reply with an edited To header.
1
2
14
I've never bothered figuring out how to do this but there's something to be said for the motivation from being angry. For whatever reason, mutt converts the `name at domain` addresses to `nameatdomain@hostname`and I forgot to fix that the 2nd time but it doesn't really matter.
1
5
Fun fact: the hostname for my workstation is `thinktank` because it was a silly name for a long dead T530 ThinkPad. After it died, I moved over the Samsung 840 EVO to an earlier incarnation of this workstation, and then later copied over everything to the current Samsung 960 Pro.
1
2
You don't see me claiming jemalloc isn't a well written, useful project because it's focused on performance and doesn't pay attention to defending against exploitation. There are substantial design tradeoffs involved in memory allocator design and it's not a hardened allocator.
1
4
There is no best approach providing everything. Bolting on superficial security features to jemalloc won't make it a hardened allocator design. Ripping out those features from hardened_malloc won't turn it into a performance-oriented design. I've written / worked on both kinds.
2
3
I've put a lot of time into the design and implementation, with the approach informed by allocators like OpenBSD malloc, DieHard(er), PartitionAlloc and jemalloc in various ways. It's primarily designed around deterministic defences, and with features like memory tagging in mind.
Replying to
Randomization is a bonus, and it's being integrated in a thoughtful way. Try exploiting assorted use-after-free bugs or other temporal memory safety issues with it. I think you'll find it's already a lot more than an annoying obstacle and it'll do more (github.com/GrapheneOS/har).
1
1
3