While it can't be done server-side, this can be done straightforwardly in a signer service, and the signer doesn't need to interact with the payloads being uploaded. In other words, a tiny signer can act as a control plane for massive quantities of uploaded data.
The client sends the request headers (including the x-amz-content-sha256 header) to the signer, and the signer responds with a valid S3 PUT request (minus body). The client takes the signer's response, appends its chosen request payload, and uploads it to S3. With such a system, you can implement a signer in a lambda function, and the lambda function enforces the content-addressed invariant.
Unfortunately it doesn't work natively with multipart: while SigV4+S3 enables you to enforce the SHA256 of each individual part, you can't enforce the SHA256 of the entire object. If you really want, you can invent your own tree hashing format atop SHA256, and enforce content-addressability on that.
I have a blog post [1] that goes into more depth on signers in general.
Most jurisdictions make a distinction between moving violations, which are issued to the driver, and parking violations, which are issued to the car (and its owner, by extension). This is why, in most places, you cannot get points on your license from parking illegally.
This situation would have been a moving violation. It sounds like the law has not caught up with the concept that a company might hold a driver's license and be issued moving violations.
Yes, by design. One major goal is to prevent a landowner from squatting on an empty lot while their neighbors build prosperity around it. The "squatter" then cashes in, having done nothing themselves. "Everyone works but the empty lot" is the commonly used phrase.
The goal of an LVT is to insulate a landowner's tax bill from being affected by their own improvements. Its anti-goal is to insulate a landowner from changes in land use around them.
The two downsides I'm aware of are difficulty in transitioning to an LVT and difficulty in valuing the land.
Transitioning to an LVT means that landowners no longer capture land rents for themselves, which is a massive overnight loss in the value they hold. The solutions there typically tax only the difference in land value versus a baseline assessment. So if a lot is worth $100 before LVT and $105 after, the tax is calculated only on the $5 difference.
Valuing the land is tricky because the whole point of LVT is to tax only the location itself. So the value of any structures should be excluded from taxation, and even improvements in soil quality (e.g. on a farm) should be excluded. This is problematic because the market for bare land is significant less liquid than improved land, especially in suburbs and cities. So there isn't always good data on comparable land, and there isn't a way to hold a straightforward auction to value a given lot. Of course, most present systems of property taxation are subject to the exact same issue.
I'm a big fan of privacy.com: they provide me with a spend-limited debit card number that varies by vendor. I use them especially for newspaper subscriptions that make it difficult to cancel and have balloon renewal payments.
OP appears to be Jack O'Connor, one of the designers of BLAKE3, which is the fastest full-strength cryptographic hash function currently available. It's always nice to see practicing cryptographers also producing digestible cryptography content.
PoW systems rely on the "phone a friend method" as well. When you download a Bitcoin client from a "friend", you are trusting them to honestly introduce you to the network. If you fall asleep for a period of years, you have to trust your friends to honestly inform you of all of the PoW forks and policy changes that have occurred over that interval. The only difference is that PoS blockchain clients must be bundled with a modestly-recent block hash along with the thousands of lines of code that you have no practical way to audit.
The problem eventually reduces to Ken Thompson's "Trusting Trust" [1] problem. There's no way to externally validate the honesty of any system (cryptocurrency, or otherwise).
I think it would be interesting for a member of Congress (or their staff) to operate a SecureDrop instance. Such a system might be a useful supplement to other forms of communication between federal officers and Congress (e.g. fax, interoffice, in person). Combined with 5 USC 7211, it might also have strong legal protection (IANAL).
rurban has been proselytizing against use of psuedorandom functions (such as SipHash) for hash tables for a while now. He appears to truly believe that using PRFs for this purpose is inappropriate.
Every argument I've seen from rurban is predicated upon the assumption that the seed will be leaked by the application, either by directly leaking the key's contents or by an algorithmic attack on the output of the algorithm. As you mention, the former would constitute a grave vulnerability in the application (the kernel, in this case). The latter would constitute a grave vulnerability in the algorithm.
As for assessing whether there are vulnerabilities in the algorithm, we have an academic field (cryptanalysis) that exists to inform us when such vulnerabilities exist. Cryptanalysts' efforts have given us substantial assurance that the algorithms we use everyday (e.g. AES, HMAC, ChaCha, GMAC) are both pseudo-random and adequately prevent disclosure of their keys. SipHash was explicitly designed to be resistant to cryptanalytic attack, by two well-regarded cryptographers (Bernstein and Aumasson). They designed it targeting a specific cryptographic strength/performance trade-off, and to my knowledge it is the best contender for building a flood resistant hash table.
zx2c4, I look forward to using your code. Thank you for making the Linux kernel more secure.
I work for Yelp, and we use cron for purposes similar to those mentioned in this article, mostly synchronizing small bits of configuration or data that we want local to the machine. We're heavy Puppet users, and we made a module to assist us in the management of our crons [1]. If you're a Puppet shop, I highly recommend checking it out. It provides answers to each of the problems mentioned in the article, often using the same mechanisms. I especially like its integration with Sensu, which we use for monitoring the jobs.
We've found that deploying cronjobs onto individual hosts is quite powerful, and helps us fill a niche between configuration management tools (like Puppet) and specialized coprocesses (like Smartstack). We have cronjobs for downloading code deploys, showing Sensu state within the motd, reconfiguring daemons (especially the Smartstack ones), and (of course) cleaning up unused data.
Of course, there's also the separate problem of scheduling and coordinating tasks across an entire cluster. In most cases we don't use our cron daemons for this, although we do have some jobs that run on multiple hosts and enforce mutual exclusion by grabbing a lock in Zookeeper.
Yep, I found a number of them, but I promptly forgot them in excitement when I found the one I actually wanted. If you want to check them out yourself, they appear to congregate in the kernel tree at net/sched/sch_* [1].
The only other qdisc I have much experience with is sch_netem, which emulates behaviors of a WAN (delay, loss, etc). I used it in this post [2] to conduct adversarial testing of MySQL replication (search 'tc qdisc').
Defcad's DNS point-of-contact is [email protected]. Meanwhile, megaupload's is [email protected]. It seems very likely that this is a wonderfully crafted hoax.
jwz's thesis, that uninformed people shouldn't vote, is overwhelmingly correct. I consider myself to be well-informed, politically speaking. Yet I voted in only 7 of 17 races on my ballot. I am not, for example, equipped to make informed choices for my jurisdiction's school board.
All ballots should come with a "No vote" option. What would the difference be from just leaving it blank? Nothing, except that it would give uninformed people a box to tick so that they don't have to stray towards the more important ones.
With that said, his stated corollary (to vote against propositions by default) is unhelpful and perhaps harmful. Many ballot proposals are stupid. Some aren't. As a voter, if you don't have an informed opinion, the right move is to leave it blank. Don't vote. Leave the job to those who have done their homework.