SW Development: WASI spec for all devices, computers, operating systems

Mozilla tries to do Java as it should have been – with a WASI spec for all devices, computers, operating systems • The Register


Quoting:

"Mozilla this week announced a project called WASI (WebAssembly System Interface) to standardize how WebAssembly code interacts with operating systems. If the project succeeds, it will do what Oracle's Java Virtual Machine does, but better and more broadly.

WebAssembly, or WASM, is a binary format for a virtual machine that can run across multiple hardware architectures. WASM code can be produced from various programming languages like C/C++, Go, and Rust as a compilation target.

WebAssembly has been adopted by all the major web browsers, but it doesn't yet have a standard way to run outside the browser. That's where WASI comes in.

"Code outside of a browser needs a way to talk to the system  –  a system interface," explains Mozilla software engineer Lin Clark in a blog post. "And the WebAssembly platform doesn’t have that yet."

What's up with WASM?

With WASI, WASM code will be able run in the browser or any compliant environment, allowing language agnostic, cross-platform application deployment. Where Portable Operating System Interface (POSIX) provides a way to make source code portable across Unix-like operating systems, WASI aims to make compiled binaries portable across devices and operating systems. It promises a universal runtime that runs at near-native speed.

The Java Virtual Machine (JVM) serves the same purpose but you can't run Java code in a browser without a plugin. And while the language flexibility offered by the WebAssembly platform may be achievable in Java via the GraalVM, the Java ecosystem, open though it may be, still stands in the shadow of Oracle and its claims on Java-related IP.

WASM, being memory safe and tuned for validation, also has security advantages over Java applets, though it still may be vulnerable to control flow hijacking. It also plays nicer with languages like C/C++ and Rust."

Security: WebAuthn what?

This:

https://www.w3.org/TR/webauthn/

Quoting:
"The below use case scenarios illustrate use of two very different types of authenticators, as well as outline further scenarios. Additional scenarios, including sample code, are given later in §12 Sample Scenarios.

1.2.1. Registration

On a phone:

User navigates to example.com in a browser and signs in to an existing account using whatever method they have been using (possibly a legacy method such as a password), or creates a new account.

The phone prompts, "Do you want to register this device with example.com?"

User agrees.

The phone prompts the user for a previously configured authorization gesture (PIN, biometric, etc.); the user provides this.

Website shows message, "Registration complete."

1.2.2. Authentication

On a laptop or desktop:

User pairs their phone with the laptop or desktop via Bluetooth.

User navigates to example.com in a browser and initiates signing in.

User gets a message from the browser, "Please complete this action on your phone."

Next, on their phone:

User sees a discrete prompt or notification, "Sign in to example.com."

User selects this prompt / notification.

User is shown a list of their example.com identities, e.g., "Sign in as Alice / Sign in as Bob."

User picks an identity, is prompted for an authorization gesture (PIN, biometric, etc.) and provides this.

Now, back on the laptop:

Web page shows that the selected user is signed in, and navigates to the signed-in page. (...)"

Security: Passwords and more...

... passwords. A list of the 100000 most common of them BTW:
https://www.ncsc.gov.uk/blog-post/passwords-passwords-everywhere

Quoting:
"I'm a developer. What should I do with these files?

If your product is unlikely to have access to the internet when deployed (or you don't want to rely on an external service), you can include a check against one of these files in your authentication flow. It's up to you how you handle cases where the password matches one of these, but you should enable users to use tools such as password managers.

If you can make use of an external service, there are options such as Troy Hunt's Pwned Passwords API. Troy has written a really good blogcovering how different companies have implemented this feature, that may help you to design your own flow.

Alternatively, look at ways to reduce the load on your users by looking at alternative authentication flows (like supporting single sign-on), and by keeping an eye on upcoming standards such as WebAuthn - we'll have more on this in the future."