Coder Legion - Recent posts tagged devices

Cloud Computing Is Just npm install for Infrastructure

Sun, 16 Aug 2026 08:44:28 +0000

Hello, I'm Ganesh. I'm building git-lrc, an AI code reviewer that runs on every commit. It is free, unlimited, and source-available on Github. Star git-lrc on GitHub to help more developers discover the project. Do give it a try and share your feedback for improving the product.

Every time you pull in a third-party package instead of writing something yourself, you make a trade: you stop owning the internals, but you're still on the hook for how you use it, what it costs you at scale, and what happens the day it breaks in production.

Cloud computing runs on the exact same trade: you're just importing servers, storage, and networking instead of a library.

That mental model answers the questions that actually matter once you move past the marketing pitch: If I don't manage the OS anymore, what am I still on the hook for? Do I self-host, use a managed service, or mix both? Why does my bill move even when my code didn't change? And what happens when the dependency I'm relying on goes down, gets slow, or degrades under load?

In this article, I'll walk through the 5 concepts that answer those questions.

1. The Shared Responsibility Model

While cloud providers manage a significant portion of the infrastructure, customers still have important security and operational responsibilities.

This concept is known as the Shared Responsibility Model, and the division of duties changes depending on whether you're running workloads On-Premises, or using IaaS, PaaS, or SaaS.

On-Premises: You Manage Everything

When applications run in your own data center, every component—data, devices, accounts, IAM, applications, network controls, operating systems, physical servers, networking, and the datacenter itself is your responsibility.

Since there's no cloud provider involved, there's nothing to share.

Infrastructure as a Service (IaaS)

Examples include virtual machines such as Amazon EC2, Azure Virtual Machines, and Google Compute Engine.

The provider supplies the physical infrastructure, hosts, networking, and datacenters, while you manage data, devices, accounts, IAM, applications, network controls, and operating systems.

IaaS offers the most flexibility of the cloud models but also requires the most operational management.

Platform as a Service (PaaS)

Examples include Azure App Service, AWS Elastic Beanstalk, Google App Engine, and Heroku.

PaaS removes the burden of managing operating systems and infrastructure. Customers still manage data, devices, and accounts; IAM, applications, and network controls are shared; and the provider manages the OS, infrastructure, hosts, networking, and datacenters.

Software as a Service (SaaS)

Examples include Microsoft 365, Salesforce, Google Workspace, and Dropbox.

Customers manage data, devices, and accounts, with IAM as a shared responsibility.

The provider manages everything else—applications, network controls, OS, infrastructure, hosts, networking, and datacenters making SaaS the model with the lowest operational overhead.

Shared Responsibility at a Glance

Service Model	Customer Manages	Shared	Provider Manages
On-Premises	Everything	None	Nothing
IaaS	OS, applications, IAM, network controls, data	None	Infrastructure & physical hardware
PaaS	Data, devices, accounts	IAM, applications, network controls	OS, infrastructure & physical hardware
SaaS	Data, devices, accounts	IAM	Applications, OS, infrastructure & physical hardware

No matter which model you choose, your data, devices, and user accounts remain your responsibility.

As you move from On-Premises → IaaS → PaaS → SaaS, the provider takes on progressively more of the operational burden but protecting users, managing access, and securing data always stay in your hands.

2. Cloud Deployment Models: Public, Private, and Hybrid

A cloud deployment model defines where your infrastructure is hosted, who owns it, and who can access it.

The three primary models are:

Public
Private
Hybrid

each offer different levels of flexibility, security, and control.

Public Cloud

Owned and operated by a provider such as Microsoft Azure, AWS, or Google Cloud Platform, with infrastructure shared among multiple customers.

Characteristics: no hardware to maintain, rapid provisioning, pay-as-you-go pricing, high scalability, global availability.
Advantages: lower upfront costs, rapid deployment, automatic maintenance, high availability ideal for startups and growing businesses.
Limitations: less control, shared environment, potential compliance restrictions.
Best for: web applications, mobile backends, dev/test environments, AI/ML workloads, disaster recovery.

Private Cloud

Dedicated to a single organization, hosted either in-house or by a third-party provider, with no resource sharing across organizations.

Characteristics: dedicated infrastructure, greater administrative control, enhanced security, custom networking.
Advantages: better compliance support, increased data privacy, full infrastructure control, custom security policies.
Limitations: higher costs, requires skilled administrators, slower scaling.
Best for: government, healthcare, banking and finance, and other heavily regulated enterprises.

Hybrid Cloud

Combines public and private environments, letting workloads and data move between them as needed This keeps sensitive workloads private while using the public cloud for scale.

Characteristics: combines both models, flexible workload placement, supports gradual migration, optimizes cost and performance.
Advantages: flexibility, business continuity, disaster recovery, cost optimization, easier migration from on-premises.
Limitations: more complex architecture, requires strong networking and identity management, more governance overhead.
Best for: large enterprises, seasonal traffic spikes, backup/DR, organizations migrating to the cloud.

Quick Comparison

Feature	Public Cloud	Private Cloud	Hybrid Cloud
Ownership	Cloud provider	Single organization	Both
Cost	Low upfront	Higher	Moderate
Scalability	Excellent	Limited by hardware	Excellent
Security	Good	Very High	High
Maintenance	Provider	Organization	Shared
Flexibility	High	Moderate	Very High

Example: An e-commerce company might run its customer-facing website on the public cloud to handle traffic spikes during sales events, store payment records in a private cloud for compliance, and connect both through a hybrid architecture for secure data exchange balancing security, performance, and cost.

3. The Consumption-Based Pricing Model

Instead of purchasing expensive servers and networking equipment upfront, the cloud lets businesses pay only for what they use, an approach known as the consumption-based model, or pay-as-you-go pricing. Think of it like an electricity bill: you pay for the units you consume, not a fixed monthly amount.

Traditional Infrastructure vs. Cloud Consumption

Traditional Infrastructure	Consumption-Based Cloud
Large upfront hardware investment	No upfront infrastructure purchase
Pay even when servers are idle	Pay only for resources you use
Capacity planning required	Scale resources up or down instantly
Hardware maintenance is your responsibility	Cloud provider manages infrastructure

Key Benefits

No upfront costs : start using services immediately without buying hardware or licenses.
Pay only for what you use : compute hours, storage, database transactions, data transfer, and function executions are all billed based on actual consumption.
Scale when needed : resources grow during demand spikes and shrink afterward, an elasticity that's expensive to replicate on-premises.
Better cost optimization : usage-based billing encourages practices like shutting down unused VMs, right-sizing instances, using autoscaling, and monitoring spend regularly.

Consumption-Based vs. Subscription-Based Pricing

Consumption-Based	Subscription-Based
Pay for actual usage	Fixed monthly or yearly fee
Flexible costs	Predictable costs
Ideal for changing workloads	Best for consistent workloads
Easy to scale	Usually includes predefined resource limits

An e-commerce site running a consumption-based model keeps only a few virtual machines running on normal days, automatically adds instances during festival sales, and scales back down once traffic normalizes, paying only for the extra capacity while it's actually in use.

To avoid cost surprises, it's worth setting spending budgets, enabling billing alerts, monitoring usage, and reviewing bills regularly.

4. High Availability vs. Scalability

Two qualities determine whether users get a smooth experience in the cloud: high availability and scalability. They're often mentioned together, but they solve different problems.

High Availability

High availability (HA) is a system's ability to remain operational even when failures occur. Rather than preventing every failure, cloud platforms detect problems and automatically shift workloads to healthy resources. Providers achieve this through redundant infrastructure, multiple data centers and Availability Zones, automatic failover, and SLAs that define expected uptime.

Example: if a server crashes during an online banking transaction, traffic is redirected to a healthy instance so customers don't lose access to their accounts.

Scalability

Scalability is the ability to handle increasing or decreasing workloads by adjusting resources—a matter of capacity rather than uptime.

Vertical scaling (scale up): add more CPU, RAM, or faster storage to an existing machine—simple, but limited by hardware ceilings.
Horizontal scaling (scale out): add more instances and distribute traffic across them preferred for cloud-native applications, and often automated based on CPU, memory, or request volume.

High Availability vs. Scalability

High Availability	Scalability
Keeps services running during failures	Handles increasing workloads efficiently
Focuses on minimizing downtime	Focuses on increasing capacity
Uses redundancy and failover	Uses additional computing resources
Improves reliability	Improves performance under load

A movie ticket booking platform sees a traffic surge when tickets for a blockbuster release, the application automatically adds servers to handle demand (scalability), and if one server fails mid-rush, requests are redirected to healthy servers without interrupting users (high availability).

A well-designed cloud application aims for both.

5. Reliability and Predictability: Building Trust Beyond Uptime

Hosting an application in the cloud doesn't, by itself, guarantee a great experience. Users expect applications to stay available, recover quickly from failures, and perform consistently regardless of workload—expectations built on two more fundamental principles: reliability and predictability.

Understanding Reliability

Reliability is a system's ability to continue operating, or recover quickly, when failures occur. Hardware failures, software bugs, network outages, and even data center outages are inevitable in distributed systems, so rather than trying to eliminate every failure, cloud platforms are designed to detect, isolate, and recover from them automatically, distributing applications across multiple VMs, Availability Zones, or regions so that if one component goes down, another takes over with minimal disruption.

For example, if a virtual machine crashes unexpectedly, the platform can automatically provision a replacement and restore service without manual intervention.

Understanding Predictability

Predictability is about delivering consistent application behavior, performance, and costs over time, giving teams confidence that infrastructure will respond as expected under both normal and peak workloads. Providers support this through tools that monitor infrastructure health, analyze workload patterns, estimate future resource needs, and automatically adjust capacity. The result:

Stable application response times
Consistent system behavior
Predictable infrastructure costs
Better resource planning
Improved operational efficiency

Reliability vs. Predictability

Reliability	Predictability
Focuses on recovering from failures	Focuses on maintaining consistent performance and behavior
Ensures applications remain available	Ensures applications perform consistently over time
Achieved through redundancy, failover, and fault tolerance	Achieved through monitoring, autoscaling, analytics, and capacity planning
Measured by availability, resilience, and recovery	Measured by performance consistency, scalability, and cost stability

Reliability answers: "Will the application continue running if something fails?" Predictability answers: "Will the application continue performing as expected as demand changes?"<

Why Passkeys Don’t Work on Some Devices: Device-Level Limitations

Tue, 21 Apr 2026 21:13:10 +0000

Passkeys fail on some devices because they depend on WebAuthn, operating systems, browsers, and secure hardware working together. Passkeys are not a standalone feature; they are a coordinated system involving the browser (client), authenticator (device), and server (relying party).

Devices fail passkey authentication when any layer is incomplete or inconsistent. Older operating systems lack platform authenticators like iCloud Keychain or Windows Hello. Browsers may implement WebAuthn differently or incompletely. Hardware limitations such as missing TPM or Secure Enclave prevent secure key storage.

Cross-device passkeys depend on cloud sync systems like Apple iCloud or Google Password Manager. When sync fails, passkeys become unavailable across devices.

Passkeys fail due to system-level fragmentation, not single-point bugs.
Reliable passkey authentication requires full stack support across device, OS, and browser.

Quick TL;DR

Passkeys depend on WebAuthn, not just frontend implementation.
OS, browser, and hardware must all support passkeys.
Older devices fail due to missing secure hardware modules.
Cross-device login depends on ecosystem sync (Apple/Google).
Fallback authentication is mandatory for production systems.

What Are Passkeys (Deep Technical Context)

Passkeys are FIDO2 credentials built on WebAuthn and CTAP protocols. They replace passwords using asymmetric cryptography.

Each passkey includes:

A public key stored on the server
A private key stored inside a device authenticator

The private key never leaves the device. Authentication happens through cryptographic signatures.

WebAuthn defines how browsers interact with authenticators and servers.

Key Components

Relying Party (Server) → verifies identity
Client (Browser/OS) → mediates authentication
Authenticator (Device) → stores keys and signs challenges

Passkeys are WebAuthn credentials stored in authenticators.
Authentication uses cryptographic signatures instead of passwords.

For full conceptual explanation:
https://mojoauth.com/blog/what-are-passkeys-and-how-they-work

How Passkeys Actually Work

Registration Ceremony

Server generates challenge
Browser calls navigator.credentials.create()
Authenticator generates key pair
Private key stored in secure hardware
Public key returned with attestation
Server stores public key

WebAuthn ensures keys are scoped to the domain.

Passkeys are origin-bound and cannot be reused across sites.

Authentication Ceremony

Server sends challenge
Browser calls navigator.credentials.get()
Authenticator signs challenge
User verifies identity (biometric/PIN)
Signed assertion returned
Server verifies signature

Authentication proves possession of private key without exposing it.

Authenticator Types (Critical for Failures)

1. Platform Authenticators

Built into device
Examples:
- iCloud Keychain
- Android Keystore
- Windows Hello

2. Roaming Authenticators

External devices
Examples:
- Security keys (YubiKey)
- Phones via QR login

3. Multi-Device Passkeys

Synced via cloud
Stored across devices

Different authenticator types behave differently across devices.

OS-Level Support (Precise Reality, Not Marketing)

Apple Ecosystem

OS	Real Behavior
iOS 16+	Full passkey support
iOS 15	No native support
macOS Ventura (13)+	Full support
macOS Monterey	Limited

Important Constraints

iCloud Keychain must be enabled for passkey storage and sync.
User must be signed in with a valid Apple ID.
Device must have passcode or biometric authentication enabled.
Passkeys are only available on iOS 16+, iPadOS 16+, and macOS Ventura+.
All devices must be part of the same Apple ecosystem for seamless sync.

Passkeys on Apple devices depend entirely on iCloud Keychain infrastructure.

Hidden Limitations

Passkeys are tightly coupled to Apple’s ecosystem and account system.
Cross-platform usage relies on QR-based fallback mechanisms.
iCloud sync delays can cause passkeys to appear missing on new devices.
Shared devices or multiple Apple IDs can break passkey availability.
Enterprise restrictions may disable iCloud Keychain, blocking passkeys.

Apple passkeys work best within a fully aligned Apple ecosystem.
Cross-device reliability decreases outside Apple-controlled environments.

Android Ecosystem

OS	Real Behavior
Android 14+	Stable support
Android 9–13	Partial / fragmented
Android <9	Unsupported

Requirements

Google Play Services
Google Password Manager
Device lock enabled

Hidden Problems

OEM fragmentation (Samsung vs Pixel behavior differs)
Inconsistent biometric APIs

Android passkey support varies by manufacturer and OS version.

Windows Ecosystem

OS Support and Reality

OS	Passkey Support
Windows 11 (22H2+)	Full support
Windows 10	Partial / inconsistent
Older versions	Not supported

Windows passkey support is strongest on Windows 11 with modern updates.

Important Constraints

Windows Hello must be configured for passkey authentication.
TPM 2.0 is required for secure key storage.
Device must have PIN, fingerprint, or facial recognition enabled.
Browser must support WebAuthn (Edge or Chrome recommended).
User must allow credential storage at OS level.

Windows passkeys rely on Windows Hello as the platform authenticator.

Hidden Limitations

Enterprise group policies can disable WebAuthn or Windows Hello.
Some corporate devices restrict biometric or PIN-based login.
TPM misconfiguration can silently break passkey registration.
Older Windows builds lack proper WebAuthn integration.
Cross-device passkey sync is weaker compared to Apple or Google ecosystems.

Windows passkey reliability depends heavily on enterprise configurations.
Corporate environments are a common source of passkey failures.

Browser-Level Behavior on Windows

Microsoft Edge provides the most stable passkey experience.
Google Chrome supports passkeys but depends on Windows Hello integration.
Firefox has limited passkey UX and inconsistent support.

Browser choice significantly impacts passkey behavior on Windows.

Common Failure Scenarios

Windows Hello not configured → passkey prompt never appears
TPM disabled → passkey creation fails silently
Corporate policy blocks WebAuthn → authentication fails
Using outdated Windows 10 → inconsistent behavior

Most Windows passkey failures are caused by configuration, not code.

Practical Fixes

Enable Windows Hello (PIN or biometrics)
Ensure TPM 2.0 is active in BIOS
Update to latest Windows 11 version
Use Edge or latest Chrome
Check enterprise policy restrictions

Correct configuration resolves most Windows passkey issues.

Linux Reality (Important Edge Case)

No native passkey ecosystem
Requires:
- External authenticator
- QR-based login

Linux lacks first-class passkey ecosystem support.

Browser Support (Detailed + Realistic)

Browser support for passkeys is based on WebAuthn implementation, but real-world behavior varies across platforms. A browser may support WebAuthn technically but still fail in certain device or ecosystem scenarios.

Browser support for passkeys is platform-dependent, not just version-dependent.

Supported Browsers and Versions

Browser	Minimum Version	Real-World Support
Chrome (Chromium)	108+	Stable, but OS-dependent
Safari	16+	Best on Apple devices
Edge	108+	Strong on Windows
Firefox	109+	Partial UX support

Google Chrome (Chromium Ecosystem)

Chrome provides the most widely used WebAuthn implementation across platforms.

Full passkey support on Chrome 108+
Relies on OS-level authenticators (Android, Windows Hello, macOS)
Supports cross-device authentication via QR flow

Limitations

Behavior varies between Android, Windows, and macOS
Sync depends on Google Password Manager
Older Chrome versions lack passkey UX

Chrome is consistent at API level but varies at platform level.

Safari (Apple Ecosystem)

Safari provides the most seamless passkey experience within Apple devices.

Deep integration with iCloud Keychain
Native biometric prompts (Face ID / Touch ID)
Strong UX consistency across iPhone, iPad, and Mac

Limitations

Limited outside Apple ecosystem
Cross-platform flows rely on QR-based login
Debugging WebAuthn issues is harder

Safari offers the best UX but is tightly locked to Apple ecosystem.

Microsoft Edge (Windows Ecosystem)

Edge is optimized for Windows and integrates directly with Windows Hello.

Uses Windows Hello for authentication
Stable WebAuthn implementation on Windows 11
Works well with enterprise environments

Limitations

Dependent on Windows Hello configuration
Enterprise policies may restrict behavior
Less flexible outside Windows ecosystem

Edge provides the most stable passkey experience on Windows.

Mozilla Firefox

Firefox supports WebAuthn but has slower adoption of passkey UX improvements.

Basic WebAuthn support available
Works with security keys and some platform authenticators

Limitations

Limited passkey UI compared to Chrome/Safari
Inconsistent cross-device support
Slower updates for passkey features

Firefox support exists but is not fully optimized for passkeys.

Key Browser-Level Limitations

WebAuthn APIs are implemented differently across browsers.
Passkey UX flows vary significantly between browsers.
Cross-device authentication behavior is inconsistent.
Fallback handling differs across implementations.

Browser inconsistency is a major source of passkey failures.

Common Failure Scenarios

Using outdated browser version → passkey prompt not triggered
Browser does not detect platform authenticator → login fails
Cross-device QR flow fails → authentication breaks
Mixed browser environments → inconsistent user experience

Most browser-related passkey failures are due to version mismatch or platform differences.

Practical Fixes

Always use latest browser version
Prefer Chrome, Safari, or Edge for production
Detect WebAuthn support before initiating login
Provide fallback authentication methods
Test across multiple browsers and devices

Testing across browser and OS combinations is critical for reliability.

Final Insight

Browsers do not implement passkeys in isolation.
They depend on operating systems and hardware for actual authentication.

Browser support alone does not guarantee passkey success.
Passkeys work only when browser, OS, and hardware are aligned.

Mobile Passkey Flows

Same Device (Native Flow)

User clicks login
OS prompts biometric
Authenticator signs challenge
Login completes

Cross-Device (Hybrid Transport)

Desktop shows QR
Mobile scans QR
Mobile signs challenge
Desktop session established

This uses FIDO Cross-Device Authentication (CDA)

Where It Breaks

Bluetooth disabled
Devices not nearby
Ecosystem mismatch

Cross-device passkeys depend on proximity and ecosystem trust.

Why Passkeys Fail

Passkeys fail when any layer in the authentication stack is misaligned. Passkey authentication depends on coordination between the brows