Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.misc > #17854 > unrolled thread

How is public WiFi meant to work?

Started bySylvia Else <sylvia@email.invalid>
First post2019-04-20 12:50 +1000
Last post2019-04-21 00:12 +0000
Articles 9 — 6 participants

Back to article view | Back to comp.misc


Contents

  How is public WiFi meant to work? Sylvia Else <sylvia@email.invalid> - 2019-04-20 12:50 +1000
    Re: How is public WiFi meant to work? Rich <rich@example.invalid> - 2019-04-20 05:02 +0000
      Re: How is public WiFi meant to work? Mike Spencer <mds@bogus.nodomain.nowhere> - 2019-04-20 03:11 -0300
      Re: How is public WiFi meant to work? Sylvia Else <sylvia@email.invalid> - 2019-04-20 16:54 +1000
    Re: How is public WiFi meant to work? Marko Rauhamaa <marko@pacujo.net> - 2019-04-20 10:38 +0300
    Re: How is public WiFi meant to work? RS Wood <rsw@therandymon.com> - 2019-04-20 09:02 +0000
      Re: How is public WiFi meant to work? Rich <rich@example.invalid> - 2019-04-20 14:44 +0000
        Re: How is public WiFi meant to work? RS Wood <rsw@therandymon.com> - 2019-04-21 19:56 -0400
    Re: How is public WiFi meant to work? not@telling.you.invalid (Computer Nerd Kev) - 2019-04-21 00:12 +0000

#17854 — How is public WiFi meant to work?

FromSylvia Else <sylvia@email.invalid>
Date2019-04-20 12:50 +1000
SubjectHow is public WiFi meant to work?
Message-ID<ghvfn4FochgU1@mid.individual.net>
In the days of yore, one chose a public WiFi node, and then when one 
entered a URL into a browser, the WiFi node served up a page that 
redirected one to a terms-acceptance page. One clicked on that. Job done.

These days, the URL one enters is likely to be for the https protocol. 
The WiFi node cannot redirect that, and nor can it pretend to be the 
target page.

So, in today's world, just how is this meant to work?

I seem to have no end of trouble with it, at times resorting to entering 
the URL of a page of my own that is not https based.

Sylvia.




[toc] | [next] | [standalone]


#17855

FromRich <rich@example.invalid>
Date2019-04-20 05:02 +0000
Message-ID<q9e95f$h47$1@dont-email.me>
In reply to#17854
Sylvia Else <sylvia@email.invalid> wrote:
> In the days of yore, one chose a public WiFi node, and then when one 
> entered a URL into a browser, the WiFi node served up a page that 
> redirected one to a terms-acceptance page.  One clicked on that.  Job 
> done.
> 
> These days, the URL one enters is likely to be for the https 
> protocol.  The WiFi node cannot redirect that, and nor can it pretend 
> to be the target page.
> 
> So, in today's world, just how is this meant to work?
> 
> I seem to have no end of trouble with it, at times resorting to 
> entering the URL of a page of my own that is not https based.

That is the solution, well, a http page, not necessarially your own, 
but at least when you own it you know it will not suddenly switch to 
https out of the blue.

Android phones work around this glitch by querying a set of google 
http: servers that presumably google specifically setup for keeping 
these captive portal pages working (and, of course, giving Google even 
more metadata with which to market things to you).

[toc] | [prev] | [next] | [standalone]


#17856

FromMike Spencer <mds@bogus.nodomain.nowhere>
Date2019-04-20 03:11 -0300
Message-ID<87d0lh2ol5.fsf@bogus.nodomain.nowhere>
In reply to#17855
Rich <rich@example.invalid> writes:

> Sylvia Else <sylvia@email.invalid> wrote:

>> In the days of yore, one chose a public WiFi node, and then when one 
>> entered a URL into a browser, the WiFi node served up a page that 
>> redirected one to a terms-acceptance page.  One clicked on that.  Job 
>> done.
>> 
>> These days, the URL one enters is likely to be for the https 
>> protocol.  The WiFi node cannot redirect that, and nor can it pretend 
>> to be the target page.
>> 
>> So, in today's world, just how is this meant to work?
>> 
>> I seem to have no end of trouble with it, at times resorting to 
>> entering the URL of a page of my own that is not https based.

A helpful person had to point that out to me last year.
 
> That is the solution, well, a http page, not necessarially your own, 
> but at least when you own it you know it will not suddenly switch to 
> https out of the blue.

And ensure that the browser doesn't go first to a copy of the data
referenced by that URL that's cached on your hard drive.  The helpful
person also had to remind me of this.

> Android phones work around this glitch by querying a set of google 
> http: servers that presumably google specifically setup for keeping 
> these captive portal pages working (and, of course, giving Google even 
> more metadata with which to market things to you).

Oh, great. :-\

-- 
Mike Spencer                  Nova Scotia, Canada

[toc] | [prev] | [next] | [standalone]


#17857

FromSylvia Else <sylvia@email.invalid>
Date2019-04-20 16:54 +1000
Message-ID<ghvu1eFr7ivU1@mid.individual.net>
In reply to#17855
On 20/04/2019 3:02 pm, Rich wrote:
> Sylvia Else <sylvia@email.invalid> wrote:
>> In the days of yore, one chose a public WiFi node, and then when one
>> entered a URL into a browser, the WiFi node served up a page that
>> redirected one to a terms-acceptance page.  One clicked on that.  Job
>> done.
>>
>> These days, the URL one enters is likely to be for the https
>> protocol.  The WiFi node cannot redirect that, and nor can it pretend
>> to be the target page.
>>
>> So, in today's world, just how is this meant to work?
>>
>> I seem to have no end of trouble with it, at times resorting to
>> entering the URL of a page of my own that is not https based.
> 
> That is the solution, well, a http page, not necessarially your own,
> but at least when you own it you know it will not suddenly switch to
> https out of the blue.
> 
> Android phones work around this glitch by querying a set of google
> http: servers that presumably google specifically setup for keeping
> these captive portal pages working (and, of course, giving Google even
> more metadata with which to market things to you).
> 

What a kludge!

Well, that's a pain. I'm trying to assist an aged person with zero IT 
smarts (or let that be negative, if it's meaningful). I was hoping there 
was a solution that I could just implement. Even bookmarking a suitable 
URL in Chrome may be asking too much.

A quick ap search (there's an ap for everything, right?) didn't reveal 
anything useful.

On the face of it, any site should do, as long as its domain name 
exists, since one isn't going to reach it until after the WiFi node has 
done its thing. Except for Google, since searches sometimes seem to be 
allowed through. I think I've found a way to put something on the home 
screen that starts Chrome and makes it go to the chosen URL. Took some 
doing - Chrome seems to have ideas of its own about when it's going to 
let one do that. I think they must have already incorporated my 
confiseauser.jar library. Where are my licence fees?

Sylvia.

[toc] | [prev] | [next] | [standalone]


#17858

FromMarko Rauhamaa <marko@pacujo.net>
Date2019-04-20 10:38 +0300
Message-ID<87lg05i0rz.fsf@elektro.pacujo.net>
In reply to#17854
Sylvia Else <sylvia@email.invalid>:

> In the days of yore, one chose a public WiFi node, and then when one
> entered a URL into a browser, the WiFi node served up a page that
> redirected one to a terms-acceptance page. One clicked on that. Job
> done.
>
> These days, the URL one enters is likely to be for the https protocol.
> The WiFi node cannot redirect that, and nor can it pretend to be the
> target page.
>
> So, in today's world, just how is this meant to work?

You use 4G data?


Marko

[toc] | [prev] | [next] | [standalone]


#17860

FromRS Wood <rsw@therandymon.com>
Date2019-04-20 09:02 +0000
Message-ID<q9en7q$djq$1@solani.org>
In reply to#17854
On 2019-04-20, Sylvia Else <sylvia@email.invalid> wrote:
> In the days of yore, one chose a public WiFi node, and then when one 
> entered a URL into a browser, the WiFi node served up a page that 
> redirected one to a terms-acceptance page. One clicked on that. Job done.
>
> These days, the URL one enters is likely to be for the https protocol. 
> The WiFi node cannot redirect that, and nor can it pretend to be the 
> target page.
>
> So, in today's world, just how is this meant to work?
>
> I seem to have no end of trouble with it, at times resorting to entering 
> the URL of a page of my own that is not https based.
>
> Sylvia.

I have trouble with this captive portal tech as well, and I know of at
least one hotel where my Linux laptop simply doesn't connect ... no
reason why.

My biggest problem is my machine connects to the captive portal, but
doesn't take me to the portal webpage where I have to accept terms/sign
away rights, etc.  Recognizing that, I open a browser and go to a page
like 2.2.2.2 which forces the process to advance.

Oh by the way this happens on Win7 as welll/work computer.

I wish there were an alternative to captive portals, but the hotel
chains seem to have found them the best solution.

[toc] | [prev] | [next] | [standalone]


#17862

FromRich <rich@example.invalid>
Date2019-04-20 14:44 +0000
Message-ID<q9fb83$7v7$1@dont-email.me>
In reply to#17860
RS Wood <rsw@therandymon.com> wrote:
> On 2019-04-20, Sylvia Else <sylvia@email.invalid> wrote:
>> In the days of yore, one chose a public WiFi node, and then when one 
>> entered a URL into a browser, the WiFi node served up a page that 
>> redirected one to a terms-acceptance page.  One clicked on that.  
>> Job done.
> 
> I wish there were an alternative to captive portals, but the hotel 
> chains seem to have found them the best solution.

Small edit: The hotel chains lawyers have insisted they be the offered 
solution. [1]

The portals exist so that the lawyers can sleep at night because they 
have offloaded (they hope) any responsibility for your browsing/use by 
having you click 'accept' to the terms and conditions the lawyers wrote 
up.

Were it not for the lawyers, one could just connect to the hotel wifi, 
get an IP address, and start browsing without all this extra impediment 
in the way.



[1] Or, alternately, for the pricey chains, it is so you can 'agree' to 
their $20/day "internet usage fee", so they can provide you a service 
that costs them $0.01/day to provide, while they make $19.99/day in 
profit from the fee they charge you.

[toc] | [prev] | [next] | [standalone]


#17874

FromRS Wood <rsw@therandymon.com>
Date2019-04-21 19:56 -0400
Message-ID<6icvof-r5k.ln1@rasp.therandymon.com>
In reply to#17862
On 2019-04-20, Rich <rich@example.invalid> wrote:
> The portals exist so that the lawyers can sleep at night because they 
> have offloaded (they hope) any responsibility for your browsing/use by 
> having you click 'accept' to the terms and conditions the lawyers wrote 
> up.
 ...
>
> [1] Or, alternately, for the pricey chains, it is so you can 'agree' to 
> their $20/day "internet usage fee", so they can provide you a service 
> that costs them $0.01/day to provide, while they make $19.99/day in 
> profit from the fee they charge you.

You're right on both accounts.

[toc] | [prev] | [next] | [standalone]


#17863

Fromnot@telling.you.invalid (Computer Nerd Kev)
Date2019-04-21 00:12 +0000
Message-ID<q9gcgg$1g0o$1@gioia.aioe.org>
In reply to#17854
Sylvia Else <sylvia@email.invalid> wrote:
> In the days of yore, one chose a public WiFi node, and then when one 
> entered a URL into a browser, the WiFi node served up a page that 
> redirected one to a terms-acceptance page. One clicked on that. Job done.

I thought the days of your were before the terms-acceptance page.
Back when free WiFi "hotspots" were also all unencrypted, so you
didn't have to find someone to harass for the the password, which
can then be used to crack the encryption anyway.

Once they started doing these redirect things I found that the
"acceptance" would time out after a while (or perhaps if the signal
was lost for a moment) and you'd be redirected again. If you were
in the middle of a large download, that stopped it in its tracks.

-- 
__          __
#_ < |\| |< _#

[toc] | [prev] | [standalone]


Back to top | Article view | comp.misc


csiph-web