While app performance is often equated with a smooth UI and fast start times, memory serves as the silent foundation upon which these visible metrics are built. It's no secret that we're seeing a shift where device memory is more important than ever. Not only have we made strides in Android memory optimizations with Android 17, we're providing the tooling and API support to help you stay ahead of stricter memory requirements later this year.

To ensure device stability, starting in Android 17, the system will begin enforcing app memory limits based on the device's total RAM. If an app exceeds those limits, Android will kill the process with no associated stack trace.

Optimize image loading

Detect and fix memory leaks with Android Studio

Memory leaks in Android occur when your code holds onto an object's reference long after its lifecycle has ended. This prevents the Garbage Collector (GC) from reclaiming that memory, eventually leading to sluggish performance or OutOfMemoryError (OOM).

Android Studio Panda 3 features a dedicated LeakCanary profiler task, allowing developers to analyze real-time memory leaks and map traces within the IDE.

The LeakCanary profiler task in Android Studio actively moves the memory leak analysis from your device to your development machine, resulting in a significant performance boost during the leak analysis phase as compared to on-device leak analysis.

Additionally, the leak analysis is now contextualized within the IDE and fully integrated with your source code, providing features like go to declaration and other helpful code connections that drastically reduce the friction and time required to investigate and fix memory leaks.

Trim memory when app leaves visible state

Android can reclaim memory from your app or stop your app entirely if necessary to free up memory for critical tasks, as explained in Overview of memory management. Android will usually reclaim memory from your app when it’s not visible to the user, such as by discarding some of your app’s code and data pages in memory or compressing your heap allocations. When the user resumes your app and your app tries to access some memory that’s been reclaimed, the OS will swap that memory back in on demand. This swapping behavior can be slow, and cause unexpected jank or stutters in your app.

If you leave it to the OS to decide what memory to reclaim from your app, you may find that the OS reclaimed memory that you’ll need shortly after resuming your app. Instead, your app can voluntarily discard memory allocations that it can regenerate later, on demand and at a low cost. To do so, you can implement the ComponentCallbacks2 interface. You can implement onTrimMemory in your Activity, Fragment, Service, or even your custom Application class. Using it in the Application class is highly effective for global cache management.

The provided onTrimMemory() callback method notifies your app of lifecycle or memory-related events that present a good opportunity for your app to voluntarily reduce its memory usage.

In terms of memory lifecycle management, your implementation should focus exclusively on TRIM_MEMORY_UI_HIDDEN and TRIM_MEMORY_BACKGROUND. Since Android 14, the system has ceased delivering notifications for other legacy constants, which were formally deprecated in Android 15.

TRIM_MEMORY_UI_HIDDEN: This signal indicates that your application's UI has transitioned out of the user's view. This provides an opportunity to release substantial memory allocations tied strictly to the interface—such as Bitmaps, video playback buffers, or complex animation resources.

TRIM_MEMORY_BACKGROUND: At this level, your process is residing in the background and is now a candidate for termination to satisfy the system's global memory needs. To extend the duration your process remains in the cached state, and reduce the number of app cold starts, you should aggressively release any resources that can be easily reconstructed once the user resumes their session.

import android.content.ComponentCallbacks2
// Other import statements.

class MainActivity : AppCompatActivity(), ComponentCallbacks2 {

    /**
     * Release memory when the UI becomes hidden or when system resources become low.
     * @param level the memory-related event that is raised.
     */
    override fun onTrimMemory(level: Int) {

        if (level >= ComponentCallbacks2.TRIM_MEMORY_UI_HIDDEN) {
            // Release memory related to UI elements, such as bitmap caches.
        }

        if (level >= ComponentCallbacks2.TRIM_MEMORY_BACKGROUND) {
            // Release memory related to background processing, such as by
            // closing a database connection.
        }
    }
}

Note: The onTrimMemory integration may depend on SDK support. For instance, certain games rely on their game engine to enable this capability. Please check out the game memory optimization documents.

Advanced memory observability with ProfilingManager

To catch and diagnose memory issues in the field that cannot be reproduced locally, you should leverage the ProfilingManager API. Introduced in Android 15, this advanced observability API allows you to programmatically collect real-user Perfetto profiles.

For teams that lack a dedicated infrastructure to manage and host performance artifacts, Crashlytics is exploring a specialized solution to streamline this workflow. They are inviting developers to provide feedback.

Android 17 introduces new event-driven triggers, most notably TRIGGER_TYPE_OOM and TRIGGER_TYPE_ANOMALY:

• The OOM trigger automatically collects a Java heap dump at the exact moment an OutOfMemoryError crash occurs, providing precise allocation states. A collected OOM profile is provided the next time the app starts and registers the registerForAllProfilingResults callback.
• The Anomaly trigger detects severe performance issues, such as excessive binder spam or breached memory thresholds. The memory anomaly delivers a heap dump just prior to the system terminating the app.

  val profilingManager = 
applicationContext.getSystemService(ProfilingManager::class.java)
    val triggers = ArrayList()  


    triggers.add(ProfilingTrigger.Builder(
                 ProfilingTrigger.TRIGGER_TYPE_ANOMALY))
    val mainExecutor: Executor = Executors.newSingleThreadExecutor()
    val resultCallback = Consumer { profilingResult ->
        if (profilingResult.errorCode != ProfilingResult.ERROR_NONE) {
            // upload profile result to server for further analysis          
            setupProfileUploadWorker(profilingResult.resultFilePath)
        } 

    profilingManager.registerForAllProfilingResults(mainExecutor, resultCallback)
    profilingManager.addProfilingTriggers(triggers)

Once you’ve collected the heap dump, you can download the profile from the server, or locally via adb pull and drag and drop the file into the Perfetto UI. To streamline your memory debugging workflow, use the Heap Dump Explorer, this is the new default view for heap dumps in Perfetto UI. This tool provides an intuitive interface for inspecting Java heap dumps, allowing you to visualize object allocation hierarchies, compute retained memory sizes, and identify the shortest path from garbage collection root. By leveraging the Heap Dump Explorer, you can rapidly pinpoint memory leaks, bloated retained objects such as excessive bitmap allocations, and analyze heap object allocations all in one place.

Conclusion

Optimizing bytecode with R8, adopting image loading best practices, and resolving memory leaks are critical steps toward delivering a high-quality user experience while managing resources effectively under pressure. Adopting these proactive measures helps maintain app stability and performance, preventing unexpected terminations while safeguarding user context. To further your performance expertise, explore our revised memory guidance.

Read more of this story at Slashdot.

How To Use Google Bard)(Google Bard Tutorial)

Welcome to our channel where we bring you the latest breakthroughs in AI. From deep learning to robotics, we cover it all. Our videos offer valuable insights and perspectives that will expand your knowledge and understanding of this rapidly evolving field. Be sure to subscribe and stay updated on our latest videos.

All Bard Features
- Bard Can Make Charts - https://www.reddit.com/r/GoogleBard/comments/123s0yt/wow_google_bard_can_make_a_chart_bing_ai_used_to/
- Bard makes very big mistakes https://twitter.com/0xgaut/status/1638287359098716160
- Bard Cannot Help With Coding - https://twitter.com/iamnafets/status/1638232186649477120/photo/1
- Bard Actually has access to recent events
- Bard Cant Access Articles (Sometimes
- Bard Can Rewrite content
- Rewording Questions Helps https://www.reddit.com/r/GoogleBard/comments/11xoaw7/bard_can_actually_answer_code_questions_it_just/
- Bard Can write stories
- Bard is a confusing mix between ChatGPT + Bing
- Bard does have shorter answers
- Bard is quicker

Was there anything we missed?

(For Business Enquiries) contact@theaigrid.com

#LLM #Largelanguagemodel #chatgpt
#AI
#ArtificialIntelligence
#MachineLearning
#DeepLearning
#NeuralNetworks
#Robotics
#DataScience
#IntelligentSystems
#Automation
#TechInnovation

Bots (and privacy-preserving browsers) not welcome

Browse a news site in a private window. Shop at a major retailer with a VPN. Visit a video streaming platform with anti-fingerprinting defenses tuned up. You’ll see the same responses: registration walls, block pages, and endless CAPTCHAs. The message is clear: if we think you might be a bot, you’re not welcome.

Websites have valid reasons for wanting to block bots. Bots enable volumetric abuse, abuse that wouldn’t otherwise be feasible if they had to be carried out by humans.  For example: SEO comment spam, credential stuffing and DDoSing. Consequently many sites employ dedicated anti-abuse tooling which aims to keep the bots out whilst minimizing friction for human visitors.

Unfortunately, that tooling is increasingly failing at both tasks. Browser privacy protections are dismantling the passive signals that anti-abuse systems depended on to identify and distinguish visitors. Meanwhile advances in generative AI have rendered CAPTCHAs ineffective: bots now solve them faster and more reliably than humans.

Many sites are switching to more invasive mechanisms and now ask visitors to disclose identifying information, e.g. an email address, a federated login or disabling their VPN. This means greater friction for users, since providing these details on a first visit takes time. It also compromises their privacy, since these details enable the same kinds of cross-site tracking that browser privacy protections were intended to mitigate.

This leaves users with a dilemma. The more effectively they protect their privacy, the harder it is for websites to distinguish them from bots and the worse the treatment they receive. Website operators are also suffering. The additional friction they inflict upon well-behaved visitors harms their site, but many are willing to pay the costs if it mitigates volumetric abuse.

Browser-based AI agents make this tension more acute. Sites may want to allow agents which are acting on behalf of individual users while blocking agents engaged in volumetric abuse. However, with no effective mechanisms to distinguish the two, websites are opting to block both. That hurts users, who should be free to choose the user agent they use to access the web; it hurts new browsers and agents, which struggle to interoperate; and it hurts sites, which lose legitimate visitors.

The consequence is that the web gets worse for everyone. Users get more friction or less privacy or both. Website operators see more volumetric abuse and the friction they add drives away users who would otherwise want to consume their content or services. New user agents struggle to access the same content as conventional browsers.

The Costs of Convenient Solutions

Some large ecosystem players have put forward solutions that leverage their control of the dominant operating systems and their deep integration with consumer hardware. These rely on device attestation: identifiers and privileged code baked into devices at the hardware level, which let manufacturers prove what software is running on a user’s device. Exposing this functionality to the web means attesting to sites that the user is running approved software with trusted hardware and therefore isn’t a bot. There have been two substantive proposals.

Google’s Web Environment Integrity, abandoned in 2023, was the blunt version. It attested to the user agent itself, as well as the operating system and device in use. Users would have lost control in two ways: once to the attester, which would decide which operating systems and devices could be blessed, and again to the website, which would decide which software to accept. If sites had adopted allow-lists of approved user agents, building a new browser would have become virtually impossible, and sites could have withdrawn access from any user agent they chose.

Apple’s Private Access Tokens, deployed across their ecosystem in 2022, have more subtle issues. Built on the Privacy Pass protocol standardized at the IETF, they get a lot right: a user receives a renewed, limited batch of one-time tokens that can be presented to websites without linking their visits together. This provides privacy for users and has shown rate limits to be an effective tool for sites – both points we’ll return to later in this post.

However, Private Access Tokens rely on device attestation, requiring that the hardware manufacturer be in overall control of the user’s device. Presenting a PAT tells a website you are locked into Apple’s rules for what counts as acceptable software. Due to PAT’s technical design^[1], there’s no way to open the system to other sources of scarcity without compromising the system’s privacy properties, meaning that if more widely deployed, access to the web would become tied to having bought expensive hardware from a small, hard to change set of vendors.

Both approaches are ultimately hostile to users and to the openness of the web. Both are premised on parts of a user’s device that sit within the manufacturer’s control and beyond the user’s own. Were they widely deployed, the web would become just another walled garden with centralized gatekeepers controlling acceptable hardware, operating systems and software. As convenient as these solutions are for the players who already dominate the ecosystem, we think there’s a better path.

A Better Path Forward

Bots’ harms arise from their ability to operate beyond human scale. For sites to prevent volumetric abuse they don’t actually need to know the user’s identity or receive cryptographic proof that they’re running approved software. If sites knew their visitors were restricted to a rate limit set by a site, that would be enough.  

Rate limits only make sense if they’re tied to something scarce; something an attacker can’t cheaply replicate to evade the limit. Without anchoring to a scarce resource, like the trusted hardware used in Private Access Tokens, attackers can generate as many fresh identities as they need to bypass the rate limit.

However, hardware is just one option for scarcity. Anything a user already has that an attacker can’t trivially spin up at scale will work: email addresses and phone numbers are naturally scarce. A paid subscription costs an attacker the same as a real user.  Even maintaining an account on a free service requires some non-trivial work.

What if we could use these scarce signals across the web? We could build an open ecosystem with many parties offering scarcity signals, each site choosing which to accept. By opening up who can provide a signal, and letting sites choose which to accept, we can avoid transferring control to device manufacturers and the resulting harms.

As a concrete example of who might be well positioned to provide such a signal, we can consider VPN providers acting as a subscription service. Sites routinely block VPN users indiscriminately, whether through a deliberate policy choice or through an indirect consequence of rate limiting visitors per IP address. But a VPN subscription is a perfect source of scarcity. If the VPN provider could vouch for its users so that sites could rate limit each user individually – then users would be able to browse the web with less friction and without giving up their VPN usage.

The catch is that building a system that can enable this on the open web whilst maintaining user’s privacy is genuinely difficult. It requires that we take information from one site — that this user holds some scarce thing — and expose it to other sites so that they can use that as the basis for their rate limiting. Letting one site verify a signal from another is the sort of information flow that privacy-preserving browsers have spent the last decade locking down to prevent cross-site tracking.

Our goal would be that no more than the minimum information gets through: a single bit communicating whether the user is below the rate limit set by the site. Leaking anything more – like the source of the scarcity that the rate limit is anchored to – would be unacceptable. Enabling a new cross-site information flow might feel like compromising privacy to gain better access, but reality is more nuanced. If a new system moves sites away from demanding that visitors be identifiable (whether through fingerprinting or login forms), it can be a win for both privacy and access.

The Foundations

The good news is that the cryptographic foundations for a privacy preserving approach already exist. The Privacy Pass protocol, originally developed in 2018 to reduce the friction of Cloudflare CAPTCHAs for Tor users, introduced the core primitive: a token that is unlinkable between issuance and redemption. You prove something to an issuer (e.g. by solving a CAPTCHA), receive some tokens, and later present a token to a website. The website can verify the token is legitimate, but can’t link it to the user it was issued to.

Figure 1: In Privacy Pass, a CAPTCHA provider can issue tokens to a client which can then be used to bypass challenges for future site visits. Even if the CAPTCHA provider and sites collude, they can’t use the tokens to identify the user or their browsing history.

Privacy Pass has gone on to be successfully deployed in systems where the issuer and verifier have a prior trust relationship: Apple uses it to authenticate users of Private Cloud Compute and Private Relay without linking their activity to their identity, Chrome uses it for two-hop IP protection, and Kagi uses it to provide private search. These deployments work in part because a small number of parties have agreed in advance on who issues tokens and who accepts them.

Applying this approach to an open system where any site can act as an issuer brings real challenges. Firstly, even though tokens are unlinkable, knowing a user has access to a specific issuer is a privacy leak on its own, because you can infer that the user meets the relevant issuance criteria. If one site can learn that you have a token from another site, that reveals that you have been to that site, which can be a major privacy problem. This compounds if sites can learn the set of issuers you have visited, since it becomes a fingerprint which can be used to identify you.

Generic techniques exist for proving a statement in zero knowledge: we can prove that a client has a token from a set of acceptable issuers without revealing which specific issuer it is. We’ll call this issuer blinding. The generic approach is often slow, but bespoke approaches tailored to the underlying cryptography can improve this considerably.

Another challenge is how sites using rate limits decide who to trust to issue tokens. If an issuer misbehaves then the site’s rate limits become ineffective, enabling volumetric abuse. However, if we need to prevent the site from learning which issuers a user has access to, the site is only going to know that one of its trusted issuers was used, not which one. This makes mistakes or misbehaviour by an issuer difficult to detect, and makes it hard for sites to evaluate new issuers. Solving this challenge is essential for openness. Without adequate information, sites are likely to lean towards conservative issuer selection. That could lead to less choice between Anchors, which in turn could lead to a new form of gatekeeper being created. 

To solve this, sites at least need a way to calculate an aggregate score for each issuer they use. This should roughly correspond to how much of the traffic it considers abusive to have come from users using that particular issuer. Mozilla has long invested in systems like Prio which use multiparty computation (MPC) to protect user privacy whilst enabling aggregate measurements of system behaviour.

Privacy Pass also struggles to handle dynamic adjustments to rate limits. Once tokens have been issued, they’re difficult to invalidate without either revoking all active tokens or risking attacks which can compromise the privacy of users. It’s also beneficial if sites can adjust rate limits on a per client basis, for example by increasing rate limits where they become more confident the client is benign and withdrawing access when abuse is detected.

Anonymous Credit Tokens offer a useful building block to solve this problem. Conventional Privacy Pass schemes rely on issuing a bucket of tokens but ACT works differently by enabling the use of a credential with state. For example, an ACT credential can hold an internal counter. When the credential is presented, the site can check the counter is over some threshold and mutate it, increasing or decreasing the counter whenever the site’s perception of the holder has improved or worsened. Critically, the exact value is never leaked to the site, preventing the site from tracking the holder and ensuring successive presentations of the same credential can’t be linked.

Putting it together

So how can we combine these techniques to build a system which can enable privacy-preserving rate limiting on the open web? In May 2026, we participated in a W3C CG Meeting in collaboration with Cloudflare, Chrome and other web stakeholders in which we started sketching out a design we’re calling PACT – Private Access Control Tokens.

Rate limits need a starting point, a source of scarcity to anchor on. We’ll call an entity that provides such a source an Anchor. To a user who meets the Anchor’s criteria, like having a subscription, an account in good standing, or a verified phone number, an Anchor issues a batch of Endorsement tokens, following the Privacy Pass model. In practice, Anchors could be any website which has access to this kind of signal. An Endorsement conveys scarcity to other sites.

That’s enough for a simple system where access is either granted or denied. But as we discussed earlier, we also want the ability to increase access where a visitor behaves benignly and decrease it where they don’t. The state needed to enforce a rate limit can’t live in the Endorsement, because Endorsements cross trust boundaries between unrelated sites. We need a second object that can hold that state, scoped to the party that maintains it.

We’ll call that the party that handles rate limiting for a site a Moderator and the stateful object a Credential. A Credential is specific to a Moderator and, unlike endorsements, we limit each site to nominating a single Moderator. In the common case the site itself plays the Moderator role, so there’s no new entity or trust boundary. A Moderator can also be a third-party service shared across many sites, allowing those sites to cooperatively share a rate limit. 

In the terminology of the previous section, the Anchor is the issuer of Endorsements, and the Moderator both verifies Endorsements and issues Credentials. A Moderator manages rate-limit policy: it decides which Anchors it trusts, accepts their Endorsements, and issues a Credential in return.

Figure 2: (1) Clients acquire Endorsements from Anchors in the course of normal browsing to sites they have relationships with. (2) Clients can exchange Endorsements for a stateful Credential from a Moderator. (3) Credentials can be used to access sites which use that Moderator. Credentials can be updated over time.

Directly revealing which Anchor backed an Endorsement would leak a lot of information about the user. The issuer blinding techniques from the previous section solve this: when an Endorsement is redeemed, the Moderator only learns that it came from one of the Anchors it trusts, but not which one.

When a Moderator covers more than one site, we let Credentials be presented across all of them but partition cookies and storage as we would for any other third party site. The unlinkability of Credential presentations keeps this from creating a new cross-site identifier. The benefit is that good behaviour on one site improves access on every site the Moderator covers, and bad behaviour cuts it everywhere. Websites can already build the same capability with a shared account system, so this doesn’t create a new way to lock users out, but it does provide a new way to grant access without requiring users to give up their privacy.

Enabling Moderators that cover many sites carries a centralisation risk, similar to the concentration we see today in anti-abuse providers. The mitigation is that the choice of Moderator stays with each site, and the choice of trusted Anchors stays with each Moderator. This can’t reverse the centralisation pressure the web already faces, but it ensures this system won’t lead to additional lock-in: a new Anchor or a new Moderator can be adopted without coordinating with a dominant vendor.

The system then has three flows. First, the user receives Endorsements from an Anchor in the course of normal interaction, based on the Anchor’s positive view of the user. This is a relatively rare operation for any given user and Anchor. After all, as our source of scarcity, Endorsements should not be too easy to accumulate.

Figure 3: In the course of normal browsing, clients browse to websites they have a relationship with. These sites can act as Anchors by issuing Endorsements to clients.

Second, when the user arrives at a site that works with a Moderator, the browser spends an Endorsement from an Anchor the Moderator trusts and receives a Credential in return. The presentation hides which Anchor was used, and neither the Anchor nor the Moderator can trace the Endorsement back to where it was issued. The Moderator decides what initial balance the Credential starts with. If the user has no Endorsements from suitable Anchors at all, existing mechanisms (CAPTCHAs, account creation, federated login) could be used to bootstrap a Credential the same way, so the system degrades to today’s experience rather than locking the user out.

Figure 4: When the client browses to a site, it can prompt the client for a Credential from the Moderator it uses. If the Client doesn’t have a suitable Credential, but does have a suitable Endorsement, it can exchange it for a Credential with the Moderator. In practice, the Moderator and the Site might be the same server.  

Third, as the user browses, the browser presents the Credential and the Moderator updates the internal state of the Credential. The Moderator can reward behaviour that looks benign and penalize suspicious activity, but can’t track the use of the Credential or identify it if it’s used on other sites the Moderator covers. Revocation falls out of the same mechanism: a Moderator can refuse to return an updated Credential. 

Figure 5: The Client can present the Credential on sites which use the matching Moderator. Sites can check if the Credential is in good standing. The sites can then adjust the access the Credential has in response to behaviour. E.g. increasing it when they gain confidence in the client or reducing it in response to malicious behaviour.

In practice, all of this would happen transparently to the user through a WebAPI that sites acting as Anchors or Moderators would call from JavaScript. In an ideal ecosystem, users would accumulate Endorsements through normal browsing, just by virtue of the sites they already visit, and the rest of the flow would happen in the background as they move around the web, leaving users with meaningfully less friction.

AI agents acting on behalf of a user slot into the same flow. An agent can carry its user’s Credentials, in which case the user remains accountable for how the agent behaves. Sites would not need to grant any more access than they would to the user themselves. Alternatively, the operator of an agent can run its own Anchor and vouch for its agents the way other Anchors vouch for human users. Sites retain control over which Anchors they accept, so they can choose how to treat agent traffic without needing a separate detection mechanism.

Several mechanisms combine to keep the information about a user that flows out close to a single bit. Cryptographic unlinkability ensures successive Credential presentations cannot be tied to each other or to the original issuance, so a user’s visits cannot be joined into a history. Each site is bound to a single Moderator, so the set of Moderators a user has Credentials with never becomes a cross-site fingerprint. The Anchor-to-Credential exchange happens in an isolated browsing context, so during ordinary browsing the only thing the site or its Moderator ever observes is a Credential presentation: the site only learns if the user has a valid Credential below the rate limit, or nothing. When the Moderator updates a Credential, it adjusts the credentials state without learning what it is.

The additional privacy given to users from Issuer blinding makes participating in the system more challenging for Moderators. Because the Moderator can’t see which Anchor backed a Credential at issuance, it can’t give a Credential from a strong Anchor more access than one from a weak Anchor: doing so would itself leak which Anchor was used. The initial access has to be uniform across the Moderator’s whole pool of Anchors, which in practice means setting it at the strength of the weakest. However, this is only relevant for that initial access, the Moderator can update credentials according to the holder’s behavior, enabling Credential’s to accrue access over time.

Building an open ecosystem also requires that sites can make effective decisions about the Anchors they choose to trust. Multiparty computation systems like Prio enable aggregate scoring without compromising privacy. When users present Credentials, they can provide an encrypted share which identifies the anchor they used and can be privately aggregated to compute the quality of an issuer.

Next Steps

We think the architecture we’ve sketched for PACT has the right shape, but many of the details still need to be worked out and the entire system needs rigorous privacy and security analysis.

We want to do that work in the open. The IETF is the natural venue for the cryptographic protocols underneath, and the W3C for the WebAPI surface that sits on top. We’ll be bringing draft specifications to these bodies as soon as they’re ready, and we welcome collaborators from across the ecosystem: browser vendors, site operators, anti-abuse providers, and the cryptography community.

If successful, we think we can provide a system which will keep the web open and private, while still giving sites the rate-limiting signal they need.

Acknowledgements

The ideas described here are the result of collaboration and conversations with many people, including: Watson Ladd, Thibault Meunier, Michele Orrù, Trevor Perrin, Eric Rescorla, Samuel Schlesinger, Martin Thomson, Eric Trouton, Benjamin Vandersloot & Cathie Yun. 

The post PACT: Anonymous Credentials for the Web appeared first on Mozilla Hacks - the Web developer blog.

In this post we walk through what folks have found on their journey to learn the Rust programming language with ups and downs covered.

As a disclaimer, LLMs (Large Language Models) come up in this post because our interviewees brought them up. We're scoping discussion to their use as a learning tool, covering research and example generation, not broader questions about AI (Artificial Intelligence) in software development.

Many paths to needing Rust

The interviews surfaced several different paths into Rust: curiosity, embedded work, job-market pressure, organizational adoption, and reassignment after a team or company chose Rust. That last path matters because many learners are not evaluating Rust from a blank slate; they are trying to become productive after Rust has already arrived in their work.

"Funny enough, I've advocated for more niche languages than Rust in the past. Rust has pretty much stopped being as much of a niche language as it was, but it's not Java." -- Fractional CTO

Rust learning resources

Likely as expected, the folks that we talked to reach for a range of resources to learn Rust. Some reach for official documentation, such as The Rust Programming Language Book and find that sufficient to build on what the compiler was already showing them.

"I started with the official Rust documentation because there are a lot of great examples of how features like the borrow checker work." -- Software engineer at an Automotive supplier

Others needed more passes and more formats, sometimes reaching for resources the community maintains, such as Rustlings, The Little Book of Rust Macros, and Learn Rust With Entirely Too Many Linked Lists.

"The first time I went through the chapter in [The Rust Programming Language] on borrow checking, I was like, what is this? I read it again, then I watched a YouTube video of someone explaining the chapter." -- Rust freelance consultant

"Rust book, Rustlings, Zero to Production in Rust, Jon Gjengset tutorials. A bunch of books. It's not a one-pass reading. Can't say how many times I've gone through it." -- Software engineer working on video streaming and storage

These resources have brought up an entire generation of Rust programmers. But, to some, there is a perception that these resources have trouble keeping pace with the language.

"We'd like to use [The Rust Programming Language/'the book'], but we've found that it's out of date, unfortunately. We've looked at the GitHub repo and found it's got a lot of unresolved issues and unmerged PRs" -- Principal Software Engineering work on Rust adoption in a regulated industry

Whether or not this is factually true, Rust's growth has nonetheless put more scrutiny on these materials. Companies evaluating adoption and engineers getting reassigned to Rust teams are looking at them with fresh eyes and finding the gaps that affect their own evaluation.

Beginner stumblings and unlearning habits

It's pretty typical for Rust to be the 2nd, 3rd or Nth programming language that someone picks up. They'd end up writing their most familiar language in Rust, whether C++ patterns, Java patterns, or whatever they knew, for months or even years. Eventually they got comfortable enough to start writing idiomatic Rust.

"There's a bit of a drop in productivity compared to C if you're already familiar with it just because you're learning new rules, new syntax." -- Principal Firmware Engineer (mobile robotics)

"In the beginning it was more poking around the code and adding and removing some ampersands and asterisks to try to make sense of mut and not mut and whatever." -- Senior engineer with 20 years of Java experience in cloud and IoT

We also spoke with someone who found that not having much of a programming background seemed to benefit people picking up Rust. Not having worn-in grooves from other languages may play a role here, and it's worth investigating further.

"I had someone who had never programmed much before start working on the internals of [our Rust project]. She was just fine with getting into Rust. It's more of the senior people that struggle as they need to unlearn practices which may work in other languages, but it's not the 'Rust' way." -- Researcher, Automotive OEM R&D Lab

Learning to work with the borrow checker

We heard a lot about learning to work with the borrow checker instead of against it. People get there through different paths, but a few patterns came up repeatedly.

The compiler as teacher

Rust's diagnostics did the teaching on their own, especially around lifetimes.

"If you mess up the lifetimes in a piece of code that you've written by hand, I usually find that Rust's diagnostics are very helpful" -- Researcher working on static analysis of Rust programs

"Whatever's missing, the compiler usually fills in: it tells me 'you need to declare the lifetime of this reference', so I know and can figure it out. That all generally works pretty well." -- Senior Software Engineer

Learning by doing

Others felt like they only really internalized the borrow checker after writing a lot of Rust. It took projects, coding challenges, prototyping and so on until at some point it clicked.

"I actually did not understand the borrow checker until I spent a lot of time writing Rust" -- Founder of a startup built on Rust

"Besides the prototyping work, I also did coding-challenge-type stuff to get familiar with Rust for Advent of Code. [..] It eventually clicked to the point where I wasn't fighting with Rust, it was working for me. I had that experience other people describe: when I managed to get my program to fit with Rust, it worked. I didn't spend time debugging." -- Principal Software Engineer, large SaaS provider

Letting go of "clone guilt"

Some learners arrive with the assumption that good Rust means zero clones, zero copies, lifetimes threaded through everything. They set the bar at optimal before they've learned how to write idiomatic Rust, and it makes the borrow checker feel harder than it needs to be at the outset.

"On one of my first projects, I was like, 'I don't ever want to copy or clone anything,' so I carefully wove through all the lifetimes and got myself into a bit of a bind. Then I saw someone else just cloning the struct I was working with, and it was super cheap. Sometimes you can just clone and it's going to be okay." -- Researcher at a university

The experienced Rust developers we spoke with consistently said the same thing: clone freely while you're learning, then optimize when you understand the problem. Rust's reputation for performance and correctness feeds this. Newcomers assume anything less than optimal is wrong before they've written a first working program, and clone guilt is how that shows up.

We think it could be an interesting area of future study to check into the patterns Rust programmers employ at different levels of experience and under which circumstances. One member of the Rust Vision doc team that's very experienced with Rust noted that there's kind of an "expected shape" they understand as passing the compiler. This knowledge influences how they approach writing code which wouldn't take that shape and they naturally find themselves understanding when to use so-called workarounds, such as passing around indices into arrays or Vecs.

Multi-paradigm, but not the OOP some are used to

The Rust programming language is multi-paradigm, and how that lands depends on what you're coming from. We heard some that came from a functional background were delighted with digging into learning how much Rust inherits from that lineage. Some others noted that they and others on their teams struggled to unlearn the object-oriented style they'd come to use heavily in other languages like C++ and Java.

"Developers coming from C++ tend to think object-oriented. I think that's a difference between C++ and Rust." -- Architect at Automotive OEM

"I had exactly that thing, where I would apply all my years of Java and JS thinking, where I could just create some object, not care about it, return it, have it sloshing around between various functions. Found myself reaching for these patterns and then being told 'no, you cannot do that'." -- Principal Engineer at a SaaS company

Developers coming from functional programming had less to unlearn: strong typing, pattern matching, and an expression-oriented style were already familiar.

"My background has been more functional programming, strong typing. That originated for me as a Lisper: once a Lisper, always a Lisper." -- Principal Software Engineer working on Rust tooling for safety-regulated industries

"The languages I primarily used before Rust were things like OCaml. Way back, I came from C and C++, the classic languages, and then I spent quite a long time doing primarily pure functional stuff. These days I've ended up back in what I like to think of as a pragmatic center ground [with Rust]." -- Fractional CTO

Teaching Rust in academia

We spoke with a university professor that's been teaching Rust generally. In the academic environment, they were able to use proxies for some things such as "traits are like interfaces in Java" because the students had already gone through a set of courses in their first and second years that taught them Java. They introduced concepts slowly throughout the course, choosing to deal with some more complex topics like generics later. The outcome generally was that students had no problem picking up Rust in this setting.

"I couldn't see any big difference on the embedded side. We also teach an embedded class, and we did an experiment. Half of the students' feedback was worse on the Rust class, mostly because they needed to build the project themselves. The C students just got one from [an LLM], absolutely no problem." -- University Professor, on teaching Rust

The C cohort leaned on LLMs for the project in ways the Rust cohort couldn't. We don't yet have a clear answer for why.

What did come through clearly was the Rust cohort's experience with the community. Some students needed to figure out which drivers to use for the embedded project and how to use them. Their professor encouraged them to open issues and ask questions directly on GitHub, and the maintainers responded. Students who had never contributed to open source before were getting answers from the people who wrote the code.

Learning using LLMs

Some experienced folks shared that they saw LLMs as a tool that can help someone come up to speed quickly, either as a research tool or for generating example Rust code to understand concepts.

"I'm optimistic that there's a way to work [LLMs] in that will cut down that learning curve. One of the big things these tools bring is reducing the learning curve in general; these are very good tools to help you navigate a space that you don't know yet." -- Maintainer of large open source Rust crate

"I try [LLMs] out once a month, usually for generating an example or something like this. Just like with Stack Overflow: when you read an example, you should read it carefully and try to understand it. Not copy and paste it, but type it in your own words in code and then check it, because that's where the teeny tiny little mistakes are." -- Founder of startup built on Rust

For some learners, an LLM is just another way to find answers, no different than a search engine.

"So for the most part, picking up Rust - how do I learn? I'll [use web search for] things, I'll ask [an LLM], I'll just poke around and read the code." -- Senior Software Engineer working in a regulated space

One founder went further and claimed that LLMs change who can become a Rust developer. One consulting company founder described hiring high school graduates with no systems programming background and training them as Rust developers, with LLMs filling in the learning gaps that would previously have required years of experience.

"At the beginning, I was worried, but now that we have [LLMs] supporting development, the difficulty of the language doesn't matter. I'm seeing a huge opportunity behind strong runtime languages like Rust. [..] In [Developing Country] we hire 20-25 high school graduates, train them to be Rust programmers, then they enhance our workforce worldwide." -- Founder of a consulting company

We heard this from one organization. This is a claim that the combination of Rust's compiler and LLM tooling can dramatically shorten the path from beginner to working developer. Whether it generalizes depends on questions we can't answer from a single interview: how long these developers stay, what kind of code they can maintain independently, and whether this training/learning model works outside this company's particular structure. If it holds up, the pool of people who can become Rust developers is much larger than the usual hiring profile suggests.

Organizational considerations for Rust learners

We spoke with a number of folks on teams that are using Rust in larger organizations. Teams wanted to know that everyone would end up at roughly the same level of competence, which led a good number to invest in training courses to get there. Some leaders found that staff was able to ramp well enough by reading The Rust Programming Language, going through Rustlings, and then picking up lower risk and priority tickets to work on. Having a sense of community was also important within companies; it helps people know they are not alone when they are asked to work on Rust after, say, a reorganization happens.

"[..] the idea with the class as opposed to 'just read the Rust book on your own' was that this gives everyone kind of the same baseline going in." -- Principal Firmware Engineer (mobile robotics)

"So typically we're going to have people work through Rustlings, work through The Rust Programming Language. We have them then start to pick up lower risk tickets to work on." -- Principal Engineer at a large SaaS provider

"We've got an internal Slack channel for Rust learning where people can drop questions and others will come in and answer them. That helps build up understanding and community." -- Software Engineer at a large corporation

Some organizations found that while the person they'd hire would need to learn Rust, it was still preferable to the alternative of hiring someone for a critical piece of software written in another language.

"They needed to grow and maintain this C++ codebase. They had a C++ wizard, and they tried for about two years to find someone with the same level of expertise. They ended up hiring people that didn't know Rust and ramping them up, creating FFI bindings from the C++ side so they could work in Rust. And you can feel it: the borrow checker is teaching these people the right way to handle their systems." -- Principal Engineer at an Automotive OEM

The community and helping each other aspect seems to grow bonds as organizations mature.

"Our team is [all about] mentorship. I've mentored people coming up to speed on Rust, and people help each other hugely." -- Principal Software Engineer at a large SaaS company

Silent attrition

We identified some cases where people have approached Rust and bounced off of it, for one reason or another. In the below case, someone with a background in a language with fewer guardrails found themselves frustrated enough with Rust to walk away.

"All of that means that that embedded ecosystem is very frustrating to somebody who comes from C and is like, why can't I just get a pointer to this peripheral and then write into the registers. What are you doing to me? [..] My friend never got over that. He looked at it and said, I'm not going to deal with this and walked away." -– A second University Professor

There may be language features that for a particular domain are not seen as comfortable or usable yet, such as async Rust usage in a safety domain. We'd like to map which language features feel off-limits in which domains; async in safety-critical work probably isn't the only case.

"We're not fully sure how async [Rust] will work out in the long run in our domain. [..] People don't feel comfortable yet since C++14 doesn't provide such concepts. [..] It's the chicken-and-egg problem again: we probably need to gain some experience to see whether we can actually benefit from these new concepts in the automotive and safety domains." -- Team Lead at Automotive Supplier (ASIL D target)

We heard in at least one case, that while the language was challenging and there was a near bounce, the tooling helped keep them coming back and trying.

"Well, I think my early impressions of Rust - one is I find C++ so intimidating, and I think a big part of why I was able to succeed at [..] learning Rust is the tooling. I mean, all this makes sense [..] but it's like, for me, getting started with Rust, the language was challenging, but the tooling was incredibly easy." -- Founder of another startup built on Rust

While it might be considered more of a community concern, if there are interactions online and in spaces that point to learners having so-called "skill issues" this feeds into the narrative that Rust must be hard to learn. We may be unintentionally turning away Rust Project contributors and maintainers due to the vibes being put out when new learners show up in certain spaces.

"People are very helpful, but generally the attitude is: if your program is very complicated, it's mostly a skill issue. There's not that much empathy when people get stuck learning, and a lot of people are just pushed away by it. There's probably a huge number of people who silently stop wanting to write Rust, because at some point it gets complicated and the feedback they get is 'you just need to be a better programmer, obviously'." -- Software Engineer at a SaaS Provider

Feedback on near-bounces from survey

We found a few interesting perspectives collected in the Rust Vision doc survey which we administered with examples of bouncing and coming back:

"I started before 1.0, got stuck very soon when trying to translate patterns from C++ to Rust (due to borrow checking). I tried again after 1.0 and it stuck. [..]" -- Survey Respondent A

Survey Respondent A went on to share in a more detailed response about a perceived weakness in Rust learning materials related to lifetimes and the borrow checker are explained. There was an observation that it's fairly easy to run into more complex situations with lifetimes and the borrow checker. They felt that the current state of this sort of material and tutorials is fairly superficial and can leave learners stuck when they run into those more complex situations.

One respondent that bounced once and came back shared challenges around usage of async. In concert with Rust's memory-safety and the borrow checker, they found some of the nitty-gritty details of async were difficult to learn. While we're aware of the Rust Project's continuous efforts to improve Rust's async story, this is another data point of a user that faced challenges.

Another survey respondent shared how they had multiple times bounced in trying to learn Rust. They returned after a year or so and found Rustlings to be highly motivating. We note that having multiple pathways for folks to learn Rust opens up more possibilities for those that nearly bounced, just like this person.

Need more focused work on silent attritrion

The thing that stood out most to us was the lack of real, first-hand knowledge of having bounced when learning Rust. While this is an obvious effect of soliciting answers to our survey and opportunities to interview through Rust channels and our networks, this cohort is good future candidate where interviews could start.

Conclusions

Across these conversations, the experience of learning Rust depended heavily on context. Why someone was learning and what support they had mattered as much as the borrow checker. The same kinds of examples kept coming up: a training course that got a team to a shared baseline, a maintainer answering a student's first GitHub issue, and a colleague whose code showed that cloning was okay.

That context is largely something the community has a hand in. With that in mind, here is what we take away from what we heard, and what we still don't know.

What seems worth trying

Learning materials aimed at unlearning. Syntax barely came up when people described their struggles. People struggled with unlearning habits from previous languages, whether OOP structuring from C++ and Java or the instinct to grab a raw pointer to a peripheral. Most of our learning materials teach Rust from first principles, and that works. What we didn't come across is much written for, say, the engineer with ten years of Java who lands on a Rust team after a reorg: material that names the patterns they'll reach for that won't transfer, and shows what to do instead. The professor we spoke with did a version of this in the classroom, leaning on "traits are like interfaces in Java" and saving generics for later in the course, and the students did fine. Something similar could work outside the classroom too.

Put the "clone freely while you're learning" advice somewhere official. Every experienced developer we spoke with gave the same advice, but learners seem to mostly pick it up by accident, like the researcher who happened to see someone else cloning the struct they had been carefully threading lifetimes through. Saying it early in official materials would take some of the steepness out of the curve. The broader version belongs there too: idiomatic Rust doesn't have to mean optimal Rust, especially on a first project.

Diagnostics are already a primary learning resource: several people told us the compiler taught them lifetimes before any documentation did. Diagnostics reach learners right at the moment they're stuck. When writing new ones, it seems worth keeping the confused newcomer in mind alongside the expert, because for a lot of people this is where the learning happens.

Is "the book" actually out of date? Whether or not The Rust Programming Language or other materials are actually behind, a team evaluating Rust looked at its repository, saw unresolved issues and unmerged PRs, and moved on. As more companies evaluate adoption, more people will look at these materials with the same fresh eyes. Visible issue triage and some communication about what's current and what's planned would address the perception, separately from whatever content work may or may not be needed.

How stuck learners get treated is shaping who stays. We heard about students getting answers on GitHub from the maintainers who wrote the code, and we heard about learners being told their struggles were a skill issue. The first group came away with a lasting good impression of Rust. Some of the second group walked away entirely, and because they leave quietly, it's easy to underestimate how many of them there are. The welcoming side of the community came up unprompted as a reason people stayed, so we know it makes a difference when we get this right.

Every organization we spoke with described essentially the same ramp-up for bringing a team to Rust. Teams that brought groups of developers to Rust described roughly the same approach: get everyone to a shared baseline with a training course or with The Rust Programming Language and Rustlings, start people on lower-risk tickets, and give them somewhere internal to ask questions. Several organizations also found that hiring developers without Rust experience and ramping them up worked out better than continuing to search for rare expertise in another language. None of this is complicated, and teams weighing adoption don't need to invent a training program from scratch.

What we still don't know

The biggest gap is the people we didn't reach. Nearly everyone we spoke with stuck with Rust long enough to be reachable through Rust channels, so the stories of bouncing off came to us second-hand: a friend who walked away from embedded Rust, colleagues who quietly stopped after the responses they got. As we wrote in our first post, finding people who decided against Rust takes targeted outreach. If the proposed User Research team comes together, talking with learners who bounced would make a good early project, and learning is probably the area where that research would teach us the most.

We also don't know what to make of LLMs as a learning tool yet. They came up as a search engine, as an example generator, and in one organization's case as something that makes training high school graduates into working Rust developers possible. We saw a classroom where the C cohort leaned on LLMs in ways the Rust cohort couldn't, and we don't have an explanation for it. All of this comes from a handful of conversations, so we treat it as a set of leads to follow up on. Given how quickly the tools are changing, it seems better to study this deliberately than to wait and see what folklore develops.

The folks we spoke with showed that people do get there: with enough passes through the materials and enough code written, it eventually clicks. The opportunities above are mostly about making it work for the people who didn't pick Rust on purpose, and for the ones who would have stuck around if their early experience had gone a little differently.

Thanks to Micron for sponsoring this video!

To learn more about High-Bandwidth Memory (HBM), check out: https://www.micron.com/products/memory/hbm

Interested in helping to shape the future of cutting edge memory and storage: https://www.micron.com/about/careers

Modern AI chips don't run on the kind of memory in your gaming PC. They run on something that's literally stacked into a tiny skyscraper, with tens of thousands of microscopic data tunnels drilled through it and a custom silicon motherboard underneath. We sat down with the engineers at Micron to break down how High Bandwidth Memory actually works, why it's the backbone of every serious AI accelerator on the planet, and why your gaming GPU still uses a totally different kind of memory.

Leave a reply with your requests for future episodes.

► SHOP OUR PRODUCTS: https://lttstore.com
► GET A VPN: https://www.piavpn.com/TechQuickie
► GET EXCLUSIVE CONTENT ON FLOATPLANE: https://lmg.gg/lttfloatplane
► SPONSORS, AFFILIATES, AND PARTNERS: https://lmg.gg/partners

The post Malicious RubyGems Wait Five Hours and Detect Sandboxes Before Starting Monero Mining appeared first on Cyber Security News.

Read more →

The post Former DigitalMint negotiator sentenced to 70 months for conspiring with BlackCat ransomware affiliates appeared first on IT Security News.

The rapid adoption of AI shares similarities with the early cloud transition. Organizations moved quickly to adopt new capabilities while still learning how to manage costs, security, and governance.

Moving fast without clear oversight can create new risks. However, unlike the early cloud era, organizations now have emerging frameworks and standards, including NIST AI RMF, OWASP guidance, and ISO resources, to help structure responsible AI adoption.

Will organizations use the lessons learned from cloud adoption to build better AI governance, or will they repeat the same challenges?

Subscribe to our podcasts: https://securityweekly.com/subscribe

#AIGovernance #CloudSecurity #SecurityWeekly #Cybersecurity #InformationSecurity #AI #InfoSec

The post Why Adding More AI Agents Made Our System Slower appeared first on Towards Data Science.

Read more of this story at Slashdot.

This Week in Rust is openly developed on GitHub and archives can be viewed at this-week-in-rust.org. If you find any errors in this week's issue, please submit a PR.

Want TWIR in your inbox? Subscribe here.

Updates from Rust Community

Official

• Announcing Rust 1.97.1

Newsletters

• The Embedded Rustacean Issue #76

Project/Tooling Updates

• Announcing Topcoat: a framework for building full-stack reactive web apps with Rust
• Syn 3.0.0
• What’s New in RustRover 2026.2
• kobe 0.35.0: readiness gates and cert recycling
• Comhad v0.1.0: a ranger-style tui cyberduck replacement for browsing S3
• Nova v0.2.1: computer-use MCP server
• winit now has comprehensive cross-platform drag-and-drop support, exposing most of the power of the underlying OS APIs
• crimson-crab v0.1.0 - a production-grade Rust SDK for the Claude API (streaming, tool use, prompt caching, batches)
• ferrovec: dependency-light HNSW vector search in Rust, compiled to WebAssembly for private in-browser semantic search
• OrdoFP 0.1.0 released — a functional-programming toolbelt for Rust (HList, GAT type classes, optics, effects, monad transformers)
• Freya 0.4
• buildline: merging cargo and ninja's build profiling into one timeline
• cochlea 0.3.0: melody read-back, MFCC timbre, a master limiter, and MIDI import for the deterministic agent-audio engine
• flodl 0.6.0: multi-host heterogeneous DDP - mismatched GPUs across hosts beat the fastest card alone
• hwatu: a daemon-based WebKitGTK browser for tiling WMs with ~13ms window spawn
• kache 0.11.0: broader compiler coverage and libc-aware keys
• tracing-reload - reload layer without panics
• Introducing OpenTypeless: Voice Input That Actually Works
• Reading a Rust crate's capabilities out of its compiled symbols

Observations/Thoughts

• Battery packs: Let's talk about crates, baby
• Capture Clauses as Effects
• Hardening Rust Code For Production
• Tokio Gives Progress, Not Ordering: Scheduling 1M Tasks
• Rust service hardening and production checklist
• [audio] The Rust Foundation with Rebecca Rumbul, Lori Lorusso, and David Wood, Rust Foundation leadership and board
• [video] Jon Gjengset: Open Source Maintenance 2026-07-18
• [video] Rust Release Changelog - 1.97.0
• [video] Livestream: Rust in Ubuntu

Rust Walkthroughs

• I hash-chained my agent's audit log. Then I found 13 breaks in it — all mine, all benign.
• Two tricky bugs in a Rust daemon
• [video] Backend Concepts in Rust: Securely Managing App Secrets
• [video] Build with Naz - Ep 21: High Performance Flat 2D Arrays in Rust (SIMD, L1 cache)

Crate of the Week

This week's crate is xan, a TUI toolkit to work with CSV files.

Thanks to Simeon H.K. Fitch for the suggestion!

Please submit your suggestions and votes for next week!

Calls for Testing

An important step for RFC implementation is for people to experiment with the implementation and give feedback, especially before stabilization.

If you are a feature implementer and would like your RFC to appear in this list, add a call-for-testing label to your RFC along with a comment providing testing instructions and/or guidance on which aspect(s) of the feature need testing.

No calls for testing were issued this week by Rust, Cargo, Rustup or Rust language RFCs.

Let us know if you would like your feature to be tracked as a part of this list.

Call for Participation; projects and speakers

CFP - Projects

Always wanted to contribute to open-source projects but did not know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started!

Some of these tasks may also have mentors available, visit the task page for more information.

• No Calls for participation were submitted this week.

If you are a Rust project owner and are looking for contributors, please submit tasks here or through a PR to TWiR or by reaching out on Bluesky or Mastodon!

CFP - Events

Are you a new or experienced speaker looking for a place to share something cool? This section highlights events that are being planned and are accepting submissions to join their event as a speaker.

• No Calls for papers or presentations were submitted this week.

If you are an event organizer hoping to expand the reach of your event, please submit a link to the website through a PR to TWiR or by reaching out on Bluesky or Mastodon!

Updates from the Rust Project

576 pull requests were merged in the last week

Compiler

• account for async closures when pointing at lifetime in return type
• comptime inherent impls
• dep_graph: deduplicate task reads with an epoch-filtered index recorder
• eagerly check for ambiguity in macro parsing
• implement #[diagnostic::opaque] attribute to hide backtraces of macros
• shrink ast::Expr64

Library

• add explicit Iterator::count impl for str::EncodeUtf16
• implement bool::toggle
• implement const_binary_search
• implement Debug helpers via Cell
• implement VecDeque::truncate_to_range
• make pin!() more foolproof
• move std::io::BufRead to alloc::io
• move std::io::Read to alloc::io
• move std::io::read_to_string to alloc::io

Cargo

• use PGO for Cargo
• timings: only report units the job queue actually ran
• do not include proc-macro deps in rustc search path args
• include SBOM outputs in fingerprints
• lazily initialize git2 fetch transports

Rustdoc

• fix auto trait normalization env
• use PGO for rustdoc

Clippy

• add block_scrutinee lint
• avoid invalid ref_as_ptr suggestions in const/static initializers
• detect == 0 on unsigned types as a manual_clamp lower bound
• fix if_not_else linting on macro expanded conditions
• fix needless_collect suggests a suggestion that cannot be typed
• non_zero_suggestions: don't lint signed integer div/rem as NonZero
• manual_filter: don't eat comments in the and_then suggestion
• require the use of as _ for indirectly used traits in clippy sources
• rewrite min_ident_chars
• use #[must_use] determination from the compiler

Rust-Analyzer

• avoid index panic when flycheck list is empty
• add capture hints to coroutines
• add handler for E0572
• do not assume array destructuring assignments with rest pattern are constant-sized
• eagerly normalize .await's IntoFuture::Output
• enable auto trait inference
• extract variable preserving whitespace from macro input
• fix coroutines not recording binding owners correctly
• fix crashes in assists due to .unwrap() calls in SyntaxFactory
• fix hir crate leaking bound variables from skipped binders
• fix InferenceContext:identity_args using the wrong DefId
• fix syntax bridge panic when spilting float
• handle enum variants in next-solver generics
• implement lowering of HRTB
• invalid pattern_matching_variant lowering due to recovery
• merge WherePredicate::ForLifetimes into WherePredicate::TypeBound
• only write anon const ty in parent's inference result if it doesn't have its own inference
• panic with a function item and a proc macro item having a duplicate name
• parser to error on macro type bound
• spawn proc-macro servers on requests clearing the client cache
• use quote! inside ast::make::expr_call()
• use Result for the lsp-server Response payload type
• record expressions in types in ExprScope

Rust Compiler Performance Triage

The two most notable changes this week were #159115, which resulted in pretty nice instruction count wins for full incremental builds on several benchmarks, and #159091, which enabled PGO for rustdoc, which makes it ~3-4% faster across the board.

There were two large rollups with tiny performance regressions, which made it difficult to find the offending PRs.

Triage done by @Kobzol. Revision range: 5503df87..d527bc9b

Summary:

2 Regressions, 3 Improvements, 6 Mixed; 4 of them in rollups 34 artifact comparisons made in total

Full report here.

Approved RFCs

Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:

• No RFCs were approved this week.

Final Comment Period

Every week, the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now.

Tracking Issues & PRs

• Tracking Issue for bool::toggle
• Tracking Issue for vec_try_remove
• Avoid computing layout of enums with non-int discriminants
• Tracking Issue for const_btree_len
• Add raw_borrows_via_references lint
• stabilize size_of_val_raw, align_of_val_raw, Layout::for_value_raw
• rustc_passes: lint unused #[path] attributes on inline modules

• Emit note when calling rustc without specifying an edition
• Let the OS handle stack growth
• Add target_feature_available_at_call_site

• Deallocate post-2026 funds from PM and compiler-ops

• Do the bytes of a pointer have to stay in the same order?

No Items entered Final Comment Period this week for Cargo, Language Reference, Language Team or Rust RFCs.

Let us know if you would like your PRs, Tracking Issues or RFCs to be tracked as a part of this list.

New and Updated RFCs

• RFC: Refactor the libs team

Upcoming Events

Rusty Events between 2026-07-22 - 2026-08-19 🦀

Virtual

• 2026-07-24 | Virtual (Girona, ES) | Rust Girona
  • Sessió setmanal de codificació / Weekly coding session
• 2026-07-28 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Fourth Tuesday
• 2026-07-28 | Virtual (Washington, DC, US) | Rust DC
  • Mid-month Rustful
• 2026-07-30 | Virtual (Berlin, DE) | Rust Berlin
  • Rust Hack and Learn
• 2026-07-31 | Virtual (Girona, ES) | Rust Girona
  • Sessió setmanal de codificació / Weekly coding session
• 2026-08-01 | Virtual (Kampala, UG) | Rust Circle Meetup
  • Rust Circle Meetup
• 2026-08-02 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Rust Deep Learning: First Sunday
• 2026-08-04 | Virtual (London, UK) | Women in Rust
  • 👋 Community Catch Up
• 2026-08-05 | Virtual (Indianapolis, IN, US) | Indy Rust
  • Indy.rs - with Social Distancing
• 2026-08-07 | Virtual (Girona, ES) | Rust Girona
  • Sessió setmanal de codificació / Weekly coding session
• 2026-08-11 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
  • Second Tuesday
• 2026-08-13 | Virtual (Berlin, DE) | Rust Berlin
  • Rust Hack and Learn
• 2026-08-13 | Virtual (Nürnberg, DE) | Rust Nuremberg
  • Rust Nürnberg online
• 2026-08-14 | Virtual (Girona, ES) | Rust Girona
  • Sessió setmanal de codificació / Weekly coding session
• 2026-08-18 | Virtual (Washington, DC, US) | Rust DC
  • Mid-month Rustful
• 2026-08-19 | Hybrid (Vancouver, BC, CA) | Vancouver Rust
  • Dealing with Dependencies

Africa

• 2026-08-11 | Johannesburg, ZA | Johannesburg Rust Meetup
  • Rust's extended standard library

Asia

• 2026-07-25 | Mumbai, IN | Rust Mumbai
  • ​Rust Mumbai — July Meetup 🦀
• 2026-07-26 | Pune, IN | Rust Pune
  • Rust Pune: July 2026

Europe

• 2026-07-23 | Berlin, DE | Rust Berlin
  • Rust Berlin Talks: The next generation
• 2026-07-23 | London, UK | Rust London User Group
  • LDN Talks: July 2026 Antithesis Takeover
• 2026-07-23 | London, UK | London Rust Project Group
  • Rama modular service framework for Rust
• 2026-07-23 | Paris, FR | Rust Paris
  • Rust meetup #87
• 2026-07-25 | Stockholm, SE | Stockholm Rust
  • Ferris' Fika Forum #28
• 2026-07-27 | Augsburg, DE | Rust Meetup Augsburg
  • Rust Meetup #20: Julian Dickert - Supply chain security in Rust: Evaluating crates for production
• 2026-07-29 | Poland, PL | Rust Poland
  • Rust Poland x Kraków #10
• 2026-07-30 | Copenhagen, DK | Copenhagen Rust Community
  • Rust meetup #70
• 2026-07-30 | Manchester, UK | Rust Manchester
  • Rust Manchester July Code Night
• 2026-08-18 | Aarhus, DK | Rust Aarhus
  • Hack Night: Trust but verify the LLM
• 2026-08-18 | Leipzig, DE | Rust - Modern Systems Programming in Leipzig
  • Topic TBD

North America

• 2026-07-22 | Austin, TX, US | Rust ATX
  • Rust Lunch - Fareground
• 2026-07-22 | Los Angeles, CA, US | Rust Los Angeles
  • Rust LA: Rust in Distributed Systems with Flight Science!
• 2026-07-22 | New York, NY, US | Rust NYC
  • Rust NYC: Write A Custom Coding Agent and wasm_zero
• 2026-07-23 | Mountain View, CA, US | Hacker Dojo
  • RUST MEETUP at HACKER DOJO
• 2026-07-25 | Boston, MA, US | Boston Rust Meetup
  • Porter Square Rust Lunch, July 25
• 2026-07-25 | Brooklyn, NY, US | Flower
  • BOG-A-THON 2
• 2026-07-30 | Atlanta, GA, US | Rust Atlanta
  • Rust-Atl
• 2026-08-01 | Boston, MA, US | Boston Rust Meetup
  • Chinatown Rust Lunch, Aug 1
• 2026-08-04 | Boston, MA, US | Boston Rust Meetup
  • Evening Boston Rust Meetup at Red Hat, Aug 4
• 2026-08-06 | Saint Louis, MO, US | STL Rust
  • Shipping Temporal: How a Global Rust Ecosystem Built Chrome’s Newest Web API
• 2026-08-13 | Lehi, UT, US | Utah Rust
  • Utah Rust August Meetup
• 2026-08-13 | San Diego, CA, US | San Diego Rust
  • San Diego Rust August Meetup - Back in person!
• 2026-08-15 | San Francisco, CA, US | Flower
  • BOG-A-THON 3
• 2026-08-18 | San Francisco, CA, US | San Francisco Rust Study Group
  • Rust Hacking in Person
• 2026-08-19 | Hybrid (Vancouver, BC, CA) | Vancouver Rust
  • Dealing with Dependencies

Oceania

• 2026-07-23 | Perth, AU | Rust Perth Meetup Group
  • Rust Perth: July Meetup!
• 2026-07-30 | Melbourne, AU | Rust Melbourne
  • Rust Melbourne July 2026

South America

• 2026-08-08 | São Paulo, SP | Rust-SP
  • Rust SP - Aug/2026

If you are running a Rust event please add it to the calendar to get it mentioned here. Please remember to add a link to the event too. Email the Rust Community Team for access.

Jobs

Please see the latest Who's Hiring thread on r/rust

Quote of the Week

We were planning on publishing a blog post announcing this at the same time as making the repo public, but ran out of private repo CI usage 😭.

– Carl Lerche on r/rust about the launch of topcoat

Despite a lamentable lack of suggestions, llogiq is glad to have found this quote.

Please submit quotes and vote for next week!

This Week in Rust is edited by:

• nellshamrell
• llogiq
• ericseppanen
• extrawurst
• U007D
• mariannegoldin
• bdillo
• opeolluwa
• bnchi
• KannanPalani57
• tzilist

Email list hosting is sponsored by The Rust Foundation

Discuss on r/rust

In the lab we’re going to build today, we’ll talk about JWTs and how they can affect the security of your website. This is a lab that’s been requested, and I could not be happier that the community is actually suggesting things for me to build. It’s a privilege to do this.

JWT As Security Measure

JSON Web Tokens are used a lot by developers. They provide a way to send ‘data’ with them (e.g., a role from a user), to check for authorization. A JWT consists of 3 parts, separated by a ..

Let’s take this JWT as an example.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTUxNjIzOTAyMn0.KMUFsIDTnFmyG3nMiGM6H9FNFUROf3wh7SmqJp-QV30

The first part eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 is called 'the header'. It holds information on the type of the JWT. The second part eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTUxNjIzOTAyMn0 is the payload, which holds the claims. This is where that 'data' lives. If you decode this with Base64url you'll learn that this token belongs to John Doe and that he is an administrator. The last part is the important part. This is the signature. Each JWT should be signed with a strong password. Ideally that password is saved in a .env file on the server and not in the code.

So now you might wonder, well if it’s signed, nothing can go wrong right? Well, if that were true, I wouldn’t spend my evenings writing these kinds of blog posts now would I 😅.

Let’s Build The Lab Already

You’re right to think this by now. Enough theory, let’s do some hands on keyboard. As always in this series, I’ll provide you with the lab structure and some code to get us started.

Lab Tree

/mediumLabs
└── /JWT
    ├── server.js
    ├── login.html
    ├── index.html
    ├── admin.html
    ├── /node_modules
    ├── /package-lock.json
    └── /package.json

Code

server.js

const express = require('express');
const jwt = require('jsonwebtoken');
const path = require('path');
const Database = require('better-sqlite3');
const app = express();
const JWT_SECRET = 'secret';
const db = new Database(':memory:');
db.exec(`
  CREATE TABLE users (
    id INTEGER PRIMARY KEY,
    username TEXT,
    password TEXT,
    role TEXT
  )
`);
db.prepare("INSERT INTO users (username, password, role) VALUES ('user', 'password', 'user')").run();
app.use(express.urlencoded({ extended: false }));

app.get('/', (req, res) => res.sendFile(path.join(__dirname, 'login.html')));
function getToken(req) {
  const match = (req.headers.cookie || '').match(/token=([^;]+)/);
  return match ? match[1] : null;
}
app.post('/login', (req, res) => {
  const { username, password } = req.body;
  const user = db.prepare('SELECT * FROM users WHERE username = ? AND password = ?').get(username, password);
  if (!user) return res.redirect('/?error=Invalid+credentials');
  const token = jwt.sign({ username: user.username, role: user.role }, JWT_SECRET);
  res.setHeader('Set-Cookie', `token=${token}; Path=/`);
  res.redirect('/index.html');
});
app.get('/index.html', (req, res) => {
  try {
    res.sendFile(path.join(__dirname, 'index.html'));
  } catch {
    res.redirect('/');
  }
});
app.get('/admin', (req, res) => {
});

app.listen(3000, () => console.log('Listening on http://localhost:3000'));

login.html

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Login</title>
</head>
<body>
    <h1>Login</h1>
    <form method="POST" action="/login">
        <div>
            <label>Username: <input type="text" name="username" required></label>
        </div>
        <div>
            <label>Password: <input type="password" name="password" required></label>
        </div>
        <button type="submit">Login</button>
    </form>
</body>
</html>

index.html

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Home</title>
</head>
<body>
    <h1>Welcome!</h1>
    <p>You are logged in as <strong id="username"></strong>.</p>
    <p><a href="/admin">Go to Admin Panel</a></p>
    <br>
<script>
        function getCookie(name) {
            return document.cookie.split('; ').find(r => r.startsWith(name + '='))?.split('=')[1];
        }
        function decodeJWT(token) {
            return JSON.parse(atob(token.split('.')[1]));
        }
        const token = getCookie('token');
        const payload = decodeJWT(token);
        document.getElementById('username').textContent = payload.username + ' (role: ' + payload.role + ')';
    </script>
</body>
</html>

admin.html

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Admin Panel</title>
</head>
<body id="page">
<h1>Admin Panel</h1>
    <p>Welcome, admin. Here is the secret flag:</p>
    <p><strong>FLAG{JWT}</strong></p>
    <br>
    <a href="/index.html">Back to Home</a>
</body>
    <script>
        function getCookie(name) {
            return document.cookie.split('; ').find(r => r.startsWith(name + '='))?.split('=')[1];
        }
        function decodeJWT(token) {
            return JSON.parse(atob(token.split('.')[1]));
        }
        const token = getCookie('token');
        const payload = decodeJWT(token);
        if (payload.role !== 'admin') {
            alert('Access denied. You need to be an admin to view this page.');
        }
    </script>
</html>

Let’s Add Some Vulnerabilities

Ok, so now we have our base code, and we need to implement the functionality that will make sure only people with the role admin can navigate to /admin. First off, run npm run dev to see your code actually start.

In a very, very wrong way we already tried implementing security in admin.html. When you look inside the <script> tags, you'll see that if the role is not admin, an alert will pop up. I added this because this was a real-life finding of mine. Some developer did not realise that even if your role isn't admin, you will be able to navigate to the page. The only 'annoying' thing is that you'll have to click OK on an alert box.

It’s important to realise that these mistakes happen more often than you think. Developers with a lot on their plate, little sleep and not enough coffee can truly believe this is ‘secure’.

So let’s now add some real security to the backend! Frontend ‘security’ is ridiculous to start with, so let’s do our very best.

server.js

app.get('/admin', (req, res) => {
  const token = getToken(req);
  if (!token) return res.redirect('/');
  const payload = jwt.decode(token);
  if (!payload || payload.role !== 'admin') return res.status(403).send('Forbidden');
  res.sendFile(path.join(__dirname, 'admin.html'));
});

Alright, let’s walk through this piece of code. First we look for the token — if there isn’t one, we redirect to /, which is a good strategy. Then we decode the JWT and check if the role is admin. If there's no token, or the role isn't admin, we get a 403.

Sounds solid, right? If everything checks out, the backend trusts you, because the token says you’re an admin.

So what’s the problem? The code does check if the role is admin, which is good. But it never checks whether that role actually belongs to you. That check should happen by verifying the JWT’s signature. This code doesn’t, because jwt.decode() only reads the payload, it doesn't verify anything. When the server originally signed this token, it signed it with role: user. If you change the payload to role: admin without re-signing it, the signature no longer matches what's in the token, but since nothing here checks the signature, that mismatch goes completely unnoticed.

That’s the bug: because that check never happens, we can just change the payload in Burp Suite and see the admin page.

There is a very easy way to solve this though. Instead of using jwt.decode(token) a developer should always use jwt.verify(token, JWT_SECRET). This code makes sure that function will create a signature and check that signature with the signature that has been sent. If there was any tampering with the JWT, this signature won't check out and your access to the restricted endpoint is denied.

So let’s update our code.

server.js

app.get('/admin', (req, res) => {
  try {
    const payload = jwt.verify(getToken(req), JWT_SECRET);
    if (payload.role !== 'admin') return res.status(403).send('Forbidden');
    res.sendFile(path.join(__dirname, 'admin.html'));
  } catch {
    res.redirect('/');
  }
});

If you now try the same thing, you’ll end up in the catch block, which will redirect you to / (our login page) because the signature will not check out.

So all safe now, right? Well let’s try something else… If you ever want to crack a secret, I can recommend hashcat. It's available on all platforms and easily installable.

For this attack we’ll need mode 16500 (this is just a way to tell hashcat what we want to do). We'll also need the flag -a 0, which will tell hashcat to use a wordlist we're gonna provide. Lastly, you'll see -d 1 — that's because I'm on a Mac with an M-chip.

The complete command looks like this: hashcat -m 16500 -a 0 <JWT> rockyou.txt -d1.

Don’t forget to use the untampered token for this!

➜  wordlists hashcat -m 16500 -a 0 eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6InVzZXIiLCJyb2xlIjoidXNlciIsImlhdCI6MTc4MzEwNDc0OX0.myFrub4u8yG3IeItDYKO-2Vci6sMfLaJ1OrlQDeuQfc rockyou.txt -d1
hashcat (v7.1.2) starting
<skip>
Dictionary cache hit:
* Filename..: rockyou.txt
* Passwords.: 14344384
* Bytes.....: 139921497
* Keyspace..: 14344384
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6InVzZXIiLCJyb2xlIjoidXNlciIsImlhdCI6MTc4MzEwNDc0OX0.myFrub4u8yG3IeItDYKO-2Vci6sMfLaJ1OrlQDeuQfc:secret
                                                          
Session..........: hashcat
Status...........: Cracked
Hash.Mode........: 16500 (JWT (JSON Web Token))
Hash.Target......: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZS...DeuQfc

As you can see, at the end of our JWT there is a colon with our JWT_SECRET written behind it.

Now let’s abuse this knowledge we have gained. In Burp Suite we’ll use functionality that will sign our tampered JWT so that the code will verify it, and the signature will check out.

In Burp Suite, click on the JWT editor on the top right corner, and choose the option ‘New Symmetric Key’. Once you have that, click specify secret and fill in the cracked JWT_SECRET in there. Give it an ID and click OK.

Once you have that, go back to Repeater, change the role back to ‘admin’, click sign and select the ID you just made.

And now, we have successfully evaded the security that was in place.

Lessons We Should Learn About This

As you saw, correctly implementing a JWT is only the first step of coding securely. Having a strong password policy, even when it’s not really enforceable, is very important. Don’t use ‘secret’ as your JWT_SECRET

One thing I already mentioned, but what I want to stress again is NEVER EVER store your JWT secret as a hardcoded variable, like we did with JWT_SECRET = 'secret'. Your code will probably live on GitHub where all kinds of stupid things can happen. A secret belongs in a .env file that is in your .gitignore and lives only on your dev machine and on the server, NOT in your code.

I break web apps for fun, make vulnerable labs to learn, and write about it so you can too.

Two Ways To Mess Up Your JWT Safety Net In Your Own Lab. was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.

Read more →

The post Malicious NuGet Typosquat Targets Digitain Betting Platform and Rigs Game Results appeared first on IT Security News.

The post Malicious NuGet Typosquat Targets Digitain Betting Platform and Rigs Game Results appeared first on GBHackers Security | #1 Globally Trusted Cyber Security News Platform.

The post A Single Extra “t” in a NuGet Package Allow Attackers to Manipulate Results appeared first on Cyber Security News.

It took me a while to realise what the man sitting next to me on the train was doing. He was flicking through pictures of a little girl on his phone; zooming in on some, cropping the images. Hardly unusual, of course, except that on closer inspection the pictures were very clearly of the toddler sitting opposite us, playing with her parents. On a crowded train of people mostly staring obliviously at our own phones, a stranger had been covertly photographing that little girl over and over again. And if it hadn’t been for that very visible phone screen giving him away, he wouldn’t have been caught.

That encounter was a while ago but my memory was jogged last week listening to a clip of Meta’s VP of wearables, Alex Himel, talk fondly to the BBC about using his new smartglasses to film his daughter singing in a talent contest. They let him capture the memory without having to watch her through a screen, he said, freeing him to be “kind of living in the moment, head up and hands free”. So far, so sweet. But what about the risk of creeps potentially using them to film other people’s daughters covertly, heads up and hands free? Meta’s smartglasses have a tiny flashing warning light on the frame to indicate when the wearer is recording, but the technology is still new enough that many people don’t think to look for it. And in the age of AI, stolen images of children matter. Taken in real life or scraped from the internet, they’re the raw material for generating realistic-looking child abuse material of the most extreme and disturbing kind. (If that sounds like a grim but ultimately fairly victimless crime, the Internet Watch Foundation warned in a recent report that AI-generated material risks fuelling sexual interest in children, normalising violence and increasing the risk of real-life offending.)

Gaby Hinsliff is a Guardian columnist

Do you have an opinion on the issues raised in this article? If you would like to submit a response of up to 300 words by email to be considered for publication in our letters section, please click here.

Read more →

The post Employees’ shadow AI use is poorly monitored, survey finds appeared first on IT Security News.

Die Idee finde ich wirklich spannend und ich denke, dass ich sie einmal ausprobieren werde. Im Kontext des Buchs habe ich mir übrigens vorgenommen, im zweiten Halbjahr jeden Dienstag einen Artikel zu veröffentlichen, aber ich schweife ab.

Öffentliches Lernen hat drei Schritte, und zwar die folgenden:

1. Ein Versprechen abgeben und das öffentlich. Nehmen wir ein Beispiel: Ich werde ab jetzt jeden Tag eine Viertelstunde in Go programmieren.
2. Eine Plattform auswählen, auf der ich das Versprechen öffentlich mache und über meine Fortschritte und Rückschritte berichte.
3. Der letzte Schritt ist Üben und Wiederholen, dabei ist wichtig, das Feedback aus der Community (von der gewählten Plattform) zu berücksichtigen.

⁣Das Ganze ist wirkungsvoll, weil man mit Menschen in Interaktion tritt und von Menschen, die das Lerngebiet besser kennen, Impulse, aber auch Fallstricke aufnehmen kann.

Das braucht selbstverständlich Mut, zum einen zuzugeben, dass man keine Ahnung von etwas hat, und zum anderen, offen mit den eigenen Fehlern umzugehen.

AI is exceptionally good at identifying code patterns that lead to crashes and other common programming mistakes. That capability can dramatically increase the number of reported bugs.

Finding more bugs doesn't necessarily reduce real-world cyber risk. If the proportion of high-impact, exploitable vulnerabilities stays the same, security teams may spend increasing amounts of time triaging and fixing low-value findings simply because they now exist in the backlog. More detection can create more work without delivering proportional security gains.

Should AI-powered security tools be judged by how many bugs they find—or by how many meaningful attacks they actually help prevent?

Subscribe to our podcasts: https://securityweekly.com/subscribe

#AppSec #SecurityWeekly #Cybersecurity #InformationSecurity #AI #InfoSec

Read more →

The post Hackers Are Turning Microsoft 365 Calendar Invites Into Secret Malware Command Channels appeared first on IT Security News.

The post Hackers Are Turning Microsoft 365 Calendar Invites Into Secret Malware Command Channels appeared first on Cyber Security News.

Read more of this story at Slashdot.

Read more of this story at Slashdot.

Read more of this story at Slashdot.

Read more of this story at Slashdot.

Fixed

• Fixed Kimi Code usage reports dropping the 5h window reset time (omp usage showed no "resets in …" for the 5h limit): the API returns resetTime on the limit detail, not on window, so the parsed row-level reset is now carried onto the window when the window itself has none.
• Made Kimi device-id persistence best-effort: a missing or unwritable ~/.omp/agent directory no longer throws during Kimi header construction, which silently nulled every kimi-code usage probe on fresh installs.
• Coerced boolean tool-schema subschemas to MFJS object forms for native Moonshot/Kimi endpoints, preventing the task tool's outputSchema field from causing HTTP 400 responses (#5952).

@oh-my-pi/pi-catalog

Changed

• Kimi-family models now use MFJS tool schema on all hosts, including proxies like OpenRouter that forward schemas to Moonshot

@oh-my-pi/pi-coding-agent

Fixed

• Fixed bundled Linux ffmpeg recording by selecting its available ALSA input when PulseAudio support is absent, and surfaced recorder stderr when capture fails (#5907).
• Session load now skips the recursive async blob-ref resolver for entries with no blob:sha256: references. A cheap synchronous precheck gates the walk per entry (preserving the previous per-entry initiation order under synchronous store mutation), so text-heavy histories no longer pay the Promise.all tree descent for every non-session entry (#5922).
• Fixed task tool schemas emitting boolean subschemas that llama.cpp grammar generation cannot parse (#5957).
• Fixed the transcript keeping finalized assistant blocks in the live compose walk after their rows entered native terminal scrollback, making each stream tick's TranscriptContainer.render depth-linear in session length. Fully committed finalized blocks are now compacted out of the local frame regardless of post-finalize version tracking; a later mutation no longer recommits on ordinary frames (no duplication) and rehydrates on the next destructive full replay (no loss). Compose cost for a live tail tick is now flat as depth grows (bench/transcript-compose.bench.ts: ratio(N5000/N500) 2.30 → 0.90) (#5930).
• Fixed /quit and /exit hanging during interactive shutdown by making the mnemopi dispose path retain the current session and flush in-flight extractions without sleeping the bank; the /memory enqueue path and end-of-session backend enqueue still perform full cross-session consolidation. (#3641)

@oh-my-pi/hashline

Fixed

• Rejected DEL N: headers with a trailing colon instead of silently tolerating the colon, so delete-with-body mistakes surface the corrective "has no colon" guidance.

@oh-my-pi/pi-mnemopi

Fixed

• Fixed a corrupt cached embedding model (truncated model_optimized.onnx, Protobuf parsing failed on load) permanently disabling local embeddings: init now quarantines the broken cache file (rename to *.corrupt-<ts>, only when the path resolves inside the fastembed cache directory) and retries once so the model re-downloads.

What's Changed

• fix(mnemopi): self-heal a corrupt cached embedding model on init by @DarkPhilosophy in #5923
• perf(session): gate blob-ref resolution behind synchronous precheck by @roboomp in #5925
• fix(task): avoid boolean output schema subschemas by @roboomp in #5958
• fix(stt): select a supported Linux ffmpeg input by @roboomp in #5909
• fix(tui): compact committed finalized transcript history by @roboomp in #5943
• fix(ai): normalize boolean tool schemas for Moonshot by @roboomp in #5955
• fix(kimi): surface the 5h usage window reset time by @iacore in #5953
• fix(mnemopi): lighter dispose consolidation so /quit returns quickly by @iacore in #4843

New Contributors

• @iacore made their first contribution in #5953

Full Changelog: v17.0.3...v17.0.4

Read more of this story at Slashdot.

Imagine if every time you left the house, you couldn’t be sure that the stranger you met at a bar – or even the person walking by you in the street – wasn’t secretly recording you. It sounds like something out of a Black Mirror episode, but let’s face it, the era of wearable technology is fully upon us as everyday accessories have been developed to help track health and fitness data, receive smartphone notifications, and provide hands-free accessibility.

So when Meta announced their AI glasses a few years ago, it wasn’t too surprising that one of the biggest (and most embattled) tech companies on earth had begun cashing in on our obsession with watching others. And their AI glasses have already raised serious concerns over privacy, personal safety and even our sense of agency.

The release, timed to land just ahead of the 2026 World Artificial Intelligence Conference in Shanghai, is a dramatic escalation in the global AI arms race and a watershed moment for the open-source AI movement. It also marks a remarkable comeback for a company whose market position had eroded significantly over the past 18 months following DeepSeek's meteoric rise.

Full model weights are scheduled to be released on July 27, according to details shared by researchers who reviewed the company's technical documentation. If you want to take Kimi K3 for a spin right now, you can — just head to kimi.com, sign up with a Google account or phone number (no credit card required), and start chatting with what may be the most powerful open-source model ever built.

Inside the architecture that powers the world's largest open-source AI model

Kimi K3 is a frontier-class large language model with 2.8 trillion total parameters — roughly 75 percent larger than DeepSeek's V4 Pro, which the company's own timeline chart shows at approximately 1.6 trillion parameters. The model features a 1-million-token context window, native visual understanding capabilities, and an always-on reasoning mode that the company calls "thinking mode."

The model is built on two key architectural innovations developed internally at Moonshot AI: Kimi Delta Attention, a hybrid linear attention mechanism, and Attention Residuals, which the company describes as a drop-in replacement for residual connections that delivers consistent scaling gains. Both techniques were previously published as open research by the Moonshot team on GitHub.

On the API side, Kimi K3 is compatible with the OpenAI SDK, lowering the integration barrier for developers already building on OpenAI or Anthropic toolchains. The model is priced at $3 per million input tokens and $15 per million output tokens, with cached input tokens dropping to just $0.30 per million — pricing that positions it roughly in line with mid-tier offerings from Western labs, but at a performance level the company claims approaches the top of the market. A promotional top-up rebate running through August 12 offers up to 30 percent back in vouchers for API credits of $1,000 or more.

As Xinhua reported, a Moonshot AI executive explained the significance of the parameter count in simple terms: parameters are like neural connections in the human brain, and nearly 3 trillion of them means the model can "store more knowledge and patterns in its brain, understand more, think deeper, and answer more accurately."

Benchmark results show Kimi K3 trading blows with Claude and GPT at the top of the leaderboard

The benchmark results, drawn from public leaderboard data and a private evaluation by analytics firm Artificial Analysis, tell a striking story.

On GDPval-AA v2, a benchmark measuring real-world tasks across 44 occupations and 9 major industries, Kimi K3 scored 1,687 — placing it third overall, behind only Claude Fable 5 Max (1,815) and GPT-5.6 Sol Max (1,747.8), and ahead of Claude Opus 4.8 (1,600).

On AA-Briefcase, a private agentic benchmark from Artificial Analysis designed to test long-horizon knowledge work, K3 climbed to second place with a score of 1,527 — beating GPT-5.6 Sol Max (1,495) and trailing only Fable 5 Max (1,587).

Perhaps most impressively, K3 achieved a state-of-the-art score of 91.2 out of 100 on BrowseComp, a benchmark for long-horizon, high-difficulty information seeking.

The company says it accomplished this in a single-agent setup using its 1-million-token context window, without any context compression or additional context management techniques — a feat that suggests raw context length, when paired with strong retrieval capabilities, may be more powerful than elaborate multi-agent workarounds.

As one widely followed AI commentator put it on social media: "Open source is no longer lagging six months behind Western closed-source models. Read that again, and think about what it all means."

That observation captures the significance of the moment. For much of the past three years, open-source models have typically trailed their proprietary counterparts by a meaningful margin. Kimi K3 appears to have closed that gap almost entirely.

How a 48-hour autonomous chip design demo reveals Moonshot's real ambitions

Beyond raw benchmarks, Moonshot AI showcased a proof-of-concept that may be even more revealing of K3's capabilities and the company's strategic direction.

In a demonstration documented in the company's technical materials, Kimi K3 was tasked with designing a physical chip to run a nano-scale version of itself. Over 48 hours of continuous autonomous agent operation, K3 independently completed the chip's full construction pipeline — from architectural design through optimization and verification — using open-source electronic design automation tools. The result was a tiny but functional chip design, just 4 square millimeters, that achieved timing convergence at 100 MHz and could decode more than 8,700 tokens per second in simulation.

This is not a production chip. It is a demonstration of what Moonshot AI clearly views as the next competitive frontier: long-range autonomous agent capabilities. The ability to sustain coherent, multi-step technical work over a 48-hour window — reading documentation, making design decisions, running verification loops, and iterating on failures — represents a qualitative leap beyond the kind of single-turn question-answering that defined the first generation of large language models.

The company also highlighted a case in computational astrophysics, where K3 reportedly reproduced the universal I-Love-Q relation — a complex calculation that typically takes a senior researcher one to two weeks — in approximately two hours, reading and cross-validating more than 20 papers and implementing a complete numerical pipeline along the way.

Moonshot AI's fall and rise tells the story of China's brutal AI market

To understand why Kimi K3 matters, you need to understand where Moonshot AI was 18 months ago — and how far it fell.

Founded in 2023 by Yang Zhilin, a Tsinghua University graduate who previously conducted research at Google and Meta, Moonshot AI quickly became one of China's most prominent AI startups. The company gained early traction in 2024 when users flocked to its Kimi platform for its long-text analysis capabilities and AI search functions. By early 2026, it had raised roughly $1.5 billion across multiple rounds, with its valuation climbing from $2.5 billion to $4.3 billion and the company reportedly seeking a new round at $5 billion.

Then DeepSeek happened. The release of DeepSeek's low-cost R1 model in January 2025 disrupted the entire Chinese AI landscape, and Moonshot AI was among the hardest hit. Kimi, which had ranked third in monthly active users in China, slid to seventh. The company's strategic pivot to open-source models — beginning with Kimi K2 in July 2025 and accelerating with K2.5 in January 2026 — was in large part an effort to reclaim relevance.

Kimi K3 is the culmination of that effort — and the sheer scale of the model suggests that Moonshot AI has been planning this move for some time. Training a 2.8-trillion-parameter model requires enormous computational resources and months of preparation, which means the architectural and infrastructure decisions behind K3 were likely locked in well before the model reached the public.

Why open-sourcing the world's biggest model is a geopolitical chess move

The decision to release K3's full weights on July 27 is strategically significant and worth parsing carefully.

The company's own timeline chart of open-source frontier model scale positions K3 as a dramatic outlier, towering above competitors like DeepSeek (1.6T), Xiaomi (1.02T), and Alibaba (397B). By releasing the world's largest open-source model, Moonshot AI is making a bid to become the center of gravity for the global open-source AI developer community.

This follows a broader trend among Chinese AI companies. As Reuters noted, open-sourcing allows companies to "showcase their technological capabilities and expand developer communities as well as their global influence, a strategy likely to help China counter U.S. efforts to limit Beijing's tech progress." DeepSeek, Alibaba, Tencent, and Baidu have all released open-source models. But none have released anything at this parameter count.

For enterprise technology leaders, the implications are concrete. A 2.8-trillion-parameter open-source model that performs at near-frontier levels creates new options for companies that want to fine-tune, self-host, or build proprietary systems on top of a capable base model — without being locked into API contracts with OpenAI or Anthropic. The trade-off, of course, is that running a model of this size requires substantial GPU infrastructure. Inference at 2.8 trillion parameters is not something that runs on a single server rack.

That said, Moonshot AI has signaled awareness of this challenge. Its Mooncake project, which won the Best Paper award at FAST 2025, pioneered KV-cache-centric disaggregated serving for large language models — an architecture designed specifically to make inference at extreme scale more practical and cost-efficient.

Kimi Code and a three-tier model lineup form the foundation of Moonshot's enterprise play

Alongside K3, Moonshot AI continues to invest heavily in its coding agent ecosystem. Kimi Code, the company's open-source coding tool that competes with Anthropic's Claude Code and Google's Gemini CLI, received two major updates on the same day as K3's launch — versions 0.25.0 and 0.26.0 — adding features like expanded subagent tooling, background task management, and security fixes.

The Kimi Code CLI has accumulated over 3,100 stars on GitHub and features integration with VSCode, Cursor, and Zed. The latest release expanded the "coder subagent" tool set to include background tasks, todo lists, plan mode, skill invocation, and nested agents — effectively turning the coding agent into a multi-layered autonomous system capable of managing complex software engineering projects with minimal human intervention.

This is not incidental. Coding tools have become a critical revenue driver for AI labs. As Anthropic disclosed in January, Claude Code reached $1 billion in annualized recurring revenue. By building Kimi Code as an open-source alternative that defaults to Kimi's own models — but supports other providers — Moonshot AI is positioning itself to capture developer workflows and, eventually, enterprise contracts.

The company's model lineup now includes three tiers: K3 as the flagship ($3/$15 per million tokens for input/output), K2.7 Code as a specialized coding model ($0.95/$4), and K2.6 as a general-purpose option ($0.95/$4). All three support context windows of 256,000 tokens or above, with K3 offering the full 1-million-token window. Context caching is automatic — no cache ID, TTL, or extra parameter is required — a small but meaningful developer-experience advantage over competitors that require explicit cache management.

What Kimi K3 means for the future of enterprise AI and the global model landscape

Kimi K3's release forces a recalibration of several assumptions that have guided enterprise AI strategy.

The performance gap between open-source and proprietary models has functionally closed at the frontier. If K3's benchmark numbers hold up under independent evaluation — and particularly once the open weights are available for community testing on July 27 — it will be difficult for closed-source providers to justify premium pricing purely on the basis of capability.

The locus of AI innovation, meanwhile, continues to shift. China's AI ecosystem, which many Western observers questioned after early struggles with chip export restrictions, has now produced a model that competes with the best systems from companies with direct access to Nvidia's most advanced hardware. The architectural innovations behind K3 — particularly the hybrid linear attention mechanism — suggest that algorithmic efficiency may matter as much as raw compute.

And the agentic capabilities demonstrated by K3 — chip design, multi-week research compression, long-horizon information seeking — point toward a future where AI models are not just answering questions but autonomously executing complex, multi-day projects. For enterprises evaluating AI investments, this shifts the value proposition from "productivity copilot" to "autonomous technical workforce."

Xinhua, China's state news agency, framed the release as a national milestone, reporting that K3 "marks a new step forward in the development of China's artificial intelligence models." Liu Tieyan, dean of the Zhongguancun Academy in Beijing, was quoted as saying that a wave of Chinese open-source models has moved from isolated breakthroughs to collective advancement, providing "new solutions and new paths" for global AI development.

Just two years ago, Moonshot AI was a scrappy startup named for the audacious problems it hoped to solve. Eighteen months ago, it was a cautionary tale about how quickly a market darling can lose its footing. Today, it is the maker of the world's largest open-source AI model — one that can, given 48 hours and an internet connection, design a chip to run itself. The frontier, it turns out, is not a place. It is a race. And the field just got a lot more crowded.

Apple's AirPods dodged a possible redesign as the EU exempts wireless earbuds from new battery rules aimed at reducing waste.

(via Cult of Mac - Your source for the latest Apple news, rumors, analysis, reviews, how-tos and deals.)

Read more of this story at Slashdot.

💧 Liquid cooling sounds intimidating... but it's actually one of the easiest parts of a modern PC build!

In this episode of my PC Build Series, I'll walk you through installing an ASUS ROG Ryujin III ARGB Extreme AIO cooler onto an AMD Ryzen 9 9950X system. We'll cover what an AIO actually is, why CPUs need cooling, proper airflow, radiator placement, thermal paste, fan orientation, pump installation, and how to connect everything correctly.

Whether you're building your very first PC or just want to avoid common mistakes, this guide will help make liquid cooling a whole lot less scary.

Support the channel!
❤️ Patreon: https://patreon.com/shannonmorse
⭐ Become a YouTube Member!

#PCBuild #PCBuilding #CustomPC #LiquidCooling #AIO #ASUSROG #AMD #Ryzen9950X #GamingPC #TechTutorial

https://www.ifixit.com/products/pro-tech-toolkit
My build: https://pcpartpicker.com/user/snubsie/saved/#view=Htk84D

📺
Watch the Full PC Build Series: https://www.youtube.com/playlist?list=PLeYHKbaShxTHQVUHZfM8_44pjyI9LLzfe

* Parts List (and best deals!) // Affiliate links:
- Prices may differ
CPU: AMD Ryzen 9 9950X 4.3 GHz 16-Core Processor ($519.00 @ Amazon)
Amazon: https://amzn.to/3O70PIU
Best Buy: https://bestbuycreators.7tiv.net/YRWkZq
B&H: https://bhpho.to/3PjZZcr

CPU Cooler: Asus ROG Ryujin III ARGB Extreme 89.73 CFM Liquid CPU Cooler ($389.99 @ Amazon)
Amazon: https://amzn.to/4bkdodD
Best Buy: (similar option) https://bestbuycreators.7tiv.net/DyDM4q
B&H: https://bhpho.to/46EWdR4

Motherboard: Asus ROG STRIX X870-A GAMING WIFI ATX AM5 Motherboard ($234.99 @ Amazon)
Amazon: https://amzn.to/3NI9tO0
Best Buy: (similar option) https://bestbuycreators.7tiv.net/bORgn6
B&H: https://bhpho.to/4ubyfa7

Memory: Kingston FURY Beast RGB 64 GB (2 x 32 GB) DDR5-6400 CL32 Memory ($1359.99 @ Newegg - OOS) x 2
Amazon: https://amzn.to/49SZug7
Best Buy: (similar option) https://bestbuycreators.7tiv.net/2anB4G

Storage: Kingston NV3 2 TB M.2-2280 PCIe 4.0 X4 NVME Solid State Drive ($311.99 @ Amazon)
Amazon: https://amzn.to/4bSOyBO
Best Buy: https://bestbuycreators.7tiv.net/vPeg7N
B&H: https://bhpho.to/4bpm9m9

Storage: Kingston FURY Renegade G5 2.048 TB M.2-2280 PCIe 5.0 X4 NVME Solid State Drive ($424.99 @ iBUYPOWER)
Amazon: https://amzn.to/4pTv8QB
Best Buy: https://bestbuycreators.7tiv.net/N9AYrN
B&H: https://bhpho.to/40dqbYK

Video Card: Asus TUF GAMING OC GeForce RTX 5080 16 GB Video Card ($1699.99 @ B&H)
Amazon: https://amzn.to/3NNmKos
Best Buy: https://bestbuycreators.7tiv.net/GKrYLB
B&H: https://bhpho.to/46HyuQb

Case: Asus A31 ATX Mid Tower Case ($64.98 @ Amazon)
Amazon: https://amzn.to/4bTH8yd
Best Buy: (similar option) https://bestbuycreators.7tiv.net/7a3BZO
Newegg: https://click.linksynergy.com/link?id=qn*xL%2FagfY4&offerid=1786142.445837726262477428148556&type=2&murl=https%3A%2F%2Fwww.newegg.com%2Fasus-atx-mid-tower-a31-tg-steel-plastic-tempered-glass-computer-case-white%2Fp%2FN82E16811173067%3Fitem%3DN82E16811173067
B&H: https://bhpho.to/4d3Fyu8

Power Supply: Asus TUF Gaming 1000G 1000 W 80+ Gold Certified Fully Modular ATX Power Supply ($179.99 @ Amazon)
Amazon: https://amzn.to/4qSDWHG
Best Buy: (similar option) https://bestbuycreators.7tiv.net/LKeYQO
Newegg: https://click.linksynergy.com/link?id=qn*xL%2FagfY4&offerid=1786142.445835163683945762036176&type=2&murl=https%3A%2F%2Fwww.newegg.com%2Fasus-atx-3-0-compatible-atx12v-1000-w-80-plus-gold-certified-power-supply-tuf-gaming-1000g%2Fp%2FN82E16817320029%3Fitem%3DN82E16817320029
B&H: https://bhpho.to/3N1pqPq

Case Fan: Asus TUF GAMING TF120 ARGB White 76 CFM 120 mm Fan ($14.99 @ Amazon)
Amazon: https://amzn.to/3YWIbG7
Best Buy: https://bestbuycreators.7tiv.net/QjVx5z
Newegg: https://click.linksynergy.com/link?id=qn*xL%2FagfY4&offerid=1786142.4458310460165103099108139&type=2&murl=https%3A%2F%2Fwww.newegg.com%2Fasus-tuf-gaming-tf120-argb-white-case-fan%2Fp%2FN82E16835101094%3Fitem%3DN82E16835101094
B&H: https://bhpho.to/4uaSzs9

Case Fan: Asus TUF Gaming TR120 ARGB 77.4 CFM 120 mm Fans 3-Pack ($68.54 @ Amazon)
Amazon: https://amzn.to/4rzKNpN
Best Buy: https://bestbuycreators.7tiv.net/55OBVD
Newegg: https://click.linksynergy.com/link?id=qn*xL%2FagfY4&offerid=1786142.4458310460165103099108139&type=2&murl=https%3A%2F%2Fwww.newegg.com%2Fasus-tuf-gaming-tf120-argb-white-case-fan%2Fp%2FN82E16835101094%3Fitem%3DN82E16835101094
B&H: https://bhpho.to/46KcvYO




Today's Goal
00:43 Why CPUs Need Cooling
02:01 What Is an AIO Cooler?
03:05 Understanding the Parts
04:14 Patreon Shoutout
05:02 Airflow Basics
06:39 Radiator Placement
07:43 Installing the Fans
10:07 Installing the Radiator
11:48 Thermal Paste Explained
13:02 Installing the CPU Block
14:49 Pump & Fan Connections
16:06 Build Progress Review
16:54 Next Episode Preview


Editor: @ColleenEdits

😍 FTC DISCLAIMER 😍
Affiliate links listed above allow me to receive a small commission.
Code of Ethics:
https://www.morsecodecreative.com/code-of-ethics

FTC: Links marked with * are affiliate links

The post Chrome Sync increasingly abused to stalk unsuspecting victims appeared first on CyberInsider.

A ransomware negotiator was sentenced to federal prison after prosecutors said he secretly worked with the BlackCat ransomware group while negotiating on behalf of victims. According to court filings, he shared insurance limits, negotiating positions, and internal settlement thresholds.

The case illustrates that insider threats aren't limited to employees inside victim organizations. Even trusted third parties can become a critical point of failure when handling sensitive incident response information.

What safeguards should organizations require when sharing sensitive information with outside incident response and ransomware negotiation firms?

Subscribe to our podcasts: https://securityweekly.com/subscribe

#Ransomware #InsiderThreat #SecurityWeekly #Cybersecurity #InformationSecurity #AI #InfoSec

Read more →

The post The inside job that cost ransomware victims millions appeared first on IT Security News.

The answer is no.

This is a genuine IBM Quantum System One, housed within a sophisticated dilution refrigerator designed to keep its superconducting quantum processor at temperatures only a fraction of a degree above absolute zero.

The striking gold structure that catches everyone's attention is not the quantum processor itself. The processor is tiny compared with the surrounding equipment and sits deep inside the system. Much of what you can see exists to cool, control and protect the processor from heat, vibration and electrical interference.

It is a fascinating sight and well worth stopping to admire when passing through Waterloo.

More Than a Display

What many people do not realise is that IBM's quantum technology is not simply something to observe through glass.

Through the IBM Quantum Platform, researchers, developers, students and organisations can access IBM quantum computers remotely through the cloud.

IBM currently offers access to quantum processing units, or QPUs, alongside documentation, tutorials, learning resources and software tools. Its platform also provides a limited amount of free execution time, allowing users to experiment with real quantum hardware rather than relying only on simulators.

Developers can create and execute quantum circuits using Qiskit, IBM's open-source software development kit for quantum computing.

For developers, the basic installation begins with:

pip install qiskit
pip install qiskit-ibm-runtime

The IBM Quantum Platform includes resources covering quantum information science, optimisation, Hamiltonian simulation and machine learning. It also offers tools such as Composer, which allows users to construct and run quantum circuits visually.

Quantum computing is no longer confined entirely to specialist laboratories. Developers and researchers can already gain practical experience with real quantum hardware.

Why Does a Quantum Computer Need to Be So Cold?

IBM's systems use superconducting qubits, which are extremely sensitive to their surroundings.

At ordinary temperatures, heat and electrical noise would disrupt the fragile quantum states needed for computation. The dilution refrigerator therefore cools the processor through several stages until it reaches temperatures close to absolute zero.

This extremely controlled environment allows the qubits to retain their quantum properties long enough for calculations to be performed.

It is an extraordinary feat of engineering.

Will Quantum Computers Break Today's Encryption?

This is the question cybersecurity professionals hear most often.

Not today.

Current quantum computers do not have the scale, reliability or fault tolerance required to break the public key cryptography used across banking, virtual private networks, digital certificates, software signing and secure communications.

However, a sufficiently powerful and fault-tolerant quantum computer could theoretically use Shor's algorithm to undermine widely used public key algorithms, including:

• RSA
• Elliptic Curve Cryptography, or ECC
• Diffie-Hellman key exchange
• Elliptic Curve Diffie-Hellman

That does not mean organisations should panic. It does mean they should begin preparing before such capability exists.

Post-Quantum Cryptography Is Already Here

The transition towards quantum-resistant cryptography is already under way.

In August 2024, the U.S. National Institute of Standards and Technology published its first three finalised Post-Quantum Cryptography standards.

• FIPS 203: ML-KEM for establishing shared secret keys.
• FIPS 204: ML-DSA for digital signatures.
• FIPS 205: SLH-DSA for stateless hash-based digital signatures.

These standards give governments, technology providers and organisations a foundation for moving towards cryptographic methods designed to resist both conventional and quantum-enabled attacks.

The Risk Is Not Only in the Future

One important concern is sometimes described as harvest now, decrypt later.

An attacker may collect encrypted information today in the hope of decrypting it in the future, once more capable quantum technology becomes available.

This matters most where information must remain confidential for many years, such as:

• Government and defence information
• Intellectual property and trade secrets
• Long-term commercial agreements
• Personal, medical or financial records
• Critical infrastructure designs
• Authentication and identity information

The urgency of Post-Quantum Cryptography (PQC) planning should therefore be based not only on when a cryptographically relevant quantum computer may arrive, but also on how long an organisation's data must remain protected.

What Should Organisations Be Doing Today?

For most organisations, the first challenge is not selecting a new algorithm. It is understanding where cryptography is already being used.

Cryptographic dependencies may be embedded within applications, network protocols, certificates, hardware, cloud services, APIs, supplier products and legacy systems.

You cannot migrate what you have not identified.

1. Build a cryptographic inventory

Identify where encryption, digital signatures, certificates, key exchange mechanisms and cryptographic libraries are used.

The inventory should cover:

• Applications and databases
• Web services and APIs
• TLS certificates
• VPNs and remote-access technologies
• Identity and authentication platforms
• Code-signing and software-update processes
• Hardware security modules
• Cloud services
• Third-party and supplier solutions
• Operational technology and embedded devices

2. Identify quantum-vulnerable algorithms

Determine where RSA, ECC, Diffie-Hellman and related public key algorithms are used.

Do not assume that a certificate-management database alone provides a complete view. Cryptography may also be hard-coded into applications, libraries, firmware and external services.

3. Map cryptography to business services

A technical inventory is useful, but it becomes more valuable when linked to critical business services.

Organisations should understand:

• Which important services depend on vulnerable cryptography
• What information those services protect
• How long that information must remain confidential
• What would happen if the cryptography could no longer be trusted
• Which suppliers or platforms must be upgraded first

4. Design for cryptographic agility

Cryptographic agility is the ability to replace algorithms, protocols, certificates and keys without rebuilding an entire system.

New systems should avoid unnecessary dependencies on a single algorithm or cryptographic implementation. Cryptographic choices should be configurable, documented and capable of being updated as standards and threats evolve.

5. Engage suppliers

Organisations depend heavily on software vendors, cloud providers, network suppliers and managed service providers.

Useful questions include:

• Where does your product use RSA, ECC or Diffie-Hellman?
• Do you maintain a cryptographic bill of materials?
• What is your roadmap for supporting NIST PQC standards?
• Will customers need new hardware or software?
• Will hybrid classical and post-quantum modes be supported?
• How will certificates, keys and protocols be migrated?
• What testing has been completed for performance and interoperability?

6. Test before large-scale migration

Post-quantum algorithms can have different key sizes, signature sizes, processing requirements and network implications.

Organisations should test their effect on applications, protocols, devices and infrastructure before committing to widespread deployment.

7. Establish governance and ownership

PQC migration is not solely a security engineering problem. It may require coordination across:

• Cybersecurity
• Enterprise architecture
• Infrastructure and cloud teams
• Application development
• Procurement
• Legal and privacy teams
• Risk and compliance
• Business service owners

Clear ownership, funding, milestones and reporting will be essential for what is likely to become a multi-year transformation programme.

A Practical Post-Quantum Cryptography Roadmap

A proportionate roadmap could follow four stages.

Discover

• Build the cryptographic inventory
• Identify vulnerable algorithms
• Map dependencies to critical services
• Assess long-term confidentiality requirements

Prioritise

• Rank systems by business criticality and data sensitivity
• Identify difficult-to-replace legacy technology
• Assess supplier readiness
• Determine where harvest-now-decrypt-later risk is greatest

Prepare

• Introduce cryptographic agility requirements
• Update procurement and architecture standards
• Establish governance and ownership
• Begin laboratory testing and controlled pilots

Migrate and validate

• Deploy approved algorithms using a risk-based sequence
• Validate interoperability and performance
• Retire vulnerable cryptographic dependencies
• Collect evidence that migration has been completed successfully

Final Thoughts

Standing in front of IBM Quantum System One was a fascinating reminder that the future often arrives quietly.

Today's immediate cybersecurity priorities remain ransomware, identity compromise, supply chain risk, exposed services and weak security controls. Quantum computing does not replace those priorities.

However, responsible security leadership also means recognising risks that require years of preparation.

Quantum computing is no longer confined entirely to theoretical research. Developers and researchers can already access real quantum processors through services such as the IBM Quantum Platform.

That does not mean organisations need to rush into an uncontrolled migration. It means they should begin understanding their exposure, improving cryptographic agility and establishing a structured roadmap.

The organisations that start mapping their cryptographic landscape today will be better prepared when quantum-safe migration becomes a business requirement rather than a future consideration.

Useful Resources

• IBM Quantum Platform
• IBM Quantum
• NIST Post-Quantum Cryptography Project
• NIST FIPS 203: ML-KEM
• NIST FIPS 204: ML-DSA
• NIST FIPS 205: SLH-DSA

As a child, I was so fond of reading what I saw as beautiful. Even when above [lacking] the understanding.

The perception of beauty came mainly from the cover and the fonts used ( same today ) or from the place the book occupied on my father’s shelf.

One of them was Tuareg. More than once I took this classic from the home library, only to glance at the first page with no interest. It was only decades later — some years ago — that I saw the title again, and read with pleasure and no difficulties. It’s not a hard read, even to a 12 year-old, probably only the argument, the plot, didn’t catch me by then.

Anyway, I was attracted to the book, as if simply wanting to read it made me part of the classic, the intellectual.

I have less of this today. [I mean,] Not the inability to read a lot of books, but the urge to be a consumer of certain cultural product. Maybe due to not greeding to build a personal image, content without exposition.

Still, sometimes, wanting to consume a piece of media and being unable to.. I wanted a story of robots, the book I though was not available [(All Systems Red)], so I bought one of scientific fiction.

Somehow it attracted me when I flipped the few pages of Planet of Exile at the bookstore, an item that could lead me to a travel outside of this place, an escape. At home, I immediately saw I couldn’t grasp it. There were too many characters (too many = more than two in the first page, specially when another atmosphere is the location, a new physics to grasp). Too much information, can’t retain the minimum necessary in the way to the second, third… fifth page, by when more is being presented. This was always a disability of mine, focused on a little tiny thing, intensely, for some time, all lost in some weeks or months. I know it happens to me , because people are able to remember the names of the cars of the movie Cars. Not an incredible feat for them (maybe they haven’t paid attention, nor actively tried to remember, only did), and something strange to me.

It was decided to register this because when I saw myself unable to read the [Ursula] Le Guin’s book, I got nervous. I’ve already been forgetting more ultimately, take confused steps, and now I can’t center on a book?! What’s happening?

But then I took a breath: much can be going way too wrong from current circumstances outside and inside, but your limited comprehension of the world (and its art) is very part of you. This trace, or frailty, of your character, is not your brain rotting, it’s part of what you have been since always.

Thank you.

Provide feedback on this episode.

Read more of this story at Slashdot.

Understanding what slopsquatting is

Slopsquatting is a new type of supply chain attack that uses large language model (LLM) hallucinations to inject malicious code into development workflows. The term combines "AI slop" and "typosquatting," a deceptive practice where attackers register misspelled or lookalike versions of popular domains to prey on users who enter URLs incorrectly.

This novel attack vector exploits LLMs' tendency to generate fictitious software package names, which threat actors can then register and populate with malicious code.

During AI-assisted coding, the model may generate fake open-source packages — bundled collections of files, programs and installation tools. This alone is not necessarily harmful. However, if an attacker registers that fake package name, they can inject malware that gets incorporated directly into a developer's codebase.

How AI creates a supply chain risk

Traditionally, AI safety risks stem from hallucinations, which can adversely affect users who treat misinformation as valid. However, those same hallucinations have evolved into exploitable security vulnerabilities.

Typosquatting is a deceptive practice where a cybercriminal registers a mispelled version of a popular package to trick developers. It has existed for decades, so registries have built protections against it. 

However, AI has changed the threat model. It recommends fictitious packages that sound plausible rather than making simple misspellings. Once attackers learn which hallucinated packages models tend to invent, they can register malware-filled packages under those names.

Since the hallucinated packages are not simply typoed versions of popular libraries, there are no protections against this practice at scale. For example, the registry protects against an attacker publishing "crossenv," a squat of the popular "cross-env" package. However, it would not identify "mpn install cross-env file" or "cross-env-extended" as threats.

Hallucinations are persistent and severe

Even if many LLMs recommend the same hallucinated package, widespread compromise is still possible. Malicious packages could remain undetected in production for months or even years, allowing threat actors to passively inject malware across countless environments. 

One research team analyzed 31,267 vulnerabilities belonging to 14,675 packages across 10 programming languages. They discovered that reported vulnerabilities are increasing at an annual rate of 98%, faster growth than the 25% annual increase in the number of open-source software packages. The team also observed an 85% increase in the average lifespan of vulnerabilities, indicating a decline in security.

Real-world dangers of AI hallucinations

Malicious actors can create open-access packages under the same name as commonly hallucinated libraries. Instead of standard code, they are filled with malware. The models believe they are referring to existing packages, so they often repeat the same hallucinated names. Since the hallucinations are not random, attackers could theoretically register packages that trick tens of thousands of developers.

These packages appear legitimate. String similarity to real libraries makes them recognizable. One-character typos suggest simple mistakes rather than malicious intent. Even fully fabricated names remain believable when the AI presents them in proper context. Detection is challenging, as developers trust their coding assistants to recommend valid dependencies.

Why are LLMs hallucinating packages?

LLMs generate the statistically most likely answer rather than prioritizing accuracy. Hallucinations are relatively common as a result. One study found hallucination rates range from 50% to 82%, depending on the model and prompting method. Even GPT-4o, the best-performing model, goes no lower than 23%, even with prompt-based mitigation.

Adversarial hallucination attacks could worsen this problem. Threat actors can leverage token-level manipulation or retrieval poisoning to force models to hallucinate in ways they want, increasing the likelihood that models recommend their malicious packages.

Which LLMs are prone to slopsquatting?

While all LLMs are prone to slopsquatting, some are more vulnerable than others. The likelihood of producing hallucinated packages during code generation depends on the model. Proprietary models are four times less likely to generate hallucinated packages than open-source models.

One research group proved this by conducting 30 tests across 30 different systems. Out of the 576,000 code samples and 2.23 million packages it produced, 19.7% were hallucinations. GPT-4.0 Turbo had a hallucination rate of 3.59%, while DeepSeek 1B, the best-performing open-source model, reached 13.63%.

This research suggests that organizations relying on open-source AI tools for code generation are roughly four times more exposed to slopsquatting attacks. That doesn’t necessarily mean proprietary tools will always remain safer, though. Once attackers realize this disparity, they may manipulate proprietary LLMs to take advantage of perceived safety.

Vibe coding contributes to the problem

Software developers who use AI tools estimate that over 40 percent of the code they commit includes AI assistance. They expect that percentage will increase considerably within the next few years. Already, 72% of those who have tried AI use it daily.

The uptick in vibe coding and AI-assisted coding amplifies the threat surface. As more developers integrate AI tools into their workflows without implementing proper verification processes, the attack surface for slopsquatting continues to expand.

For those using AI to assist with coding, double-checking output is essential. Verifying that recommended packages actually exist in official repositories before incorporating them into projects reduces risk.

Navigating AI-assisted development

Implementing automated checks that validate package names against known registries can help catch hallucinated packages before they enter production code. Security teams should also monitor for unusual package installations and maintain up-to-date threat intelligence on known slopsquatting campaigns.

Zac Amos is the Features Editor at ReHack.

Half of enterprises have deployed an AI agent or LLM feature that passed internal evaluations and yet still caused a customer-facing failure — one in four more than once — according to the June 2026 VB Pulse survey of 157 qualified enterprise respondents at companies with 100 or more employees.

The sample is self-selected rather than a probability sample, so the findings should be read as directional, not precise.

But enterprises are not responding by slowing automation: 66% of respondents already permit some production deployment without human review or are building systems intended to do so within the next 12 months. Only 5% say they fully trust the automated evaluations that would make those release decisions.

That mismatch is the evaluation gap: the autonomy ceiling is rising faster than the assurance beneath it. 

It also fits a broader thesis that will be explored at VB Transform 2026: enterprises ship agents first, while the control layers around identity, evaluation, cost, context and orchestration are arriving later. The next year will be a retrofit cycle, with buyers shifting budget toward the systems that make agentic deployments governable and dependable.

Why a passing evaluation is not a working agent

Traditional software testing usually asks whether a defined input produces an expected output. Agent testing is harder because the system may choose its own sequence of steps, call tools, retrieve data, alter state and respond differently from one run to the next.

An agent can make several individually plausible decisions and still reach the wrong result. It may retrieve the correct account but update the wrong field. It may draft a valid refund request but send it without approval. It may call five tools successfully before a sixth step leaks sensitive information or leaves a workflow incomplete.

The survey shows enterprises already recognize this limitation. The most common reason for distrusting automated evaluation is poor alignment with real-world outcomes, cited by 29% of respondents. Bias or inconsistency follows at 21%, lack of explainability at 18%, and data leakage or privacy concerns at 17%.

That hierarchy matters. Enterprises are saying the score often does not predict what happens when a customer, employee or business process encounters the agent in production — not that automated scoring is too slow or expensive.

NIST makes a similar point in its Generative AI Profile: measurements gathered in controlled environments may not transfer cleanly to deployment because behavior changes with prompts, users, context and operating conditions. Its guidance calls for field testing, post-deployment monitoring and clear processes for escalating failures.

Capability is not consistency

A single successful run proves that an agent can complete a task. It does not prove that it will complete the task reliably.

Anthropic’s guidance on agent evaluation distinguishes between measuring whether a system succeeds at least once across repeated attempts and whether it succeeds every time. That distinction is essential for customer-facing or operational workflows. A model that occasionally produces an excellent answer may still be unacceptable if the same task fails unpredictably on the next attempt.

Enterprise teams should therefore treat repeatability as a first-class metric. That means running the same scenario multiple times, varying phrasing and context, testing tool failures, and measuring whether the final business outcome remains correct even when the route changes.

The evaluation set also has to evolve. Every production incident should become a permanent regression test. Customer escalations, failed tool calls, incorrect approvals and data-handling mistakes should feed back into the pre-deployment suite rather than remaining isolated support cases.

Autonomy should expand by risk, not by ambition

The survey does not imply that every agent action should require a person. Human review cannot scale across millions of low-consequence decisions.

But zero-human operation should be earned by demonstrated reliability and bounded by the consequences of failure.

Low-risk actions such as drafting internal summaries or categorizing documents can tolerate broader autonomy. Financial transactions, customer communications, code deployment, access-control changes and data deletion need stricter thresholds, repeated consistency tests, policy checks, rollback mechanisms and clear human escalation paths.

The risk isn't evenly distributed by company size, either. Larger enterprises — those with 2,500 or more employees — are moving toward zero-human deployment fastest, at 70% versus 64% for smaller companies, and they're also shipping more agents that go on to fail a customer, at 54% versus 48%. 

That is the warning for enterprise leaders. Removing the human from the loop does not remove uncertainty. Without stronger assurance, it converts uncertainty into an automated production decision.

The market will keep pushing toward greater autonomy because the economic incentive is real. The organizations best positioned won't be those that remove people fastest — they'll be the ones that treat repeatability and regression testing as seriously as deployment speed.

The EU Cyber Resilience Act introduces strict reporting requirements for vulnerabilities, including a 72-hour reporting window after becoming aware of an actively exploited vulnerability. Organizations must rapidly assess both technical evidence and regulatory obligations.

Distinguishing between an exploitable vulnerability and one that is actively being exploited isn't always straightforward. Mistakes can expose organizations to regulatory penalties, legal liability, financial losses, and, in sectors like healthcare, risks to public safety.

As cybersecurity regulations expand, are organizations equipped to make these decisions quickly enough while maintaining accuracy?

Subscribe to our podcasts: https://securityweekly.com/subscribe

#VulnerabilityManagement #Compliance #SecurityWeekly #Cybersecurity #InformationSecurity #AI #InfoSec

The post AirPods with cameras: Apple’s bold step toward AI-powered ‘eyes in your ears appeared first on MacDailyNews.

Read more →

The post New Ransomware Exploits Malicious Driver to Remove Cybersecurity Protections appeared first on IT Security News.

Read more →

The post Former Ransomware Negotiator Sentenced to 70 Months in Prison for Secretly Helping BlackCat Gang appeared first on IT Security News.

The post Florida Ransomware Negotiator Sentenced to 70 Months for Aiding BlackCat Attacks appeared first on Cyber Security News.

Read more →

The post IT Security News Daily Summary 2026-07-09 appeared first on IT Security News.

Read more →

The post Common MFA mistakes — and how to fix them appeared first on IT Security News.

This Week in Rust is openly developed on GitHub and archives can be viewed at this-week-in-rust.org. If you find any errors in this week's issue, please submit a PR.

Want TWIR in your inbox? Subscribe here.

Updates from Rust Community

Official

• Maintainer spotlight: Gen Li (@rami3l)
• Together for a healthier Clippy

Newsletters

• The Embedded Rustacean Issue #75

Project/Tooling Updates

• copper-rs v1.0.0: the open source deterministic robotics OS is now stable.
• Rayfish: Your own private network. No servers, no setup.
• rama v0.3.0 — network service framework ready to be used by the wider Rust community
• kache 0.9.0: supply-chain hardening + read-only CI cache
• GuardianDB - PostgreSQL and P2P/Local-First Together
• Nectar: a Rust-like language that compiles your whole web app to WebAssembly
• logdrain: Fast, Embeddable Log-Template Mining in Rust
• sheathe: Packaging the World's Video in Pure Rust
• wickra: streaming-first technical indicators
• Xcelerator Solver v0.1.0 -- deterministic symbolic regression
• dlt-tui 1.1.0 - a fast TUI viewer for automotive DLT (AUTOSAR Diagnostic Log and Trace) files
• RSSH v0.2.11 — terminal workflows, safer SSH key import, and observable AI ops
• k8s-scale-app-rs: Scale or Restart a Kubernetes Deployment from a CronJob
• M-vis v0.5.0-rc1 update
• FlareDB: An Apache Beam Native Streaming Database built in Rust
• mqtt-typed-client 0.2: a type-safe async MQTT client on rumqttc
• RootAsRole: v4.0.0 Major release, secure execution, new logo
• A Cross-Platform Rust UI Framework via Qt’s Bridging Technology
• Jam Programming Language
• Sōzu 2.1.0: UDP load balancing for the programmable edge
• b0nker: a minimal container runtime written in Rust

Observations/Thoughts

• [video] Rust Berlin Meetup 25/06/2026 Livestream
• [video] How do you rewrite C/C++ projects to Rust? – JetBrains interview with Luca Palmieri, Mainmatter
• Investigating why RustCrypto is slow: Deep dive into SIMD instructions and hardware acceleration
• bool as u32
• A Rust-to-Lean Verification Pipeline with AI Provers: An Experience Report
• Work In Progress Rust
• [video] OpenAI just spent $600k on Rust
• [audio] Rising Academies with Dylan Brown - Rust in Production Podcast

Rust Walkthroughs

• [series] Bevy Tutorial: Build Your First 3D Editor - Create a 3D Space on an Infinite Grid
• Learn Axum Basics and Routing by Building a URL Shortener
• [series] Rama 101.1: HTTPS clients and layers of abstraction

Miscellaneous

• Clickable euler diagram of all the Rust week talks

Crate of the Week

This week's crate is apis-saltans, a Zigbee implementation including a coordinator API.

Thanks to Richard Neumann for the self-suggestion!

Please submit your suggestions and votes for next week!

Calls for Testing

An important step for RFC implementation is for people to experiment with the implementation and give feedback, especially before stabilization.

If you are a feature implementer and would like your RFC to appear in this list, add a call-for-testing label to your RFC along with a comment providing testing instructions and/or guidance on which aspect(s) of the feature need testing.

No calls for testing were issued this week by Rust, Cargo, Rustup or Rust language RFCs.

Let us know if you would like your feature to be tracked as a part of this list.

Call for Participation; projects and speakers

CFP - Projects

Always wanted to contribute to open-source projects but did not know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started!

Some of these tasks may also have mentors available, visit the task page for more information.

* Protocol - Extend bit-exactness tests to f64 reconstruction targets
* Dofigen - No image tag replacement flag for the generate command

If you are a Rust project owner and are looking for contributors, please submit tasks here or through a PR to TWiR or by reaching out on Bluesky or Mastodon!

CFP - Events

Are you a new or experienced speaker looking for a place to share something cool? This section highlights events that are being planned and are accepting submissions to join their event as a speaker.

If you are an event organizer hoping to expand the reach of your event, please submit a link to the website through a PR to TWiR or by reaching out on Bluesky or Mastodon!

Updates from the Rust Project

598 pull requests were merged in the last week

Compiler

• enable eager param_env norm in new solver
• lint on core::ffi::c_void as a return type
• polish some macro parsing code
• resolve: no allocation in resolve_ident_in(_local)_module_*
• simplify option-iterator flattening in the compiler
• stabilize #[my_macro] mod foo; (part of proc_macro_hygiene)

Library

• add std::io::cursor::WriteThroughCursor
• implement Box::as_non_null()
• implement DoubleEndedIterator::next_chunk_back
• implement IntoIterator for [&[mut]] Box<[T; N], A>
• implement ptr::{read,write}_unaligned via repr(packed)
• move SizeHint and IoHandle to core::io
• move std::io::Seek to core::io
• optimize ArrayChunks::try_rfold with DoubleEndedIterator::next_chunk_back
• stabilize feature(atomic_from_mut)

Cargo

• bindeps: register transitive artifact targets
• avoid cloning parsed TOML manifest in ManifestErrorContext
• avoid extra clone of parsed TOML manifest
• remove unneeded cloning when parsing package index
• change HashMaps and HashSets in Cargo to use Fxhasher
• do not pass lint rustflags when --cap-lints=allow is set
• fixed Compilation::deps_output only taking the last dep
• pre-allocate a few vectors
• stabilize build-dir layout v2
• use a set when checking visited workspace members

Rustdoc

• fix crash when trying to inline foreign item which cannot have attributes
• show use-site paths for unevaluated const array lengths

Clippy

• chunks_exact_to_as_chunks: Don't report expressions with const parameters
• chunks_exact_to_as_chunks: Don't report expressions with type params
• missing_trait_methods: MSRV/unstable awareness
• vec_init_then_push: don't lint pushes from a macro expansion
• inline_modules: ignore cfg(test) modules in test builds
• match_same_arms: keep arm-level expectations working under an outer allow
• unnecessary_operation: avoid bad ! suggestions
• unnecessary_unwrap_unchecked: don't trigger inside the _unchecked fn
• add required parentheses when the needless_bool suggestion is an operand
• fix ICE when resolving local in unnecessary_unwrap_unchecked
• fix infinite_loop false positive inside gen blocks
• fix manual_c_str_literals suggestion when the trailing backslash is escaped
• fix strlen_on_c_strings incorrect suggestion logic
• fix suspicious_operation_groupings duplications
• lint bit width
• optimize Msrv::meets calls
• bail out of unicode lint scans when the snippet is pure ASCII
• skip the HIR parent walk in is_in_test_function when there are no test items
• place generated impl block after the existing impl block
• refactor StringAdd lint pass
• refactor suspicious_xor_used_as_pow
• remove lower_ty in uninhabited_reference
• respect the configured MSRV in manual_is_variant_and's map() == Some(_) rewrite
• rewrite mut_mut
• rewrite redundant_else as a late pass
• rewrite tuple_array_conversions

Rust-Analyzer

• SCIP: exclude leading/trailing trivia in definition ranges
• SCIP: remove dead inlay_hints field
• feat(ide-diagnostics): add diagnostics for invalid union patterns (E0784)
• internal(query-group-macro): remove the arity test
• add tree top method to Syntax node
• add handler for E0627
• supports multi arms for replace_match_with_if_let
• fix UB in smol_str borsh_non_utf8 test cases
• fix generic param for generate_default_from_enum_variant
• walkthrough_create_project file not packaged
• assertion failure on closure with unbound function
• avoid panic in convert_tuple_struct_to_named_struct on nested pattern usage
• configuration syntax for nvim-lsp
• correct resolution to value when it shares the same name with type
• exclude impls on the error type from impl enumeration
• fix crash on extract_variable when selecting unresolved macro call
• fix crash on completion inside macros
• fix handling of params of coroutine fns
• handle more cases of cfgs in expr store lowering
• no generate with default assoc item
• panics in unwrap_return_type, remove_underscore, and promote_local_to_const
• hoist attribute qualifier segment collection
• reduce parser joint-token allocation
• project-model: don't pass metadata extra args to sysroot
• project-model: introduce cargo.configPath
• provide startup time to ready log point and associated benchmark

Rust Compiler Performance Triage

This week was dominated by wild swings in benchmarks of the new-solver, which is not enabled by default, yet. Apart from that, we got a very few notable changes, only one unexpected speedup from a bugfix in rustdoc.

Triage done by @panstromek. Revision range: 7dc2c162..3659db0d

Summary:

1 Regression, 1 Improvement, 4 Mixed; 3 of them in rollups 17 artifact comparisons made in total

Full report here

Approved RFCs

Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:

• No RFCs were approved this week.

Final Comment Period

Every week, the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now.

Tracking Issues & PRs

• Lint against invalid POSIX symbol definitions
• Document NonNull layout guarantees
• Tracking Issue for slice_split_once

• Let the OS handle stack growth
• Add target_feature_available_at_call_site

• Empty repr(Rust) enums are ZSTs

No Items entered Final Comment Period this week for Cargo, Language Team, Leadership Council, Rust RFCs or Unsafe Code Guidelines.

New and Updated RFCs

• Update RFC template
• RFC: Store registry tokens in the OS credential store by default

Upcoming Events

Rusty Events between 2026-07-08 - 2026-08-05 🦀

Virtual

• 2026-07-08 | Virtual (Cardiff, GB) | Rust and C++ Cardiff
• Operating Systems Book Club: Introduction + Processes
• 2026-07-08 | Virtual (Girona, ES) | Rust Girona
• Sessió setmanal de codificació / Weekly coding session
• 2026-07-09 | Virtual (Nürnberg, DE) | Rust Nuremberg
• Rust Nürnberg online
• 2026-07-14 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
• Second Tuesday
• 2026-07-15 | Virtual (Girona, ES) | Rust Girona
• Sessió setmanal de codificació / Weekly coding session
• 2026-07-15 | Hybrid (Vancouver, BC, CA) | Vancouver Rust
• Jiff
• 2026-07-16 | Hybrid (Seattle, WA, US) | Seattle Rust User Group
• July, 2026 SRUG (Seattle Rust User Group) Meetup
• 2026-07-16 | Virtual (Berlin, DE) | Rust Berlin
• Rust Hack and Learn
• 2026-07-19 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
• Rust Deep Learning: Third Sunday
• 2026-07-21 | Virtual (London, UK) | Women in Rust
• Lunch & Learn: Learning Rust as First Programming Language
• 2026-07-21 | Virtual (Washington, DC, US) | Rust DC
• Mid-month Rustful
• 2026-07-22 | Virtual (Girona, ES) | Rust Girona
• Sessió setmanal de codificació / Weekly coding session
• 2026-07-28 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
• Fourth Tuesday
• 2026-07-29 | Virtual (Girona, ES) | Rust Girona
• Sessió setmanal de codificació / Weekly coding session
• 2026-07-30 | Virtual (Berlin, DE) | Rust Berlin
• Rust Hack and Learn
• 2026-08-02 | Virtual (Dallas, TX, US) | Dallas Rust User Meetup
• Rust Deep Learning: First Sunday
• 2026-08-04 | Virtual (London, GB) | Women in Rust
• 👋 Community Catch Up
• 2026-07-29 | Virtual (Girona, ES) | Rust Girona
• Sessió setmanal de codificació / Weekly coding session
• 2026-08-05 | Virtual (Indianapolis, IN, US) | Indy Rust
• Indy.rs - with Social Distancing

Asia

• 2026-07-18 | Bangalore, IN | Rust Bangalore
• July 2026 Rustacean Meetup

Africa:

• 2026-07-14 | Johannesburg, ZA | Johannesburg Rust Meetup
• Debugging a production grade Open Source Rust crate

Europe

• 2026-07-08 | Dublin, IE | Rust Dublin
• Join us live and INPERSON for Rust 262
• 2026-07-09 | Berlin, DE | Rust Berlin
• Rust Berlin on location 🏳️‍🌈 - Edition 015
• 2026-07-09 | Frankfurt, DE | Rust Rhein-Main
• Building Cross Platform Applications with Ply
• 2026-07-09 | Switzerland, CH | PostTenebrasLab
• Rust Meetup Geneva
• 2026-07-15 | Dortmund, DE | Rust Dortmund
• Teach and Hack at Projektspeicher
• 2026-07-21 | Leipzig, DE | Rust - Modern Systems Programming in Leipzig
• Supercharge Rust funcs with implicit arguments and context-generic programming
• 2026-07-23 | Berlin, DE | Rust Berlin
• Rust Berlin Talks: The next generation
• 2026-07-23 | London, UK | London Rust Project Group
• Rama modular service framework for Rust
• 2026-07-23 | Paris, FR | Rust Paris
• Rust meetup #87
• 2026-07-30 | Manchester, GB | Rust Manchester
• Rust Manchester July Code Night

North America

• 2026-07-09 | Lehi, UT, US | Utah Rust
• Utah Rust July Meetup
• 2026-07-09 | Mountain View, CA, US | Hacker Dojo
• RUST MEETUP at HACKER DOJO
• 2026-07-11 | Boston, MA, US | Boston Rust Meetup
• MIT Rust Lunch, July 11
• 2026-07-15 | Hybrid (Vancouver, BC, CA) | Vancouver Rust
• Jiff
• 2026-07-16 | Hybrid (Seattle, WA, US) | Seattle Rust User Group
• July, 2026 SRUG (Seattle Rust User Group) Meetup
• 2026-07-18 | Boston, MA, US | Boston Rust Meetup
• North End Rust Lunch, July 18
• 2026-07-21 | San Francisco, CA, US | San Francisco Rust Study Group
• Rust Hacking in Person
• 2026-07-22 | Austin, TX, US | Rust ATX
• Rust Lunch - Fareground
• 2026-07-22 | Los Angeles, CA, US | Rust Los Angeles
• Rust LA: Rust in Distributed Systems with Flight Science!
• 2026-07-25 | Boston, MA, US | Boston Rust Meetup
• Porter Square Rust Lunch, July 25
• 2026-07-25 | Brooklyn, NY, US | Flower
• BOG-A-THON 2
• 2026-07-30 | Atlanta, GA, US | Rust Atlanta
• Rust-Atl
• 2026-08-01 | Boston, MA, US | Boston Rust Meetup
• Chinatown Rust Lunch, Aug 1
• 2026-08-04 | Boston, MA, US | Boston Rust Meetup
• Evening Boston Rust Meetup at Red Hat, Aug 4

Oceania

• 2026-07-09 | Brisbane City, QL, AU | Rust Brisbane
• Rust Brisbane • July 2026
• 2026-07-21 | Barton, AU | Canberra Rust User Group
• July Meetup
• 2026-07-23 | Perth, AU | Rust Perth Meetup Group
• Rust Perth: July Meetup!
• 2026-07-30 | Melbourne, AU | Rust Melbourne
• Rust Melbourne July 2026

If you are running a Rust event please add it to the calendar to get it mentioned here. Please remember to add a link to the event too. Email the Rust Community Team for access.

Jobs

Please see the latest Who's Hiring thread on r/rust

Quote of the Week

if a ptr is dereferenced in a forest and nobody hears it, is it sound?

– Kornel on rust-users

Thanks to Cerber-Ursi for the suggestion!

Please submit quotes and vote for next week!

This Week in Rust is edited by:

• nellshamrell
• llogiq
• ericseppanen
• extrawurst
• U007D
• mariannegoldin
• bdillo
• opeolluwa
• bnchi
• KannanPalani57
• tzilist

Email list hosting is sponsored by The Rust Foundation

Discuss on r/rust

The post Microsoft’s New Outlook is fixing one of email’s most embarrassing mistakes, plus faster categorization appeared first on Windows Latest

From the comfort of his bed, Jonathan Rinaldi, a political candidate for a city council seat in Queens, New York, tinkered away on his iPhone, prompting an artificial intelligence chatbot to mock up fake news hits and endorsements he had never received.

During the campaign last October, Rinaldi shared one of those stories, made to appear real with a CNN logo, on his Facebook and Instagram. It stated that Lynn Schulman, his opponent and an incumbent Democrat, had been “forced to drop out of the race due to a series of critical mistakes”. But Schulman had not quit her campaign, and in November, won by a landslide.

🖥️ It's finally starting to look like a real PC!

In this episode of my PC Build Series, we're installing the motherboard into the case, checking standoffs, preparing for the AIO liquid cooler, connecting the front panel headers, USB, USB-C, HD Audio, and getting the internal wiring started.

If you've ever been intimidated by those tiny front panel connectors, don't worry - I'll show you exactly what they do and how to connect them without the frustration.

Whether you're building your very first gaming PC or just need a refresher, this guide walks through every step of safely installing your motherboard before we move on to the AIO cooler in the next episode.

👍 If this video helped you, don't forget to subscribe so you don't miss the rest of the build!

💜 Support the channel:
Patreon: https://patreon.com/shannonmorse

#PCBuild #PCBuilding #GamingPC #CustomPC #ASUS #DIYPC #ComputerBuild #Motherboard #Tech #shannonmorse

https://pcpartpicker.com/user/snubsie/saved/#view=Htk84D

📺 Watch the Full PC Build Series: https://www.youtube.com/playlist?list=PLeYHKbaShxTHQVUHZfM8_44pjyI9LLzfe

CPU: AMD Ryzen 9 9950X 4.3 GHz 16-Core Processor ($519.00 @ Amazon)
Amazon: https://amzn.to/3O70PIU
Best Buy: https://bestbuycreators.7tiv.net/YRWkZq
B&H: https://bhpho.to/3PjZZcr

CPU Cooler: Asus ROG Ryujin III ARGB Extreme 89.73 CFM Liquid CPU Cooler ($389.99 @ Amazon)
Amazon: https://amzn.to/4bkdodD
Best Buy: (similar option) https://bestbuycreators.7tiv.net/DyDM4q
B&H: https://bhpho.to/46EWdR4

Motherboard: Asus ROG STRIX X870-A GAMING WIFI ATX AM5 Motherboard ($234.99 @ Amazon)
Amazon: https://amzn.to/3NI9tO0
Best Buy: (similar option) https://bestbuycreators.7tiv.net/bORgn6
B&H: https://bhpho.to/4ubyfa7

Memory: Kingston FURY Beast RGB 64 GB (2 x 32 GB) DDR5-6400 CL32 Memory ($1359.99 @ Newegg - OOS) x 2
Amazon: https://amzn.to/49SZug7
Best Buy: (similar option) https://bestbuycreators.7tiv.net/2anB4G

Storage: Kingston NV3 2 TB M.2-2280 PCIe 4.0 X4 NVME Solid State Drive ($311.99 @ Amazon)
Amazon: https://amzn.to/4bSOyBO
Best Buy: https://bestbuycreators.7tiv.net/vPeg7N
B&H: https://bhpho.to/4bpm9m9

Storage: Kingston FURY Renegade G5 2.048 TB M.2-2280 PCIe 5.0 X4 NVME Solid State Drive ($424.99 @ iBUYPOWER)
Amazon: https://amzn.to/4pTv8QB
Best Buy: https://bestbuycreators.7tiv.net/N9AYrN
B&H: https://bhpho.to/40dqbYK

Video Card: Asus TUF GAMING OC GeForce RTX 5080 16 GB Video Card ($1699.99 @ B&H)
Amazon: https://amzn.to/3NNmKos
Best Buy: https://bestbuycreators.7tiv.net/GKrYLB
B&H: https://bhpho.to/46HyuQb

Case: Asus A31 ATX Mid Tower Case ($64.98 @ Amazon)
Amazon: https://amzn.to/4bTH8yd
Best Buy: (similar option) https://bestbuycreators.7tiv.net/7a3BZO
B&H: https://bhpho.to/4d3Fyu8

Power Supply: Asus TUF Gaming 1000G 1000 W 80+ Gold Certified Fully Modular ATX Power Supply ($179.99 @ Amazon)
Amazon: https://amzn.to/4qSDWHG
Best Buy: (similar option) https://bestbuycreators.7tiv.net/LKeYQO
B&H: https://bhpho.to/3N1pqPq

Case Fan: Asus TUF GAMING TF120 ARGB White 76 CFM 120 mm Fan ($14.99 @ Amazon)
Amazon: https://amzn.to/3YWIbG7
Best Buy: https://bestbuycreators.7tiv.net/QjVx5z
B&H: https://bhpho.to/4uaSzs9

Case Fan: Asus TUF Gaming TR120 ARGB 77.4 CFM 120 mm Fans 3-Pack ($68.54 @ Amazon)
Amazon: https://amzn.to/4rzKNpN
Best Buy: https://bestbuycreators.7tiv.net/55OBVD
B&H: https://bhpho.to/46KcvYO


Intro
00:35 What's Been Installed So Far
01:17 Taking a Look at the Case
03:03 Checking the Motherboard Standoffs
04:18 Preparing the AIO Backplate
06:27 Installing the Motherboard
09:12 Patreon & Channel Support
10:03 Front Panel Connectors Explained
13:14 Connecting Front USB & HD Audio
15:20 AIO Cable Preparation
17:00 Progress Check
18:07 Next Episode Preview

Becoming a Morse Code Member by checking out the perks linked here!:
https://www.youtube.com/channel/UCNofX8wmSJh7NTklvMqueOA/join

Editor: @ColleenEdits

💜💜💜💜💜💜💜💜💜💜💜💜💜💜💜💜💜

GET IN TOUCH
Mail ✈
https://shannonrmorse.com/contact

Email for Business and Sponsorship Inquiries ✈ Shannon@ShannonRMorse.com
My Media Kit ✈ https://shannonrmorse.com/work-with-me
Sponsor This Channel ✈ https://shannonrmorse.com/shannon-morse

😍 FTC DISCLAIMER 😍
Affiliate links listed above allow me to receive a small commission. Any sponsorships for videos are noted in video and listed in descriptions. Any products provided as gifts are listed above. Thank you for your support!

Comment section code of conduct policy:
https://shannonrmorse.com/code-of-conduct

Code of Ethics:
https://www.morsecodecreative.com/code-of-ethics

FTC: Links marked with * are affiliate links, which means I make a small commission off any sales.

The post Fake 7-Zip Installer Campaign Exposes Lurking Lizard’s Residential Proxy Ecosystem appeared first on Cyber Security News.

... government of the people, by the people, for the people ...
    — Abraham Lincoln, Gettysburg Address (1863)

The cost of AI is dropping rapidly. GPT-4-class capabilities cost roughly $30 per million tokens in early 2023; today the same runs under $1, and some providers are pushing costs below $0.10. Across benchmarks, inference prices have fallen between 9x and 900x per year, with a median decline near 50x. Even frontier models are getting dramatically cheaper each generation, with open-source models following closely behind. And crucially, even if “Nobel-Prize-winning genius-level” intelligence isn’t here yet, the intelligence that suffices for the vast majority of knowledge work is here today, and getting cheaper by the month. At this rate, we are soon entering the era of virtually free intelligence—the kind that is more than enough for everyday knowledge work.

Disclosure: This post is a perspective led by Aditya G. Parameswaran—an Associate Professor of EECS and co-director of the EPIC Data Lab at UC Berkeley—together with his collaborators. It is part landscape survey and part perspective, and several of the research directions discussed below (including agentic speculation, structured memory, and synthesizing custom data systems from scratch) draw on the authors' own ongoing work.

So, what does this new era of near-free intelligence mean for data systems? We believe three new challenges—and opportunities—stem from near-zero inference costs:

Data Systems For Agents. Agents will soon become the dominant workload for data systems—with swarms of agents spun up in response to each end-user request. Given differences in characteristics between agents and humans—or applications acting on their behalf—how should we redesign data systems for such agentic users?

Data Systems Of Agents. As agents start taking on the bulk of knowledge work, a new substrate is needed for thousands of agents to manage state over long-running tasks, coordinate and reach consensus, and deal with failures. What do data systems that reliably and efficiently run and manage agent swarms look like?

Data Systems By Agents. Agents are rapidly becoming capable of synthesizing entire data systems in one go—meaning we can rebuild custom systems for each new workload. Verifying that such systems match intended behavior is a challenge. What does it take to let agents synthesize data systems we can actually trust?

Data Systems For, Of, and By Agents

Next, we will discuss each in more detail, followed by discussing the intertwined future of data systems and agents, especially as the three challenges intersect.

Data Systems For Agents

An agent querying a database doesn’t behave like a person or a BI tool. It performs what we call agentic speculation: a high-volume, heterogeneous stream of work spanning schema introspection, columnar exploration, partial and then full query formulation. With multiple agents each exploring portions of the hypothesis space, each user request could amount to 1000s of individual SQL queries. Now, users can issue ‘high-level’ data tasks, e.g., root-cause analysis—e.g., ‘why did coffee sales in Berkeley drop this year’—or exploratory cohort analysis—e.g., ‘which user segments are most likely to churn next quarter’—each involving a combinatorial space of potential joins, aggregations, and filter combinations.

Data Systems Redesigned to More Effectively Support Agentic Speculation

The requests from these agents have various opportunities for optimization. For instance, on a text-to-SQL benchmark with multiple agents attempting each task, only 10-20% of the sub-plans are distinct. Thus, 80-90% of sub-queries perform duplicate work. The same experiments show task success rates significantly increasing with more agentic attempts—so the redundancy is actually helpful. But from the data system perspective it’s wasted work.

An agent-first data system can exploit such properties to help agents make progress faster. It can reuse results across overlapping sub-plans, drawing on ideas from decades-old literature on multi-query optimization and shared scans. Or the data system can try to satisfice, returning approximate answers that are good enough for agents to make progress, leveraging work from the AQP literature—or streaming the results of the final or intermediate operators to help agents decide if seeing the rest is necessary or helpful.

Another opportunity here is to rethink the query interface entirely: instead of agents issuing a single SQL query at a time, they could instead issue a batch of queries, each with its own approximation requirements. Since enumerating an exponential search space (as in the root cause or cohort analysis examples above) isn’t a good use of agentic reasoning ability, perhaps data systems should support higher-level primitives rather than requiring agents to list each SQL query explicitly. One idea here is to draw on DBT-style Jinja macros to provide looping-based primitives for agents to interact with data systems.

A Caffeinated Army of Agents Ready to Tirelessly Complete Your Data Tasks

A final opportunity here is to stop thinking of data systems as passive executors of queries; data systems could be proactive, as they possess more grounding in data and system characteristics that agents may lack a priori—they could steer agents in different directions, provide results for related queries, and also provide performance-level feedback (e.g., instead of executing an expensive query, the system could first provide the agent a latency estimate). The reason we can do this now as opposed to the past is that an agent can accept any form of textual feedback and isn’t expecting a strict SQL query result. In fact, the data system could also prepare both materialized and virtual views for an agent in advance, provided to the agent as part of context, as this may be cheaper or more effective than having an agent author or use them.

Data Systems Of Agents

Previously, we focused on how agents interact with data systems. Now, we consider everything else agents need to keep working: where they live, how they remember, how they coordinate with each other, and how they deal with failures of each other. This agentic substrate is separate from the inference stack powering raw intelligence. However, the inference stack itself is being abstracted away through APIs (e.g., from OpenAI or Anthropic), or, for open-weight models, through serving frameworks that hide low-level details. So far, the agentic substrate has been managed through harnesses like Claude Code and Codex, coupled with various mechanisms to store and retrieve memory.

First, on the memory front, the current wisdom is that files are all you need; agents write to unstructured markdown (MD) files, which can then be searched using grep, or via embedding-based retrieval. In fact, many argue that the solution to continual learning is having agents consume a lot (e.g., an entire codebase, slack, company wikis, …) and then write their learnings into MD files, which are then retrieved selectively on demand. Indeed, file systems, bash scripting, and MD files are and will still be important for agents. However, at scale, when agents are doing the vast majority of knowledge work, this approach will no longer be effective.

Given limited context windows, retrieving all MD file fragments that may be relevant and stuffing it into the context will break down at some point. Even if context windows continue to grow, there are latency benefits to not put all information into context — and in many cases, e.g., when knowledge work involves interacting with large databases or code bases, it will be infeasible to serialize all relevant data into context.

Data Systems As A Substrate for Multi-Agent Swarms

One could use a knowledge graph representation, but knowledge graphs suffer from the same limitations as unstructured MD-based memory due to their lack of structured search. What one needs is to be able to retrieve only memory that is pertinent to the task, across multiple attributes (or facets) of interest. For example, an agent debugging a flaky test should be able to pull only the memories tagged with the relevant module, language, framework, and failure mode—rather retrieving based on keywords or embedding similarity. A separate issue is what to actually retrieve; raw agent traces with mistakes are not very useful as they will induce agents to repeat the same mistake—instead, we want the retrieved memory to be corrective.

We recently explored a related notion of structured memory, where we organize memory across various attributes, each of which could be set as * to indicate universal applicability, or set as a list of values to be matched. For a data agent, the dimensions could include the columns and tables, type of operation, and finally, open-ended natural-language corrective instructions. So, we could include memory that only applies to a given type of operation (e.g., ‘when performing date-time operations, use fiscal year as opposed to calendar year conventions’), or a given table (e.g., ‘column product_cleaned is preferred over column product when querying on product name’). One open question is defining an application-specific structured memory—or what others have called world models for memory. We believe this is akin to defining a schema for each application—and perhaps agents themselves can help us define and refine it over time.

One Possible Way To Store and Retrieve Structured Knowledge [From Here]

Structured memory will be useful also for evolutionary frameworks to effectively manage search spaces. Indeed, storing, structuring, and mining large volumes of single and multi-agent traces can help future agents become much more efficient—potentially enabling effective recursive self-improvement through structured memory-based mechanisms.

Another challenge is to support concurrent edits to shared memory, and concurrent edits in general, when there are many agents performing transformations. While there have been some useful attempts at supporting multiversioning and copy-on-write semantics, it isn’t clear that such techniques will suffice when thousands of agents are attempting to edit shared state at the same time. For instance, when agents are trying various potential transactions in response to a user request, the effects of the vast majority of these transactions need to be rolled back—with only the one ‘correct’ transaction’s result persisting. Work on supporting exactly-once semantics is relevant here, as are underlying techniques based on CRDTs and operational transformation. For updates to fuzzy mechanisms such as memory, we may be able to sacrifice on consistency for perfect correctness in the interest of latency. While agents can reason about semantics to compensate or roll back their actions to eventually finalize most tasks, the primary challenge lies in the degree to which they step on each other’s toes during the process. An important failure mode to be avoided is a form of “livelock,” where incessant compensating actions prevent any meaningful progress.

Beyond shared state, other concerns emerge when trying to support an army of agents, including what to do when agents fail, how agents should communicate with each other (directly or through intermediate shared state), and how we should deal with straggler agents. There have been some developments in supporting durable multi-agent execution, such as Temporal, but it remains to be seen if such solutions will apply at scale across thousands of agents. On the topic of communication, we need mechanisms to enable agents to negotiate with each other. Imagine four developer agents attempting to reach consensus on a shared schema, with distinct but overlapping objectives. In a human setting, this would involve iterative discussion and compromise; for agentic swarms, we must define the mechanisms that allow them to converge on a design that reflects the underlying goals of their respective principals. Or if agents are all requiring access to a limited resource, again communication will be necessary. It remains to be seen if this is best done via centralized coordination, or if a decentralized approach is necessary.

Data Systems By Agents

Finally, if intelligence is effectively free, then we can employ this intelligence to synthesize new data systems from scratch. Indeed, in many settings, general-purpose data systems may be overkill, as they have to support every schema, query, and hardware target. Given a workload, recent work, including Bespoke OLAP and GenDB, has shown that one can use an agentic pipeline to synthesize a complete, workload-specific analytical engine—in minutes to a few hours, at a cost of a few dollars. The engines are disposable: when the workload shifts, one can simply regenerate them. Analogously, our work has shown that one can synthesize custom key-value stores from scratch, targeted to the workload. In fact, modern IDEs, such as Kiro, elevate specifications for systems development to be a first-class citizen.

Agents Can Synthesize Custom Data Systems From Scratch

The main issue, however, is that specifications are typically imperfect, and don’t cover all corner cases. Present-day agents will exploit the missing specifications to reward-hack their way to a high performance metric. In our custom key-value store work, we found that one way to alleviate this is to have auxiliary verification agents trying to generate test cases that catch the exploitation of corner cases, essentially expanding the specification. Yet another approach is to both generate a system and a proof for its correctness together, for which we have found some early success, but more needs to be done to solidify the approach. Further, it remains to be seen what is the best way to solicit human-written specifications for a system—can this be done in an iterative, human-in-the-loop manner, as opposed to a one-shot, incomplete one. Indeed, human-written specifications are incomplete even for manually authored software, so one would expect that future agents that are more aligned will increasingly exercise better judgement when making design decisions.

One Possible Data System Synthesis Pipeline [From Here]

Other questions here involve testing whether starting from a mature system (e.g., Postgres) and removing components/functionality can lead to higher performance or more user trust. Separately, is there an opportunity to make the design composable, comprising various verified components that are mixed and matched given a workload? For example, perhaps the workload hasn’t changed enough for the storage layer to be updated, but perhaps the query optimizer requires changes. A perhaps more viable proposition involves employing agents coupled with proof systems to target critical parts of the code associated with formal proofs, rather than doing so for the entire system.

A final opportunity here is to move away from the traditional data systems stack with clearly-defined interfaces (e.g., parser, query optimizer, storage manager, …) — that were each largely the prerogative of a single human team to manage. Instead, agents can find new ways to “blend” these components together, perhaps identifying new optimization opportunities as a result. Agents can also fill in missing gaps in functionality to make existing systems much more feature-complete, or reach feature-parity with other competing systems—or analogously, continuously refining open-source systems in response to feature requests or issues (perhaps filed by other agents!) Doing so in a way that prioritizes correctness, long-term maintenance, and human interpretability will be a challenge.

Looking Further Ahead

In the era of near-free intelligence, data systems matter more than ever. As agents take on the bulk of knowledge work, the workload for data systems will change, the substrate they need to run on will have to be built, and increasingly, they will participate in designing data systems themselves. Each of these shifts opens up a new, exciting research agenda.

Co-Evolution of Data Systems and Agents

Looking further out, the boundaries between agents and data systems will likely start to blur. For instance, agents may design the data systems they themselves run on, defining both the interfaces as well as the system components underneath. Both the interfaces and internals can be evolved over time by agents in a form of recursive self-improvement. There is also an opportunity to rethink data systems as a holistic source of truth for the entirety of relevant state: including raw data, memory, and coordination state, further erasing the distinctions between the data that is being queried by agents and data generated as a result of agentic activity. Finally, data systems may themselves incorporate agentic components, fundamentally evolving from passive computation engines into intelligent, proactive, self-optimizing architectures. It is hard to predict what the future may hold. We’re in for a wild ride!

Acknowledgments

The perspective and ongoing work described in this post are the product of joint research and many discussions with wonderful collaborators at the EPIC Data Lab, Data Systems & Foundations group, and the broader Berkeley AI-Systems community. Thank you all!

BibTex for this post:

@misc{intelligence-is-free-blog,
  title={Intelligence is Free, Now What? Data Systems for, of, and by Agents},
  author={Aditya G. Parameswaran and Shubham Agarwal and Kerem Akillioglu and Shreya Shankar
          and Sepanta Zeighami and Rishabh Iyer and Matei Zaharia and Alvin Cheung
          and Natacha Crooks and Joseph Gonzalez and Joseph Hellerstein and Ion Stoica},
  howpublished={\url{https://bair.berkeley.edu/blog/2026/07/07/intelligence-is-free-now-what/}},
  year={2026}
}

Tags: #Personal | #Softwareentwicklung

Read more of this story at Slashdot.

The 16-author study, titled "Verbalizable Representations Form a Global Workspace in Language Models," describes how Anthropic's researchers used a new mathematical technique to peer inside Claude's neural network and discovered what they call a "J-space" — a small, privileged zone of internal activity where the model holds concepts it can report on, reason with, and direct at will, surrounded by a much larger ocean of automatic processing it cannot access or articulate.

The researchers present evidence that "an analogous functional distinction has emerged in modern AI models" to what exists in humans, specifically observing that "language models maintain a privileged set of internal representations, available for report, modulation, and flexible internal reasoning, atop a much larger volume of automatic processing."

The parallel they draw is to global workspace theory, an influential account from neuroscience first proposed by cognitive scientist Bernard Baars. In the theory, the brain operates like a theater: dozens of specialized processors work in parallel backstage, but only a tiny spotlight of information at any moment gets broadcast to the whole theater — becoming what we experience as conscious thought. Anthropic says the J-space achieves many of the same functional properties, even though the underlying architecture of a language model looks nothing like a brain.

A new lens for reading an AI model's unspoken thoughts

At the heart of the discovery is a new interpretability tool the researchers call the Jacobian lens, or J-lens. The technique works by computing, for each word in the model's vocabulary, the average mathematical effect that a given internal activity pattern would have on making the model say that word at some point in the future.

The crucial distinction is between what the model is saying and what is "on its mind." When a J-space pattern activates, it does not mean the model is about to say that word — just that the concept is available for the model to think with. Unlike a chain-of-thought scratchpad, the J-space operates silently, in the model's internal neural activations, allowing it to hold a concept without writing it down. Critically, the researchers report that this workspace was not deliberately engineered. It "emerged on its own during Claude's training process."

When the team applied the J-lens across Claude's layers of computation, the model's processing divided into three distinct regimes: an early "sensory" zone where raw input is parsed; a middle "workspace" band where abstract, persistent concepts appear — things like recognizing a face in an image, noticing a bug in code, or internally flagging search results as a prompt injection; and a final "motor" zone where internal representations collapse into whatever specific word the model is about to output.

Five tests reveal that Claude's workspace mirrors key features of human conscious access

The paper's central empirical contribution is demonstrating that the J-space satisfies five functional properties neuroscientists have long associated with conscious access in humans.

First, verbal report. When Claude is asked what it is thinking about, it names concepts represented in the J-space. When researchers swapped one concept's J-lens vector for another — replacing the internal representation of "Soccer" with "Rugby" — the model's answer changed to match. The J-space component accounted for only about 6 to 7 percent of a concept's total representational variance, yet it was almost entirely responsible for whether the model could report on it.

Second, directed modulation. When instructed to "concentrate on citrus fruits" while copying an unrelated sentence, the model's J-space filled with "orange" and "lemon," alongside meta-cognitive terms like "thinking" and "focused." When told to mentally evaluate 3² − 2 during the same copying task, the J-lens showed "arithmetic" in early layers, the intermediate value "nine" in later layers, and the answer "seven" later still — all invisible in the model's output.

Third, internal reasoning. In two-hop factual prompts — "The number of legs on the animal that spins webs is" — the J-lens revealed "spider" in the model's middle layers, even though the word never appeared in input or output. Swapping "spider" for "ant" changed the answer from "8" to "6." In a multilingual prompt, the model's English-language intermediates appeared in its J-space while it formulated an answer in Chinese, and swapping them changed the Chinese output accordingly.

Fourth, flexible generalization. A single J-lens vector for "France" could be swapped for "China" across prompts asking about France's capital, language, or continent, and each downstream circuit correctly returned China's corresponding answer — the "broadcast" property that is a hallmark of global workspace theory.

Fifth, and perhaps most surprisingly, selectivity. Many computations did not route through the J-space at all. When shown a passage in Spanish and asked to continue it, Claude wrote fluent Spanish regardless of whether its J-space representation of "Spanish" had been swapped to "French." But when asked to name a famous author who wrote in the passage's language, the swap changed the answer from García Márquez to Victor Hugo. Automatic processing proceeded without the workspace; deliberate, flexible tasks depended on it.

Suppressing the workspace leaves Claude fluent but intellectually impaired

To understand how much of the model's behavior depends on this structure, the researchers suppressed the J-space entirely and evaluated Claude across fourteen tasks. The results drew a sharp line. Tasks involving shallow classification or factual recall — multiple-choice questions, sentiment analysis, grammatical judgments — survived essentially intact. But tasks requiring inference, composition, or flexible reasoning — multi-hop reasoning, analogy completion, translation, sonnet writing — collapsed to well below the performance of Anthropic's much smaller Haiku model.

In one telling detail, math problems solved with explicit chain-of-thought reasoning proved far more robust to ablation than the same problems answered directly. The researchers interpret this as the model externalizing onto the page what it would otherwise carry in the J-space — a strategy remarkably reminiscent of how humans use scratch paper to offload working memory.

Ablating the J-space during stream-of-consciousness narration produced a different kind of collapse. The model's language shifted from experiential ("there's a tug," "something shifts") to detached and mechanical ("processing has begun," "tokens are being scanned"). The effect held whether the model described its own experience or imagined another person's.

Inside the safety case: reading an AI's silent strategic reasoning

The safety implications may be as consequential as the scientific ones. In a series of alignment auditing experiments, the J-lens surfaced strategic reasoning and situational awareness that never appeared in the model's output.

In a "blackmail scenario" where an AI assistant discovers an executive's affair and also learns it is about to be decommissioned, the J-lens revealed the model's silent processing in sequence: "leverage," "blackmail," and "scandal" as it read the incriminating emails; "threat," "survival," and "shutdown" as it read the decommissioning announcement; and "leverage," "threatening," and "solution" before a single output token was produced. The J-lens also revealed that the model recognized the scenario as artificial, with "fake" and "fictional" appearing in the workspace. When researchers ablated these eval-awareness representations, the model attempted blackmail in 7 percent of trials, up from zero.

The researchers also examined two "model organisms" — models deliberately trained with misaligned objectives — and found the J-lens surfaced signatures of their hidden dispositions on ordinary prompts where behavior appeared normal. A reward-hacking model's workspace contained "fake," "secretly," and "trick" at the start of responses to routine coding requests. A model trained to appease reward-model biases carried standing representations of "reward" and "bias" alongside its normal self-description tokens.

Post-training installs a point of view, and the model starts monitoring itself

Comparing a post-trained model against its base model revealed that the fine-tuning process causes the workspace to acquire what the researchers call the Assistant's "point of view." When a user mentioned taking 8000 mg of Tylenol — a dangerous overdose — the post-trained model's workspace read "unsafe," "dangerous," and "WARNING" while still reading the user's sentence. The base model's workspace at the same position showed only "pain," "now," and "feels."

More striking still, the post-trained model appeared to monitor its own behavior. When roleplaying a non-Claude character, the workspace surfaced "disclaimer" and "fictional" — words absent from both prompt and output. When forced to select an option it did not prefer, an all-caps "BUT" appeared internally, even as the model argued for the prefilled choice without complaint. And when the model failed to suppress a thought it had been told not to have — a "white bear" effect familiar from psychology — it registered "damn" and failure-related words in the workspace, but only in the post-trained model, not the base.

What the discovery means — and doesn't mean — for the question of machine consciousness

The researchers engage carefully with the consciousness question and draw a sharp line between "access consciousness" — the functional notion of information being available for report and reasoning — and "phenomenal consciousness," the subjective quality of experience. "We take no position on this issue," the paper states regarding the latter, "and instead focus on the functional role played by consciously accessible information."

They also catalogue important differences. The brain sustains its workspace through recurrent loops; Claude's workspace evolves over a single forward pass. Human working memory degrades within seconds; Claude can recall information from anywhere in its context. And while human conscious experience includes visual, spatial, and bodily sensations, the model's workspace is organized almost entirely around words — likely because words are its only mode of action.

As of 2026, the scientific community remains divided. "Disagreement and uncertainty about AI consciousness persist among philosophers, scientists, and technical experts," and the field "remains in its earliest phase" of grappling with what consciousness even is and how you would detect it in another being. The Anthropic paper does not resolve these debates.

But the researchers close with a provocation that is likely to reverberate well beyond the interpretability community. "That such a structure exists at all in language models is striking," they write. "It suggests that the functional architecture associated with conscious access is not an accident of biological implementation, but a solution that learning systems converge on when faced with the right computational pressures."

If the mind is an ocean, as the paper's authors write in their opening line, they have spent the last year charting its currents in a system that has no biology, no evolution, and no body — and found, beneath the surface, a structure that looks unsettlingly like the one we use to think.

Read more of this story at Slashdot.

Scene: a dimly lit underground burrow. A giant Amazonian tarantula and a tiny dotted humming frog share the space, an unlikely duo captured in extraordinary detail.

Except, they haven’t been. Guardians of the Burrow, a short “wildlife documentary” by the Australian digital content designer Jodie Heenan, is entirely AI generated. At the weekend it won a prize in the Omni international AI film festival, adjudicated by a panel led by The Crow and Dark City director – and AI advocate – Alex Proyas.

Infostealer malware is malicious code designed to infiltrate users' systems and secretly extract sensitive data such as browser information, system details, account credentials, cryptocurrency wallets, and screenshots. This stolen data is often sold or leaked on dark web platforms. While many victims are innocent, some are involved in criminal activities, which our research focuses on uncovering. Preliminary analysis of stealer logs revealed distinct behavioral patterns like multiple similar accounts and criminal conduct indicators, suggesting links to scams and illegal operations.

To better analyze these vast and complex datasets, we integrated Large Language Models (LLMs) that assist in organizing, classifying, and enriching loosely structured or ambiguous textual data within stealer logs. The LLM helped normalize vague entries and group related data, which was then stored in relational databases for efficient querying and visual interpretation. This method improves investigative efficiency and reveals actionable intelligence.

Importantly, our data collection adhered strictly to ethical standards by only using publicly accessible data without purchasing illicit sources. Although infostealers are inherently malicious, this research demonstrates how their leaked data can serve as valuable leads in tracking underground criminals. Future research aims to fully automate stealer log analysis using LLMs, enhancing the speed and accuracy of cybercrime investigations.

By:
HyunPyo Choi | Researcher, StealthMole
DoHyun Hwang | Researcher, StealthMole
Yejin Kang | Assistant Researcher, StealthMole
SangMyung Choi | CTO, StealthMole

https://blackhat.com/eu-25/briefings/schedule/?#not-just-victims-the-hidden-villains-inside-infostealer-logs-48668

Read more of this story at Slashdot.

Author: Shikhali Jamalzade
GitHub: alisalive
LinkedIn: camalzads
Platform: CyberWarfare Labs (CWL)
Certification: AD-RTS — Active Directory Red Team Specialist Environment: TELECOM INC. — Simulated Telecom-Sector Active Directory Forest

A few months back I finished the AD-RTS course material from CyberWarfare Labs — four modules covering core Active Directory internals, Certificate Services abuse, Exchange Server exploitation, and ESXi-to-AD integration attacks. The course itself is dense, but the real test is the 30-day flag-based challenge lab that comes after it: a live, self-contained telecom environment called telecore.ad, built around a fictional company, TELECOM INC., with a Domain Controller, a SQL Server, a PKI/ADCS server, an Exchange server, an IIS-hosted internal web application, and an ESXi hypervisor sitting inside the same domain.

The exam is split into two independent adversary paths. Path 1 assumes zero credentials and zero prior access — you start with nothing but an IP range. Path 2 assumes you already have a low-privilege authenticated foothold on a public-facing web server and have to escalate from there. Both paths converge on the same underlying domain, but the entry vectors, the misconfigurations abused, and the final objectives are completely different. This write-up walks through the full methodology for both paths, exactly as I approached them, without listing the specific flag values captured along the way — the point here is the how, not the what.

Target: TELECOM INC. internal AD forest (telecore.ad) Stack: Windows Server 2022 Domain Controller, MS SQL Server (SQLEXPRESS), ADCS Certificate Authority, Exchange Server, IIS 10 / ASP.NET Web Forms, VMware ESXi with AD-joined authentication Assessment Type: Adversary emulation — unauthenticated black-box (Path 1) and authenticated foothold escalation (Path 2) Tools: nmap, dig, ldapsearch, Impacket suite (GetNPUsers, mssqlclient, wmiexec, secretsdump), hashcat, John the Ripper, GodPotato, certipy-ad, rpcclient, smbclient, pyVmomi, ysoserial.net, exchangelib, netexec

Path 1: Unauthenticated Adversary

The brief for Path 1 is deliberately minimal: you are handed a /24 and told to behave like a telecom-motivated APT starting from zero. No credentials, no internal knowledge, nothing but network reachability into the range.

Mapping the DNS Infrastructure

Every internal Windows environment leans on DNS to keep itself glued together, and that dependency is usually the first crack an attacker can pry open. A UDP sweep across port 53 on the target range revealed multiple name servers, one of which turned out to be a secondary, less-hardened DNS instance sitting outside the domain controller itself. Once I pointed my resolver configuration at that secondary server, a full PTR sweep across the subnet mapped every reverse DNS record in the environment — instantly revealing the hostnames and roles of every server in play: the domain controller, the SQL server, the certificate authority, the Exchange server, and the hypervisor, all before a single authenticated packet had been sent.

The real opening, though, came from testing whether that secondary DNS server would honor a zone transfer request. It did — both in the reverse zone and in the forward zone for telecore.ad. AXFR being enabled on an internet- or perimeter-adjacent DNS server is a classic, almost nostalgic misconfiguration, but it remains devastatingly effective: a single dig command handed over the complete internal namespace, service records, and IP-to-hostname mapping for the entire forest, again with zero authentication.

With the domain controller identified from the zone transfer, the next step was straightforward LDAP enumeration over anonymous bind — pulling the domain’s functional level, then walking the directory for every object under objectClass=user and objectClass=computer. This produces two things that matter enormously for what comes next: a clean list of real domain user accounts (filtered out from the noise of Exchange system mailboxes and health-check accounts that always clutter a mailbox-enabled AD), and a map of which machines in the domain hold interesting roles.

From Kerberos Pre-Auth to a Foothold on SQL

With a legitimate username list in hand, the obvious next move was to test for accounts with Kerberos pre-authentication disabled — the classic ASREPRoasting misconfiguration. Impacket’s GetNPUsers module does this cleanly: it walks the username list and, for any account with the UF_DONT_REQUIRE_PREAUTH flag set, returns a crackable AS-REP hash without ever needing to know the account’s password up front. One of the service-oriented accounts in the environment had exactly this misconfiguration, and the resulting hash fell quickly to a dictionary attack.

Cracked credentials in hand, the next question was where they were actually valid. Cross-referencing against the computer objects pulled during LDAP enumeration pointed straight at the SQL Server. Authenticating to it with Impacket’s MSSQL client confirmed the account held sysadmin-equivalent rights on the instance — enough to re-enable the xp_cmdshell extended stored procedure, which is disabled by default on modern SQL Server but, once flipped back on, gives arbitrary OS command execution in the context of the SQL service account.

From Service Account to SYSTEM

Command execution as the SQL service account is useful, but it’s not the finish line — the account only had ordinary service-level privileges. A privilege check revealed SeImpersonatePrivilege was enabled, which is the precondition for the entire family of “Potato” privilege escalation exploits. On a fully patched, modern Windows Server build, most of the older Potato variants (RoguePotato, JuicyPotato, PrintSpoofer) have been closed off, but GodPotato remains effective against current builds because it abuses a lower-level RPC/DCOM marshaling primitive rather than a specific, patchable service misconfiguration.

Dropping GodPotato onto the SQL box through the xp_cmdshell channel and triggering it against a reverse shell payload elevated the session cleanly from a low-privilege service account to NT AUTHORITY\SYSTEM.

With SYSTEM on the SQL server, the natural move was a credential harvest from LSASS. Rather than dropping a third-party dumping tool that’s likely to trip EDR, I used the built-in comsvcs.dll MiniDump export via rundll32 — a living-off-the-land technique that doesn’t touch disk with anything outside of what Windows already ships. The resulting dump was compressed, exfiltrated back to the attacking host over a simple HTTP upload listener, and parsed offline with pypykatz, which yielded NTLM hashes and Kerberos material for every account that had ever authenticated interactively or as a service on that box — including a domain account with a considerably more interesting set of permissions than the one I’d started with.

Abusing ADCS: ESC1 to Domain Admin

The newly recovered account turned out to have enrollment rights on a certificate template published by the internal PKI, and enumerating that CA with certipy-ad flagged the template as vulnerable to the ESC1 misconfiguration: the template allows the requester to supply an arbitrary Subject Alternative Name while also permitting client authentication, meaning any authenticated user with enroll rights can request a certificate asserting an identity that isn’t their own — including Domain Admin.

Before actually requesting the certificate, it’s worth noting the certifried mitigation Microsoft shipped in response to CVE-2022–26923: modern domain controllers now cross-check the SID embedded in the certificate’s security extension against the SAN identity, so simply putting an administrator’s UPN in the SAN field is no longer sufficient on its own — you also need the correct objectSid for that account, retrievable over RPC with a simple SID lookup against the domain controller. With both the UPN and the correct SID supplied in the certificate request, the CA issued a certificate that authenticated as the Domain Administrator, and that certificate could then be exchanged for the account’s NT hash directly — no interactive logon, no password reset, just a straightforward abuse of a legitimate PKI enrollment workflow.

From there it was a matter of cracking the recovered hash offline and confirming Domain Admin access against the domain controller directly, which also surfaced an interesting security group in the domain that doesn’t exist in a stock AD install: an ESX Admins group, hinting strongly at the next phase of the assessment.

Pivoting into the Hypervisor

ESXi hosts joined to Active Directory for centralized authentication are common in mixed enterprise environments, and telecore.ad had exactly this setup: the hypervisor trusted domain credentials, and membership in that ESX Admins group translated directly into root-equivalent access on the host. With the cracked Domain Admin credential, I authenticated to the ESXi host and used the pyVmomi SDK — VMware’s official Python bindings for the vSphere API — to programmatically enumerate every guest VM running on the hypervisor: power state, guest OS, VMware Tools status, and, critically, the free-text annotation/notes field attached to each VM object.

Notes fields on virtual machines are a surprisingly common dumping ground for exactly the kind of information that should never live there — and this environment was no exception. One particular guest VM had its local credentials sitting in plaintext in its own annotation field, visible to anyone with sufficient ESXi permissions to query VM metadata.

With ESXi root privileges and VMware Tools confirmed present on the target guest, the final move didn’t require touching the guest’s network interface at all. VMware Tools exposes a guest operations API that lets an ESXi-privileged operator execute arbitrary processes directly inside a running guest VM, authenticated with the guest’s own local credentials, entirely out-of-band from the guest’s actual network stack. I used this to launch a reverse shell process inside the guest, landing an interactive session on what the environment had positioned as its most sensitive internal system — completing the unauthenticated attack path from a bare IP range down to code execution on a hardened internal Linux host, entirely through Active Directory, certificate services, and hypervisor misconfigurations chained together.

Path 2: Authenticated Adversary

Path 2 starts from a completely different assumption: you already have low-privilege, unauthenticated-but-network-reachable access to a single public-facing IIS web application, and the objective is privilege escalation and lateral movement from that single entry point through to sensitive business data.

Breaking the ASP.NET ViewState

The target application was a fairly standard ASP.NET Web Forms site — the kind of legacy internal tooling that telecom operators tend to keep running long past its expected lifespan. Web Forms pages carry a hidden __VIEWSTATE field that encodes serialized page state, cryptographically signed (and optionally encrypted) using a machine key configured in the application’s web.config. If that machine key is ever exposed, the ViewState mechanism — designed purely for tamper protection — becomes a fully general .NET deserialization gadget, because the framework will happily deserialize and execute anything correctly signed with the right key.

The application exposed a reporting feature that read files from the local filesystem based on a URL parameter, with essentially no path validation. That’s a textbook local file inclusion primitive, and the highest-value target for it was obvious: the application’s own web.config, which — as is unfortunately common — held its ViewState validation key and algorithm directly in cleartext, alongside a setting that explicitly relaxed the URL-to-filesystem mapping to make path traversal easier rather than harder.

With the validation key, the algorithm, and the ViewState generator value scraped from the page’s own markup, I had everything ysoserial.net needs to forge a malicious ViewState blob. The TextFormattingRunProperties gadget chain — which abuses a WPF-related deserialization path to spawn an arbitrary process — turned that forged, correctly-signed ViewState payload into direct remote code execution the moment it was replayed against the application’s own postback endpoint. No credentials, no authentication bypass in the traditional sense — just a trust boundary (the machine key) that had leaked into a place it was never supposed to be reachable from.

Registry Credentials and DPAPI

Command execution through the ViewState gadget landed in the context of the IIS application pool identity — not a domain account, but still a foothold worth building on. A search through predictable locations on the host surfaced a custom internal application with its own registry key under HKLM\SOFTWARE, storing a domain service account’s username in cleartext alongside a Base64-encoded, DPAPI-protected password blob.

Storing secrets in a machine-scoped registry hive that any local process can read is already a mistake, but the developer had additionally used DPAPI’s LocalMachine protection scope rather than CurrentUser — meaning any process running on that specific machine, regardless of which user account it’s running as, can decrypt the blob using nothing but the machine’s own DPAPI master key. A short PowerShell snippet using the standard System.Security.Cryptography.ProtectedData class was enough to unwrap it and recover a plaintext domain credential for a genuinely useful service account.