Fine, but the way the thing works today, there's no mechanism for discovering what those terms and conditions are, or indeed, that they even exist.
So I go somewhere, flick on my WiFi, and then get frustrated because various tools (say, my native-code Google Reader app) can't communicate. It can't talk to the network because HTTP is trapped.
The thing is, HTTP is the de facto transport for everything. But these authentication/confirmation pages assume that a human will be reading them.
It seems to me that a mechanism that detects the presence of such a trap, and pops up that response page in a browser window for the user to react to, would solve everyone's problem (if inelegantly).
And the other issue is that (if I have this correct), the reason my phone connects automatically to various portal hijacking waps is because in the past I have connected to those waps, and almost certainly checked off the terms and agreements for them, and continued.
I don't believe the nexus one will connect by itself to any open wap, it will just tell you one is available.
It seems absurd for anyone to think I need to check off the terms and agreements every single time I connect to the open wap, everyone's suspicion of course is that no one ever reads through the terms and agreements, we just check the box to make some lawyer or IT dude happy and continue.
Exactly. This is the specific reason why I ask if these portal pages, the DNS hijacking violates some RFC.
I do understand the desire and even the need for some form of authentication, or notice you are on someone else's network and ought to read what the terms are.
But the behavior of how that is implemented today is totally obnoxious, especially since for the most part, the terms and agreements are boilerplate intended to satisfy some lawyer, and functionally get in the way of why the vendor or site provided the wifi access in the first place.
So I go somewhere, flick on my WiFi, and then get frustrated because various tools (say, my native-code Google Reader app) can't communicate. It can't talk to the network because HTTP is trapped.
The thing is, HTTP is the de facto transport for everything. But these authentication/confirmation pages assume that a human will be reading them.
It seems to me that a mechanism that detects the presence of such a trap, and pops up that response page in a browser window for the user to react to, would solve everyone's problem (if inelegantly).