(In reply to Sunil Mayya from comment #23) > Great idea. I think it would make sense that if we have detected captive portal to skip LNA checks. Will add it to list of enhancements. 100% - I filed bug 1981514 on that. (In reply to Sunil Mayya from comment #22) > This is as per the spec -> https://wicg.github.io/private-network-access/#ip-address-space-heading > So in this case we are behaving as per that. I understand that this can be confusing, but the idea is (I guess) that it is more "private" than the other addresses in this category. I will confirm with the spec authors again. I see that this IP range is technically "reserved for benchmarking"; however I think there's a broad perception on the web that 192.168.* is instead reserved for local-network addressing (e.g. https://www.avast.com/c-ip-address-public-vs-private#:~:text=And%20don%27t%20be%20surprised,network%20routers%20around%20the%20globe. ) So my strong suspicion is that any actual Firefox user with a 192.168.18.* ip-address is almost certainly just on a network that happens to use that local network addressing scheme, rather than a user doing some networking benchmarking on their local device with that range... Maybe this is less of an issue once we've got the captive-portal situation sorted out, but I can imagine other situations too (e.g. homeassistant and other IOT dashboards) which might be hosted at some domain name and reference IP addresses on your local network, where users would probably be pleased to see a prompt for local-network-access but would be surprised to see a "services on this device" prompt...
Bug 1980302 Comment 25 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Sunil Mayya from comment #23) > Great idea. I think it would make sense that if we have detected captive portal to skip LNA checks. Will add it to list of enhancements. 100% - I filed bug 1981514 on that. (In reply to Sunil Mayya from comment #22) > This is as per the spec -> https://wicg.github.io/private-network-access/#ip-address-space-heading > So in this case we are behaving as per that. I understand that this can be confusing, but the idea is (I guess) that it is more "private" than the other addresses in this category. I will confirm with the spec authors again. I see that this IP range is technically "reserved for benchmarking"; however I think there's a broad perception on the web that 192.168.* is instead reserved for local-network addressing (e.g. https://www.avast.com/c-ip-address-public-vs-private#:~:text=And%20don%27t%20be%20surprised,network%20routers%20around%20the%20globe. ) So my strong suspicion is that any actual Firefox user with a 192.168.18.* ip-address is almost certainly just on a network that happens to use that local network addressing scheme, rather than a user doing some networking benchmarking on their local device with that range... Maybe this is less of an issue once we've got the captive-portal situation sorted out, but I can imagine other situations too (e.g. homeassistant and other IOT dashboards) which might be hosted at some domain name (whether `homeassistant.local` or a public domain-name), and might reference IP addresses on your local network - in this situation users would probably be pleased to see a prompt for local-network-access but would be surprised to see an "allow this site to access services on **this device**" prompt...
(In reply to Sunil Mayya from comment #23) > Great idea. I think it would make sense that if we have detected captive portal to skip LNA checks. Will add it to list of enhancements. 100% - I filed bug 1981514 on that. (In reply to Sunil Mayya from comment #22) > This is as per the spec -> https://wicg.github.io/private-network-access/#ip-address-space-heading > So in this case we are behaving as per that. I understand that this can be confusing, but the idea is (I guess) that it is more "private" than the other addresses in this category. I will confirm with the spec authors again. I see that this IP `192.168.18.*` range is technically "reserved for benchmarking"; however I think there's a broad perception on the web that the whole 192.168.* address-block (including this sub-range) is reserved for local-network addressing (e.g. https://www.avast.com/c-ip-address-public-vs-private#:~:text=And%20don%27t%20be%20surprised,network%20routers%20around%20the%20globe. ) So my strong suspicion is that any actual Firefox user with a `192.168.18.*` ip-address is almost certainly just on a network that happens to use that local network addressing scheme, rather than a user doing some networking benchmarking on their local device with that range... Maybe this is less of an issue once we've got the captive-portal situation sorted out, but I can imagine other situations too (e.g. homeassistant and other IOT dashboards) which might be hosted at some domain name (whether `homeassistant.local` or a public domain-name), and might reference IP addresses on your local network - in this situation users would probably be pleased to see a prompt for local-network-access but would be surprised to see an "allow this site to access services on **this device**" prompt...
(In reply to Sunil Mayya from comment #23) > Great idea. I think it would make sense that if we have detected captive portal to skip LNA checks. Will add it to list of enhancements. 100% - I filed bug 1981514 on that. (In reply to Sunil Mayya from comment #22) > This is as per the spec -> https://wicg.github.io/private-network-access/#ip-address-space-heading > So in this case we are behaving as per that. I understand that this can be confusing, but the idea is (I guess) that it is more "private" than the other addresses in this category. I will confirm with the spec authors again. I see that this IP `192.168.18.*` range is technically "reserved for benchmarking"; however I think there's a broad perception on the web that the whole 192.168.* address-block (including this sub-range) is reserved for local-network addressing (e.g. https://www.avast.com/c-ip-address-public-vs-private#:~:text=And%20don%27t%20be%20surprised,network%20routers%20around%20the%20globe. ) So my strong suspicion is that any actual Firefox user with a `192.168.18.*` ip-address is almost certainly just on a network that happens to use that local network addressing scheme, rather than a user doing some networking benchmarking on their local device with that range... Maybe this is less of an issue once we've got the captive-portal situation sorted out, but I can imagine other situations too (e.g. homeassistant and other IOT dashboards) which might be hosted at some domain name (whether `homeassistant.local` or a public domain-name), and might have links or embedded frames that use IP addresses on your local network - in this situation, users would probably be pleased to see a prompt to grant local-network-access but would be surprised to see an "allow this site to access services on **this device**" prompt...