[Mesh] This Week in Mesh!

[Marc Juul]

On Wed, Jul 10, 2013 at 5:28 PM, Mitar <mitar at tnode.com> wrote:

> Hi!
>
> I would just raise concerns about captive portal/splash screen. We had
> that for some time and it was much more an issue than worth. It was our
> primary reason why people said that the network does not work.
>
> People wondered why things don't work. For example Skype and e-mail. And
> the concept that they have first to open some webpage. And then Skype
> will start working. This was made easier now since OSes detect captive
> portal and display information about that. But still. Smart phones still
> have this issue.
>

They do? My phone is pretty old and it doesn't have this issue. Most free
wifi these days have a captive portal. Examples are Starbucks and BART.


> It does not work with HTTPS. And we should encourage users to use HTTPS.
> So if they are using Google over HTTPS and we have captive portal and
> they want to open Google (what is what they do in practice first) over
> HTTPS, you have two options:
> - you block 443 (and all other ports) until they confirm
> - you intercept and have some untrusted SSL shown (which is really bad
> to get people used to that)
> - you leave through all traffic before the captive portal, you intercept
> only 80, but then it is very strange why everything works, except 80
>

There may be legal reasons why we'd need a splash page, so if that turns
out to be the case we may have to block everything until they click "ok" to
some agreement. We'll talk to lawyers to figure this out. Hopefully it's
not required. If it turns out that we can get away with not having a "real
captive portal" then we should just block port 80 and trick the tests that
different devices do to figure out if they're behind a captive portal, such
that people will see our splash page but with minimal limitation of their
connectivity. We also talked about allowing people to say e.g. "don't show
the splash page for this device for 1 week" and a way for more technical
users to input the mac address of devices that should never have port 80
redirected.


> In general captive portal is a very bad moment to display any
> information. People want at that moment to connect to the Internet, they
> will just click anything and continue. What you would want is to display
> something after they finish working with anything. So like captive
> portal people maybe read first time, but later on it is useless to use
> it for some messages and notices.
>

Yes we know this, but since captive portal is the only way that that will
allow us to tell users anything about the mesh then unfortunately it
becomes our only solution. One other proposal was to have the ssid be a
short url (which i think we should do either way), but i suspect very few
will bother typing that in.


> And the most important thing: If you have captive portal on nodes, then
> every time you want to upgrade captive portal, you have to upgrade
> nodes. (You could maybe make some system which syncs this automatically,
> but then nodes are getting more and more complicated and you might want
> that things are stable and don't change once they are deployed.)
>

We should definitely have a system for updating the captive portal page.
We've been tossing around ideas about having the local community use it for
geo-specific notices, or even having a few geo-specific unobtrusive ads
from local businesses.


> Captive portal also makes things harder when uplink to Internet fails.
> So then in such situations people have to confirm the captive portal
> just to be able to connect to the network, not even Internet. This is
> hard to explain to people. This difference.
>

If the uplink to the internet fails, then the captive portal should tell
people.


> Captive portal makes it really hard for Batman roaming between nodes.
>

Why? You just have each node host the exact same page and whichever node
you are connected to when you request your fist non-ssl site will give you
a splash page.


> So we removed captive portals from all nodes. Currently we don't have
> anything. What we are planning is to intercept first request on port 80
> on the Internet gateway and redirect to our social info portal called
> PiplMesh:
>
> http://dev.wlan-si.net/wiki/PiplMesh
>
> So the idea is that people can still use the network and Internet
> normally. You just hijack first request. But it is not a captive portal
> (so no button to confirm to get access). Just to display information
> about the network. But even more important: to display a portal which is
> useful to people using the network. If you have such a portal, then
> people will be using and reading things there and you will get people
> engaged into the network and then you can communicate two-ways with your
> users.
>

Great! We definitely want the splash page to be a gateway to community mesh
services!


> So the idea is that on that portal all connected people to the mesh can
> communicate in real-time, share information (like "hey, this event is
> happening there and there, come", or even "hay, I am sitting in this
> coffee shop, anybody for a chat?" or "I am a CouchSurfer and got
> stranded in the city, can anybody offer me a couch for a night?" And you
> can share this based on the distance in hops from the node you are
> connected to (for example the message about chat is relevant only to the
> node you are on, the message about the event is maybe useful to more
> people, and CouchSurfer might want to address the whole city). So the
> portal again introduces the physical nature of "voice" into virtual
> sharing. How load you are, so far you are heard. And distance is hops
> between nodes.
>

Sounds very similar to ideas about decentralized social networks I've seen
lately as well as some of our own projects. Is all of this implemented yet?
It seems like something like this should be developed in a way that does
not make it dependent on a mesh network, but instead allows it to operate
well on any network, synchronously or asynchronously.


> And next to that you can also display local relevant information for
> people.
>
> So the idea is that captive portal influence is minimized (only 80 port,
> firs time) and that the content of the portal is made useful to the
> people. So that they might even use it outside the captive portal use.
>

Yes.


> But yes, this is again possible because we have a centralized gateway
> and we don't have issues with central services if the network can still
> operate without them. They then just add a value to the network and make
> adoption and usefulness of the network higher.
>

Why would you implement something like this as a centralized service? That
seems lazy. Decentralized networks should run decentralized services.


> (The development of PiplMesh sadly stopped and we will probably rewrite
> it from the scratch. But the idea I believe is still valid.)
>

A good opportunity to write it as a decentralized service instead then.

Honestly the idea of having a community web app as a splash page occurred
to us early on and we are well aware of the problems associated with
captive portals. PiplMesh could have been interesting if it was a
functioning and maintained piece of software.

Your experience with mesh networks and the software you have developed is
of great interest and value to our mesh group!

However, it would be helpful in the future if you first ask and listen to
find out which discussions we have already had and which solutions we have
already arrived at and afterwards chime in with thoughts and considerations
that have not occurred to us. This is the bay area. If a idea occurs to
you, check with your network. Ten people will have almost identical ideas,
two of them will be working on a related piece of software, and one will
point out that there's already an app for that :)

-- 
Marc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sudoroom.org/lists/private/mesh/attachments/20130711/67d1691b/attachment.html>