Back in my day you needed a PhD in CSS to center a div vertically. We used to pore over the freshest W3C drafts with excitement. You don't see that anymore since jQuery.
About 15 years ago I implemented "cache namespacing" for memcached, where you build a final cache key for a stored item (e.g. "profile_page") by doing an initial multiget cache query for all the "namespace" version values (e.g "user_123", "team_456" might be needed for "profile_page"), which you combine together as a prefix for the final cache key.
You can then invalidate any final cache key that uses one of the namespaces by incrementing the namespace key.
I haven't come across this technique mentioned elsewhere since, but it's very useful.
I guess nosql, edge caching and materialised views make it less applicable than it used to be (when inelastically scaling single/replicated SQL instances were the only game in town and taking load off them was vital).
Or is this technique now a first class feature of various cache client SDKs?
- You can imagine a situation where Tofu keeps TF DSL compatibility but add useful new features to the runtime (better plan summary, multiple stack deployment, chained deployments, etc). That’s going to put Hashicorp under pressure to move quicker..
- … but Hashicorp publicly pleaded poverty over their development resource on TF as the reason they wouldn’t accept community PRs. You can’t just grow a team tenfold overnight. They’ve been quite deliberate about the design of the Terraform language and runtime over the years, taking their time to add new features. It’s going to be interesting !
- The provider situation looks fairly safe to me. Those licenses didn’t change and you can always redirect to github releases for the really popular binaries ?
You can exfiltrate secrets that aren't in the state, but are in accessible resources during a plan using an http data source with the secret encoded into the url
In the long run, I wonder if all video will be signed via blockchain-or-other-trusted-3rd-party. You'd need everything from the camera to the the editing software to support it though.
Unless somebody builds a kind of 'pseudo-random-generator' chain where the internal state is huge, changes substantially each tick and is very expensive to compute, so that it becomes infeasible to store or recompute (a large number of) previous states for anyone but the most powerful players.
You could then use that internal state as a private key to sign what you want and only keep the corresponding public key and a signed date+time to proof the veracity. The public keys themselves would need to form a blockchain in the traditional sense, so you can verify their integrity without the previous internal states.
If you wanted to go all-in with the verification, you'd probably also want to show something containing the date+time in the video, together with some complicated physical effects that are hard to fake.
Well, just thinking out loud here, but it seems like it might work :D
I vaguely recall reading somewhere several years ago about some cameras which signed the photos they produced, so one could prove they came directly from the camera and weren't edited. IIRC, it was in an article about these signatures being broken, though I don't recall the details (perhaps it was by dumping the signing key from the camera firmware?).
Early digital cameras could be fingerprinted by looking at dead pixels (there are over a hundred million ways to have three dead pixels in a one megapixel camera, so if these are uniformly distributed, that, in the early days, when few cameras existed, have almost guaranteed uniqueness). It wouldn’t surprise me if that still is possible by looking at minor variations in light sensitivity across pixels (that might require having access to lots of photos by a single camera, though)
Why would the blockchain help here? Basically you need public private key pairs where the private key exists only in silicon and the public key is associated with a serial number. Normally the serial number is trivially associated with the customer who ultimately purchases the hardware especially if the camera is part of a phone with an active plan.
It seems like this trivially works better with a centralized database especially since you don't necessarily want to make all of this data public. The general public needs to know that this is a true and accurate photo that hasn't been edited taken on such and such a date. The authorities with a warrant might well need to know that it was taken by a device owned by bob.
