| Summary: | (Anti Tracking) Unsupported API's Compromise Request | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Joshua Hamilton <joshua> |
| Component: | WebKit Misc. | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED INVALID | ||
| Severity: | Enhancement | CC: | ap |
| Priority: | P2 | ||
| Version: | Other | ||
| Hardware: | All | ||
| OS: | Unspecified | ||
WebKit Bugzilla is not an appropriate place for a general debate like this. Please feel encouraged to file bugs for specific use cases that your applications have. |
Hello, > Before I start, I am aware of the [Tracking Prevention in WebKit](https://webkit.org/tracking-prevention/) page. After reading the page I am left wondering if there is a middle-ground that can be found in relation to the unsupported API's due to not wanting users tracked. This is the list as of today: - Web Bluetooth - Web MIDI API - Magnetometer API - Web NFC API - Device Memory API - Network Information API - Battery Status API - Web Bluetooth Scanning - Ambient Light Sensor - HDCP Policy Check extension for EME - Proximity Sensor - WebHID - Serial API - Web USB - Geolocation Sensor (background geolocation) - User Idle Detection Looking at this list, these seem more useful for applications; not so much for day to day websites where I imagine marketing (tracking) is more prominent. Seeing as hybrid apps are rather common and having access to these API's would be very helpful (especially when dealing with connecting to external devices); perhaps we could have a flag for each API (above) that enables them in when WebKit is embedded within an application. This could also have the added benefit of have the work done once a way to prevent tracking has been implemented, making rolling it out to Safari potentially easier(?). Thank you for your time.