This is the twenty-second post in our ongoing series showcasing new privacy features in iBrowe. This update highlights work by Research and Privacy Engineer Arthur Edelstein and was written by VP of Privacy Engineering Peter Snyder.

📋 Summary

Starting in version 1.50, iBrowe introduces HTTPS by Default—an aggressive policy that upgrades every HTTP request to HTTPS, falling back only when a site truly does not support or breaks under HTTPS. 🚀 By maintaining a compact “HTTP‐only” exception list, iBrowe ensures maximum security for users without sacrificing compatibility. This policy surpasses all other popular browsers’ defaults, launching first on Desktop and Android, with iOS support to follow.

🌐 1. Why HTTPS Matters

1.1 Protecting Privacy on the Open Web

  • Visibility Without Encryption: On an HTTP-only connection, your ISP (or any on-path observer) sees the full contents of pages you visit, form submissions, and API calls. Suppose you visit example.com/login over HTTP: your username and password travel in cleartext, easily intercepted. 👁️
  • HTTPS Encryption: With TLS (HTTPS), data between your browser and the server is encrypted. Third parties can see only the domain (e.g., example.com), not the page path or query parameters. This preserves confidentiality and mitigates passive eavesdropping.

1.2 Security Beyond Privacy

  • Integrity & Authenticity: HTTPS guarantees that content hasn’t been tampered with in transit. An attacker on a public Wi-Fi network cannot inject malicious scripts or swap out images when the site is served over HTTPS. 🔐
  • Protection Against Active Attacks: Without HTTPS, a “man-in-the-middle” could rewrite page responses, injecting ads, trackers, or exploit code. HTTPS thwarts that by validating the server’s TLS certificate.

🔍 2. The Challenge of Automatically Upgrading to HTTPS

2.1 Mixed HTTP/HTTPS Support Across Sites

  • HTTPS-Only Sites: Major sites like wikipedia.org or github.com fully support HTTPS. Upgrading is seamless. ✅
  • HTTPS-Available but Not Enforced: Some websites listen on both HTTP and HTTPS (e.g., http://blog.example.com/ and https://blog.example.com/). Upgrading works, except for certain third-party resources still loaded over HTTP (mixed-content warnings).
  • HTTPS-Optional Domains: A handful of domains use entirely different hostnames for secure access (e.g., http://oldsite.com/ vs. https://secure.oldsite.net/). Automatic upgrades may break these without special handling.
  • HTTP-Only Legacy Sites: Rare sites do not support HTTPS at all. Blindly upgrading them would produce a connection error, leaving the user unable to access essential services.

2.2 The Limitation of Static Upgrade Lists

  • HTTPS Everywhere Deprecation: Previously, iBrowe relied on a fixed “upgrade” list from HTTPS Everywhere. Unfortunately, that community-maintained list is now stale—many sites have changed certificates, renamed domains, or deprecated HTTP endpoints. Maintaining a massive “allowlist” of HTTPS redirects is unsustainable. 🗂️

🚀 3. Introducing “HTTPS by Default” in iBrowe 1.50

3.1 Core Logic Workflow

  1. User Navigates to an HTTP URL (e.g., http://example.net/page).
  2. Check Exception List: iBrowe consults a concise, community-editable “HTTP-Only” list of known non-HTTPS hosts (e.g., legacy.example.net).
    • On List: Load over HTTP without modification.
    • Not on List: Attempt a strict upgrade to HTTPS.
  3. Upgrade Attempt: iBrowe rewrites the request to https://example.net/page.
    • Success (200 OK with valid TLS): Render the HTTPS page; ensure all subresources (images, scripts, style sheets) also load via HTTPS or are upgraded if possible.
    • Failure (e.g., TLS error, 4xx/5xx): Fallback to HTTP seamlessly—user sees no prolonged error page, just the original HTTP content.
  4. Mixed-Content Handling: If certain resources still load over HTTP (e.g., CDN assets), iBrowe displays a shield icon indicating “Mixed Content.” Users can click to view or reload these subresources in a secure manner if the server permits.

3.2 Exception List Details

  • Compact & Public: Unlike giant “upgrade” lists, iBrowe’s “HTTP-Only” list is deliberately small—only high-traffic or widely used domains known to break under HTTPS are included.
  • Community-Editable: Developers and privacy advocates can propose additions or removals via our open repository. This crowdsourced approach keeps the list up-to-date without overwhelming maintenance overhead. 📂
  • Minimal False Positives: Sites are only added if an HTTPS upgrade causes functionality to fail completely (e.g., login forms break, essential JavaScript errors). In rare cases where a site occasionally misconfigures TLS but corrects it quickly, it may be temporarily removed once resolved.

🛠️ 4. Why iBrowe’s Approach Exceeds Other Browsers

4.1 Comparison to Competing Defaults

Browser Default HTTPS Policy Fallback Behavior Exception List Approach
iBrowe 1.50+ Upgrade all HTTP → HTTPS by default<br>Fallback to HTTP on error<br>(Exceptions managed via small, public list) Load HTTP if HTTPS fails or on exception list Community-editable “HTTP-Only” list for known breakages
Chrome (Stable) Upgrade via HSTS Preload & “HTTPS-First Mode” (opt-in only) Show warning, let user decide to proceed over HTTP HSTS list maintained by Chromium (large, global); no fallback automation
Firefox (Stable) Upgrade via “HTTPS-Only Mode” (opt-in) Block page with error; user must click “Ignore the risk” No custom exception list easily editable
Safari (Stable) Upgrade HTTP → HTTPS when server advertises HSTS or via Smart Tracking Prevention Load HTTP if no HSTS, no user prompt No automated exception management

Key Differentiator: iBrowe’s default “upgrade first, fallback gracefully” policy applies to all users out of the box—no manual toggles needed. No other browser combines comprehensive default upgrading with a crowd-sourced exception list enabling seamless fallback.

4.2 Real-World Impact

  • Wider HTTPS Adoption: Many smaller sites still offer only HTTP. Under iBrowe’s policy, users automatically gain TLS protection whenever possible, incentivizing admins to enable HTTPS (Let’s Encrypt, Cloudflare, and others provide free certificates). 🌱
  • Reduced User Friction: Instead of presenting users with “Your connection is not private” errors or requiring manual “Proceed insecurely” clicks, iBrowe silently upgrades or reverts, keeping browsing fluid.
  • Stronger Privacy by Default: Users no longer must configure “HTTPS-Only Mode.” iBrowe’s out-of-the-box policy ensures everyone benefits—novices and experts alike.

📲 5. iOS Plan & Private Browsing + Tor

5.1 Upcoming iOS Integration

  • WKWebView enforces strong TLS but does not itself rewrite HTTP → HTTPS. iBrowe’s iOS team is integrating the same “HTTPS by Default” engine, with a small on-device exception list. Performance-tuned for Apple’s networking stack, this will ship in iBrowe iOS 1.52. 📱

5.2 Private Windows with Tor

  • When you open a Private Window with Tor, iBrowe enforces HTTPS-Only Mode—any HTTP connection triggers a prompt:

    ⚠️ HTTPS Required
    This site is not secure. Continue anyway?

  • This stricter policy aligns with Tor’s zero-logging ethos. Unencrypted traffic over Tor is not only visible to your guard relay but falls back to exit relays, exposing content. Forcing HTTPS ensures your content remains encrypted from end to end.

5.3 User-Configurable HTTPS-Only Mode

  • For advanced users, iBrowe offers HTTPS-Only Mode on all windows: visit ibrowe://settings/shields and toggle HTTPS-Only on. Any HTTP request will show a blocking warning; you may override if desired.

🔮 6. Beyond HTTPS: Complementary Privacy Innovations

6.1 STAR & P3A Integration

  • iBrowe’s STAR (Secure Telemetry via k-Anonymity) protocol collects usage data only when k users submit the same value. Combined with HTTPS by Default, telemetry flows are encrypted, and unique identifiers remain protected. 📊

6.2 FrodoPIR for Safe URL Checks

  • When iBrowe queries third-party threat lists (e.g., to check if a URL is malicious), it uses FrodoPIR—a Private Information Retrieval scheme—ensuring your browsing queries remain hidden, even from the threat-list server. 🔍

6.3 Ongoing Fingerprint Randomization

  • iBrowe continues to “farble” canvas, WebGL, audio, fonts, and languages, making cross-site fingerprint linking infeasible. This works hand-in-hand with HTTPS by Default to prevent both passive eavesdropping and active fingerprinting. 🎨🔤

🎉 7. Conclusion

iBrowe 1.50’s HTTPS by Default feature offers the strongest default encryption policy of any major browser. 🌟 By automatically upgrading all HTTP traffic to HTTPS—except for a small, public set of exceptions—and falling back only when necessary, iBrowe ensures each connection is encrypted whenever possible. Combined with deeper telemetry protections, fingerprint randomization, and upcoming iOS support, iBrowe remains committed to a user-first Web where privacy and security are the baseline, not afterthoughts.

Update to iBrowe 1.50 on Desktop or Android today (and look for iOS 1.52 soon) to experience the future of secure, private browsing.