Browser Plug-ins have been deprecated for Modern Browsers

Modern browsers like Google Chrome and Microsoft Edge no longer support traditional plug-ins (such as Adobe Flash, Java Applets, or Silverlight).
Key Changes:

1. Google Chrome:
   • Stopped supporting NPAPI (Netscape Plugin Application Programming Interface) plug-ins in Chrome 45 (2015).
   • Adobe Flash was officially discontinued and removed from Chrome in 2020.
   • Instead of plug-ins, Chrome now relies on extensions (which use JavaScript, HTML, and CSS) and built-in browser capabilities like WebAssembly.
2. Microsoft Edge:
   • The legacy version of Edge (before it switched to Chromium) did not support NPAPI plug-ins.
   • The new Chromium-based Edge (since 2020) also does not support NPAPI plug-ins.
   • Like Chrome, Edge relies on extensions and built-in browser features for added functionality.

Alternative Technologies:

• HTML5 (for multimedia content)
• WebAssembly (for running compiled code in the browser)
• Progressive Web Apps (PWA) (for enhanced web experiences)
• Extensions (for additional browser features)

WebAssembly (Wasm) enhances the security of applications in several ways, making it a valuable tool for developers looking to build secure and efficient web applications. Here’s how a developer can leverage WebAssembly for improved security:

1. Sandboxed Execution Environment
   • Wasm runs in a sandboxed virtual machine within the browser or other environments, meaning it is isolated from the host system.
   • It has no direct access to the DOM, system files, or network, reducing the risk of security vulnerabilities like code injection or buffer overflow attacks.
2. Memory Safety
   • Unlike traditional low-level languages like C and C++, which can suffer from memory corruption issues, Wasm enforces strict memory boundaries.
   • Each Wasm module gets its own linear memory space, preventing unauthorized access to other parts of memory and mitigating issues like buffer overflows and use-after-free attacks.
3. No Direct System Calls
   • Wasm code cannot directly execute system calls (syscalls). Instead, it relies on the host environment (e.g., browser, server runtime) to provide controlled access to system resources.
   • This significantly reduces the attack surface and prevents exploits that depend on direct system interactions.
4. Reduced Attack Surface
   • Since Wasm modules are compiled from source code (C, C++, Rust, etc.) into a portable binary format, they avoid many of the traditional vulnerabilities associated with interpreted JavaScript.
   • Obfuscation and minification are built into Wasm binaries, making reverse engineering and code tampering more difficult.
5. Capability-Based Security Model
   • WebAssembly follows a capability-based security model, meaning that modules cannot access anything beyond what they are explicitly granted.
   • Developers must explicitly define imports and exports, ensuring that untrusted code does not gain unnecessary privileges.
6. Prevention of Side-Channel Attacks
   • WebAssembly is designed to be resistant to timing attacks and speculative execution vulnerabilities (like Spectre and Meltdown) by enforcing constant-time execution in many cases.
   • Since Wasm uses an explicit execution model, it reduces the ability of attackers to extract sensitive data via CPU timing variations.
7. Efficient Code Execution with Performance and Security
   • WebAssembly allows developers to write security-sensitive modules in Rust or C++, compile them to Wasm, and execute them efficiently in a controlled environment.
   • This enables cryptographic operations, data validation, and sanitization to be performed securely without relying on potentially unsafe JavaScript implementations.
8. Server-Side Security with Wasm on Edge Computing
   • Wasm is not limited to browsers; it can run in serverless environments and edge computing platforms like Cloudflare Workers and Fastly’s Compute@Edge.
   • Since Wasm functions are stateless and isolated, they provide a secure execution model for running untrusted code in distributed environments.
9. Prevention of Injection Attacks
   • Since WebAssembly is a binary format, it is not susceptible to script injection attacks like XSS (Cross-Site Scripting) or SQL Injection.
   • WebAssembly modules do not interpret user-supplied code, reducing the risk of executing malicious JavaScript.
10. Code Signing and Integrity Checks
    • Developers can sign Wasm modules and verify their integrity before execution, ensuring that the code has not been tampered with.
    • This is useful in supply chain security, where ensuring that the Wasm module has not been compromised before deployment is critical.

Conclusion WebAssembly significantly enhances application security by 1) sandboxing execution, enforcing strict memory safety, eliminating direct system access, and reducing attack surfaces. By using WebAssembly for performance-critical and security-sensitive tasks, developers can mitigate vulnerabilities inherent in JavaScript and traditional native applications while ensuring fast and safe execution.

The following series of images exhibits the legacy of nature of plug-ins which have been discontinued/

Plug-ins let designers take advantage of many types of multimedia without having to supply or license the technology required for viewing them.
Some of the disadvantages of using plug-ins are as follows:

1. Plus-ins are proprietary technology.
2. Plug-ins may take up space in the browser window, limiting space for other elements.
3. Not all plug-ins are available for all platforms.
4. Most plug-ins have to be installed by the user.
5. Some organizations prohibit users from downloading and installing plug-ins.

Developers should carefully consider each use of plug-ins.

• Delivering Multimedia
  Now that you know how multimedia is created, you should also know there are two ways to deliver multimedia elements (video and audio) on the Web:
  1. Stream the file to the visitor's computer so that the sound or movie starts to play as the file continues to download.
  2. Download the entire file to the visitor's computer and then play it from within the browser or as a Java applet.
  
  Downloading an entire file before playing it back eliminates restrictions on playback quality, but visitors may find the download time unacceptably long, particularly for audio files, which can be very large. When a multimedia file is streamed, the playback starts while the file continues to download.
  The next lesson wraps-up this module.