401670 - change browser.send_pings to be a multistate pref

Status: NEW

(Core :: DOM: Core & HTML, defect, P5)

Description

[Mike Beltzner [:beltzner, not reading bugmail]]

Right now there are two preferences governing <a ping>: browser.send_pings and browser.send_pings.require_same_host

It would be better to provide more granularity over the privacy options for notifications, and I suggest making this a single, multi-state pref:

0: disable
1: send pings to URIs within the same domain as the document containing the link (DEFAULT)
2: send pings to URIs within the same domain as the document containing the link or the same domain as the target of the href
3: always send <a ping>, no restrictions

Also, should we consider defining "same domain" as eTLD+1?

Comment 1

[mv_van_rantwijk]

So in the new situation we end up having the following two preference:

browser.send_pings (type integer)
browser.send_pings.max_per_link (type integer)

May I suggest to rename the preferences in one go and to change it to opt-in instead of opt-out?

And before you reply with: But we have cookies which are opt-out also, but think about this:

1) Browsers do have a pref UI for cookies.
2) There are many web pages about cookies and what they do.
3) Cookies are well know by now (probably because of 1 and 2).
4) There are many tools to block or notify you about when cookies are about to be send.
5) There isn't a single web site blocking me from visiting their website because I block ping (POST) request.
6) The spec is a draft only, and seems to be implemented in the wrong way [1] opening gaps subject to misuse.
7) People using dial up (and SAT [2]) connections might not be willing to pay for the loads/data transfers.
8) This feature was introduced and send POST requests without the end-users consent, and that's part of the spec; to give visitors control over link tracking.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=319368#c3
[2] Some SAT connections are notorious for billing on a per request basis.

Comment 2

[Jesse Ruderman]

If it's disabled by default, no web sites are going to use it, so click-tracking will continue to be done in ways that introduce latency and give users no control at all.

Comment 3

[mv_van_rantwijk]

(In reply to comment #2)
> If it's disabled by default, no web sites are going to use it, so
> click-tracking will continue to be done in ways that introduce latency and give
> users no control at all.

The introduction of safety belts took decades, and many people died because they did not understood what the safety belt did, and this feature will need a similar long breath and lots of love, but until that, until the bugs are fleshed out, and the implementation is limited to a and area elements in (X)HTML like the spec writes, without user feed back and proper pref UI, without doing the things good for the users...it should be switched off.

Comment 4

[Johnny Stenback (:jst)]

Is changing the preference really needed to build the UI here? And do we need the new state (nr 2 in Mike's list)? The less code we can take for this the better...

Comment 5

[Johnny Stenback (:jst)]

Beltzner, ping?

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I do agree we need UI for pings, but I don't think this bug is a blocker. The new state (2) sounds like something we could ship without.

Comment 7

[Boris Zbarsky [:bzbarsky]]

We should make sure we have a blocker bug on the ping UI, fwiw....

Comment 8

[Mike Beltzner [:beltzner, not reading bugmail]]

Sorry, was afbugmail for a day or two there (if that happens and you need me, please just find me on IRC or send mail - jonas has learned that before!)

I agree that this doesn't block, I filed the bug based on a dev-apps-firefox discussion and comments from bz. Marking wanted, though, as I think everyone agrees it would be a helpful RFE.

+1 to comments for UI on the ping setting ...

Comment 9

[Dave Townsend [:mossop]]

Filed bug 404238 for the UI

Comment 10

[[e-mail]]

(In reply to comment #0)
> Also, should we consider defining "same domain" as eTLD+1?

this would be consistent with the domain cookie concept, our (soon to be default) "foreign cookie" blocking operation, document.domain operation etc. i can help out with this part of the code if required.

Comment 11

[Tony Mechelynck [:tonymec]]

err... shouldn't this bug be Trunk/All/All rather than Unspecified/PC/Mac OS X ? (Can't change it myself)

Comment 12

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.