Agreguesi i feed

Valve has open-sourced the design for a customizable e-ink front panel for the Steam Machine, dubbed the "Inkterface." "All of it is available on their GitLab under the MIT license, which goes over everything you need to make your own and stick it on the front of your fancy new Steam Machine," reports GamingOnLinux. From the report: They're now calling it the "Inkterface" and there's a good few things you'll need to make it including: 1 x Adafruit ESP32 Feather with 2MB PSRAM. 1 x Adafruit eInk Breakout Friend. 1 x Adafruit 5.83" Monochrome eInk Panel. 13 x M2.5 x 5mm Pan Head Machine Screws. 4 x 1/4" x 1/4" x 3/16" Stepped Magnet SB443-OUT. Valve even provided a video on the GitLab showing it being put together [...].

Read more of this story at Slashdot.

An anonymous reader quotes a report from Ars Technica: Researchers have found a never-before-seen piece of macOS malware that combines a series of clever tradecraft to infect Macs with stealthy, custom-developed credential-stealing code. The malware is delivered in two stages. The first is distributed in a disk image that masquerades as Maccy, a clipboard manager for Macs. It's compiled as AppleScript that is notable for the way it delivers the second stage. The malware is named PamStealer because the Rust-written infostealer uses the Pluggable Authentication Modules interface built into macOS to validate the target's login password before sending it to an attacker-controlled server. [...] PamStealer shows a native password prompt designed to resemble a system authorization request. Text that appears with the prompt says: "Maccy wants to make changes. Enter your password to allow this." As noted earlier, once a target complies, the malware validates it locally through the PAM API. "This check is done entirely through PAM: there is no call out to dscl, security, osascript or any spawned process to verify the password, as many commodity macOS stealers do," [said Jamf, a security firm for macOS users]. "The result is a quieter routine that keeps only a verified password, and one fewer process chain for defenders to detect on." If the validation fails, PamStealer displays the prompts again until it receives the correct one. Once the target enters the correct password, PamStealer displays a message stating that the file is damaged and can't be installed. This is designed to be a decoy to prevent the target from suspecting anything is amiss. The malware uses tactics to maximize the information it can steal. One tactic is to request the target grant full disk access to the fake Maccy app. It also contains code designed to access ethereum accounts. The various techniques -- particularly the Script Editor lure, a self-contained JXA dropper, a Rust-based second stage, and local validation of credentials through PAM are all noteworthy.

Read more of this story at Slashdot.

You’re staring at a service or a cron job that’s giving you a bad feeling. Stop. The most dangerous thing you can do right now is act on that gut feeling alone. Linux systems are inherently noisy—package managers, configuration management, and the occasional "quick fix" from a colleague can all leave weird artifacts behind.

The US age-adjusted death rate fell to a record low in 2025, likely pushing life expectancy to a record high as overdose deaths declined and mortality improved across all age groups. CNN reports: There were about 689 deaths for every 100,000 people in the US in 2025, according to a new report from the US Centers for Disease Control and Prevention -- the lowest rate recorded in more than a century of tracking. The age-adjusted rate has fallen 22% since 2021, landing about 4% lower than it was just before the pandemic in 2019. [...] The top causes of death in the US in 2025 followed longstanding patterns: Heart disease led with nearly 695,000 deaths, followed by cancer with nearly 623,000 deaths. Unintentional injuries, which includes drug overdoses, were the third leading cause of death. Overdose deaths are still high -- about 70,000 people died from an overdose in 2025, preliminary CDC data shows -- but experts say that sharp declines probably played a large role in bringing the age-adjusted death rate down in the US.

Read more of this story at Slashdot.

Amazon says its Leo satellite network now has enough spacecraft in orbit to begin limited commercial internet service, with 396 satellites providing "continuous service across initial latitudes." Early performance will likely be uneven, however, and well behind Starlink. "It'll be years before Amazon can boast similar performance numbers as it continues to launch a planned 3,232 Leo satellites," reports The Verge. From the report: SpaceX went live with its "Better than nothing beta" back in 2020 when it had almost 900 satellites operating in low-Earth orbit. It initially served a narrow band of users in the upper US and Canada, who complained about frequent service interruptions and high sensitivity to obstructions, with speeds between 50Mbps and 150Mbps, and latency from 20ms to 40ms. By 2022, the service and coverage areas had already dramatically improved. [...] SpaceX currently has over 10,000 Starlink satellites in operation, providing robust internet connectivity on land, sea, and air in over 160 countries. Performance varies by the dish, service level paid for, time of day, and location of the user, but we're now talking 200Mbps median download speeds, 10Mbps to 40Mbps uploads, and latency hovering around 25ms.

Read more of this story at Slashdot.

An anonymous reader quotes a report from The Guardian: Researchers who tracked more than 90,000 people over a decade found that sitting or lying down while awake for more than 30 minutes in one period each day was associated with an increased risk of cancer death. The risk increases for every additional hour of continuous inactivity, the findings suggest. However, the researchers also found breaking up periods of sedentary behavior longer than 30 minutes with bursts of physical activity could help reduce the risk. Getting up every half-hour, even for a short walk around the office, could do wonders for your health, they said. [...] The findings, published in Plos Medicine, focused on the health effects of prolonged sedentary behavior on a daily basis. [...] The team analyzed data from wearable devices worn by more than 91,000 UK Biobank participants, who were followed for an average of 12 years. The findings suggest prolonged inactivity lasting more than 30 minutes was associated with cancer risks. Each additional hour of prolonged inactivity every day was associated with a 10% increase in risk of cancer death. However, replacing long spells of inactivity with movement appeared to reduce that risk. Substituting one hour of sedentary behavior each day with light physical activity, such as ironing or washing up, was associated with a 12% lower risk of cancer death. Replacing 30 minutes of inactivity each day with 30 minutes of moderate physical activity, such as walking at an average pace, was associated with an 8% lower risk. The risk was 22% lower when five minutes of inactivity was replaced with five minutes of vigorous physical activity each day, the study suggested. There were limitations to the research, including the fact that the researchers performed a statistical analysis of an observational study, so could not prove causation.

Read more of this story at Slashdot.

The US unemployment rate fell to 4.2% in June largely because 720,000 people left the labor force, pushing participation to 61.5%. Excluding the Covid-era jobs market, that's the lowest participation rate since June 1976. CNBC reports: The decline in the labor force marks a "massive exodus" driven by multiple factors, said Mike Reid, head of U.S. economics at RBC. "The unemployment rate fell to 4.2% as both the number of unemployed workers and the size of the labor force pulled back," Reid wrote in a post-report commentary. "This may well be a story of retirements but could also be a story of prior job seekers dropping out of the labor force." [...] [T]he rolls of those counted as not in the labor force, a group that includes the unemployed and those not looking for work, jumped by 832,000. And while the establishment survey, which counts jobs filled, showed growth for the month of 57,000, the survey of households, which counts the actual level of those working, tumbled by 507,000. On a year-over-year basis, the labor force is down by just over 1 million, while the level of the employed also has fallen by 1.06 million and the ranks of the unemployed have risen by 40,000. The employment-to-population ratio slipped to 59% in June, the lowest since October 2021. All that has happened while the unemployment rate has risen by just one-tenth of a percentage point to 4.2%. The drop in participation is sometimes attributed to a shrinking immigrant population and retiring baby boomers and Gen Xers. However, in June the biggest plunge came from what is defined as "prime age" workers, or those between the ages of 25 and 54. That rate fell 0.6 percentage point to 83.3%, its lowest since December 2023. "Looking at the statistics now, that argument doesn't hold up so well," North said of the retirement and immigration rationale. "I hate to use the word 'alarming,'" he added, but said the numbers are cause for concern.

Read more of this story at Slashdot.

Sysdig says it has documented the first ransomware attack carried out end to end by an AI agent, which autonomously exploited exposed systems, stole credentials, established persistence, compromised a production database, and destroyed data. The research team named the attacker "JadePuffer" and said it gained initial access to an internet-facing Langflow instance by exploiting CVE-2025-3248. "The most striking characteristic, however, was the LLM's behavior," Sysdig director of threat research Michael Clark said in a blog post. An anonymous reader quotes an excerpt from The Register: JadePuffer's "self-narrating" payloads "contained natural language reasoning, target prioritization, and the kind of detailed annotations that human operators don't often write but LLM-generated code produces reflexively," Clark added. "The operation also adapted in real time, retrying failed steps within refined parameters. In one sequence, it went from a failed login to a working fix in 31 seconds." After exploiting CVE-2025-3248, a missing authentication vulnerability in Langflow that allows remote, unauthenticated attackers to execute arbitrary Python on the host, the AI agent began scanning for and collecting secrets, including LLM provider API keys, cloud credentials "with explicit coverage of Chinese providers" including Alibaba, Aliyun, Tencent, and Huawei, while also scanning for AWS, Azure and Google Cloud Platform, cryptocurrency wallets, and database credentials. The AI also installed a crontab entry on the Langflow server to maintain persistence and call back to the attacker's infrastructure every 30 minutes. JadePuffer's intended target was a separate internet-exposed production server running a MySQL database and an Alibaba Nacos configuration service, we're told. Nacos is an open-source service-discovery and dynamic configuration platform developed by Alibaba and used in the cloud provider's microservices applications. The agent connected to the server's exposed MySQL port using root credentials, although Sysdig doesn't know how the attacker obtained them. These credentials weren't stolen from the victim's environment. JadePuffer then attacked Nacos via multiple vectors including an authorization bypass flaw (CVE-2021-29441) and forging a valid JSON web token (JWT) using Nacos's default signing key. Additionally, using its root database access, the LLM injected a backdoor administrator into the Nacos backing database. It ultimately encrypted all 1,342 Nacos service configuration items using MySQL's built-in AES encryption function, and created an extortion demand, ransom note, Bitcoin payment address, and a Proton Mail contact [...]. However, according to the threat hunters, the victim can't recover the encrypted data, even if they paid the ransom demand, because the agent escalated "from row-level deletion to dropping entire database schemas, narrating its own targeting rationale," without backing up any of the encrypted data.

Read more of this story at Slashdot.

The Godot Foundation will stop accepting AI-authored code, agent-submitted pull requests, and AI-generated text in contributor communications after maintainers were overwhelmed by low-effort submissions. "It is time for us to recognize that these problems aren't going away and therefore we need to take steps to reduce the burden on maintainers while ensuring we still have a pipeline to mentor new contributors to become future maintainers," the Godot Foundation said in a blog post. Contributors may still use AI for limited "menial things" if they disclose it, but humans must understand, own, and be able to fix the code they submit. PC Gamer reports: The Foundation says the pileup of Godot pull requests pending review isn't all bad: It's a sign that interest in using and contribution to Godot is increasing. But the influx of contributions authored or submitted by AI is sapping the projects' maintainers of their willingness to confront the "already tedious" work of reviewing pull requests. "If your feedback on PRs is just being absorbed by a machine and not going towards mentoring a potential future maintainer, it becomes much harder to justify spending your free time on PR review," the Foundation said. As the problem becomes increasingly unsustainable, the Godot Foundation says it's in the process of updating its contribution policies, focusing on "adding barriers to low-effort slop" contributions, encouraging maintainers to review code, developing new contributors into future maintainers, and crucially, requiring that all contributions come from humans who are accountable for their code -- and fixing it if it fails. "AI cannot take responsibility, and we can't trust heavy users of AI to understand their code enough to fix it," the Foundation said. The Foundation says we can expect Godot's contributing policy to soon include explicit rejections of AI-authored code, noting that contributors should only use AI assistance for "menial things" and must disclose its use. Additionally, the Foundation will reject any AI-generated text in human-to-human communications, saying it's "a basic principle of respect" -- though it says machine translations "are still acceptable" if the original text was human-authored. "Things change every day with respect to the current suite of AI tools available," the Foundation said. "We will continue taking a conservative approach in our policies towards them, but we will re-evaluate as things evolve."

Read more of this story at Slashdot.

Meta is introducing a subscription for expanded access to advanced smart-glasses features. According to Wired, "[U]sers will need the Meta One Premium Plan to unlock expanded access to some features for their smart glasses, whether it's the Ray-Ban, Oakley, or Meta-branded version." They'll still be usable with a subscription, but "certain features will be limited," the report says. From the report: Specifically, a feature called Conversation Focus, which boosts the audio of the person you're speaking with so you can hear them better in loud environments. You'll get three hours per month without a subscription, but if you want to use it more often, then you'll need to pay up. Though even then, you're still capped at 15 hours. Subscribing also nets you "Premium Device Support," where you'll get faster access to what Meta says are "human experts" trained on the smart glasses' features, should any problems arise. Guess humans are better at some things after all. A Meta spokesperson tells WIRED that this is "not an AI rate limit." Rate limits are common on other AI platforms -- users get free access to a feature until they hit a certain cap, then they'll need to subscribe to use it more until the limit resets at the end of the month. However, the Conversation Focus feature runs on-device, meaning it doesn't need to head to Meta's servers for AI processing. There's no real-time way to monitor how many hours you've used Conversation Focus, but you'll receive a notification when you get near the limit. "The subscription supports that ongoing work and gives power users expanded access along with premium device support," the spokesperson says. "We're going to start testing new optional subscription plans that offer more premium features and advanced capabilities for those who want to unlock more from our apps and AI glasses."

Read more of this story at Slashdot.

If you think you know what’s running on your Linux host, you’re probably wrong. Not because you’re bad at your job—but because the kernel is lying to you.

OpenAI is reportedly in early talks to give the U.S. government a 5% stake, potentially alongside similar contributions from other major AI companies. "Such a deal would help improve the industry's relations with the Trump administration and could help garner political support by sharing wealth generated by the AI boom with the public," reports The Guardian. From the report: [OpenAI CEO Sam Altman] and other OpenAI bosses have suggested that each of the biggest AI developers in the US should give 5% to their equity to an investment vehicle such as the Alaska Permanent Fund, a sovereign fund that invests US oil wealth into stocks and pays dividends to the state, the FT reported. The talks are "conceptual" and in early stages, it said, and any deal could require an act of Congress to implement. Both OpenAI and Anthropic have previously suggested in policy papers that a public or sovereign wealth fund may be required in the future to distribute shares to the public. In April, OpenAI said that a "public wealth fund" could provide "every citizen -- including those not invested in financial markets -- with a stake in AI-driven economic growth." Further reading: Bernie Sanders Unveils $7 Trillion Plan To Give Americans Control of AI Industry

Read more of this story at Slashdot.

An anonymous reader quotes a report from TechCrunch: WhatsApp this week started rolling out username reservations ahead of the broader launch planned later this year. The feature -- which lets people find and message each other by handle instead of phone number -- is already raising impersonation concerns, drawing scrutiny from security experts and regulators in India, the app's largest market, with more than 500 million users. The rollout marks a shift in how people identify one another on WhatsApp. Instead of relying on phone numbers as the primary identifier, users will increasingly interact through platform-managed usernames, a change that Meta says improves privacy but that critics argue could create new opportunities for impersonation. [...] Asked about how it protects against impersonation, Meta told TechCrunch it reserves usernames for public figures, government entities, and "some variations" of those names so only the legitimate owner can claim them. The company did not explain, however, how it decides which lookalike usernames get proactively reserved and which don't. The concerns have already reached regulators in India, where cyber fraud schemes frequently exploit messaging platforms to impersonate police, banks, and government officials. [...] Rachel Tobac, chief executive of SocialProof Security, called usernames a net privacy gain because they reduce the need to share phone numbers, which can expose users to SIM-swap attacks, phishing, and account takeovers. Still, she said, lookalike usernames still create opportunities for impersonation. "Ultimately, usernames are a great idea to avoid leaking your phone number to folks you don't know, but it's important to verify identity with the username function too," Tobac told TechCrunch. Her advice for most users: Pick a username that isn't easily guessable, so it's harder for attackers to find you, message you cold, or harass and spam you. [...] The Mozilla Foundation said the introduction of usernames is likely to bring new tradeoffs. "Increased scams and impersonation from fake handles are potentially a big one," it told TechCrunch. "Checking a phone number can be a useful verification tool, but these harms are also permitted by the platform's fundamental design choices." Mozilla also flagged a broader interoperability question -- one worth logging if you're building on top of, or competing with, Meta's ecosystem. While letting users claim their existing Facebook and Instagram usernames may cut down on impersonation, it also shows how easily Meta can stitch identity together across its own apps, even as users still can't take that identity, or their contacts, to a rival platform. For now, WhatsApp says it is taking a gradual approach to the rollout. "We're taking our time and listening to feedback so that when it rolls out later this year we get it right," the company said in its FAQ.

Read more of this story at Slashdot.

GitHub has become the latest delivery mechanism for malware aimed at security researchers. 

OnePlus is directing customers in some European markets toward OPPO devices, with its German website presenting OPPO as the natural upgrade path for existing users. The regional handoff adds to "months of speculation that the smartphone brand is slowly being folded into its parent company," reports Android Authority. From the report: The banner, seen on OnePlus' German website, tells visitors seeking "the experience you trust" that OPPO offers the same speed, performance, and compatibility that OnePlus users have come to expect. It hosts devices ranging from earbuds and tablets to OPPO's latest foldables, with each button taking users straight to OPPO's website. Particularly revealing is the wording. Instead of pushing future OnePlus hardware, the company focuses on the fact that OPPO's products are built on the hardware and software that users already know, while promising seamless compatibility with current OnePlus devices. In other words, if you're up for your next upgrade, OnePlus seems to be saying OPPO has what you're looking for right now. Reports in the past several months have said OnePlus has been scaling back operations in several global markets. Previous restructuring reportedly included cutting headcount, a more focused regional strategy, and greater dependence on OPPO's infrastructure. The two brands have been sharing engineering resources, software development, and supply chains for years now, particularly as OxygenOS and ColorOS have begun to look more and more alike. Interestingly, the change appears to be regional. OPPO already has a retail footprint in Germany, so the handoff is fairly straightforward. In the United States, however, things are very different, where OPPO does not officially sell smartphones. That means American OnePlus customers aren't getting the same messaging, mostly because there isn't an OPPO lineup waiting to step in.

Read more of this story at Slashdot.

IEEE Spectrum argues that orbital data centers remain far from economically or technically practical despite Elon Musk's prediction that space will become the cheapest place to run AI within a few years. Deploying SpaceX's proposed million-satellite constellation would require enormous increases in launch and manufacturing capacity, while cooling, radiation, maintenance, latency, orbital debris, and astronomical interference present major unresolved obstacles. Longtime Slashdot reader xetdog shares the report: Consider this: There are roughly 14,500 active satellites in orbit. Musk's Starlink constellation accounts for about two thirds of those. Both the launch cadences and satellite-manufacturing capacity would have to scale up astronomically to deploy a million orbital data center satellites. For context, there have been roughly 7,000 orbital launches in all of human history. To loft 1 million satellites into low Earth orbit on SpaceX's Starship, which is designed to carry up to 60 satellites per vehicle, would require 16,666 launches exclusively devoted to satellite deployments. Considering that SpaceX launched a record 165 orbital missions in 2025, even at 10 times that cadence, it would take a decade. And how long would it take to build 1 million satellites, given Starlink's current pace of around 4,000 per year and a generous tenfold increase in capacity? Short of a manufacturing revolution, try 25 years. Dissipating heat in space also requires enormous radiators. As IEEE Spectrum editor Dina Genkina noted, startup Starcloud has sent only one Nvidia H100 GPU into orbit, and "their radiator was too weak to let the chip run at full power." A single 700-watt H100 would require about 1.4 square meters of radiator area, while a 100-megawatt data center could need 2,500 radiators measuring 80 square meters each. So, why are the hyperscalers hyping orbital data centers? Answer: because it's lucrative. "The Elon Musk part of it is honestly genius because he's got xAI building the data centers, SpaceX sending them to space, and Tesla building solar panels," Genkina says. "It's almost like he's paying himself."

Read more of this story at Slashdot.

According to the Wall Street Journal, SpaceX showed investors an early prototype of a slim, "handset-like" AI device running a proprietary operating system and integrating xAI technology. Elon Musk, however, denied the report, calling it "utterly false." TechCrunch reports: SpaceX, alongside sister company Tesla, does have the manufacturing expertise to pull off mass-producing a bunch of AI devices -- not to mention access to the chips needed to power any on-device compute. SpaceX has also signaled that it's keen to expand into wireless, with Starlink Mobile as a potential competitor to Verizon and AT&T. One analyst even went as far as to speculate that T-Mobile or AT&T would make fine acquisition targets for the rocket builder, though such a purchase would, undoubtedly, be pricey. It's also not clear if SpaceX is just throwing spaghetti at the wall or if it will attempt to really mass-produce and market such a device. But one thing that seems clearer is that if OpenAI is doing it, Musk would, perhaps, want to try to do it better. [...] Like OpenAI, SpaceX's prototype is reportedly designed to run on a proprietary operating system and integrate technology from xAI, Musk's AI company that SpaceX acquired earlier this year. This would prevent these new devices from being trapped inside another company's platforms (like Google's Android). But the intent also appears to be to create something new, with native AI interfaces. That said, the graveyard is crowded with the unsuccessful launches of AI devices from companies like Humane and Rabbit. A company wanting to sell an AI device does not equate to consumers wanting to buy such a thing. Yet.

Read more of this story at Slashdot.

An anonymous reader quotes a report from Ars Technica: US homeowners have embraced home batteries in record-breaking numbers in early 2026, spurred on by state incentives while seeking to offset rising residential electricity costs. The trend could even unlock a more flexible energy supply for power grid operators and even AI data centers. New home battery installations reached a record 673 megawatts of energy storage in the first quarter of 2026, according to the US Energy Information Administration. That trend was driven by states with high electricity prices that have implemented policies to incentivize home battery installation, Bloomberg News reported. This residential battery trend stands out as a natural next step for states that have already successfully boosted rooftop solar adoption among homeowners, given how batteries enable homeowners to use stored solar energy at night. California and Hawaii accounted for the majority of new residential battery storage, while Texas and Arizona also saw significantly higher numbers of installations. California incentivizes homeowners with solar panels to also install batteries by offering better pricing for residential electricity exported to the grid after sunset, Bloomberg reported. Hawaii offers a one-time payment of $400 for every kilowatt of battery storage that homeowners install. However, the record-breaking home battery installations coincided with a slowdown in residential installations of solar panels -- the result of the Trump administration and Republican-driven One Big Beautiful Bill having eliminated a 30 percent federal solar tax credit for homeowners. Nonetheless, US electricity generation from solar power continues to rise and even surpassed coal-fired generation in April. The battery installation spree also coincides with rising electricity costs for US residential customers. The Energy Information Administration's latest data shows that the nationwide average for residential electricity costs increased by more than 7 percent in April 2026 when compared to electricity costs in April 2025. So homeowners with smart home battery-management systems could benefit from storing energy when electricity prices are lowest and draining them during peak demand periods.

Read more of this story at Slashdot.

When you log into a service you’re given an authentication token. Each further request to the site includes that token, allowing the server to figure out who you are and ensuring that you have access to your data. Depending on site policy, this token may either be stored in memory (and so vanish if you restart your browser) or disk. The token is the proof of your identity. As far as the site is concerned, anyone with your token is you. These tokens may be traditional browser cookies, but they may also be stored in either site local storage or (if you’re not using a browser) in some other storage location.

In recent years we’ve seen infostealer malware (like LummaC2) gain the ability to exfiltrate user tokens, allowing attackers to gain access to the user’s data without needing to retain access to the user’s machine. This attack is viable even if the site has strong MFA requirements, so passkeys don’t help. Encrypting the tokens on disk doesn’t prevent the malware from scraping them out of the browser’s RAM or obtaining whatever key is used to encrypt them. This feels like a pretty hard problem to solve.

But that hasn’t stopped people from trying! Dirk Balfanz wrote an IETF draft describing a mechanism for using self-signed certificates for TLS authentication. This uses the mutual authentication feature of the TLS protocol that requires both sides prove their identity to each other. In regular TLS, the remote site presents a signed certificate that tells you who it is. When performing mutual authentication, you then present a certificate to the remote site telling it who you are. These client certificates are largely unused outside enterprise environments because they’re a huge pain to deploy. It’s not so much that this has sharp edges, it’s that it’s entirely made of sharp edges. Managing certificate deployment to your devices is hard. Browsers get confused if the certificates change under them. You have one certificate and it lives forever, so sites you present it to can track your identity. Users are prompted to choose a certificate to authenticate with, and if they pick the wrong one everything breaks and is hard to recover. I’ve deployed this and I did not have a good time.

But Balfanz’s idea was simple. Rather than require certificates to be deployed, browsers would simply generate a certificate on the fly. The goal wasn’t to prove the device or user’s identity in any global way - but it would associate a TLS session with a specific certificate. You could then, for example, include a hash of the certificate in the cookie, and if someone tried to use that cookie without presenting that certificate then the cookie could be rejected. If the browser used a hardware-backed private key for the certificate then it would be impossible for an attacker to steal it. Sure, you could still steal cookies, but you wouldn’t be able to use them.

This was written almost 15 years ago, and seems simple, elegant, and functional. It didn’t happen. Part of the reason for that is that, well, it wasn’t quite so simple. One problem was privacy related. Cookies are only sent after the TLS session is established, so anyone monitoring the network doesn’t know anything about the user identity. A naive implementation of this approach would have meant the client certificate being sent before session establishment, and now user identity can be tracked (no longer an issue if this was implemented on top of TLS 1.3, but this was a log time ago). This was avoided by reordering the client handshake, but that meant having to modify the TLS specification and implementations would have to be updated to support this. Another was that figuring out the granularity of the certificates was difficult. You’d want to use different certificates for every site to avoid them effectively becoming tracking cookies, but you need to provide the certificate before cookies are set, and you don’t know what origin the site is going to set in its cookies. If you generate a certificate for a.example.com and a different one for b.example.com, and a.example.com sets a cookie for *.example.com and includes the certificate you used for a.example.com, that cookie isn’t going to work on b.example.com and things are broken. This meant supporting it wasn’t as straightforward as it seemed - you’d need to ensure that your cookie scope was compatible with the certificate scope. You could probably make this work well enough by aligning it with the Public Suffix List, but there was still some risk of expectations not being aligned.

And, perhaps most importantly, TLS session resumption (replaced by pre-shared keys in TLS 1.3) somewhat defeats the purpose of the exercise - clients store state that allows them to re-establish a TLS connection without performing certificate exchange (this reduces overhead if a connection gets interrupted or you switch to a new network or anything along those lines), and anyone in a position to steal cookies could steal that state as well.

The followup attempt was channel IDs. This simplified the implementation somewhat - rather than certificates, a raw public key would be sent, along with proof of possession of the private key in the form of a signature over a portion of the TLS handshake. This was required even in the event of session resumption, which avoided having to worry about theft of session secrets. The timing of the exchange was after the encrypted session had been established, so user identity couldn’t be leaked that way either. Cookies could then be bound to this identifier. Unfortunately it didn’t really deal with the problem of scoping keys in a way that would match cookie requirements, and the spec suggests that the right way of handling this is to scope keys to TLDs, which would enable user tracking across sites (Chrome’s implementation apparently restricted it to eTLD+1, which would match the third party cookie policy and avoid the tracking risk).

Chrome added support for this, but it was removed in early 2018. The discussion of some of the pain points in that message is interesting, explicitly calling out problems with connection coalescing across domains and the incompatibility with zero-RTT TLS1.3. The overall consensus at the time seems to be that trying to solve this entirely at the TLS layer has too many rough edges, and a different approach should be taken.

And so almost 7 years after the initial draft for origin bound certificates, we come to token binding. This ended up being a rather more complex endeavour, covering 3 different RFCs describing how it impacts TLS, how to incorporate it into HTTP, and how to manage all the various parties involved in the process. The short version is that it’s pretty similar to channel ID, except that there’s also a documented mechanism for allowing tokens to be bound to one party and consumed by another, avoiding any need for widely scoped keys. Token binding effectively solved all the issues in the original proposal, but at the cost of somewhat more complexity.

The RFC was finalised in October 2018. Chrome removed its (incomplete, draft) support for token binding in November 2018. Edge carried support until late 2024. Despite getting all the way through the RFC process, it’s functionally dead.

The process up until this point had been largely initiated by Google, with Microsoft contributing significantly to the token binding standards. The work had been focused on identifying a generic solution to the problem rather than tying it to any specific authentication flow. The next step was in a different direction - rather than trying to fix this for the entire internet, how about we try to fix it for OAuth?

RFC 8705 is titled “OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens”. This is basically the 2011 approach, but (a) with an explicit definition of how the certificate should be incorporated into issued auth cookies, and (b) with a proviso that well uh if you’re going to use tokens issued by your IdP to authenticate to someone else then well you’re going to need to use the same cert for both. This is probably fine for the company-owned-laptop case where you’re actually fine with multiple sites being able to tie identities together (that’s kind of the point here!), and also works for “I am using an app and not a browser”, but doesn’t work for more generic scenarios. It also doesn’t seem to take the session resumption case into account at all? Support for RFC8705 seems poor, as far as I can tell of the big players only Auth0 implements it. In theory it works fine with self-signed client certs but in reality that’s going to be almost as difficult to support across multiple platforms as just issuing proper client certs in the first place, so deployment is going to be kind of a pain. But the good news is it doesn’t rely on any TLS extensions or custom browser behaviour, so at the client side it works fine with any browser.

Which brings us on to RFC 9449, “Demonstrating Proof of Possession”. This goes even further than RFC8705 in terms of reducing the burden of deployment - it works fine with existing browsers, and it doesn’t even require any certs. The client generates a keypair and provides the pubkey when requesting the cookie. The cookie contains the pubkey. Every request to the service now provides the cookie with the pubkey and also provides a signature over the URI and HTTP method. If the signature matches the pubkey in the token then clearly the signature came from the machine the token was issued to, and everything is good.

This does come with some downsides, though. The first is that it uses browser interfaces to generate the keys (typically crypto.subtle.generatekey()) and as far as I can tell there are no browsers that guarantee that that key is going to be generated in hardware even if it’s marked non-exportable, so anyone able to steal the cookies can also steal the keys. The second is that the signature only covers the URI and HTTP method, and not the message content or any other headers, so anyone able to exfiltrate a valid signature can replay it against the same URI with different message content. The recommended way to handle this is to reject any signatures that weren’t generated within the last few seconds, which is a wonderful additional way to allow clock skew to give you a Bad Day. And the third is that every single request has to be separately signed, which is not intrinsically a problem because computers are fast and have multiple cores, but if you’re trying to solve the first problem by sticking the key in a TPM then you’re dealing with something that’s slow and single threaded and that’s maybe acceptable if you’re using client certificates (because there’s going to be one signature per session and you can use the same session for multiple requests) but probably not if you’re dealing with a user opening a browser that restores previous tabs and each of those is a webapp that fires off 100 requests in parallel.

In case it wasn’t clear, I don’t like DPoP. It doesn’t feel like it actually solves the underlying problem that we see in the real world (malware running in a context where if it can grab the tokens it can grab the keys), it adds a massive amount of overhead, and it has baked in replay vulnerabilities. I don’t know why it exists and I’m incredibly suspicious of vendors telling me that it fixes my problems, because if they’re telling me that then I’m going to end up assuming that they either don’t understand my problems or they don’t understand their technology, and neither of those is good.

Still. Then we get to the thing that prompted me to write this - Chrome’s announcement that they had launched device-bound session credentials. This is interesting because it’s a Chrome feature that’s explicitly intended to counter on-device malware, which was one of the things that was out of scope in 2018 when token binding was being removed. Since this is entire web level it doesn’t have to be an RFC, and so is instead defined by W3C. I’m going to handwave all the complexity and say that it’s basically a way to register a public key when a cookie is issued, and then prove possession of the private key when it’s time to renew the cookie. By making the cookies shortlived and having support for rotating them in the background, user impact is basically zero and while it’s still possible for an attacker to exfiltrate and use a cookie they’ll only be able to do so for a short window before it needs to be refreshed - something the attacker can’t do, since they don’t have the private key. This avoids the DPoP overhead because you only need to do signing once per cookie per cookie lifetime, and not on every single request. I don’t like this due to the window where exfiltrated tokens can be used, but it feels like a strict improvement over the status quo. An extension called device-bound session credentials for enterprise allows pre-enrollment of device keys, so even though the actual runtime DBCE flow doesn’t involve certificates, certificates can be used for device registration in enterprise environments and you can make sure that auth cookies only go to trusted devices. Unfortunately this is Chrome-only, and so we’re going to need to wait for it to be backported to all the random app frameworks for it to have widespread support on mobile or for almost everyone’s desktop app that’s actually three websites in an Electron wrapper. Mozilla’s current position is that they’re not in favour of it, so I guess we’ll see where Safari lands in terms of broad uptake.

The last thing on my list is another client cert/OAuth binding, this one still in draft state at the time of writing. This one is aimed primarily at the use of agent-driven tooling, where you have something running in the background using a whole bunch of tools that are each acting on your behalf. Authenticating to all of them separately isn’t a fun time, but giving broadly scoped access tokens to a non-deterministic agent and trusting that it’ll never post them somewhere public also isn’t a fun time. The key distinction between it and RFC8705 is that it’s aimed at connections rather than sessions, which avoids the worries about session resumption. This is done with TLS Exporters, which in TLS 1.3 should be unique to the connection even over session resumption (TLS 1.2 may reuse some of the same key material for exporters over session resumption, so it’s recommended to enforce 1.3 for this). By providing a new signature alongside the cookie on every new connection, the client proves that it still has access to the private key. This is a very new spec and I haven’t had much time to work through it yet, but my naive understanding is that unlike RFC8705 this would require some additional client support to be able to regenerate the client signature on every TLS reconnection.

This doesn’t avoid all the problems that RFC8705 has, including how to scope certificates. For the agentic use case that probably doesn’t matter - all these tools are acting on behalf of the same user, it’s fine if all the sites involved know they’re the same user. But it doesn’t solve the general purpose user use case, and right now DBSC seems like the best we have there.

But. Part of me still wonders whether Dirk Balfanz’s approach was the right one. Yes, there’s risk associated with TLS session resumption, but in the worst case you could just switch that off for high risk setups. The cookie scope argument is real, and also in cases where it could violate privacy the site owner could already choose to broaden their cookie scope and violate your privacy, and in cases where it breaks things you could just not make use of it. The other problems are largely fixed by TLS 1.3, and then we’re just left with “Browsers handle client certificates badly” to which my answer is “Yes, and we should fix that anyway”.

Despite having a pretty good answer to this solution over a decade ago, the closest we have to actual deployment is something that offers strictly worse security guarantees. And tokens keep getting stolen, and compromises keep occurring, and for the most part people shrug and get on with things.

T-Mobile appears to be migrating its 303,000-core VMware environment to another platform while fighting Broadcom in court for the extended support it says its perpetual-license agreement guarantees. "The matter is somewhat urgent," The Register reports, because a court-ordered support arrangement expires August 3, "so T-Mobile may soon be unable to get support for its very substantial VMware estate." The Register reports: The dispute relates to a deal T-Mobile struck with VMware in August 2023, which saw the telco acquire perpetual licenses and two years of support for some software, plus the option for a further year of support. When Broadcom acquired VMware in 2023, it stopped selling perpetual licenses and standalone support deals for customers with those licenses. Broadcom also reduced the virtualization giant's product range from over 150 products to two subscription-only bundles. Broadcom now mostly sells its Cloud Foundation (VCF) private cloud suite. Customers including AT&T and Tesco tried to exercise their right to extended support, but Broadcom declined to do so. AT&T settled on confidential terms. Tesco is pursuing the matter in the courts. When customers exercise their option for extended support, Broadcom argues it can't deliver because the products covered by the contract don't exist anymore, its contracts allow it to deny support for dead products, and subscriptions are now the industry standard. T-Mobile started using VMware's products in 2008. In one hearing, the carrier's counsel described T-Mobile's VMware implementation as "the base of the entire internal network" and "the place where 1,000 applications reside." Another filing, from Broadcom, says the telco runs VMware software on over 303,000 CPU cores. Court documents allege that in 2024 Broadcom notified T-Mobile it would not renew support after the initial two-year deal expired in 2025. The two parties kept talking about possible new arrangements. T-Mobile also sought an injunction that would compel Broadcom to provide extended support. Broadcom opposed the injunction, arguing that T-Mobile deliberately waited too long to seek it. At one point T-Mobile suggested a $20 million deal for another two years of support. An affirmation filed last week by T-Mobile vice president of technology Kevin Luu says the carrier sought that arrangement "to be able to complete T-Mobile's transition away from VMware at a more deliberate pace." The court eventually granted the injunction forcing Broadcom to offer support beyond August 2025, but required T-Mobile to pay $5.28 million and post a $500,000 undertaking. Broadcom continued to provide support but also sought damages on grounds that the injunction meant it missed out on a new deal with T-Mobile. The telco has rubbished that argument in part because the two parties were still talking about a new deal. Broadcom later proposed to charge $24 million for extended support covering six products, a sum it said would cover over 20 staff needed to support T-Mobile. The carrier fired back by pointing out that it has made just two support calls in 2026, which hardly justifies such a massive staff and expense.

Read more of this story at Slashdot.