Closed Bug 866718 Opened 9 years ago Closed 4 years ago
Automatically connect to openwireless
.org Wi Fi networks if no others available
Mozilla is looking at becoming a formal supporter of the Open Wireless Movement (https://www.openwireless.org/), started by the EFF. It is permitted and encouraged for devices to connect to Open Wireless networks automatically and without user intervention. As a practical indicator of that support, and as a useful Firefox OS feature, I want to investigate the possibility of us getting Firefox OS to automatically connect to openwireless.org networks. No doubt this would require a little discussion on exactly how this would work. I would anticipate such networks being low priority, connected to only if no explicitly known network is available. For bonus points, we might also warn the user if they have used more than a certain amount of bandwidth on such a network. There may be other ESSIDs which are used for the purpose of indicating "open!" which we could enable in the same way (but not Free Public Wifi! - http://www.npr.org/2010/10/09/130451369/the-zombie-network-beware-free-public-wifi ). Another thing I am filing a bug on is having Mozilla provide openwireless.org ESSID networks in all our offices (bug 866716). The combination of this bug and that one might be very useful for Mozillians. Gerv
dlee/vchang: do either of you know who the right person is to give their opinion on this? Gerv
Requesting NEEDINFO from people who I think might be able to correctly direct this bug. Gerv
Hi gerv, nice to meet you. AFAIK, wifi Boardband alliance defines WISPr 2.0 that supports similar functionality. Is it something we can begin with ? Or openwireless.org proposes the other protocol to deal with this ? Or even easier that we just have built-in database and connect to a AP automatically when the scan result contain SSID in database ?
Hi vchang, Yes, I'm proposing the latter, very simple system. It would be a 'database' of one SSID (at the moment :-). We might want to make the list configurable, I don't know. The point is, openwireless.org networks are designed for devices to automatically connect to and start using (politely). So, whereas it might be legally complicated for us to connect to random open wireless networks in the general case, we can do it in this case. Which means that Firefox OS devices will be more connected more of the time, and often for free rather than using a data plan. If we also manage to get our office networks to advertise themselves additionally as open wireless (bug 866716) then Firefox OS devices would auto-connect in our offices too. Which would be nice. Gerv
In this case, it should be easy for gaia developers to support this with exist wifi APIs. Ask opinions from gaia developer. :-)
Flags: needinfo?(dlee) → needinfo?(arthur.chen)
Is there any event for gaia to know that gecko is unable to connect to any network? I think we need a timing to request gecko to connect to openwireless.org from gaia.
Flags: needinfo?(arthur.chen) → needinfo?(vchang)
It is handled by wpa_supplicant once you add the network to gecko. Maybe you can use the same way we are doing in the "join hidden network".
Base on the request it said that we should automatically connect to openwireless.org when no others available. Is there any way for gaia to know there is no available network? Then we can use the way same way as "join hidden network" to connect to openwireless.org.
I think vincent's method is "add the network by gaia using wifimanager.associate()", then wpa_supplicant will handle the connection decision afterwards. Or we can make the ssid a default config to wpa_supplicant, then Gaia won't need to do anything. Also I think this function should be default disable, and user should also have the power to disable the function at anytime, including delete the default ssid. Open wifi network is still more dangerous than others, not only the sniffers, also the fake AP performing middle man attack. And not every app is using encrypted protocol to translate data. I don't think normal user is aware of such risk.
(In reply to Chuck Lee [:chucklee] from comment #9) > Also I think this function should be default disable, and user should also > have the power to disable the function at anytime, including delete the > default ssid. I certainly think the list of default-connect SSIDs should be configurable. openwireless.org can be the single shipped value, but users should be able to remove it and add others. > Open wifi network is still more dangerous than others, not only the > sniffers, also the fake AP performing middle man attack. How is an MITM attack made more dangerous by autoconnect? We already (I assume) autoconnect to known network names the user has connected to before. And a user who uses public wifi at all is already connecting to networks they know basically nothing about. In 2014, application authors trusting the privacy of the networks they use are idiots. They should use HTTPS. Gerv
(In reply to Gervase Markham [:gerv] from comment #10) > > Open wifi network is still more dangerous than others, not only the > > sniffers, also the fake AP performing middle man attack. > How is an MITM attack made more dangerous by autoconnect? We already (I > assume) autoconnect to known network names the user has connected to before. > And a user who uses public wifi at all is already connecting to networks > they know basically nothing about. In 2014, application authors trusting the > privacy of the networks they use are idiots. They should use HTTPS. > > Gerv I think there's a different between "user choose to connect a open wifi" and "system connect to a open wifi by default". User might not aware of this behavior. I point this out mainly to say this function is better to be default disable.
We have been meaning to write this up somewhere, but... It may make sense to have a convention like: "openwireless.org" -- feel free to join, but try to avoid very large (gigabyte scale) transfers unless it's an emergency "m.openwireless.org" -- this is a tethered 3G/4G device. Do not join this network if you are a client with your own live 3G/4G connection, and avoid bulk data transfers. "fast.openwireless.org" -- this is a very well provisioned open wireless network, feel free to treat it like your own internet connection or perhaps even a datacenter link
(In reply to Chuck Lee [:chucklee] (PTO Jan. 29 ~ Feb. 5) from comment #11) > I think there's a different between "user choose to connect a open wifi" and > "system connect to a open wifi by default". User might not aware of this > behavior. > I point this out mainly to say this function is better to be default disable. We strongly encourage default-enabled connection to "openwireless.org" networks. I'm sure someone will make some security counterarguments, but I believe those people are unrealistically optimistic about the security of the networks they currently connect to.
I think Chuck had answered the question in comment 9.
(In reply to Peter Eckersley from comment #13) > I'm sure someone will make some security counterarguments, but I believe > those people are unrealistically optimistic about the security of the > networks they currently connect to. Indeed. There is a plan to create "openwireless.org" networks in all the Mozilla offices, so Firefox OS devices can autoconnect there. This requires this feature to be default-on in order to realise the seamlessness benefits. How can we make progress here? Does this bug need to be on some tracking radar? Gerv
Bruce, can we add this item to the product backlog?
Ravi, are you familiar with the background on this?
Flags: needinfo?(bhuang) → needinfo?(rdandu)
According to bug 866716, we now have "openwireless.org" networks in SF and MV, hopefully with more to come. So once this bug is implemented, Firefox OS devices will have automatic network connections in those offices. Gerv
This is in the backlog: WLAN22 in "FxOS Product Backlog" document
The openwireless.org ESSID has now been deployed to all Mozilla offices. So if this feature gets implemented, Firefox OS phones will have automatic network access in all our offices. That would be most cool. Gerv
Hi Henry, this does not block 1010733, can you confirm?
This bug is related to having a pre-loaded list of SSID so that we can notify the WISPr app even it's never executed before. But after re-checking the spec, this seems not the requirement so it only relates to bug 1010733 but not blocks it.
In Europe we have a similar organization called "Freifunk": http://freifunk.net/ There are already thousands of free access point in Germany.
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.