Re: Intent to remove Ambient Light and Proximity sensor APIs

[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.

2018-03-01 14.03.33 UTC+2 Jonathan Kingston wrote:
> 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  wrote:
> 
> > On Mon, Dec 18, 2017 at 7:36 PM, Gervase Markham  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/
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to remove Ambient Light and Proximity sensor APIs

[gaurav . genisys]

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.)

On Sunday, 17 December 2017 15:30:06 UTC, 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.
> 
> 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
> 
> 
> 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

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to remove Ambient Light and Proximity sensor APIs

[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  wrote:

> On Mon, Dec 18, 2017 at 7:36 PM, Gervase Markham  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/
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to remove Ambient Light and Proximity sensor APIs

[Anne van Kesteren]

On Mon, Dec 18, 2017 at 7:36 PM, Gervase Markham  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/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to remove Ambient Light and Proximity sensor APIs

[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




signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to remove Ambient Light and Proximity sensor APIs

[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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to remove Ambient Light and Proximity sensor APIs

[Tantek Çelik]

On Mon, Dec 18, 2017 at 5:52 AM, Gervase Markham  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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to remove Ambient Light and Proximity sensor APIs

[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
 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


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

On Mon, Dec 18, 2017 at 7:52 AM, Gervase Markham  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.
>
> 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
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to remove Ambient Light and Proximity sensor APIs

[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

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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


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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform