On Wed, Apr 16, 2014 at 7:52 AM, Benjamin Smedberg <benja...@smedbergs.us> wrote: > On 4/16/2014 9:30 AM, Richard Barnes wrote: >> Allows pages to send a "beacon" HTTP request. Beacons are allowed a >> limited subset of HTTP (only a few content types), and the JS cannot receive >> the content of the response. However, beacon requests will survive after >> the page is unloaded, removing the need for synchronous XHRs in onunload >> handlers. > > Are beacons primarily meant as tracking devices, or is it also meant as a > way to persist unsaved page state when the user navigates? > > I can't imagine that there is any reasonable way to expose UI prefs > specifically about beacons, but should we disable beacons by default if the > user has do-not-track enabled? Or will we leave a hidden pref so that > privacy-sensitive extensions could disable beacon functionality if they > wished?
I would expect that gathering telemetry will be at least as common as doing user tracking. But I would also expect that websites will do things like saving user state when the user leaves a page. So I don't think tying this to do-not-track would be good. / Jonas _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
