"ping" attribute UI
Boris Zbarsky
attribute. In particular, a user is not told that following the link will
notify a third party.
Quite apart from this being a SHOULD-level requirement in the spec, it seems
like we're being somewhat dishonest with users by not telling them this...
As I see it, the options are:
1) Develop some UI in Firefox for this
2) Develop some UI (or UI hooks) in Gecko for this
3) Remove "ping" support (or disable it by default)
4) Do nothing and leave things as they are
To be honest, I like option 4 the least. The idea of this attribute is that it
makes it easy for website authors to do something they can do anyway (track
users) in return for the users knowing when they're being tracked. But if we
don't give the user that information, it seems to me that the situation is worse
than if the user doesn't know he's being tracked but the site at least has to
put in some work to do it.
We initially enabled ping in the alphas as a test, but before we ship 1.9 we
should make a final decision on whether we're supporting it, and if so what UI
we want to have for it. Around now is as late as we want to go with that
decision, imo.
-Boris
Mike Beltzner
> It seems that Firefox doesn't have any UI to indicate links that
> have a "ping"
> attribute. In particular, a user is not told that following the
> link will
> notify a third party.
Thanks for bringing this up, Boris. A couple of questions come to mind
here, which I think will help us decide what the best thing to do is
for <a ping> links in Firefox 3.
First, what was the purpose of <a ping>? As you point out, webmasters
have long been able to do things *like* <a ping>, and the goal of the
spec was to simplify and standardize the behaviour. As I understand
things, this would allow users to opt-in/out of the behaviour, and
would allow webmasters to more easily add usage metric tracking to
their website. I don't think anyone expected malicious third-party
notifications to shift over to <a ping>, but maybe I'm wrong?
Second, does <a ping> actually differentiate between "third parties"
and "any party"? By that I mean, do we think a <a ping> notification
from www.foo.com to somewhere.foo.com is any more or less kosher than
one from www.foo.com to somewhere.else.com? It strikes me that if I'm
on beltzner.ca, and the notification ping goes to beltzner.ca, it's
pretty different than if I'm on beltzner.ca and the notification ping
goes to adsense.com.
Third, do we expect that telling a user that clicking link will result
in a notification ping is useful information for them to have? Can
that user take any action (or inaction) due to that information? My
feeling is that we'd probably want to add UI that allows users to turn
these types of notifications off, not UI that notifies the user that
they're being sent.
> Quite apart from this being a SHOULD-level requirement in the spec,
> it seems
> like we're being somewhat dishonest with users by not telling them
> this...
>
> As I see it, the options are:
>
> 1) Develop some UI in Firefox for this
Based on my above discussion, I'm ready to make some recommendations:
- do NOT add indications to the status bar, since it might give
users a false sense of security when they are, in fact, being tracked
by mechanisms that aren't <a ping>
- add UI that allows users to enable/disable tracking by <a ping>
(need to be careful here, again, to not provide a false sense of
security)
> 2) Develop some UI (or UI hooks) in Gecko for this
I think we should definitely do this, since I bet extension authors
will have some other ideas of how to expose the information for the
Very Privacy Sensitive. I also think we should modify
browser.send_pings to support three different levels:
0: disable
1: send pings to URIs within the same domain as the document
containing the link
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: send all pings
> 3) Remove "ping" support (or disable it by default)
This should only be done, IMO, if the reasons for adding support for
<a ping> have changed. For example, if it turns out that there's no
indication of websites or website tracking software supporting it.
> 4) Do nothing and leave things as they are
>
> To be honest, I like option 4 the least. The idea of this attribute
> is that it
> makes it easy for website authors to do something they can do anyway
> (track
> users) in return for the users knowing when they're being tracked.
> But if we
> don't give the user that information, it seems to me that the
> situation is worse
> than if the user doesn't know he's being tracked but the site at
> least has to
> put in some work to do it.
I think that we shouldn't be seeing <a ping> as a way of enabling
malicious use, nor designing it for the prevention of malicious use,
but rather implementing it as a way of allowing webmasters who want to
do web tracking yet allow users to opt in/out of that tracking to make
that decision.
Providing additional information to users is valuable, I agree, but
should be done carefully, and only if we think providing it adds a lot
of value.
cheers,
mike
> We initially enabled ping in the alphas as a test, but before we
> ship 1.9 we
> should make a final decision on whether we're supporting it, and if
> so what UI
> we want to have for it. Around now is as late as we want to go with
> that
> decision, imo.
>
> -Boris
>
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
Boris Zbarsky
guess it didn't get any response there, so this is as good as anything.
Mike Beltzner wrote:
> First, what was the purpose of <a ping>?
I think one of the purposes is ad impression tracking, last I checked.
> I don't think anyone expected malicious third-party
> notifications to shift over to <a ping>, but maybe I'm wrong?
I'm not sure what you mean by "malicious" in this context. Pretty much all
tracking is malicious, really. ;)
> Second, does <a ping> actually differentiate between "third parties" and
> "any party"?
The current implementation has a way to enforce a "send pings only to same host"
policy. It defaults to not doing that, and Firefox doesn't set the relevant pref.
> By that I mean, do we think a <a ping> notification from
> www.foo.com to somewhere.foo.com is any more or less kosher than one
> from www.foo.com to somewhere.else.com?
That's a social question, not a technical question. Note that www.foo.com and
somewhere.foo.com need not have much to do with each other (though our effective
TLD service tries to capture that sort of thing...)
> It strikes me that if I'm on
> beltzner.ca, and the notification ping goes to beltzner.ca, it's pretty
> different than if I'm on beltzner.ca and the notification ping goes to
> adsense.com.
Sure. Restricting ping to same-origin is a one-line pref change.
> Third, do we expect that telling a user that clicking link will result
> in a notification ping is useful information for them to have?
That really depends on the user.... For most of them, possibly not.
> Can that user take any action (or inaction) due to that information?
Yes. The user can not click on the link and take their business elsewhere. Most
probably won't bother.
> My feeling is that we'd probably want to add UI that allows users to turn these
> types of notifications off, not UI that notifies the user that they're
> being sent.
I suspect most users would never find such UI unless it comes up when a ping is
first encountered or something... which sucks as UI goes.
> I also think we should modify browser.send_pings to
> support three different levels:
>
> 0: disable
> 1: send pings to URIs within the same domain as the document containing
> the link
> 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: send all pings
Right now the available frobs are:
"browser.send_pings" -- boolean
"browser.send_pings.require_same_host" -- boolean
So we have states 0, 1, 3 above. We could definitely add state 2 (though of
course it wouln't handle redirects that well) and could make this a single pref.
> I think that we shouldn't be seeing <a ping> as a way of enabling
> malicious use, nor designing it for the prevention of malicious use
Sure. At the same time, it _will_ get malicious use, and we should be keeping
that in mind.
> Providing additional information to users is valuable, I agree, but
> should be done carefully, and only if we think providing it adds a lot
> of value.
Agreed. At the same time, providing a well-hidden "turn off ping" knob when
most users don't even realize the knob exists doesn't really serve the user
either. Might as well just tell people who care to use about:config.
-Boris
Mike Beltzner
> Ugh. I forgot to set Reply-To in addition to Followup-To (both
> to .dom)... I
> guess it didn't get any response there, so this is as good as
> anything.
>
> Mike Beltzner wrote:
>> First, what was the purpose of <a ping>?
>
> I think one of the purposes is ad impression tracking, last I checked.
According to the WHATWG HTML 5 spec ..:
* It allows the user to see the final target URI unobscured.
* It allows the UA to inform the user about the out-of-band
notifications.
* It allows the paranoid user to disable the notifications
without losing the underlying link functionality.
* It allows the UA to optimise the use of available network
bandwidth so that the target page loads faster.
So I think it's more than just "ad impression tracking". Allowing
website authors easier ways to track navigation within their site
could result in huge usability wins on those websites. I don't think
we should come at this with a "tracking is always bad" mentality.
>> I don't think anyone expected malicious third-party
>> notifications to shift over to <a ping>, but maybe I'm wrong?
>
> I'm not sure what you mean by "malicious" in this context. Pretty
> much all
> tracking is malicious, really. ;)
Yeah, like that type of mentality ;)
>> Second, does <a ping> actually differentiate between "third
>> parties" and
>> "any party"?
>
> The current implementation has a way to enforce a "send pings only
> to same host"
> policy. It defaults to not doing that, and Firefox doesn't set the
> relevant pref.
>
>> By that I mean, do we think a <a ping> notification from
>> www.foo.com to somewhere.foo.com is any more or less kosher than one
>> from www.foo.com to somewhere.else.com?
>
> That's a social question, not a technical question. Note that www.foo.com
> and
> somewhere.foo.com need not have much to do with each other (though
> our effective
> TLD service tries to capture that sort of thing...)
Does browser.send_pings.require_same_host require 1:1 matching or just
eTLD matching? I'm guessing that it requires 1:1 at the moment.
>> It strikes me that if I'm on
>> beltzner.ca, and the notification ping goes to beltzner.ca, it's
>> pretty
>> different than if I'm on beltzner.ca and the notification ping goes
>> to
>> adsense.com.
>
> Sure. Restricting ping to same-origin is a one-line pref change.
>
>> Third, do we expect that telling a user that clicking link will
>> result
>> in a notification ping is useful information for them to have?
>
> That really depends on the user.... For most of them, possibly not.
>
>> Can that user take any action (or inaction) due to that information?
>
> Yes. The user can not click on the link and take their business
> elsewhere. Most
> probably won't bother.
That seems like a less useful option given the stated purposes of the
specification above, which is to allow users to disable the tracking
option yet retain the underlying functionality of the link.
My current feeling (now accepting counter-arguments) is that this
should be a visible pref in the privacy options, worded carefully to
express the fact that it's user-opt-out if the webmaster gives the
user a choice :)
>> My feeling is that we'd probably want to add UI that allows users
>> to turn these
>> types of notifications off, not UI that notifies the user that
>> they're
>> being sent.
>
> I suspect most users would never find such UI unless it comes up
> when a ping is
> first encountered or something... which sucks as UI goes.
Agreed. Mind you, the privacy conscious can read documentation or
follow guides about how to turn off such features just like they
currently do with cookies or other privacy options. And in the future,
if we do write a Private Browsing Mode, this pref would obviously be
part of that.
>> I also think we should modify browser.send_pings to
>> support three different levels:
>>
>> 0: disable
>> 1: send pings to URIs within the same domain as the document
>> containing
>> the link
>> 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: send all pings
>
> Right now the available frobs are:
>
> "browser.send_pings" -- boolean
> "browser.send_pings.require_same_host" -- boolean
>
> So we have states 0, 1, 3 above. We could definitely add state 2
> (though of
> course it wouln't handle redirects that well) and could make this a
> single pref.
That would be great flexibility to have, IMO.
>> I think that we shouldn't be seeing <a ping> as a way of enabling
>> malicious use, nor designing it for the prevention of malicious use
>
> Sure. At the same time, it _will_ get malicious use, and we should
> be keeping
> that in mind.
Right. Reducing the ways in which <a ping> can be used maliciously
should be our goal, so that we can provide a way for webmasters to
play by nice rules, so to speak.
>> Providing additional information to users is valuable, I agree, but
>> should be done carefully, and only if we think providing it adds a
>> lot
>> of value.
>
> Agreed. At the same time, providing a well-hidden "turn off ping"
> knob when
> most users don't even realize the knob exists doesn't really serve
> the user
> either. Might as well just tell people who care to use about:config.
There's a pretty big difference between Preferences > Privacy and
about:config, I think, in terms of both discoverability and ability to
act on the control.
So let's think about how we could make users aware as they hover over
a link. A few options come to mind:
A - add something to the status bar: "http://www.foo.com (bar.com will
be notified)"
B - some sort of security dialog/browsermessage/thing on the first
encountered <a ping>
C - some text added to the tooltip: "http://www.foo.com (bar.com will
be notified)"
My feeling is that B is a non-starter, since it's basically another
"whatever" dialog, and A and C will only really be understood by a few
people and isn't worth the pixels spent on them, but again, I'd be
totally willing to hear arguments to the contrary.
cheers,
mike
Michael Vincent van Rantwijk, MultiZilla
> Ugh. I forgot to set Reply-To in addition to Followup-To (both to
> .dom)... I guess it didn't get any response there, so this is as good
> as anything.
>
> Mike Beltzner wrote:
>> First, what was the purpose of <a ping>?
This is all about the user consent, giving the visitor control. There
will be a new privacy label stating that the visited website will *not*
use any other technique for user tracking other than a/area pings, which
is under the end user (visitors) control.
> I think one of the purposes is ad impression tracking, last I checked.
>
>> I don't think anyone expected malicious third-party notifications to
>> shift over to <a ping>, but maybe I'm wrong?
>
> I'm not sure what you mean by "malicious" in this context. Pretty much
> all tracking is malicious, really. ;)
>
>> Second, does <a ping> actually differentiate between "third parties"
>> and "any party"?
>
> The current implementation has a way to enforce a "send pings only to
> same host" policy. It defaults to not doing that, and Firefox doesn't
> set the relevant pref.
>
>> By that I mean, do we think a <a ping> notification from www.foo.com
>> to somewhere.foo.com is any more or less kosher than one from
>> www.foo.com to somewhere.else.com?
>
> That's a social question, not a technical question. Note that
> www.foo.com and somewhere.foo.com need not have much to do with each
> other (though our effective TLD service tries to capture that sort of
> thing...)
>
>> It strikes me that if I'm on beltzner.ca, and the notification ping
>> goes to beltzner.ca, it's pretty different than if I'm on beltzner.ca
>> and the notification ping goes to adsense.com.
>
> Sure. Restricting ping to same-origin is a one-line pref change.
>
>> Third, do we expect that telling a user that clicking link will result
>> in a notification ping is useful information for them to have?
> That really depends on the user.... For most of them, possibly not.
I would say yes, because of this text in the draft spec: "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 URIs."
and: "User agents should allow the user to adjust this behaviour, for
example in conjunction with a setting that disables the sending of HTTP
Referrer headers. Based on the user's preferences, UAs may either ignore
the ping attribute altogether, or selectively ignore URIs in the list
(e.g. ignoring any third-party URIs)."
And thus without any of these UI features the ping attribute should be
ignore, taken out or disabled by default. That's why I said to go for
option 3 in the other newsgroup.
>> Can that user take any action (or inaction) due to that information?
>
> Yes. The user can not click on the link and take their business
> elsewhere. Most probably won't bother.
>
>> My feeling is that we'd probably want to add UI that allows users to
>> turn these types of notifications off, not UI that notifies the user
>> that they're being sent.
>
> I suspect most users would never find such UI unless it comes up when a
> ping is first encountered or something... which sucks as UI goes.
>
>> I also think we should modify browser.send_pings to support three
>> different levels:
>>
>> 0: disable
>> 1: send pings to URIs within the same domain as the document
>> containing the link
>> 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: send all pings
This feature is all about user control; so you'll need to ask me also.
You might want to load the ping docs for everything, I don't care about
mozilla.org but I most certainly don't want google.com to track me even
more than they already do.
> Right now the available frobs are:
>
> "browser.send_pings" -- boolean
> "browser.send_pings.require_same_host" -- boolean
browser.send_pings is not a good name, because it doesn't send a ping
header but uses a post request. The pref should also be of type int
instead of boolean.
> So we have states 0, 1, 3 above. We could definitely add state 2
> (though of course it wouln't handle redirects that well) and could make
> this a single pref.
First, the ping attribute can be a list of URI's, with different
domains. Also note that relative URI's must be completed based on the
parent element, which can be anything. Let's take an example:
<a href="mozilla.org" ping="mozilla.com/ping.xml
google.com/ping.xml>click here</a>
This should bring the visitor to: mozilla.org and load
mozilla.com/ping.xml and google.com/ping.xml *after* the load of
mozilla.org (but ignoring the response body completely).
Now, if I have set your browser.send_ping to ask me it should show a
<panel> listing all URI's and I want control over what when to load.
That's like having control over something.
Why not use the permission manager for this?
>> I think that we shouldn't be seeing <a ping> as a way of enabling
>> malicious use, nor designing it for the prevention of malicious use
>
> Sure. At the same time, it _will_ get malicious use, and we should be
> keeping that in mind.
That's why there will be a new label, with a link to a governing
organization which checks things. Privacy will become an expensive good
one day, I tell you.
>> Providing additional information to users is valuable, I agree, but
>> should be done carefully, and only if we think providing it adds a lot
>> of value.
>
> Agreed. At the same time, providing a well-hidden "turn off ping" knob
> when most users don't even realize the knob exists doesn't really serve
> the user either. Might as well just tell people who care to use
> about:config.
>
> -Boris
If you are a privacy aware developer, you'll turn the feature off and
let people opt-in ;)
--
Michael Vincent van Rantwijk
- MultiZilla Project Team Lead
- XUL Boot Camp Staff member (ActiveState Training Partner)
- iPhone Application Developer
Jesper Kristensen
> So let's think about how we could make users aware as they hover over a
> link. A few options come to mind:
If users need to be aware of this or need to opt-in, I think it is
better to just not implement the feature. As said by other people, the
functionality can be achieved by other means without notifying the user.
>
> A - add something to the status bar: "http://www.foo.com (bar.com will
> be notified)"
> B - some sort of security dialog/browsermessage/thing on the first
> encountered <a ping>
> C - some text added to the tooltip: "http://www.foo.com (bar.com will be
> notified)"
Doing B would be teaching the users to ignore warnings (if we forget
that they have learned it already). I guess that would negatively impact
security and maybe also privacy.
If the browser is going to "warn" users that a website is doing
statistics on the user's behavior, my guess is that websites won't use
this feature because they don't want to annoy their users. Websites can
already do the tracking today anyway without annoying or scaring the
users with browser warnings.
Option C: tooltips are content domain. putting chrome information in
here would be confusing.
Option A: This is added UI complexity for very little or no value.
IMO the negatives of the UI outweigh the positives of the feature.
Gijs Kruitbosch
> <snip>
>> Third, do we expect that telling a user that clicking link will result
>> in a notification ping is useful information for them to have?
>
> That really depends on the user.... For most of them, possibly not.
I'm pretty sure that 99.9999% of users won't, and that developers/geeks
are the only people who do. And in fact, a fair bunch of even those
people will not understand that this setting does not completely prevent
them from being tracked - just not through <a ping>. Which all goes to
show we're entirely the wrong people to be having this discussion.
>> Can that user take any action (or inaction) due to that information?
>
> Yes. The user can not click on the link and take their business
> elsewhere. Most probably won't bother.
I think the fact that most people ignore security warnings and other
privacy concerns when browsing to a website they "need" (bank, mail,
whatever) proves that Boris is right here - people won't bother to stand
on their principles. Which is another reason that confronting UI is
going to be useless.
>> My feeling is that we'd probably want to add UI that allows users to
>> turn these types of notifications off, not UI that notifies the user
>> that they're being sent.
>
> I suspect most users would never find such UI unless it comes up when a
> ping is first encountered or something... which sucks as UI goes.
Agreed. But then, most users would never need such UI (see above). And
the people who do need such UI *would* find it (as they're the kind of
people who go exploring about:config and/or the entire pref panel, even
if they're not sure what they're going to change about it, just assuming
that good tweaks will be hidden in there).
> <snip>
>
>> I think that we shouldn't be seeing <a ping> as a way of enabling
>> malicious use, nor designing it for the prevention of malicious use
>
> Sure. At the same time, it _will_ get malicious use, and we should be
> keeping that in mind.
How does that help us? I'm pretty sure that if malicious tracking is
wanted, right now websites will use other means (because other browsers
don't yet support this, as far as I know) and people are able to turn
this method off. So I actually don't think there will be much malicious
uses of it. That is to say, if I were a malicious person, I would choose
the route that is least likely to be found out and/or blocked by
obstacles (such as user consent or user agent support) to accomplish my
malicious goals. Which makes <a ping> a really bad candidate to do
malicious tracking. For positive use, on the other hand, it is a really
good candidate since users can turn it off (which positive use would be
quite OK with, most of the time).
>
>> Providing additional information to users is valuable, I agree, but
>> should be done carefully, and only if we think providing it adds a lot
>> of value.
>
> Agreed. At the same time, providing a well-hidden "turn off ping" knob
> when most users don't even realize the knob exists doesn't really serve
> the user either. Might as well just tell people who care to use
> about:config.
>
> -Boris
Right. See above. So to be honest, while I agree that it might be good
to have one more option for the pref, I don't really think we need or
want UI. It just adds complexity and annoyance, most people who see it
don't need it, and the people who do need it will find it even if we
don't have UI for it.
~ Gijs
Michael Vincent van Rantwijk, MultiZilla
> Mike Beltzner skrev:
>> So let's think about how we could make users aware as they hover over
>> a link. A few options come to mind:
>
> If users need to be aware of this or need to opt-in, I think it is
> better to just not implement the feature. As said by other people, the
> functionality can be achieved by other means without notifying the user.
>
>>
>> A - add something to the status bar: "http://www.foo.com (bar.com will
>> be notified)"
>> B - some sort of security dialog/browsermessage/thing on the first
>> encountered <a ping>
>> C - some text added to the tooltip: "http://www.foo.com (bar.com will
>> be notified)"
>
> Doing B would be teaching the users to ignore warnings (if we forget
> that they have learned it already). I guess that would negatively impact
> security and maybe also privacy.
This feature has nothing to do with security.
> If the browser is going to "warn" users that a website is doing
> statistics on the user's behavior, my guess is that websites won't use
> this feature because they don't want to annoy their users. Websites can
> already do the tracking today anyway without annoying or scaring the
> users with browser warnings.
This feature is about giving the visitors control over tracking, and
since when is informing people scary? It will be a hell lot more
annoying to not have control over it; the <marquee> implementation in
Mozilla comes to mind here.
> Option C: tooltips are content domain. putting chrome information in
> here would be confusing.
>
> Option A: This is added UI complexity for very little or no value.
>
> IMO the negatives of the UI outweigh the positives of the feature.
If people want to use it, willing to opt-in, then this might be a little
price for it, and it won't change anything for the rest of the Mozilla
Firefox users.
Michael Vincent van Rantwijk, MultiZilla
> Boris Zbarsky wrote:
>> <snip>
>>> Third, do we expect that telling a user that clicking link will
>>> result in a notification ping is useful information for them to have?
>>
>> That really depends on the user.... For most of them, possibly not.
>
> I'm pretty sure that 99.9999% of users won't, and that developers/geeks
> are the only people who do. And in fact, a fair bunch of even those
> people will not understand that this setting does not completely prevent
> them from being tracked - just not through <a ping>. Which all goes to
> show we're entirely the wrong people to be having this discussion.
>
>>> Can that user take any action (or inaction) due to that information?
>>
>> Yes. The user can not click on the link and take their business
>> elsewhere. Most probably won't bother.
>
> I think the fact that most people ignore security warnings and other
> privacy concerns when browsing to a website they "need" (bank, mail,
> whatever) proves that Boris is right here - people won't bother to stand
> on their principles. Which is another reason that confronting UI is
> going to be useless.
Just ask people about why they use a "different" OS or Mozilla
Firefox/SeaMonkey and they will teach you about the first rule of
principles...which is to be able to choose what you need/want and in
freedom, and that is what this feature is about; giving you the visitor
(end-user) control over something.
This malicious site talk has got to stop as it is getting ridiculous,
seriously, or people should start accepting these 'bad sites' and just
use Internet Explorer on MS Windows, just because some 'bad sites' are
stupid and refuse to change their minds.
Gijs Kruitbosch
Exactly how many people use a "different" OS? How many of them do you
estimate know where about:config is? Because I think the answer to the
first question is "very few" and to the second is "very many". Which was
kind of my point to begin with...
I'm not advocating taking choice away from users. I'm advocating not
annoying users with choices which they cannot reasonably be expected to
make. Users don't like that. Do you think Joe User understands the
reasons behind, implications of, and uses of, sending <a ping> or not?
'Cause I certainly don't. And adding dialogs or icons or tooltips isn't
going to Make It So.
~ Gijs
PS: principles are personal - by extension, so are first principles. If
you don't believe me, look up the first articles of the constitutions of
10 random countries. I'll guarantee you that standard deviation will be
way more than 0.
Michael Vincent van Rantwijk, MultiZilla
Add the number of Mozilla Firefox and SeaMonkey users, that's the number
we're talking about.
> How many of them do you estimate know where about:config is?
You only need about:config when there is no (or poor/hidden) pref UI for
the setting(s) involved, and IMHO there should only be one.
> Because I think the answer to the
> first question is "very few" and to the second is "very many". Which was
> kind of my point to begin with...
>
> I'm not advocating taking choice away from users.
Not implementing this feature _is_ about taking a choice away; as if
they cannot make this decision on their own. Like they cannot read, go
to school and study, because I know that *the* majority of Mozilla
Firefox are in fact young people under 30.
> I'm advocating not
> annoying users with choices which they cannot reasonably be expected to
> make. Users don't like that. Do you think Joe User understands the
> reasons behind, implications of, and uses of, sending <a ping> or not?
One word -> education!
> 'Cause I certainly don't. And adding dialogs or icons or tooltips isn't
> going to Make It So.
I keep reading about how stupid the end-users of Mozilla Firefox are,
but they made the switch to Mozilla Firefox from presumably a
pre-installed version of MS Internet Explorer, so tell me something; was
that also a judgment error?
> ~ Gijs
>
> PS: principles are personal - by extension, so are first principles. If
> you don't believe me, look up the first articles of the constitutions of
> 10 random countries. I'll guarantee you that standard deviation will be
> way more than 0.
Exactly; and that is why I wrote: "the first _rule_ of principles"
because that is about freedom and being able to make choices, which of
course should be personal, and to each its own ;)
Boris Zbarsky
Without at the same time annoying him out of his mind.
> There will be a new privacy label stating that the visited website will *not*
> use any other technique for user tracking other than a/area pings
Ah, P3P-like fun. Doesn't work, sorry. Who'd bother with it?
> I would say yes, because of this text in the draft spec:
That reminds me. Once we have implementation experience with UI for this we
should give feedback to the spec author. I suspect that Ian is underestimating
the difficulties in having a sane UI for this.
> And thus without any of these UI features the ping attribute should be
> ignore, taken out or disabled by default.
Those are SHOULD requirements, not MUST.
> This feature is all about user control; so you'll need to ask me also.
You seriously want to be asked for every single link click?
> browser.send_pings is not a good name, because it doesn't send a ping
> header but uses a post request. The pref should also be of type int
> instead of boolean.
Patches accepted. ;)
> First, the ping attribute can be a list of URI's, with different
> domains.
Yes, yes. Right now each ping in the attr is treated separately, with the
same-origin policy, if enabled, applied to each ping.
> Also note that relative URI's must be completed based on the
> parent element, which can be anything.
I don't see how that's relevant to anything here.
> Now, if I have set your browser.send_ping to ask me it should show a
> <panel> listing all URI's and I want control over what when to load.
> That's like having control over something.
Imagine for a few minutes having "control" over your body. I'm talking full
at-all-times conscious control over breathing, the circulatory system, the
digestive system, temperature regulation, hormone balance, other aspects of
homeostasis, balance, all muscle function, etc. Would that be a good thing?
A setup where the things that should work Just Work and don't bother you with it
is really a lot better. You have a medulla oblongata and a cerebellum for a
reason. Ideally, there are conscious overrides as needed (e.g. you can hold
your breath or make yourself fall over to the right if you decide you want to do
it).
> Why not use the permission manager for this?
How, exactly? We sort of need a plan, not a general vague idea.
> That's why there will be a new label, with a link to a governing
> organization which checks things.
I'll believe it when I see it.
-Boris
Boris Zbarsky
> Which all goes to
> show we're entirely the wrong people to be having this discussion.
Sadly, there is no one else. We'll just have to do our best.
> So I actually don't think there will be much malicious
> uses of it. That is to say, if I were a malicious person, I would choose
> the route that is least likely to be found out and/or blocked by
> obstacles
This is a compelling argument, indeed. Perhaps compelling enough that we don't
really need UI after all (though I would still suggest restricting the ping
functionality in reasonable ways if possible). Can we think offhand of places
that we _woudln't_ want to get pings?
-Boris
Boris Zbarsky
>> I'm advocating not annoying users with choices which they cannot
>> reasonably be expected to make. Users don't like that. Do you think
>> Joe User understands the reasons behind, implications of, and uses of,
>> sending <a ping> or not?
>
> One word -> education!
Let's get serious here. Most people don't care to be educated about
_everything_. This is a reasonable attitude, because there are more things to
learn than one can learn in a lifetime. So one picks and chooses where to
invest learning time. This would strike most users as a bad investment. Heck,
it strikes _me_ that way.
> I keep reading about how stupid the end-users of Mozilla Firefox are,
No. They're not stupid. They just don't necessarily care about all the niggly
details of the infrastructure of the Web. Nor should they.
Let me put it this way. Do you do a safety inspection of every bridge you come
to before you drive over it? If not, why not?
-Boris
Martijn
> Gijs Kruitbosch wrote:
> > So I actually don't think there will be much malicious
> > uses of it. That is to say, if I were a malicious person, I would choose
> > the route that is least likely to be found out and/or blocked by
> > obstacles
>
> This is a compelling argument, indeed. Perhaps compelling enough that we don't
> really need UI after all (though I would still suggest restricting the ping
> functionality in reasonable ways if possible). Can we think offhand of places
> that we _woudln't_ want to get pings?
I don't understand, isn't this actually a reason disable 'ping'?
Because if it would be enabled by default, it wouldn't be likely
blocked by obstacles.
Btw, what should happen when javascript has been turned off, users
might think they are cured from this kind of tracking, since it's
normally done in a javascript sort of way.
BBtw, can a script know if ping is enabled/disabled? I think there
should be a way to know it, otherwise they'll still use the js way,
since that is always reliable.
Regards,
Martijn
> -Boris
>
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
>
--
Martijn Wargers - Help Mozilla!
http://weblogs.mozillazine.org/qa/
http://wiki.mozilla.org/Mozilla_QA_Community
irc://irc.mozilla.org/qa - /nick mw22
Michael Vincent van Rantwijk, MultiZilla
> Michael Vincent van Rantwijk, MultiZilla wrote:
>> This is all about the user consent, giving the visitor control.
>
> Without at the same time annoying him out of his mind.
I agree, but what if we can make this work without UI? I mean, why
bother asking for post request to the same domain? Either make it an
opt-in feature, or set the default to the same domain policy.
>> There will be a new privacy label stating that the visited website
>> will *not* use any other technique for user tracking other than a/area
>> pings
>
> Ah, P3P-like fun. Doesn't work, sorry. Who'd bother with it?
>
>> I would say yes, because of this text in the draft spec:
>
> That reminds me. Once we have implementation experience with UI for
> this we should give feedback to the spec author. I suspect that Ian is
> underestimating the difficulties in having a sane UI for this.
>
>> And thus without any of these UI features the ping attribute should be
>> ignore, taken out or disabled by default.
>
> Those are SHOULD requirements, not MUST.
Ok, but right now the user has no control, and that might bite you one day.
>> This feature is all about user control; so you'll need to ask me also.
>
> You seriously want to be asked for every single link click?
>
>> browser.send_pings is not a good name, because it doesn't send a ping
>> header but uses a post request. The pref should also be of type int
>> instead of boolean.
>
> Patches accepted. ;)
What else is new ;)
>> First, the ping attribute can be a list of URI's, with different domains.
>
> Yes, yes. Right now each ping in the attr is treated separately, with
> the same-origin policy, if enabled, applied to each ping.
>
>> Also note that relative URI's must be completed based on the parent
>> element, which can be anything.
>
> I don't see how that's relevant to anything here.
Ah yes, because I would say limit the default value to same domain
policy only, again without any nagging. That would at least work for me.
>> Now, if I have set your browser.send_ping to ask me it should show a
>> <panel> listing all URI's and I want control over what when to load.
>> That's like having control over something.
>
> Imagine for a few minutes having "control" over your body. I'm talking
> full at-all-times conscious control over breathing, the circulatory
> system, the digestive system, temperature regulation, hormone balance,
> other aspects of homeostasis, balance, all muscle function, etc. Would
> that be a good thing?
Again, I certainly don't want to be asked time after time, that's why I
want to use the permission manager, making it a one time nagging only
feature.
> A setup where the things that should work Just Work and don't bother you
> with it is really a lot better. You have a medulla oblongata and a
> cerebellum for a reason. Ideally, there are conscious overrides as
> needed (e.g. you can hold your breath or make yourself fall over to the
> right if you decide you want to do it).
See above.
>> Why not use the permission manager for this?
>
> How, exactly? We sort of need a plan, not a general vague idea.
Ok, so what if we save the setting (permission) for future use,
eliminating the need to bother the end-user with it ever again? Just
like we do with popups and images? And only for anything else but the
same origin policy. Would that work for you?
>> That's why there will be a new label, with a link to a governing
>> organization which checks things.
>
> I'll believe it when I see it.
>
> -Boris
>
Michael Vincent van Rantwijk, MultiZilla
> 2007/10/30, Boris Zbarsky <bzba...@mit.edu>:
>> Gijs Kruitbosch wrote:
>>> So I actually don't think there will be much malicious
>>> uses of it. That is to say, if I were a malicious person, I would choose
>>> the route that is least likely to be found out and/or blocked by
>>> obstacles
>> This is a compelling argument, indeed. Perhaps compelling enough that we don't
>> really need UI after all (though I would still suggest restricting the ping
>> functionality in reasonable ways if possible). Can we think offhand of places
>> that we _woudln't_ want to get pings?
>
> I don't understand, isn't this actually a reason disable 'ping'?
> Because if it would be enabled by default, it wouldn't be likely
> blocked by obstacles.
The spec also reads: "It allows the user to see the final target URI on
obscured.".
This will become very useful, almost mandatory because it helps me from
getting on sites I don't want to visit, and that might help me
eventually from getting into legal trouble, for example: visiting a site
with child porn images (how sickening) even by accident, is a criminal
offense in the Netherlands.
Boris Zbarsky
> BBtw, can a script know if ping is enabled/disabled?
At the moment, no.
> I think there
> should be a way to know it, otherwise they'll still use the js way,
> since that is always reliable.
It's also a lot more work. I thought that was the appeal of ping to website
authors: simplicity.
-Boris
Mike Beltzner
>> Does browser.send_pings.require_same_host require 1:1 matching or
>> just
>> eTLD matching? I'm guessing that it requires 1:1 at the moment.
>
> It's 1:1 on host (not hostport, mind you). This could be changed,
> of course. SMOC.
>
>>> Yes. The user can not click on the link and take their business
>>> elsewhere. Most
>>> probably won't bother.
>>
>> That seems like a less useful option given the stated purposes of the
>> specification above, which is to allow users to disable the tracking
>> option yet retain the underlying functionality of the link.
>
> Agreed.
>
>>> So we have states 0, 1, 3 above. We could definitely add state 2
>>> (though of
>>> course it wouln't handle redirects that well) and could make this a
>>> single pref.
>>
>> That would be great flexibility to have, IMO.
>
> OK. Let's get a bug filed? The changes shouldn't be that hard,
> esp. if we
> don't care about migrating existing user prefs from the alphas.
Filed bug 401670.
> Perhaps we should take another approach to this. Figure out what
> uses of ping
> we would like to cater to, figure out what pings need to be allowed
> to handle
> those use cases, then decide whether limiting to just those pings is
> reasonable
> (or whether it's even "limiting" at all).
I think that's what we're doing :) I really do see <a ping> as a way
of formalizing tracking into a web-standard fashion, and I see our
responsibility as being allowing a user to opt-out of web tracking in
a way that's analogous to them opting out of cookies (which is ...
hey! ... another form of tracking :)
cheers,
mike
Dão
> Martijn wrote:
>> BBtw, can a script know if ping is enabled/disabled?
>
> At the moment, no.
If the browser supports ping, it should say so, but IMO it shouldn't
expose the enabled/disabled state, as a javascript fallback wouldn't be
in the user's interest in that case.
Dao
Tony Mechelynck
Is it possible for JavaScript to do the following:
1. Does the User-Agent include " Gecko/" ?
2. If yes, is the preference browser.send_pings defined?
3. If yes, what is its value?
If it can, then of course it can know whether pings are enabled in Firefox.
Best regards,
Tony.
--
"If you understand what you're doing, you're not learning anything."
-- A. L.
Dão
> Dăo wrote:
>> Boris Zbarsky wrote:
>>> Martijn wrote:
>>>> BBtw, can a script know if ping is enabled/disabled?
>>>
>>> At the moment, no.
>>
>> If the browser supports ping, it should say so, but IMO it shouldn't
>> expose the enabled/disabled state, as a javascript fallback wouldn't
>> be in the user's interest in that case.
>
>
> 1. Does the User-Agent include " Gecko/" ?
> 2. If yes, is the preference browser.send_pings defined?
> 3. If yes, what is its value?
>
> If it can, then of course it can know whether pings are enabled in Firefox.
Untrusted content doesn't have access to the browser's internal preferences.
Martijn
Then as a website devver, I would go for the javascript solution,
since that's always working.
Regards,
Martijn
> Dao
Michael Vincent van Rantwijk, MultiZilla
Actually, scripts seem to be able to initiate a POST request [1] and
since you check for your own POST request ;)
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=319368#c4
Jesper Kristensen
> Jesper Kristensen wrote:
>> Mike Beltzner skrev:
>>> encountered <a ping>
>>
>> that they have learned it already). I guess that would negatively
>> impact security and maybe also privacy.
>
> This feature has nothing to do with security.
Exactly. That is why I think a UI that would make users think it has
something to do with security is a bad thing.
Dão
> Dão wrote:
>> Boris Zbarsky wrote:
>>> Martijn wrote:
>>>> BBtw, can a script know if ping is enabled/disabled?
>>>
>>> At the moment, no.
>>
>> If the browser supports ping, it should say so, but IMO it shouldn't
>> expose the enabled/disabled state, as a javascript fallback wouldn't
>> be in the user's interest in that case.
>
> since you check for your own POST request ;)
Sure, you can always check if a ping got through on the server side. But
I think if there's an API as simple as
document.implementation.hasFeature("aPing", "1.0"), authors will more
likely use that, especially as most users aren't going to disable that
feature.
Dao
Dão
> 2007/10/30, Dão <d...@design-noir.de>:
>> Boris Zbarsky wrote:
>>> Martijn wrote:
>>>> BBtw, can a script know if ping is enabled/disabled?
>>> At the moment, no.
>> If the browser supports ping, it should say so, but IMO it shouldn't
>> expose the enabled/disabled state, as a javascript fallback wouldn't be
>> in the user's interest in that case.
>
> Then as a website devver, I would go for the javascript solution,
> since that's always working.
If you don't think users should be in control of such things, <a ping>
isn't for you in the first place.
Dao
Martijn
Michael Vincent van Rantwijk, MultiZilla
> 2007/10/30, Dão <d...@design-noir.de>:
>> Martijn wrote:
>>> 2007/10/30, Dão <d...@design-noir.de>:
>>>> Boris Zbarsky wrote:
>>>>> Martijn wrote:
>>>>>> BBtw, can a script know if ping is enabled/disabled?
>>>>> At the moment, no.
>>>> If the browser supports ping, it should say so, but IMO it shouldn't
>>>> expose the enabled/disabled state, as a javascript fallback wouldn't be
>>>> in the user's interest in that case.
>>> Then as a website devver, I would go for the javascript solution,
>>> since that's always working.
>> If you don't think users should be in control of such things, <a ping>
>> isn't for you in the first place.
>
> Exactly.
>
> Regards,
> Martijn
Are you aware that this is an opt-out feature in Mozilla Firefox?
Robert Kaiser
> Exactly how many people use a "different" OS? How many of them do you
> estimate know where about:config is? Because I think the answer to the
> first question is "very few" and to the second is "very many". Which was
> kind of my point to begin with...
Many people knowing about about:config sound like a UI flaw to me, as
they shouldn't even want to know about it if UI is good.
Robert Kaiser