On 2014-04-16, 10:52 AM, Benjamin Smedberg 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?
Beacons do not enable any new ways of tracking which is not already
possible. They just allow the client to not have to wait around for the
tracking server to respond, contrary to the existing tracking facilities
(XHR, HTTP navigation, etc.)
Cheers,
Ehsan
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
