I'm not sure that's a very fair comparison, as this algorithm does point-wise streaming compression/decompression. I could see myself using something like this in a FPGA context or within a tight acquisition inner loop for example.
822 karma · joined April 27, 2020
Now, there's an argument to be made that actors who accepted to work under Kubrick knew (or at least ought to have known) what they were getting into, which blurs things a lot in this specific case. But "It's the only way" is going too far imo.
So yeah, dropping more significant digits should lead to even better compression.
But if we are going to be massaging the data based on what we know/need, there are better ways to go about compressing it. e.g. I'd expect that simple fixed-point quantization with a delta encoding would compress better than this. What I find cool about this is that it dynamically figures things out without having to deal with any priors.
The very first part of the answer to "How do you approach GDPR" is:
> "We approach data privacy and security holistically, [...]"
Which reads to me as a polite way to say: We don't want to be GDPR-compliant.
That seems to be a very common position, and one that's super weird to me. C and particularly C++ absolutely have that ability with library support if you know what you are doing.
The only material difference, from my point of view, is that the default behavior of the language is different.
I will fully grant that the path of least resistance being dangerous is a huge issue in C/C++, and one that Rust addresses, but extending that all the way to saying that the language lacks the ability is really excessive.
The detractors of the ecosystem (myself included, to be honest) will be quick to point out that obfuscating the tech as magic as much as possible, as well as creating an inside group lingo, is key to onboarding and retaining people into it. But it's fascinating how that percolates throughout the dev community behind it as well.
Installing software in the first place is placing a lot of trust into whoever made that software from the get-go. There are a myriad of ways a bad vendor can abuse a software installation without having to involve auto-updates. Singling that as a specific abuse vector that's orders of magnitude worse than giving filesystem access to an opaque binary just doesn't make much sense to me.
If I don't trust a vendor enough to allow auto-updates, then I don't trust them enough to install the software in the first place (dev dependencies notwithstanding for obvious reasons). Combine this with the well known fact that optional updates just don't get installed, and the cost/benefit calculus of the feature becomes not that hard to motivate.
Fwiw, I also think that a switch to disable the feature should always be present for those of us who care.
That being said, I really like VS Code's approach of having auto-updates enabled by default, but making a switch to turn off the feature available for nerds like us who care.
That's the model to follow in my book.
Automatic updates, again unfortunately, are critical to safety.
Alternatively, a "central" repo linking to the others would also work.
Right now, the site says that the link leads to the project, but instead, it links to you. That's giving the impression that the project's primary goal is to raise your personal profile.
If you want to refer to a collection of repositories, using a GitHub organization, even if you are the only member, prevents people from assuming you are self agrandizing.
No browser deserves special treatment here. And this is as true for Firefox as it is for Lynx.
The government doesn't design roads to conform to the top brands of cars and trucks. It specs them to a standard and any manufacturer can have their product certified as compliant. This both protects the public and gives anyone an opportunity to provide products no matter how small their market share is. Doing it the other way around would be madness, and I don't see why the same principle shouldn't apply here.
That's what what success means in this context: Something that makes that expense worthwhile.
On top of that, said lack of knowledge is a stated goal of all privacy-focused browsers. GA-blindness is an implementation detail of these policies. Any method the government could use to accurately track that information is effectively a bug in need of fixing from the POV of the browser's developers.
The most practical answer is, as was posted by someone else here, the government spec'ing to a standard instead of a set of browsers, which it really should be doing in the first place. The mere fact that the current setup means that the government accidentally makes and/or breaks winners in that space is justification enough.
It doesn't particularly matter whether or not the figure is accurate in that context. Maybe that can be fixed easily by having Firefox contextually relax tracking a bit or by having the government change how they perform the tracking, but the status quo is not really sustainable. And that's really all the article is saying at the end of the day.
On top of that, using localStorage for storing large amounts of data rarely involves anything like a cookie warning because it's 100% client side unless manually sent back to the server. And even then, if you anonymize the data (i.e. you don't care who's storage you are using), you still don't technically need any warning.
All this to say: There is basically no relationship whatsoever between pervasive cookie warnings and the usage concerns you are voicing. Both are valid concerns, both are important stakes, but they have nothing to do with one-another.