> If someone is going to criticize other people's work and dismiss it as
> nearly useless without even somewhat informing themselves about it,
> they should expect to be called out on that. You might find my reply
> offensive, but I found the email that I was replying to extremely
> offensive and
On Wed, 21 Aug 2019 at 16:28, Ryan Duff wrote:
>
> > If someone is going to criticize other people's work and dismiss it as
> nearly useless without even somewhat informing themselves about it,
> they should expect to be called out on that.
>
> I don't have a dog in this fight but, as an outside
On Wed, 21 Aug 2019 at 16:42, Richard Pospesel wrote:
>
> Yeah same, this convo went from 'wow an interesting discussion about
> allocators' to 'fuck you Tom' real quick and without provocation.
The email I replied to makes a bunch of false claims and attacks on my
project. It was never a
Yeah same, this convo went from 'wow an interesting discussion about
allocators' to 'fuck you Tom' real quick and without provocation.
From a human standpoint, maybe try and be your best self? Or (if you
prefer) from a practical standpoint, maybe berating on one of the devs
that would be
> If someone is going to criticize other people's work and dismiss it as
nearly useless without even somewhat informing themselves about it,
they should expect to be called out on that.
I don't have a dog in this fight but, as an outside observer, I never got
the impression that this is what Tom
On Wed, 21 Aug 2019 at 11:57, Nicolas Vigier wrote:
>
> On Wed, 21 Aug 2019, Daniel Micay wrote:
>
> >
> > No, you're just making false attacks and misleading comparisons / spin
> > to promote your own work, which is trash. You're being incredibly
> > dishonest and unethical. You didn't even
[Replying to both emails]
My hope is that most of this stems from my cursory work in replying
and a general misunderstanding.
I've seen people advocating for replacing the memory allocator in Tor
Browser since I started the effort five years ago here:
On Wed, 21 Aug 2019, Daniel Micay wrote:
>
> No, you're just making false attacks and misleading comparisons / spin
> to promote your own work, which is trash. You're being incredibly
> dishonest and unethical. You didn't even bother to inform yourself about
It's fine to disagree with Tom about
On Mon, Aug 19, 2019 at 04:09:36PM +, Tom Ritter wrote:
> Okay I'm going to try and clear up a lot of misconceptions and stuff
> here. I don't own Firefox's memory allocator but I have worked in it,
> recently, and am one of the people who are working on hardening it.
This makes it clear why
On Sat, Aug 17, 2019 at 09:17:40PM +, Tom Ritter wrote:
> On Sat, 17 Aug 2019 at 15:06, procmem at riseup.net
> wrote:
> > Question for the Tor Browser experts. Do you know if it is possible to
> > remotely fingerprint the browser based on the memory allocator it is
> > using? (via JS or
> The only way to guarantee catching early allocator use is to switch
> the system's allocator (ie, libc itself) to the new one. Otherwise,
> the application will end up with two allocator implementations being
> used: the application's custom one and the system's, included and used
> within libc
Hey Tom,
Thank you for your response. You've made some great points. My
response is inline.
On Mon, Aug 19, 2019 at 04:09:36PM +, Tom Ritter wrote:
> Okay I'm going to try and clear up a lot of misconceptions and stuff
> here. I don't own Firefox's memory allocator but I have worked in it,
Btw Hardened Malloc does not require recompilation of TBB.
Compilation of Hardened Malloc is easy.
https://github.com/GrapheneOS/hardened_malloc
It then can be used with TBB or any application using LD_PRELOAD
environment variable.
LD_PRELOAD='/path/to/libhardened_malloc.so' /path/to/program
Okay I'm going to try and clear up a lot of misconceptions and stuff
here. I don't own Firefox's memory allocator but I have worked in it,
recently, and am one of the people who are working on hardening it.
Firefox's memory allocator is not jemalloc. It's probably better
referred to as
Hi,
> On 18 Aug 2019, at 08:35, Shawn Webb wrote:
>
> Having the heap implementation selectable at runtime would enable
> users to make the determination for themselves, while also making
> future integration efforts easier through modularization/abstraction
> APIs (I'm making a silly, naive,
On Sat, Aug 17, 2019 at 03:06:04PM +, proc...@riseup.net wrote:
> Question for the Tor Browser experts. Do you know if it is possible to
> remotely fingerprint the browser based on the memory allocator it is
> using? (via JS or content rendering)
>
> We are thinking of switching Tor Browser
*On Sat, 17 Aug 2019 at**21:17, Tom Ritter* mailto:tor-dev%40lists.torproject.org?Subject=Re%3A%20%5Btor-dev%5D%20TBB%20Memory%20Allocator%20choice%20fingerprint%20implications=%3CCA%2BcU71%3DPeZGCAJNsPQy9QpKY9%3Dwz3vPdW8QKruF_ZwyanoyYzQ%40mail.gmail.com%3E>>
wrote:
> On Sat, 17 Aug 2019 at
On Sat, 17 Aug 2019 at 15:06, proc...@riseup.net wrote:
> Question for the Tor Browser experts. Do you know if it is possible to
> remotely fingerprint the browser based on the memory allocator it is
> using? (via JS or content rendering)
Fingerprint what aspect of the browser/machine?
> We are
Question for the Tor Browser experts. Do you know if it is possible to
remotely fingerprint the browser based on the memory allocator it is
using? (via JS or content rendering)
We are thinking of switching Tor Browser to use the minimalist and
security oriented hardened_malloc written by Daniel
19 matches
Mail list logo
