Hi!
There may be legal reasons why we'd need a splash
page,
This could depend on the question how an organization relates to the
network. If network is not "owned" by any organization - who is then
required to put there a splash page? What exactly would it be on the
splash page?
So the only legal requirement I know (from Europe) is that you might
have to collect identifiable information who is using the network to be
able to provide this to law enforcement.
The issue is that you often use private IPs and NAT (at least for IPv4)
so this is pretty useless anyway. And also the idea that users are
anonymous is something I do like.
My conclusion was, that you might want to consider splash page only on
the gateway (the node which has Internet access) and not all nodes. So
connecting to the network does not require you to confirm the splash
page. Going to the Internet does.
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.
Yes, we had this as well. Even syncing of this information between
nodes. It is a good think.
One other (related) useful think about captive portal is that you can
add timeouts. For example, that user has to confirm a captive portal
every 3 hours. This is a simple measure to quite cut the over the night
leeching of Bittorrents, if you will have issues with them. But it goes
against the "don't show the splash page" concept. So this is why we had
the "don't show the splash page" registration on our main webpage. Not
on the splash screen. So if you wanted to remove the splash page, you
had to go to our webpage and input your MAC. This is another way to get
attention to your project.
Yes we know this, but since captive portal is the only
way that that will
allow us to tell users anything about the mesh
I agree.
As I said, we are also planing to bring the captive portal online, but
it will be on the gateway and it will just intercept and redirect the
first 80 request. It will not block any traffic and it will not display
a captive portal page instead of the original page, it will do the
redirect. (Some captive portal software just sends the captive portal
back, this was problematic because it confuses favicons if nothing else.
And it might trigger some phishing warnings.)
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.
We are now using this approach, yes. And I think it is quite effective.
SSID is an URL:
open.wlan-si.net
Works pretty well I would say. Based on number of e-mails we get when a
node goes down and they are used to it. So people do figure how to
contact us when things are not working.
If the uplink to the internet fails, then the captive
portal should tell
people.
Yes. We had that. If OLSR on the node noticed, that default route was
not announced anymore over OLSR (which means gateway is not reachable
anymore), it put up another splash screen explaining that the node is
not connected to the network:
https://github.com/wlanslovenija/firmware-packages-opkg/blob/master/util/no…
It was quite tricky to make it work right and not lock out on strange
routing tables fluxes.
I personally think now that it is better to not show anything in such
situations because it could lock people out. Or maybe maybe some info
screen which would help people communicate inside the separated mesh
part (most people don't know what to do once Internet is down - what can
they use, how can they communicate). Maybe a captive portal is useful in
such cases. But then, it should not prevent communication. And how does
one get back to this information, once it confirms the captive portal?
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.
This is not roaming then. Roaming is that I do not want any
interruption. Once I register to the network, I just want to have
everything working. OK, if you will block only 80 then you might have
this. But imagine that you are blocking everything. Then I am on a VoIP
call and I move between nodes. Bam. VoIP call terminates. I have to open
a captive portal, confirm. Call again. OK, I can check the button "don't
display captive portal again", but this brings another issue of syncing
this information between nodes, if you want that this "check" is global.
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.
Yes. I am currently thinking about possible integration with existing
social network platforms (like Diaspora or
http://pump.io/). It seems
easier to integrate IP-based (GeoIP) or some other way-based notion of
nodes into the social network, but reusing existing code.
What I am missing, I would go into a decentralized architecture with
this, is something which integrates nicely with Zeroconf. So that even
when there is no gateway and users are not technically skilled, they can
still connect to some common chat with Skype, iChat, Adium or some other
chat client with supports Zeroconf/Bonjour. Sadly, not many closed
source do (and also this support is limited, probably still requires
Internet access, haven't tried it yet).
Why would you implement something like this as a
centralized service? That
seems lazy. Decentralized networks should run decentralized services.
I tend to first implement something centrally, to even try if the idea
is good. And then distribute. But I know that we disagree on that. For
me, it is just a practical approach. Do I want to spend one year
implementing a framework to develop my distributed app running on nodes.
Or do I want to spend one year working on a app itself.
It just boils down to how many developers there is. I rather spend time
on something which can be used immediately and by everybody (so it has
to work as they people are used to).
But please, teach/show me how can be this done easier. Maybe I am just
an old school guy who has not yet grasped some new framework which
allows to do this. Is there a framework like
http://www.meteor.com/,
just distributed and would run on nodes themselves?
A good opportunity to write it as a decentralized
service instead then.
Yes! Or maybe use something existing instead of writing from the scratch.
Honestly the idea of having a community web app as a
splash page
occurred to us early on
Yes. This idea is nothing new. But the important parts are in details.
The ones I like the most are two:
- that you integrate both existing service provided geo-based content
(Yelp, Google Maps) and a way for users to augment this content through
a social network integrated with the community web app
- that you can share the content based on the distance from the node you
are sharing, only node, one hop, more hops, to get back into (social)
sharing the concept of physical properties of sound/wave propagation;
that you can again have the intuitive feeling of the reach of what you share
we are well aware of the problems associated with
captive portals.
True. But then there is difference between being aware and getting
e-mails about how the network doesn't work because of captive portals
and learning how much is this really a problem.
Again, the difference is in details. Like: block only 80, have it only
on the gateway (which might not be relevant to you as you do not (yet)
have centralized gateways).
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 :)
We will sync eventually. :-) Eventual consistency. :-)
Mitar
--
http://mitar.tnode.com/
https://twitter.com/mitar_m