josnyder

Sylvan Dr and Forest View Dr are two blocks from each other.

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.

[1] https://josnyder.com/blog/2024/patterns_in_s3_data_access.ht...

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.

(I'm a big proponent of LVT)

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.

This was great in 2012. In 2022, most use-cases should be using parallelized zstd.

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).

[1] https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...

I'm saddened that the answer isn't "Just use BeyondCorp".

Layer 7 solutions provide so much more capacity for granular AuthZ, and thereby eliminate the "soft underbelly" of corporate networks.

I clocked a custom Ubuntu-based AMI at 2.85 seconds for the median of 10 runs.

https://gist.github.com/hashbrowncipher/17a92c6afb9642503876...

Location: Bay Area

Remote: No preference

Willing to relocate: No

Gist: SRE with a focus in databases; additional specializations in security, automation, and performance

Technologies: online databases (Cassandra, MySQL, Postgres), Python, Terraform, Puppet

Résumé: https://drive.google.com/file/d/1nVQj1w1KK6rLBp_k8dGuSUFO706...

Email: josh@code406.com

Even worse, the idea that SE is a learning process is not communicated in any of the SE textbooks I know.

I think that Naur's "Programming as Theory Building" (1985) communicates this idea succinctly and forcefully. It's not a textbook, though.

I saw it presented at Percona Live three days ago. As far as I am aware, there was no video.

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.

[1] https://github.com/Yelp/puppet-cron#puppet-cron

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').

[1] http://lxr.free-electrons.com/source/net/sched/

[2] http://engineeringblog.yelp.com/2014/03/mysql-replication-ne...

Defcad's DNS point-of-contact is dns@jomax.net. Meanwhile, megaupload's is ipr@ic.fbi.gov. 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.

From Wikipedia:

Leon Chua, who is considered to be the father of non-linear circuit theory, has argued that all 2-terminal non-volatile memory devices including phase change memory should be considered memristors. Stan Williams of HP Labs has also argued that phase change memory should be considered to be a memristor.

https://en.wikipedia.org/wiki/Phase-change_memory

API design requires much skill and foresight. As you said:

Designing a good API is one of the most difficult skills to acquire in all of software development.

However, the yardstick for copyrightability remains creativity (among other things). Some tangible work that was formed by the "sweat of one's brow" is not necessarily copyrightable, unless it was done creatively by the sweat of one's brow. Feist v. Rural [1] is the common case to cite here, where it was decided that telephone books were not creative, and thus not copyrightable, despite the effort that went into creating them.

[1] https://en.wikipedia.org/wiki/Feist_v._Rural

The way I view copyright law (IANAL), this is the correct approach. Each upload of an item to Megaupload is an independent assertion by the uploader that they have a license to put the work in question on the site. _Content_ itself is not prima facie infringing; instead, it is the unlicensed _use_ of the content that is infringement. This was essentially Youtube's argument when Viacom uploaded "roughed up" content to their site [1]. In that case, the roughed up copy as originally uploaded would be a licensed copy, but any copies that other users uploaded, even with the same MD5 hash, would be unlicensed.

On the other hand, child pornography can never be "non-infringing." It is always illegal to knowingly store obscene content, regardless of who stores it. Thus, one link to a child-pornographic file is as culpable as the next, justifying mass removal. This is essentially the argument made by Katherine Oyama of Google at one of the SOPA hearings [2].

[1] http://news.bbc.co.uk/2/hi/8575666.stm

[2] http://danwin.com/2012/01/the-sopa-debate-and-how-its-affect... (Ctrl-f "REP. MARINO")

It already has, to a small extent. Two services I can think of which already aim to provide this guarantee: Firefox Sync [1] and Tarsnap [2].

[1] http://docs.services.mozilla.com/sync/overview.html#cryptogr...

[2] http://www.tarsnap.com/crypto.html

This has been done. Real World Haskell [1] comes to mind.

[1] http://book.realworldhaskell.org/read/types-and-functions.ht...

Much as I like to jump on VZW, I don't think that Verizon should be vilified for this one. By my back-of-the-envelope math, Verizon is passing on the cost of credit-card processing to their customers, and no more (2% CC processing fee on a $100 phone bill == $2).

I would much prefer to see customers realize how much they are gouged by credit card companies every day. Some small businesses (e.g. gas stations, the deli on the corner) already do this, and I'd like to see other large businesses follow suit. It's time for people to realize the sorry state of payments at-present, perhaps opening the way for a better alternative. Some are saying that Verizon is abusing their captive customers, but I see this as Verizon trying to escape captivity as a customer of Visa, MC, and Amex.