✨ Feature Suggestion | disable sensor in firefox #2084

New Issue

2020-10-07T23:35:06Z

rhjdvsgsgks commented

2020-10-07 23:35:06 +00:00

(Migrated from github.com)

search device.sensors in about:config , turn all "enable" flags to false, can be used to prevent websites from use accelerometer to record audio indirectly

blacklight447 commented

2020-10-08 08:20:24 +00:00

(Migrated from github.com)

Seems like a reasonable addition, @Thorin-Oakenpants what do you think?

Thorin-Oakenpants commented

2020-10-08 09:28:22 +00:00

(Migrated from github.com)

ignore it, close with prejudice

blacklight447 commented

2020-10-08 15:13:27 +00:00

(Migrated from github.com)

Any elaboration?

rhjdvsgsgks commented

2020-10-08 16:18:21 +00:00

(Migrated from github.com)

@Thorin-Oakenpants
sorry, i'm not a native speaker of english, and i can't understand what means of "prejudice" here, could you please explain it ?
if you think i have some prejudice in what i said before, i apologize to you here

@Thorin-Oakenpants sorry, i'm not a native speaker of english, and i can't understand what means of "prejudice" here, could you please explain it ? if you think i have some prejudice in what i said before, i apologize to you here

gary-host-laptop commented

2020-10-08 19:13:59 +00:00

(Migrated from github.com)

It seems like a good addition, if it does what you say it does, for laptop users or people who have a microphone plugged in all day on their desktop machines.

rhjdvsgsgks commented

2020-10-08 21:36:57 +00:00

(Migrated from github.com)

@LongJohn-Silver
I think you may misunderstand, this flag is more target to mobile platform which have accelerometer. if you want to prevent website access microphone, you can deny "microphone" permission

@LongJohn-Silver I think you may misunderstand, this flag is more target to mobile platform which have accelerometer. if you want to prevent website access microphone, you can deny "microphone" permission

Thorin-Oakenpants commented

2020-10-09 05:15:38 +00:00

(Migrated from github.com)

Any elaboration?

where are the sources, papers on this? (not doubting op, and I already know sensors have other FP issues: but everything needs sources in order to evaluate)
what is the actual threat? e.g. I know sensors provide a high precision timestamp and the application of that means different things. What is the end threat here of this "audio recording" - what is it recording. Audio may just a simple way to hash the combined sensor data and is not required .. this is why we need sources
what is the proper solution? i.e not some blanket "set everything to false"
what do Mozilla and RFP and TB say
who is this solution targeted at? - Fenix users with about:config access, right? That's very niche
who is PTIOs audience?

edit:

if you think i have some prejudice in what i said before, i apologize to you here

you're all good: no need to apologize - I was implying (to blacklight) that this ticket is useless "as is": requests should provide sources, proofs, analysis etc.. at least something - and I already know the answers (I think) and I'm 99% sure that it won't be actioned for PTIO's website: I just can't be bothered a lot of time to have to explain everything: it gets really repetitive and annoying and time wasting - so "useless" tickets in my own repos I just close them as invalid (which can seem a bit rude at times)

so if anything, I apologize to you

> Any elaboration? - where are the sources, papers on this? (not doubting op, and I already know sensors have other FP issues: but everything needs sources in order to evaluate) - what is the *actual* threat? e.g. I know sensors provide a high precision timestamp and the application of that means different things. What is the end threat here of this "audio recording" - what is it recording. Audio may just a simple way to hash the combined sensor data and is not required .. this is why we need sources - what is the proper solution? i.e not some blanket "set everything to false" - what do Mozilla and RFP and TB say - who is this solution targeted at? - Fenix users with about:config access, right? That's very niche - who is PTIOs audience? edit: > if you think i have some prejudice in what i said before, i apologize to you here you're all good: no need to apologize - I was implying (to blacklight) that this ticket is useless "as is": requests should provide sources, proofs, analysis etc.. at least something - and I already know the answers (I think) and I'm 99% sure that it won't be actioned for PTIO's website: I just can't be bothered a lot of time to have to explain everything: it gets really repetitive and annoying and time wasting - so "useless" tickets in my own repos I just close them as invalid (which can seem a bit rude at times) so if anything, I apologize to you

Thorin-Oakenpants commented

2020-10-09 16:56:15 +00:00

(Migrated from github.com)

I commented at tor project - typically this is something that should get handled upstream under RFP: most likely under bugzilla 1562290

I commented at [tor project](https://gitlab.torproject.org/tpo/applications/fenix/-/issues/40074#note_2711271) - typically this is something that should get handled upstream under RFP: most likely under [bugzilla 1562290](https://bugzilla.mozilla.org/show_bug.cgi?id=1562290)

rhjdvsgsgks commented

2020-10-09 17:31:23 +00:00

(Migrated from github.com)

here is the source and paper (maybe)

[here](https://www.ndss-symposium.org/ndss-paper/learning-based-practical-smartphone-eavesdropping-with-built-in-accelerometer/) is the source and paper (maybe)

Thorin-Oakenpants commented

2020-10-09 18:05:55 +00:00

(Migrated from github.com)

thanks - i'll add that to the tor ticket notes

Thorin-Oakenpants commented

2020-10-12 19:55:32 +00:00

(Migrated from github.com)

IMO, you can close this. My source tells me it looks like this attack is impractical from a webpage. Also note the default settings: ambientLight and proximity aren't exposed. Orientation doesn't matter (except allow you to change orientation: big deal) and the master switch .enabled is immaterial, as is the .test.events

Which only leaves motion. I didn't read the paper in detail. But this is a very niche attack, if even at all possible/practical within Fenix

device.sensors.*

- ambientLight.enabled ; false // devicelight (false since FF62)
- enabled              ; true
- motion.enabled       ; true
- orientation.enabled  ; true
- proximity.enabled    ; false // userproximity and deviceproximity (false since FF62)
- test.events          ; false // FF70+

IMO, you can close this. My source tells me it looks like this attack is impractical from a webpage. Also note the default settings: ambientLight and proximity aren't exposed. Orientation doesn't matter (except allow you to change orientation: big deal) and the master switch .enabled is immaterial, as is the .test.events Which only leaves motion. I didn't read the paper in detail. But this is a very niche attack, if even at all possible/practical within Fenix device.sensors.* ``` - ambientLight.enabled ; false // devicelight (false since FF62) - enabled ; true - motion.enabled ; true - orientation.enabled ; true - proximity.enabled ; false // userproximity and deviceproximity (false since FF62) - test.events ; false // FF70+ ```

Thorin-Oakenpants commented

2020-10-13 23:46:12 +00:00

(Migrated from github.com)

I knew I was missing something: it's already covered by RFP: 1369319

I knew I was missing something: it's already covered by RFP: [1369319](https://bugzilla.mozilla.org/show_bug.cgi?id=1369319)

This repo is archived. You cannot comment on issues.