Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Intent to ship: Hyperlink Auditing (<a ping>)

511 views
Skip to first unread message

Tim Taubert

unread,
May 16, 2014, 5:29:19 AM5/16/14
to dev-pl...@lists.mozilla.org
*Link to Standard*
http://www.whatwg.org/specs/web-apps/current-work/#hyperlink-auditing

*Summary*
Anchor tags can have a "ping" attribute that sends asynchronous pings
after or while navigating to the target page for auditing purposes.

*Motivation*
Since bug 786347 landed our Hyperlink Auditing implementation follows
the spec but is disabled by default. If a website wants to audit
navigation to outgoing links (think Google, DuckDuckGo, Facebook, etc.)
it nowadays has to either link to an internal page to record and then
redirect to the target page or use sync XHRs. <a ping> allows to
asynchronously (and with low prio) send one or multiple pings after or
while we start loading the target page.

*Bug to enable by default*
https://bugzilla.mozilla.org/show_bug.cgi?id=951104

*Notes*
The navigator.sendBeacon() API is a superset of <a ping>. <a ping>
allows for lightweight navigation pings without having to use JavaScript.

The number of pings per link is currently limited to 1
(browser.send_pings.max_per_link). Chrome does not limit the number of
pings, we should look into raising or disabling the limit.


- Tim


--
Tim Taubert
Engineering Manager, Firefox
@ttaubert

Jonathan Kew

unread,
May 16, 2014, 6:09:31 AM5/16/14
to Tim Taubert, dev-pl...@lists.mozilla.org
On 16/5/14 10:29, Tim Taubert wrote:
> *Link to Standard*
> http://www.whatwg.org/specs/web-apps/current-work/#hyperlink-auditing

A couple of quotes from there:

"User agents should allow the user to adjust this behavior, for example
in conjunction with a setting that disables the sending of HTTP Referer
(sic) headers. Based on the user's preferences, UAs may either ignore
the ping attribute altogether, or selectively ignore URLs in the list
(e.g. ignoring any third-party URLs)."

"When the ping attribute is present, user agents should clearly indicate
to the user that following the hyperlink will also cause secondary
requests to be sent in the background, possibly including listing the
actual target URLs."

What's our story here? It's not obvious to me from a (brief) look at the
bugs whether we have addressed these issues. Without them, I find the
idea of <a ping> quite disturbing...

JK

Tim Taubert

unread,
May 16, 2014, 6:20:43 AM5/16/14
to Jonathan Kew, dev-pl...@lists.mozilla.org
Jonathan Kew wrote:
> "User agents should allow the user to adjust this behavior, for example
> in conjunction with a setting that disables the sending of HTTP Referer
> (sic) headers. Based on the user's preferences, UAs may either ignore
> the ping attribute altogether, or selectively ignore URLs in the list
> (e.g. ignoring any third-party URLs)."

Users can disable sendings pings by flipping a preference. They can
limit the number of pings sent per link. They can restrict pings to the
same host as the document in which the click occurs by flipping a pref.

> "When the ping attribute is present, user agents should clearly indicate
> to the user that following the hyperlink will also cause secondary
> requests to be sent in the background, possibly including listing the
> actual target URLs."

This is covered by bug 401352.

> What's our story here? It's not obvious to me from a (brief) look at the
> bugs whether we have addressed these issues. Without them, I find the
> idea of <a ping> quite disturbing...

We don't have a story here at the moment. Sites currently audit external
navigation by using redirects and sync XHRs which don't notify the user
either but at the same time make navigation a lot slower.

Calling the whole idea of <a ping> "disturbing" makes it sound like we
would introduce a whole new concept, we just provide a saner way to do
things that lots of web pages want. There is no obvious disadvantage to
the user from my POV here.

- Tim


>> *Summary*
>> Anchor tags can have a "ping" attribute that sends asynchronous pings
>> after or while navigating to the target page for auditing purposes.
>>
>> *Motivation*
>> Since bug 786347 landed our Hyperlink Auditing implementation follows
>> the spec but is disabled by default. If a website wants to audit
>> navigation to outgoing links (think Google, DuckDuckGo, Facebook, etc.)
>> it nowadays has to either link to an internal page to record and then
>> redirect to the target page or use sync XHRs. <a ping> allows to
>> asynchronously (and with low prio) send one or multiple pings after or
>> while we start loading the target page.
>>
>> *Bug to enable by default*
>> https://bugzilla.mozilla.org/show_bug.cgi?id=951104
>>
>> *Notes*
>> The navigator.sendBeacon() API is a superset of <a ping>. <a ping>
>> allows for lightweight navigation pings without having to use JavaScript.
>>
>> The number of pings per link is currently limited to 1
>> (browser.send_pings.max_per_link). Chrome does not limit the number of
>> pings, we should look into raising or disabling the limit.
>>
>>
>> - Tim
>>
>>
>

Anne van Kesteren

unread,
May 16, 2014, 7:44:14 AM5/16/14
to Tim Taubert, dev-pl...@lists.mozilla.org, Jonathan Kew
On Fri, May 16, 2014 at 12:20 PM, Tim Taubert <ttau...@mozilla.com> wrote:
> Calling the whole idea of <a ping> "disturbing" makes it sound like we
> would introduce a whole new concept, we just provide a saner way to do
> things that lots of web pages want. There is no obvious disadvantage to
> the user from my POV here.

It should be better as closing a document is no longer halted by
synchronous XMLHttpRequest. Are we implementing them in such a way
they can be transmitted even if the window goes away? So performance
for the user is optimal and developers don't feel forced to slow
things down?


--
http://annevankesteren.nl/

Jonathan Kew

unread,
May 16, 2014, 7:49:31 AM5/16/14
to Tim Taubert, dev-pl...@lists.mozilla.org
On 16/5/14 11:20, Tim Taubert wrote:
> Jonathan Kew wrote:
>> "User agents should allow the user to adjust this behavior, for example
>> in conjunction with a setting that disables the sending of HTTP Referer
>> (sic) headers. Based on the user's preferences, UAs may either ignore
>> the ping attribute altogether, or selectively ignore URLs in the list
>> (e.g. ignoring any third-party URLs)."
>
> Users can disable sendings pings by flipping a preference. They can
> limit the number of pings sent per link. They can restrict pings to the
> same host as the document in which the click occurs by flipping a pref.
>
>> "When the ping attribute is present, user agents should clearly indicate
>> to the user that following the hyperlink will also cause secondary
>> requests to be sent in the background, possibly including listing the
>> actual target URLs."
>
> This is covered by bug 401352.

...which has seen no apparent activity since it was filed, over 6 years
ago. :(

>
>> What's our story here? It's not obvious to me from a (brief) look at the
>> bugs whether we have addressed these issues. Without them, I find the
>> idea of <a ping> quite disturbing...
>
> We don't have a story here at the moment. Sites currently audit external
> navigation by using redirects and sync XHRs which don't notify the user
> either but at the same time make navigation a lot slower.
>
> Calling the whole idea of <a ping> "disturbing" makes it sound like we
> would introduce a whole new concept, we just provide a saner way to do
> things that lots of web pages want. There is no obvious disadvantage to
> the user from my POV here.
>

When I click a Google search result (for example), I can see -- thanks
to the status overlay that shows the URLs being requested -- that it's
redirecting me via a Google URL that is presumably being used to track
me. So although this is hardly an optimal UI, at least I get a clue that
the site is doing something more than simply giving me a link that I
follow, and if I want to avoid telling Google which results I'm
clicking, I need to somehow work around this.

If this is replaced by the use of <a ping> on those search results, then
(AFAICT) there will no longer be *any* clue to alert me as a user to the
fact that the site is monitoring which result I click on. This allows
pages to more easily track me without ever bringing it to my attention.
So I do think there's a disadvantage here.

JK

Tim Taubert

unread,
May 16, 2014, 7:53:41 AM5/16/14
to Anne van Kesteren, dev-pl...@lists.mozilla.org, Jonathan Kew
Anne van Kesteren wrote:
> On Fri, May 16, 2014 at 12:20 PM, Tim Taubert <ttau...@mozilla.com> wrote:
>> Calling the whole idea of <a ping> "disturbing" makes it sound like we
>> would introduce a whole new concept, we just provide a saner way to do
>> things that lots of web pages want. There is no obvious disadvantage to
>> the user from my POV here.
>
> It should be better as closing a document is no longer halted by
> synchronous XMLHttpRequest. Are we implementing them in such a way
> they can be transmitted even if the window goes away? So performance
> for the user is optimal and developers don't feel forced to slow
> things down?

Yes, <a ping> is implemented only to ping when the user clicks a link
and navigates away from the current document. Thus transmitting the ping
when the inner window goes away is a requirement. The outer window going
away isn't a problem either because we create independent http
channels/requests that will be held alive by the networking subsystem
until they succeed or time out.

Anne van Kesteren

unread,
May 16, 2014, 8:00:30 AM5/16/14
to Jonathan Kew, dev-pl...@lists.mozilla.org, Tim Taubert
On Fri, May 16, 2014 at 1:49 PM, Jonathan Kew <jfkt...@gmail.com> wrote:
> When I click a Google search result (for example), I can see -- thanks to
> the status overlay that shows the URLs being requested -- that it's
> redirecting me via a Google URL that is presumably being used to track me.
> So although this is hardly an optimal UI, at least I get a clue that the
> site is doing something more than simply giving me a link that I follow, and
> if I want to avoid telling Google which results I'm clicking, I need to
> somehow work around this.
>
> If this is replaced by the use of <a ping> on those search results, then
> (AFAICT) there will no longer be *any* clue to alert me as a user to the
> fact that the site is monitoring which result I click on. This allows pages
> to more easily track me without ever bringing it to my attention. So I do
> think there's a disadvantage here.

I suspect that most end users do not realize this and probably wonder
more why things are slower in Firefox (assuming that browsers that
ping get to the target page directly). There's also nothing preventing
us from exposing the ping attribute in some way, though probably
extensions need to lead the way there.


--
http://annevankesteren.nl/

L. David Baron

unread,
May 16, 2014, 8:02:06 AM5/16/14
to Jonathan Kew, dev-pl...@lists.mozilla.org, Tim Taubert
On Friday 2014-05-16 12:49 +0100, Jonathan Kew wrote:
> When I click a Google search result (for example), I can see --
> thanks to the status overlay that shows the URLs being requested --
> that it's redirecting me via a Google URL that is presumably being
> used to track me.

You actually don't, since Google doesn't add the tracking stuff to
the link until you click it. But it adds it early enough in click
handling so that it affects what happens when you click the link.

To see this:
1. search for something on Google
2. hover over the link in a result; you see a normal link
3. right-click to get the link's context menu
4. hover over the link again

In step (2) you see the link on its own; in step (4) you see the
version with the tracking redirect added.

-David

--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla https://www.mozilla.org/ 𝄂
Before I built a wall I'd ask to know
What I was walling in or walling out,
And to whom I was like to give offense.
- Robert Frost, Mending Wall (1914)
signature.asc

Tim Taubert

unread,
May 16, 2014, 8:02:22 AM5/16/14
to Jonathan Kew, dev-pl...@lists.mozilla.org
Jonathan Kew wrote:
> When I click a Google search result (for example), I can see -- thanks
> to the status overlay that shows the URLs being requested -- that it's
> redirecting me via a Google URL that is presumably being used to track
> me. So although this is hardly an optimal UI, at least I get a clue that
> the site is doing something more than simply giving me a link that I
> follow, and if I want to avoid telling Google which results I'm
> clicking, I need to somehow work around this.

Google and DuckDuckGo are hiding these, when hovering a search result
link I don't see that the browser will request a different page first
and redirect me afterwards. I think for the average user this is hardly
different from not seeing any hint at all.

> If this is replaced by the use of <a ping> on those search results, then
> (AFAICT) there will no longer be *any* clue to alert me as a user to the
> fact that the site is monitoring which result I click on. This allows
> pages to more easily track me without ever bringing it to my attention.
> So I do think there's a disadvantage here.

The argument "we make it easier to track" seems valid at first but we
can't even prevent that right now. If sites want to and will do that
anyway we should at least provide a way that has less disadvantages for
the user.

Jonathan Kew

unread,
May 16, 2014, 8:35:48 AM5/16/14
to L. David Baron, dev-pl...@lists.mozilla.org, Tim Taubert
On 16/5/14 13:02, L. David Baron wrote:
> On Friday 2014-05-16 12:49 +0100, Jonathan Kew wrote:
>> When I click a Google search result (for example), I can see --
>> thanks to the status overlay that shows the URLs being requested --
>> that it's redirecting me via a Google URL that is presumably being
>> used to track me.
>
> You actually don't, since Google doesn't add the tracking stuff to
> the link until you click it. But it adds it early enough in click
> handling so that it affects what happens when you click the link.
>
> To see this:
> 1. search for something on Google
> 2. hover over the link in a result; you see a normal link
> 3. right-click to get the link's context menu
> 4. hover over the link again
>
> In step (2) you see the link on its own; in step (4) you see the
> version with the tracking redirect added.

Yes; but even if I simply click the link at step (2), I see (via the
status overlay) that it actually sends me via a Google tracking URL
instead of directly to the destination. I remember noticing (and
disapproving) when this behavior was first introduced to their search
results.

At that point, of course, it's too late to decide I didn't want Google
to know that I clicked that link -- but in the process, I've learned
something: that Google search results are not simply links for my
browser to follow, but "booby-traps" that will report back to Google
before taking me to the target page. And if I don't like that, I might
decide to look for a different search engine, or to be more careful what
I do with results in future.

Replacing the redirects with <a ping> will completely hide this from me;
in that case, I might never have noticed that clicking those links was
anything more than a simple "go to this page".

Maybe that's OK, but I do think this changes things in a significant
way, and we should give some priority to addressing the concerns. Maybe
the send-ping preference should be exposed at a similar level to Do Not
Track?

For comparison, I really like the fact that when an email comes with
return receipt request, Thunderbird will ask me something like "the
sender asked to be notified when you open this message..." and let me
choose whether or not to respond. While I guess <a ping> will probably
become so widespread that I wouldn't want to be prompted every time
("Google asked to be notified when you click this link..."), some kind
of user notification and UI to opt in/out of tracking does seem needed here.

JK

L. David Baron

unread,
May 16, 2014, 8:49:36 AM5/16/14
to Jonathan Kew, dev-pl...@lists.mozilla.org, Tim Taubert
On Friday 2014-05-16 13:35 +0100, Jonathan Kew wrote:
> Maybe that's OK, but I do think this changes things in a significant
> way, and we should give some priority to addressing the concerns.
> Maybe the send-ping preference should be exposed at a similar level
> to Do Not Track?

There's a tradeoff there, though. If enough users opt out of the
preference for sites to care, then sites will just use other ways to
track users that aren't controlled by the preference.

(And sites could certainly use other ways that don't show up in the
"Loading..." message in the status bar as well; some of these would
probably also be faster than redirects.)

We need to be careful to design the preferences we expose to the
user in ways that make sense even if sites don't want to honor those
preferences. It's not clear to me that it makes sense to have a
preference to disable one particular tracking feature when sites can
do that sort of tracking in many other ways that aren't controlled
by the preference.
signature.asc

Wesley Hardman

unread,
May 16, 2014, 8:58:19 AM5/16/14
to
I just use "Remove Google Redirection" for Greasemonkey, so I don't have the redirects.

Can you detect if <a ping> is enabled? If so, having a preference isn't going to be particularly useful as sites will just fallback to the redirect method. If it is added as a UI preference, it needs to be silent, or else the preference is really "track via pings, or track via slower redirect".

Tim Taubert

unread,
May 16, 2014, 9:11:41 AM5/16/14
to L. David Baron, dev-pl...@lists.mozilla.org, Jonathan Kew
L. David Baron wrote:
> We need to be careful to design the preferences we expose to the
> user in ways that make sense even if sites don't want to honor those
> preferences. It's not clear to me that it makes sense to have a
> preference to disable one particular tracking feature when sites can
> do that sort of tracking in many other ways that aren't controlled
> by the preference.

That's a great point. I think it really might make sense to remove the
preferences altogether as the number of pings per link limit and the
same hosts requirement can actually be worked around quite easily and
would make websites just fall back to the same bad behavior that we
currently have. Ensuring this feature works as expected would surely
drive adoption a lot better.

- Tim

Curtis Koenig

unread,
May 16, 2014, 9:30:58 AM5/16/14
to Tim Taubert, L. David Baron, dev-pl...@lists.mozilla.org, Jonathan Kew

On 16 May, 2014, at 09:11 AM, Tim Taubert <ttau...@mozilla.com> wrote:

> I think it really might make sense to remove the
> preferences altogether


Given our stance on privacy[1] and commitment to Real Choices, Sensible Settings and User Control; I don’t believe removing the users ability to control this preference would be a positive move. David’s point is more correct in that we need to be careful as to how the preference is exposed. We could also do something very innovative in this case like what is done with do not track. We could default to allowing all requests (which would honor the spec) but allow the users to change the pref to 2 other states. One being only allow pings from the sites I specify and the final one being don’t allow any at all. With accompanying text that explains the tradeoffs/benefits/pain of each setting. This would help us both keep inline with the goal of Hyperlink Auditing and balance our stance on privacy.

[1] https://wiki.mozilla.org/Privacy/Principles
--
Curtis

Kyle Huey

unread,
May 16, 2014, 9:37:26 AM5/16/14
to Curtis Koenig, L. David Baron, dev-platform, Tim Taubert, Jonathan Kew
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

The point being made is that the preference is not a real choice. If
you disable this feature you can still be tracked in the exact same
way by methods that exist today and are not covered by the preference.

- Kyle

Curtis Koenig

unread,
May 16, 2014, 9:38:02 AM5/16/14
to Tim Taubert, dev-pl...@lists.mozilla.org
Would this be disabled in Private Browsing? If not that might be perceived as negating one of the reasons users have for using that particular feature.

On 16 May, 2014, at 05:29 AM, Tim Taubert <ttau...@mozilla.com> wrote:

> *Link to Standard*
> http://www.whatwg.org/specs/web-apps/current-work/#hyperlink-auditing
>
> *Summary*
> Anchor tags can have a "ping" attribute that sends asynchronous pings
> after or while navigating to the target page for auditing purposes.
>
> *Motivation*
> Since bug 786347 landed our Hyperlink Auditing implementation follows
> the spec but is disabled by default. If a website wants to audit
> navigation to outgoing links (think Google, DuckDuckGo, Facebook, etc.)
> it nowadays has to either link to an internal page to record and then
> redirect to the target page or use sync XHRs. <a ping> allows to
> asynchronously (and with low prio) send one or multiple pings after or
> while we start loading the target page.
>
> *Bug to enable by default*
> https://bugzilla.mozilla.org/show_bug.cgi?id=951104
>
> *Notes*
> The navigator.sendBeacon() API is a superset of <a ping>. <a ping>
> allows for lightweight navigation pings without having to use JavaScript.
>
> The number of pings per link is currently limited to 1
> (browser.send_pings.max_per_link). Chrome does not limit the number of
> pings, we should look into raising or disabling the limit.
>
>
> - Tim
>
>
> --
> Tim Taubert
> Engineering Manager, Firefox
> @ttaubert
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

--
Curtis Koenig
Mozilla Corp.
Security Program Manager

Tim Taubert

unread,
May 16, 2014, 9:38:15 AM5/16/14
to Curtis Koenig, L. David Baron, dev-pl...@lists.mozilla.org, Jonathan Kew
Curtis Koenig wrote:
> Given our stance on privacy[1] and commitment to Real Choices, Sensible Settings and User Control; I don�t believe removing the users ability to control this preference would be a positive move. David�s point is more correct in that we need to be careful as to how the preference is exposed. We could also do something very innovative in this case like what is done with do not track. We could default to allowing all requests (which would honor the spec) but allow the users to change the pref to 2 other states. One being only allow pings from the sites I specify and the final one being don�t allow any at all. With accompanying text that explains the tradeoffs/benefits/pain of each setting. This would help us both keep inline with the goal of Hyperlink Auditing and balance our stance on privacy.

I am all for "real choice" and keeping the user in control but offering
these preferences does nothing but pretend to protect users and their
privacy. If there is a chance the user might have turned it off without
the site noticing then websites will just keep on doing what they do
currently. Without any chance for the user to intervene or limit, and
without a way to notice this is happening. And with all the current
performance impacts.

- Tim

Tim Taubert

unread,
May 16, 2014, 9:39:38 AM5/16/14
to Curtis Koenig, dev-pl...@lists.mozilla.org
Curtis Koenig wrote:
> Would this be disabled in Private Browsing? If not that might be perceived as negating one of the reasons users have for using that particular feature.

Are sync XHRs and HTTP redirects disabled in private browsing? :)

- Tim

Curtis Koenig

unread,
May 16, 2014, 9:40:06 AM5/16/14
to Kyle Huey, L. David Baron, dev-platform, Tim Taubert, Jonathan Kew

On 16 May, 2014, at 09:37 AM, Kyle Huey <m...@kylehuey.com> wrote:

> The point being made is that the preference is not a real choice. If
> you disable this feature you can still be tracked in the exact same
> way by methods that exist today and are not covered by the preference.

True, but those methods are being done outside of a browser feature we have control over. In this case given that we can implement and control this particular feature behavior we should try to implement it in a way that aligns with our projects values.
--
Curtis

Curtis Koenig

unread,
May 16, 2014, 9:44:49 AM5/16/14
to Tim Taubert, dev-pl...@lists.mozilla.org
Assuming I am understanding this correctly, it appears from this doc https://developer.mozilla.org/en-US/docs/Supporting_per-window_private_browsing that they maybe disabled in some instances of private browsing given changes in Fx 20.

> Forcing a channel into private mode
>
> Usually, network channels inherit the privacy status of the document that created them, which means that they work correctly most of the time. However, sometimes you need to adjust the privacy status on a channel manually, for example, if you have created the channel directly yourself. You can use the nsIPrivateBrowsingChannel interface for this purpose. The example below creates a channel to load a URL, and forces it to be in private mode.
>
> var channel = Services.io.newChannel("http://example.org", null, null);
>
> channel
> .QueryInterface(Components.interfaces.nsIPrivateBrowsingChannel);
>
> channel
> .setPrivate(true); // force the channel to be loaded in private mode
> Similarly, XMLHttpRequest objects created via createInstance(Ci.nsIXMLHttpRequest) will often require explicit adjustment, since they have no context from which to derive a privacy status.
>
> var xhr = Components.classes["@mozilla.org/xmlextras/xmlhttprequest;1"].createInstance(Components.interfaces.nsIXMLHttpReqeust);
> var channel = xhr.channel.QueryInterface(Components.interfaces.nsIPrivateBrowsingChannel);
>
> channel
> .setPrivate(true);
--
Curtis

Anne van Kesteren

unread,
May 16, 2014, 9:49:33 AM5/16/14
to Curtis Koenig, L. David Baron, Kyle Huey, dev-platform, Tim Taubert, Jonathan Kew
Yes, but that might lead to non-use, which leads to worse performance
for our users due to alternate methods deployed (and less obvious
introspection of data flows through e.g. extensions).


--
http://annevankesteren.nl/

Tim Taubert

unread,
May 16, 2014, 9:49:18 AM5/16/14
to Curtis Koenig, dev-pl...@lists.mozilla.org
Curtis Koenig wrote:
> Assuming I am understanding this correctly, it appears from this doc https://developer.mozilla.org/en-US/docs/Supporting_per-window_private_browsing that they maybe disabled in some instances of private browsing given changes in Fx 20.

The only thing I can see here is that I can force single
requests/channels into private mode, which means they won't persist
cookies, sessionStorage, cache entries, etc. All other means of tracking
navigation by rewriting links before clicking and then redirecting, or
firing a sync XHR do still work and probably can't be disabled because
they would break the web.

- Tim

Jonathan Kew

unread,
May 16, 2014, 9:59:14 AM5/16/14
to Kyle Huey, Curtis Koenig, L. David Baron, dev-platform, Tim Taubert
On 16/5/14 14:37, Kyle Huey wrote:
> On Fri, May 16, 2014 at 6:30 AM, Curtis Koenig <cur...@mozilla.com> wrote:
>>
>> On 16 May, 2014, at 09:11 AM, Tim Taubert <ttau...@mozilla.com> wrote:
>>
>>> I think it really might make sense to remove the
>>> preferences altogether
>>
>>
>> Given our stance on privacy[1] and commitment to Real Choices, Sensible Settings and User Control; I don’t believe removing the users ability to control this preference would be a positive move. David’s point is more correct in that we need to be careful as to how the preference is exposed. We could also do something very innovative in this case like what is done with do not track. We could default to allowing all requests (which would honor the spec) but allow the users to change the pref to 2 other states. One being only allow pings from the sites I specify and the final one being don’t allow any at all. With accompanying text that explains the tradeoffs/benefits/pain of each setting. This would help us both keep inline with the goal of Hyperlink Auditing and balance our stance on privacy.
>>
>> [1] https://wiki.mozilla.org/Privacy/Principles
>> --
>> Curtis
>>
>> _______________________________________________
>> dev-platform mailing list
>> dev-pl...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>
> The point being made is that the preference is not a real choice. If
> you disable this feature you can still be tracked in the exact same
> way by methods that exist today and are not covered by the preference.
>

Yes; but the methods being used by at (least some major) sites are
visible to the user, which makes them less insidious than an
invisible-by-design tracking feature.

If we implement <a ping>, and make it on-by-default (but with a user
preference to turn it off), we can reasonably expect sites to use this
as their tracking method in place of redirects, etc. And if they hten
detect (can they?) that the user has turned off pings and fall back to
other methods to track the user - who by disabling it has expressed a
desire not to be tracked - this puts them in much the same category as
those who decide to stop honoring Do Not Track.

We can't force sites to honor DNT, and we can't prevent them working
around user-disabled <a ping>. But in both cases we can and should (IMO)
provide a simple means for the user to express a wish about tracking.
Respectable sites will interoperate nicely with it; those that decide to
circumvent it should be publicly shamed.

JK

Tim Taubert

unread,
May 16, 2014, 10:39:07 AM5/16/14
to Jonathan Kew, L. David Baron, Kyle Huey, Curtis Koenig, dev-platform
Jonathan Kew wrote:
> On 16/5/14 14:37, Kyle Huey wrote:
>> On Fri, May 16, 2014 at 6:30 AM, Curtis Koenig <cur...@mozilla.com>
>> The point being made is that the preference is not a real choice. If
>> you disable this feature you can still be tracked in the exact same
>> way by methods that exist today and are not covered by the preference.
>
> Yes; but the methods being used by at (least some major) sites are
> visible to the user, which makes them less insidious than an
> invisible-by-design tracking feature.

I doubt that the common user will notice any of these tracking measures.
Even I wouldn't notice if I don't pay attention or the network would not
sometimes be slow to load.

> If we implement <a ping>, and make it on-by-default (but with a user
> preference to turn it off), we can reasonably expect sites to use this
> as their tracking method in place of redirects, etc. And if they hten
> detect (can they?) that the user has turned off pings and fall back to
> other methods to track the user - who by disabling it has expressed a
> desire not to be tracked - this puts them in much the same category as
> those who decide to stop honoring Do Not Track.

Web pages can't detect whether pings are actually sent, they know when
those arrive at their endpoints. Thus if a website is concerned about
Firefox users having turned this feature off they might just keep it the
way it currently is and thus be sure it works for every user.

> We can't force sites to honor DNT, and we can't prevent them working
> around user-disabled <a ping>. But in both cases we can and should (IMO)
> provide a simple means for the user to express a wish about tracking.
> Respectable sites will interoperate nicely with it; those that decide to
> circumvent it should be publicly shamed.

Using DNT is a flawed comparison, DNT is very much only about letting
websites know without the ability to prevent any of that tracking.
Websites can't tell whether <a ping> is enabled and thus there is no
real point in shaming any of them when we can't even prove they're not
using <a ping> because some users might have turned it off.

- Tim

Justin Dolske

unread,
May 16, 2014, 10:45:22 AM5/16/14
to
On 5/16/14, 6:38 AM, Curtis Koenig wrote:
> Would this be disabled in Private Browsing? If not that might be
> perceived as negating one of the reasons users have for using that
> particular feature.

Private Browsing mode is about not storing _local_ data from your
activities. It is explicitly not an "anti tracking" mode because that's
extremely difficult-to-impossible to do robustly just on the client, and
would be a misleading claim and/or result in a browser most people would
think is broken. E.G. as already noted in this thread, sites can already
do this without <a ping>.

Justin

L. David Baron

unread,
May 16, 2014, 5:54:11 PM5/16/14
to Wesley Hardman, dev-pl...@lists.mozilla.org
On Friday 2014-05-16 08:58 -0400, Wesley Hardman wrote:
> Can you detect if <a ping> is enabled? If so, having a preference isn't going to be particularly useful as sites will just fallback to the redirect method. If it is added as a UI preference, it needs to be silent, or else the preference is really "track via pings, or track via slower redirect".

Sites can certainly tell if it's enabled with the help of a server
(which those using it would have anyway); they can try it once, and
if they get the ping, set a cookie. (And then they might use the
faster ping method rather than the redirect only if the cookie is
set.)
signature.asc

L. David Baron

unread,
May 16, 2014, 6:06:31 PM5/16/14
to Curtis Koenig, Kyle Huey, dev-platform, Tim Taubert, Jonathan Kew
On Friday 2014-05-16 09:40 -0400, Curtis Koenig wrote:
> On 16 May, 2014, at 09:37 AM, Kyle Huey <m...@kylehuey.com> wrote:
> > The point being made is that the preference is not a real choice. If
> > you disable this feature you can still be tracked in the exact same
> > way by methods that exist today and are not covered by the preference.
>
> True, but those methods are being done outside of a browser feature we have control over. In this case given that we can implement and control this particular feature behavior we should try to implement it in a way that aligns with our projects values.

No, I don't think we can implement control over "this particular
feature behavior", since for the user to actually have control, the
description of the preference needs to be understandable and then
actually do what it says.

We can control one technical underpinning of tracking which links a
user follows, but we can't control all of them. This means that any
preference for this that we expose to users would either have to be
described in technical jargon that's not meaningful to most users,
would have to either be untruthful or unclear about what effects it
has. Compare this to the preference for DNT, which says "Tell sites
that I do not want to be tracked". [1] That's understandable, but
also makes it clear that it's not preventing tracking but telling
the other end about a preference.

Supporting user control should mean that the choices we expose to
users actually control useful and understandable things.

-David

[1] Speaking of DNT -- if it's all just the honor system for
honoring this preference anyway -- why shouldn't it just be
based on the DNT header anyway? We send the DNT header in the
network request for the ping, right?
signature.asc

Robert O'Callahan

unread,
May 16, 2014, 8:15:35 PM5/16/14
to L. David Baron, Kyle Huey, Curtis Koenig, dev-platform, Tim Taubert, Jonathan Kew
Seems to me we should indicate pings in the link status text (bug 401352),
indicate pinging in the status text while we load the next page, and retain
the about:config pref to disable pinging.

The first two measures seem low-cost and constitute a strict improvement on
the current privacy situation, making it somewhat clearer to the user
what's going on. The text will still be difficult to understand but less
obscure than the Google-vomit URLs you see now.

Leaving the about:config pref in means that extensions can disable pings
but probably not enough to drive people away from using the feature.

Rob
--
Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa
stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr,
'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp
waanndt wyeonut thoo mken.o w

Gavin Sharp

unread,
May 17, 2014, 1:07:44 PM5/17/14
to Jonathan Kew, L. David Baron, dev-platform, Tim Taubert
On Fri, May 16, 2014 at 5:35 AM, Jonathan Kew <jfkt...@gmail.com> wrote:
>> You actually don't, since Google doesn't add the tracking stuff to
>> the link until you click it. But it adds it early enough in click
>> handling so that it affects what happens when you click the link.

> Yes; but even if I simply click the link at step (2), I see (via the status
> overlay) that it actually sends me via a Google tracking URL instead of
> directly to the destination. I remember noticing (and disapproving) when
> this behavior was first introduced to their search results.

When you say "see via the status overlay", are you referring to the
instant between the mousedown and mouseup? That's the only time I see
the "real destination" in the status overlay when clicking links on
google.com. I suppose if the latency to Google servers is high or your
connection is slower, the hostname/destination might also appear there
as the "real destination" loads. I doubt most users notice this; it's
effectively invisible. If we ship <a ping> and Google starts using it,
users who don't care will not perceive any differences (except perhaps
faster pageload), and the minority who do care (like you) will be able
to much more easily be made aware of the behavior (e.g. by installing
an extension that reveals ping destinations visibly and consistently,
without needing to reverse engineer Google's custom link-tracking
implementation). Sounds like a win-win to me.

(There's a separate question about whether we want to make it a goal
to move users from the "don't care" bucket to the "do care" bucket, by
improving the visibility in Firefox proper in an attempt to make them
aware of link-tracking. It's a trickier one that's worth exploring,
but for "user education" to be effective its benefits need to outweigh
the annoyances.)

Gavin

Gavin Sharp

unread,
May 17, 2014, 1:20:45 PM5/17/14
to Robert O'Callahan, dev-platform
On Fri, May 16, 2014 at 5:15 PM, Robert O'Callahan <rob...@ocallahan.org> wrote:
> Seems to me we should indicate pings in the link status text (bug 401352),
> indicate pinging in the status text while we load the next page, and retain
> the about:config pref to disable pinging.

> The first two measures seem low-cost and constitute a strict improvement on
> the current privacy situation, making it somewhat clearer to the user
> what's going on. The text will still be difficult to understand but less
> obscure than the Google-vomit URLs you see now.

The potential costs to the first two include:
- making it confusing which link you would be navigating to. It can
be tricky to differentiate "you will go to X" and "your browser will
ping Y". Exposing them both at the same time in limited link-overlay
space is also hard, particularly since there can be multiple ping
URLs.
- making it confusing which page is currently loading vs. being
pinged. Our existing page loading status indicators are kind of a
mess, simplifying them is a goal. This would complicate them.

As Anne suggests, this is an area ripe for experimentation from
add-ons. I would like to explore this problem more, but I don't think
it's a blocker for shipping <a ping>.

> Leaving the about:config pref in means that extensions can disable pings
> but probably not enough to drive people away from using the feature.

I agree, this seems reasonable.

Gavin

Steve Fink

unread,
May 20, 2014, 12:37:22 PM5/20/14
to dev-pl...@lists.mozilla.org
When you're shopping for an engagement ring, why would you want to
prevent the jewelry vendor from knowing that you're shopping, or from
knowing who you are?

Mike Hoye

unread,
May 20, 2014, 1:20:56 PM5/20/14
to dev-pl...@lists.mozilla.org
On 2014-05-20, 12:37 PM, Steve Fink wrote:
> On Fri 16 May 2014 07:45:22 AM PDT, Justin Dolske wrote:
>> Private Browsing mode is about not storing _local_ data from your
>> activities. It is explicitly not an "anti tracking" mode because
>> that's extremely difficult-to-impossible to do robustly just on the
>> client, and would be a misleading claim and/or result in a browser
>> most people would think is broken. E.G. as already noted in this
>> thread, sites can already do this without <a ping>.
> When you're shopping for an engagement ring, why would you want to
> prevent the jewelry vendor from knowing that you're shopping, or from
> knowing who you are?
Because being able to more uniquely identify you makes it easier to game
you. You should always be in private browsing mode when you're shopping
for airplane tickets, for example.

- mhoye






Ehsan Akhgari

unread,
May 20, 2014, 5:24:37 PM5/20/14
to Tim Taubert, Curtis Koenig, dev-pl...@lists.mozilla.org
On 2014-05-16, 9:39 AM, Tim Taubert wrote:
> Curtis Koenig wrote:
>> Would this be disabled in Private Browsing? If not that might be perceived as negating one of the reasons users have for using that particular feature.
>
> Are sync XHRs and HTTP redirects disabled in private browsing? :)

They are not. Private Browsing is explicitly not about network level
privacy and we should definitely not disable <a ping> in private windows
in any way, since we cannot do anything to prevent websites from
tracking the user in private browsing if they choose to do so.

Cheers,
Ehsan

Jonas Sicking

unread,
May 20, 2014, 6:43:27 PM5/20/14
to Ehsan Akhgari, dev-platform, Justin Dolske
On Tue, May 20, 2014 at 2:33 PM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
>> But I believe that that would be a pretty crappy private browsing
>> feature which I don't think anyone here would argue for.
>>
>> Private browsing is mainly about giving you a new, throw-away,
>> identity. The throw-away part is why we don't allow storing data. The
>> reason we have a separate cookie jar is in order to implement the
>> "new" part.
>
> That was actually an unintended use case which was enabled as a side-effect
> of the cookie jar separation. We never really designed PB for this.

Whatever the reason we did this originally was, I believe that we
would have had a mostly useless private-browsing feature if we had not
created a new blank cookie-jar for private browsing.

I really do believe that private browsing must create a "new,
throw-away" profile. Anything else will be mostly useless to users.
They don't care if google didn't technically create any new cookies,
if "wedding ring" shows up in the user's search history due to a
search done in private browsing, they will be very disappointed.

/ Jonas

Ehsan Akhgari

unread,
May 20, 2014, 8:20:11 PM5/20/14
to Jonas Sicking, dev-platform, Justin Dolske
On 2014-05-20, 6:43 PM, Jonas Sicking wrote:
> On Tue, May 20, 2014 at 2:33 PM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
>>> But I believe that that would be a pretty crappy private browsing
>>> feature which I don't think anyone here would argue for.
>>>
>>> Private browsing is mainly about giving you a new, throw-away,
>>> identity. The throw-away part is why we don't allow storing data. The
>>> reason we have a separate cookie jar is in order to implement the
>>> "new" part.
>>
>> That was actually an unintended use case which was enabled as a side-effect
>> of the cookie jar separation. We never really designed PB for this.
>
> Whatever the reason we did this originally was, I believe that we
> would have had a mostly useless private-browsing feature if we had not
> created a new blank cookie-jar for private browsing.
>
> I really do believe that private browsing must create a "new,
> throw-away" profile. Anything else will be mostly useless to users.

We're diverging from the topic of this thread, but to me, that's an
implementation detail as long as we ensure that the users' activity in
PB mode doesn't "leak" into their normal session.

> They don't care if google didn't technically create any new cookies,
> if "wedding ring" shows up in the user's search history due to a
> search done in private browsing, they will be very disappointed.

That's true, and it's the reason why we made this choice for handling
cookies. As long as we ensure that the channel opened to deliver the
ping from <a ping> inherits the correct privacy settings, it should work
fine with the rest of the stack, ensuring that your non-private cookies
are not sent alongside the ping, the ping doesn't get cached to disk, etc.

Cheers,
Ehsan

Frederik Braun

unread,
May 21, 2014, 4:38:10 AM5/21/14
to Ehsan Akhgari, Jonas Sicking, Justin Dolske, dev-platform
On 20.05.2014 23:33, Ehsan Akhgari wrote:
> On 2014-05-20, 2:25 PM, Jonas Sicking wrote:
>> On Fri, May 16, 2014 at 7:45 AM, Justin Dolske <dol...@mozilla.com>
>> wrote:

>> However we do implement some additional features in private browsing
>> mode. For example we disable link coloring. I'm not sure what the
>> exact goal of that is. I always guessed that it is to enable you to be
>> extra private about your identity while in private browsing. So that
>> might provide an argument for disabling <a ping> in private browsing.
>
> The goal of disabling link coloring was IIRC to disable websites from
> being able to run attacks against your browsing history to be able to
> correlate your browsing sessions like I said above. A smaller reason
> was that because we don't store history items from private navigations,
> the link coloring might "not work" in surprising ways to the user. This
> was before dbaron's general fix for that issue, I don't actually think
> we need to keep doing that any more, but nobody has complained about
> that yet. :-)

FWIW I'd like to keep colored links out of private browsing, which is a
"guest mode" benefit: Somebody else using a private browsing window on
your computer can't immediately see which websites you visit.

(I know private browsing isn't intended to be a guest mode)

Ehsan Akhgari

unread,
May 21, 2014, 9:53:30 AM5/21/14
to Frederik Braun, Jonas Sicking, Justin Dolske, dev-platform
Sure they can. Cmd+Shift+H is right at their fingertips in private
windows, among tons of other UI we have for exposing history.

> (I know private browsing isn't intended to be a guest mode)

Yeah, PB is many things to many different people for the better or
worse. :-) That being said, I'm not planning to change the link
coloring behavior for now, and if someone writes a patch, I'll need to
think more before deciding whether or not to take it!

Cheers,
Ehsan

0 new messages