Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add API for requesting permission to receive device motion / orientation events #57

Closed
cdumez opened this issue Dec 13, 2018 · 124 comments
Closed

Comments

@cdumez
Copy link
Contributor

cdumez commented Dec 13, 2018

Due to the privacy issues related to this API (e.g. https://www.wired.com/story/mobile-websites-can-tap-into-your-phones-sensors-without-asking/ and https://arxiv.org/pdf/1605.08763.pdf), we are considering adding to WebKit a permission dialog in order to ask the user if they want to expose their device orientation/motion to the Website.

However, because trackers already register such event listeners on top sites, we are worried about the risk of over-prompting. We wouldn't want this prompt to start showing on a lot of top-sites.

To address the issue, we'd like to propose adding a new API allowing the page's script explicitly ask for permission to access the device / motion. We think we should also require a user-gesture to call this new API.

It could look something like this (similar to Notification API):

[Exposed=(Window)]
interface DeviceOrientation {
  [Exposed=Window] static Promise<boolean> requestPermission();
};

What are your thoughts?

@reillyeon
Copy link
Member

This specification is superseded by the Generic Sensors family of specifications, which include integration with the Permissions API. I think that this specification should be updated with a similar integration by requiring "accelerometer" and "gyroscope" permissions for deviceorientation and devicemotion events and additionally "magnetometer" permission for deviceorientationabsolute events. This would match the existing Orientation Sensor, Accelerometer, Gyroscope and Magnetometer specifications which provide access to the same or similar data.

Is there any plan to implement navigator.permissions.query() in WebKit?

Blink is currently considering similar changes to start notifying users or prompting when sites request access to device sensors. The plumbing is already implemented to manage these permissions however they are still granted by default.

@cdumez
Copy link
Contributor Author

cdumez commented Dec 13, 2018

@reillyeon I may be missing something but where is that API that JS actually calls to request permission for something? navigator.permissions.query() seems to only query, not request.

There is a section in the Permissions API spec about "requesting more permission" but it seems to merely be an algorithm, no actual API for it.

What we want in WebKit is really an API to ask for permission to access device orientation. Without such permission request, the content would not be getting the events at all.

@reillyeon
Copy link
Member

That is correct, I forgot that the navigator.permissions.request() method has been removed in favor of each specification integrating its own method for requesting more permission, but calling into the algorithm you mention. A cursory look at query() made me think that that had been integrated into it instead.

Given that the Generic Sensors specifications I linked to above should be updated to include a requestPermission() method similar to Notification.requestPermission().

As the DeviceOrientation API does not provide an object in the global scope like AbsoluteOrientationSensor or Notification (except perhaps DeviceOrientationEvent) what do you think about not adding a method specific to this API but instead relying on the ones that need to be added to the newer specifications?

My recollection is that WebKit does not implement the deviceorientationabsolute event and so implementing a single RelativeOrientationSensor.requestPermission() method would suffice for your purposes.

@cdumez
Copy link
Contributor Author

cdumez commented Dec 13, 2018

I think relying on a Permissions API from another spec would probably work (although, I'd have to see what it looks like first). That said, it would be bit confusing to use Permissions API from another (newer) API and predicate using the (older) API on it.

How about for the 'devicemotion' events, would it be a LinearAccelerationSensor.requestPermission() ?

Honestly, the fact that the names do not match would be super-confusing IMO.

I get that the DeviceOrientation API does not have a global scope object at the moment but it seems like it could have one. Or I actually like the idea of adding static requestPermission() methods to the existing DeviceOrientationEvent / DeviceMotionEvent interfaces.

@anssiko
Copy link
Member

anssiko commented Dec 13, 2018

navigator.permissions.request() is specified in https://wicg.github.io/permissions-request/

@jyasskin probably knows the status of that work.

@reillyeon
Copy link
Member

I think relying on a Permissions API from another spec would probably work (although, I'd have to see what it looks like first). That said, it would be bit confusing to use Permissions API from another (newer) API and predicate using the (older) API on it.

I believe that use of either API should be predicated on the same permission since they expose the same capability. Having two functions that request the same permission feels like unnecessary bloat but I'm willing to accept that in favor of not confusing developers.

How about for the 'devicemotion' events, would it be a LinearAccelerationSensor.requestPermission() ?

devicemotion events should require the "accelerometer" and "gyroscope" permissions which conveniently is the same as the ones I think should be required for deviceorientation events so a single call could provide the necessary permissions for either event type.

Honestly, the fact that the names do not match would be super-confusing IMO.

I don't disagree. It sounds like navigator.permissions.request() is not as abandoned as I thought it was. That API feels like a better solution.

I get that the DeviceOrientation API does not have a global scope object at the moment but it seems like it could have one. Or I actually like the idea of adding static requestPermission() methods to the existing DeviceOrientationEvent / DeviceMotionEvent interfaces.

That seems reasonable if doing this solely through the Permissions Request API is untenable.

@cdumez
Copy link
Contributor Author

cdumez commented Dec 13, 2018

So if I understand correctly, it would look like:

navigation.permissions.request({ name: “gyroscope” }); // For DeviceOrientationEvents
navigation.permissions.request({ name: “accelerometer” }); // For DeviceMotionEvents

This does not look bad actually.

@reillyeon
Copy link
Member

You need both "gyroscope" and "accelerometer" for both so it would look like:

Promise.all([navigation.permissions.request({ name: “accelerometer” }),
             navigation.permissions.request({ name: “gyroscope” })])
    .then(results => {
      ...
    });

@jyasskin
Copy link
Member

I think w3c/permissions#158 is the most recent discussion about permissions.request(...), and it links to the older discussions. Firefox folks have generally been opposed, Chrome's been in favor, and Edge and Safari have ignored it. I haven't been paying a lot of attention in the last year so can't really help guide here.

@cdumez
Copy link
Contributor Author

cdumez commented Dec 13, 2018

@annevk Based on w3c/permissions#158, it looks like Mozilla considered gating the old deviceorientation / devicemotion events behind a permission as well. Did you end up doing it or do you still have plans to do so?

@annevk
Copy link
Member

annevk commented Dec 14, 2018

@cdumez we haven't made progress on this yet I believe, but I strongly suspect we're still interested. Perhaps not in a generic request() method though, but something specific for this API. Either that, or seeing if we can remove the API altogether (we don't expose it so widely I think).

cc @ehsan

@cdumez
Copy link
Contributor Author

cdumez commented Dec 14, 2018

Yes, I discussed it internally a bit and I do not think we are interested in the generic permissions.request().

A few things we could do:

  1. add a permission request api to this spec
  2. drop the api altogether but there are some legit use cases so it would be unfortunate.
  3. maybe require a user gesture when adding the event listener (and then we’d show a prompt). Avoids over prompting and adding any api.

I would have preferred option 1 I think but given the mess with permissions it seems, I am starting to think about option 3.

@richtr
Copy link
Member

richtr commented Dec 14, 2018

From the study referenced in that Wired article (PDF paper: https://sensor-js.xyz/webs-sixth-sense-ccs18.pdf) the recommendations given to browser vendors are as follows:

  • W3C’s recommendation for disabling sensor access on crossorigin
    iframes [80] will limit the access from untrusted thirdparty
    scripts and is a step in the right direction. However,
    Safari and Firefox are the only two browsers that follow this
    recommendation. Our measurements indicate that scripts
    that access sensor APIs are frequently embedded in crossorigin
    iframes (67.4% of the 31 444 cases). This shows that
    W3C’s mitigation would be effective at curbing the exposure
    to untrusted scripts. Allowing sensor access on insecure
    pages is another issue where browsers do not follow the
    W3C spec: all nine browsers we studied allowed access to
    sensors on insecure (HTTP) pages.

  • Feature Policy API [16], if deployed, will allow publishers
    to selectively disable JavaScript APIs. Publisher may disable
    sensor APIs using this API to prevent potential misuses by
    the third-party scripts they embed.

  • Provide low resolution sensor data by default, and require
    user permission for higher resolution sensor data.

  • To improve user awareness and curb surreptitious sensor
    access, provide users with a visual indication that the sensor
    data is being accessed.

  • Require user permission to access sensor data in private
    browsing mode, limit resolution, or disable sensor access all
    together.

[80] Rich Tibbett, Tim Volodine, Steve Block, and Andrei Popescu.
2018. DeviceOrientation event specification.
https://w3c.github.io/deviceorientation/

[16] Ian Clelland. 2017. Feature policy: Draft community group
report.
https://wicg.github.io/feature-policy/.

This specification could instead be updated to include normative text that limits the sampling rate for deviceorientation, deviceorientationabsolute and devicemotion events to less than or equal to 60 Hz as effective mitigation to fingerprinting and other security and privacy issues.

At that point, a permissions API could then be introduced for accessing higher frequency sensor data from devices. Or, just require higher frequency sensor data to be obtained only via the Generic Sensors API going forward.

Incremental improvements based on these research recommendations seem possible. Putting all access to these events behind a permission dialog seems like a Really Big Gun to start with. It may still be required to eventually look at that approach but for an API that has been available for 8+ years this could be extremely damaging for legitimate use cases given its widespread adoption.

@cdumez
Copy link
Contributor Author

cdumez commented Dec 14, 2018

This would not be acceptable on WebKit-side. Limiting sampling rate for those events would mitigate fingerprinting but not some of the other privacy issues (e.g. The site can tell if the user is standing or laying in bed).

We'd require a user gesture / permission for any of those events. We could also disable the API altogether as @annevk mentioned.

@richtr
Copy link
Member

richtr commented Dec 14, 2018

Determining which way the user is pointing their device is the entire purpose of this API.

Enabling usage for legitimate sites while preventing fingerprinting seems to be the objective of this proposal based on the contents and research in the cited studies.

The studies you referenced to justify this addition do not recommend putting this behind permission prompts as a first course of action. Those studies present many other options that could be considered.

Why the immediate and full rejection of all recommendations from your own references?

@cdumez cdumez closed this as completed Dec 14, 2018
@cdumez cdumez reopened this Dec 14, 2018
@geoffreygaren
Copy link

Why the immediate and full rejection of all recommendations from your own references?

Though the attached research paper investigated quantization,

(a) It acknowledged that quantization only reduced the fingerprinting surface area, and did not eliminate it;

(b) It acknowledged that quantization, though it did not break a toy game, might still break other important use cases;

(c) It did not address at all concerns like key logging and other forms of privacy invasion, which are mentioned in the Wired article;

(d) It did not address the unusually high power impact of the motion and orientation (which we probably should have mentioned earlier).

I don't think we reject quantization as an area of investigation. Rather, we acknowledge that quantization is an area of investigation, and we also acknowledge the need to solve this privacy and security problem without waiting for the conclusion of an open-ended investigation.

@reillyeon
Copy link
Member

I am in favor of adding requestPermission() methods to DeviceOrientationEvent and DeviceMotionEvent (as well as the equivalent Generic Sensors APIs). Acknowledging WebKit's concerns I think it is reasonable for an implementation to choose to completely deny permission for these APIs by default if they wish to. Blink's current plans are to,

  1. Implement a permissions API allowing a site to request a particular level of precision and/or frequency.
  2. Allow access to the existing level of precision and frequency by default.
  3. Notify the user that a site is using the device sensors and allow them to revoke permission.

(2) is necessary to maintain compatibility with existing sites and the existing information leaks are partially mitigated by (3). (1) provides a framework for enabling (a) future use cases that require more data and (b) a move towards reducing the amount of data available without a permission in a gradual fashion in order to allow sites to adapt.

@richtr
Copy link
Member

richtr commented Dec 19, 2018

@reillyeon If we must add permissions to this API then your approach seems like a least disruptive way to do that - progressively reducing the data available (assuming (2) continues to be available by default without permissions). We could also add a relevant console warning message during this process informing developers of the planned change to access in future releases.

What the research in https://arxiv.org/pdf/1605.08763.pdf suggests is that a combination of reducing the frequency of events + sensor obfuscation + sensor quantization would be enough to significantly fix security and privacy concerns in this thread without significantly disrupting web app UI and UX for legitimate actors. Permission dialogs or any changes that disrupt a user's flow while using a web app should be considered as a last resort (when all you have is a hammer...).

There is going to be a disruptive impact of adding permission requirements for sensor events on the nascent web VR/AR/360 ecosystem. e.g. Developers will need to start wrapping their calls for sensor events within user-gesture events IIUC. It is unclear if or how permission requests would display if called from within e.g. iframes (with e.g. correct allow attributes cross-origin).

Anything we can do to reduce the impact of blocked requests and disrupted UI/UX experiences within this ecosystem - gradually introducing such disruptive changes only if all other techniques have been tried and deemed unsatisfactory after further studies, making developers aware of these updates via e.g. console.warn before they land and not just landing these changes one day in mainline browsers without letting existing API consumers adapt - would be very welcome here.

@richtr
Copy link
Member

richtr commented Dec 19, 2018

In summary, changes could be made immediately to implementations by obfuscating, quantizing and/or reducing the rate of sensor event data emitted without impacting the existing API footprint or validity/conformity of implementations to this specification. We could also immediately add security and privacy considerations to this effect to this specification based on these emergent research studies since last publication. We can then continue to discuss additional requirements / API changes as required, hopefully with a view to reducing the impact of those changes on current legitimate consumers of this API.

@19h
Copy link

19h commented Dec 21, 2018

I would very much appreciate a more sober reflection on how this might possibly affect developers and users. The privacy concerns are perfectly valid. But removing the API, or locking it down, will wipe out a complete genre of interactive online games. Not only the ones on the web, but rather those distributed to mobile devices via Cordova (et al.).

Additionally, how do you intend to communicate this permission request to the users? What's the difference between device acceleration and orientation data for the end-user? What if the user only permits either of them? Based on what rationale? What if the user does not understand the requested sensor function?

Does requesting permissions protect users? Or does it simply limit the “tracking” to big platforms that provide so many features that there's at least one with a credible use case for one of these APIs, opening them for the whole rest of the platform?

I'm unconvinced these questions have sufficiently been answered.

@annevk
Copy link
Member

annevk commented Jan 2, 2019

@richtr you have two-out-of-three implementers saying that's not enough. That doesn't seem like a good summary to me.

@richtr
Copy link
Member

richtr commented Jan 7, 2019

There are many softer approaches to be explored here as opposed to implementing a black-and-white “on/off” switch straight out of the gate.

Following your current course will effectively destroy nascent VR/AR/360/gaming companies and industries and pretending otherwise is silly.

I want to avoid a cliff-edge scenario where access to these sensors would change overnight without proper planning — particularly in browsers where no platform-alternative browser engines exist.

For that purpose there are many many intermediate steps, recommended in the cited papers - before you need to implement on/off switches for an 8+ year old API. Jumping straight for that approach is incredibly hostile to web developers. Have you evaluated the full impact that would have?

That is the purpose of the summary above.

@cdumez
Copy link
Contributor Author

cdumez commented Jan 7, 2019

I believe @geoffreygaren’s comment above explains why we want a permission api and user consent in WebKit. For us, it is either this or disabling the API by default until we can make it safe. The other proposals do not address all our concerns as explained by Geoff.

@richtr
Copy link
Member

richtr commented Jan 9, 2019

For us, it is either this or disabling the API by default until we can make it safe.

All content relying on the API will break overnight. No replacement sensor access is provided on WebKit (Generic Sensors API). No alternative browser engines are allowed on iOS so there is no way to keep any applications relying on those APIs running. No deprecation strategy is planned warning developers of disruption or revocation of sensor data before they land in Safari. A cliff-edge backward-incompatible fall-off of usage is deemed the correct way to modify an extensively used 8+ year old web platform API.

Browser-based content and embedded web view content in native applications will cease operation in all of the following use cases:

  • Games and gaming
  • Navigation
  • Virtual Reality
  • Augmented Reality
  • 360 viewers (videos, panoramas)
  • 3D scanning
  • Gesture recognition
  • Step counters
  • Physical activity monitoring
  • Sleep monitors

Multiple proposals exist to make the emitted motion sensor data both a.) still useful for legitimate use cases and b.) resistant to raised security and privacy concerns by refining/limiting the data emitted in different ways. Those solutions will not be considered further because the effectiveness of those solutions needs further investigation/research even though they are cited as potentially resolving all current security and privacy concerns by the original investigators. Instead we will modify the API invocation to require permissions/user-gesture or just remove the whole API because it is easier, less implementation work and resolves all security and privacy concerns because then there are no use cases or usage anymore.

Now contrast this to the alternative approach/summary I posted above.

@zchrykng
Copy link

zchrykng commented Jan 9, 2019

Browser-based content and embedded web view content in native applications will cease operation in all of the following use cases:

  • Games and gaming
  • Navigation
  • Virtual Reality
  • Augmented Reality
  • 360 viewers (videos, panoramas)
  • 3D scanning
  • Gesture recognition
  • Step counters
  • Physical activity monitoring
  • Sleep monitors

How many of these things are implemented as web apps/views? And why would requiring them to ask permission be that big of a deal? There is exactly zero people who should be able to access any of this data without asking for permission, in my opinion. And I honestly couldn't care less how many business models or apps would be affected by having to ask permission. If the app is scared of asking for permission first, I don't want them having my data anyway.

@eligrey
Copy link
Member

eligrey commented Jan 10, 2019

Companies like UnifyID use gyroscope data for user gait profiling. I would definitely prefer if gyroscope data required permission to access.

@andrewmd5
Copy link

andrewmd5 commented Jan 10, 2019

Sacrificing UX in the name of a slight privacy increase is regressive at best. Not only will most end-users not understand what granting the permission actually entails, it just creates friction when trying to build solutions that “just work.”

In HTML5 eBook reader I created I actually leverage device orientation to determine when someone is laying down to suggest turning on night mode at certain hours. There are plenty of valid reasons not to put these standard features behind a permissions prompt.

Throttling polling rates is a decent mitigation.

@anssiko
Copy link
Member

anssiko commented Jan 10, 2019

A note on scoping with my chair hat on:

As @reillyeon pointed out earlier, DAS WG's position is this specification is superseded by the Generic Sensors family of specifications which include integration with the Permissions API. The DAS WG considers this spec to be in maintenance, and as such no new feature work per charter. The charter is not super clear on this, says "fix remaining known issues and to finish" so I'm open to discussion if someone feels strongly we should add new API surface to this spec.

An alternative transition plan to browsers who are planning to unship this legacy feature sometime in the future would be to first implement (applicable parts of) the new API surface (see Generic Sensor API and related concrete sensors at https://www.w3.org/das/roadmap), and deprecate the legacy API surface only after a reasonable grace period during which web developers are recommended to migrate to the new API that provides the permission hooks and other privacy enhancements.

@neave
Copy link

neave commented Mar 25, 2019

No, it doesn't. I cannot comment on when it will ship but I have already agreed to post a message on this issue when the permission API becomes available in a public beta.

This is disappointing. I hope the API will make it into an update soon.

For anyone looking for a workaround, the best thing to do is to detect the disabled state via a timeout and clear it in the event handler. Something like this:

const id = setTimeout(() => alert('Enable device orientation in Settings > Safari > Motion & Orientation Access.'), 500);

window.addEventListener('deviceorientation', event => {
	clearTimeout(id);
	// ...
});

@keithito
Copy link

keithito commented Apr 8, 2019

To add to @neave's workaround, it appears the deviceorientation API still works in Chrome, so you could prompt the user to open the page in Chrome if you detect that deviceorientation is broken. Something like:

<div id="nodeviceorientation" style="display:none">
  This page no longer works in your browser.<br>
  <a href="googlechromes://YOUR_URL">Open in Chrome</a> or 
  <a href="itms-apps://itunes.apple.com/us/app/chrome/id535886823">Install Chrome</a>
</div>

<script>
const id = setTimeout(() => {
  document.getElementById('nodeviceorientation').style.display = 'block'
}, 500);
window.addEventListener('deviceorientation', (e) => clearTimeout(id));
</script>

Not a great solution, but possibly the easiest option for the user given the current state of things.

@EvanBacon
Copy link

@cdumez it'd be nice if toggling the switch at Settings > Safari > Motion & Orientation Access. would reset the Safari app, this would be analogous to toggling native app permissions.
Otherwise the developer would need to observe the app state and attempt to resolve motion access again.

@micsun-al
Copy link

Fun edge case...
iPad Air (MD785LL/A) + iOS 11.4:
Does not emit either devicemotion or deviceorientation events if the tablet is laying flat on it's back (on a table or whatever).

iPhone X + iOS 12.2 + "Motion and Orientation Access" on:
Laying on a table does emit both events.

I guuuesss we can add a some window.navigator.userAgent checks, but getting in to the "pretty janky checks" arena :\

@reillyeon
Copy link
Member

Regarding the last couple comments, please report implementation-specific issues to the appropriate issue tracker.

@nbutko
Copy link

nbutko commented May 14, 2019

@cdumez Does iOS 12.3 add an implementation for the request permissions spec?

@reillyeon
Copy link
Member

For WebKit and iOS questions please use bugs.webkit.org and bugreport.apple.com respectively. This is not the right place to ask about implementation status in particular engines.

@nbutko
Copy link

nbutko commented May 14, 2019

@reillyeon is there a link to an existing bug that we can track progress and get updates on?

@reillyeon
Copy link
Member

I searched bugs.webkit.org but didn't find one. @cdumez might be able to provide a link.

@cdumez
Copy link
Contributor Author

cdumez commented May 14, 2019

Bugs.webkit.org is not a way to track when a particular feature ships. Apple also does not comment on when a particular will ship.

@nbutko Please coordinate internally. I already asked Erik from 8th Wall to file a bug on bugreport.apple.com and he did (49748962). When the feature ships, this bug should get closed and you will be notified.

You could also simply test if DeviceOrientationEvent.requestPermission is defined in any new build that comes out (it is not in 12.3), or even ping me on Twitter (@chris_dumez) where I am already in contact with 8th Wall.

Just please let's stop pinging on this GitHub issue.

@cdumez
Copy link
Contributor Author

cdumez commented Jun 3, 2019

For people interested in trying out this new API on iOS, I suggest installing the iOS 13 developer beta 1. If you find issues, please file them at https://bugs.webkit.org, not here. I am also happy to answer questions on Twitter (@chris_dumez) or at WWDC WebKit Labs this week for those attending.

@elmariocarlos
Copy link

Hi @cdumez I'm having some problems requesting permissions for Motion Sensors on WkWebKit.

My team was able to succesfully request permisions when we were navigating using Safari. But when using a WebView in App, althought we use the same function and calls, the permission window does not appear.

We have already tested adding further permissions to the iOS app in our Info.Plist, but it's just not working.

Any ideas we could pursue?

Thanks in advance for any guidance!

@cdumez
Copy link
Contributor Author

cdumez commented Oct 18, 2019

This is not the place for WebKit support. Please file bugs on bugs.webkit.org or ping me on Twitter.
WKWebView currently has access the device motion and orientation without permission so we did not expose the permission API there. This may change in the future though.

@elmariocarlos
Copy link

Hi @chris_dumez I filed the bug here, let me know if there is any further specification that should be looked at: https://bugs.webkit.org/show_bug.cgi?id=203287

@mvl22
Copy link

mvl22 commented Oct 27, 2019

Useful articles for those wanting to implement this in their client code, showing implementation:

https://dev.to/li/how-to-requestpermission-for-devicemotion-and-deviceorientation-events-in-ios-13-46g2

https://medium.com/flawless-app-stories/how-to-request-device-motion-and-orientation-permission-in-ios-13-74fc9d6cd140

@gkoberger
Copy link

Just a quick note for anyone who keeps running into denys without seeing a prompt; you need to be in https or it won't work! I wasn't able to get this working locally for this reason, but it works otherwise.

@solarsu
Copy link

solarsu commented Nov 11, 2019

Hi @cdumez I have the same problem
1.when I use UIWebview in ios13 iphone and and the address is https://www.audero.it/demo/device-orientation-api-demo.html it can work
2.but when I use WKWevView in the same iphone and same address it can't work
3.when I use UIWebview in ios12.3 iphone and and the address is https://www.audero.it/demo/device-orientation-api-demo.html it can work
how can I get the the device motion and orientation without permission in ios 13 by WKWebView
ths

@yoyo837
Copy link

yoyo837 commented Nov 11, 2019

iOS 12.2+ (Privacy switch turned on):

- http https
Safari No Yes
WebView No Yes

iOS 12.2+ (Privacy switch turned off):

- http https
Safari No No
WebView No Yes

@solarsu
Copy link

solarsu commented Nov 11, 2019

@yoyo837 thank But I want to know how WKWebView turned on in ios13

@cdumez
Copy link
Contributor Author

cdumez commented Nov 11, 2019

Hi @cdumez I have the same problem
1.when I use UIWebview in ios13 iphone and and the address is https://www.audero.it/demo/device-orientation-api-demo.html it can work
2.but when I use WKWevView in the same iphone and same address it can't work
3.when I use UIWebview in ios12.3 iphone and and the address is https://www.audero.it/demo/device-orientation-api-demo.html it can work
how can I get the the device motion and orientation without permission in ios 13 by WKWebView
ths

Bugs.webkit.org is the right place for WebKit support.

Also, I have just tried https://www.audero.it/demo/device-orientation-api-demo.html in a WKWebView and it worked fine. To test, I used the WebView app in the App Store.

@reillyeon
Copy link
Member

I'm locking this issue. Please use the WebKit issue tracker for questions about WebKit's implementation.

@w3c w3c locked as off-topic and limited conversation to collaborators Nov 11, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests