On Thursday, November 9, 2023 at 11:18:51 AM UTC-5 Andreas S wrote:
Same situation here @Franky I'm working for a mobile payment service provider that offers mobile payment in multiple countries in Europe. Multiple mobile network operators in Europe like few ones in Poland currently only support end user identification via header enrichment! The header enrichment is used for an automatic silent end user identification that allows service providers in subsequent flow (of course via https!) to: a) auto-login an already known end user in mobile web b) offer an end-user the possibility to purchase a good/service without need to enter mobile phone number of a user in mobile web (which would require a media break to validate the number via SMS). The enforced https upgrade has a huge negative impact on usability of such services for end-users in mobile web: Flow that worked automatically in the past gets now interrupted by a request for confirmation for an unsecure flow -> scares a lot of people as it looks very unprofessional. Hope you have a realizable idea to deal with this use case, to offer end users a good user experience again! (changing identify flow from HE to redirect loop ot mobile network operator is unfortunately not, as they have very limited ressources :( ATT Wireless USA (my testing, not easy to look up its exact header name for me, but I've seen it before, partial evidence that ATTW has an transparent port 80 proxy that adds req headers https://howardforums.com/showthread.php/1908276-AT-amp-T-Prepaid-no-IPV6-address?p=17008722#post17008722 ) and Verizon Wireless USA ( https://news.ycombinator.com/item?id=8500131 ) also add per-customer (I guess per SIM card) GUIDs to clear HTTP req headers, by default. Its not politically correct, for any USA based service provider, to publicly admit or document, they use ISP/customer specific info from an LTE provider's port 80 transparent proxy, if a port 80 transparent proxy exists, but as the post above says, in Poland, is it is standard procedure to use an LTE ISP's metadata to change features and behavior for customer facing websites. Advocating "can't you just make a smartphone native app and pass Apple and Play store review if you want that info (raw TCP sockets)?" seems the opposite of the goals and purpose of the W3C/WP. So whats the solution, if there is a clear business need, as above, for a browser to navigate to a cleartext port 80 domain and back again, which sounds impossible now? Note, there is no opt-out mechanism from HTTPS upgrades defined in this spec other than a a server delivering a RST TCP packet on port 443 or TLS handshake but invalid/unsigned cert returned, or a many seconds long TCP timeout on port 443. -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4fd50e3a-43ec-4720-9a9d-c823a7a108d7n%40chromium.org.
