E-Authentication updated architecture - when did it happen

The E-Authentication project has updated the architecture as covered in my previous post E-Authentication has revised architecture to incorporate SAML V2.0. When i wrote the post I could not find a description of the updated architecture and the new interface specification. Today I found them and here I'll I have a quick look at the documents and the what's new.

The documents can be found by going to the E-Authentication start page and then choose Technical Architecture under FEDERATION block in the QUICK LINKS section in the right column. There are three documents:

• E-Authentication Federation Technical Approach (59 pages)
• E-Authentication Federation Adopted Scheme (40 pages)
• E-Authentication Federation Architecture Interface Specification (38 pages)

Time for update

I was curious to seen when it had been updated. The first document Technical Approach for the Authentication Service Component is versioned as 2.0.0 Final from May 4, 2007. A look at the document properties:

Shows that the PDF was created june 14, 2007 by Terry with the use of GPL Ghostscript. Open Source is certainly being used in government as well - Versions entitled GPL Ghostscript are distributed with the GNU General Public License, also note Ghostscript is a copyrighted work (artofcode LLC owns the copyright); it is not shareware or in the public domain.

The HTTP headers for the PDF document:

wget -S http://www.cio.gov/eauthentication/documents/TechnicalApproachForTheASC.pdf
--10:16:06--  http://www.cio.gov/eauthentication/documents/TechnicalApproachForTheASC.pdf
           => `TechnicalApproachForTheASC.pdf'
Resolving www.cio.gov... 159.142.134.71
Connecting to www.cio.gov|159.142.134.71|:80... connected.
HTTP request sent, awaiting response...
  HTTP/1.1 200 OK
  Server: Microsoft-IIS/5.0
  X-Powered-By: ASP.NET
  Date: Fri, 20 Jul 2007 08:26:49 GMT
  Content-Type: application/pdf
  Accept-Ranges: bytes
  Last-Modified: Mon, 16 Jul 2007 19:42:56 GMT
  ETag: "182d3482e1c7c71:179c"
  Content-Length: 1133852
Length: 1,133,852 (1.1M) [application/pdf]

Shows that it was last modified Mon, 16 Jul 2007, and the page carrying the links:

wget -S http://www.cio.gov/eauthentication/TechnicalArchitecture.htm
--10:15:28--  http://www.cio.gov/eauthentication/TechnicalArchitecture.htm
           => `TechnicalArchitecture.htm'
Resolving www.cio.gov... 159.142.134.71
Connecting to www.cio.gov|159.142.134.71|:80... connected.
HTTP request sent, awaiting response...
  HTTP/1.1 200 OK
  Server: Microsoft-IIS/5.0
  X-Powered-By: ASP.NET
  Date: Fri, 20 Jul 2007 08:26:11 GMT
  Content-Type: text/html
  Accept-Ranges: bytes
  Last-Modified: Mon, 16 Jul 2007 19:44:33 GMT
  ETag: "b8c292bbe1c7c71:179c"
  Content-Length: 2808
Length: 2,808 (2.7K) [text/html]

the same date but approximately two minutes later, so that probably was the publication time. But what about the july newsletter:

wget -S http://www.cio.gov/eauthentication/documents/FederationNewsletterJULY2007.pdf
--10:25:51--  http://www.cio.gov/eauthentication/documents/FederationNewsletterJULY2007.pdf
           => `FederationNewsletterJULY2007.pdf'
Resolving www.cio.gov... 159.142.134.71
Connecting to www.cio.gov|159.142.134.71|:80... connected.
HTTP request sent, awaiting response...
  HTTP/1.1 200 OK
  Server: Microsoft-IIS/5.0
  X-Powered-By: ASP.NET
  Date: Fri, 20 Jul 2007 08:36:34 GMT
  Content-Type: application/pdf
  Accept-Ranges: bytes
  Last-Modified: Thu, 19 Jul 2007 20:17:07 GMT
  ETag: "da8562c741cac71:179c"
  Content-Length: 199334
Length: 199,334 (195K) [application/pdf]

that was yesterday 19 Jul 2007 and the index page was updated five minutes later:

wget -S http://www.cio.gov/eauthentication/
--10:26:57--  http://www.cio.gov/eauthentication/
           => `index.html'
Resolving www.cio.gov... 159.142.134.71
Connecting to www.cio.gov|159.142.134.71|:80... connected.
HTTP request sent, awaiting response...
  HTTP/1.1 200 OK
  Server: Microsoft-IIS/5.0
  X-Powered-By: ASP.NET
  Content-Location: http://www.cio.gov/eauthentication/index.htm
  Date: Fri, 20 Jul 2007 08:37:39 GMT
  Content-Type: text/html
  Accept-Ranges: bytes
  Last-Modified: Thu, 19 Jul 2007 20:23:44 GMT
  ETag: "ece822b442cac71:179c"
  Content-Length: 14280
Length: 14,280 (14K) [text/html]

So by luck I found the news rather quickly (haven't found out where to sign up for the newletter yet).

Well kept secret

Why didn't I find the documents yesterday? Yes, i didn't follow the right navigation, but that aside the search engine at www.cio.gov doesn't impress me. A search for e-authentication from the http://www.cio.gov/ index page gives, let say not what I had expected. As a further sidenote it's kind of odd that the page with the links to the technical documents are set not to be indexed with:

<meta name="ROBOTS" content="NOINDEX">

The SAML V2.0 was announced in the March newsletter, so enough bitching and digging dates, what's the content? (to be followed)

E-Authentication has revised architecture to incorporate SAML V2.0

The E-Authentication Federation Newsletter for July brings the happy news New Architecture Approved: SAML 2.0 is Ready for Business.

The architecture has been revised to incorporate SAML V2.0 and adds an additional adopted scheme and interface specification. It sounds like the existing interfaces (and schemes) will be kept, but if the architecture is truly changed then these will have to be updated or otherwise the architecture must have been widened to embrace both the current and an SAML V2.0'ish version.

Considering that the previous interface specifications are defined on earlier versions of SAML and that SAML v2.0 was approved as an OASIS Standard since March 2005 and basic interoperability was proven at the RSA conference the same year, it's about time. There has obviously been put a lot of time and energy into the work leading to the new SAML V2.0 interface specifications:

The process to revise the architecture was rigorous. The E-Authentication PMO conducted an interoperability event in the Interoperability Lab to determine the capability of various vendors to comply with the SAML 2.0 specification. The E-Authentication PMO also talked with agencies to identify which features were necessary, as well as other features that would be most valuable to them. Working on behalf of the agencies, the EAuthentication PMO discussed the Government’s prioritized requirements with the vendors so they could include those features in their products, resulting in better product capabilities available to agencies. The vendors then participated in another interoperability event to demonstrate their products’ capabilities, their ability to meet the Government’s requirements, and their ability to interoperate with other vendors’ products.

Eager to get some deeper insight into the revised architecture I navigated and searched the E-Authentication website for the new SAML V2.0 interface specifications without any luck, to come back the next day and find it under The E-Authentication Technical Architecture. The next phase to prepare actual implementation has begun:

A tiger team within the Technical Working Group is now addressing the issues associated with migrating agencies and CSPs to the new architecture.

An analysis of a P3P compact policy example

Since 6.0 IE has been aware of P3P policies in deciding whether to accept third party cookies or not. This is a quick look at P3P, based on an example.

The Platform for Privacy Preferences (P3P) Project homepage gives the purpose as:

The Platform for Privacy Preferences Project (P3P) enables Websites to express their privacy practices in a standard format that can be retrieved automatically and interpreted easily by user agents. P3P user agents will allow users to be informed of site practices (in both machine- and human-readable formats) and to automate decision-making based on these practices when appropriate. Thus users need not read the privacy policies at every site they visit.

What strikes as a bad smell is that the P3P Work has been suspended, in the process of creating version 1.1. I think there could be three reasons for that:

• The work is done, it hit spot on and conquered the world
• The former version
• It's a dead end and it's not attracting any attention

It's not clear to me exactly what's the case here. It states The P3P Specification Working Group took this step as there was insufficient support from current Browser implementers for the implementation of P3P 1.1.. This is a fair argument but still does uease me slightly since privacy is on the rise.

I'll go for the The Platform for Privacy Preferences 1.0 (P3P1.0) Specification, since the group note is not for me until I realize that everybody is following it. Since I'm not implementing P3P (yet) this seems like the one for me, though a clear primer probably would have been best. I usually don't read a spec from end to end, but instead take some examples and follow those into the spec, sort of attacking it from the side based on a search for specific information.

The example

In FDIM and third party cookies I discovered the geminus host ndk.hit.gemius.pl has a compact P3P policy that contains P3P: CP="NOI DSP COR NID PSAo OUR IND", so what does that code mean?

This way of showing the policy is defined in 2.2.2 HTTP Headers. This is a case of compact-policy-field defined in 4. Compact Policies. This leaves the real meat to be NOI DSP COR NID PSAo OUR IND.

NOI is described in 4.2.1 Compact ACCESS and stands for <nonident/>, but that's just a reference to the full policy for 3.2.5 The ACCESS element, and it means Web site does not collect identified data.

DSP means there are some DISPUTES (4.2.2 Compact DISPUTES), which is really defined in 3.2.6 The DISPUTES element, described by:

A policy SHOULD contain a DISPUTES-GROUP element, which contains one or more DISPUTES elements. These elements describe dispute resolution procedures that may be followed for disputes about a services' privacy practices.

The index page for the host just delivers an empty HTML structure, so here's no reference to the full policy, but following the well know location /w3c/p3p.xml that contains:

<?xml version="1.0" encoding="UTF-8" ?>
<META>
   <POLICY-REFERENCES>
      <POLICY-REF about="/w3c/policy.xml">
         <INCLUDE>/*</INCLUDE>
         <COOKIE-INCLUDE>* * * </COOKIE-INCLUDE>
      </POLICY-REF>
   </POLICY-REFERENCES>
</META>

That's a policy reference to the real privacy policy. The DISPUTES links to the service, the company website. I'm not sure what's best practice here, but I did expect something more specific though this usage is quite abstract to me, and I guess no agents will read it any way.

COR stands for <correct> in 4.2.3 Compact REMEDIES. The real definition is in 3.2.7 The REMEDIES element and has the promised description Errors or wrongful actions arising in connection with the privacy policy will be remedied by the service. There's also the possiblity to use the <money/> as a common use case will involve an economic limit.

NID stands for <NON-IDENTIFIABLE> in 4.2.4 Compact NON-IDENTIFIABLE.In 3.3.3 The NON-IDENTIFIABLE element it's described as:

This element signifies that either no data is collected (including Web logs), or that the organization collecting the data will anonymize the data referenced in the enclosing STATEMENT. In order to consider the data "anonymized", there must be no reasonable way for the entity or a third party to attach the collected data to the identity of a natural person. Some types of data are inherently anonymous, such as randomly-generated session IDs. Data which might identify natural people in some circumstances, such as IP addresses, names, or addresses, must have a non-reversible transformation applied in order be considered "anonymized".

PSAo is described in 4.2.5 Compact PURPOSE where the PSA stands for <pseudo-analysis/> and o stands for opt-out. The full description is in 3.3.4 The PURPOSE element:

Pseudonymous Analysis: Information may be used to create or build a record of a particular individual or computer that is tied to a pseudonymous identifier, without tying identified data (such as name, address, phone number, or email address) to the record. This profile will be used to determine the habits, interests, or other characteristics of individuals for purpose of research, analysis and reporting, but it will not be used to attempt to identify specific individuals. For example, a marketer may wish to understand the interests of visitors to different portions of a Web site.

and opt-out means:

Data may be used for this purpose unless the user requests that it not be used in this way. When this value is selected, the service MUST provide clear instructions to users on how to opt-out of this purpose at the opturi. Services SHOULD also provide these instructions or a pointer to these instructions at the point of data collection.

OUR stands for <ours/> 4.2.6 Compact RECIPIENT. 3.3.5 The RECIPIENT element where it's described:

Ourselves and/or entities acting as our agents or entities for whom we are acting as an agent: An agent in this instance is defined as a third party that processes data only on behalf of the service provider for the completion of the stated purposes. (e.g., the service provider and its printing bureau which prints address labels and does nothing further with the information.)

The last one is IND stands for <indefinitely/> in 4.2.7 Compact RETENTION. That's described in 3.3.6 The RETENTION element:

Information is retained for an indeterminate period of time. The absence of a retention policy would be reflected under this option. Where the recipient is a public fora, this is the appropriate retention policy.

An easy overview for compact policies can be found on the p3pwriter website.

A second and deeper look at the Google Analytics Urchin Module

I first had A quick look at the Google Analytics Urchin Module and then what give cookiewise for a user in Party cookie - GA a virtual first party. In this post I'll go deeper into this by monitoring the HTTP headers (including Cookies) by using ngrep.

For this example I'll use the minimal post The Firefox is a Panda!. First I request the page, giving the following HTTP headers:

T <my.local.ip.number>:44675 -> 72.14.207.121:80 [AP]
GET /2007/03/firefox-is-panda.html HTTP/1.1.
Host: blog.sweetxml.org.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.8.1.2) Gecko/20070312 Firefox/2.0.0.2.
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5.
Accept-Language: da,en;q=0.7,en-us;q=0.3.
Accept-Encoding: gzip,deflate.
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7.
Keep-Alive: 300.
Connection: keep-alive.
If-Modified-Since: Mon, 16 Jul 2007 08:05:35 GMT.
If-None-Match: "30e8cd45-16a1-4d71-9221-725b96401ca5".

And the response, which shows that my browser has a valid copy in cache:

T 72.14.207.121:80 -> <my.local.ip.number>:44675 [AP]
HTTP/1.1 304 Not Modified.
Last-Modified: Mon, 16 Jul 2007 08:05:35 GMT.
Cache-Control: max-age=0 private.
ETag: "30e8cd45-16a1-4d71-9221-725b96401ca5".
Content-Length: 0.
Date: Mon, 16 Jul 2007 21:20:18 GMT.
Server: GFE/1.3.

Then comes a request for a dynamic CSS-file, which for some reason contains all the cookies for both GA and blogger.com, maybe because of the CNAME record.

T <my.local.ip.number>:37235 -> 72.14.207.191:80 [AP]
GET /dyn-css/authorization.css?blogID=591744930960839717 HTTP/1.1.
Host: www2.blogger.com.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.8.1.2) Gecko/20070312 Firefox/2.0.0.2.
Accept: text/css,*/*;q=0.1.
Accept-Language: da,en;q=0.7,en-us;q=0.3.
Accept-Encoding: gzip,deflate.
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7.
Keep-Alive: 300.
Connection: keep-alive.
Referer: http://blog.sweetxml.org/2007/03/firefox-is-panda.html.
Cookie: __utma=150635877.801410967.1184268448.1184496074.1184570589.11; __utmz=150635877.1184570589.11.5.utmccn=(referral)|utmcsr=www2.blogger.com|utmcct=/navbar.g|utmcmd=referral; __utmz=238348806.1184442198.162.32.utmccn=(referral)|utmcsr=blog.sweetxml.org|utmcct=/2007/07/fdim-and-third-party-cookies.html|utmcmd=referral; __utma=238348806.2055646945.1171363119.1184356396.1184442198.162.
If-Modified-Since: Mon, 16 Jul 2007 21:12:21 GMT.

And the response comes gzip'ed with a new cookie for .blogger.com:

T 72.14.207.191:80 -> <my.local.ip.number>:37235 [AP]
HTTP/1.1 200 OK.
Content-Type: text/css; charset=UTF-8.
Cache-Control: max-age=1800 private.
Pragma: no-cache.
Last-Modified: Mon, 16 Jul 2007 21:20:19 GMT.
Transfer-Encoding: chunked.
Set-Cookie: S=blogger=uttzz-o7dCskolJlCyOmeQ; Domain=.blogger.com; Path=/.
Content-Encoding: gzip.
Date: Mon, 16 Jul 2007 21:20:19 GMT.
Server: GFE/1.3.

Next is the request for navbar (classicly in an iframe, but in my template in an object. Once more all the cookies comes along

T <my.local.ip.number>:37235 -> 72.14.207.191:80 [AP]
GET /navbar.g?targetBlogID=591744930960839717&blogName=Sweetxml&publishMode=PUBLISH_MODE_HOSTED&navbarType=SILVER&layoutType=LAYOUTS&homepageUrl=http%3A%2F%2Fblog.sweetxml.org%2Findex.html&searchRoot=http%3A%2F%2Fblog.sweetxml.org%2Fsearch HTTP/1.1.
Host: www2.blogger.com.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.8.1.2) Gecko/20070312 Firefox/2.0.0.2.
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5.
Accept-Language: da,en;q=0.7,en-us;q=0.3.
Accept-Encoding: gzip,deflate.
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7.
Keep-Alive: 300.
Connection: keep-alive.
Referer: http://blog.sweetxml.org/2007/03/firefox-is-panda.html.
Cookie: __utma=150635877.801410967.1184268448.1184496074.1184570589.11; __utmz=150635877.1184570589.11.5.utmccn=(referral)|utmcsr=www2.blogger.com|utmcct=/navbar.g|utmcmd=referral; __utmz=238348806.1184442198.162.32.utmccn=(referral)|utmcsr=blog.sweetxml.org|utmcct=/2007/07/fdim-and-third-party-cookies.html|utmcmd=referral; __utma=238348806.2055646945.1171363119.1184356396.1184442198.162; S=blogger=uttzz-o7dCskolJlCyOmeQ.

The navbar response:

T 72.14.207.191:80 -> <my.local.ip.number>:37235 [AP]
HTTP/1.1 200 OK.
Content-Type: text/html; charset=UTF-8.
Cache-Control: private, no-cache, proxy-revalidate.
Pragma: no-cache.
Transfer-Encoding: chunked.
Content-Encoding: gzip.
Date: Mon, 16 Jul 2007 21:20:22 GMT.
Server: GFE/1.3.

Next an, to me,unknown POST (must be default javascript?)

T <my.local.ip.number>:44675 -> 72.14.207.121:80 [AP]
POST /2007/03/firefox-is-panda.html HTTP/1.1.
Host: blog.sweetxml.org.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.8.1.2) Gecko/20070312 Firefox/2.0.0.2.
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5.
Accept-Language: da,en;q=0.7,en-us;q=0.3.
Accept-Encoding: gzip,deflate.
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7.
Keep-Alive: 300.
Connection: keep-alive.
Content-Type: application/x-www-form-urlencoded.
Referer: http://blog.sweetxml.org/2007/03/firefox-is-panda.html.
Content-Length: 90.
Cookie: __utma=114544340.2000377505.1184620823.1184620823.1184620823.1; __utmb=114544340; __utmc=114544340; __utmz=114544340.1184620823.1.1.utmccn=(direct)|utmcsr=(direct)|utmcmd=(none).
Pragma: no-cache.
Cache-Control: no-cache.

Now finally the GA backend call that sync's the cookie values:

T <my.local.ip.number>:44208 -> 64.233.183.104:80 [AP]
GET /__utm.gif?utmwv=1&utmn=2000377505&utmcs=UTF-8&utmsr=1280x1024&utmsc=24-bit&utmul=de-de&utmje=1&utmfl=9.0%20r48&utmcn=1&utmdt=Sweetxml%3A%20The%20Firefox%20is%20a%20Panda!&utmhn=blog.sweetxml.org&utmr=-&utmp=/2007/03/firefox-is-panda.html&utmac=UA-1555577-1&utmcc=__utma%3D114544340.2000377505.1184620823.1184620823.1184620823.1%3B%2B__utmb%3D114544340%3B%2B__utmc%3D114544340%3B%2B__utmz%3D114544340.1184620823.1.1.utmccn%3D(direct)%7Cutmcsr%3D(direct)%7Cutmcmd%3D(none)%3B%2B HTTP/1.1.
Host: www.google-analytics.com.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.8.1.2) Gecko/20070312 Firefox/2.0.0.2.
Accept: image/png,*/*;q=0.5.
Accept-Language: da,en;q=0.7,en-us;q=0.3.
Accept-Encoding: gzip,deflate.
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7.
Keep-Alive: 300.
Connection: keep-alive.
Referer: http://blog.sweetxml.org/2007/03/firefox-is-panda.html.

This is a so called web bug. The parameters are:

• utmwv=1
• utmn=2000377505
• utmcs=UTF-8
• utmsr=1280x1024
• utmsc=24-bit
• utmul=de-de
• utmje=1
• utmfl=9.0%20r48
• utmcn=1
• utmdt=Sweetxml%3A%20The%20Firefox%20is%20a%20Panda!
• utmhn=blog.sweetxml.org
• utmr=-
• utmp=/2007/03/firefox-is-panda.html
• utmac=UA-1555577-1
• utmcc=__utma%3D114544340.2000377505.1184620823.1184620823.1184620823.1%3B%2B__utmb%3D114544340%3B%2B__utmc%3D114544340%3B%2B__utmz%3D114544340.1184620823.1.1.utmccn%3D(direct)%7Cutmcsr%3D(direct)%7Cutmcmd%3D(none)%3B%2B

With the used URL encoding:

• %2b -> '+'
• %3a -> ':'
• %3b -> ';'
• %3d -> '='
• %7C -> '|'

So the last parameter can be further divided into:

• __utma=114544340.2000377505.1184620823.1184620823.1184620823.1;+
• __utmb=114544340;+
• __utmc=114544340;+
• __utmz=114544340.1184620823.1.1.utmccn=(direct)|utmcsr=(direct)|utmcmd=(none);+

The GA response (a GIF-image):

T 64.233.183.104:80 -> <my.local.ip.number>:44208 [AP]
HTTP/1.1 200 OK.
Pragma: no-cache.
Cache-Control: private, no-cache, no-cache="Set-Cookie", proxy-revalidate.
Expires: Fri, 04 Aug 1978 12:00:00 GMT.
Content-Type: image/gif.
Last-Modified: Mon, 18 Jun 2007 23:10:08 GMT.
Server: ucfe.
Content-Length: 35.
Date: Mon, 16 Jul 2007 21:20:28 GMT.

The next part came out through ngrep, but I can't figure out why i looks different, and doesn't have a GET and other headers:

T <my.local.ip.number>:44675 -> 72.14.207.121:80 [AP]
action=backlinks&widgetId=Blog1&widgetType=Blog&responseType=js&postID=1676954542643567733

And the response is some javascript

T 72.14.207.121:80 -> <my.local.ip.number>:44675 [AP]
HTTP/1.1 200 OK.
Content-Type: text/javascript; charset=UTF-8.
Cache-control: private.
Transfer-Encoding: chunked.
Content-Encoding: gzip.
Date: Mon, 16 Jul 2007 21:20:28 GMT.
Server: GFE/1.3.

That was it, so the cookies that's set by the JavaScript is sync'ed by means of an GET to an GIF-image with the values in the query string. This has a certain resemblance with the fallback method for the Gallup system with an image request in the <noscript> section.

FDIM and third party cookies

The Association of Danish Internet Medias (FDIM) which is responsible for a Danish Internet traffic and audience measurement system. There's a short info page on FDIM in english.

The current tracking system is about to be phased out and replaced by a new one. Both systems are enabled on the info page. The first one from Gallup is inserted like:

<script type="text/javascript">
<!--
var tmsec = new Array ('tmsec=fdim');
getTMqs('http', '', '', 'fdim_dk', 'dk', 'ISO-8859-15', tmsec);
//-->
</script>
<noscript>
  <img src="http://statistik-gallup.net/V11***fdim_dk/dk/ISO-8859-15/tmsec=fdim/">
</noscript>

This uses a classic third part cookie to the domain statistik-gallup.net. Since this system is be phased out I'll no go deeper into that.

The new audience measurement setup with Gemius Audience:

<!-- (C)2000-2006 Gemius SA - gemiusAudience / fdim.dk / Main Page -->
<script type="text/javascript">
var pp_gemius_identifier = new String('zNrq9nyrPxWCP8HNpip1JsQKjzMy_1tV8XABkQa9y_j.A7');
</script>
<script type="text/javascript" src="http://www.fdim.dk/xgemius.js"></script>

Where the JavaScript file is a very simple 70 liner (compared to the GA which is more that 10 fold larger):

    1 // (c) 2000-2007 by Gemius SA
    2 
    3 function gemius_parameters() {
    4   var d=document;
    5   var href=new String(d.location.href);
    6   var ref;
    7   if (d.referrer) { ref = new String(d.referrer); } else { ref = ""; }
    8   var t=typeof Error;
    9   if(t!='undefined') {
   10     eval("try { if (typeof(top.document.referrer)=='string') { ref = top.document.referrer } } catch(gemius_ex) { }")
   11   }
   12   var url='&tz='+(new Date()).getTimezoneOffset()+'&href='+escape(href.substring(0,299))+'&ref='+escape(ref.substring(0,299));
   13   if (screen) {
   14     var s=screen;
   15     if (s.width) url+='&screen='+s.width+'x'+s.height;
   16     if (s.colorDepth) url+='&col='+s.colorDepth;
   17   }
   18   return url;
   19 }
   20 
   21 function gemius_append_script(xp_url) {
   22   if(typeof Error !='undefined') {
   23     eval("try { xp_javascript = document.createElement('script'); xp_javascript.src = xp_url; xp_javascript.type = 'text/javascript'; xp_javascript.defer = true; document.body.appendChild(xp_javascript); } catch(exception) { }");
   24   }
   25 }
   26 
   27 function gemius_load_script() {
   28   if (window.pp_gemius_image.width && window.pp_gemius_image.width>1) {
   29     gemius_append_script(window.pp_gemius_script);
   30   }
   31   if (document.location && document.location.protocol=='http:' && window.pp_gemius_image.height && window.pp_gemius_image.height>1) {
   32     gemius_append_script('http://ndk.hit.gemius.pl/nosb.js');
   33   }
   34 }
   35 
   36 if (typeof pp_gemius_identifier == 'undefined') {
   37   if (typeof gemius_identifier != 'undefined') {
   38     pp_gemius_identifier = gemius_identifier;
   39     gemius_identifier = 'USED_'+gemius_identifier;
   40   } else {
   41     pp_gemius_identifier = "";
   42   }
   43 }
   44 
   45 var gemius_proto;
   46 if(document.location && document.location.protocol) {
   47   gemius_proto = 'http'+((document.location.protocol=='https:')?'s':'')+':';
   48 } else {
   49   gemius_proto = 'http:';
   50 }
   51 var pp_gemius_host = gemius_proto+'//gadk.hit.gemius.pl/_'+(new Date()).getTime();
   52 
   53 if (typeof window.pp_gemius_image != 'undefined') {
   54   if (typeof window.pp_gemius_images == 'undefined') {
   55           window.pp_gemius_images = new Array();
   56   }
   57   var gemius_l = window.pp_gemius_images.length;
   58   window.pp_gemius_images[gemius_l]=new Image();
   59   window.pp_gemius_images[gemius_l].src = pp_gemius_host+'/redot.gif?id=ERR_'+pp_gemius_identifier+gemius_parameters();
   60 } else {
   61   if (window.attachEvent) {
   62     window.attachEvent("onload", gemius_load_script);
   63   } else if(window.addEventListener) {
   64     window.addEventListener("load", gemius_load_script, false);
   65   }
   66   window.pp_gemius_image = new Image();
   67   window.pp_gemius_image.src = pp_gemius_host+'/rexdot.gif?l=11&id='+pp_gemius_identifier+gemius_parameters();
   68   window.pp_gemius_script = pp_gemius_host+'/pp.js?id='+pp_gemius_identifier;
   69 }
   70 pp_gemius_identifier = 'USED_'+pp_gemius_identifier;
   71 

With meaningful names it is also much more readable than the GA - I can't tell if the feature set for GA is much larger than Gemius, since that could be an argument for the more complex JavaScript for GA.

A visit to the info page confronts me with five cookies:


A cookie from/to the specific host statistik-gallup.dk.

This is four domain cookies to .hit.gemius.pl (host ndk.hit.gemius.pl) which also uses third part cookies which potentially ruin some of the data quality, but they seem to be using P3P since a simple GET to http://ndk.hit.gemius.pl shows the usage of a compact P3P policy, which opens up for using third part cookies with IE (Firefox in general don't care):

wget -S http://ndk.hit.gemius.pl
--21:47:57--  http://ndk.hit.gemius.pl/
Resolving ndk.hit.gemius.pl... 81.19.234.252
Connecting to ndk.hit.gemius.pl|81.19.234.252|:80... connected.
HTTP request sent, awaiting response...
  HTTP/1.1 200 OK
  Date: Sat, 14 Jul 2007 19:47:57 GMT
  Expires: Sat, 14 Jul 2007 20:47:57 GMT
  Accept-Ranges: none
  Cache-Control: max-age=3600
  Last-Modified: Thu, 31 May 2007 08:34:54 GMT
  P3P: CP="NOI DSP COR NID PSAo OUR IND"
  Connection: close
  Content-Type: text/html;charset=utf-8
  Content-Length: 55
Length: 55 [text/html]

It's time to have a quick look at P3P.