- From: ROBO Design <robodesign@gmail.com>
- Date: Fri, 21 Oct 2005 22:53:10 +0300
On Fri, 21 Oct 2005 21:43:59 +0300, Ian Hickson <ian at hixie.ch> wrote: > > One of the patterns I've seen a lot while looking at big sites is this: > > <a href="record?url=http%3A%2F%2Ffoo.example.com/"> Foo </a> > > ...where "redirect" is a CGI script that records that the user followed > the link, and that then redirects the user to the real page (potentially > setting a cookie in the process). > > This is used for four main reasons: > > 1. Improving sites, by getting data regarding how users use the site. > > 2. Keeping track of which adverts were clicked on, for book-keeping. > > 3. Improving services, e.g. by offering a number of options, checking > which the user picked, and making that one be the first on the list > the next time the user uses the service. > > 4. Uniquely identifying and tracking a user for evil purposes. > > Sometimes more than one of the above is done, e.g. clicking on adverts > sometimes informs the publisher and the advertiser before moving the user > to the real destination. > > The problem at the moment is that the redirect mechanism obscures the > eventual target URI. It would be good to have the target URI separate > from the tracking URIs, so that the UA can show each of them separately > in > the UI, indicating the user who is getting told what. > > Doing this would also allow the UA to easily turn off the pinging thing > for users who are worried about point 4 above. > > Bearing the above in mind, I've added a section to the <a> element that > describes a ping="" attribute. The URIs given in this attribute would be > followed when the user clicks the link, thus getting around the problems > listed above. > > Now, because of number 4 above, I'm guessing this is going to be > controversial, which is why I'm calling this out explicitly (as opposed > to > waiting til I've filled in all the TBW sections and then just asking for > a > general review, since people might miss it if I did that). > > Thoughts? Is it evil? > > http://whatwg.org/specs/web-apps/current-work/#ping > Yes, it's evil. That's my first impression. Actually, very evil. Yet, I want it :). Here are my thoughts on this one. - Very, very good idea. Yet, we don't live in a perfect world. - Developers will still use the old trick in the book. So, they won't give a ... link :) about the ping attribute. - You could enforce the usage of ping attribute if ... you specifically disallow usage of the tracking trick devs currently use. Yet, this is exagerated. - The way you currently defined the ping= attribute is ... a bit ... dislikable. I mean, you allow the usage of third-party URLs for pinging. Now... if I want to annoy my friend (and flood his server), I just put a ping= attribute pointing to his server? I would enforce the usage of ping= URLs only on the server of the page. - Why multiple ping= URLs? It's useful ... if you allow usage of different servers. Yet, if you apply my above suggestion, then ... multiple pings are no longer needed. - Nobody would really make use of it. As people actually currently ignore the existing web standards (talking about invalid HTML 4 with tables for layout instead of CSS). Those who will use ping= will be ... me ... you .... and all those who do standards-based web sites today (less than a quarter of existing web "developers"). Would be yet-another thing for ... puritans :) (or how they call us) to brag about in their "perfect" sites. It really depends what you want: to give the users something better ... or developers and companies. If you want to give users something better ... you'd probably do what I said above. If you want to give companies "power" then just forbid disabling the use of ping= in implementations. Yet, having a separate link always gives a window of escaping, if you know what I mean. For companies, they would be happier to just not add ping= (see why I said it's evil?). Anyway, congratulations on the idea. Very good one. Curious how it will turn out. -- http://www.robodesign.ro ROBO Design - We bring you the future
Received on Friday, 21 October 2005 12:53:10 UTC