GormanFletcher

I think that would work well. A high-quality hash is designed such that changing a single input bit will flip approximately half of the output bits. So hashing both values will make it very easy for a human to spot whether the input values were different.

> Just curious, but in your opinion, how does the composition API improve on React hooks?

I'm a fan of how Vue's composition API executes exactly once during a component lifetime (during `setup()`), whereas React hooks get set up again on every render. I find it I find Vue's approach easier to mentally model, and thus easier to write correct code (especially when doing something complicated where state changes / effect executions trigger each other). Since `setup()` is only run once, I can also do things like store non-reactive state in closure variables without wrapping those variables in hooks.

> There's another approach to making CRDTs fast, which I haven't mentioned here at all and that is pruning.

Pruning is a key thing I appreciate about Yjs, because it's not just a performance optimization - it's a privacy feature. Users often expect that if they delete something from a document, it's gone unless they have explicitly turned on document revisioning. A CRDT without pruning leaves every accidental paste or poorly phrased remark in the permanent record.

Some lefties learn to write by either hooking their hand above or angling it below below the line being written, sometimes complemented by slanting the page toward or away from their writing arm.

I'm in Raleigh/Durham, North Carolina, USA.

Before everything shut down last year, my local theaters played a showing of a classic film each month, often Hitchcock. The few I went to had plenty of attendees.

Another local theater took the lockdown as an opportunity to do outdoor socially-distanced showings of previous blockbusters, like The Dark Knight. Plenty of attendees there, too.

I'd be happy to have more showings like that.

I interpreted it as brainstorming ways to actively sabotage success. "Solutions" that appears superficially plausible, but undermine the outcome in real world situations.

So for the dust filter, maybe selecting a material that's only rated for high temperatures in short bursts. Or one that needs frequent, labor-intensive replacements in that dangerous environment. Or test that your filter survives at high temperatures, and test the filtration efficacy, but forget to test the efficacy at high temperatures.

The GP's example doesn't involve invalid datetimes. The datetimes aren't out of bounds or invalid in any way that a check constraint would detect. They've just become factually incorrect ("bad data"), because they are derived data that wasn't updated when the derivation rules changed (i.e., regulatory changes).

If you're storing future datetimes that semantically represent wall clock time, you need to store the locale time plus the full time zone (such as America/New_York) so that your program does the right thing in response to any common regulatory changes that happen after you store the value. Storing the time zone abbreviation (e.g., EST) is inadvisable, as computers sometimes care whether you asked for EST vs EDT. Storing the time offset (e.g., -500) is incorrect, as it has the same pitfalls as storing UTC - you're precomputing the locale's expected time offset at storage time, and your data won't automatically be corrected if time regulations change.

If you're storing historical timestamps, UTC is fine because you can safely convert it to whatever time zone you want to display, knowing that changes to time zone / DST regulations tend not to affect the past.

There is a material difference to users between a single attacker having (and possibly ignoring) a data dump, and that attacker publishing that dump publically, or selling it to someone who plans to exploit its contents.

The attacker has offered to not publish if they are paid. Their word probably isn't worth much, but $1,000 seems like an affordable sum for a business to gamble on them being honest about it. And if Newsblur doesn't fix their security problems they'll be targeted again either way.

As someone who has a decade of data in Newsblur, if there's any chance that an affordable ransom will keep my data from spreading further I want Samuel to take it.

Having lived through the debut of Firesheep, which prompted the industry to get serious about using TLS, its an amusing triumph of cybersecurity that today a site has to be careful to not accidentally get issued a certificate. Back in 2010, when certificates cost substantial sums and needed some expertise to apply for and install, I wouldn't have guessed we'd ever get to this point.

My Aftershokz are good for spoken word in noisy/trafficy environments unless I'm inside a car at freeway speeds, or operating a lawn mower. They could work in a car if they got a little louder.

Just be aware that they make it practical to tell that something is happening around you, but with spoken word you'll usually have to pause to tell what is happening around you. I.e., I can't understand what someone is saying to me if a narrator is already speaking into my ear.

The external auth service's API would receive textual input (expecting a string read from a textbox), not binary. A hash that included null bytes would output those in hex as ASCII zeroes, which wouldn't cause the same problem when the external service received the value.