8 ms·

If you're suggesting that anything not originating on an enumerated list of IP's for localhost cannot request an url for something that resolves to an entry in

If you're suggesting that anything not originating on an enumerated list of IP's for localhost cannot request an url for something that resolves to an entry in an enumerated list of IP's for localhost, that would be possible, but is not really representative of the entire surface area of the effect demonstrated in the article. It's also entirely possible you have some development api running on a particular port on localhost, and some app running in a container or VM that wants to make calls to it.

mehrdadn 7y ago
> is not really representative of the entire surface area of the effect demonstrated in the article So let's let perfect be the enemy of good? What's the logic here? Let's leave a huge security hole because we can't achieve perfection in all scenarios? > It's also entirely possible you have some development api running on a particular port on localhost, and some app running in a container or VM that wants to make calls to it. The VM should be on localhost or you should jump through a few hoops to whitelist it somehow. I see no reason why this should be allowed by default.
- linuxftw 7y ago
  > So let's let perfect be the enemy of good? What's the logic here? Let's leave a huge security hole because we can't achieve perfection in all scenarios? The logic here is don't hastily start implementing changes to how http requests currently work without a well established plan for doing so. I think there would be a good deal of corner cases you need to account for to successfully implement this feature. Anyway, this problem seems pretty obvious, and I'm sure this discussion has been had elsewhere already.
  - mehrdadn 7y ago
    > The logic here is don't hastily start implementing changes to how http requests currently work without a well established plan for doing so. As if the point of this thread was to push browser vendors to hastily implement this without thinking it through? Are you just trying to find something to have an argument over? I'm tired of this.

mehrdadn 7y ago

> is not really representative of the entire surface area of the effect demonstrated in the article So let's let perfect be the enemy of good? What's the logic here? Let's leave a huge security hole because we can't achieve perfection in all scenarios? > It's also entirely possible you have some development api running on a particular port on localhost, and some app running in a container or VM that wants to make calls to it. The VM should be on localhost or you should jump through a few hoops to whitelist it somehow. I see no reason why this should be allowed by default.

linuxftw 7y ago
> So let's let perfect be the enemy of good? What's the logic here? Let's leave a huge security hole because we can't achieve perfection in all scenarios? The logic here is don't hastily start implementing changes to how http requests currently work without a well established plan for doing so. I think there would be a good deal of corner cases you need to account for to successfully implement this feature. Anyway, this problem seems pretty obvious, and I'm sure this discussion has been had elsewhere already.
- mehrdadn 7y ago
  > The logic here is don't hastily start implementing changes to how http requests currently work without a well established plan for doing so. As if the point of this thread was to push browser vendors to hastily implement this without thinking it through? Are you just trying to find something to have an argument over? I'm tired of this.