Agreguesi i feed

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.

Meta is reportedly developing its own cloud business that could sell access to its AI models and lease data-center computing capacity to other companies. The move would put Meta in direct competition with Amazon, Google, and SpaceX. Engadget reports: The cloud business could offer multiple services, according to [Bloomberg], like selling access to AI models run on Meta's infrastructure, or leasing the computing power of its data centers to other companies looking to train AI. Offering something akin to Amazon Web Services could help make back some of what Meta has already spent on its new bet. As part of its AI plans, the company has committed to investing $600 billion in the US by 2028. Meta has also already made more than a few expensive hires to build its AI superintelligence team. Meta Compute, the data center and AI-focused initiative Meta created in January, is currently developing the new cloud business, according to Bloomberg.

Read more of this story at Slashdot.

BrianFagioli writes: Cloudflare announced new controls that give publishers more say over how AI companies access and use their content. Beginning September 15, new Cloudflare sites will allow traditional search indexing while blocking AI training and AI agent access on ad supported pages by default. The company is also expanding its monetization efforts with a Pay-Per-Use model that aims to compensate publishers when their content contributes to AI generated answers rather than simply being crawled. Cloudflare argues that publishers should not have to choose between being discoverable online and giving away their work for free to AI systems.

Read more of this story at Slashdot.

AleRunner writes: The first fully synthetic cell ("SpudCell") has been created in the Department of Genetics at the University of Minnesota. Strictly speaking, it's described as a "cell-like system constructed entirely from known chemical components that can perform a complete cell cycle." It is able to replicate, but only for approximately five generations. The key advance is that the cell is "built entirely bottom-up from individually purified, non-living components," although it still contains material from E. coli bacteria. "PURE is a defined mixture of 36 purified enzymes from E. coli bacteria," including ribosomes, that provides the infrastructure for genetic replication. CNN has an article on the advance, including interview material with Professor Kate Adamala, who led the research. "I know the full ingredient list of the cell. I know exactly what chemicals, what molecules, at what concentrations," she said. "It is fully defined, which means we can engineer it." "Humans did not create life," notes an anonymous Slashdot reader. "Researchers call it a constructed cell, not 'life created in the lab' but a 'genuine milestone on the road toward that question.' It lacks full autonomy (needs feeding, no independent evolution)." Special thanks to Slashdot readers kemosabi and AleRunner for submitting the story and additional sources, including reports from The New York Times and The Guardian, as well as information from the University of Minnesota Twin Cities.

Read more of this story at Slashdot.

An anonymous reader quotes a report from Ars Technica: Reddit will start requiring people to be logged into Reddit to use old.reddit.com. The new requirement will take effect "over the next month," a Reddit employee going by the username boat-botany announced on the social media platform today. The person claimed that the change is part of an ongoing effort to "tighten how automated systems access Reddit." The Reddit employee wrote: "Old Reddit's logged-out experience is a significant source of abusive scraping and automated traffic on the platform. It's also an important interface for many long-time mods and Redditors. To strike the right balance between preserving your access to Old Reddit while preventing abusive scraping and automated traffic, over the next month we will start requiring everyone to log in." In a follow-up comment, boat-botany defined abusive behavior as that which violates Reddit's rule prohibiting activity that interferes with the platform's "normal use" or that "create[s] programs or applications" that break Reddit's (controversial) API rules. "By logging in, we get a lot more signal that allows us to detect whether an account is breaking the rules, and then we can block that traffic or enforce those accounts," boat-botany said. Asked why boat-botany scrapes New Reddit less frequently than Old Reddit, the Reddit employee pointed to another commenter's explanation. "[T]he shape of malicious traffic is always changing," the user, Nestramutat, wrote. "It's going to be a constant cat and mouse game[.] As you ban one method, a new one gets developed. It's easy to see abusive traffic in hindsight, but it's harder to pre-emptively block it. Given that they're claiming Old Reddit doesn't have the modern security stack, this is likely proving to be an even greater challenge." Nestramutat said that the login requirement will add a barrier against threat actors. "You're also now attaching an account ID to every malicious request, plus account creation is only available on New Reddit (with the enhanced security stack)." As for how long Old Reddit will exist, boat-botany left the door open for its retirement. "We can't promise it will be around forever, but [Reddit CEO Steve Huffman] himself has said we'll keep supporting it while folks are still using it," boat-botany wrote. "That said, it doesn't have the same modern security tech stack reddit.com has, so we need to tighten security on old reddit to keep it viable."

Read more of this story at Slashdot.

Longtime Slashdot reader AmiMoJo shares a report from the BBC: New PlayStation games will no longer be released on discs from January 2028, the gaming giant has announced. Sony said in a blog post new games would still be able to be bought in shops, but they would come with a digital code. It comes just days after Rockstar announced the hotly-anticipated Grand Theft Auto VI would similarly launch without a physical disc. It marks a significant moment for the gaming industry, which has in recent years begun to rely more and more on digital distribution. Sony said the move came "as consumer preferences and the broader entertainment industry continue to shift away from physical discs to digital." "This is a natural direction for Sony Interactive Entertainment to adapt to consumer trends as the general preference for digital media significantly outpaces physical discs," it added. [...] PlayStation said the move would have no impact on games which are already released, or would be released before January 2028.

Read more of this story at Slashdot.

A federal judge rejected Meta's bid to dismiss claims from 29 state attorneys general alleging that Facebook and Instagram were designed to addict children while concealing the harms. The judge found significant factual disputes that must be decided at trial. They also ruled that Meta failed to comply with federal parental notice and consent requirements for children under 13, "and granted summary judgement to the states on that issue," reports Reuters. From the report: In a separate statement, California Attorney General Rob Bonta called the decision a "critical win" in holding Meta accountable for fueling a mental health crisis among American children. Gonzalez Rogers also oversees related multidistrict litigation by more than 2,600 individuals, school districts and local governments over whether social media platforms such as Facebook, Instagram, Google and YouTube, Snapchat and TikTok addict children. The states said research has shown that children's use of Facebook and Instagram could lead to depression, anxiety, insomnia, interference with education and daily life, and self-harm including suicide. Meta countered that the attorneys general had no evidence it misled consumers about its platforms' alleged addictiveness, including in congressional testimony by Chief Executive Mark Zuckerberg. The Menlo Park, California-based company said this was because "social media addiction" is not an established psychiatric condition, and therefore statements that its platforms are not addictive could not be false. Meta also said it didn't violate the children's online privacy law because it directed Facebook and Instagram to a general audience, not just children under age 13. In a 38-page decision, Gonzalez Rogers found material factual disputes over whether Meta's social media platforms are addictive, whether Meta falsely denied it designed them that way, and whether it "partially" directed the platforms at children. "The AGs present a reasonable interpretation of [Meta's] statements that Facebook and Instagram are not designed in ways that cause teens to compulsively use the platforms to their detriment," the judge wrote. "To the extent plaintiffs' evidence shows that the platforms are in fact designed to do just that, a jury could reasonably find the statements were untrue to a reasonable person," she added. A trial over California, Colorado, Kentucky and New Jersey's claims against Meta is scheduled for August 18, court records show. Further reading: Will Social Media Change After YouTube and Meta's Court Defeat?

Read more of this story at Slashdot.

An anonymous reader quotes a report from Space.com: NASA provided an Artemis update today (June 30), announcing new lunar landing contracts for its Moon Base initiative and a surprise new possible rover mission that could be headed to the moon's south pole. During the second monthly update that NASA has provided for its moon base plans, the agency named Astrobotic, Firefly Aerospace and Intuitive Machines as the providers of four robotic landers that will deliver scientific payloads to the surface of the moon, as NASA tests and expands the technologies needed for a permanent human outpost. "This is this drawing on the playbook that worked very well for NASA during the 1960s," NASA Administrator Jared Isaacman said during the livestreamed update, explaining the experiential approach to a crewed lunar return. "We didn't just jump right to Apollo 11." Isaacman also announced the potential repurposing of an engineering development model built to mirror the agency's Perseverance and Curiosity rovers on Mars. "There is another," Isaacman said, quoting Yoda's line from "Star Wars: The Empire Strikes Back." That test rover is called PROMISE, short for "Polar Rover for Observation, Mapping, and In-Situ Exploration" (though it was formerly known as Optimism). PROMISE was developed at NASA's Jet Propulsion Laboratory (JPL) in Southern California, where it has been used as a test platform for fixes or commands that engineers want to try on the ground before permanently sending them to Perseverance and Curiosity. Now, NASA wants to send PROMISE on a mission of its own. Though sending PROMISE to the moon would leave Perseverance and Curiosity -- both of which remain active on Mars -- without an Earth-based testbed, Isaacman thinks it would be worth it. "We've had years now of experience operating the two rovers on the surface of Mars, and we've got this hardware that the taxpayers have invested a lot in," he said. "So the question was posed: 'What if we send it to the moon?'" With a little refurbishment, PROMISE would help advance NASA's lunar plans, Isaacman added. Like Perseverance and Curiosity, the test rover is powered by a radioisotope thermoelectric generator (RTG), which converts heat from naturally decaying radioactive material into electricity. So it wouldn't require sunlight to operate -- a real benefit on the moon, where most locations experience long stretches of darkness. (NASA plans to build its Artemis base near the moon's south pole, which is thought to harbor an abundance of water ice and also has a relatively complex lighting environment.) The other robots currently in the works to launch on future missions to the moon, including the landers announced during today's update, are all solar powered. Through 2029, NASA hopes to launch up to 20 such missions as part of the CLPS (Commercial Lunar Payload Services) initiative to support the first phase of the agency's moon base plans, and the landers announced today will be some of the first in that lineup.

Read more of this story at Slashdot.

Version:next-20260701 (linux-next) Released:2026-07-01

Over the span of just 14 days, threat actors unleashed more than 81 million login attempts against Microsoft’s Azure command-line interface (CLI). The campaign, which security researchers at Huntress identified as an ongoing, automated password-spraying effort, successfully compromised at least 78 Microsoft accounts across 64 organizations between June 12 and June 26, 2026.

Building effective behavioral detections starts with understanding how processes behave at runtime, rather than simply collecting more logs. eBPF gives Linux security teams the visibility needed to correlate those behaviors into meaningful detections, moving away from static signatures and toward real-time analysis.

The Vera C. Rubin Observatory has begun its 10-year Legacy Survey of Space and Time, using the world's largest digital camera to image the entire southern sky every few nights. The project is expected to catalog billions of stars and galaxies, track changing and transient objects, and generate an enormous dataset for studying dark matter, galaxy formation, asteroids, and unexpected cosmic phenomena. The New York Times reports: "This is the end of a 30-year wait," said Phil Marshall, the deputy director of the telescope's operations at SLAC National Accelerator Laboratory in California, in a statement to The New York Times. "It's a major milestone for us." Astronomers expect this collection of data, known as the Legacy Survey of Space and Time, to revolutionize their knowledge of our galaxy's birth, the invisible matter permeating the cosmos, what shaped the universe into the structure it has today and more. According to Dr. Marshall, the survey is designed to see everything, "even the things we don't know we're looking for yet," he said. The team behind the observatory, a joint effort funded by the U.S. Department of Energy and the National Science Foundation, unveiled several images of the cosmos that were jampacked with celestial goodness -- a peek at what the Rubin could do -- last year. Since then, scientists have been busy conducting final tests and reviews of the telescope's operations and systems. According to Bob Blum, the director of Rubin operations at the National Optical-Infrared Astronomy Research Laboratory, the team has also been hard at work ensuring that the telescope can operate reliably in different environmental conditions for the next decade.

Read more of this story at Slashdot.

The FAA plans to replace its 1973 ban on civilian supersonic flight over U.S. land with a noise-based standard, potentially allowing aircraft to exceed Mach 1 as long as they stay below certain sound limits. The agency aims to finalize the rules by mid-2027, opening the door for companies such as Boom Supersonic and Spike Aerospace to operate quieter next-generation passenger jets over land. Longtime Slashdot reader schwit1 shared the notice (PDF) published Tuesday by the FAA. Forbes reports: Technological advances "will eliminate the old sonic boom," FAA Administrator Bryan Bedford said in a statement. "This means we can ultimately repeal the ban from the 1970s on supersonic flight over U.S. territory while minimizing noise impacts to residents in communities along the route and near airports." The primary reason was public opposition to loud sonic booms. In the 1960s, a plane flying faster than the speed of sound -- about 660 mph at high altitudes -- created shock waves that traveled to the ground and reached human ears as a loud gunshot-like crack or thunder-like boom. Tests during that decade, including the Oklahoma City sonic boom experiments, found repeated booms broke windows, damaged property and generated thousands of public complaints. In its 1973 ruling, the FAA stated that due to the limits of technology at that time, "a prohibition was needed to protect the public from sonic boom .... by preventing operations of a civil aircraft at a true flight Mach number greater than 1." Several years later, Air France and British Airways introduced Concorde, and were allowed to serve New York's John F. Kennedy International Airport as long as flights remained subsonic over U.S. land. Notably, "the prestigious London-New York service was the only truly profitable [Concorde] route, supported by high-powered business and celebrity travel," wrote a former British Airways network planner for Forbes in 2021. Several U.S. companies are working on a new generation of luxurious supersonic passenger aircraft with much quieter sonic booms and improved fuel efficiency. In particular, Colorado-headquartered Boom Supersonic says it has pre-orders from United Airlines, American Airlines and Japan Airlines for its Overture jets, which will carry 60-80 passengers. Atlanta-based Spike Aerospace is developing smaller Diplomat jets for up to 18 passengers. Both companies' websites tout future transatlantic flights in under four hours.

Read more of this story at Slashdot.

The Trump administration has lifted export restrictions that forced Anthropic to shut off public access to its Mythos and Fable models. After weeks of talks, Secretary of Commerce Howard Lutnick said Anthropic "has agreed to proactively detect and address security risks associated with the models; to work diligently with the U.S. government on protocols and standards and releases for Mythos, Fable and future models; and to inform the US government of any malicious activity." Access is set to begin returning July 1. TechCrunch reports: Anthropic had already publicly pledged to do much of this voluntarily, months before the export rule existed. That's part of why cybersecurity experts were skeptical of the restrictions in the first place. To them, the ban looked less like a security fix and more like leverage, a way for the Trump administration to punish Anthropic for its executives' public criticism of how the government, and the president's political opponents, might use the technology. Mythos was originally made available to a select group of organizations beginning in April to allay concerns about its ability to identify and exploit vulnerabilities in software, while a version called Fable was released to the public in June with additional security guardrails. However, with Asian AI companies beginning to release their own AI models approaching Mythos-level capabilities -- among them Fugu and Tulonfeng -- the US government was under pressure to ease its restrictions on Anthropic to ensure that American AI could compete globally. Last week, Lutnick cleared Mythos to be released to select customers approved by the White House. OpenAI's latest models were also released to a group of organizations approved by the Trump team, instead of the public. The Trump administration's erratic approach to AI policymaking has left companies across the industry with little clarity about what will govern future model releases. An executive order issued in June that signaled a desire to review models ahead of release was criticized by influential analysts like Dean W. Ball, who recently started a policy position at OpenAI.

Read more of this story at Slashdot.

An anonymous reader quotes a report from Inside Climate News: A new state law limits Florida communities' aims to offset greenhouse gas emissions that are warming the global climate and intensifying disasters such as hurricanes. Specifically, HB 1217 prohibits local governments from pursuing net-zero emissions goals. At least 10 cities and counties have implemented such policies, including Fort Lauderdale, Miami, Orlando and Leon County, where Tallahassee, the state capital, is located. But the new law will not necessarily upend these policies, said Bradley Marshall, senior attorney at Earthjustice, an advocacy group. "It's certainly meant to scare municipalities and local governments from trying to do things to further net-zero policies," he said. "Now, its exact impact and what it exactly prohibits is probably up for some debate. Things that are adjacent to it -- emissions reductions and even climate change reduction policies -- on their face will not run afoul at all of a ban on adopting a net zero policy." The measure requires local governments to submit an affidavit annually to the state Department of Revenue verifying compliance. Gov. Ron DeSantis, a Republican, signed the measure on April 22, Earth Day, and the law will take effect July 1. It states that "net zero policies, carbon taxes and assessments, and emission trading programs are detrimental to this state's energy security and economic interests and inconsistent with the energy policy and the environmental policy of this state." [...] HB 1217 also prevents local governments from purchasing items such as vehicles or appliances based on the fuels they use or production of the items. Local governments may not participate in carbon-trading programs or use public funds to support other organizations with net-zero policies. Cities and counties also may not charge a tax or fee tied with carbon emissions. "This bill is definitely part of a larger coordinated push by the political enablers of the fossil fuel industry to obstruct any tools -- legal or legislative tools -- to hold the industry accountable for its contributions to climate change," said Laura Peterson, senior analyst at the Union for Concerned Scientists, an advocacy group. "Florida is really on the front lines. So I imagine the governor is taking this step because he sees what's coming down the pike. It's not getting better. So I can only assume that this is an effort to satisfy some of the pressures that he's getting from donors and from his party to protect the industry. And he's doing it at the expense of his constituents."

Read more of this story at Slashdot.

If you’re relying on standard network logs to protect your Linux infrastructure, you’re flying blind. Most organizations believe they have network security monitoring because they’re capturing traffic, but they’re actually just collecting noise. Real security—the kind that stops an attacker—happens in the gaps between the network, the process, and the host. When an attacker breaches a Linux server, they rarely reach for a custom zero-day. They use what’s already there: curl, bash, python, or ...