Re: [whatwg/fetch] HTTPS upgrades proposal (PR #1655)

@bulk88 commented on this pull request.



> +<div algorithm>
+<p>To <dfn>upgrade an HTTP request</dfn> given a <a for=/>request</a> <var>request</var>:
+
+<ol>
+ <li>
+  <p>If any of the following are true:
+
+  <ul>
+   <li><p><var>request</var>'s <a for="request">destination</a> is not "<code>document</code>";
+
+   <li><p><var>request</var>'s <a for="request">method</a> is not "<code>GET</code>";
+
+   <li><p><var>request</var>'s <a for="request">URL</a>'s <a for="url">scheme</a> is not
+   "<code>http</code>"; or
+
+   <li><p><var>request</var>'s <a for="request">URL</a>'s <a for="url">origin</a> is exempted from

In https://groups.google.com/a/chromium.org/g/blink-dev/c/cAS525en8XE/m/jAAG2CIPBgAJ a user reported a Polish LTE ISP, offers the UA subscriber's ISP specific GUID (lets ignore privacy) through a clear HTTP 1.1 ISP addon req header (MITM clear proxy), so a site has to downgrade to clear, capture the customer's ISP subscriber GUID, then redirect back to HTTPS, then on backend, submit LTE subscriber GUID+server's 3rd party api key->bill UA's LTE account for 3rd party service. No app stores, no native apps, no browser specific local or cloud storage of UA auto-logins, and no asking a UA to type in his telephone number. How would this continue to work if a clear HTTP is prohibited by spec globally? Someone demonstrated a business need to capture req headers from a clear MITM proxy.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/1655#discussion_r1479676325
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/pull/1655/review/1864998486@github.com>