29

I just stumbled upon this post. The bottom of the answer contained two tracking links. After editing the post I discovered that all of this user's posts contain bit.ly and CiteHistory trackers.

A quick Google for site:stackoverflow.com "CiteHistory record" shows just 6 results. That's not much, but most of the results are hidden behind a bit.ly link, such as this one.

Further searches brought me to research.microsoft.com, which says (emphasis mine):

CiteHistory is an experimental Internet Explorer 9 browser plug-in that enables MSDN and Stack Exchange forum participants to share the pages they visit in association with asking and answering forum questions. (...)
CiteHistory transmits browsing logs associated with visitation of technical forums. When a person visits MSDN, or a Stack Exchange website, CiteHistory logs the visit to the forum and an obscured representation of the past hour of browsing history. (...)

Editing out the links will be a temporary solution, because the CiteHistory project is still on-going.
What's the best way to get rid of this junk?

8
  • 7
    Hrm. We could blacklist "CiteHistory" across all sites, but there's not much we can do about folks who hide it behind a shortener.
    – Adam Lear StaffMod
    Jan 18, 2013 at 21:54
  • 8
    @AnnaLear - What if we did away with shortened links altogether, as suggested here: meta.stackexchange.com/questions/29518/… ? I'm seeing more spammers hiding links in shortened URLs, as well as people using that to get around our ban of LMGTFY and related links. Jan 18, 2013 at 22:16
  • @BradLarson I think that sounds nice in principle, but in theory any site could be used as a shortener (or longener :)), so we'd be forever fighting a losing battle trying to keep up.
    – Adam Lear StaffMod
    Jan 18, 2013 at 22:18
  • 3
    @AnnaLear - True, but if we dealt with the most common cases (goo.gl, bit.ly, tinyurl) that would take care of almost all of the instances I've seen. I'd imagine only a small fraction of people would find other ways to work around this. Jan 18, 2013 at 22:22
  • 2
    That request linked by @Brad Larson should be implemented. Reading through the discussion, in 2013, there is now not a single good reason for link shorteners to be allowed on SE sites. Jan 18, 2013 at 23:08
  • 1
    @AnnaLear: It wouldn't be that hard to resolve any shortened/obfuscated URLs: just try to fetch all linked pages when the post is saved, and if you get a 301 redirect (or several in a row), replace the original URL with the redirect target. That's basically what your browser does when you click the link, anyway, and also what Google and other web crawlers do, so why couldn't SE do the same? The HTTP spec actually encourages clients with link editing capabilities to do that. Jan 19, 2013 at 8:44
  • @IlmariKaronen FYI, Stack Exchange does have a crawler, but for different purposes. I think that HEADing for every link is too expensive though.
    – Rob W
    Jan 19, 2013 at 9:00
  • 1
    @RobW: If it's only done once for each new post (or edit), or even only once for each URL with the results cached, I doubt it'd be a very significant expense compared to adding the post itself. And it could be done using fairly short timeouts, or deferred to a background job. Also, much of the expense could be avoided by whitelisting commonly linked sites known not to be URL shorteners. Jan 19, 2013 at 9:09

2 Answers 2

16

I have no idea what this plugin is and far as I can tell it is not endorsed by us in any way. I don't know who's behind research.microsoft.com and why this plugin specifically addresses MSDN (well, that's sort of obvious) and Stack Exchange but not other sites.

That said, my advice would be to edit these links out whenever you find them. They are just noise and nobody likes to be tracked.

If we see a lot of these links in plain form, we can blacklist "CiteHistory" as an input. Although that would only drive folks to use more URL shorteners and make these links harder to find and remove, so I hesitate to recommend that right away.

1
1

I think Anna has slightly missed the point of this plug-in... it's purpose is not to track the readers of the post, it's a link accumulator/tracker plug-in for the convenience of the person who is posting the question or answer. It looks handy, I would consider giving it a trial run.

Therefore, you could edit out links which are not directly related to the question/answer, but if you remove more than that then technically you are vandalising the post because the author intended for those links to be there.

So while there is a certain amount of unknown relating to this, let's not just go editing stuff out willy-nilly.

Edit:

After checking the target of the original link used in the example, it seems to contain an ID relating to the user of the tool but not related to Stack Overflow, and nothing else. CiteHistory seems to be merely a redirection service - if it is tracking readers that are clicking the links then it is only tracking stuff that is available to anyone clicking on a link from Stack Overflow (attempting to go to http://citehistory.azurewebsites.net redirects to the applicable Microsoft Research page).

3
  • So, you're advising against editing out CiteHistory links when CiteHistory itself is the subject of the question or answer? Sure, I guess, but I don't think that's happening here. Jan 19, 2013 at 1:57
  • @MichaelPetrotta I haven't checked all the links, I'm just tying to calm the trigger-happy edit fingers - people need to evaluate the validity of the links rather than edit it based on the tool used to place it there.
    – slugster
    Jan 19, 2013 at 2:02
  • 2
    @MichaelPetrotta I agree that if the links are obfuscated or add zero value then they are candidates for culling.
    – slugster
    Jan 19, 2013 at 2:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .