I help run a tech/AI meetup in San Francisco - during the initial post-Covid period we often hit capacity limits since there wasn't much else going on.
But since late 2024 into 2025, meetups are extremely back in fashion here. Every day of the calendar has multiple meetups and it's impossible to avoid conflicts, so attendance rate can vary wildly.
It's just like a parallel of tech venture capital, where missing the next big thing is far more costly than making a wrong bet. No wonder we see herding in tech investments as well.
I think it's a legitimate question to ask: how much capital should be redirected to studying this promising direction?
Is the herd effect wrong? This is not a simple question to answer with objective pareto-optimal answers for everyone.
If the promising direction pans out, having 3-5 drugs in the pipeline represents a far faster optimization problem, with far faster discovery, leading to more years of lives saved. Going slow, waiting for one drug to succeed or fail, learning maximally, then maybe trying another, may be dollar optimal, but has other risks: abandoning a good direction too early because of stochastic decision making (see for example the story of GLP-1 agonists which were delayed for decades because of optimizing to avoid me-too diabetes injectables), and also not exploiting a very promising target that pans out well in the first trial.
The speed issue is also one reason that trials are so expensive, and why drug discovery is limited in what we can try. If there were lower barriers to entry for trials--that somehow maintain the same safety characteristics--then perhaps we could learn faster and better and more cheaply. And the quote talks about a very important thing: there's only so many data points we can collect because there's only so many people who can ethically go on to a clinical trial in the first place. How we optimize the best outcome for those clinical trial patients, and the best outcome for society in general from what we learn from the trials, does not have a clear and obvious answer. This is why ethics classes belong in the curriculum of all advanced bio degrees, IMHO!
Also if it turns out in the end the next big thing that everyone bet on just wasn’t it, you don’t stand out. But if it did work out and you missed the train you come out looking like a fool. There is asymmetry in the downsides for your career between these two options
I remember in 2021 or so there was a startup doing 20 minute grocery delivery in SF, $50 off on your first order.
I got some really nice steaks for free and the delivery actually arrived via motorbike in 10 minutes. They must have had delivery drivers waiting with their own inventory or something. Anyways, the VC funding dried up and the company was gone a few months later.
Getir was doing 20 mins grocery delivery in most European capitals.
Interestingly, one way they get the delivery time down is they pack the items into the motorbike when you add them to the basket, not when you checkout.
If you remove an item from the basket and checkout, the motorbike will often arrive with the removed item (and take it back again).
that was ~20 years earlier but was so awesome when it was around. That and webvan were better (for customers, not for making money) than anything that existed until 2020.
Yeah, I had the same question myself. I think that's what you would want to do to make it airtight (plus some amount of rate limiting or flagging for devices that are part of dedicated device farms).
But even if not, there's still value in raising the barrier to entry. For example, you can buy 1000 reCaptcha solves for $1-2 from various captcha-solver services. And yet that $0.001-per-request fee does discourage mass-scale bot attacks.
99% of the crap and fraud comes from ads, aka Google. Thanks, Google. Just run an ad blocker, there goes most of the scams you'll see.
Also putting QR codes before every webpage doesn't make the web less shitty. It obviously makes it more shitty. And this will 100% be used for fraud. Phishing websites can get away with QR codes now, great.
How though? Can you also avoid DDoS simply by designing your system to not care if the requester is a bot or not.
Let's say I'm running https://grep.app/ for example. AI bots start heavily using it, costing me a ton of money. How would you magically design this so it doesn't matter if the end bots are using it?
How do you "determine" individual clients to show them CAPTCHAs? Yes, you can, and probably should, make some use of IP addresses, although that would work better if idiots hadn't polluted the Internet with quite so much NAT.
But you don't have to, and you definitely don't have to completely rely on it. Look for a cookie. If you don't see it, route the client through a page that sets it.
Yes, this is subject to flooding attacks... in exactly the same way that every CAPTCHA system is subject to flooding attacks. But it actually uses fewer resources per request than showing the CAPTCHA would.
> Uhm no the whole point of captchas is that it requires (or used to anyway) humans to solve them, thus limiting the rate to human speeds.
The CAPTCHA challenge page itself has to be served to a client that has not yet given any evidence that it's not a bot. It's just as expensive to serve the challenge page as it is to serve a cookie-setting page. Bots can infinitely retrieve the challenge page (and can also infinitely try to retrieve the underlying "authenticated" page, forcing you to process redirects).
The only reason it looks better to you is that a third party is serving the CAPTCHA. You could also have a third party serve the cookie-setting page.
This is generally true of every application that handles sensitive data. Unless you explicitly clear that memory, it's likely to hang around forever.
For example, here is a 2019 writeup from KeePassXC with similar notes: https://keepassxc.org/blog/2019-02-21-memory-security/ - even though they explicitly clear sensitive data, there is still a window of opportunity.
During my time working on confidential computing, we had a variety of demos showing similar attacks against lots of different datastores, scripts, etc. That's just how computers work and your options are very limited if this is part of your threat model (imo just confidential computing and, if you can handle the performance hit, fully-homomorphic encryption).
Windows already has a secure kernel credential store, they could move the Edge password store there with a bit of effort, minimize the splash damage when you retrieve a single password to send over HTTP from the regular user space.
> Credential Guard prevents credential theft attacks by protecting NTLM password hashes, Kerberos Ticket Granting Tickets (TGTs), and credentials stored by applications as domain credentials.
> Credential Guard uses Virtualization-based security (VBS) to isolate secrets so that only privileged system software can access them.
This only works if credential guard has implemented a way to build a subsequent token/value from that secret. For things like basic auth the secret would need to eventually hit the userland process that needs it in some shape or form to then embed it in the HTTP payload which is plaintext.
I see it as no different from the previous generation of consumer startups burning money - as Derek Thompson wrote,
> ...if you woke up on a Casper mattress, worked out with a Peloton, Ubered to a WeWork, ordered on DoorDash for lunch, took a Lyft home, and ordered dinner through Postmates only to realize your partner had already started on a Blue Apron meal, your household had, in one day, interacted with eight unprofitable companies that collectively lost about $15 billion in one year.
But since late 2024 into 2025, meetups are extremely back in fashion here. Every day of the calendar has multiple meetups and it's impossible to avoid conflicts, so attendance rate can vary wildly.
reply