Device motion data (accelerometer/gyro) not available on Android

Browser Support
1

Issue:
The accelerometer is not supported by mobile Brave on any android device. No issues on iOS.

Same as unresolved bug here: The accelerometer is not supported on mobile devices

Repro steps:

  1. Open 8th.io/motion in Brave on Android
  2. it will attempt to read out device motion data

Expected result:
Each of the fields should constantly update with new motion data.

Current result:
Null values occupy the fields because no motion data is available.

This breaks all websites that rely on window.DeviceMotionEvent including all 8th Wall WebAR sites. This includes websites belonging to Warner Bros, Heineken, BMW, Coca-Cola, Nike, and many others.

Apple has enabled window.DeviceMotionEvent.requestPermission() as a way of prompting users for access to these sensors. If you try 8th.io/motion on iOS, a button appears on the page that uses this functionality.

As a result of this bug, 8th Wall currently routes all users away from Brave and to any other Android browser (all others are compatible).

Tested on Brave 1.30.87, Chromium 94.0.4606.71, Android 11
Samsung Galaxy Z Flip3 5G
Samsung Galaxy Z Fold3 5G
Pixel 5a

2

@rigel-8thwall,
Thank you for bringing this to our attention. I am able to reproduce this issue and have reached out to the Android team for more information on it. Will likely open an issue on Github and will reply here with the link to it for further tracking.

1 Like
3

Howdy all,

Brave intentionally disables these features because inputs from these motion sensors can be used to track users across the web without their consent. When we raised these concerns with the Chromium team in the W3C (around the relevant specs) they did not mention any immediate plans to address. Until their implementation in Chromium is modified so that they’re compatable with Brave’s privacy goals, we expect to keep them disabled (though we’ve discussed, but have no immediate plans to, allow advanced users to re-enable them through brave://flags. The main constraint here is competing demands on engineer time).

You might find these papers of interest if you’re interested in learning more on the topic. They are just a few in this area:

https://dl.acm.org/doi/pdf/10.1145/3243734.3243860

I hope this helps

1 Like
4

Thank you for your quick response!

Apple echoed these concerns back in early 2019. They disabled motion access by default until implementing a permissions request prompt a few months later that mirrored other common device requests (geolocation, camera, microphone, etc).

Following Apple’s implementation would be our request, as it puts the decision in the hands of users without breaking existing web standards developers and businesses rely on.

Thanks

5

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.