4 ms·

Adding to this, requests to local IPs (ei: 192.168.0.0/24, etc) could still work over plain HTTP. These never go through your ISP anyways. This pretty much eli

• zAy0LfpBZLC8mAC 10y ago
  That's not correct and would be a terrible idea. There is nothing technically special about RFC1918 addresses, and if your router doesn't have an explicit route for some RFC1918 address, it will forward packets to that address to your upstream provider. The only way that RFC1918 addresses are special is that it's guaranteed that the RIRs (ARIN, RIPE, and so on) won't ever allocate them to providers, that's it. Especially, there is nothing "local" about them, it's perfectly possible to use them on WANs, you can interconnect businesses using different RFC1918 prefixes, say, and some ISPs even assign them to their customers (using NAT to connect them to the public internet).
  • hobarrera 10y ago
    I honestly can't think of any scenario where users* would need to contact a private-range IP, over HTTPS, using an untrusted ISP. * Note that tech users can simply be told that they need to use HTTPS over HTTP explicitly. More importantly, my proposal does not affect those scenarios, should they exist. > Especially, there is nothing "local" about them They're used for local area networks probably over 99.9% of the time.
    • zAy0LfpBZLC8mAC 10y ago
      > More importantly, my proposal does not affect those scenarios, should they exist. Really, I am even less sure now what your proposal actually is. Could you explain? > They're used for local area networks probably over 99.9% of the time. If you count the global internal networks of companies as "local area networks", sure ...