​This should be the last beta release of Paint.NET 5.2 before the final, stable release which I’m planning for the day of-or-after the release of .NET 11. That should be the second week of November.

This build fixes a few bugs, adds a new Uzbek (uz) translation, introduces an official plugin SDK Nuget package, adds a “Nearest Neighbor (Antialiased)” mode to the Move Pixels tool, and includes further improvements to the experimental Wine packages.

Nearest Neighbor (Antialiased) is similar to what the emulator community calls “sharp bilinear”. It first uses Nearest Neighbor to upscale to the ceiling of the requested scaling factor (e.g. from 100% to 700% instead of from 100% to 632%), and then uses bilinear to downscale to the target scaling factor (700% -> 632%). This retains the blocky/pixelated look of Nearest Neighbor, but with the added effect of antialiased edges. This works for both scaling and rotation.

(credit: Stardew Valley)

Changes since 5.2 Beta (build 9772):

• New: Added a “Nearest Neighbor (Antialiased)” resampling mode to the Move Pixels tool
• New: Paint.NET.Plugin.SDK nuget package. You no longer have to manually add references with paths hardcoded for your local system.
• New translation: Uzbek (uz)
• Fixed tooltips for effect plugin menu items not going away when using the keyboard
• Wine: PNG and JPEG images should work a lot better now, with proper metadata support
• Wine: GPU effect plugins that use ComputeSharp.D2D1 are now working
• Wine: Stability and memory usage should be improved by using a better method for selecting a device for software rendering paths

Download and Install

This build is available via the built-in updater as long as you have opted-in to pre-release updates. From within Settings -> Updates, enable “Also check for pre-release (beta) versions of paint.net” and then click on the Check Now button. You can also use the links below to download an offline installer or portable ZIP.

You can also download the installer here (for any supported CPU and OS), which is also where you can find downloads for offline installers, portable ZIPs, and deployable MSIs.

For Linux, the experimental builds for Wine can be downloaded here. It can also work on Mac  but that is not the primary focus at this time.

​

Microsoft Teams will let organizations plug in certified third-party tools that scan meeting audio and video for deepfakes, with the rollout starting in mid-November 2026 on Teams for desktop, Mac and web. Microsoft says the outside provider does the detection, while Teams only shows the alerts and controls. However, the software giant hasn’t named any providers, licensing, or what meeting data those vendors get to see.

Teams getting this specific ability makes all the more sense, as the FBI warned in July that “AI-generated content has advanced to the point that it is often difficult to identify,” including fake executives on real-time video calls.

Microsoft Teams is getting deepfake detection, but Microsoft won’t be the one scanning

The feature first showed up on the Microsoft 365 roadmap on October 2 as “Third-party synthetic audio and video detection in Microsoft Teams,” and it’s still listed as in development. Synthetic media is AI-generated content, like a cloned voice of your CFO or a face-swapped video of a vendor you haven’t met before.

Microsoft’s admin notice, MC1509787, made sure to mention who does the work. “Synthetic media detection is performed by the third-party provider,” it says, while “Microsoft Teams provides the platform integration and experiences for surfacing and acting on detection signals from supported providers.”

Microsoft also changed the schedule on October 22. The original notice planned general availability from late November to mid-December, but the revised one only commits to a Targeted Release between mid-November and late November. For everyone else, Microsoft says it “will communicate via Message center when we are ready to proceed.”

The roadmap only lists Desktop, Mac and Web. Microsoft’s separate impersonation warnings for Teams meetings, also due in November, list Android and iOS, but deepfake detection doesn’t, at least for now.

Here’s how a deepfake detection bot will flag someone in your Teams meeting

Microsoft’s Graph documentation already has a beta API called reportSyntheticMedia, which shows how it works.

A certified detection bot has to be admitted to the call, and your tenant admin has to grant it the Calls.ReportSyntheticMedia.All permissions. The bot then flags a participant with a confidence score between 0.0 and 1.0, a low, medium, or high severity, and whether it thinks the content is malicious. Microsoft’s examples include a “voiceClone” audio detection and “faceSwap” and “lipSync” video detections.

Microsoft says the result is propagated to “all participants via roster updates,” which tells us that everyone in the meeting gets the signal. It won’t be limited to the organizer. Microsoft also asks bots to report no more than once per minute per participant.

On the admin side, the notice asks IT teams to pick a provider, deploy its app from Manage apps in the Teams admin center, grant permissions, and configure meeting policies. Teams PowerShell already has two policy settings for it, SyntheticMediaDetection and SyntheticMediaDetectionAppId, though Microsoft says they “will have no effect” until the feature is fully released.

Interestingly, the documentation says the default app ID mentions “Microsoft Detection when 1P is available.” So Microsoft may have its first-party detector in the works, too, though we can’t confirm that yet.

Microsoft hasn’t said what these deepfake detectors get to see in your meetings

Microsoft’s compliance note says “certified third-party providers may analyze meeting audio/video signals,” and asks admins to “review provider terms, data handling, and compliance documentation before enabling.”

For context, when Teams uses its own AI to enhance audio and video, Microsoft says your meeting’s audio and video “never leave Teams and aren’t stored anywhere, by anyone.” That promise is about Microsoft’s processing, and it doesn’t automatically cover an outside vendor’s bot.

Some vendors already sell Teams deepfake apps. Sensity’s documentation, for example, says its bot “joins the call and captures 30 seconds of audio/video” for each analysis. Microsoft hasn’t said whether Sensity or anyone else is certified.

So, we still don’t know which providers are certified, what certification requires, which licenses you need, whether media is processed in the cloud, how long vendors keep it, or whether it can train their models. We also don’t know if every participant will be told that a detection bot is listening, which is a fair question after the privacy backlash against Microsoft’s own Facilitator AI in Teams.

How it’s different from Teams’ Report a concern button

Microsoft already lets people flag suspicious meetings with Report a concern, which Windows Latest first covered in August. The admin notice for it, MC1466296, planned general availability from mid-October to late October, and it covers Android and iOS, too.

	Report a concern	Third-party deepfake detection
Who flags it	A meeting participant	A provider’s detection bot
What it flags	Phishing, impersonation, scams, social engineering	Synthetic or manipulated audio and video
Where it goes	Teams admin center and Microsoft Defender	Every participant, via roster updates
Default	On, with the “Allow users to report meetings” policy	Needs a provider, permissions and policy

 

Report a concern isn’t automatic, obviously, as a person has to spot the fake, and research says people are bad at it. In a 2023 UCL study with 529 participants, people identified deepfake speech only 73% of the time, and training barely helped. A 2024 meta-analysis of 56 papers shows overall human deepfake detection accuracy at 55.54%, which isn’t reliably better than a coin toss. Also, the funny part is that we all think we’re good at spotting deepfakes, even when we’re not.

A deepfake warning in Teams won’t be proof of fraud

A confidence score is still a guess, but I guess something is better than nothing. Also, it doesn’t help that Microsoft hasn’t published accuracy or false-positive rates for any provider. Teams being so popular, and Microsoft with all its resources, Redmond does have a responsibility in preventing deepfake scams. I wonder how well the third-party tools perform if a participant has a bad webcam or an intentionally patchy internet connection.

Of course, I’m not understating a very welcome security layer, although I’d love to see Microsoft put the same energy into other aspects of Teams, like how it idles at around 1GB of RAM as a WebView2 app.

Would you trust a third-party bot to be an attendee in your Teams meetings?

The post Microsoft confirms Teams will let third-party tools scan your meetings for deepfakes from November appeared first on Windows Latest

Microsoft has clarified that it isn’t killing WinUI and XAML after it began testing an experimental framework called Microsoft.UI.Reactor. Given Microsoft’s reputation for giving up on UWP and killing Silverlight before, it’s not a surprise some developers have had doubts.

For those unaware (or if you’re not a developer), WinUI is Microsoft’s native UI framework. Apps built with it generally follow Windows 11’s design, like the Settings app. On the other hand, XAML is the markup language developers use to describe an app’s interface.

Reactor builds on WinUI and offers a new way to describe those same native interfaces directly in C#, without writing XAML. So it was quite obvious that Reactor wasn’t supposed to replace WinUI, but it does make you wonder if this is the FINAL nail in the coffin of XAML, which has felt neglected for years at this point.

I asked Microsoft and was redirected to its new document as well as the open-source materials.

“WinUI is the foundation. XAML is a first-class way to use it, it isn’t being deprecated, and it’s still getting active investment,” Microsoft’s Alexandre Zollinger Chohfi wrote in an October 21 developer blog post.

It’s quite funny that Microsoft had to say it explicitly, but it did the right thing.

After Silverlight and UWP, developers have reasons to be cautious

I’ve been closely following Windows development for a decade now, and Microsoft has a history of killing products. It’s just as bad as Google, or even worse, if you look at the effort involved.

Microsoft ended support for Silverlight on October 12, 2021. UWP remains supported “on paper,” but Microsoft itself no longer builds new apps using UWP, and its own documentation says it is “no longer under active development,” so it’s fair to call it effectively dead. In fact, the entire “one app, everything” vision for Windows is now dead.

WhatsApp replaced its native UWP app with a WebView2 version. In our earlier test of the web version, RAM usage climbed from about 600MB to 1.2GB while scrolling through chats. Playback is sped up 2.5 times. Video WindowsLatest.com

Microsoft instead recommends that devs use the Windows App SDK and WinUI for new apps.

I have seen Microsoft munch-munch, chomp-chomp, gobble-gobble, gulp (aka kill) projects like Project Astoria (Android to Windows), the Windows Subsystem for Android, and its iOS bridge project right in front of me after it made a HUGE deal out of everything. And I am not even going to get started on Windows Phone.

You can argue that Silverlight or UWP had different purposes from WinUI, but there’s no denying that both help explain why another Microsoft framework announcement can make developers nervous.

As a consumer, and later a developer, I’ve watched Microsoft change its strategies every few years, and it’s been a hell of a ride. We don’t have any compelling reasons to believe that today’s Microsoft is different from Microsoft a few years ago. In fact, a new company-wide reorg to cut costs and invest more in AI could once again put Windows on the back burner and derail its current revival efforts.

Microsoft says it’s sticking with WinUI

We’ve heard similar promises earlier this year as well, at least for WinUI. At the Build 2026 developer conference, Microsoft’s Chris Anderson said the company had “no intention of building a new framework.”

It even began referring to WinUI 3 as simply “WinUI,” so developers do not end up assuming that WinUI 4 is on the way and that it would be better to wait.

Chris Anderson explains why Microsoft is dropping the “3” from WinUI at Build 2026. Video Microsoft / WindowsLatest.com

The idea is to prove “continuity,” and I think it’s similar to Microsoft 365. You don’t wait for Microsoft 365 v2 every year because you know it’s being updated, and there’s no need to wait for a major milestone before you start using it.

Microsoft tried a similar idea with Windows 10 when it said Windows 10 would be the last version of Windows, but it eventually reversed course. I think there was also a problem for OEMs, as Windows as a service gave users fewer reasons to buy new hardware when their existing PCs could keep getting new features.

Reactor changes how you write a WinUI app

Now, why the heck is Reactor a big deal? Not everything Microsoft announces has a bad outcome, and I think Reactor could be one of the good ones. If it works, Windows could actually end up with far more native apps, and we may be saying a final goodbye to WebView-based apps.

It’s exactly what some developers were probably looking for. I am not talking about Windows-only developers, but those who use SwiftUI, React, or Jetpack Compose. If you’re familiar with one of those frameworks, a typical WinUI project still involves learning XAML. This new idea of using a style that feels familiar could be a game changer, if you ask me.

Right now, if you’re a developer, and use to XAML for WinUP apps, you would have already noticed that the code managing its state and markup for the interface can be spread across several files, and it can be worse than that in some cases. But Reactor takes care of it by allowing developers to describe appearence and maintain component’s state together. This reduces the number of files compared to XAML.

It’s also worth noting that if developers begin using Reactor (C#) to do markup and drop XAML, they will be still using the real WinUI controls, including the text boxes, navigation views, and other controls.

Microsoft has assured that Reactor does not introduce a separate renderer or a browser-based interface, which is why WinUi remains safe, and is the foundation of this entire experiment.

“Reactor is not a new UI platform. It is a new way to describe WinUI content,” Microsoft noted in the project’s GitHub documentation.

One developer also loved it and noted, “My reaction was ‘oh, finally’. I hope this catches on and helps native windows development to becomes more friendly to devs coming from other stacks. Can you imagine a world without the Electron bloatware crap.”

The post Windows 11’s native app framework isn’t being killed this time, Microsoft promises, after Silverlight and UWP appeared first on Windows Latest

On Thursday, Pennsylvania Governor Josh Shapiro signed the Artificial Intelligence Deceptive Advertising Act into law, requiring disclosures on AI-generated ads. The law requires any ad - whether it's a still image, video, audio, or text - that "has been significantly modified or generated by artificial intelligence" to include a label in the same format as the ad itself. That applies to TV commercials from multi-billion-dollar companies, as well as restaurants' ugly, crowded flyers about their wing specials.

Pennsylvania is one of the first states to require disclosures on AI content. And it requires those labels regardless of where an ad …

Read the full story at The Verge.

Learn how Dijkstra's algorithm helps Zorb find the cheapest route through a JavaScript grid of rocks, mud, and hamburgers, even when that route takes more steps.

See the video at: Walk-Thru: BlazorData.net, Deploy Blazor Data Orchestrator Into Your Own Azure Subscription Blazor Data Orchestrator is an open-source job orchestration platform built on .NET Aspire and Blazor Server . Until now, getting it into Azure meant cloning the repository, installing the Azure Developer CLI, the .NET SDK and Docker, and running azd up . BlazorData.net replaces all of that. It installs and updates Blazor Data Orchestrator in your own Azure subs