neverfone's comments

neverfone | 7 years ago | on: Say Hello to Full Employment

Your third paragraph was enlightening and explained your position reasonably well. I'm not sure I'm convinced, but it seems like an interesting discussion.

I feel obliged to downvote you because of the first two paragraphs, why did you add them? You were trying to refute what you considered an "accusation of arrogance" with the most arrogant opening paragraph possible?

neverfone | 7 years ago | on: C++ Just My Code Stepping in Visual Studio

Hmmph, I see what you're saying, that sounds like it could work.

I think the tab flashing is the critical detail, otherwise you would be confused why things are deadlocking.

neverfone | 7 years ago | on: Against privacy defeatism: why browsers can still stop fingerprinting

I'm not following your argument, do you agree that there are resources that cannot be saved in a shared cache?

neverfone | 7 years ago | on: Against privacy defeatism: why browsers can still stop fingerprinting

Then you would need to know the (dynamically generated) contents in advance?

neverfone | 7 years ago | on: Against privacy defeatism: why browsers can still stop fingerprinting

Yes, private doesn't necessarily mean authenticated, it just means shouldn't be saved in a shared cache.

For example, "weather_at_your_geoip.js".

neverfone | 7 years ago | on: C++ Just My Code Stepping in Visual Studio

I don't know if there are any good Linux GUI debuggers, but gdb is a comprehensive debugger and can do something similar with the skip command.

Any gui debugger for Linux is probably a frontend to gdb, so as long as it lets you passthrough commands to gdb it can do this.

neverfone | 7 years ago | on: C++ Just My Code Stepping in Visual Studio

Not a windows user, but the same applies to gdb. What is your proposal? If you're currently debugging a thread, breakpoints are disabled for other threads? That really doesn't seem like what people would expect by default.

neverfone | 7 years ago | on: Against privacy defeatism: why browsers can still stop fingerprinting

I think you're forgetting that resources cannot be shared if they're marked private. You cannot get account_statement.js from your shared cache, it has to be unique to you.

There is no easy fix to this.

neverfone | 7 years ago | on: Against privacy defeatism: why browsers can still stop fingerprinting

I don't understand the question, it's either cached or not.

If it's not cached, then it has to be fetched synchronously for anything depending on its value to work - so it's slow.

If it is cached, then the cached value is known.

neverfone | 7 years ago | on: Against privacy defeatism: why browsers can still stop fingerprinting

I'm not a privacy defeatist, but I am a fingerprinting defeatist. Here's why: I don't think it's realistic for caching and anti-fingerprinting to co-exist, and given those two options users will always pick the former because the latter would be perceived as slow. The classic example is:

Where foobar.js just returns something like "var id=0x1234567", the user who doesn't want to be fingerprinted cannot cache this script because it could be uniquely generated.