Late to Site Meter third party cookie skullduggery or nothing to see here? |
This might be old news to some, but I’m just getting up to speed on this one. I’ve used Site Meter on most of the blogs I contribute to but somehow missed the whole discussion about them allegedly being paid to plant third party cookies like specificclick in visitor’s browsers.
Eric Odom quotes a long response from Site Meter on the issue where they essentially say the specificclick cookie is harmless, the company is reputable, they check out any company before doing business with them.
I just inspected the Site Meter privacy policy to see if it specifically mentions or addresses planting third party cookies as part of their stats service but the closest I could find was this (emphasis mine):
“Site Meter does not share any customer Personal Information with any third party other than those business partners which are directly involved in managing our day to day business operations, such as, without limitation, our billing and payment processes.”
In Site Meter’s detailed comment response to Eric (hey Eric Otom, the code that turns my cursor into crosshairs isn’t cute it’s annoying) they also indicate that in order to provide the comprehensive stats they offer they require the specificclick cookie that has caused Eric, Todd Cochrane, Davis Freeberg and several others to remove Site Meter from their blogs.
Debbie makes some good points that Site Meter should have sent their customers an email before they started planting third party cookies. Site Meter competitor Statcounter says they were offered money to plant the (same?) cookie and said no.
Though I like third party stats primarily for advertiser and reader transparency — if I say we did X number of visitors, readers can go to a page and verify — I have no problem showing Site Meter (or any other service this site is using) the door if the service starts slowing the site down or doing anything unethical. The Site Meter service has been sketchy lately since they upgraded the features and we have been thinking about removing them anyway.
As for the unethical part? What little information I’ve gleaned about Specific Click thus far (website is 404, that’s not good) hasn’t proved as damaging as them being proven true “spyware.” A lot of people throw around the word ’spyware’ too easily these days. It’s like yelling fire in a movie theater for netizens.
I’m digging but haven’t found anything unethical about Specific Click yet and being that it’s been a little while, has anybody else? NetWizard inspected the Site Meter code and shows the calls back specificclick.net writing:
While this is not true spyware per se - there is not physical software installed, nevertheless it is a tracking cookie which is being installed without permission.
There it is again, it’s not spyware “per se.” Look, something is either spyware or not, there isn’t such a thing as almost spyware.
Let’s not forget that anti-spyware services profits (in a big way) from people buying into Fear, Uncertainty and Doubt and the one linked at the top of this post for specificclick is no different. Many of these services will give you a computer risk assessment and yet want $39.99 to get rid of anything. The services I’ve seen so far list the specific click cookie as “low risk” which seems like a reasonable threshold for a service that provides statistical information.
Beyond the fact that Site Meter didn’t use good judgement in properly notifying its customers they were doing this — and that alone is damning — where is the skullduggery with Specific Click?
While investigating this issue further and as an act of good faith to Hmm readers Site Meter has been removed until further notice. While on the topic, I’ve been thinking about removing Google Analytics too. In this day and age being able to advertise less third party JavaScript usage and faster loading pages is advantageous.
I’ve grown somewhat weary of third party JavaScript code impacting reader experience. Provide the tools to hook into an API and let’s do this stuff server side. Enough of all this third party Javascript baggage.
Did this post make you go hmm?
(2 votes, average: 5 out of 5)
Loading ...Maybe Related Posts (plugin generated)
- Newsgator and Google privacy concerns raised by Hmm reader
- Kanoodle leaves milk, pays affiliates for cookies
- Privacy Policy
- Privacy conscious search engine user: paranoia?
- Does Amazon data collection go too far?
- No cookie love for I Love Messenger
Hmm, I’m from GoStats and I’ve been following this issue closely. On one level, it seems that the cookie thing with sitemeter could have been handled better. On another level, what is happening here is in essence the same thing Google is doing with it’s advertising products. How thin is that line between marketing and spyware? Another large web stats company made a big fuss about the spyware (in fact emailed all of their members about it). In the process a huge buzz with some mis-information or even misleading ideas went out. Seemed more like a scare tactic than anything ethical.
GoStats doesn’t have any form of spyware, nor is there any cross marketing like this. But in response to your pessimism on third party javascript, I should mention that one case shouldn’t ruin your use of tools. (Google ads would be considered third-party javascript by the way. Chitika, Wordpress, are other javascripts your site uses).
Comment by Richard — May 27, 2007 @ 10:33 am PST
Richard - My point is it’s becoming too much on the whole (and yes that includes the advertising, but at least in those cases they pay some of the freight for the overall experience). It’s not one third party case that’s souring me on using third party JavaScript, it’s all of them collectively. It seems like everybody wants you to install some widget or gadget or gizmo on your site these days using third party javascript code. That’s got to stop or nobody’s sites will load very fast (some with sidebaritis don’t already).
As my second to last sentence above says, I’d much rather have the option to go server side with this stuff with an API to hook into. Those that offer that type of interaction will rise higher on our family of sites interest level.
Comment by TDavid — May 27, 2007 @ 10:52 am PST
TDavid, I see what you mean about the load times with many javascripts on one page, however: API or javascript, there will still be similar load times. In fact with many API calls, it is possible, even likely, that those API calls would slow down loading of the entire page in the same way - if not worse (reasons are based on how API uses resources). Not to mention that some widgets still need javascript code to run some browser side controls and add functionality.
That said, it is possible that the APIs could be done efficiently and load times are acceptable. Having an API would be a great solution for management of data if done/implemented right. Speed wouldn’t be a reason to use an API since many cases an extra back-and-forth server communication would be needed. (thereby APIs in general would be slightly slower than in-line javascripts)
Comment by Richard — May 27, 2007 @ 11:12 am PST
Richard - I understand that by using JavaScript it allows getting certain client-side data that isn’t available (my programming site has been on the web according to WHOIS longer than your gostats service), but this same data can be gotten through first party javascript code and eliminate the need to process this on a third party connection with every page load which is the way a lot of these programs work. Stat updates aren’t in real time in a lot of case anyway, they are still delayed at least a small amount of time.
As for individual page loads many times the client (surfer) doesn’t understand the slowdown is coming from third party programs and blames the originating site. As I’m sure you know it can also come from pulling images, not just scripts, from slow servers. We try to eliminate that here by reducing the amount of third party images pulled in. Yes, it’s possible if it’s a popular image from a third party location it has already been cached by the third party server, that’s one pro to hosting images from a popular third party server.
You really can’t make general statements like “thereby APIs in general would be slightly slower than in-line javascripts” unless it’s done on a case by case basis. I’d say more often than not it can be made significantly faster not using third party programs to get the same information. The only major reason third parties want to have the information come to them is control and supposed “convenience” to the webmaster. It often has very little to do with efficiency of code. I’m not saying never, but very, very rarely. It’s common sense that if you can cut down the frequency of trips to exchange information it will be more efficient.
A lot of the slowdown I’m talking about is with the third party servers getting pounded (so in the communication process the slowdown isn’t happening on the source end). With API calls we can minimize, collate and cache the data on our servers that are better balanced than some of these programs and widgets running on slipshot hardware or overburdened CPUs.
Obviously, I’m not talking about Google, nor likely Site Meter, who have some great facilities but some of these widget providers nobody has heard about aren’t even running on dedicated boxes. I’ve seen a few admit they were using virtual hosting.
I’m enjoying the conversation, but please stop trying to sandwich your site name into your name, just keep it Richard. People who are interested can follow your name to your site, there is no need to pile on the SEO
You’ll also skip needing to have us moderate the comment.
Comment by TDavid — May 27, 2007 @ 1:02 pm PST
oops “it has already been cached by the third party server”
meant to say “it has already been cached in the client’s browser from the third party server”
Comment by TDavid — May 27, 2007 @ 1:06 pm PST
TDavid - Using first party javascripts isn’t the same as an api. For any widget out there, you can change the reference for the external js file to a local copy on your server. An api would have your server send data to them, you’d wait for a response and then display some in-line text as the resulting widget. API will only save time over in-line javascript if you don’t display anything for your widget - or if the display is some simple cached object. A rare case at that. That’s really the basis for my statement: “thereby APIs in general would be slightly slower than in-line javascripts”.
Overall, let’s think about what cases will benefit from an API? Cases where we can cache the data? Which widgets will benefit from that? Non-real-time, widgets that may not need to be always “fresh”. In widgets which display something this will work fine, but most widgets are widgets because they display something that updates quickly or customizes itself to the user. Overall, the static widgets fit the API model. We might be missing some ease of installation with an api, but for experienced users, the api will work fine for specific in-only data solutions.
Yeah, it is a great thread we have going here. To address the name for my comments, I actually switched to RFG because people told me that they didn’t have enough full disclosure about who I represent. (Yes, I know I even had the url of my site too) The ‘richard from gostats’ is basically the best way I found to properly address the name field question. I wouldn’t say that there is an seo benefit there. Who searches for that phrase anyway?
I’m sure you can imagine some seo motivated phrases.
Yeah, it looks like you’ve got me by a few months in the WHOIS data age
Don’t worry, GoStats isn’t my first web project. 
Comment by Richard — May 27, 2007 @ 1:45 pm PST
Richard I understand using first party Javascripts isn’t the same as an API
Sheesh, give me some credit 
Perhaps you aren’t understanding the situation I’m describing. This is a question only and not intended to be disrespectful, but are you one of the programmers behind your service too?
“Overall, let’s think about what cases will benefit from an API?”
I was telling the VP of Quantcast a little while back that stats programs like his and yours would benefit from offering an API model in addition to the JavaScript for webmasters who would prefer to package and send along the data and let you sort it out.
The advertiser transparency angle is the downside but then you could still load an external javascript after the page load and compare against the data served through a single (larger) POST than a bunch of GET with every visit to catch webmasters fudging the numbers.
Again, the main point of javascript has little to nothing to do with efficiency because I can group the data server side and run some backend process to pass off the data whenever and where ever I want — shielding the visitor from the hit by hit by hit cycle. It can still be collected in real time on my server and passed along to an update widget or even a static image that is refreshed every minute or less.
What people call “real time” these days can be a bit misleading as to the frequency of publishing that data, particularly with all the server gymnastics happening. If a stats widget is updated once every 1-5 minutes that is good enough for the vast majority of webmasters/publishers out there.
The data can and should still be collected in real time, but we’ll have to agree to disagree if you think that should be happening in a Javascript call versus server side (with Javascript after page load execution to capture the other details that can only be grabbed through JS). This doesn’t even address the fundamental flaws with an all-JavaScript model. What about users who turn off Javascript in the browser or non-JavaScript browers? They aren’t being counted in an all-Javascript model. There are also the bot scrubbing algos which is whole other kettle of fish.
Let’s be realistic about the number of widgets that really, truly need to be updated with every single page hit. The answer is very few. Take a MLB scores widget. Even if it’s pitch by pitch, there is a delay as the pitcher goes off the mound, uses the rosin bag. This site could have a dozen hits before that next update and this isn’t even our most busiest sites — a dozen hits to say: nothing has changed. A movie times widget doesn’t need to check back to the server only but once a week when new movies are announced but I’ve seen some that check back several times a day. There is a lot of waste happening with widgets executing calls back and forth to servers when they don’t need the frequency they are using. That’s my point here and it’s coming from an architecture standpoint.
The major benefits third party stats services like yours provide is to advertisers and thus a secondary benefit to me so I can show advertisers a third party and presumably more neutral point of view. They can also just take a look at the server logs and get all the data they need without any lost hits to Javascript-less browsers and users.
Bottom line: I can get any piece of information about each visitor any third party site offers better, faster and more reliably directly from the surfer here at our sites. Webmasters don’t need any third party stats service as a middle layer, however they are there for convenience and advertiser transparency and/or in the case where people are using third party hosted sites to begin with and can’t run their own code.
Don’t get me wrong, I’m not saying third party stats services such as yours, Site Meter, Google Analytics don’t have value because they certainly do, but let’s not try to pretend that these services are using the most efficient model to gather stats with a completely JavaScript-only architecture. They’re not.
Comment by TDavid — May 27, 2007 @ 2:56 pm PST
As for the SEO benefit, are you truly suggesting nobody is going to search Google for that? I just did and the first result has you apologizing to somebody for their experience with one of the GS employees (ouch!).
Ahh, but I also learned you are (were?) the sales exec at B5. I’d say 24,000+ “calculated” Google results indicates the term is SEO friendly. You are selling advertising for them, eh?
Comment by TDavid — May 27, 2007 @ 3:14 pm PST
No I figured that you knew the difference between the api and in-line javascript, I rewrote that point to express my idea. I understand your situation just fine. I’m contrary on your point because I’ve worked with both systems. I’ve seen how running APIs on the front side can slow down the webserver. Think about it; your process stack increases dramatically while it waits for active connections to the api to close. I’m referring to only customized, dynamic real-time data. Any widget that you described: one that is not based on viewer/client attributes is best done as a simple image or iframe. An api for those would be overboard. When the functionality becomes more complex and is based on viewer attributes, web-page specifics, and/or updated in true real time, then javascript is likely the best option for the job. I think APIs have a specific need for only certain customized applications (almost anything that isn’t front-side & large install base). Further, you are right, APIs are not easy/simple enough for the average user to install without hassle.
I’m not convinced that the API can be more efficient than javascript.
An api would work like this: (arrows denote data flow)
[client] —> [web page] —> [web server] —> [ext. api server] —> [web server] —> [web page] —> [client]
Javascript method:
[client] —> [web page] —> [javascript] —> [ext. app. server] —> [client]
(not to mention that the client can (and often do) multi-thread the http/javascript requests)
Convenience, speed/efficiency, and specialization of applications are huge reasons for third party javascript. The complexity to setup and API system and it’s corresponding drawbacks vs js don’t really make the benefit you described worth it for the majority of sites.
Regarding the SEO: Ask yourself why you searched for Richard from GoStats? I bet you wouldn’t have done that if I simply signed Richard. Right? Yeah, it makes sense that the results would contain other posts I’ve replied to. Do you think that it isn’t relevant that I sign my name that way? (do you think it’s spammy? why?) If you were given the job to organize the web (like google does), would it make your job easier if I signed Richard or ‘Richard from GoStats’?
-I would not recommend you compare the value of search phrase by the number of results it returns. By that measure you are doing me a favor since “Richard” alone returns 10x the results. …And I’m pretty sure you are the only one searching “Richard from GoStats” today.
Comment by Richard — May 27, 2007 @ 9:40 pm PST
Richard - Please provide some specific examples of “customized, dynamic real-time data” where you honestly have benchmarked the difference between using an API the way I’ve described versus running a third party Javascript model.
And your model is flawed (wrong order logically and not as I’ve described above either) when you are seeding the user with update intervals and not contacting the API with every page hit — re-read what I wrote carefully and you’ll see me say several times that you don’t do this with every page hit (hit the API). Most APIs have daily limits for number of calls anyway. First, let’s look at what’s wrong with your 7 step model:
7 steps as described by you
[client] —> [web page] —> [web server] —> [ext. api server] —> [web server] —> [web page] —> [client]
would actually look like this (web server contacted before the web page is processed by the web server):
3 steps
A. [client] -> [web server] -> [web page]
The web server (in step 2) could hand off the hit data to another program on the server that decides every X number of hits or at a designated interval to make the remote webserver call using the data collected by A for B:
3 steps
B. [web server] -> [web server] - [ext. api server response: XML, JSON, etc] -> [web server] (saved for operation A to dynamically load)
And you completely ignored these points:
1) my question whether or not you are a programmer at Gostats
2) my point about JavaScript being flawed when the user doesn’t have Javascript enabled which is a huge disadvantage in reliability.
3) the fact that lost stats occur when people stop page loading (and thus the Javascript call never executes)
With a server side architecture you don’t have #2 or #3 problem. As soon as there is a connection, you’ve got the data you need to track. Also if there is a delay or bottleneck in the data flow process speaking to the third party API server, it is kept separate from the surfer. They will not be exposed to the slowdown, all they would see is data not being refreshed as output on the webpage at the designated interval.
The model I described is still running and collecting real time stats, it’s just not providing real time updates to the web page visitor. In the case of a counter being updated, it’s possible to increment a counter from a last known position server side and still show the web visitor a correct count without needing to contact an API. To the visitor they see a counter iterating which could all happen in my 3 step process.
Perhaps the closest visual representation of true real time stats I’ve seen with a stats program that shows much more than a simple counter iterating would be Visitor Ville which will show a Google bus dropping off in 3D visitors to your site in “real time” — but even in that case there is a delay while the animation is moving. That delay, however small, is likely doing exactly what I described above: processing things on the backend where it should be rather than trying to make the web visitor wait.
There is always a delay of some sort processing the data on the backend the way it should be. That delay time can be very short and still work as I described above.
Comment by TDavid — May 28, 2007 @ 5:54 am PST
As for the SEO comments …
Having the extra “from GS” part does seem kind of spammy because we can easily see where you’re from with the link and you simply stating somewhere in the body of your first post in a non-spammy way (as you did above) who you are and what company you represent. Just as I was able to reference my programming site as relevant in our conversation without having to put ‘TDavid from …’ in my name.
However, as a significant number of VP, CEO, authors, owners, etc have left comments on this blog over the years it would be worthwhile to have a company/title field in the comments OR the option to create a profile, neither of which are currently in use here
I wonder though if by adding that field if people would put a bunch of junk in there, plus the more input fields the less likely someone is going to want to leave a comment which kind of defeats the purpose. We’ve recently started experimenting with the CAPTCHA below which I feel strains the process too. How do you feel bout this CAPTCHA, Richard? Has it been annoying having to answer those two words to prove you aren’t a bot or is it not that big of a deal? The refresh button will quickly provide an easier to read one if necessary. At least with this particular CAPTCHA there is a benefit to society.
I’m in favor of simplifying the conversation process rather than providing extra profile input fields in the comment form or expecting people to add titles or company names to their name. You know how it goes, Richard, if you have something that looks spammy or unmoderated it is a turn off of sorts to get involved. I’m interested in intelligent, on topic discussions from real people like we’ve been having above, not getting drive by comments from people who only want to pimp their stuff. You aren’t doing that and IMHO by adding the “from …” to your name kind of devalues your feedback and participation here. That’s all I’m saying, if that makes sense (?).
You do bring up an excellent point (thank you) that it would be nice if respected readers from companies such as yourself could link to a profile of themselves here at the site in a manner which would be dignified and professional and not turn people off. I suspect that functionality will be made available for those who (optionally) wish to fill out a profile at this site someday. Seems like a need has been developing
Comment by TDavid — May 28, 2007 @ 6:18 am PST
I see what you mean about caching the api data on the web server. I should say, you are right about case that more people wouldn’t mind a slight lag on the real-time display of the information. Assuming that’s all well and good it looks like a viable alternative. I should mention that some system which need display real-time customized data for each page view, would not benefit from the api (google ads for example). I can agree that most static or near static visible widgets can benefit from the api, with the exception of very simple ones (ones which are more suited to an in-line image or iframe).
Regarding your questions:
1) Sorry, I had thought I made is clear in the WHOIS discussion, that I am a programmer of GoStats. Although I’ve stepped away from the development side as of late, I still play a part in overseeing the role. (Yes, I also work at b5. You may have noticed that the post about me is very recent.)
2) The javascript flaw is very real. However, a vast majority of web users enable javascript, so for most purposes this isn’t a big issue. Also, additional data can be included in a -noscript- tag to get some data to the user.
3) The pageload-stop issue is also a possible problem. It would be interesting to see what the real difference is for the average site. I have a guess that it wouldn’t be very big. (assuming that the site in question isn’t of very low quality) You do have a point, depending on implementation or site structure, you could potentially lose some data.
Commenting with the “from gs” would be spammy if my post was a simple mindless statement, like: “nice site”, or “great post A+++”, etc. I think at present, giving commenters a way to attribute their thought-out responses is best served in the “from -company-” method. (not everyone is a mouse-over surfer) It would be great if we had a built in method to do that. I still don’t see spam or seo being a basis or part of the “from -company-” design. Would you look at it the same way if it was “Ted from Microsoft”? I think it would devalue the feedback if I stuffed the name field with keywords or a marketing tag-line, this is just a basic attribution.
The ReCAPTCHA doesn’t bother me. Now that I think about it; it would be more convenient to not captcha the moderated commenters. But I could see how that has abuse potential.
Hmmm, it might be good to get my typo on the fist line of my first comment: “I’ve be following ” -> “I’ve been following “
Comment by Richard — May 28, 2007 @ 11:54 am PST
RE: “The ReCAPTCHA doesn’t bother me. Now that I think about it; it would be more convenient to not captcha the moderated commenters.”
Good suggestion. I just went into the reCAPTCHA plugin and edited so it will only appear for those with less than *5* approved comments. You shouldn’t see it now in fact. Let me know if you’re experiencing otherwise.
Comment by TDavid — May 28, 2007 @ 12:52 pm PST
[…] back after this debacle. This is a serious flaw. Fortunately MakeYouGoHmm hasn’t used the Site Meter code since I learned of disturbing allegations on May 27, 2007, so IE7 browser users can view this site just […]
Pingback by Site Meter fails to allow page viewing in Internet Explorer 7 » Make You Go Hmm — August 2, 2008 @ 8:38 am PST