Intent to remove Ambient Light and Proximity sensor APIs

[Jonathan Kingston]

I am suggesting the removal of both Ambient Light and Proximity Sensor APIs
via a preference so we can ensure there is no adverse impact to the web
with a quick mitigation if needed.

If there are no issues with this, I plan to push the code early in the new
year to account for the holiday downtime.

Previous attempts have been made to remove these APIs however this intent
to remove *does not* include Device Orientation which will need further
work to deprecate:
https://groups.google.com/forum/#!topic/mozilla.dev.platform/45XApRxACaM

<https://groups.google.com/forum/#!topic/mozilla.dev.platform/45XApRxACaM>
Previous thread:
https://groups.google.com/forum/#!searchin/mozilla.dev.platform/ambient$20light|sort:relevance/mozilla.dev.platform/QI2-SO-1jxY/-CrSbuH-BAAJ

The rationale:

* These APIs have various privacy leaks, including violating the
same-origin policy, without the user being informed or interaction.
* These APIs do not match the current standards for sensor APIs
* There's no interest to address these shortcomings. (Mostly in the sense
of engineering resources and having other problems to tackle first.)
* As these are event-driven APIs the compatibility impact should be minimal
to none. The events simply won't fire.

Work will be implemented here: https://bugzilla.mozilla.org/
show_bug.cgi?id=1359076
Thanks
Jonathan

[Gervase Markham]

On 17/12/17 15:29, Jonathan Kingston wrote:
> I am suggesting the removal of both Ambient Light and Proximity Sensor APIs
> via a preference so we can ensure there is no adverse impact to the web
> with a quick mitigation if needed.

Is it fair to say that after removal of the Proximity Sensor API, no
e.g. WebRTC-based audio-calling webapp will be able to blank the screen
when the user holds the device to their ear?

That seems sad.

Gerv

[Jonathan Kingston]

> Is it fair to say that after removal of the Proximity Sensor API, no
e.g. WebRTC-based audio-calling webapp will be able to blank the screen
when the user holds the device to their ear?

Yes, however this would be the case for all other browsers too.

Given that we are the only browser to implement the event based interface
<https://developer.mozilla.org/en-US/docs/Web/API/Proximity_Events> for
this I don't think we should block on the loss of this feature.

The next generation of these APIs are going through TAG review where many
of the concerns here are still being addressed:
https://github.com/w3ctag/design-reviews/issues/207

<https://github.com/w3ctag/design-reviews/issues/207>
We may be able to reimplement this functionality with the new APIs with far
less granular access and prompted if more granular is needed. There has
also been no real intent from browser makers to ship them despite their
improvements.

Thanks

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[Tantek Çelik]

On Mon, Dec 18, 2017 at 5:52 AM, Gervase Markham <ge...@mozilla.org> wrote:
> On 17/12/17 15:29, Jonathan Kingston wrote:
>> I am suggesting the removal of both Ambient Light and Proximity Sensor APIs
>> via a preference so we can ensure there is no adverse impact to the web
>> with a quick mitigation if needed.

I think this removal is prudent and timely. It is consistent with our
default principles on privacy etc. and good to do it quickly while we
think the potential impact is low at worst.

> Is it fair to say that after removal of the Proximity Sensor API, no
> e.g. WebRTC-based audio-calling webapp

Do you know of a specific (URL?) mobile-device-capable (which
device(s)?) WebRTC-based audio-calling webapp that works today? I
would be very interested in testing it out.

> will be able to blank the screen
> when the user holds the device to their ear?
>
> That seems sad.

It's likely worth capturing your use-case in the Sensors Use-cases doc:
* https://w3c.github.io/sensors/usecases

That specific use-case doesn't seem to be in there, so go ahead and
file it here and feel free to cc: @tantek
* https://github.com/w3c/sensors/issues

Thanks,

Tantek

[Gervase Markham]

On 18/12/17 18:25, Tantek Çelik wrote:
> Do you know of a specific (URL?) mobile-device-capable (which
> device(s)?) WebRTC-based audio-calling webapp that works today? I
> would be very interested in testing it out.

appear.in, which supports both audio and video calling via WebRTC, works
in Firefox for Android, although performance is not awesome on my Z3C
Compact.

It does not blank the screen when you place the device to your ear.

Gerv

[Peter Saint-Andre]

On 12/18/17 11:36 AM, Gervase Markham wrote:
> On 18/12/17 18:25, Tantek Çelik wrote:
>> Do you know of a specific (URL?) mobile-device-capable (which
>> device(s)?) WebRTC-based audio-calling webapp that works today? I
>> would be very interested in testing it out.
>
> appear.in, which supports both audio and video calling via WebRTC, works
> in Firefox for Android, although performance is not awesome on my Z3C
> Compact.

My old team at talky.io offers both web and mobile WebRTC, too:

https://talky.io/

(For mobile, it's iOS only, not Android.)

Peter

[Anne van Kesteren]

On Mon, Dec 18, 2017 at 7:36 PM, Gervase Markham <ge...@mozilla.org> wrote:
> appear.in, which supports both audio and video calling via WebRTC, works
> in Firefox for Android, although performance is not awesome on my Z3C
> Compact.
>
> It does not blank the screen when you place the device to your ear.

There might be more secure ways we can address this use case. E.g.,
having a dedicated signal just for that, perhaps only given if the
user already granted access to the microphone and such.

(And if something does require the full power of the proximity API, we
should first work out how to expose it securely. I'm sure folks can
come up with use cases for running arbitrary code as root too, but
that doesn't mean we can offer it.)


--
https://annevankesteren.nl/

[Jonathan Kingston]

As an update here the code has landed in 60 from
https://bugzilla.mozilla.org/show_bug.cgi?id=1359076

This adds:
- Deprecation warnings for DeviceOrientation and DeviceMotion sensors.
- Deprecation errors for AmbientLight and Proximity sensors.
- Preferences to control all 4 sensors independently:
- "device.sensors.ambientLight.enabled" - devicelight event and
DeviceLightEvent constructor.
- "device.sensors.proximity.enabled" - deviceproximity, userproximity
events and DeviceProximityEvent and UserProximityEvent constructors.
- "device.sensors.motion.enabled" - devicemotion event and
DeviceMotionEvent constructor.
- "device.sensors.orientation.enabled" - deviceorientation event and
DeviceOrientationEvent constructor.
- In Nightly and Early beta releases the proximity and light sensors are
disabled by default.

My plan is to deprecate light and proximity sensors in Stable Firefox in
version 62 if no issues arise.

Please reach out if you have any questions or concerns.

Thanks
Jonathan

On Tue, Dec 19, 2017 at 7:01 AM, Anne van Kesteren <ann...@annevk.nl> wrote:

> On Mon, Dec 18, 2017 at 7:36 PM, Gervase Markham <ge...@mozilla.org> wrote:

> > appear.in, which supports both audio and video calling via WebRTC, works
> > in Firefox for Android, although performance is not awesome on my Z3C
> > Compact.
> >
> > It does not blank the screen when you place the device to your ear.
>

> There might be more secure ways we can address this use case. E.g.,
> having a dedicated signal just for that, perhaps only given if the
> user already granted access to the microphone and such.
>
> (And if something does require the full power of the proximity API, we
> should first work out how to expose it securely. I'm sure folks can
> come up with use cases for running arbitrary code as root too, but
> that doesn't mean we can offer it.)
>
>
> --
> https://annevankesteren.nl/

[gaurav....@gmail.com]

Originally posted this on the Firefox support forum (https://support.mozilla.org/en-US/questions/1222676), and was advised to post this here as well.

At our Russell Group UK university, we rely on the ambient light sensor heavily for research projects on visual perception, smart devices, etc, using mobile devices for quick and easy variable-location tests. We have been able to do this because Firefox on Android (as far as we know - Chrome doesn't do it, Safari iOS doesn't either, and neither does Opera, to the best of our knowledge) was the only browser to allow access to the light sensor, which is incredibly useful. Now we understand that you have privacy concerns and thus wish to disable the ambient light sensor API completely, but this will completely grind to a halt some of our methods while we redevelop alternatives. We distribute these to participants of psychophysical tests, who so far were simply able to install Firefox on Android and the web-loaded app would just work. We were under the impression that such APIs would become more widely available over time, including other platforms and operating systems, not the other way around where you would end up planning to remove an incredibly useful feature.

Please could you not disable the light sensor, surely there must be other ways, such as asking user permission for access just like you do with the cameras. Disabling the sensor API will be a gigantic step backwards, specially in the scientific community.

(Adding on the above, previously there were indications of the browser community planning to extend sensor readings by introducing additional readable parameters such as camera exposure and white balance. This makes sense, and is a step forward. Similar steps forward would be to enhance sensor access, rather than the other way round.)

[Roni Kantola]

Are there any reasons at all not to make this a feature that simply needs/asks a permission?

Perhaps with a short additional text "Allowing might compromise privacy". Not only for ambient light and proximity sensors, but especially if you want to remove device orientation information too. We already have location and camera permissions, for example. They are much bigger privacy issues, but asking for a permission is rather ok.

If a website asks to get permissions for all of those things, it kind of deteriorates usability, but it's for the website to decide whether they want to have that tradeoff, and for the user to decide whether they trust the website or want to allow something.

I am developing a citizen science website for mapping, and it becomes impossible if you simply deprecate everything. Perhaps an actual app might do the trick, though, but it can be suboptimal.