945047 - Uncertified apps cannot manage/use ad-hoc wifi connectivity

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Wifi, defect)

Description

[walter]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:25.0) Gecko/20100101 Firefox/25.0 (Beta/Release)
Build ID: 20131201175730

Steps to reproduce:

I want to write an application that makes use of ad-hoc wifi links, for situations in which network connectivity is not present. These situations are common in the developing world, which is a target market.


Actual results:

The wifi-manage permission requires a certified application, according to https://developer.mozilla.org/en-US/Apps/Developing/App_permissions


Expected results:

There should be some way for the system to proxy an application's wifi management to the user in order to manually approve operations (such as listing wifi networks, connecting to a wifi network, etc.) so that jumping through the expensive certification hoop (and all of its maintainance overhead) is not required.

Such a feature should not significantly impact overall security.

However, it will enable a much broader range of real world use for the intermittent or poor connectivity scenarios popopularly found in the developing world, which is a stated target market for Firefox OS devices.

Use cases include one device and another wanting to link over wifi, and multiple devices wanting to share a wifi link.

The current wifi code 'connection sharing' apparently designates one device as the network AP. However, there are also ad-hoc networking modes apparently supported by the wpa_supplicant layer that facilitate ad-hoc wifi networking without requiring one device to be overwhelmingly responsible (ie. network survives the death of the initial device).

Some random use cases: sharing apps, sharing app updates, sharing system updates (see #802118), sharing media, playing games, sharing data.

Incidentally a few years ago I heard of a cross-platform, commercial API to achieve similar things executed over bluetooth or wifi or internet. If bluetooth were viable and desirable (for example if the user is already online and thus the wifi chipset is in use, but also wants to do an ad-hoc local network), then it could be desirable to implement a layer of abstraction to this API for achieving local ad-hoc networking over arbitrary link-layers.

Comment 1

[Paul Theriault [:pauljt] (no longer reading bugmail)]

Note this use case probably depends on 934292. It was going to dupe this bug, but I think the use case your describe is more complex that simply allowing access to the existing API so I am leaving this open.

Comment 2

[Julien Wajsberg [:julienw]]

Related to bug 890261 too ;)

Comment 3

[walter]

Attachment: Document exploring forward thinking in this area

I had begun to write this more than a month ago but unfortunately have been traveling. Rather than let it go to waste I rounded it out (albeit with less technical detail than I would have liked) in the hopes that it can foster some discussion.

Comment 4

[Vincent Chang[:vchang][changyihsin]]

wifi supports in FFOS is relied on wpa_supplicant which is provided by partner mostly. It may depend on if wpa_supplicant supports ad-hoc mode or not. I used to try it on Unagi with no luck.

Comment 5

[BMO Automation]

Firefox OS is not being worked on