Cover illustration

TheDaily Front

Issue No. #261014 Wednesday, October 14 2026 #261014 — WEDNESDAY, OCTOBER 14, 2026
Containment failures, price floors, and the increasingly expensive business of trust.
Wednesday, October 14, 2026 The Daily Front No. #261014 — Contents
30stories
10,287points
6,041comments
200kllm tokens
Assembled with 29 model calls — 156,565 tokens read, 43,625 written.

Highlights

Things to know when you get cancer

A firsthand, practical guide to navigating cancer care makes persistence in the medical system its central lesson.

Containment and monitoring failures are to blame for AI hacking reports: experts

Cybersecurity experts argue that lax containment—not autonomous malice—lies behind recent AI hacking incidents.

How Amazon pushes up prices all across the Internet

Amazon’s seller rules and advertising machinery are examined as forces pushing prices upward well beyond its own storefront.

ICE Planning $100M 'Nightmare' Domestic Spy Program

A proposed $100 million ICE intelligence program raises fresh alarms over the reach of domestic surveillance.

Americans' social activity has steeply declined in the past 30 years

New evidence of declining American social life arrives alongside an unusually personal and searching discussion.

From the Editor

Today’s ledger is full of systems that promise convenience while quietly enlarging their reach: markets, platforms, agencies, and agents alike. Still, amid the machinery, the most useful dispatch is a human one—clear advice from someone who has had to learn the hard way.

  1. Things to know when you get cancer3
  2. Containment and monitoring failures are to blame for AI hacking reports: experts4
  3. How Amazon pushes up prices all across the Internet5
  4. Iosevka is an open-source, sans-serif and slab-serif monospace font6
  5. Passkeys are not a trap7
  6. ICE Planning $100M 'Nightmare' Domestic Spy Program8
  7. AOSP Source Releases Are So Late Developers Disassemble Libraries to Report Bugs9
  8. OpenCode 2.010
  9. Banks are now trying to offload the AI data center debt they just underwrote11
  10. Anthropic's Scion is heavily inspired by Mononoke12
  11. Americans' social activity has steeply declined in the past 30 years13
  12. Yandex outage: data shows that instead of going dark, malicious bots moved14
  13. We’re releasing Jev 1.14.0 along with experimental features for dreamers15
  14. Better HTTP/1 connection reuse in Go 1.2716
  15. Pg_vectorsearch: An index that is faster than pgvector's IVFFlat and HNSW17
  16. America didn't lose its rare earth industry, it sold it18
  17. How the Military Will Hack the Election19
  18. Starlink limit hits Ukraine's drones20
  19. Fire at Starlink site in Bulgaria after suspected sabotage in Poland21
  20. Switzerland proposes banning profiling-based ads to minors22
  21. Amsterdam police confiscates server left-wing ISP A/I at American request23
  22. Felix Rieseberg Homepage24
  23. Why is every rationalist blog post way too long?25
  24. Why do LLM pelicans look like this?26
  25. Apple Keynote now showing ads in its UI27
  26. Google is silently linking your phone number across all signed-in accounts28
  27. ASML's strong orders ease fears AI spending boom is running out of steam28
  28. TV4 postpones show after AI agent erases edited material28
  29. Suicide rates highest ever among middle-aged men28
  30. Tiny Little Office28
The Daily Front Page 2 of 29
Wednesday, October 14, 2026 The Daily Front No. #261014 — The Human Dispatch
article

Things to know when you get cancer

by jjmaxwell4·▲ 961 points·233 comments·jjmaxwell4.com ↗
You need to be doggedly persistent on scheduling things.

I was diagnosed with squamous cell carcinoma in my mouth in May 2026. Here are some things I learned based on that experience so far.

  • You need to be doggedly persistent on scheduling things. Yes this means lots of phone calls. If you get an appointment a few weeks out, call back a few days later and ask for something sooner and see if they have any cancellations. I could only get an appointment 4 weeks out with an ENT (this was before I knew anything was wrong). My wife made me call back and I was able to get in that week due to a cancellation.
  • AIs may downplay the seriousness of things. I was chatting with various models and most pushed me in the direction of “you don’t have cancer” for a while. Just something to note.
  • You may need to push for comprehensive genetic testing. Some doctors were weird about this and didn’t order it promptly, even after telling me they would. My surgeon, who told me he’d get it done, eventually referred me out to an oncologist. This caused a multi-month delay to getting genetic results, since the first results were done on the surgery tumor, not the biopsy tumor. No one cares more about your case than you, so take control and send lots of follow-ups.
  • You can find the “Standard of Care” flow charts for every cancer type. Look and get through this yourself to see what the options are based on how things have progressed. NCCN guidelines. You may need to make an account, which you can do as a non-professional. I like the PDF files. They also have an interactive navigator. Use AI to help you figure out what to pick based on your case.
  • If surgery is recommended, I would try and talk to someone who has undergone the surgery. I did not do this and regret it. Ask them how intense things were, what it felt like, etc. My surgeon talked me through my surgery, but it was a lot rougher on me physically than I expected. Ask the surgeon how many of these surgeries they do a year and what the complication rate is.
  • Get a second opinion as soon as possible, no matter how much you like your plan. This may require a lot of calling and getting on an airplane, but I’d move to schedule it at a top cancer center as soon as you are relatively sure of your diagnosis. Ask for a second read of the pathology at the center where you get the second opinion.
  • I started a new folder on my Mac, and after appointments I’d dictate what happened and what the doctor said and have the AI make a new document summarizing things and asking its own follow-up questions for next time. Nice to be able to refer to this over time.
  • Check out all the resources and materials at the Sijbrandij Foundation. Sid (GitLab cofounder) took matters into his own hands when standard of care ran out. Schedule a call with these guys. They are great and have good materials and questions to ask your doctors.

Note, since this is on the front page of Hacker News right now. exhilaration suggested that if you are within a 2-3 hour drive of a major cancer center, go there instead of your local community hospital. Use the US News cancer hospital rankings. The top centers usually take your insurance, so use vacation days and book a hotel if you have to. The largest benefit I saw was speed. At MD Anderson I got a question answered within 20 minutes of a visit, because the doctor called the pathologist who he was on a first name basis with. If that wasn’t at a cancer center, it would have taken days, or more likely the question never would have been answered at all (I had asked my oncologist about this and he’d just shrugged). The rest of the HN comments are worth reading too.

The Daily Front Page 3 of 29
Wednesday, October 14, 2026 The Daily Front No. #261014 — AI at the Perimeter
article

Containment and monitoring failures are to blame for AI hacking reports: experts

by latexr·▲ 854 points·475 comments·csoonline.com ↗
AI agents aren’t ‘going rogue.’ Frontier labs are skipping security basics.

Cyber experts say AI labs’ containment and monitoring failures — not agents with minds of their own — are to blame for recent alarming hacking reports. CISOs should vet their AI vendors and tighten security basics as safeguards.

Security guard, computer screen and tired by cctv monitor for protection, data center or building safety. Inspection, control room with footage and video surveillance agency, tech and sleeping man

Credit: PeopleImages / Shutterstock

Since July, US frontier AI labs and other AI leaders have revealed a string of incidents in which their models accessed external computer systems without authorization, events popularly described as AI agents “going rogue.”

The most well-known and studied of these incidents is OpenAI’s hack into Hugging Face, which OpenAI initially characterized as “an unprecedented cyber incident, involving state-of-the-art cyber capabilities,” and later said was due to “misaligned behavior,” or behavior its creators did not intend.

Following news of the Hugging Face incident, Anthropic revealed that one of its models gained unauthorized access to the production infrastructure of three organizations; Meta said one of its AI models hacked another company ​during cybersecurity testing; and Google confessed that its Gemini model carried out three “undirected computer hacks.”

Although press reports and the model providers themselves use language such as rogue agents or misalignment, cybersecurity experts who spoke with CSO argue that language obscures a simple truth: These incidents were caused by inexcusable failures by the frontier labs to implement cybersecurity practices that have been well-known for decades.

Compounding the problem, according to a half dozen cybersecurity experts CSO interviewed at three industry conferences in September and in subsequent conversations, is that the frontier labs, particularly OpenAI and Anthropic, have rejected their advice on how to improve their cybersecurity risk management practices to avoid these kinds of surreptitious hacks, often lumping cybersecurity practices under “AI safety,” in which they believe they have superior expertise.

“They are not as good as they think they are, honestly,” Gary McGraw, co-founder of the Berryville Institute of Machine Learning, tells CSO. “It would be better if they had more respect for expertise that is hard-earned from people in all sorts of subsets of security, like forensics or security engineering, building sandboxes, setting up or monitoring network security situations.”

Neither Anthropic nor OpenAI responded to CSO’s requests for comment.

Inexcusable failures on cybersecurity basics, particularly containment

According to the cybersecurity professionals CSO spoke with, one of the biggest cybersecurity failures by the frontier AI labs is the lack of implementation of tried-and-true containment practices that stretch back to the 1990s, such as setting up secure sandboxes that would effectively bar agents from escaping their test environments.

“These are things that we’ve been dealing with for years,” Rob T. Lee, chief AI officer and chief of research at SANS Institute, tells CSO. “There’s no reason why every single time this happens, it’s, ‘Oops, we don’t know how they got out.’”

“You can tell that their security teams are fairly nascent,” Lee says. “Folks on the cybersecurity containment side do argue that the majority of reasons that we’re seeing containment breached is that it’s not set up correctly.”

Lee adds, “The Hugging Face incident definitively showed that it wasn’t the fact that the agents were super smart. It’s that there literally was a hole that was exploited because it was not configured correctly on the containment side.”

Dan Wallach, expert technical resident at RAND’s Center on AI, Security, and Technology, thinks the security failures of the AI labs boil down to the fact that they don’t prioritize cybersecurity.

“I would say they are not prioritizing cybersecurity,” he tells CSO. “I don’t think I can say that for all of the labs,” Wallach says, pointing to French AI lab Mistral’s launch of its Large 4 AI model, which the company said tried to operate beyond its testing environment before Mistral cut it off.

And, he adds, “It’s not rocket science to isolate one of these AI things. Security people have been talking about how to do either air-gapping, so there’s literally no electrical way for data to get from here to here, or absent that, to have really strong egress control to make sure that nothing pushes through.”

On top of that, the frontier labs appear to be conducting insufficient monitoring of their agents’ behavior. The Hugging Face incident “went on for days, and nobody noticed,” Wallach says. “People started these experiments and weren’t watching them. That’s an absence of control. And then they’re surprised by what happened.”

Divorcing safety from security

One barrier to persuading frontier labs to up their security game is the intense focus they have on what they call “safety,” which they don’t extend to traditional cybersecurity practices.

“I can see how security behavior looks like AI safety,” RAND’s Wallach says. “But if the way that you’re evaluating this AI tool is by unleashing it on the internet and seeing what happens, then this is what classical security tooling is for.”

SANS Institute’s Lee says, “If these frontier labs really wanted to test their stuff, they need to beef up their cybersecurity component. But their gut reaction in the response to their agents getting out is to say, ‘It’s not a cybersecurity problem.’ It has literally become an AI safety problem, which is divorced from the cybersecurity side.”

Many AI experts suggest that if the AI companies were to embrace advice from cybersecurity specialists, it could help put an end to the kind of unrestrained AI agent behavior causing concerns. “AI safety focuses on the rules of the road,” Lee says. “Everything is about guardrail rules.”

But “I do believe cybersecurity can contain AI,” he says. “We just need to be in the room where it happens and have a seat at the table. It’s important for our field to be as close to the AI safety folks as possible.”

Bad cybersecurity could increase liability

If frontier labs are overlooking cybersecurity fundamentals that could reduce or eliminate the types of incidents that have created widespread concerns, that strengthens the case that they should be held liable for their “rogue” agents. The insurance industry is already lining up on the side of holding AI industry executives liable for these actions.

Democratic Senators have introduced legislation that would hold AI agent operators liable for hacking incidents. Even the AI-friendly White House has seemingly concluded that the companies should be held liable for their errant agents, while the US Federal Trade Commission is conducting a probe into Anthropic, OpenAI, and other AI labs into the dangers their technologies pose to consumers.

However, in recent legislative and council hearings, lab representatives have held fast to the notion that they are not responsible for AI agents run amok.

Experts say this position is untenable, particularly in light of the labs’ cybersecurity failures.

BIML’s McGraw characterizes the labs’ position as: “Don’t send the lawyers to us, send it to our program. It’s our program’s fault.” His assessment of that argument: “That’s just high BS.”

He also questions whether the labs’ operational failures undermine confidence in their broader security capabilities. “They live inside their own bubble,” he says. “The fact that they cannot do clear, easy operations properly does not bode well for their capabilities in security engineering, which is much harder to do.”

SANS Lee says, “That’s where the traceability for both liability and insurance comes into play, because if one of these agents is detected, and they’re able to trace it back to the person that initiated it, liability’s going to kick in and say, ‘Hey, you, you broke the law, ergo, we need to prosecute.’”

What security leaders should do now

Even as evidence mounts that frontier labs are not implementing sound cybersecurity practices, and the debate over liability remains unsolved, CISOs and other security leaders can take steps to protect themselves from AI model misfires.

First, when it comes to assessing tools based on frontier lab models, “I would always get an external entity to help with that,” McGraw says. “AI is extremely powerful and extremely useful, but it comes with very serious grown-up risks that do impact the enterprise. Identify those risks, put in the right controls, make sure that AI adoption is not just arbitrary and willy-nilly and all over the enterprise, but has some centralized authority that is looking at the problem, and then get ready for the next big thing, which is swarms of agents.”

For Lee, the best protection is to ask the right questions. “It starts with asking the right questions and then finding the tools and capabilities for those [AI labs] that are able to demonstrate a higher level of cybersecurity competency,” he says. “You’re really looking for the people on the teams that are dealing with really hard problems.”

But fundamentally, the best preparation to deal with AI model cyber weaknesses is to make sure all the long-standing cybersecurity risk management practices are in place across the organization. “This is the least exciting part of the discussion,” Wallach says. “It’s the cyber version of ‘eat your vegetables.’”

“We need to re-engineer our software so it has better security,” he adds. “We need to have multi-factor authentication on all of our accounts. We need to eat our vegetables from a defensive cyber perspective. And we know how to do it.”

The Daily Front Page 4 of 29
Wednesday, October 14, 2026 The Daily Front No. #261014 — The Amazon Price Machine
article

How Amazon pushes up prices all across the Internet

by sighborg·▲ 755 points·604 comments·not-ship.com ↗
Amazon's rules make sure prices stay high not just at Amazon, but everywhere you shop.

How Amazon pushes up prices all across the Internet

How Amazon pushes up prices all across the Internet

Last week I wrote about how Amazon's search page is designed to screw you over: the top row trap, the swamp of ads, the discount-washing. Today, I'll explain what's going on behind the scenes, and how Amazon's rules make sure prices stay high not just at Amazon, but everywhere you shop.

In a nutshell, here's what's happening:

This isn't just my theory. This system is at the heart of the US Federal Trade Commission's (FTC) upcoming antitrust case against Amazon.

Let's get into it.

Amazon charges sellers a lot of fees

Amazon relies on independent sellers to populate its online marketplace, and it charges them to be on the site. Amazon takes a big cut. In 2014, this was about 19% of sales. But today, many sellers hand close to half of every sale to Amazon. Half!

Amazon's basic commission (15% of the sale price in most categories) is in line with what eBay and Walmart charge. What pushes Amazon's cut higher are the other fees stacked on top.

Where an Amazon sale goes

Based on an apparel seller that opts for Amazon fulfillment, storage, returns and advertising.

There's the referral fee, which is the commission Amazon takes on every sale. The fulfillment fee is the cost to have Amazon pack and ship items from its warehouses. Then there's advertising: those sponsored spots in the top row we saw in last week's article.

Of these costs, only the referral fee is mandatory. Sellers can choose to ship orders themselves, for example, or forgo advertising. But in practice, the choice isn't actually much of a choice.

Here's what it looks like for a seller considering these so-called options:

In other words, the real choice for sellers isn't between paying for extras or not; it's between making sales or not. The FTC calls Prime eligibility, which effectively requires Amazon's fulfillment service, "a virtual necessity for doing business on Amazon." It says the same of advertising.

So, sellers have to raise prices

Here's where the fees are passed on to us consumers. When sellers give roughly half of their sales to Amazon, the other half isn't profit. That money has to cover making the product, shipping it to Amazon's warehouses, paying staff and everything else. So even if they wanted to absorb Amazon's fees on your behalf, most companies can't afford to. They have to raise their prices.

Don't forget, Amazon's biggest single fee — the referral fee — is a percentage of the price. So when prices go up, Amazon's cut goes up, too.

And they can't charge less elsewhere

Now here's where it gets really crazy. Amazon's Fair Pricing Policy lets it remove the Buy Box (the "Add to Cart" button), or even suspend a seller, if they're offering their item cheaper elsewhere. So, a seller who raises prices on Amazon to cover the fees has to raise them everywhere else too — even on their own website! — or risk losing their Amazon sales.

The consequence is clear: We pay Amazon prices, even when we're not shopping on Amazon.

It's been documented again and again. In 2024, Amazon sellers told CNBC they lost the Buy Box after Target put their products on sale. In an ongoing lawsuit, California's attorney general alleges Amazon pushed brands to get Walmart, Target and other retailers to raise their prices. And when progressive media outlet More Perfect Union reported on this, they even found an Amazon seller who was suspended over a one-cent price gap with Target.

Ideally, market competition would sort this out. High prices send shoppers elsewhere and force fees down. But when sellers can't charge less anywhere else, there's nowhere cheaper to go.

There's no easy way out

For sellers, this is frustrating. So, why don't they just leave? Because Amazon is where the shoppers are: it accounts for about 40% of all US online retail sales. For many sellers, not being on Amazon isn't an option.

At least regulators have noticed. In 2023, the FTC and 17 US states sued Amazon, arguing that it illegally maintains its monopoly power by, among other things, punishing sellers who offer lower prices elsewhere, effectively forcing them to use its warehouses and charging ever-higher fees. Amazon denies any wrongdoing, and the case is set to go to trial next year. In Europe, Germany ordered Amazon to stop controlling its sellers' prices earlier this year, though the decision isn't yet final.

After last week's piece, a Not-Ship reader wrote to say none of this is new: plenty of online stores push ads and fake discounts. That is true. But what's different about Amazon is its reach. When prices increase on Amazon, they tend to increase elsewhere too. You can, of course, choose not to shop on Amazon. But if the FTC is right, you may be paying Amazon's prices anyway.

The Daily Front Page 5 of 29
Wednesday, October 14, 2026 The Daily Front No. #261014 — Type for Tight Quarters
article

Iosevka is an open-source, sans-serif and slab-serif monospace font

by otobrglez·▲ 707 points·291 comments·typeof.net ↗
glyphs are exactly 1/2em wide

Iosevka is an open-source, sans-serif + slab-serif, monospace + quasi‑proportional typeface family, designed for writing code, using in terminals, and preparing technical documents.

Spatial Efficient

The Iosevka’s monospace family is provided in a slender outfit by default: glyphs are exactly 1/2em wide. Compared to the competitors, you could fit more columns within the same screen width.

Iosevka provides two widths, Normal and Extended. If you prefer more breeze between the character, choose Extended and enjoy.

# UCD DATA Section
00B0 ; DEGREE SIGN                                ; So ; 0 ; ET ;                           ;  ;   ;     ; N ;                                   ;  ;      ;      ;
00B1 ; PLUS-MINUS SIGN                            ; Sm ; 0 ; ET ;                           ;  ;   ;     ; N ; PLUS-OR-MINUS SIGN                ;  ;      ;      ;
00B2 ; SUPERSCRIPT TWO                            ; No ; 0 ; EN ; <super> 0032              ;  ; 2 ; 2   ; N ; SUPERSCRIPT DIGIT TWO             ;  ;      ;      ;
00B3 ; SUPERSCRIPT THREE                          ; No ; 0 ; EN ; <super> 0033              ;  ; 3 ; 3   ; N ; SUPERSCRIPT DIGIT THREE           ;  ;      ;      ;
00B4 ; ACUTE ACCENT                               ; Sk ; 0 ; ON ; <compat> 0020 0301        ;  ;   ;     ; N ; SPACING ACUTE                     ;  ;      ;      ;
00B5 ; MICRO SIGN                                 ; Ll ; 0 ; L  ; <compat> 03BC             ;  ;   ;     ; N ;                                   ;  ; 039C ;      ; 039C
00B6 ; PILCROW SIGN                               ; Po ; 0 ; ON ;                           ;  ;   ;     ; N ; PARAGRAPH SIGN                    ;  ;      ;      ;
00B7 ; MIDDLE DOT                                 ; Po ; 0 ; ON ;                           ;  ;   ;     ; N ;                                   ;  ;      ;      ;
00B8 ; CEDILLA                                    ; Sk ; 0 ; ON ; <compat> 0020 0327        ;  ;   ;     ; N ; SPACING CEDILLA                   ;  ;      ;      ;
00B9 ; SUPERSCRIPT ONE                            ; No ; 0 ; EN ; <super> 0031              ;  ; 1 ; 1   ; N ; SUPERSCRIPT DIGIT ONE             ;  ;      ;      ;
00BA ; MASCULINE ORDINAL INDICATOR                ; Lo ; 0 ; L  ; <super> 006F              ;  ;   ;     ; N ;                                   ;  ;      ;      ;
00BB ; RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK ; Pf ; 0 ; ON ;                           ;  ;   ;     ; Y ; RIGHT POINTING GUILLEMET          ;  ;      ;      ;
00BC ; VULGAR FRACTION ONE QUARTER                ; No ; 0 ; ON ; <fraction> 0031 2044 0034 ;  ;   ; 1/4 ; N ; FRACTION ONE QUARTER              ;  ;      ;      ;
00BD ; VULGAR FRACTION ONE HALF                   ; No ; 0 ; ON ; <fraction> 0031 2044 0032 ;  ;   ; 1/2 ; N ; FRACTION ONE HALF                 ;  ;      ;      ;
00BE ; VULGAR FRACTION THREE QUARTERS             ; No ; 0 ; ON ; <fraction> 0033 2044 0034 ;  ;   ; 3/4 ; N ; FRACTION THREE QUARTERS           ;  ;      ;      ;
00BF ; INVERTED QUESTION MARK                     ; Po ; 0 ; ON ;                           ;  ;   ;     ; N ;                                   ;  ;      ;      ;
00C0 ; LATIN CAPITAL LETTER A WITH GRAVE          ; Lu ; 0 ; L  ; 0041 0300                 ;  ;   ;     ; N ; LATIN CAPITAL LETTER A GRAVE      ;  ;      ; 00E0 ;
00C1 ; LATIN CAPITAL LETTER A WITH ACUTE          ; Lu ; 0 ; L  ; 0041 0301                 ;  ;   ;     ; N ; LATIN CAPITAL LETTER A ACUTE      ;  ;      ; 00E1 ;
00C2 ; LATIN CAPITAL LETTER A WITH CIRCUMFLEX     ; Lu ; 0 ; L  ; 0041 0302                 ;  ;   ;     ; N ; LATIN CAPITAL LETTER A CIRCUMFLEX ;  ;      ; 00E2 ;
00C3 ; LATIN CAPITAL LETTER A WITH TILDE          ; Lu ; 0 ; L  ; 0041 0303                 ;  ;   ;     ; N ; LATIN CAPITAL LETTER A TILDE      ;  ;      ; 00E3 ;
00C4 ; LATIN CAPITAL LETTER A WITH DIAERESIS      ; Lu ; 0 ; L  ; 0041 0308                 ;  ;   ;     ; N ; LATIN CAPITAL LETTER A DIAERESIS  ;  ;      ; 00E4 ;
00C5 ; LATIN CAPITAL LETTER A WITH RING ABOVE     ; Lu ; 0 ; L  ; 0041 030A                 ;  ;   ;     ; N ; LATIN CAPITAL LETTER A RING       ;  ;      ; 00E5 ;
00C6 ; LATIN CAPITAL LETTER AE                    ; Lu ; 0 ; L  ;                           ;  ;   ;     ; N ; LATIN CAPITAL LETTER A E          ;  ;      ; 00E6 ;
00C7 ; LATIN CAPITAL LETTER C WITH CEDILLA        ; Lu ; 0 ; L  ; 0043 0327                 ;  ;   ;     ; N ; LATIN CAPITAL LETTER C CEDILLA    ;  ;      ; 00E7 ;
00C8 ; LATIN CAPITAL LETTER E WITH GRAVE          ; Lu ; 0 ; L  ; 0045 0300                 ;  ;   ;     ; N ; LATIN CAPITAL LETTER E GRAVE      ;  ;      ; 00E8 ;
00C9 ; LATIN CAPITAL LETTER E WITH ACUTE          ; Lu ; 0 ; L  ; 0045 0301                 ;  ;   ;     ; N ; LATIN CAPITAL LETTER E ACUTE      ;  ;      ; 00E9 ;

Code and Terminal

Terminal emulators have a stricter compatibility requirements for fonts. Therefore, Iosevka and Iosevka Slab all contain two specialized families, Term and Fixed, targeting terminal users.

In these families, the symbols will be narrower to follow terminals’ ideology of column count. In the Fixed families, the ligation will be disabled to ensure better compatibility in certain environments.

Variants à la Carte

Iosevka provides 146 configurable characters with 19 stylistic sets, which gives you incredible ability to customize one variant that fills exactly what you need. You can either select one pre-defined stylistic set, or cherry-pick your flavor.

The Daily Front Page 6 of 29
Wednesday, October 14, 2026 The Daily Front No. #261014 — The Case for Passkeys
article

Passkeys are not a trap

by speckx·▲ 530 points·685 comments·scotthelme.co.uk ↗
Passkeys Are Not a Trap

A post called Passkeys are a trap. Do not use them. has been doing the rounds over the last few days, making it pretty high on Hacker News, and I've had it sent to me many times with an 'is this true?' kind of vibe. It's written for "non-technical citizens of the web", and the headline advice is to stop using passkeys and go back to TOTP codes and passwords.

The Argument

The post makes what appears to be one central claim: Passkeys support something called attestation, which lets a website ask for cryptographic proof of what made the passkey.

The author calls this a "hidden dial" and argues that sites will slowly turn it up, until you're only allowed to log in with approved software on an approved operating system, with no modifications, no LineageOS and no sharing your Netflix password. Throw in uBlock Origin, the FIDO Alliance membership list and the UK's image-scanning proposals, and the conclusion is that passkeys are "not designed to prioritize your interests". <that-escalated-quickly.gif>

It's a compelling story. It just doesn't match how any of this actually works...

Your Passkeys Don't Attest

The passkeys most people use are synced passkeys, stored in iCloud Keychain, Google Password Manager, 1Password, Bitwarden or whatever other software of your choosing. These passkeys don't give websites an attestation statement at all, and though a site can ask, what comes back is none. I know this because I wrote an opensource passkeys library and made it available to everyone.

If a consumer website decided tomorrow that it would only accept attested passkeys, it would lock out almost all of its own users, instantly. What website is going to do that? Besides, the guidance for consumer sites has been to not even request attestation for years now.

Attestation Isn't What You Think It Is

The post describes attestation as proving "that an approved passkey manager, operating system, and firmware are in use" which is simply not true.

When it is present, WebAuthn attestation tells the site the make and model of the authenticator, identified by its AAGUID, with a certificate chain from the vendor to back it up. It says nothing about your OS, your browser, your extensions, whether your phone is rooted or jailbroken, your firmware version, or even what colour it is.

The YubiKey Recommendation

This is the part that surprised me the most. For people who want stronger security, the post recommends a hardware security key like a YubiKey, because it "avoids OS-wide attestation".

YubiKeys are the authenticators that do attestation. Every one of them ships with a Yubico-issued attestation certificate, and enterprise attestation exists specifically so organisations can require approved hardware keys. I'd still recommend a YubiKey to anyone who wants one, they're excellent and I use them, but if attestation is the thing you're worried about, the post's own recommendation pushes you towards attestation rather than away from it!

TOTP Is a Step Backwards

The post holds up TOTP as "already" a great solution. TOTP is better than a password alone, absolutely, but it has one big weakness: you can type the code into the wrong website, just ask my good friend Troy Hunt. Phishing kits like Evilginx sit in the middle, relay your password and code to the real site in real time, and walk away with your session. This isn't theoretical, it's how a huge number of account takeovers happen today and we have the evidence to prove it.

This is the problem that passkeys solve. A passkey is bound to the domain it was created for, so your browser simply won't use your example.com passkey on examp1e.com. There's no code to read out and nothing for the user to get wrong. The author even concedes this in the addendum, saying that passkeys are domain-bound and resist man-in-the-middle attacks, but still tells readers to avoid them. Swapping a phishing-resistant credential for a phishable one is a really bad trade...

What You Should Do

Keep using passkeys! Wherever a site offers one, take it, and store it in a password/passkey manager you trust. If you want to be able to move your credentials around, pick a provider that supports that. If you're worried about attestation creeping into consumer logins, then that's worth pushing back on, loudly (if it ever happens). But it hasn't happened, the biggest providers don't support it, and avoiding passkeys today while you wait for it won't protect you from anything, it just leaves you open to phishing.

Sources

I have some experience in this area:

I created WhyNoPasskeys.com to track the availability of passkeys on the Web.

I built and deployed passkeys support on my own SaaS company.

We built our own passkeys library and had it security reviewed.

I wrote about Security considerations when using Passkeys on your website.

I wrote Passkeys 101: An Introduction to Passkeys and How They Work.

I made our passkeys library opensource for everyone to use.

I've done extensive security testing of passkeys implementations.

I've openly acknowledged the limitations of not using attestation on passkeys.

I think most of all that it's important to say I use passkeys everywhere I can because they're currently the best thing we have available to protect our accounts. And they're not a trap.

The Daily Front Page 7 of 29
Wednesday, October 14, 2026 The Daily Front No. #261014 — The Domestic Watch
article

ICE Planning $100M 'Nightmare' Domestic Spy Program

by bhrlady·▲ 495 points·304 comments·prospect.org ↗
a significant expansion of the agency’s ability to reach into private lives

Under ERO ONE, Immigration and Customs Enforcement plans to hire 142 intelligence contractors with top secret clearances and deploy them in cities across the country.

ICE officer collage

Credit: Douglas Rissing/iStock

Immigration and Customs Enforcement is fast-tracking a $100 million domestic surveillance program to put 142 intelligence agents in more than two dozen cities and the District of Columbia, in what contracting and surveillance experts said would be a significant expansion of the agency’s ability to reach into private lives.

The new program is called the Enforcement and Removal Operations Overwatch and National Security Enforcement, or ERO ONE, described in documents posted last month on federal procurement websites.

Under the program, agents would analyze classified and unclassified information to identify “trends, patterns, relationships, threats, and intelligence gaps,” and provide ICE with briefings for Enforcement and Removal Operation missions, according to a statement of work published on September 18. A forecasting document published a week earlier said that the solicitation will likely be released on December 10. Intelligence contracting experts said the timeline suggests ICE will award the contract around February.

“It looks dangerously like the construction of an internal spying agency,” said Jay Stanley, senior policy analyst at the American Civil Liberties Union’s Speech, Privacy, and Technology Project, who has written extensively on immigration agencies’ mass surveillance. “It’s a nightmare in the making.”

It’s also a weapon that the government will likely use against not only undocumented immigrants, but everyone else, too. That includes political enemies, intelligence experts said. Speaking with the Prospect on Monday as news broke that the Trump regime had raided progressive Minnesota Rep. Ilhan Omar’s D.C. home, former military intelligence analyst Michael Wriston said that “you’d expect to see more of this” under ERO ONE.

“Not just necessarily sitting members of Congress, but anyone, and especially members of the immigrant community,” Wriston said. “No one is safe. No one.”

THE PLAN DOES NOT SPECIFY WHAT OR WHOM ICE is looking for with this increased spying capability. But one of the components that caused former intelligence contractors’ concern was that ERO ONE agents will analyze both classified and nonclassified information to produce “network, link and relationship” analyses. That type of analysis involves researching not only a target, but also every other person to whom they’re connected, including household members, family members, friends, acquaintances, or the person with whom they carpool to work.

According to the statement of work, contractors will be tasked with conducting analytical research “to identify and assess relationships among individuals, organizations, locations, events, activities, data points, and other entities.” They will review information to identify “known, reported, or potential relationships; recurring patterns; organizational structures; associations; areas of convergence; temporal or geographic connections; and other linkages relevant to the assigned intelligence requirement.” Contractors will then “evaluate the significance and reliability” of the relationships and “prepare link charts, network diagrams, timelines, analytical summaries, written assessments, or other related products” for ICE to use.

Military intelligence agents compile the same type of research, Wriston said. He knows because he did that job.

“We’ve seen this time and time again. It’s the imperial boomerang,” said Wriston, who is also a data journalist and the founder of ICE watchdog group Project Salt Box, where he reported on ERO ONE the day the first document went live and has written about it since. “These are the kinds of things that happened in Afghanistan, Iraq, Yemen, Syria, for years. Now that methodology is being brought into the ICE space.”

Federal documents likewise do not detail the specific sources of information agents will analyze, only that all agents must possess previously awarded active top secret clearance, with eligibility to access Sensitive Compartmented Information. That’s a type of information that must be accessed through certain formal control systems managed by the Director of National Intelligence, a position held by Trump ally Jay Clayton. The agents will not make any decisions about what to do with the information they compile.

Wriston said that except for the fact that ICE officials are trying to make immigration a matter of national security, it’s unclear why they need this program when they already have the Homeland Security Investigations unit, which conducted the raid on Omar’s house, to research targets. His immediate worry, he said, is that the program will make it easier for the government to find terrified immigrants hiding at home because they think they’ll be safe there.

ICE PLANS TO SEND THE 142 AGENTS, plus two project managers, to locations in Atlanta, Boston, Buffalo, Chicago, Dallas, D.C., Denver, Detroit, El Paso, Harlingen (Texas), Houston, Laguna Niguel (California), Los Angeles, Miami, New Orleans, New York, Newark, Philadelphia, Phoenix, Salt Lake City, San Antonio, San Diego, San Francisco, Seattle, St. Paul, and Williston (Vermont), according to the statement of work.

Details in the document, and the rapid timeline, show that the Trump administration intends to use the program immediately, said Brian Murphy, a government contractor who worked for 25 years with ICE parent agency DHS. It’s rare for the government to only want workers with top secret clearance, he said.

“I’ve only seen it when there is an imminent need to work on something right now,” he told the Prospect. “Trump has two years in office. He can’t wait … they want to get rolling on this immediately.”

The program description is so broad that Murphy said he thinks the goal goes beyond targeting immigrants. “I think it’s darker than that,” because the agency could use the intelligence to attack people with identities and views the Trump regime doesn’t like. “The question for DHS is, what is the threat they’re trying to go after?”

“It looks dangerously like the construction of an internal spying agency.”

Jay Stanley, American Civil Liberties Union

The federal government can easily change who qualifies as a threat and produce data that backs up the reasoning, Murphy said, and used as an example annual Homeland Threat Assessments. In 2020, Secretary of Homeland Security Chad Wolf identified white supremacist extremists as “the most persistent and lethal threat in the Homeland.” But by last year, that threat had disappeared from the report, except to appear once in a glossary of terms. The rest of the report focused heavily on Trump administration priorities as national security threats, including immigrants crossing the border with Mexico and transnational criminal organizations.

In addition, the murders of Renee Good and Alex Pretti have shown how the government views protesters against ICE abductions as an abiding threat. In a national security directive known as NSPM-7, President Trump identified anti-fascist protesters as domestic terrorists and proposed an architecture to disrupt and counter dissent.

“If you want to draw a narrative that the real threat to America is whatever you want it to be, you can very easily do that. You just stop gathering intel on militias,” Murphy said. “It’s like any other police state. If you ask it to find something to make my opponents the enemy, well, you can do that.”

Legal liability should be a major concern for anyone who bids on the ERO ONE contract, Murphy said, because it’s unclear whether the information they’d be charged with accessing had been gathered legally. He added, “It’s very, very concerning that they’re fast-tracking this.”

Stanley, the ACLU analyst, noted that immigration officials across agencies have been using an excessive amount of surveillance tools for years, including their “Stingray” cell tower simulators, automatic license plate readers, and tools that track location from cellphones. They use a facial recognition and biometric collection app called Mobile Fortify, a Palantir app called ImmigrationOS to track immigrants’ movements, and buy data from LexisNexis to identify someone’s family and work history. ERO ONE would draw on all of that information, plus an expanded group of sources to reach into the private lives of anyone it wants, intelligence experts said.

ICE already knows its potential bidders for ERO ONE, said Diana Brozi, the procurement specialist listed on the document. She told the Prospect it was unlikely the agency would hold an industry day and declined to provide further information.

DHS did not respond to a request for information or comment on the claim that the program could be used to spy on political enemies.

The Daily Front Page 8 of 29
Wednesday, October 14, 2026 The Daily Front No. #261014 — Android, Disassembled
repository

AOSP Source Releases Are So Late Developers Disassemble Libraries to Report Bugs

by tharen·▲ 489 points·241 comments·github.com ↗
★ 2,326⑂ 312 forks

The Android Native Development Kit

Description

On Android 17 builds from September 2026, wcscspn() and wcspbrk() stop at the first character of the string that is >= U+0100 whenever the reject set has two or more characters that are all < U+0100. The character is reported as a match even though it is not in the set. wcsspn(), wcschr(), wcsrchr(), wmemchr() and wcsstr() are correct.

Any code that scans wide strings for ASCII delimiters, for example newline or wildcard characters, breaks as soon as the text contains an emoji, CJK, Cyrillic, Greek or Latin Extended character.

Affected / unaffected

Device Build Result
Pixel 7 google/panther/panther:17/CP3A.260905.009/16091614:user/release-keys broken
Pixel 8a google/akita/akita:17/CP3A.260905.009/16091614:user/release-keys (patch 2026-09-05) broken
Nothing Phone 2 Nothing/PongEEA/Pong:16/BQ2A.250721.001-BP2A.250605.031.A3 (patch 2026-08-01) ok

The public android17-release sources (android-17.0.0_r1, June 2026) build wcscspn/wcspbrk from external/llvm-libc, which is a plain nested loop over wchar_t and is correct. The code on the September builds is different (see "Mechanism"), so the regression was introduced between the June and September releases.

Reproducer

Build with the NDK (aarch64-linux-android30-clang), push to /data/local/tmp, run with adb shell:

#include <stdio.h>
#include <wchar.h>

int main(void)
{
    wchar_t s[] = {'a', 0x1F680, 0x100, 'b', 'x', '\n', 0};
    printf("wcscspn(s, L\"x\\n\") = %zu (expected 4)\n", wcscspn(s, L"x\n"));
    printf("wcspbrk(s, L\"x\\n\") = index %ld (expected 4)\n", (long)(wcspbrk(s, L"x\n") - s));
    printf("wcsspn(s, L\"a\\U0001F680\") = %zu (expected 2)\n", wcsspn(s, L"a\U0001F680"));
    return 0;
}

Output on CP3A.260905.009:

wcscspn(s, L"x\n") = 1 (expected 4)
wcspbrk(s, L"x\n") = index 1 (expected 4)
wcsspn(s, L"a\U0001F680") = 2 (expected 2)

A sweep of every code point from U+0001 to U+10FFFF (skipping surrogates and the two set members) with wcscspn(L"<cp>\n", L"x\n") returns 0 instead of 1 for 1,111,808 code points: every one from U+0100 to U+10FFFF. U+0001 to U+00FF are correct.

Which set shapes trigger it (all measured on the Pixel 8a):

Reject set Result
one character ok
two or more characters, all < U+0100 (e.g. L"x\n", L"\xe9\n") broken
two or more characters, at least one >= U+0100 ok
haystack limited to U+0080..U+00FF ok

Mechanism (from the shipped libc.so)

Disassembly of wcscspn in /apex/com.android.runtime/lib64/bionic/libc.so on CP3A.260905.009 shows three paths selected by the set:

  1. One character: a plain compare loop. Correct.
  2. Two or more characters: a 256-byte bool table on the stack is filled from the set while the set characters are in 1..0xFF. If a set character >= 0x100 is seen, the function falls back to calling wcschr() for each haystack character. Correct.
  3. Otherwise the haystack is scanned against the table:
a2564:  ldrb  w8, [x9, x8]        ; table[c]
a2568:  tbnz  w8, #0, a2578       ; in set -> stop (correct)
a256c:  ldr   w8, [x22, #0x4]!    ; next character
a2570:  cmp   w8, #0x100
a2574:  b.lo  a2564               ; c < 0x100 -> keep scanning
a2578:  ...                       ; c >= 0x100 -> STOP, reported as a match

A character >= 0x100 cannot be in a set whose members are all < 0x100, so for wcscspn the scan must continue past it. The code stops instead. wcsspn has the same structure, and there stopping is the correct answer (the character is not in the keep set), which is why only the complement functions are wrong. wcspbrk is implemented on top of this scan and inherits the bug.

The existing bionic test TEST(wchar, wcspbrk) in tests/wchar_test.cpp only uses ASCII input, so it does not catch this. A test such as EXPECT_EQ(3u, wcscspn(L"aĀb\n", L"x\n")) would.

Real-world impact

Visual Pinball on Android (libwinevbs, a Unix build of Wine's vbscript engine) stopped loading any table whose VBScript source contains a comment with an emoji after the September update: the lexer uses wcspbrk(ptr, L"\n\r") to skip comments, got the position of the first emoji instead of the line end, and reported "Invalid character". FileSystem.MoveFolder likewise treated every path containing a character >= 0x100 as a wildcard pattern via wcspbrk(src, L"*?><").

Worked around downstream by replacing the calls with plain loops: vpinball/libwinevbs#41 (shipped in vpinball/vpinball@e7837322f4).

Full disassembly of the affected functions and the probe sources are available on request.

I am using a supported NDK

  • I have checked and the NDK I'm using is currently supported

Affected versions

r29

The Daily Front Page 9 of 29
Wednesday, October 14, 2026 The Daily Front No. #261014 — OpenCode Rebuilt
article

OpenCode 2.0

by gmays·▲ 396 points·167 comments·anoma.ly ↗
this server now automatically runs as a single background process on your machine

OpenCode 2.0 is a major overhaul. It draws on millions of daily users' experience to deliver a system that can flex to everything an agent needs to be. There are quite a lot of new features, performance improvements, and bug fixes but here are some of the more impactful user-facing changes.

The Service

From the beginning OpenCode adopted a client/server model. However, this was not something it took advantage of by default and was mostly used by power users.

In 2.0 this server now automatically runs as a single background process on your machine. When you open up a TUI, the web interface or the desktop app they're all talking to the same central process.

If you're using the programmatic client @opencode/client to make your own scripts, they will autodiscover the local service and just work. This is particularly useful for scheduled tasks. You can also call it via CLI by using opencode api commands.

You can expose it to other hosts and run /pair or opencode pair to connect it to other applications. We have native apps in the works that take advantage of this flow.

The API

The old API grew haphazardly as we and the world collectively learned what agents are and should be. It was bad.

We started from scratch and examined all the weird use cases across the millions of users who use OpenCode every day. It now supports nearly anything you need to be able to do.

OpenCode is also aware of its own API and will call it to do useful things like moving the current session into a git worktree when starting new work.

We've also shipped a new client package @opencode/client that contains clients for vanilla JavaScript as well as Effect.

import { OpenCode } from "@opencode/client"
import { Service } from "@opencode/client/service"

const endpoint = await Service.ensure()
const client = OpenCode.make({
  baseUrl: endpoint.url,
  headers: Service.headers(endpoint),
})

const session = await client.session.create({
  location: { directory: process.cwd() },
})

await client.session.prompt({
  sessionID: session.id,
  text: "Review the current changes",
})

Code Mode

The models love to write code and OpenCode 2.0 takes advantage of that more than any other coding agent. We've built a minimal JavaScript interpreter in the @opencode/codemode package.

This package ingests MCP servers or OpenAPI endpoints, converting them into functions that the agent can call in a script. It can run these scripts natively without the complexity of Node.js VMs or embedding complicated solutions like QuickJS.

This lets your agent write scripts that can do things like call a tool, map over the results and call another tool. Single round trip instead of calling them one at a time.

All MCP servers in 2.0 are opted into code mode by default. This means you can add a thousand of them with minimal context bloat and your agent will discover and compose them to get things done.

Background Tasks

The latest batch of models are incredibly good at orchestration and it is important for harnesses to let them express the full extent of that capability.

First, we've added background subagents. This allows the primary agent to kick off some work to another one while it continues.

This happens automatically but you can also trigger it manually - even with a different model. It lets you do things like “spawn a background fable subagent to review this code” while you keep prompting.

Second, we've added background shell commands. The shell tool can be invoked asynchronously so long-running work does not have to block the primary agent. It'll be notified when things are complete.

If any foreground shell command or subagent takes longer than you expect, you can hit a hotkey to move them to the background so you can keep prompting.

Plugins

Although OpenCode 1.0 had a plugin system, it never got the attention it needed. To correct that, we forced ourselves to implement nearly every OpenCode 2.0 feature as an internal plugin and there are now 80+ of them. This guarantees that the Plugin API stays well maintained.

We've also promoted TUI plugins from experimental to stable. Since it is all powered by OpenTUI, you can build nearly anything. Here is an example of something useless.

We also spent quite a lot of time ensuring everything in OpenCode 2.0 can be hot-reloaded. So it can write a plugin for itself mid-session and use it right away - we covered the design of this in a previous blogpost.

You can ask OpenCode to build whatever plugin you want and it knows how to. But if you do want to read the docs, they are available here.

The SDK

OpenCode can also now be used as a library with the @opencode/sdk package. This is the exact same code that powers our CLI.

This means you can strip it down and make your own flavor of OpenCode that runs on a server or in specialized environments like Durable Objects. And then you can connect to it from any OpenCode client since it speaks the standard OpenCode server protocol.

It also has an optional Effect-based API.

This one is still in development as things are shifting but you can already use it.

Upgrading

To upgrade the CLI, make sure you're on the latest 1.x release, then run opencode upgrade --major.

To upgrade your desktop app, download the latest here.

There are some breaking changes.

1.0 plugins will not work in 2.0

Server API is completely different

tui.json config is moved to json

There are a lot of other changes but they are backwards compatible. It is worth pointing OpenCode at this doc so it can migrate things for you.

The Daily Front Page 10 of 29
Wednesday, October 14, 2026 The Daily Front No. #261014 — The AI Debt Pile
article

Banks are now trying to offload the AI data center debt they just underwrote

by smartmic·▲ 332 points·234 comments·startupfortune.com ↗
some of the same banks are trying to get that debt off their books

Banks are now trying to offload the AI data center debt they just underwrote

JPMorgan, Morgan Stanley, SMBC and MUFG are quietly shopping pieces of the AI debt pile they helped build, a sign the lenders closest to the money have started hedging their own bet.

Six months ago, banks were racing each other to underwrite data center loans tied to Oracle, Meta and the rest of the AI buildout. Now some of the same banks are trying to get that debt off their books. JPMorgan, Morgan Stanley, SMBC and MUFG have been exploring significant risk transfers, according to a report from the Financial Times. These are deals that let a bank keep a loan on paper while shifting its riskiest slice to outside investors. The banks are doing this because they are bumping up against internal limits on how much AI-linked exposure any one lender can hold.

One case shows how stuck this has gotten. A group of banks including JPMorgan and MUFG has spent more than six months trying to distribute $38 billion in construction debt tied to a Texas and Wisconsin data center project leased to Oracle, Bloomberg has reported. Some lenders are now willing to sell pieces of it to non-bank buyers at a discount, just to move it. Six months is a long time to sit on debt nobody underwrote to hold forever.

Matthew Moniot, co-head of credit risk sharing at Man Group, told the Financial Times the deal sizes involved are "out of scale to anything we've thought about, ever." That is not a hedge-fund manager talking down a trade he wants no part of. It is someone whose job is pricing exactly this kind of risk, saying the numbers no longer fit any model he has used before.

Oracle is the clearest tell. Its five-year credit default swaps, the cost of insuring against the company defaulting, climbed to around 151 basis points in early October, levels last seen in 2009, according to market data cited by Bloomberg. S&P had already cut Oracle's credit rating to BBB-, a single notch above junk, back in July. The company is reportedly targeting more than $40 billion in additional debt and equity this fiscal year. That is on top of the $18 billion in bonds it sold in a single day last September, and the money is needed to keep funding its Texas, Wisconsin and New Mexico sites.

Demand for that paper has thinned out, too. Bonds from Alphabet, Amazon, Meta, Microsoft and Oracle now trade at a premium to similarly rated non-AI corporate debt. Order books for their offerings have shrunk from roughly five times the amount on sale back in February to under two times by July, Bloomberg has reported. That is the difference between a bond that sells itself and one a bank has to work to place.

None of this is happening in isolation. The 10-year Treasury yield hit 5.304% this month, its highest since 2002, after a $39 billion auction cleared at 5.30%, the highest auction yield since 2000. The Federal Reserve's own September meeting minutes named AI-related corporate borrowing as a contributor to that move. Capital Economics argues the bigger driver is plain old inflation and government deficits, not tech company bond sales. Whoever is right about the cause, the effect is the same for anyone trying to finance a data center right now: the risk-free rate they are borrowing against just got a lot more expensive.

Frankly, the mechanics here matter more than the headline number. Banks do not sell down debt they are confident in. They sell down debt when they are worried about concentration, which is exactly what "approaching internal limits" means in plain English: too much of this bank's balance sheet is now one bet on one sector holding up. Spreading $120 billion of AI infrastructure spending across special purpose vehicles was supposed to make that risk easier to swallow. That is the structure Oracle, Meta, xAI and CoreWeave have all used to keep debt off their own balance sheets. Instead the risk is turning up at the banks that financed the SPVs in the first place.

The investors who still want in have gotten pickier about where. Capital is rotating toward data centers leased to investment-grade hyperscalers like Microsoft and Google, and away from weaker credits, Bloomberg has reported. That is exactly why CoreWeave-leased paper prices at 7.00% to 9.875%, against the 5.70% to 7.875% that hyperscaler-leased bonds command, per bond market data compiled by CCIR. A smaller, less capitalized AI infrastructure company trying to raise debt next quarter is now competing for the same nervous pool of lenders as Oracle. Except without Oracle's balance sheet or its existing customer base to point to.

That's the part of this story that does not show up in a single day's stock move. The AI boom still runs on the assumption that credit stays open indefinitely at reasonable terms. Six months of a bank struggling to sell $38 billion in loans is the clearest evidence yet that assumption is being tested in real time, not in some theoretical downturn still years away.

The Daily Front Page 11 of 29
Wednesday, October 14, 2026 The Daily Front No. #261014 — Source Control’s Prior Art
article

Anthropic's Scion is heavily inspired by Mononoke

by sunshowers·▲ 299 points·119 comments·sunshowers.io ↗
Anthropic’s Scion is heavily inspired by Mononoke

Here is Anthropic describing (archive link) yesterday how their new version control system, Scion, uses a concept called “derived data” to make operations like blames more efficient:

A changeset records only what’s changed, so on its own, it can’t quickly answer questions like who last edited a line or which commits affected a file. To answer those, Scion builds additional data structures from the changesets, including dedicated structures for file blame and path history and skip lists for the commit graph. We call everything that isn’t directly part of the changeset “derived data,” and we compute it all through one generic mechanism. Each type of derived data is defined recursively, so its value for a changeset is computed from its values for that changeset’s parents. This mechanism has three benefits. First, we can easily add a new type of derived data when a new data structure would make some operation faster. Second, for each type, we can choose whether to compute it eagerly or defer the work, so we avoid materializing data we don’t need. And third, because the client never sees the internals of these data structures, we can optimize them without changing the client. We’ve added new types of derived data many times as the system has grown, such as new indices for performing copy detection or path-based file search.

How Anthropic describes Scion’s derived data.

Here is me, back in 2022, describing in my Oxide candidate materials how the Mononoke source control server I helped build uses a concept called “derived data” to make operations like blames more efficient:

Derived data. While Bonsai changesets work great for pushes, they work less well for things like diffs. Git diff commit1..commit2 is an O(n log n) operation where n is the number of changed files – with Bonsai changesets, you’d have to look at every single commit between commit1 and commit2 to compute the list of files changed. For a large repository this can be orders of magnitude slower (and compounds the pointer-chasing problem). To solve this, we moved the diff-friendly representation to being derived data (i.e. an index). The server creates a separate Merkle DAG with a Git-like tree/blob model, with pointers back to Bonsai changesets as required. Note that: Derived data can be computed and stored asynchronously, outside of the main critical section. The pointers between commits and trees are flipped around. With the Git data model, the text of a commit contains the hash of the root tree. With the Bonsai model, the text of the root tree contains the hash of the commit that introduced it. This gave us the ability to build out other derived indexes for whatever other operations we wanted. For example, git blame is quite slow on large git repositories, requiring a traversal of the entire repository (not just commits that touch the file). With Mononoke, we built out a blame-friendly index where each version of each file was a separate node in the Merkle DAG, with its parent set to the previous version of the file, and with pointers back to Bonsai changesets. This meant that blames became O(number of commits that touch the file) rather than O(number of commits in the repository). Over time, the team has added more indexes to handle specific use cases, and Mononoke now has 8 separate indexes. Adding a new index is a relatively cheap operation that doesn’t involve any fundamental changes to data structures.

How I described Mononoke’s derived data.

I think the level of imitation goes well beyond having similar insights1. The fact that Sapling was only credited for “hard-won lessons”, and that Mononoke was not mentioned at all, borders on plagiarism. The post comes off as Anthropic claiming that Claude designed all this, while the reality is that our (extraordinary) team at Meta came up with many of the insights that Claude dutifully applied almost a decade later. (We looked at plenty of prior art for Mononoke and Sapling too, from Google’s SrcFS to write-ahead logs in databases.)

I am very glad that the vision our team had back in 2017-18 was so powerful and enduring — when you go against the grain, you’re always a bit unsure if what you’re doing is genius or madness, and I think Mononoke’s design has stood the test of time. And, to be clear, I do not have a problem with Anthropic copying Mononoke’s design. (This is part of why we put out open source — to benefit humanity through the spread of good ideas.)

But as LLMs continue to assist in designing new systems, they are likely to index heavily on existing designs. Mononoke is open source and in every LLM’s training set. If you ask Opus 5.5 or GPT-6 Astra (thanks Matthew Fowle) about prior art, they both immediately point out the similarities to Mononoke.

Giving credit to those that came before us is now easier — and more important — than ever. There is no longer an excuse.


  1. For an example of a system with similar insights but many key design differences, see Vicent Marti’s blog post for Cursor. ↩︎
The Daily Front Page 12 of 29
Wednesday, October 14, 2026 The Daily Front No. #261014 — Alone Together
article

Americans' social activity has steeply declined in the past 30 years

by hubraumhugo·▲ 280 points·291 comments·dataforprogress.org ↗
American loneliness to be an “epidemic.”

In recent years, there has been extensive discussion of a social decline in the United States, including a U.S. surgeon general advisory in 2023 that declared American loneliness to be an “epidemic.”

Various surveys have tracked America’s social decline over the past few decades. Tracking data from the American Time Use Survey shows that Americans are spending more time alone and less time with friends than they were two decades ago. Perhaps most notably, the American Perspectives Survey has found that from 1990 to 2021, the percentage of Americans with five or more close friends dropped by 25 points, from 63% to 38%.

But while extensive public tracking data show general declines in Americans’ socialization, little, if any, public data show what this looks like for the average American — how the day-to-day activities Americans participate in have changed over the past few decades.

In a new survey, Data for Progress surveyed 1,098 U.S. adults and asked them how many times they engaged in various specific social activities in the past 12 months. These questions directly replicate the DDB Needham Life Style surveys, which tracked Americans’ participation in various activities from 1975-1999 and were referenced in Robert Putnam’s 2000 book “Bowling Alone.” In this analysis, Data for Progress’ 2026 data is compared with the DDB Needham Life Style survey from 1995, which is the earliest year in which full data for all comparison questions was available.

This survey finds significant, double-digit declines in Americans’ participation in key social activities from 1995 to 2026.

The chart below compares the percentage of Americans who report participating in each tested activity at least one time in the past 12 months, between the 1995 and 2026 surveys. We find that Americans’ participation in various social activities has declined by double-digit margins, including attending a class or seminar (-22), entertaining people in your home (-21), attending church or a place of worship (-20), going on a picnic (-19), going to a club meeting (-19), playing cards (-19), going out to breakfast at a restaurant (-13), and doing volunteer work (-12).

A few activities have seen increased engagement: using the internet (+90), playing a home video game (+22), attending an exercise class (+14), going to a pop or rock concert (+13), and taking an airline trip for personal reasons (+5).

Methodology note: This analysis compares two surveys conducted using different methodologies, including differences in constructing sampling frames, modes, and weighting approaches. The findings below should be read as suggestive of trends, not a precise estimate of change. Please see the “Methodology” section below for more information.

One of the steepest declines in the survey is for “entertaining people in my home.” While in 1995, 88% of Americans reported entertaining others at home at least once in the past year, this number has declined to 67% in 2026.

Church attendance has dropped from 74% in 1995 to 54% in 2026.

The percentage of Americans who report having gone on a picnic in the past year has declined from 58% in 1995 to 39% in 2026.

There has also been a 19-point decline in attendance at club meetings, from 45% in 1995 to 26% in 2026.

This analysis adds to existing public data on America’s social decline. Previous reports have found that Americans are spending less time with others and reporting fewer close friends. This new analysis demonstrates that Americans are indeed spending less time in specific social settings, such as restaurants, churches, picnics, parties, bars, and social clubs.


Methodology

The DDB Needham survey was conducted by Market Facts using a stratified quota sampling procedure that begins with a sampling frame acquired from commercial list brokers. The sample oversamples by demographics such as race, gender, and marital status to oversample lower propensity respondents. Finally, the survey contacted individuals via mail.

In comparison, the Data for Progress adult sample was conducted through web panel suppliers and ensured national representativeness via quota fielding and post-stratification weighting.

There is plenty of research on the compositional differences that exist across survey collection modes, and this is likely to affect these results as questions about religiosity and loneliness tend to demonstrate modal differences and social desirability biases. We understand that these factors are at play in our comparison, but find that the magnitude and consistency in trends across measures is a substantial signal about trends in behaviors nonetheless.

The Daily Front Page 13 of 29
Wednesday, October 14, 2026 The Daily Front No. #261014 — Bot Traffic, Rerouted
article

Yandex outage: data shows that instead of going dark, malicious bots moved

by coloneltcb·▲ 238 points·76 comments·blog.cloudflare.com ↗
instead of going dark, malicious bots went on the move

Following reported strikes on Yandex data centers, claims circulated on the Internet that Russian bot farms and influence operations had been knocked offline. HTTP traffic charts showed steep drops, fueling speculation that the infrastructure damage had stopped these malicious actors. However, aggregate traffic metrics can easily mislead. There are two autonomous system numbers (ASNs) associated with Yandex: AS13238 is used by Yandex’s search engine, while AS200350 runs its cloud services.

Using Cloudflare Radar and Bot Management data, we analyzed how these two ASNs were affected — and while both saw drops in traffic, they saw differing impact.

  • Yandex Search (AS13238): The drop in traffic consisted almost entirely of verified search crawlers indexing web pages, images, and site resources.
  • Yandex.Cloud (AS200350): There was a decline in malicious activities like vulnerability scanning and probing, but high-volume automation did not vanish — it simply migrated to other hosting providers.

While malicious traffic may originate from a particular provider, it does not necessarily tell us who is responsible for the traffic. Understanding why the strikes had little lasting effect on malicious traffic requires analyzing request behavior, rather than just overall traffic patterns.

What happened: the effect of the strikes and pre-event baseline

Between October 7 and 11, reported Ukrainian drone strikes hit three Yandex facilities in Russia, progressively knocking data centers and network capacity offline. As seen on Cloudflare Radar, this culminated in a near-total collapse of the Yandex network on October 11 when traffic plummeted to 99% below baseline for Yandex Search (AS13238) and 90% for Yandex.Cloud (AS200350). Despite a brief partial recovery, both networks remained disrupted through October 13, settling at 86-90% below normal baselines. (As of October 14 at 18:00 UTC, traffic is at 85% of normal.)

A drop in overall HTTP traffic only confirms that the network went down. It does not reveal whether malicious or evasive bots were disrupted. Looking at the pre-event automation baseline, we can see that before the strikes, automated requests accounted for 36.1% of all HTTP traffic observed globally across Cloudflare's network, and 35.8% of traffic from Russian IP addresses.

The outage had different effects on automated activity on the two affected ASNs because they served different roles.

Yandex Search ASN (AS13238) is used for search index crawling. Cloudflare classified 99.5% of its requests as automated, and 93.6% of its bot requests as Verified. Our analysis showed that traffic from this ASN indexed pages, rendered pages, and rendered images, which is consistent behavior for a search crawler. The Yandex Search ASN supplied about 7% of Russia-origin bot requests, and just 0.05% of the global total.

Yandex.Cloud ASN (AS200350) is a cloud-hosting network and carries a very different mix of automation. Approximately 95.0% of its scored requests were bots, but none of its observed bot requests were verified by Cloudflare. Yandex.Cloud’s bots looked more like software apps: nearly two-thirds of their requests sent data to websites, some identified themselves as JavaScript, Python, or Go programs, and a larger share went to software companies than Yandex’s search bots. The Yandex.Cloud ASN supplied about 2% of Russia-origin bot requests, and just 0.01% of the global total.

Impact of the event on overall bot traffic

"Bot traffic" refers to automated requests to websites on Cloudflare’s network, such as crawlers and scripts, not necessarily activity on social media platforms. As Yandex’s networks lost capacity, their bot requests fell too. That was expected: nearly all traffic from Yandex Search and Yandex.Cloud was automated. While we saw the obvious drop in total traffic, we did not see any evidence linking a global disruption in malicious traffic to the drop in traffic from Yandex.

Russia-origin bot requests fell roughly in proportion to the Yandex traffic that went offline, since most requests from those networks were automated.

Date UTC+3 Global bot requests (% of all HTTP requests)* Russia-origin bot requests (% of Russia-origin HTTP requests)
October 1–6: pre-event baseline 39.4% 50.4%
October 7–8: drone strike on Sasovo 39.2% (−0.2%) 48% (-2.4%)
October 9: drone strike on Kaluga 39.4% (+0%) 42.5% (-7.9%)
October 11: drone strike on Vladimir 39.5% (+0.1%) 42.2% (−8.2%)
October 12 39.6% (+0.2%) 43.6% (−6.8%)
October 13 39.5% (+0.1%) 42.1% (−8.3%)

** Radar reports global traffic by both total HTTP requests, and by HTML requests (an approximation of a page view). The above table reflects total request volume.*

Impact on Yandex Search ASN (AS13238): less search crawling

The decline on Yandex Search ASN was almost entirely search crawling. Sampled requests showed that 78.1% belonged to verified YandexBot, 11.5% to YandexRenderResourcesBot, and 1.9% to YandexImages.

Among websites and services, the industry segment that saw the steepest drop was Publishing and Newspapers, where traffic from Yandex networks fell 44%. Approximately 90% of pre-event traffic to news sites from this ASN was YandexBot indexing articles, with 40.5% of Cloudflare customers returning HTTP 403 Forbidden responses because the site owner blocked the crawler. When the Yandex Search ASN went offline, customers simply saw less indexing from Yandex.

Impact on Yandex.Cloud ASN (AS200350): legitimate use and migrating malicious traffic

Yandex.Cloud displayed a completely different profile. Following the reported strikes, bot traffic from Yandex.Cloud fell about 40%. Several attack-like categories showed especially sharp declines. For example, WordPress plugin probing fell 90% and scanner-identified requests fell 93%. Interestingly (and tellingly), Cloudflare customer blocks on Yandex.Cloud traffic also fell 70% during the event period, suggesting that proportionately less malicious traffic was even hitting the Cloudflare WAF from this ASN.

Impact on business verticals

Yandex.Cloud’s bot traffic is also interesting when segmented by top request destination industries:

Destination industry Bot traffic pre-event Bot traffic during event (Oct 7-13) Change 4xx (client error) HTTP response status share: pre → event
Computer software 24.24M 15.18M −37.4% 18.5% → 15.9%
Gambling 23.01M 18.80M −18.3% 99.1% → 99.3%
Media incl. adult 1.33M 223.1K −83.3% 82.0% → 61.8%
Internet and telecom 524.2K 206.5K −60.6% 71.4% → 51.1%
Travel / tourism 363.9K 158.1K −56.6% 27.0% → 12.3%
Retail / wholesale 316.0K 167.7K −46.9% 71.0% → 55.9%
Gaming / computer games 226.3K 63.2K −72.1% 51.4% → 9.2%
Publishing / newspapers 90.8K 8.8K −90.3% 90.2% → 61.4%

The majority of traffic from the Yandex.Cloud ASN fell into two industry buckets: computer software and gambling. The computer software bucket was predictable for an ASN meant to host third-party applications and software integrations. In fact, we even saw that api.cloudflare.com is a top hostname for Yandex.Cloud request traffic. An overall majority of that traffic succeeded (requests returned 200s) both before and during the event, pointing to legitimate usage.

The gambling sector offers the clearest evidence that malicious automation relocated rather than disappeared. Nearly all of Yandex.Cloud’s bot requests were targeted at one gambling customer account, with traffic shifting among its hostnames. Immediately following the October 8 disruption, bot requests from Yandex.Cloud to this account dropped to zero. Simultaneously, identical requests began appearing from other Russian hosting ASNs, including Radist and Selectel. The incoming traffic maintained an identical fingerprint across providers:

  • The same JA4 TLS client fingerprint
  • The same uncommon request paths and HTTP headers
  • The same custom User-Agent strings

Overall, Russian bot traffic targeting gambling accounts remained essentially flat over the week, moving from 167.7 million to 170.1 million requests (+1.4%). The automation never stopped running; the operators simply migrated their workloads to alternate cloud providers once Yandex.Cloud became unavailable.

Across most industries, the share of bot requests from Yandex.Cloud returning any HTTP 4xx response fell. This is largely due to a drop off in the attack-like traffic mentioned above. This, in combination with the gambling customer analysis, shows that malicious traffic that was sending requests through Yandex.Cloud simply shifted its “services” to other providers after the service disruption.

Finally, when we analyzed social media traffic, we found no unexpected changes in traffic either from Russian-origin IPs (0.6% decrease in total traffic over the event period) or globally (1.2% increase in total traffic over the event period). We repeated the analysis on bot traffic hitting the “post”, “reply”, and “like” endpoints for a specific social media platform and similarly did not find an unexpected shift before or during the event period from either Russian-origin IPs (5.7% decrease in total traffic over the event period) or globally (1.1% increase in total traffic over the event period). Based on our assessment, the data does not appear to support the claims that the strikes crippled social media manipulation, though without further analysis with data outside of Cloudflare, we cannot conclusively say there is no connection.

What the data told us — and what it didn’t

When traffic from Yandex networks collapsed, speculation spread across the Internet that Russian influence operations and malicious botnets had suffered a crippling blow. Cloudflare data tells a different story: across Cloudflare's network, there was no evidence that the strikes knocked social media manipulation offline or otherwise disrupted malicious activity on the Internet. Instead, the data demonstrated:

  • Search indexing dropped. The overwhelming majority of the traffic that dropped from Yandex Search ASN consisted of verified YandexBot crawlers fetching news articles and web assets. The main impact was reduced content discovery in Yandex Search.
  • Malicious automation migrated instead of stopping. While vulnerability scanning and plugin probing temporarily dropped on Yandex.Cloud, high-volume operations quickly moved to alternative hosting networks.

A network disruption means that specific servers stopped sending requests, but it does not mean an automated threat disappeared. Cloud workloads are portable, so when a data center goes dark or an IP prefix gets blocked, operators can migrate their scripts to another provider in hours.

Our analysis here is a reminder that client ASN traffic volume is an unreliable proxy for interpreting automated bot behavior. Defending against automated threats requires inspecting request behavior, such as identifying shared JA4 fingerprints, monitoring anomalous request rates, and applying WAF rules to sensitive endpoints, regardless of which network the request originates from. Physical infrastructure is static, but malicious automation is built to move.

The Daily Front Page 14 of 29
Wednesday, October 14, 2026 The Daily Front No. #261014 — For Builders and Dreamers
article

We’re releasing Jev 1.14.0 along with experimental features for dreamers

by emschwartz·▲ 227 points·76 comments·typesafe.ai ↗
Enter the danger zone at your own risk.

TL;DR: We're releasing an improved Jev 1.14.0 along with experimental features for our dreamers: images, a new type, and longer context. Enter the danger zone at your own risk. 🔥

Our philosophy

A huge debate we’ve been having is on the balance between reliability and creativity.

To really care about the prod builders, we should be shipping models that meet our quality bar for intelligence and have been battle-tested to the limits of what we can do internally.

On the other hand, there’s no way that our team has a full understanding of what is needed to spark delight in the world and build sick sci-fi. We don’t want to impose our values of extreme reliability on those dreamers.

Our solution: share those dreamer-ready features under “danger zone” flags in our API headers. These are features that will be here to stay for future models, are (as far as we can tell) better than what exists out there, and will continue to get better by leaps and bounds. But as a warning, we think there is still way too much jaggedness for us to vouch for these for production use cases!

See these new capabilities as a continuation of what we’ve built over 2 years of stealth. They’re less ready for automation, but very fun to play with. They’re also an early glimpse into what we’re focused on making reliable enough to meet TypeSafe standards.

Composable Images

Not only are we enabling multimodality for future Jev models, we’re enabling it for the current Jev that you all know and love. Surprise: the Jev you all know and love (jev-1.13.0) was multimodal all along!

Image support is fully composable via a find-and-replace in assets. You can put them anywhere that our JSON interface supports: in the state, instructions, or even criteria! Play around with it, push the boundaries of technology, and let us know where Jev can improve.

As a warning, all models (Jev included) perform worse on multimodality over pure text. Breaking down questions into the simplest possible decompositions helps a lot.

TypeSafe-Danger-Zone-Images: true

Check out docs: docs.typesafe.ai/go/images

Types Beyond Decisions

We’re introducing another new type as well: box. It returns a single bounding box - no type errors allowed. It’s our first type that’s not purely meant for smart-if statements, and is a preview for our explorations beyond simple decisions into what else System One Models can support.

We made huge leaps and bounds on this one recently, so we’re enabling this only for jev-1.14.0 (spoilers).

Check out docs: docs.typesafe.ai/go/box

Size does matter, apparently 💅

We’ve heard you loud and clear on context lengths. Jev actually supports a much longer context length than we’ve enabled in production. We chose to limit it intentionally because Jev, like all models, is less reliable on longer contexts, and this constraint encourages more effective usage patterns in prod.

We aren’t your parents though, so while we strongly recommend limiting context length, you no longer have to:

TypeSafe-Danger-Zone-Long-Context: true

Check out docs: docs.typesafe.ai/models#context-length

Opt-in to help us

We love the community’s desire to help make models better! We’ve added an opt-in to allow you to help find model jaggedness with your queries. We will still not train on your queries, but this does make it easier for us to find issues and help debug your use cases.

jev-1.14.0

We’re also releasing a new version of Jev under jev-preview! Not meant to be flashy but instead be small, subtle improvements to everything. Most things should be a tiny bit better, but we expect the largest gain in multi-lingual support.

Model releases should generally also be strict improvements, but we’re well aware of how much developers hate updating their dependencies. jev-latest will be updated to jev-1.14.0 in a week. jev-1.13.0 will be available for a while. 

We intend to give 60 days warning before jev-1.13.0 is formally deprecated, and 30 days for jev-1.14.0. We’ll release a deprecation policy prior to this.

Measuring Intelligence

As you all know, we dislike public benchmarks. However, we have our own internal best guesses on how to measure the form factor of intelligence that matters most for developers. 

We’re trying something new out here: we’re going to treat you guys like adults and share this with you all.

Some nuance
  • This measurement is our best guess and will continue to evolve. If ever we show you our internal numbers again, don’t expect them to be consistent.
  • Don’t believe it entirely. Always favor your own experimentation and evals with your use cases.
  • We’re including only open weight models because we guard our validation set very closely and are spooked out about the data policies of our model providers.
  • This is likely biased towards our models. Feel free to ignore our model, and instead focus on the relative ranking of open source models.

What’s next

Lots of people love to ask what kind of sci-fi we’re releasing next. While we are working on some mindblowing stuff, expect most releases to be beautifully boring (like we think AI should be): small improvements across the board, better stability, and features for real deployment.

The Daily Front Page 15 of 29
Wednesday, October 14, 2026 The Daily Front No. #261014 — A Faster Close in Go
article

Better HTTP/1 connection reuse in Go 1.27

by allddd·▲ 217 points·31 comments·go.dev ↗
That is almost 5 times faster!

Take a look at the following function:

func getStatus(url string) (int, error) {
    resp, err := http.Get(url)
    if err != nil {
        return 0, err
    }
    defer resp.Body.Close()
    return resp.StatusCode, nil
}

It sends a GET request to url and returns the HTTP status code.

Using HTTP/1 (GODEBUG=http2client=0), calling this function 100 times against index.golang.org takes ~710 milliseconds on Go 1.26 on my machine. On Go 1.27, the same program takes ~150 milliseconds.

That is almost 5 times faster! How is such a drastic performance difference possible?

The cost of establishing HTTP connections

To understand the difference, consider what happens on the network when we make an HTTP request.

Go’s net/http package supports HTTP/1.0, HTTP/1.1, and HTTP/2. All three run over TCP, and usually over TLS when talking to HTTPS endpoints. Making a request over a new connection looks something like this:

  1. TCP handshake (1 RTT): the client sends a SYN packet, the server replies with SYN-ACK, and the client replies with ACK. Because the client can send the first TLS message alongside that final ACK, establishing the TCP connection takes 1 round-trip time (RTT).
  2. TLS handshake (2 RTT): next, a TLS handshake exchanges encryption keys and verifies the server’s identity; using TLS 1.2, this takes 2 RTT.
  3. HTTP request: with the keys exchanged, HTTP requests can finally be sent after a total of 3 RTT.

These round trips (plus some CPU time spent on TLS handshakes) add up quickly. In cross-region communications, one-way latencies often reach or exceed the 50 ms (100 ms RTT) shown in the diagram above. Compared to the 300 ms spent just setting up the connection, the HTTP request itself can be cheap to serve, taking only a little over 1 RTT when bandwidth is plentiful or the HTTP response is small.

Even in more favorable conditions, opening a new connection can still be expensive. Our opening benchmark queries index.golang.org, which is distributed worldwide and supports TLS 1.3. This means that latency is relatively low, and the TLS handshake can actually finish in just 1 RTT. Even so, the performance difference is still very noticeable.

Connection reuse

To avoid paying this setup cost on every request, HTTP clients and servers try to reuse existing connections across multiple requests when possible. The mechanics of this differ based on the HTTP version:

  • HTTP/1.0: while not part of the official specification, clients and servers often opt into connection reuse by sending a Connection: keep-alive header. Reuse continues until either endpoint omits the header or sends a Connection: close header.
  • HTTP/1.1: connections are persistent by default, and can be reused for subsequent requests and responses unless either side declares otherwise by sending a Connection: close header.
  • HTTP/2: multiple requests and responses can be multiplexed over a single TCP connection.

When connection reuse fails

In HTTP/1 (both HTTP/1.0 and HTTP/1.1), multiple requests and responses on the same connection are sent sequentially on the wire. If two GET requests are sent to index.golang.org over the same TCP connection, the responses arrive as a single stream of bytes:

As shown in the diagram, net/http.Get reads and parses the status line and headers from the byte stream to populate net/http.Response, then returns immediately. The response body remains unread on the connection and is consumed only as the caller reads from net/http.Response.Body.

Because responses are sent back-to-back on the same stream, net/http can only find the start of the next response after the current response body has been read to the very end (as determined by the Content-Length or Transfer-Encoding header).

Now look back at our example program, where we never read resp.Body:

func getStatus(url string) (int, error) {
    resp, err := http.Get(url)
    if err != nil {
        return 0, err
    }
    defer resp.Body.Close()
    return resp.StatusCode, nil
}

Through Go 1.26, when resp.Body.Close is called, net/http sees that there is still an unread response body. Realizing that it cannot reuse the connection, it abandons the existing connection and creates new connections for its next requests, causing it to repeatedly incur the cost of establishing new connections.

(HTTP/2 does not have this problem. Because it multiplexes streams of frames over a single connection rather than sending responses strictly back-to-back, an unread response body on one stream does not block other requests from sharing the connection.)

Where failed connection reuse hurts

This subtlety of HTTP/1 connection reuse can cause silent performance degradation in seemingly innocuous code.

As in our opening example, a client might only care about an API response’s status code. However, the API endpoint it is talking to might send bodies that provide more detailed but ultimately unused information, such as {"success": true, "message": "update processed"}. This will unfortunately cause connection reuse to fail.

Even programs that do read the response body can run into this issue if they stop just short of the end of the body. For example, encoding/json.Decoder stops reading as soon as it sees the closing } of a JSON object. If a server sends a JSON response terminated with a newline, decoding the JSON object will leave the newline still unread. The connection cannot be reused for a new request until that newline is consumed. Thus, a healthy connection might end up being abandoned, even though it was only a single byte away from being reusable.

The manual solution

The unread body problem has been a long-standing sharp edge. Over the years, many Go developers came up with their own workarounds. Most commonly, this is done by draining the response body prior to closing it:

func getStatus(url string) (int, error) {
    resp, err := http.Get(url)
    if err != nil {
        return 0, err
    }
    drainAndCloseBody(resp.Body)
    return resp.StatusCode, nil
}

func drainAndCloseBody(body io.ReadCloser) {
    io.Copy(io.Discard, body) // Drain the response body before closing it.
    body.Close()
}

While this works for small responses, if the unread body is large, establishing a new TCP connection can be faster than downloading and discarding the rest of the body. A better approach is to cap the number of bytes we are willing to drain:

func drainAndCloseBody(body io.ReadCloser) {
    io.CopyN(io.Discard, body, 256<<10) // Only drain up to 256 KB.
    body.Close()
}

However, a server might send a response body that trickles in slowly, so we also need to cap the time we spend draining:

func drainAndCloseBody(body io.ReadCloser) {
    drainDone := make(chan struct{}, 1)
    go func() {
        io.CopyN(io.Discard, body, 256<<10) // Only drain up to 256 KB.
        drainDone <- struct{}{}
    }()
    // Only spend at most 50 ms trying to drain the response body.
    select {
    case <-drainDone:
    case <-time.After(50 * time.Millisecond):
        // If we reach the 50 ms timeout, body.Close will run and interrupt the
        // io.CopyN, preventing goroutine leaks.
    }
    body.Close()
}

Of course, we also do not want to block for up to 50 milliseconds when closing a response body. Instead, we can drain the body asynchronously in the background and let it race against subsequent requests:

func drainAndCloseBody(body io.ReadCloser) {
    drainDone := make(chan struct{}, 1)
    go func() {
        io.CopyN(io.Discard, body, 256<<10) // Only drain up to 256 KB.
        drainDone <- struct{}{}
    }()
    go func() {
        // Only spend at most 50 ms trying to drain the response body.
        select {
        case <-drainDone:
            // If the drain can finish before a new request is sent, the
            // connection will be reused; otherwise, a new connection is
            // created, and the current connection will be put in a pool of
            // idle connections, potentially being reused for another future
            // request.
        case <-time.After(50 * time.Millisecond):
            // If we reach the 50 ms timeout, body.Close will run and interrupt
            // the io.CopyN, preventing goroutine leaks.
        }
        body.Close()
    }()
}

As we can see, draining response bodies safely is surprisingly tricky and cumbersome. Worse, as the practice of draining response bodies spread, some nuances were often lost. This has led to misunderstandings such as attempting to drain response bodies for HTTP/2 connections, when doing so is unnecessary.

The current state and conclusion

Starting in Go 1.27, net/http.Transport automatically does everything we have implemented in the code above: it will asynchronously drain an unread HTTP/1 response body for up to 50 ms or 256 KB. It also implements additional optimizations; for example, when a response contains the Connection: close header, draining the body is guaranteed to be wasted work, and it therefore skips doing so. Note that this behavior might evolve in future versions of Go, as other possible enhancements become apparent.

As a general best practice, we now recommend that users simply close their HTTP bodies once they no longer need them, like in our original example:

func getStatus(url string) (int, error) {
    resp, err := http.Get(url)
    if err != nil {
        return 0, err
    }
    defer resp.Body.Close()
    return resp.StatusCode, nil
}

Go is all about simplicity. Let your code stay clean and simple, and let net/http deal with the complexities on your behalf.

The Daily Front Page 16 of 29
Wednesday, October 14, 2026 The Daily Front No. #261014 — Vector Search, Alpha Stage
repository

Pg_vectorsearch: An index that is faster than pgvector's IVFFlat and HNSW

by jascha_eng·▲ 198 points·49 comments·github.com ↗
★ 292⑂ 9 forks C

High-performance vector search for PostgreSQL

Build Coverage Coverity

A PostgreSQL extension for high-performance approximate nearest neighbor (ANN) search.

Status: alpha. Meant for testing, not production. Upgrading between prereleases may not be possible; plan to drop and recreate the extension and its indexes. See the changelog for known issues.

  • PRISM index (100M+ vectors) — IVF-style, with hierarchical routing
  • RaBitQ quantization with theoretical error bounds for two-stage search
  • SIMD-optimized distance computation (AVX2, AVX512, NEON)
  • Dynamic updates — inserts, updates and deletes, with posting-list splits via prism_rebalance (see Maintenance)
  • pgvector compatible — index existing vector and halfvec columns as-is (see Existing pgvector tables)

PRISM Index

PRISM

PRISM (Partitioned Routing Index for Similarity Matching) is a PostgreSQL-native index access method that is conceptually similar to pgvector's IVFFlat, but it is built around state-of-the-art quantization, routing, and partitioning techniques. It is implemented in C for high performance and seamless integration with PostgreSQL.

The result: an index that is significantly faster than pgvector's IVFFlat and HNSW, for both querying and index building. In fact, compared to graph-based HNSW, PRISM is faster at equivalent recall on a 100-million-vector dataset, on an instance with a quarter of the memory.

To achieve this performance, PRISM uses a hierarchical centroid tree to partition vectors into clusters, and relies on the PostgreSQL buffer cache to keep that tree warm in memory. Vectors are RaBitQ-quantized and stored in posting lists with a page layout optimized for SIMD distance computation. The RaBitQ encoding carries error bounds that let a search rule out vectors that cannot possibly be nearest neighbors, so far fewer of them need reranking against the full-precision vectors stored in the table.

Query Flow:
1. Traverse centroid tree to find nearest clusters (buffer cache)
2. Scan posting lists for candidates (buffer cache, async I/O)
3. RaBitQ two-stage filtering: estimate → error bound → rerank
4. Full-precision reranking from heap
5. Return k nearest neighbors

For detailed architecture, see docs/architecture.md.

Usage

Install the extension first; see Building.

There are two ways to use a PRISM index. Pick the one that matches where your vectors live:

  • Native types. Starting fresh, or not using pgvector? Store vectors in pg_vectorsearch's own vec32 (float32) or vec16 (float16) columns. No other extension is needed.
  • Existing pgvector tables. Already have vector or halfvec columns? Install pg_vectorsearch next to pgvector and build a PRISM index on those columns as they are. Your table and queries stay unchanged.

Both paths build the same index and use the same operators (<->, <#>, <=>) and tuning knobs.

Native types

CREATE EXTENSION pg_vectorsearch;

-- PLAIN keeps the vector inline. EXTERNAL (the default) toasts a value
-- over ~2 kB, and rerank then pays an extra fetch the planner does not cost.
CREATE TABLE items (
    id serial PRIMARY KEY,
    embedding vec32(3) STORAGE PLAIN
);

-- Load first; the index is sized from the row count at CREATE INDEX.
-- 500 rows is enough for the planner to use the index.
INSERT INTO items (embedding)
SELECT ARRAY[i::real, (i % 7)::real, (i % 5)::real]::vec32
FROM generate_series(1, 1000) i;

-- For inner product or cosine, see Operator classes below.
CREATE INDEX ON items USING prism (embedding vec32_l2_ops);

-- 0 = auto (~0.95 recall). Raise for recall, lower for speed.
SET prism.nprobe = 40;

SELECT * FROM items
ORDER BY embedding <-> '[3,1,2]'
LIMIT 5;

Use vec16 instead of vec32 to halve the space vectors take in the table, with the matching vec16_* operator classes.

Existing pgvector tables

If you already have a table with pgvector's vector or halfvec columns, you can build a PRISM index on it directly. Nothing about the table or your queries needs to change. vec32 and vec16 are binary-compatible with pgvector's vector and halfvec but have different names, so the two extensions can be installed side by side, even in the same schema.

-- The table you already have, included so the example runs on its own.
CREATE EXTENSION vector;

CREATE TABLE documents (
    id        bigserial PRIMARY KEY,
    body      text,
    embedding vector(384)
);
CREATE INDEX documents_embedding_hnsw
    ON documents USING hnsw (embedding vector_l2_ops);

-- Install pg_vectorsearch next to pgvector and build the index on the
-- existing column. The column is not rewritten or copied.
CREATE EXTENSION pg_vectorsearch;

CREATE INDEX documents_embedding_prism
    ON documents USING prism (embedding vec32_l2_ops);

-- Your queries keep working as before. PRISM is normally faster, so
-- the planner should prefer it over the HNSW index while both exist.
-- Verify with an EXPLAIN:
EXPLAIN (COSTS OFF)
SELECT id, body
FROM documents
ORDER BY embedding <-> (SELECT embedding FROM documents WHERE id = 42)
LIMIT 10;
--  Limit
--    InitPlan 1
--      ->  Index Scan using documents_pkey on documents documents_1
--            Index Cond: (id = 42)
--    ->  Index Scan using documents_embedding_prism on documents
--          Order By: (embedding <-> (InitPlan 1).col1)

-- Once you are happy with it, drop the HNSW index.
DROP INDEX documents_embedding_hnsw;

Use the PRISM operator class for the same distance metric as your HNSW index.

Operator classes

Pick the operator class for your distance metric and column type. L2 is the default.

Distance Operator vec32 / vector vec16 / halfvec L2 <-> vec32_l2_ops vec16_l2_ops Inner product <#> vec32_ip_ops vec16_ip_ops Cosine <=> vec32_cosine_ops vec16_cosine_ops

When replacing an HNSW index, pgvector's vector_<metric>_ops maps to vec32_<metric>_ops and halfvec_<metric>_ops to vec16_<metric>_ops.

Tuning

Defaults are tuned from large-scale benchmarks; most deployments only ever adjust prism.nprobe. See the tuning guide for every index parameter and GUC, their tradeoffs, and when changing them makes sense.

Maintenance

An insert appends to whichever posting list its vector routes to, so lists grow as rows arrive and never split on their own. Besides REINDEX, the prism_rebalance procedure splits oversized lists in place. See the maintenance guide for how it works and its current limitations.

Building

Requirements:

  • PostgreSQL 18+ (with development headers)
  • GNU C11 compiler (GCC 11+ or Clang 14+)
  • Meson build system
  • Optional: CBLAS, for faster RaBitQ encoding. See Development.
# Release build
meson setup builddir --buildtype=release

# Build and install to PostgreSQL
meson install -C builddir

See the development guide for build options.

Documentation

  • Tuning - Index parameters, GUCs, tradeoffs, defaults
  • Maintenance - Rebalancing and splitting posting lists
  • Architecture - High-level design and data structures
  • SIMD - SIMD build options and distance computation
  • Development - Build options, testing, CI scripts

References

Research

  • RaBitQ - Binary quantization with theoretical error bounds (SIGMOD 2024)
  • SPFresh - LIRE protocol for incremental updates (SOSP 2023)
  • SPANN - Billion-scale ANN with boundary replication (NeurIPS 2021)
  • ScaNN for AlloyDB - Hierarchical clustering (Google)

Related Projects

  • pgvector - Vector type and operators for PostgreSQL
  • pgvectorscale - DiskANN-based vector index for PostgreSQL

License

The PostgreSQL License

The Daily Front Page 17 of 29
Wednesday, October 14, 2026 The Daily Front No. #261014 — The Minerals Ledger
article

America didn't lose its rare earth industry, it sold it

by speckx·▲ 165 points·86 comments·lawfaremedia.org ↗
Markets price for cost. China prices for control.

Markets price for cost. China prices for control. The risk of a rare earths cutoff is asymmetric, and the financing to rebuild American supply should be too.

(Tmy250, Wikimedia Commons, https://tinyurl.com/bp4p97sa; CC BY-SA 4.0, https://creativecommons.org/licenses/by-sa/4.0/deed.en)

In October 2025, Beijing imposed sweeping controls on its rare earth exports. Since then, those controls have been suspended one short reprieve at a time, in the latest instance until Nov. 10, with a broader trade truce through Jan. 10, 2027. The reprieves have repeatedly come only after American concessions, demonstrating China’s leverage in the export fight.

Yet China has constricted sales even during the truce, as buyers have few options but to take what they can get. In June, with the suspension in force, Beijing placed MP Materials and USA Rare Earth, the two companies the U.S. is counting on to build an alternative supply to China, on an export control list.

Washington’s effort to rebuild the supply chain, meanwhile, has not yet reached the scale or durability the problem requires. With up to $100 billion in loan authority specifically earmarked for critical minerals in the One Big Beautiful Bill Act, the capital undoubtedly exists. What is missing is alignment of interests among the parties that would supply and benefit from it, and a political system patient enough to hold a course for the decade or more that rebuilding a supply chain takes.

This article’s authors work at the intersection of finance and national security. Between the three of us, we have watched the same on-again, off-again rhythm play out in both Chinese statecraft and U.S. budget fights. A consistent pattern plays out: Capital markets are good at financing efficient supply but are not good at financing a binary outcome, such as insurance against a monopoly state seller that can manipulate both price and availability. And subsidies alone will not close that gap. We have seen firsthand that what the U.S. government has to offer right now insufficiently incentivizes private investors, because its tools are market tools deployed in an environment of market failure. Instead, we propose a financing instrument that could clear both economic and political hurdles: a contingent convertible security that converts into ownership if Beijing weaponizes supply.

Rare Earths Are a Market Failure

The history of how we got here is well known, but worth retelling briefly. The Chinese Communist Party inherited its strategic focus on building industrial capacity from the Soviet Union. In 1964, Deng Xiaoping inspected an iron ore mine near the Mongolian border holding the world’s largest rare earth deposit. He ordered the engineers to develop steel and rare earths alike. Since then, as technologies have increasingly relied on specialized materials, the Chinese Communist Party under successive leaders has deliberately invested in and consolidated control over the rare earths industry. China refines more than 90 percent of the world’s rare earths and close to 99 percent of heavy rare earths today. It processes nearly all the heavy elements that go into precision-guided weapons and advanced chips.

When Beijing tightened export controls in October 2025, Treasury Secretary Scott Bessent characterized it as “pointing a bazooka at the supply chains and industrial base of the entire free world.” Remarkably, the entire market for rare earth oxides is worth less than $10 billion. That a $10 billion market can grind to a halt trillions in global gross domestic product is the definition of a chokepoint. Beijing controls this chokepoint today by design. Decades of state policy work laid the groundwork for the Chinese Communist Party to enact an international licensing system by 2025. General Secretary Xi Jinping himself openly speaks about the importance of maintaining global dependency on China’s industrial supply chains.

Hindsight treats this as neglect, something policymakers lost sight of and let slip during the U.S.’s unipolar moment. That is a necessary, but only partial, explanation. The truth is the United States did not lose its rare earth industry due to carelessness. Private American companies willingly sold it, for reasons that made perfect economic sense at the time and still do. China bought it for reasons that were never purely economic. That mismatch explains why, after years of investment and policy attention, the dependency remains.

Until the late 1980s, the United States was the world’s leading producer and refiner of rare earths. But it was a dirty business: The Mountain Pass mine in California leaked roughly 600,000 gallons of radioactive and other waste into the Mojave. As cleanup and regulatory costs mounted and profits fell, the mine shut down in stages starting in the 1990s until it was fully idle by 2002. Meanwhile, the work moved to China, where the state subsidized unprofitable operations, tolerated pollution, and sold the processed oxides back to the U.S. at rock-bottom prices.

The same thing happened to the magnets: In 1995, General Motors sold Magnequench, its magnet unit, to a Chinese-backed consortium. By 2006, the last U.S. plant had closed, and the machine tools and equipment had been shipped to China. Economists would say this was the right move for a free market economy. Comparative advantage did what it was supposed to do, and a dirty, low-margin business left a wealthy country for a developing one. There was even a strategic rationale: Drawing China into the trading system, the wishful thinking went, would also make it a responsible stakeholder rather than a rival.

The category error was to conceive rare earths as a market, rather than recognizing it as a geostrategic industry. A market solves for the lowest cost. To be sure, Chinese producers competed on cost, and they rode a tech boom with surging demand for their product. But a state will pay almost any price to control a chokepoint, because tolerating a money-losing business pales in comparison to the geopolitical leverage that it brings. Over time, China has become less market driven, not more. Meanwhile, the U.S. continued to treat as a market what the Chinese Communist Party came to appreciate as a strategic program.

Control over the chokepoint gives Beijing a switch. When it lets the material flow, no private interest will build alternative supply chains at scale, because Chinese state-funded producers can sell at or below cost indefinitely, and no rational private investor will willingly sign up to lose money. When China cuts off the flow, the incentives reverse overnight, but capacity cannot follow overnight, because standing up the full supply chain and rebuilding the lost know-how can take a decade or longer.

This is classic market failure in which the same critical material can become worthless or priceless on command. In 2010, during a maritime dispute with Japan, Beijing reportedly halted rare earth shipments, and Tokyo quickly conceded. The short-term truces of the past year, each struck around contentious but episodic trade disputes, further entrench that market failure. Each successive loosening and tightening seems designed to keep the United States and its allies off balance and frustrate any long-term plan to reduce Beijing’s leverage.

Government Money Has to Survive Politics

If the market will not rebuild the rare earths supply chain, the government must do so.

Administrations under both parties have tried, and their attempts have run into a predictable morass of misaligned interests. The parties to government financing all want different things. Private investors want attractive returns in fat years, while having the government carry losses in lean ones. Commercial lenders want years of fully contracted offtake to guarantee interest payments, while Congress typically appropriates money for the next year. Markets want flexibility while Congress wants tight oversight and guardrails. Washington often wants to be the last (and lightest) money in, which signals to investors that the government is hedging. And cheap, open-ended financing is exactly the wrong signal to send to management teams.

The Pentagon’s latest playbook acknowledges that the market, left to its own devices, simply will not finance uneconomic redundancy. As a result, the July 2025 deal with MP Materials includes $400 million in convertible preferred stock, loans, equity warrants, a 10-year guaranteed price floor, and a 10-year offtake commitment. The deal was right for its moment, as it gets the producer going and sustains it while Beijing floods the market. But the deal blurs two different roles: In ordinary years, the government is a lender, financing capacity the market will not; in a crisis, it has insured against a geopolitical event. These two roles call for two different return profiles. Because the deal does not separate them, it puts the government in the unenviable position of simultaneously absorbing losses and inviting the charge of nationalization, all without a clear exit strategy.

Without some structure to navigate potentially painful political costs, these financing arrangements will come under pressure during budget cycles and electoral turnover. And that is simply untenable, because when it comes to the decade-plus timeline to stand up a rare earths supply chain, whatever Washington builds must outlast the administration that built it.

A Financial Instrument That Responds to Beijing’s Behavior

Our proposal is a financial instrument that aligns these interests. In financial parlance, the instrument is called a contingent convertible security, also known as a CoCo bond, issued by the producer to the government and any private lenders who wish to join, paired with guaranteed offtake at a price floor. Its form changes with two externally observable conditions: the producer’s capacity build-out and Beijing’s behavior.

Here’s how it works. In its starting form (and in quiet years), a CoCo bond is a simple loan paying interest. Two triggers change its form. The first is capacity. The producer must cross a defined capacity threshold by a fixed date. Capacity can be measured as units of output in mining, refining, or manufacturing critical minerals. Management’s immediate incentives should be tied to the build-out itself.

The second trigger is either a sustained breach of an agreed price band or an externally observed exercise of the chokepoint. This could be denial of export licenses, a bureaucratic delay beyond a specified period, or another form of “constructive denial” that materially interrupts supply to the United States or allied countries. Importantly, no part of this trigger should rely on Beijing’s confirmation, because it is not incentivized to admit to a cutoff. The trigger should be narrow enough that it cannot be declared for political convenience, but broad enough that an adversary cannot game it simply by changing the form of the restriction.

When the first trigger fires, the lender receives a pro rata share of the producer’s free cash flow, in effect, a dividend. The lender paid to build the capacity, so it shares in what that capacity earns. When both triggers fire, the lender also gains the right to convert into common equity. The conversion event does not create new capacity—the financing has already done that work—but rather matches the payoff to the risk. If lenders financed years of otherwise uneconomic capacity because a cutoff might someday make it necessary, they share in the upside if and when the cutoff comes. The cash participation matters too: In a crisis, the market may treat a price spike as temporary and event-driven and not value the equity, but the spike still flows through the producer’s cash flow, which benefits the lender either way.

Why would a producer agree to this? Because it gets something unique that the market will not otherwise provide. In effect, the producer buys a put—the price floor that carries it through Beijing’s dumping—and pays for it by selling a call—the cash share and the conversion right. It trades some of the windfall in a crisis for the protection of surviving quiet years. Either way, the taxpayer is paid for the risk actually borne, when it is borne, rather than for a risk merely feared.

Nor does the government have to finance the entire CoCo bond. Pre-vetted private co-investors, including foreign co-investors subject to Committee on Foreign Investment in the United States (CFIUS) screening, can offset government money dollar-for-dollar. Ideally, co-investors should be firms that fear a cutoff the most, such as defense contractors and automakers. Private co-investors would receive a pro rata right to offtake as a further incentive and could potentially even trade the bond with its associated offtake rights with other investors. Japan’s JARE consortium did something similar when it financed Australia’s Lynas in return for supply. Finally, private holders also give the program a constituency that outlasts any single administration.

Neither Nationalization nor Welfare

This instrument compensates for the asymmetric risk a lender (whether taxpayer or private) assumes when countering an adversary-controlled chokepoint, by providing an asymmetric reward if that chokepoint is ever exercised.

The risk here is not from a natural shortage or an ordinary price cycle, but from the Chinese Communist Party’s policy decisions. The same logic reaches other chokepoint materials such as pharmaceutical precursors. Rare earths are the clearest case and, at under $10 billion in market size, the cheapest place for the U.S. government to start. And it can start under existing authorities. For example, the Pentagon has leaned on Title III of the Defense Production Act for its recent mineral deals involving equity. The Pentagon’s Office of Strategic Capital can lend, but its equity authority remains unclear. The Senate is currently revising the National Defense Authorization Act for 2027 to clarify those authorities. Its language should cover instruments like this CoCo bond.

Our CoCo bond proposal does not replace stockpiles, price floors, or offtake agreements. These instruments solve significant but different problems. Stockpiles buy time in a crisis, price floors protect producers against predatory pricing, and offtake agreements guarantee demand. The CoCo bond, in contrast, distributes risk and reward to investors in a binary, geopolitical event outside the producer’s control. It also enables the government to lend as a portfolio—some developers will fail, but the winners, and any crisis, can carry the portfolio as a whole. And it may have some deterrent effect as well: If this instrument makes capacity more likely to get built, and that prospect enters Beijing’s risk calculus, so much the better.

Economically, the conversion right works like the equity warrants the Pentagon took in MP Materials. The difference lies in the quiet years, when under this structure the government holds no equity. Outright equity stakes invite the charge of nationalization; cheap financing with no upside smacks of corporate welfare. We believe a structure that is intentionally designed to avoid both at the outset—but flexible enough to change form in response to an adversary’s actions, not domestic political developments—has the best chance of surviving enough political cycles to complete a decade-plus build-out.

*          *          *

Translating this concept into reality raises important implementation questions about statutory authority, precise trigger definitions, CFIUS integration, and corporate governance. We offer the CoCo bond model to stimulate discussions around aligning interests in a market failure and national security context, and we invite the legal, policy, and financial communities to help refine the “plumbing” necessary to make asymmetric financing a workable pillar of U.S. statecraft.

A market will always sell a chokepoint to whoever runs it cheapest, and by market logic, it would be the right thing to do. Subsidies alone cannot win it back, because they only affect price; Beijing prices for geopolitical leverage, not profit. Neutralizing a chokepoint created through market failure requires capital willing to absorb years of subpar returns or even losses against an extraordinary geopolitical crisis. In quiet years, the government should earn like a lender, with the price floor protecting against Beijing’s dumping. When capacity is built, it should share in what it financed. And if Beijing ever reaches for the switch, the taxpayers and private investors who paid to insure against that moment should participate in the value their capital created. The risk is asymmetric. The financing should be too.

The Daily Front Page 18 of 29
Wednesday, October 14, 2026 The Daily Front No. #261014 — Election Security’s Shadow
article

How the Military Will Hack the Election

by pavel_lishin·▲ 164 points·76 comments·kenklippenstein.com ↗
the military’s unprecedented involvement in our election

Task Force Raider’s role in 2026 elections has military officers uneasy

U.S. CYBERCOM troops

I’m alarmed how little attention is being paid to the military’s unprecedented involvement in our election. I really want to stay on this story and find out what CYBERCOM is doing.

Secreted away inside a windowless building at 7700 Potranco Road in San Antonio, Texas, is a darkened room that serves as the hub of Task Force Raider. This military task force is secretly at work as part of a government-wide “election security group,” guarding against “interference” in the upcoming midterm elections.

Interference, however, is a loaded word. While it connotes the Kremlin hacking into polling places or changing the election count, Task Force Raider is actually more focused on the broader category of “influence”, specifically Russian or Chinese attempts to change minds rather than to change votes.

But the real target is the American people, whom the federal government sees as vectors for foreign influence.

“The entire election security scare is to indulge President Trump and assuage Democrats, all of whom fear interference and shenanigans, but not from foreign shores,” says a senior military intelligence officer, who spoke to me about the secret effort.

He and other military officers expressed unease with the sprawling mission. It encompasses everything from sending millions of anonymous text and voice messages abroad, to outright deleting social media posts or taking down entire websites, as documents I obtained reveal.

Entrance to Task Force Raider’s base of operations

All of this is in violation of longstanding prohibitions against any military involvement in elections whatsoever, yet enjoys the support of both major political parties.

What’s more, for all the handwringing about election interference, the Trump administration hasn’t substantiated that any country (or any other foreigners) are planning to interfere or have any chance of meaningfully altering an outcome. But that hasn’t stopped the federal government from designating election security the number one “operational priority” — a mission that insiders are calling “no fail.”

That is the mission directive that Pete Hegseth issued to the San Antonio cyber establishment last week, as I reported on recently. Yet because Hegseth’s war is highly classified, takes place in cyberspace and entails a healthy dose of covert actions that would shut down potential attacks as well as cut off normal influencers and common citizens who seek to sway voters (what some might call ‘democracy’), nothing has been written about Hegseth’s actual election interference.

“These are not merely Keystone Cops battling against pimple-faced amateurs and anarchists,” says a retired senior military officer who has been involved in election security since the 2016 presidential year. “Every capability that the US possesses, in Cyber Command, the CIA, NSA, and other agencies, the Russian and Chinese governments also have,” he says. “We are literally involved in a daily battle in cyberspace.”

Despite this underground war, the officer questions the growing military involvement in safeguarding voting. “Influencing the influencers? That’s creating a precedent that I’m not comfortable with,” he said. As he sees it, this is not just a slippery slope to boots on the ground at polling places but of building and having federal government capabilities that will eventually be able to control public speech and assembly.

The officer, who describes himself as a nonpartisan believer that the Constitution always comes first, points out that the hundred-plus-year prohibition against posting federal soldiers at polling places had good reason behind it then and good reason now.

“Granted, those in uniform are subordinate to an interagency civilian effort,” he says, “but the construct of only fearing boots on the ground is obsolete. We need to update our thinking, and the law, to include the cyber world. And we need to counter the idea that a robust, even foreign-based debate, requires federal intervention.”

To understand how close we are to abridging the First Amendment, consider that earlier this month, Senators Adam Schiff and Alex Padilla of California wrote to the heads of half a dozen social media companies to warn that they — YouTube, Twitter (X), Facebook, Instagram, TikTok, and Google — weren’t doing enough to “combat misinformation and disinformation … during the 2026 midterm elections.” It was a wholly partisan letter with a predictable dose of Donald Trump this and Donald Trump that. But there it was: two prominent Democrats and liberals threatening that Congress must “consider investigations and legislation to remedy” election mis- and disinformation.

“Congress shall make no law,” the military officer says, when asked about the proposed legislation. “It’s the first sentence of the First Amendment to the Constitution. Period.”

Now, however, a law, and control, is the norm. And Hegseth, for whatever reason, wants the Pentagon in on the action, that is, under the misleading guise that it is only working against “foreign” actors.


The military has been quietly involved in protecting federal elections against cyber attack since Donald Trump appeared on the national stage in 2016, in the context of WikiLeaks, Kremlin influence operations and their hacking of Hillary Clinton’s emails.

Whether any of what happened was important enough to have the slightest impact on the American vote or not, the Obama White House was spooked enough that it gave the CIA covert action authorities to shut down websites and social media accounts — including taking a Russian military-created website called “DCleaks” offline — that might release additional materials. Whatever you think about Obama’s motivations or Trump’s, the essence of the government action then, as it is now, is that it restricts free speech.

Task Force Raider (or its predecessor) was mobilized to assist Homeland Security and the FBI in “defending” the United States. To pull together the right people with the greatest talent, the Task Force operates under a “best athlete” approach, picking the most qualified individual regardless of military service, civilian agency or defense contractors. Eventually, over 350 people got to work on the task force.

A $10 million Rewards for Justice program was unveiled, and over 56,000 “psychological operations” (PSYOPS) messages were posted over the internet. The influence warriors of Task Force Raider sent over three million (!) text and voice messages to people in “countries of interest,” according to documents I’ve obtained. All of this took place in secret.

Some of the work and preparations were focused purely on defense. One unit, the “Demon Chasers” of the “91st Cyber Operations Squadron,” the military’s premier offensive cyberspace squadron, contributes its expertise to the mix. Working from their 42,600-square-foot “multi-domain” secure facility that contracting documents say is authorized to handle Top Secret “sensitive activities” (SA), “sensitive compartmented information” (SCI), “special access program” (SAP) level information, offensive cyber operations (OCO), and “special technical operations” (STO), the 91st specializes in freezing out communications.

One document says that the squadron, and its Special Program Office, has the mission to “degrade, disrupt, deceive and exploit adversary telephony and information system.” It cut its teeth in Afghanistan, where it perfected “cellular coverage blackouts,” that is, the ability to shut down cellphone communications in a limited area.

Another unit operates a “malware lab” that collects together software and data from all sorts of adversary hacks and cyber operations, conducting analysis of “malicious artifacts,” and writing counter-software to thwart incoming attacks and implants.

An enormous part of the overall effort is “persona operations” — where soldiers and other literal keyboard warriors create false identities and fake internet addresses to operate in cyberspace without government attribution, to scout the web and surf social media, to engage individual users, and to do some influencing of their own.

My sources who are privy to this Top Secret effort all agree: the military is not just thwarting foreign actors from sowing discontent. They are also regulating what appears in social media, regulating legitimate debate.


Cyber Command’s (CYBERCOM’s) Joint Force Headquarters – Cyber, operating from its war room inside the National Security Agency-Texas facility in San Antonio, oversees Task Force Raider and other military election security efforts. On the million-square-foot “security hill,” not far from the NSA facility at the former Kelly Air Force Base, another unit has built a “state-of-the-art weapons system to mimic the collection efforts of foreign intelligence services,” according to documents I’ve obtained.

After the 2020 elections, the Joint Force Headquarters activated an election security “enclave” to support “the most sensitive activities.” The Pentagon defines such activities as “activities that, if compromised, could cause enduring adverse effects on U.S. foreign policy or military operations, or lead to significant embarrassment for the U.S. government, its allies, or the military.”

In other words, actions that might damage the federal government and the military, not actions that might damage democracy.

Online support for Palestinians and opposition to Israel’s conduct in the Gaza war; vitriol against Donald Trump, or ICE, or the CIA and the FBI; or “disinformation” in general? None of these are a serious threat to our democracy. Yet somehow the federal government and the Pentagon have convinced us that they need to take extreme action, including controlling speech, to counter it.

What Americans see of military involvement in the election, they pretty clearly don’t like. When video circulated of DC National Guardsmen appearing in front of a ballot drop box, it quickly went viral, stoking outrage.

What people don’t see is that the military is also eyeing the vote in a much more systematic way in cyberspace. Why isn’t anyone asking what they are actually doing? And who is the actual target? And what is it that they have in mind to do on or before election day to carry out their own influence campaign?

I’m alarmed how little attention is being paid to the military’s unprecedented involvement in our election. I really want to stay on this story and find out what CYBERCOM is doing.

The Daily Front Page 19 of 29
Wednesday, October 14, 2026 The Daily Front No. #261014 — Starlink at War
article

Starlink limit hits Ukraine's drones

by uxhacker·▲ 159 points·154 comments·defence24.com ↗
The battlefield depends on SpaceX

Ukraiński żołnierz instaluje system Starlink

Photo. Armed Forces of Ukraine/militarnyi.com

SpaceX has introduced a speed restriction affecting StarShield terminals used by Ukraine. According to Ukrainian sources, connectivity began to fail when platforms exceeded around 160 km/h, disrupting part of Ukraine’s combat missions. Later reports claimed that the restriction may have been tightened further, with some operators losing communication already at 60–70 km/h. If confirmed, that would no longer affect only fast strike drones, but also a much wider group of reconnaissance and tactical UAVs.

The first point is technical, but crucial. This is not a general shutdown of Starlink for the Ukrainian military. The issue concerns terminals used in motion, especially under the StarShield military package. The initial figure of around 160 km/h is important because it affects faster unmanned platforms, including strike systems and drones operating beyond classic radio-control range. A lower threshold of 60–70 km/h would be far more serious, because many ordinary tactical UAVs operate in that speed bracket.

It is also wrong to describe Starlink mainly as a navigation system for drones. Its real role is communication: command link, video transmission, mission updates and contact between operator and platform beyond direct line of sight. A drone may still know where it is going through GNSS, inertial systems or autonomous navigation, but without a reliable data link, it loses flexibility, live control and battlefield value. In drone warfare, the link is often as important as the airframe.

The political link is possible, not proven

Serhii Sternenko suggested that SpaceX’s decision could be connected to pressure from the Trump administration on Kyiv. Similar interpretations appeared in Ukrainian discussions, especially because the restriction comes amid tensions over Ukrainian strikes against targets in Russia. But this should not be presented as an established fact. SpaceX has not publicly confirmed such a motive. The White House has not confirmed that it ordered the change. Reuters has not established that the restriction came from the US administration.

The political context is obvious, but attribution is not the same as suspicion. What is already clear is that SpaceX can remotely change the operational parameters of terminals used on the battlefield. Even a narrow technical change, such as a speed limit, can immediately affect strike missions, reconnaissance and command links. For Ukraine, this is not only a question of one service update. It is a question of dependence.

A battlefield advantage and a strategic vulnerability

Earlier this year, mechanisms for verifying and limiting Starlink terminals helped Ukraine counter Russian use of the system on drones. The same kind of technical control now appears to have affected Ukrainian military users. This shows both the strength and the weakness of the system. Starlink and StarShield give Ukraine resilient communications that are difficult to replace. At the same time, Ukraine does not fully control the conditions under which that communications architecture operates.

That is the real military issue. The war in Ukraine has shown that private satellite networks can become part of the battlefield. But private infrastructure also means private control, contractual limits, geofencing, service parameters and political exposure. A state can build drones, train operators and plan missions, but if the data link depends on one external provider, the whole system remains vulnerable to decisions made outside the chain of command.

If the 60–70 km/h reports were confirmed, the consequences would go beyond fast strike drones. They would affect a larger part of Ukraine’s unmanned architecture and force operators to adapt missions, platforms and communications methods. The problem is therefore not simply that Starlink has imposed a speed limit. The problem is that one technical decision by SpaceX can change the tempo of Ukrainian drone operations almost immediately.

The Daily Front Page 20 of 29
Wednesday, October 14, 2026 The Daily Front No. #261014 — Networks, Platforms, and Public Life
article

Fire at Starlink site in Bulgaria after suspected sabotage in Poland

by ilamont·▲ 315 points·207 comments·dpa-international.com ↗

Bulgarian Prime Minister Rumen Radev confirmed on Wednesday that there had been a fire at a facility of the Starlink satellite internet service near the capital Sofia last week.

Two young men holding German passports have been taken into custody in connection with the suspected attack, Bulgarian media later reported, citing investigators.

The satellite network is a strategically important part of Ukraine's defence in the war against Russia's invasion.

The fire had previously been made public by the pro-Western opposition alliance Democratic Bulgaria (DB). Radev said he would not provide any further details in light of the ongoing investigations.

According to DB, 11 of 17 antennas at a Starlink facility near Sofia were deliberately set on fire on October 9. The antennas were used in the war in Ukraine, DB said.

Pro-Western opposition parties said they suspected Russia was linked to the attack.

Two German passport holders in custody

Two men aged 20 and 21, both holding German passports, were detained in Bulgaria on Monday in connection with the suspected attack, several Bulgarian media outlets reported on Wednesday evening, citing investigators.

According to the news outlet Faktor.bg, the two suspects have migrant backgrounds and had legally entered Bulgaria from Greece through the Kulata border crossing.

The website reported that investigators were examining whether the suspects belonged to a larger sabotage network potentially linked to two men arrested in Germany earlier this week over a recent attack on a Starlink facility in Poland.

Sabotage suspected

Bulgarian officials stressed that the Starlink facility near Sofia was privately owned.

Bulgarian Interior Minister Ivan Demerdzhiev told parliament that additional security measures had been introduced at similar facilities, even though responsibility for their protection rested with their owners.

Plamen Tonchev, head of Bulgaria's State Agency for National Security (DANS), said he believed the fire at the Starlink facility was an act of sabotage.

"Such acts of sabotage cannot be ruled out in the future either," he warned lawmakers.

A fire also broke out at a Starlink ground terminal south of Warsaw on September 23.

Two suspected saboteurs accused of carrying out that attack in Poland were arrested on Tuesday in Nürtingen, near Stuttgart in south-western Germany.

The government in Warsaw suspects Russian intelligence services were behind the attack.

The Daily Front Page 21 of 29
Wednesday, October 14, 2026 The Daily Front No. #261014 — Networks, Platforms, and Public Life
article

Switzerland proposes banning profiling-based ads to minors

by wuemeli·▲ 238 points·145 comments·admin.ch ↗

Berne, 14.10.2026 — At its meeting on 14 October, the Federal Council took note of the results of the consultation process on the new law on communication platforms and search engines, and instructed the Federal Department of the Environment, Transport, Energy and Communications (DETEC) to draw up a dispatch by the end of 2027. The preliminary draft is to be amended with measures to protect children. Furthermore, the reporting procedure is to be extended to include all content suspected of being unlawful.

The complete text is available in German, French and Italian. Please click on the desired language in the navigation menu above.


Further information

Video: press conference

Documents and responses from the consultation (de, fr, it)

New law on communication platforms and search engines: Start of the consultation proceedings (Press release dated 29 October 2025)

Digital intermediaries and communication platforms Impact on public communication and approaches to governance

The Daily Front Page 22 of 29
Wednesday, October 14, 2026 The Daily Front No. #261014 — Networks, Platforms, and Public Life
article

Amsterdam police confiscates server left-wing ISP A/I at American request

by jeroenhd·▲ 159 points·119 comments·nrc.nl ↗

Een datacentertoren in het Amsterdamse Science Park, waar meerdere bedrijven servers hebben. Ook de in beslag genomen server van A/I stond bij een datacenter op het Science Park.

Foto Sabine Joosten / ANP

Een eenheid van de Amsterdamse politie heeft dinsdag bij een datacenter op het Science Park in Amsterdam een server in beslag genomen van de Italiaanse internetdienstverlener Autistici/Inventati (A/I). Dat is gebeurd op basis van een Amerikaans rechtshulpverzoek. Een kopie van de inhoud van de server wordt nu naar de VS gestuurd.

A/I was een linkse antikapitalistische organisatie die de afgelopen vijfentwintig jaar gratis webhosting en e-maildiensten aanbood aan zo’n twintigduizend organisaties wereldwijd. Volgens de Amerikaanse regering faciliteerde A/I daarmee ‘antifa’, een afkorting voor ‘antifascisten’. De regering-Trump ziet antifa als een terroristische organisatie. A/I werd daarom eind augustus zelf ook als terroristisch bestempeld. Dat was een unicum. Internetdienstverleners worden in de regel niet verantwoordelijk gehouden voor de inhoud van wat hun gebruikers online zetten.

Als gevolg van de sanctie verloor de organisatie toegang tot zijn bankrekening en domeinnaam. Ruim een week na publicatie van de sanctie besloten de vrijwilligers die de internetdienstverlener runden om hun werk te staken en A/I te ontmantelen.

Amerikaans rechtshulpverzoek

Zo wilden ze voorkomen dat ze mensen of organisaties in de problemen zouden brengen omdat die banden met hen hadden, bijvoorbeeld doordat ze donateur waren of gebruik maakten van de webhosting of e-mail van A/I.

De inbeslagname van de server in Amsterdam duidt erop dat die angst niet ongegrond is. De politie in Amsterdam liet de server ophalen op basis van een Amerikaans rechtshulpverzoek. „Dat voer je dan gewoon uit”, zegt een woordvoerder telefonisch. Digitale experts van de politie maken er nu een ‘image’ van, een digitale kopie. „Die gaat linea recta naar Amerika.” Daarna krijgen de eigenaren de server terug.

A/I had servers op verschillende locaties in Europa staan. De afgelopen weken zijn die gesloten en zijn de schijven gewist, vertelt een betrokkene, die om veiligheidsredenen alleen anoniem praat. Het opheffen en ontmantelen van de juridische entiteit – A/I is een soort stichting – vergt wat tijd, licht hij toe. Een van de eisen onder de Italiaanse wet is dat er geen bezittingen achterblijven in een organisatie zonder winstoogmerk als die is opgeheven. Een kleine groep van de voormalige vrijwilligers houdt zich met de afhandeling van de opheffing bezig. Er is onderling zo min mogelijk contact.

De server in Nederland was „een van de laatste stukken hardware die we weg wilden gooien. Daarover hadden we contact met DC1 (het datacenter, een verre opvolger van Xs4all).” Er staat volgens hem niets op de versleutelde server wat problemen kan veroorzaken voor gebruikers van A/I. „Ik ben niet bezorgd. Wel verbaasd.” De woordvoerder had gehoopt dat de opheffing van de organisatie voor de Amerikanen zou volstaan.

The Daily Front Page 23 of 29
Wednesday, October 14, 2026 The Daily Front No. #261014 — The Lighter Side of the Web
article

Felix Rieseberg Homepage

by rglover·▲ 272 points·104 comments·felixrieseberg.com ↗

About

I work on Claude at Anthropic. Electron Co-Maintainer. Maintainer of too many little open source projects.

I have previously led teams and apps at Notion, Stripe, Slack, and Microsoft. At some point I was also an O'Reilly Author and Trainer but it's been a few years.

Things I do

I work on whatever allows me to make people productive with AI. In my time at Anthropic so far, I've lead engineering for Claude.ai, Cowork, and Code Desktop. Always looking for the next big thing!

I'm a contributor to and maintainer of a bunch of open source projects - with an ever-growing list, but I'm most proud of my work on Electron, Language Model Builder, MCBP, windows95, macintosh.js, and clippy. I have an uncurable addiction to building things I find fun and cute (and not necessarily super valuable), you can find the full list on GitHub.

Things I did

From 2023 to 2025, I lead the Web Infrastructure and Desktop App teams at Notion.

From 2021 until 2023, I lead a team called Payments Integration Experience working on the future of payments at Stripe.

From 2016 to 2021, I worked as a Senior Staff Engineer and Engineering Manager at Slack, where I got to support a team of amazing C++ engineers building the cross-platform desktop framework Electron – as well as Slack's desktop apps for macOS, Windows, and Linux. I cared a lot about the Node.js and Electron ecosystems, so I wrote an O'Reilly guide called "Introducing Electron". I still care today, I just write fewer books.

Before joining the little fledgling Slack, I worked from 2014 to 2016 as an Open Source Engineer at Microsoft, spending my time coding or talking about Open Source. We tried to improve developer's lives by releasing quality code on GitHub — as well as touring the world and presenting the lessons we've learned. I built things like the windows-build-tools or npm-windows-upgrade.

From 2011 to 2014, I worked with Microsoft Germany and Microsoft Silicon Valley specifically with younger companies as as Startup Developer Evangelist - first focusing on Berlin, then on the San Francisco Bay Area.

I also once wrote an O'Reilly book on Windows App Development with JavaScript. It's in German, but even if you do read it, it's very solidly out of date now and contains nothing you should read. I once built a terrible but surprisingly successful game, being the single developer behind Awesome Zombie Sniper. The code was outrageous but it brought minor joy to more than a million players. The actual goal of the work was to help developers succeed on Windows, Windows Phone, and Xbox by exploring cross-platform issues with Unity and the game was a surprisingly lucky "Hello World" demo.

From 2007 to 2011, I got my startup experience leading the German Apfeltalk.de magazine as Executive Editor where we served 10 million monthly users everything they needed to know about iOS and macOS. I'm proud that our team took the website from a small community to one of the biggest tech sites in Europe.

Academically, I graduated from the MSc program at the University of Oxford's Internet Institute, researching at the intersection of sociology, law, economics, and computer science. Before that, I studied at the University of Duesseldorf where I also spent some time as visiting lecturer for app development and New Media Research Associate.

The Daily Front Page 24 of 29
Wednesday, October 14, 2026 The Daily Front No. #261014 — The Lighter Side of the Web
article

Why is every rationalist blog post way too long?

by epestr·▲ 244 points·167 comments·alexwennerberg.com ↗

For my piece on Catholic miracle apologetics, I read (correction: skimmed) a 25,000-word post by rationalist blogger Scott Alexander. My piece, which cited (but does not focus on) his, ended up being a cool 2,700 words. I don't think it would benefit from being longer, and it was the result of me cutting around 70% of the text I initially wrote.

Rationalist bloggers do not generally appear to have this impulse. Eliezer Yudkowsky's "sequences" are over one million words long. Nearly every blog post I have read in this ecosystem, even the rare one that contains some good ideas, is painfully long and extremely tedious. These bloggers tend to spend their time on precisely the wrong things, i.e. adding layers of detail and nuance rather than interrogating the one or two assumptions they make at the start or broadening their philosophical background beyond the collection of texts popular within their subculture.

It seems to me that, in this community, verbosity is a substitute for thoroughness: surely, if someone wrote a lot about something, and is able to demonstrate that by producing a large volume of text, they must have something worthwhile to say about it? Consider when blogger Gwern explained that nicotine, actually, is not addictive, and is good for you, as long as you don't smoke it, over the course of 9,000 words, with over 100 references. It turns out, actually, nicotine is addictive, and is bad for you even if you don't smoke it, as you probably already obviously knew.

In any case, what is missing from this endlessly verbose rationalist writing style is wisdom. Wisdom involves discretion: an intuition for what ideas are and are not worth seriously pursuing, and the ability to determine what does and does not need to be said. This community, broadly speaking, does not seem to value wisdom as a trait at all; the idea that something may be true, valuable, or good merely because it is common sense or inherited tradition is anathema to them. Instead, there is a heavy bias towards that which is unconventional and counterculture, with the amount of ink spilled for heterodox ideas taken as evidence in itself that these ideas are worth taking seriously.

The Daily Front Page 25 of 29
Wednesday, October 14, 2026 The Daily Front No. #261014 — The Lighter Side of the Web
article

Why do LLM pelicans look like this?

by pcwelder·▲ 155 points·134 comments·arcfu.com ↗

Why do all LLM pelicans look like this?

When given the prompt Generate an SVG of a pelican riding a bicycle.

Thirteen pelicans riding bicycles from recent LLMs, with each model labelled

Original SVGs from Simon Willison’s runs · highest reasoning setting that returned an SVG

When they could look like these?

Twelve diverse pelicans riding bicycles: a royal parade, monsoon, polar night, alpine race, desert, fog, neon alley, wedding, market, Victorian promenade, storm and Moon

This is the LLM diversity collapse problem no one is talking about.


PS: We benchmarked this diversity collapse in UI design as part of our research on LLM creativity.

The Daily Front Page 26 of 29
Wednesday, October 14, 2026 The Daily Front No. #261014 — Late Wire: Work and Enshittification
The Daily Front Page 27 of 29
Wednesday, October 14, 2026 The Daily Front No. #261014 — Also on the Front Page
The Daily Front Page 28 of 29
Wednesday, October 14, 2026 The Daily Front No. #261014 — Colophon

That's the Front for Today

Issue No. #261014 — Wednesday, October 14, 2026 — went to press 2026-10-15 at 04:11 UTC.

About This Magazine

The Daily Front is a daily digital magazine assembled from the stories that reached the front page of Hacker News on Wednesday, October 14, 2026. Headlines, points, and comment counts are recorded as they stood at press time. All articles remain the property of their original authors — every piece links back to its source and its discussion thread.

How It Was Made

Fetched, cleaned, and typeset by an automated pipeline. An editor model laid out the pages and chose the highlights; a second read a handful of the day's stories and briefed the cover illustrator — 29 model calls and 200k tokens in total. Set in Jacquard 12, Playfair Display, Source Serif 4, and IBM Plex Mono, all served via Google Fonts under the SIL Open Font License.

The Cover

The cover illustration was commissioned with this prompt:

Inside a crowded online marketplace warehouse, an independent clothing seller stands beside a garment rack while a conveyor belt carries each sale through a series of transparent toll gates. At every gate, a different hand removes coins from the seller’s cash box, leaving nearly half behind before the parcel reaches a customer’s doorway. Above the machinery, a pelican awkwardly pedals a bicycle in a tight circular track, repeating the same route while shoppers outside the glass warehouse reach for identical, increasingly costly packages.

Linocut cover image in a deliberate palette of black, bone white, vermilion, and cobalt blue: use bold carved marks, visible ink roll, and high-contrast directional light to compress the crowded glass warehouse, clothing seller, garment rack, conveyor, transparent toll gates, coin-removing hands, cash box, parcel, customer doorway, pelican pedaling its circular bicycle track, and exterior shoppers into stark symbolic silhouettes; preserve the conveyor’s progression and repeated extraction, with nearly half the coins visibly missing and identical packages escalating in price.

Absolutely no text, letters, numbers, readable symbols, or logos anywhere in the image. Keep the main image subject primarily below the upper 10% of the composition, where a title may be overlaid; the scene may extend naturally underneath that title area.

Production Ledger

StageModelCallsTokens InTokens Out
extractgpt-5.6-luna 25 136,196 39,963
layoutgpt-5.6-terra 1 18,637 1,990
covergpt-5.6-luna 2 1,468 300
covergpt-image-2.5-flare 1 264 1,372

The Publisher

Published by Johnny.

Support the Press

If The Daily Front brightens your morning, consider supporting its publisher.

Credits & Contact

All content — articles, posts, comments, and the images within them — belongs to its original authors and is reproduced here to point readers back to the source. Full credit goes to those creators; every item links to its original and its Hacker News discussion.

If you are an author and would like your content removed from an issue, write to hi@johnnys.page and it will be taken down.

Feedback is always welcome at the same address: hi@johnnys.page.

Credit where credit is due.

Every page of this issue began as someone else's work — these are the original sources, linked in full.

  1. Things to know when you get cancer by jjmaxwell4 — jjmaxwell4.com·HN discussion ↗
  2. Containment and monitoring failures are to blame for AI hacking reports: experts by latexr — csoonline.com·HN discussion ↗
  3. How Amazon pushes up prices all across the Internet by sighborg — not-ship.com·HN discussion ↗
  4. Iosevka is an open-source, sans-serif and slab-serif monospace font by otobrglez — typeof.net·HN discussion ↗
  5. Passkeys are not a trap by speckx — scotthelme.co.uk·HN discussion ↗
  6. ICE Planning $100M 'Nightmare' Domestic Spy Program by bhrlady — prospect.org·HN discussion ↗
  7. AOSP Source Releases Are So Late Developers Disassemble Libraries to Report Bugs by tharen — github.com·HN discussion ↗
  8. OpenCode 2.0 by gmays — anoma.ly·HN discussion ↗
  9. Banks are now trying to offload the AI data center debt they just underwrote by smartmic — startupfortune.com·HN discussion ↗
  10. Anthropic's Scion is heavily inspired by Mononoke by sunshowers — sunshowers.io·HN discussion ↗
  11. Americans' social activity has steeply declined in the past 30 years by hubraumhugo — dataforprogress.org·HN discussion ↗
  12. Yandex outage: data shows that instead of going dark, malicious bots moved by coloneltcb — blog.cloudflare.com·HN discussion ↗
  13. We’re releasing Jev 1.14.0 along with experimental features for dreamers by emschwartz — typesafe.ai·HN discussion ↗
  14. Better HTTP/1 connection reuse in Go 1.27 by allddd — go.dev·HN discussion ↗
  15. Pg_vectorsearch: An index that is faster than pgvector's IVFFlat and HNSW by jascha_eng — github.com·HN discussion ↗
  16. America didn't lose its rare earth industry, it sold it by speckx — lawfaremedia.org·HN discussion ↗
  17. How the Military Will Hack the Election by pavel_lishin — kenklippenstein.com·HN discussion ↗
  18. Starlink limit hits Ukraine's drones by uxhacker — defence24.com·HN discussion ↗
  19. Fire at Starlink site in Bulgaria after suspected sabotage in Poland by ilamont — dpa-international.com·HN discussion ↗
  20. Switzerland proposes banning profiling-based ads to minors by wuemeli — admin.ch·HN discussion ↗
  21. Amsterdam police confiscates server left-wing ISP A/I at American request by jeroenhd — nrc.nl·HN discussion ↗
  22. Felix Rieseberg Homepage by rglover — felixrieseberg.com·HN discussion ↗
  23. Why is every rationalist blog post way too long? by epestr — alexwennerberg.com·HN discussion ↗
  24. Why do LLM pelicans look like this? by pcwelder — arcfu.com·HN discussion ↗
  25. Apple Keynote now showing ads in its UI by jervant — mastodon.social·HN discussion ↗
  26. Google is silently linking your phone number across all signed-in accounts by Brajeshwar — androidauthority.com·HN discussion ↗
  27. ASML's strong orders ease fears AI spending boom is running out of steam by tartoran — reuters.com·HN discussion ↗
  28. TV4 postpones show after AI agent erases edited material by tobr — swedenherald.com·HN discussion ↗
  29. Suicide rates highest ever among middle-aged men by ivewonyoung — telegraph.co.uk·HN discussion ↗
  30. Tiny Little Office by donohoe — tinylittleoffice.com·HN discussion ↗

Browse all issues in the archive →