I-1006, Pristine Prolife 1, Shankar Kalate Nagar, Wakad Pune Maharashtra 411057 IN ali.ranalvi@gmail.com

General Internet Engineering Task Force HTTPS, Secure HTTP, shorter URL scheme This document proposes the introduction of `s://` as a universal shorthand for secure URLs, replacing the explicit use of `https://`. The proposed scheme simplifies URL syntax, assumes secure connections by default, and aligns with the modern web's security-first approach. The adoption of `s://` is expected to enhance user experience, improve efficiency, and reinforce secure practices across the internet.

Introduction URLs are a foundational element of the internet, allowing users to locate resources using protocols such as HTTP, HTTPS, and FTP. In recent years, HTTPS adoption has grown significantly, driven by security concerns and performance improvements offered by TLS . Despite this shift, URLs still explicitly distinguish between `http://` (insecure) and `https://` (secure). This explicit declaration is redundant in a web environment where security should be the default . This document proposes the introduction of `s://` as a shorthand for secure URLs, simplifying the syntax and reinforcing the norm of secure connections.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Proposed Solution The `s://` scheme is defined as a shorthand for `https://`. When a client encounters `s://`, it MUST interpret and process it as a secure HTTPS connection . Existing URLs using `https://` remain fully functional, ensuring no disruption to current systems. The `http://` scheme may continue to function during a transition period but is expected to be deprecated in the future. The `s://` scheme SHALL remain compatible with HTTP/1.1 and HTTP/3 semantics .

Motivation

• Security as the Default: The internet has evolved to prioritize secure connections, with HTTPS adoption exceeding 90% of global web traffic. The explicit declaration of `https://` is redundant and assumes that insecure `http://` is still a viable option, which it should no longer be.
• Improved Usability: Users often ignore or misunderstand the difference between `http://` and `https://`. A streamlined `s://` scheme eliminates confusion and simplifies the user experience.
• Efficiency Gains: Reducing the length of URLs saves bandwidth, storage, and processing power. For systems handling billions of URLs, even small optimizations have significant impact.
• Future-Proofing the Web: Adopting `s://` aligns with the long-term goal of deprecating insecure HTTP connections entirely.

Challenges & Mitigations

• Adoption Resistance: Gradual adoption with backward compatibility ensures a smooth transition.
• Legacy Systems: Legacy systems can continue using `http://` or `https://` until phased out.
• Awareness: Collaborate with industry leaders, browser vendors, and developers to promote the change.

IANA Considerations This document requests the registration of the `s://` scheme in the Uniform Resource Identifier (URI) Schemes registry .

Security Considerations The introduction of `s://` does not alter the underlying security model of HTTPS . It is essential that implementations ensure `s://` is interpreted as a secure connection using TLS . Proper validation and error handling must be maintained to prevent misuse or vulnerabilities.

References Normative References

Acknowledgements The author would like to acknowledge his parents (Abbas & Parveen), wife (Shaheen) and his two daughters (Zoya & Anaya) for their love and support, always.