Re: Online Status Design

[Neil Broadley <scaine scaine net>]

2009/12/3 Martin Owens <doctormo gmail com>

Hey Darren,

On Wed, 2009-12-02 at 16:48 -0500, Darren Albers wrote:

> There are a number of challenges here and it has been discussed in the
> past on this list which might help provide some more details.  At a
> high level:
> 1) Sites that require a proxy or sites that use captive portals will
> give inaccurate results

Sites that require proxy or sites that use captive portals should be
reported as such, this shouldn't be too difficult to work out when you
make a http request and it fails to get the information it expected.

I think proxies are going to be the tricky one, requires someone who
knows about them tbh. But in any case, reporting that your not online
when you are is slightly more desirable that reporting that your online
when your not.

> 2) Needless traffic for people in countries with costly access charges

That's a concern, although many tools and services already attempt to
make requests, updates etc and people from these countries have learned
how to turn things off they find undesirable. Although making the tests
use the smallest amount of bandwidth is also important.

> 3) Who would host this site that is checked?

You'd have a number of them, mirrors of the same file or the same
challenge script that returns a predictable result.

> 4) Do we want to rely on an internet hosted site to determine our
> network status?   What happens when the site goes down or is otherwise
> unavailable?

When it's down, you check the second mirror, then the third and then
conclude that your offline (or the internet has been destroyed by
skynet)

> 5) For most "Home" users if they have a link they are "Online" for all
> intents and purposes.

That isn't true, I work with home users all the time and one of their
problems is the inaccurate reporting of what they want (to be online)
and what the computer can tell them (that they're on a network) there
are all sorts of problems that crop up in all sorts of situations,
especially for people with laptops on wifi networks.

To think that network link is the same as online is to go against the
evidence of user behviour. It's also making it hard to teach, what do I
tell my users? lie to them and say that when it's link they're online?
or tell them the truth and spend 40 mins explaining the complexity of
when they won't be online?

> It might be better to have a troubleshooter
> option that they can run if they can't connect that checks what type
> of link (PPPOE, Wireless etc..) that gives them instructions on how to
> connect and can ping internet sites to determine connectivity and
> suggest options etc...   This way it is more of a troubleshooting tool
> and the items above don't matter.

Instructions for how to fix the problem is a good idea, possibly a
second phaise that you can implement higher up once you have the lower
level detection.

> I personally don't see this as being very valuable and causing
> potential confusion but I am not a developer so my opinion doesn't
> carry much weight  ;-)

Unfortunately experienced users won't find value because they're used to
how it works already. New and casual users on the other hand (and even I
who is a programmer) have had examples of trying to check my email in
evolution and it not getting a connection because my wifi has been stuck
behind a paywall.

It's most definitely a feature which should have always existed.

Martin,

I think you need to be really careful about the use-case here.  I think the blueprint is aiming this feature at home users, so the issue of proxies is vastly reduced.  Also, there's no reason why a tiered approach couldn't be used :

1. Test for http://amionline.ubuntu.com
2. If (1) fails, test for any site and see if the response headers include a 302 or similar code (which many inline proxies will use to redirect you to an accept page - usually for terms and conditions, or possibly to enter your username/password)
3. If (2) fails, test for ping against the default gateway.
4. Report findings back to user appropriately.

And example error messages could be, based on the above,
All fail : "Your router appears to be down"
3 works, 1 and 2 fail : "Your router does not appear to be connected to the internet"
3 and 2 work, 1 fails : "You appear to be behind a firewall/proxy which requires authentication"
All work : "You are connected to the internet".

That would be a million miles more useful than Vista's vague "Local/Limited Connectivity" rubbish.

I mean, you could probably test for DHCP failing too?  Doesn't network-manager just fail silently in that case (unless you have "static" version of the same network defined)?