Sr. Content Developer at Microsoft, working remotely in PA, TechBash conference organizer, former Microsoft MVP, Husband, Dad and Geek.
153038 stories
·
33 followers

Congress Wants To Hand Your Parenting To Big Tech

1 Share
An anonymous reader quotes a report from the Electronic Frontier Foundation (EFF): Lawmakers in Washington are once again focusing on kids, screens, and mental health. But according to Congress, Big Tech is somehow both the problem and the solution. The Senate Commerce Committee held a hearing [Friday] on "examining the effect of technology on America's youth." Witnesses warned about "addictive" online content, mental health, and kids spending too much time buried in screen. At the center of the debate is a bill from Sens. Ted Cruz (R-TX) and Brian Schatz (D-HI) called the Kids Off Social Media Act (KOSMA), which they say will protect children and "empower parents." That's a reasonable goal, especially at a time when many parents feel overwhelmed and nervous about how much time their kids spend on screens. But while the bill's press release contains soothing language, KOSMA doesn't actually give parents more control. Instead of respecting how most parents guide their kids towards healthy and educational content, KOSMA hands the control panel to Big Tech. That's right -- this bill would take power away from parents, and hand it over to the companies that lawmakers say are the problem. [...] This bill doesn't just set an age rule. It creates a legal duty for platforms to police families. Section 103(b) of the bill is blunt: if a platform knows a user is under 13, it "shall terminate any existing account or profile" belonging to that user. And "knows" doesn't just mean someone admits their age. The bill defines knowledge to include what is "fairly implied on the basis of objective circumstances" -- in other words, what a reasonable person would conclude from how the account is being used. The reality of how services would comply with KOSMA is clear: rather than risk liability for how they should have known a user was under 13, they will require all users to prove their age to ensure that they block anyone under 13. KOSMA contains no exceptions for parental consent, for family accounts, or for educational or supervised use. The vast majority of people policed by this bill won't be kids sneaking around -- it will be minors who are following their parents' guidance, and the parents themselves. Imagine a child using their parent's YouTube account to watch science videos about how a volcano works. If they were to leave a comment saying, "Cool video -- I'll show this to my 6th grade teacher!" and YouTube becomes aware of the comment, the platform now has clear signals that a child is using that account. It doesn't matter whether the parent gave permission. Under KOSMA, the company is legally required to act. To avoid violating KOSMA, it would likely lock, suspend, or terminate the account, or demand proof it belongs to an adult. That proof would likely mean asking for a scan of a government ID, biometric data, or some other form of intrusive verification, all to keep what is essentially a "family" account from being shut down. Violations of KOSMA are enforced by the FTC and state attorneys general. That's more than enough legal risk to make platforms err on the side of cutting people off. Platforms have no way to remove "just the kid" from a shared account. Their tools are blunt: freeze it, verify it, or delete it. Which means that even when a parent has explicitly approved and supervised their child's use, KOSMA forces Big Tech to override that family decision. [...] These companies don't know your family or your rules. They only know what their algorithms infer. Under KOSMA, those inferences carry the force of law. Rather than parents or teachers, decisions about who can be online, and for what purpose, will be made by corporate compliance teams and automated detection systems.

Read more of this story at Slashdot.

Read the whole story
alvinashcraft
15 minutes ago
reply
Pennsylvania, USA
Share this story
Delete

Evernote 11 adds AI assistant, semantic search, and meeting notes

1 Share
Evernote 11 has arrived, the first major update to the popular note-taking app in five years. The new release gains three artificial intelligence features: AI Assistant, Semantic Search, and AI Meeting Notes. The new features sit alongside the app’s existing tools for notes, tasks, and organization. Work on version 11 has been underway for roughly two years. During that period, the app has received hundreds of smaller updates focused on performance, syncing, and reliability. Evernote 11 groups that longer-term work into a single release and adds new AI-based tools across the tool. Federico Simionato, product lead at Evernote, said: “Through… [Continue Reading]



Download video: https://www.youtube.com/embed/0let_BX8ahM
Read the whole story
alvinashcraft
16 minutes ago
reply
Pennsylvania, USA
Share this story
Delete

Surfshark adds post-quantum protection to its WireGuard VPN

1 Share
Surfshark has added post-quantum protection to its WireGuard VPN, with the aim of protecting users against future risks rather than fixing a problem being faced right now. The new addition focuses on how secure connections are set up, not on day-to-day browsing speed or features people can actually see. VPNs work by encrypting data as it travels across the internet, especially on public or shared networks. Encryption is secure today because breaking it would take current computers an impractical amount of time. Quantum computers could do the same work far more quickly, weakening that protection. Post-quantum protection Post-quantum cryptography tries… [Continue Reading]
Read the whole story
alvinashcraft
16 minutes ago
reply
Pennsylvania, USA
Share this story
Delete

Why Your Code Review Process Might Be Missing Its Biggest Security Risks

1 Share

Abstract

1 Introduction

2 Background and Related Work

  • Software Security
  • Coding Weaknesses
  • Security Shift-Left
  • Modern Code Review
  • Code Review for Software Security
  • Security Concern Handling Process in Code Review

3 Motivating Examples

4 Case Study Design

  • Research Questions
  • Studied Projects
  • Data Collection
  • Coding Weakness Taxonomy
  • Study Overview
  • Security Concern Identification Approach (RQ1)
  • Alignment Analysis of Known Vulnerabilities (RQ2)
  • Handling Process Identification (RQ3)

5 Preliminary Analysis

  • PA1: Prevalence of Coding Weakness Comments
  • PA2: Preliminary Evaluation of our Security Concern Identification Approach

6 Case Study Results

7 Discussion

8 Threats to Validity

  • Internal Validity
  • Construct Validity
  • External Validity

\

7 Discussion

In this section, we discuss the implications of our results and provide practical recommendations for practitioners and potential future work. 1) Various coding weaknesses that may lead to security issues can be raised during code reviews. Our first preliminary analysis (PA1) in Section 5 shows that coding weaknesses were raised in the code review process 21 - 33.5 times more often than explicit vulnerabilities. This finding supports our intuition that the reviewers tend to focus on issues in source code. Therefore, it is more natural for the reviewers to identify coding weaknesses than security issues. This implication aligns with the previous work (Gon¸calves et al., 2022) that the cognitive load required for code reviews is lower if the reviewers already have the relevant knowledge. Indeed, our RQ1 shows that the raised security concerns in code reviews of OpenSSL and PHP cover nearly 90% of the CWE-699 weakness types (i.e., 35 out of 40 categories, see Table 10). This confirms our presumption that a variety of coding weaknesses can be raised by reviewers during the code review process. As shown in the motivating examples in Section 3, such coding weaknesses can lead to security issues. It can be implied that the coding weaknesses that may introduce security issues can potentially be identified during the code review process although the weaknesses did not yet explicitly expose the vulnerable outcomes (Braz et al., 2021). Our manual observations from RQ1 also show that the code changes may potentially be vulnerable if the author did not address the raised security concerns. For instance, Figure 7 shows that vulnerabilities such as CVE-2008-498963 and CVE-2012-582164 could be introduced into the code if the Improper Certificate Validation coding weakness (CWE-295) under the Authentication Errors category (CWE-1211) was not raised by a reviewer.

\ Recommendation: As we found that coding weaknesses can be identified in code reviews, our findings suggest that practitioners and/or other software projects could adopt the coding weaknesses taxonomy (i.e., CWE-699) to assist code reviews. A list of coding weaknesses should help the team increase the awareness of the potential problems that can lead to security issues without requiring deep security knowledge. A recent controlled experiment of Braz et al. (2022) has shown that a code review checklist could help reviewers better find security issues. Hence, one of the possible ways to adopt the coding weaknesses taxonomy for code reviews is to incorporate it into a code review checklist. Future work should investigate the effectiveness and practicality of using coding weaknesses as a code review checklist for identifying and mitigating security issues during the code review process. Moreover, as coding weakness are more frequently discussed than the security issue, coding weakness can also be an effective proxy for understanding secure code review practices

\ 2) Coding weaknesses related to the known vulnerabilities of the systems are not frequently discussed in code reviews. Our RQ2 shows that some types of coding weaknesses were less frequently discussed compared to the known vulnerabilities (see Figure 10). In particular, we found that Memory Buffer Errors (CWE-1218) and Resource Management Errors (CWE-399) are the least frequently discussed coding weaknesses in OpenSSL and PHP (4%-9%), albeit the high percentages of known vulnerabilities (17%-29%). Furthermore, our motivating examples in Section 3 highlighted that such coding weaknesses can lead to a serious vulnerability. For example, OpenSSL’s Heartbleed is a known vulnerability related to weakness Out-of-bounds Read (CWE125) which is a type of memory buffer error.

\ These coding weaknesses were rarely discussed maybe because they are generic and easy to be overlooked. Hence, the reviewers may have failed to notice them. To mitigate this problem, the reviewers should be aware of these latent coding weaknesses in order to properly prioritize them in the code reviews. In addition to the known vulnerabilities, our RQ1 indicates that the security concerns in code reviews can vary from project to project. Particularly, OpenSSL reviewers were concerned about direct security threats (e.g., Authentication Errors (CWE-1211 and Random Number Issues (CWE-1213)), while PHP reviewers were more concerned about data controlling (e.g., Type Errors (CWE-136)). As OpenSSL is an encryption library for secure communication and PHP is a programming language, it can be implied that the application domain may correlate with the coding weaknesses that reviewers can raise. This finding also supports our results that coding weaknesses such as User-interface Security Issues (CWE-355) and Encapsulation Issues (CWE-1227) were neither found in our results nor appear in the known vulnerabilities because they are less related to the application domains of the studied projects.

\ Recommendation: Our findings suggest that it is essential to identify the specific coding weaknesses that are significant, highly prone to introduce security issues, and relevant to the application domain of the projects. Thus, rather than reviewing all types of coding weaknesses, a selected set of coding weaknesses can be prioritized for effective code reviews. Prioritization of coding weaknesses during code reviews can be based on known vulnerabilities and the unique concerns of the projects that were raised in the past. Future work can investigate a systematic approach for identifying and prioritizing the types of important coding weaknesses for individual projects in this context.

\ 3) Not all the raised security concerns were addressed within the same code review process. The security concern handling scenarios identified in our RQ3 reveal a shortcoming in the code review process. Our results show that approximately a third of the security concerns from coding weaknesses (30%-36%, see C2 in Table 11) were acknowledged without fixes in the process. We observed that developers promised to fix some of the acknowledged concerns in the new independent code changes (10%-18%), but some concerns were left without fixing due to disagreement about the proper solution (18%-20%). Nevertheless, approximately half of the unresolved concerns (6%-9%) were eventually merged. This result implies a possible risk that security issues can slip through the code review process into the software product. The incomplete code reviews or unclean code changes that contain security concerns related to coding weaknesses should be held from merging until all security concerns are resolved. Otherwise, the remaining coding weaknesses in code changes can become security issues in the future.

\ This implication is consistent with the findings of the prior work which reported that relentless and inconclusive discussion could impact the code review quality (Kononenko et al., 2015), and the incomplete code reviews and the unsuccessfully fixed can negatively affect the developer’s contribution (Gerosa et al., 2021). Recommendation: Code reviews with security concerns should be escalated if the final resolutions cannot be agreed upon before merging. Security experts or experienced developers should be included in such code reviews to investigate complex security concerns. In addition, the mechanisms to notify the reviewers of the incomplete code reviews or the insufficiently addressed security concerns could reduce the risk that security issues will slip through the code review process into the software product. Our suggestion aligns with Wessel et al. (2020) who reported that the adoption of an automated mechanism such as code review bots can increase the number of merged pull requests, and, hence, reduce the number of abandoned code reviews. Kudrjavets et al. (2022) also observed that the automated bots can remind the developers of the pending tasks in the code review process without inciting negative feelings. Hence, future work should investigate an approach to identify incomplete code reviews or the insufficiently addressed security concerns to help developers increase awareness.

:::info Authors:

  1. Wachiraphan Charoenwet
  2. Patanamon Thongtanunam
  3. Van-Thuan Pham
  4. Christoph Treude

:::

:::info This paper is available on arxiv under CC by 4.0 Deed (Attribution 4.0 International) license.

:::

\

Read the whole story
alvinashcraft
16 minutes ago
reply
Pennsylvania, USA
Share this story
Delete

GitHub releases COPILOT SDK and Google's new open translation models! - Developer News 03/2026

1 Share
From: Noraa on Tech
Duration: 3:06
Views: 1

Today we cover the new Copilot SDK, Google's TranslateGemma, and more!

00:00 Intro
00:12 Visual Studio Code
00:45 GitHub
02:20 Google
02:41 Microsoft 365

-----

Links

Visual Studio Code
• Copilot Studio Extension for Visual Studio Code Is Now Generally Available - https://devblogs.microsoft.com/microsoft365dev/copilot-studio-extension-for-visual-studio-code-is-now-generally-available/?WT.mc_id=MVP_274787
• Building docfind: Fast Client-Side Search with Rust and WebAssembly - https://code.visualstudio.com/blogs/2026/01/15/docfind?WT.mc_id=MVP_274787
GitHub
• Hierarchy view now available in GitHub Projects - https://github.blog/changelog/2026-01-15-hierarchy-view-now-available-in-github-projects/
• GitHub Copilot now supports OpenCode - https://github.blog/changelog/2026-01-16-github-copilot-now-supports-opencode/
• GitHub Copilot bring your own key (BYOK) enhancements - https://github.blog/changelog/2026-01-15-github-copilot-bring-your-own-key-byok-enhancements/
• Copilot SDK in technical preview - https://github.blog/changelog/2026-01-14-copilot-sdk-in-technical-preview/
• GPT-5.2-Codex is now generally available in GitHub Copilot - https://github.blog/changelog/2026-01-14-gpt-5-2-codex-is-now-generally-available-in-github-copilot/
• Upcoming deprecation of select GitHub Copilot models from Claude, Google, and OpenAI - https://github.blog/changelog/2026-01-13-upcoming-deprecation-of-select-github-copilot-models-from-claude-and-openai/
Google
• TranslateGemma: A new suite of open translation models - https://blog.google/innovation-and-ai/technology/developers-tools/translategemma/
Microsoft 365
• Announcing Microsoft Entra PowerShell v1.2.0 - https://devblogs.microsoft.com/entrapowershell/announcing-microsoft-entra-powershell-v1-2-0/?WT.mc_id=MVP_274787

-----

🐦X: https://x.com/theredcuber
🐙Github: https://github.com/noraa-junker
📃My website: https://noraajunker.ch

Read the whole story
alvinashcraft
17 minutes ago
reply
Pennsylvania, USA
Share this story
Delete

The State of WebAssembly – 2025 and 2026

1 Share
Annual Report

Welcome to the annual State of WebAssembly (Wasm) article, where I’ll recap the events of 2025 and preview what 2026 could bring to this rapidly evolving technology.

As we enter 2026, it’s a good time to reflect on the significant progress made over the past year and look ahead at what’s on the horizon.

Browser Coverage Note

When I mention browser support for different WebAssembly features, I typically focus on Chrome, Firefox, and Safari. I don't mention Edge or Opera because they're built using the same Chromium open-source project as Chrome. It's still a good idea to test your modules in these browsers, but they usually inherit the WebAssembly work done for Chrome.

To verify feature support (including non-browser runtimes), check the official WebAssembly feature list. If your browser supports the feature, there will be a checkmark in the ‘Your browser’ column to the right of the feature’s name.

Last year’s State of WebAssembly.

Now, let’s dig in.

2025 in Review

When using WebAssembly in the browser, most teams want cross-browser support or at least a solid fallback, before adopting a new feature. Because Safari still represents a large share of web traffic, its Wasm support often determines when a feature is viable in production. In 2025, the Safari team continued closing key gaps.

Safari

Two Safari additions in 2025 helped complete cross-browser support for important Wasm proposals:

Exception Handling (exnref) — Safari 18.4

  • There was already an Exception Handling proposal live in all browsers. The original proposal was adjusted to include a new ‘exnref’ value to address a number of issues with the existing approach that included difficulty for the JavaScript API to handle the identity of thrown exceptions. The exnref value also allows for a reduction in the complexity of both the specification and engine implementations.

    Because exception handling was already live in all browsers, the original approach will continue to work until it’s determined that it’s safe to be removed.

JavaScript String Builtins arrived in version 26.2.

  • This feature wraps the JavaScript String primitive so that there’s no need for glue code when calling functions like ‘compare’ or ‘concat’. This simplifies modules and improves performance. You can find more information about string builtins here

    Glue code is simply JavaScript code written by a developer, provided by a framework, or generated by a compiler toolchain to act as a go-between when the module’s code can’t do something independently. When the JavaScript code is called, it does some work on the module’s behalf.

    The JavaScript String Builtin feature is a first step towards a larger goal of allowing the use of other builtin objects and primitives from a WebAssembly module without the need for JavaScript glue code

In addition, Safari shipped several Wasm runtime improvements in 2025:

In addition to the features just mentioned, Safari also received the following WebAssembly improvements:

  • Support for JIT-less Wasm was added so that modules will still work if Just-In-Time compilation is disabled
  • Large WebAssembly modules now run faster thanks to a new in-place interpreter being used to evaluate modules first
  • The following methods have been added to the WebAssembly JavaScript API allowing for the conversion of a module’s memory between fixed-length and resizable buffers:
  • WebAssembly.Memory.prototype.toResizableBuffer()
  • WebAssembly.Memory.prototype.toFixedLengthBuffer()

Standardized Features

Over this past year, the following features have reached phase 5 (completed standardization) and are now considered “done” at the specification level:

  • Exception Handling with exnref
  • JavaScript String Builtins
  • Memory64

The linear memory of a WebAssembly module was originally limited to a maximum of 4 GB due to the use of 32-bit indexes. Because some applications need more than 4 GB of memory, 64-bit indexes have been added.

There are some proposals in the works that may help improve things but, at the moment, there are a couple things to be aware of with this feature before you jump in:

  • Even though a 64-bit pointer can theoretically access up to 16 exabytes of memory, web browsers currently limit memory to a maximum of 16 GB.
  • Browser engines were able to make some optimizations around 32-bit pointers that they’re not able to do with 64-bit pointers. Without those optimizations, unfortunately, there is a potentially large performance hit depending on the workload. The following article goes into detail about the performance penalty when using 64-bit mode.

For now, the recommendation is that you should only use Memory64 if you need more than 4 GB of memory.

Progress of Other Features

Beyond the features that completed standardization, several other proposals made meaningful progress in 2025 with some shipping broadly while others are still gated behind a flag.

Note on “behind a flag”

When a feature is “behind a flag,” it only works if a user/developer turns on an experimental setting (usually for pre-release testing). Flags can change browser behavior, and the underlying implementations may be rough or expose security gaps. Use with caution.

Relaxed SIMD

When SIMD (Single Instruction, Multiple Data) was proposed for WebAssembly, 128-bit fixed-width SIMD was chosen as a starting point because it was seen as having the most hardware support.

SIMD is a type of parallel processing that takes advantage of a CPU’s SIMD instructions to perform the same operation on multiple points of data simultaneously. This can result in large performance gains for things like image processing.

There are additional SIMD instructions that are possible depending on the hardware so the Relaxed SIMD proposal’s aim is to take advantage of some of those additional instructions. If you’d like to learn more about Relaxed SIMD, the proposal can be found here.  

This proposal was standardized in 2024 but was still behind a flag in Firefox and Safari by the end of the year. In 2025, this feature came out from behind a flag in Firefox but is still behind a flag in Safari.

JavaScript Promise Integration (JSPI)

This feature’s aim is to allow a Wasm module’s synchronous code to make asynchronous Web API calls. When this happens, the browser would pause the module’s execution while it waits for the call to complete. More information on this proposal can be found here. 

This proposal is now at phase 4 and is live in Chrome. It’s still behind a flag in Firefox.

Safari hasn’t publicly committed to if they’re working on this feature. They did have some concerns about the proposal and didn’t initially want to implement it. That changed late in 2025 when they removed their objection so that’s a promising development.

If you want to use this feature before it arrives in Safari, one approach that’s possible is to use feature detection for JSPI and fall back to the slower Asyncify approach if JSPI isn’t available.

WebAssembly CSP

CSP (Content Security Policy) is a security mechanism used by web developers to specify what resources are allowed to be loaded by the browser for their website. When a CSP is used, the browser will block the download of files, or execution of code, that are not included in the allow lists.

WebAssembly CSP extends CSP limitations to WebAssembly modules. Using the ‘wasm-unsafe-eval’ keyword in the ‘script-src’ directive explicitly allows the loading, compilation, and instantiation of WebAssembly modules. The proposal is here if you’d like to read more about it: 

Because wasm-unsafe-eval is supported across all major browsers, this work has advanced and is being standardized.

Wide Arithmetic

For Wasm code to perform 128-bit integer operations, it needs to use 64-bit instructions, or external library calls, but this is currently 2 to 7 times slower than native performance. This proposal’s aim is to add new instructions to improve the performance of 128-bit arithmetic operations.

During 2025, this proposal moved to phase 3 and is now being implemented in runtimes.

Stack Switching

The goal of this proposal is to allow a WebAssembly module to manage multiple execution stacks concurrently by using continuations. A continuation represents a snapshot of execution on a particular stack that could be suspended or resumed. Language providers would use these continuations to build the non-local control flow features that they need like async/await, coroutines, or generators/iterators to name a few. A more detailed explanation can be found here if you’d like to learn more: 

This proposal also moved to phase 3 this past year.

There are also a number of interesting proposals in phases 1 and 2 but they’re still early in the discussion and planning stages so I won’t mention them here. If you’d like to see what they are, the list of all proposals can be found here

WebAssembly 3.0

WebAssembly 3.0 is a specification milestone: it’s a clear line in the sand for “modern Wasm support,” bundling a growing set of standardized features under one version label.

When WebAssembly was launched as an MVP in 2017, it was considered 1.0.

In 2022, a version 2.0 of the WebAssembly specification was started as a way of saying that, if a runtime supports WebAssembly 2.0, it supports all of the standardized features that are a part of it.

This past year, WebAssembly reached another milestone when 3.0 was announced. All standardized features since 2.0, including the following, are now considered part of 3.0:

  • Custom Text Format Annotations
  • Deterministic profile
  • Exception Handling
  • Garbage Collection
  • JavaScript String builtins
  • Memory64
  • Multiple Memories
  • Relaxed SIMD
  • Tail Calls
  • Typed References

 

Many of these 3.0 features are already shipping in the major web browsers and in some of the stand-alone runtimes. If you’d like to investigate the status of a feature for your target runtimes, you can use the following website.

If you’d like to learn more about the list of features in 3.0, details can be found here.

Outside the Browser

Kotlin

Kotlin is a cross-platform high-level programming language that’s designed to be a modern alternative to Java but is fully interoperable with the Java ecosystem. 

Because it’s multiplatform, it can compile to Java bytecode for the JVM (Java Virtual Machine), JavaScript, and native machine code.

With the 2.2.20 release in September of 2025, a beta version of the Kotlin/Wasm tool is now available that allows Kotlin code to be compiled to WebAssembly. 

.NET

.NET 10 was released in November of 2025 and comes with a lot of performance and reliability improvements. It also includes better diagnostic collecting either through C# code, via the JavaScript interop, or by using the browser’s built-in developer tools.

In 2025, we saw the continued innovation that we’ve come to expect from The Uno Platform. In addition, with every release the Uno Platform’s performance has improved:

  • With their 5.6 release in early 2025, they were able to improve ahead-of-time (AOT) compilation that resulted in 2.5 times faster execution for most scenarios and up to 10 times faster execution in certain cases.
  • With their 6.3 release in October, they made significant improvements around image decoding allowing for faster load times and smoother UIs in apps that have heavy image workloads.
  • Uno Platform’s latest release in November continues this trend by taking advantage of the performance and reliability improvements in .NET 10.

Aside from the performance improvements brought by both .NET and the Uno Platform, 2025 saw the announcement of a closer collaboration between the two organizations. With .NET being open source, the Uno Platform has been helping with .NET improvements for some time now but this makes things more official. From the WebAssembly side of things, this collaboration means a focus on something that many .NET developers have been asking for: multithreading.

WebAssembly System Interface (WASI)

WASI is a standardization effort led by the Bytecode Alliance for WebAssembly’s use outside the browser to ensure things are done in a secure and consistent way. It also includes the creation of a set of interfaces that your modules can access called worlds. For example, there’s a ‘wasi-http’ set of interfaces that your module can use to send and receive HTTP requests.

WASI also leverages the Component Model Wasm feature for the linking of multiple modules that are potentially written in different languages. The Component Model is also how modules interface with the WASI worlds.

The WASI work is being released in phases and advanced to 0.2 early in 2024. Work then started towards 0.3 by adding native async support to the Component Model and adjustmenting the WASI worlds to take advantage of the new async capabilities. 

Although WASI 0.3 is not quite ready, the Wasmtime runtime now has experimental support for 0.3 so that users can start testing.

The current WASI roadmap can be found here if you’re interested.

Debugging

One of the biggest arguments that I’ve heard against WebAssembly adoption over the years is a lack of tooling support with debugging being a major hurdle. Debugging support still varies by programming language but things have improved quite a bit since WebAssembly was first released. 

When the MVP of WebAssembly was first introduced in 2017, debugging options were limited. You could use a printf approach where you would send information to the console as the code executed. Or, you could use the browser’s developer tools to examine and step through a module’s WebAssembly Text Format (WAT) representation of the code. It was something at least but it definitely wasn’t an ideal way to debug your code.

In 2019, Chrome started adding in DWARF support but Firefox opted to go with source maps. In both cases, you still needed to use the browser’s developer tools to work with it but these options brought the ability to step through your original source code rather than the WAT code. This made things easier to work with because the WAT representation of the code doesn’t know information like variable names making things difficult to follow if there are a lot of variables.

DWARF is a debugging format that gives debuggers the information they need to map the low-level machine code instructions back to the original source code. 

The following article gives a quick glimpse into how things looked with WAT debugging, then source maps, and finally DWARF debugging when it was first being introduced in browsers.

There’s still work to do but fast forward to 2025 and debugging has improved. Now, debugging can often happen from within your IDE without needing to use the browser’s developer tools. This video from WASM I/O in March of 2025 gives a good example of this in action by using the LLDB debugger from VS Code to debug WebAssembly executing in a stand-alone runtime.

For some programming languages, like .NET, debugging from the IDE is possible without going through LLDB. .NET interacts with the browser directly through a debugging proxy. In November, .NET went a step further and announced the ability to do performance profiling as well as extract diagnostic data as shown in this video.

Adoption

Every year, WebAssembly’s use continues to grow in the browser. Based on the Chrome Platform Status metrics (click the ‘Show all historical data’ checkbox), of the number of websites visited by Chrome users, the sites using Wasm have increased by almost 1% again this past year to now sit at 5.5%. We’re not told what the total number of websites visited overall are but this is a potentially large amount given the number of sites on the internet. This count doesn’t include Safari, Edge, or Firefox browsing figures either so the percentage is likely even higher. 

Almost all of the top 25 programming languages have some WebAssembly support including Kotlin’s recently released beta compiler mentioned earlier. Although some popular languages, like SQL, might not compile to Wasm, it’s possible for SQL to leverage WebAssembly. For example, SQLite and MySQL Heatwave allow for the creation of WebAssembly-based User-Defined Functions (UDF) in the database that your SQL can then call.

I recently had the opportunity to do the technical review of the “Server-Side WebAssembly” book and one of the coding projects was the creation of a Wasm UDF for SQLite. The book also has a lot of interesting projects demonstrating how WASI and the Component Model work making it an interesting read.

WebAssembly’s use outside the browser is growing rapidly in many different locations including IoT, embedded devices, serverless, edge, cloud native, application code calling into Wasm modules or implementing plug-in systems and the list goes on. 

IoT devices are a subset of embedded systems where they have an internet connection allowing the device to communicate and share data. Embedded devices are a broader group where their focus is on a specific task, can operate independently, and usually with very limited resources (e.g. an engine control unit).

One example of WebAssembly’s use in the embedded devices space is demonstrated by a company called Atym. They have a runtime that can work on devices with as little as 256 KB of memory and the runtime uses containers that can be distributed via standard Docker repositories. It’s even possible to leverage AI with this system by using TinyML. The following video gives a demo of this in action: https://youtu.be/iDpG1yFDW1g

Edge computing is one many areas that takes advantage of WebAssembly’s small size, fast startup times, and security model. Cloudflare, Fastly, and Fermyon are some of the edge computing companies currently leveraging Wasm. For the past year, Fermyon has been working with Akamai, considered the largest CDN company globally, and it was just announced that Akamai is buying Fermyon in order to embrace the promise of WebAssembly.

People are using WebAssembly in a lot of interesting ways and one that stood out for me recently was the idea of compiling PHP and WordPress to Wasm. The aim is to run a WordPress website on the edge where you’d have a CDN type setup for your website. This can give low latency because it’s potentially closer to your user than a server might be. It can also reduce your costs because, rather than having a server that’s running all the time, your website spins up when a request comes in and then shuts down once the request is complete. This should result in less energy used, which is better for the environment, and also allows your website to scale based on demand. The following talk from WASM I/O goes into detail about how this works: 

With 2025 now behind us, let’s take a look at what the possibilities are for this year.

Expectations for 2026

Given that all browsers support the WebAssembly CSP proposal, it’s possible that this feature will be standardized this year.

Firefox has announced that they plan to bring the Branch Hinting feature out from behind a flag with their release that’s expected to ship in late February. With this change, all browsers will support this proposal.

  • The Branch Hinting proposal’s aim is to help improve the performance of modules by giving engines hints about which paths are most likely to be executed.

The Type Reflection specification is something that I expected to move to phase 4 in 2025 because it has been behind a flag in all browsers for some time now.

  • The Type Reflection proposal is meant to allow the WebAssembly JavaScript API to query information about the data types of functions imported and exported from a module.

Apparently, one reason why the proposal hasn’t moved forward is because it no longer has a champion. 

In late 2025, I was surprised to see that the team is considering demoting this proposal back down to phase 2 for two reasons:

  • The first reason being the need to find a new champion.
  • The second reason for the suggested demotion is because the specification may need some updates to reflect changes made by other proposals.

Safari

Over the past few years, Safari has done a lot of work to catch up to the other browsers in terms of Wasm support and I don’t see any indication of that slowing down. I’m hopeful that we’ll see support added for the following features in 2026 because they’re now standardized and live in the other browsers:

  • Multiple memories
  • Memory64
  • Relaxed SIMD

Safari had some concerns about the JavaScript Promise Integration (JSPI) proposal initially but removed their objection in late 2025. With the proposal now at phase 4, and because Safari now has someone assigned to a ticket to implement the feature, I’m hopeful that we’ll hear more about this before the end of the year.

JSPI is still behind a flag in Firefox so there’s a possibility that this will come out from behind the flag in Firefox this year as well.

There is a workaround that’s possible until the JSPI feature becomes available by using Asyncify. It doesn’t work as well, which is why this proposal exists, but that might be an option if your module needs asynchronous support in the meantime.

Other features that are possible this year

ESM - Source Phase Imports

ESM stands for ECMAScript Modules and is a standard format for the packaging of JavaScript code for reuse.

Right now, to call a function in a WebAssembly module, you need to fetch the .wasm file and instantiate it manually as shown in the following example:

JAVASCRIPT
const req = fetch("./myMath.wasm");

WebAssembly
  .instantiateStreaming(req, { …imports… })
  .then(res => { 
    console.log(res.instance.exports.add(1, 3)); // Prints 4 to the browser’s console
  });

The eventual goal with the ESM Integration proposal is to be able to just use the import keyword and the host would handle the downloading and instantiation for you. This is referred to as evaluation phase imports and the following is an example of what this could look like:

JAVASCRIPT
import { add } from ‘./myMath.wasm’

console.log(add(1,3)); // Prints 4 to the browser’s console

It was decided that a first step towards supporting evaluation phase imports would be implementing source phase imports as shown in the following example:

JAVASCRIPT
import source mathModule from "./myMath.wasm";

const myInstance = await WebAssembly.instantiate(mathModule, { …imports… });
console.log(myInstance.add(1, 3)); // Prints 4 to the browser’s console

In last year’s article I didn’t have an expected timeline but things are further along now. The specification is being worked on in the WHATWG W3C group and is now at stage 3.

Chrome and Firefox are currently working on this proposal. A ticket also exists for this with Safari but I’m not sure of the status beyond that.

I’m hoping to see this made available for testing this year.

.NET

After the release of .NET 10 in November 2025, a planning kickoff meeting happened in December for version 11. A follow-up meeting was held in January to answer questions and give insights into .NET plans from the web browser side of things. The January meeting can be found here if you’re interested.

Every release of .NET includes improvements around WebAssembly and that’s expected to continue with .NET 11 but more incrementally for this version. The reason for only incremental improvements this time is because they’re working on transitioning from the Mono runtime to the CoreCLR runtime and don’t want to put effort into a big feature only to have to redo it in the new runtime. 

That said, the team is looking into adding some features into version 11 to make developer’s lives a bit easier. One example is a web worker template to make it easier for WebAssembly logic to run in a background thread, rather than in the browser’s main UI thread, which would help keep the UI responsive.

A preview of the new CoreCLR runtime is expected in .NET 11 but it’s not expected to officially ship until .NET 12 in 2027. When the new runtime is released, they plan to target WebAssembly 3.0 which is interesting because that version includes features like Garbage Collection and Memory64.

Another exciting thing to watch out for this year is the Uno Platform’s work towards implementing multithreading.

WASI

The Component Model is currently being adjusted with native async support and the WASI worlds are being modified to take advantage of the new async capabilities. This part of the work is expected to be complete in February of this year and will be released as WASI 0.3.

Once 0.3 has been released, a series of 0.3.x releases are expected to add in additional async features like cancellation tokens, stream optimizations, and threads to name a few. The following link gives more information about the 0.3 roadmap if you’re interested.

The WASI 1.0 release is then expected to happen in late 2026 or early 2027.

As work has been happening on the features for 0.3, the Component Model proposal is also being refined. A lot of people have been watching this proposal for a while and were asking why it’s still at phase 1. I’m pleased to report that things are about to change. There was a suggestion of possibly advancing the proposal to phase 2 once WASI 0.3 is released, so that’s possible, but it’s definitely expected to start moving up through the phases once WASI 1.0 is released.

In Conclusion

2025 was another great year for WebAssembly-related progress. This past year saw several features, like Exception Handling with exnref and JavaScript String Builtins, become available in Safari rounding out support in all major browsers. We also saw several proposals advance through the standardization phases. On top of that, WebAssembly 3.0 was announced bringing a host of new features into the main specification.

We saw the release of Kotlin’s beta Wasm compiler, the release of .NET 10, and several releases of the Uno Platform that brought performance improvements with each release. The Uno Platform also announced a collaboration with Microsoft that will see a focus on bringing multithreading into .NET’s WebAssembly story.

The Bytecode Alliance has been busy adding async support to WASI in preparation for a 0.3 release. With that work, the Wasmtime runtime now has experimental support for WASI 0.3. The 0.3 release is expected in February of this year with a potential 1.0 release by the end of 2026 or early 2027.

The Component Model proposal is being worked on at the same time as WASI 0.3 and is expected to start advancing through the specification phases either after the 0.3 or 1.0 release.

We also saw that tooling is maturing as debugging options continue to improve for DWARF support and the LLDB debugger allows you to debug Wasm in stand-alone runtimes from VS Code. Some IDEs even integrate with browsers so that developers can debug in the IDE rather than in the browser’s developer tools. This past year, we also saw .NET add in the ability to do performance profiling and extract diagnostic data.

WebAssembly is gaining a lot of adoption but its use is more behind the scenes helping with portability, performance, and security. It’s a technology that’s not super flashy so it’s not always obvious that it’s being used which I think leads people to believe that it’s not as popular as it really is. In the browser over the past year, we’ve seen another 1% increase in use across websites that Chrome users visit to now sit at 5.5% in Chrome’s Platform Status metrics. Almost all of the top 25 programming languages support Wasm. In the cases where the language doesn’t compile to Wasm, like SQL, we’re seeing some of those languages leveraging WebAssembly in other ways like calling into Wasm-based User-Defined Functions.

Edge computing is one of many areas that are a natural fit for Wasm. In 2025, Fermyon was purchased by Akamai, the largest CDN company globally, in order to embrace the promise of WebAssembly. In related edge news, the ability to compile PHP and WordPress to Wasm so that it can run on the edge was demonstrated showing an interesting idea for how websites might be deployed in the future to reduce latency, reduce energy consumption, and scale better.

With the maturing of the WebAssembly specifications, developer tooling improving, programming language support growing, and the wide variety of areas where Wasm now runs, I have no doubt that 2026 is going to be another great year for WebAssembly. I think the biggest challenge for WebAssembly is marketing. We need to get the word out that Wasm is no longer an experiment. It’s ready for production. If you have something you want to build directly with WebAssembly, you can do that or you can also leverage Wasm by using tooling like the Uno Platform where you code in C# and it just works in the browser.

The post The State of WebAssembly – 2025 and 2026 appeared first on Uno Platform.

Read the whole story
alvinashcraft
17 minutes ago
reply
Pennsylvania, USA
Share this story
Delete
Next Page of Stories