Raven and cookies

This is a slightly edited copy of a UCS News announcement, originally posted on 29 June 2012

---

The Raven privacy policy has recently been updated to comply with the changes to legislation on the use of cookies. But this is only half of the equation. Additional action is now required on the part of the maintainers of any server that uses the Raven service.

As a minimum we recommend that you review the way any websites you control or maintain use cookies with Raven, documenting the use of those cookies in a separate cookie policy or your existing privacy policy. You will also have to determine whether it is necessary for you to seek the informed consent for such cookies to be set on a per site basis.

The central Raven service now has an expanded section on cookies in its privacy policy, which is linked from the header of every page on the central Raven server and explicitly from the Raven login page. However, the Raven server cannot document authentication-related cookie used on every other server in the University. For that, individual server operators need to take action in relation to the contents of their websites. UCS encourages those sites which take advantage of Raven authentication to include a link to the Raven Privacy and Cookie policy hosted at https://raven.cam.ac.uk/privacy.html, but please note that creating such a link alone is insufficient for you to fully comply with recent changes to legislation.

Additionally, if you use the Apache module provided by the Computing Service for interacting with Raven over the Ucam-WebAuth protocol (mod_ucam_webauth), or the Apache Shibboleth module then you may find the information below helpful. If your server interacts with Raven in some other way, or you use other authentication software, then you may need to identify similar information yourself.

Further Information

UCS is not able to give legal advice on the use of cookies on individual websites. You may find the following resources useful:

The Information Commissioner's web site at:

http://www.ico.gov.uk/for_organisations/privacy_and_electronic_communications/the_guide/cookies.aspx

Recent guidance from the European advisory Article 29 Working Part guidance on Cookie Consent Exemptions at:

http://ec.europa.eu/justice/data-protection/article-29/documentation/opinion-recommendation/files/2012/wp194_en.pdf

mod-ucam-webauth cookie use

mod_ucam_webauth uses a single cookie to track the user's authentication state. This is a 'session' cookie which browsers should delete when the user quits. By default this is called 'Ucam-WebAuth-Session' (over http) or 'Ucam-WebAuth-Session-S' (over https) with path '/' and a scope of the host its set from, but the name, path and scope can all be configured in the Apache configuration file as needed (see the AACookieName, AACookiePath, and AACookieDomain configuration directives). This cookie contains:

Either

• the value 'Not-authenticated' during the early stages of the authentication process,

Or:

• A version number - currently always 1 (included for future expansion)
• A status code from the most recent authentication - '200' for 'success' following a successful authentication.
• An optional message explaining any error (empty following a successfully authentication)
• When the user most recently authenticated on this server
• When the user most recently interacted with this server (only maintained if an inactivity timeout is being used - see the AAInactiveTimeout directive)
• The length (in seconds) of the user's authentication session
• A unique ID issued by the Raven server for this authentication event
• The user's CrsID
• A record of how the user was authenticated by the Raven server - currently always 'pwd' for 'provided password' - and whether on this occasion they typed their password or relied on a previously-established identity
• A signature to prevent anyone tampering with the cookie value

Shibboleth Consortium Apache/IIS plugin cookie use

The Shibboleth Apache and IIS modules appear to use two session cookies, though this behaviour is explicitly not documented by the Shibboleth developers. Both of these cookies are set with path '/' and a scope of the host that sets them. They are 'session' cookies which browsers should delete when the user quits. These are:

• _shibstate_nnnnnnnn which is used to maintain limited information during the authentication process and which is activly deleted once this is complete, where 'nnnnnnnn' is a string of hexadecimal digits.

• _shibsession_nnnnnnnnnnnnnnnnnnnnnn which is used to record the user's authentication state, where 'nnnnnnnnnnnnnnnnnnnnnn' is a string of up to 97 hexadecimal digits.

At least some of the behaviour of these cookies can be influenced by the Shibboleth module's configuration.

Cookies used by the central Raven server

UCS believes that an exemption from obtaining explicit consent is applicable to the Raven server service relating to a users' use of Raven within a single browser session. Note that this exemption DOES NOT apply to persistent cookies that may be set by any user in their Raven account administration page at:

https://raven.cam.ac.uk/auth/account/change-options.html

Note that the default behaviour for Raven is to not use a persistent cookie. Persistent cookies are only set at the users' request, in doing so the user gives their consent for this and UCS has updated the Account Management interface to make this clear.