On Apr 16, 2014, at 10: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? > > --BDS > I think the answer is that beacons are good for whenever you want to push state to the server and don't care about getting results back. So both tracking (as the name implies) and persisting state. I expect tracking to be the initial use case, but I wouldn't be surprised to see it get picked up for other cases within the category above, since the API is a lot simpler than XHR. As far as preferences, the bug to enable it by default leaves the preference there, so it could be disabled by, say, an add-on. --Richard
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
