sarcasmic

It's an odd term, but one that inadvertently brings attention to concerns such as privacy and identity persistence.

Such concerns are far less obvious to laypeople when terms like "real-time modeling of traffic flows" are used. Perhaps, the choice of term is fortunate after all.

Sometimes it really shows that many early Wikipedia articles were someone's labor-of-love about a relatively obscure topic, and even today there's uneven levels of notability across the encyclopedia.

Instead of these hyphenated iron laws of transportation demand that no one has ever heard of that all say the same thing, the article of "induced demand" ought to suffice, and these formulations, if they exist original sources at all, ought to become references in that article's footnotes.

The clearest benefit of conferences for developers is networking and the "hallway tracks" -- the emergent discussions that arise after talks. The social processes of these are hard to replicate online. The asynchronous nature of online text chat, perhaps the most apt widely-deployed alternative, already lessens the urgency and spontaneity of the discussion. There are people who don't take advantage of the opportunities to insert themselves into emergent conversations, and unless their presence alone is a positive signal for the company, they're largely wasting their company's money.

The clearest benefit of conferences for sponsors is the potential lead between frontline-but-backoffice workers who work on a particular topic to the decision-makers behind them who can influence purchasing. Being present at conferences fosters passing familiarity of developers with the product, which helps conversations that occur between those developers and their bosses later: the emails from the higher-ups that ask "what do you think about Product?", and the off-the-cuff gut assessments that follow. Irrespective of the developer's initial reaction, name recognition of the product sticks around and often makes it to later rounds of evaluation and assessment.

This whole case is contrived, and both actors acted in bad faith, so the outcome will be troubling no matter what.

If Oracle wins, others can claim that their API is copyrighted and weaponize copyright law to sue anyone they don't want to interoperate with them -- despite the whole point of APIs being that interoperability.

If Google wins, it means anyone will be able to hijack the syntax, semantics, and interfaces of an ecosystem verbatim for commercial ends to promote an incompatible implementation, like they've done with Android. To protect against this, patents and NDAs will proliferate, and black-box organization and SaaS business models will solidify as the only (commericially) sensible way of distributing software.

In a JWS the header is integrity-protected by the signature if the alg isn't none. This is prominently noted in the specs and alg=none artifacts are referred to as "unsecured JWS". In a JWE the protected header is integrity protected by the AEAD cipher, because all encs must be AEAD.

The alg=none substitution issues happened because of bad usage of mediocre libraries. Other algorithm substitution can arise for the same reason. The invalid curve attacks were the ones that the spec didn't call out as a security consideration.

I support the arguments that say algorithmic agility is a bad idea and a new protocol with algorithmic agility shouldn't have come out at a time when other protocols (like TLS) were finally starting to catch on to this fact. But the JWT cat is out of the bag, and won't go back in: it's widely deployed and people are using it thinking it's solving problems they actually have. Education is the proper remedy.

The PASETO effort attempts to provide better answers and better design to an audience familiar with JWT, but there's also been an uptick in the kind of advice that heavily condemns JWT without supplying some migration paths. That latter brand of advice is harmful.

Most people use the JWT compact serialization, which cannot carry the unprotected header at all. If you're exchanging JWT compact tokens, the header is protected by the signature or the encryption.

Much of the ahead-of-the-curve, aspirational tech stack posts featured on HN are the blogging equivalent of Instagram-polished shots. On a personal blog they're equal parts self-expression and self-promotion; on a company blog they're equal parts deep dive and recruitment teaser. It's okay. Some readers will feel intrigue, some confusion, some envy. They'll wonder why they can't use those new tools at their work.

It's nice to recognize there exist developers who seem to stand apart from the vocal ones who make these posts, but they're not a single class. Some brag just as much, just in different circles. Some don't brag, but they do lots of good work. Some put out work that's not so good, and they may or may seek to represent their accomplishment regardless. The only factor they clearly share is their underrepresentation and their lack of attained popularity in talking about their work on social media.

As tempting as it may be, it's a big reach to conclude due to their underrepresentation that their tech stacks are conservative, or even dated; it's not a given that their work is solid and they're hard at work solving business problems given numerous constraints and office politics. Efforts to define this population by their rejection of shiny hype just perpetuates a kind of fictitious class divide between "fancy" developers and "plain" developers, when the real class divide is between management that is desperate for results, and IT workers that are desperate for empowered decision-making and resources. Businesses are under tremendous pressure, and silver bullets read about elsewhere carry great appeal. Transplanted organically by enthusiastic developers or by order of management, such solutions rarely work, because changing just a few inputs of a complex process won't deterministically give a better result. And mediocre results of a messy process make for a different genre of writing.

Maybe there's a class divide after all: between developers who are privileged enough to cook up all sorts of clever, custom solutions to challenging problems and can write about it, and those who spend their whole workday surviving the onslaught of nonsensical demands and deliver something mostly working in the end.

It's disruptive as this kind of product moves downmarket, at least in the sense of mindshare and marketing, if not always in terms of customer segment. These accounts may be common knowledge among people who invest online and interface with brokerage firms, but others might not know about them.

The recent marketing tactic by newer firms is to convince people to migrate from checking and savings accounts, to catch the demographic that has (for whatever reason, presumably related to cashflow, lack of info, or generational anxiety) already decided that online investing may not be for them. Perhaps they'll change their mind once they're past your acquisition funnel.

I didn't see 'cash management accounts' on the list, but I think these are among the best products. They're not too common, but more are appearing now.

There's the classic ones that combine various investment products and slush balance that's insured by a bank sweep in the same interface, and the new ones that abstract completely away from the underlying storage of the money, and provide some familiar features (debit card, bill pay, ACH transfers) and perks (high interest rate, no fees).

The latter kind is a great, low-risk, low-effort store of spending money for people with unpredictable income and/or spending who have little time or cushion to invest in products with higher returns and need the liquidity. It's a compelling alternative to a traditional US checking account at a large bank, where most of this demographic has their money.

Tumblr's adult content ban was likely a last-ditch effort by Tumblr, encouraged by owner Verizon, to salvage some business value out a hectic social (re-)blogging site that seemed like a questionable fit even for the previous buyer Yahoo.

Verizon embarked on an ambitious effort to be a force in online content and display ads, so that they'd produce worthwhile content that would contribute to them running a bigger and more successful ad network. They bought AOL and its magazines to make it happen, and a few years later they acquired the content arm of Yahoo when Yahoo pivoted to an investment holding company.

Porn blogs were a big and visible part of Tumblr, but Tumblr's unwillingness to use coarse filtering meant that they were poorly policed. Porn blogs were overwhelmingly run by bots and hosted stolen content, they'd spam-follow unrelated accounts to game search engines, and they'd generally be a nuisance in every way, despite attracting a fair amount of viewers. The Apple App Store fiasco gave a convenient pretext to roll out the coarse filter to whack porn blogs and make the site more palatable for advertisers, but the collateral damage also affected erotica, art, sex-positive communities, and various LGBTQ communities. Meanwhile, ads on Tumblr have gotten a slight bit more frequent since the Yahoo days, but hardly any more relevant or less low-rent.

The author is clearly passionate and brings a lot of detail, but it was always my amateur impression that Walmart won primarily on footprint. They covered the country in stores, and not just the suburbs, but also rural America where the likes of Target and Kmart never ventured, and shops with much smaller selections and different formats were the norm.

I don't perceive Amazon as an 'unbounded' Walmart like the author does, but as an aggregator as thoroughly analyzed by Ben Thompson of Stratechery fame. They bootstrapped a destination with undifferentiated products, a broad selection, and convenience, and later bolted on a marketplace to further capitalize on the traffic. But the dynamics of customer-facing marketplaces are very different from those of internal ones like those of Walmart and McDonald's. McDonald's puts out specs and has suppliers compete for restaurants' buys, and Walmart and Costco have immense purchasing leverage with suppliers, this process results in optimizing the desired quality-to-cost ratio the retailer wants to target.

Amazon, on the other hand, is a free-for-all, where selection is overwhelming, products with obscure branding appear to rip each other off to the point where no obvious choice rises above, human curation is absent, reviews frequently appear gamed, prices change arbitrarily, products are gated behind Prime and are subject to obscure shipping math, and despite being long perceived as having low prices, pricing on products is now being used as a signal. Amazon is hardly anything more than a digital flea market, where Amazon is the landlord and some of the vendor booths are staffed by them directly. A wildly successful and profitable one, and one that draws marketshare away from traditional retail, but it diverges so far from the formula of retail that comparisons with them are of questionable value.

Not sure if the comparison to Conway's Law works. The key goal of layering is abstraction, so that one can be productive without having to know details about the layers below, but much of optimization is about exploiting details in the layers below for gain. Clearly, these goals are in conflict.

After posing a hypothesis, the post talks about security and process isolation. But the problems raised aren't in line with the hypothesis: the challenge in these cases isn't "insufficient communication" between the levels of the stack, but rather a discrepancy between the abstraction's actual behavior vs. a human's desires and expectations about big-picture topics.

These abstractions often compromised by information leakage through side effects that executing code can observe or deduce, leading to the class of vulnerabilities that have long been around, but have received far more attention since Spectre.

Protecting against timing attacks and other side-channel attacks requires the observable state of the system to not vary due to execution in a different security domain. Timing attacks are particularly frustrating, because processes can estimate their execution time even without external timers, so it can compare the time taken between different calls. Cryptographic operations often take special care to avoid leaking information through timing, but the same discipline isn't commonplace in system calls or userland code. And shared caches will leak info in timing but greatly improve performance.

Hardware isolation is an effective solution for curbing timing attacks for systems that don't communicate over a network. It's not sufficient in the case of networked systems, because the network and its connections form another source of observable state that's likely full of unrelated side-effects.