4 ms·

> Suppose the likelihood of the government or ISP rewriting my requests is very low, as it is in the U.S. Comcast used to (and maybe still does) inject JavaScr

> Suppose the likelihood of the government or ISP rewriting my requests is very low, as it is in the U.S. Comcast used to (and maybe still does) inject JavaScript into HTTP requests when users were approaching their transfer caps, so that a warning banner would be shown to let them know they are almost at their terabyte limit. ISP's have been and continue to be caught playing tricks like this. T-Mobile for instance used to rewrite the playlists that YouTube would send down for HSL to remove the higher bitrates to reduce network traffic. Just because you are in the US does not mean you are immune from this sort of shenanigans, currently it is used mostly in the name of network management, but it could also be used for nefarious purposes. I also fully believe this is why public libraries should exist. The library near me has new computers, help that can help the person navigate those sites and even has tablets available for loan.

forgotmypw17 5y ago
So, you have a choice between: ISP may inject bandwidth cap limit -or- No access to information at all What do you think the person looking for critical information would choose? By the way, libraries are scarce in the U.S., and library computers have been some of the most out-of-date and poorly maintained machines I've used. This is a problem I have no chance of solving, while allowing HTTP access is something I can do today.
- Dylan16807 5y ago
  You act like "no access" can't happen because other things break. If that was the only choice, I'd consider it, but I'm not going to give up everything in tiny incremental bits to maximize access in every edge case. Also you could disable expiration as a much safer measure.
  - forgotmypw17 5y ago
    There are many reasons something can break. I'm not sure how you got the impression I believe otherwise. There are many reasons someone may not be able to access. Furthermore, some of those reasons can be known ahead of time, and some cannot even be predicted before they happen. But the ones I do know of, I try to accommodate, just like i try to accommodate visually impaired, those with slow devices, etc. And I have found that the more known scenarios I accommodate, the more unknown scenarios are also accommodated, just from raising the accessibility bar. Of course, this is not something everyone cares about. You probably won't gain many profitable customers with deep pockets accommodating the edge cases. They're all using the latest and greatest. But if you care about allowing access to as many as possible to your resource, serving both HTTP and HTTPS is the way.
    - Dylan16807 5y ago
      > I'm not sure how you got the impression I believe otherwise. It's the impression your post gives. Either I pick insecurity -or- it breaks. The real version is I pick insecurity -or- the number of ways it can break goes from 73 to 74. And I care about accessibility too. That doesn't mean I indiscriminately want to increase access. The downsides of certain methods are important.

forgotmypw17 5y ago

So, you have a choice between: ISP may inject bandwidth cap limit -or- No access to information at all What do you think the person looking for critical information would choose? By the way, libraries are scarce in the U.S., and library computers have been some of the most out-of-date and poorly maintained machines I've used. This is a problem I have no chance of solving, while allowing HTTP access is something I can do today.

Dylan16807 5y ago
You act like "no access" can't happen because other things break. If that was the only choice, I'd consider it, but I'm not going to give up everything in tiny incremental bits to maximize access in every edge case. Also you could disable expiration as a much safer measure.
- forgotmypw17 5y ago
  There are many reasons something can break. I'm not sure how you got the impression I believe otherwise. There are many reasons someone may not be able to access. Furthermore, some of those reasons can be known ahead of time, and some cannot even be predicted before they happen. But the ones I do know of, I try to accommodate, just like i try to accommodate visually impaired, those with slow devices, etc. And I have found that the more known scenarios I accommodate, the more unknown scenarios are also accommodated, just from raising the accessibility bar. Of course, this is not something everyone cares about. You probably won't gain many profitable customers with deep pockets accommodating the edge cases. They're all using the latest and greatest. But if you care about allowing access to as many as possible to your resource, serving both HTTP and HTTPS is the way.
  - Dylan16807 5y ago
    > I'm not sure how you got the impression I believe otherwise. It's the impression your post gives. Either I pick insecurity -or- it breaks. The real version is I pick insecurity -or- the number of ways it can break goes from 73 to 74. And I care about accessibility too. That doesn't mean I indiscriminately want to increase access. The downsides of certain methods are important.