In 2009 the European Commission issued an amendment to the 2003 E-Privacy Directive requiring consent for the storage of information on user devices. The British Government, and all other member states, passed this into law in 2011. Prior to the introduction of the new legislation the government made it clear that in the first year they would not be enforcing the new rules, allowing businesses time to prepare for the changes. This so called “amnesty period” comes to an end in May 2012.

In their latest guidance document, the British government’s information regulatory office, the Information Commissioner’s Office (ICO), offers detailed guidelines on how businesses might comply with the new regulation.

There follows a brief outline of the December 2011 guidelines.

Why now?

The legislation was prompted by concerns about online tracking and spyware i.e. information stored on users PC’s which is used to identify them without their knowledge.

What does it cover?

It covers cookies (both persistent and non-persistent), “Shared objects” (e.g. Flash Cookies and Silverlight Isolated Storage objects) and web bugs (e.g. information hidden in gif files).

Importantly it applies to any information about a user and not just Personally Identifiable Information (PII).

Consent

There are three classifications of consent. Understanding these is important in assessing any necessary compliance measures.

‘Assumed’ Prior

This describes the act of getting consent after a cookie has already been created. This is not how consent normally works and is likely to confuse users. In the case of older web sites the ICO suggests that this will be acceptable provided there is a prominently displayed “About Cookies” in the sites header area, and site owners show that they’ve made some effort to reduce the intrusiveness and life time of such cookies.¹

Implied

Where it is assumed the user knows that cookies are being used. In the future when browsers allow users to configure their preferences this will constitute “implied consent”. However browser based opt-in strategies are not widely supported at present. In fact the success of these future opt-in strategies is, in part, dependent upon the current generation of web sites educating users about cookies.

User/Subscriber

This describes issues around services a user or subscriber³ has signed up for, and which require cookies to work correctly. Incidentally, no distinction is made between the user/subscriber parties as far as consent goes. It is an interesting distinction though, and is intended to distinguish a business user acting on behalf of a business, and home user acting on behalf of themselves.

The recommended approach for existing web sites is to make information about cookies clearly visible, along with options to disable them (along with a warning of the implications of doing so).⁴ For new build web sites, consent will need to be gained prior to setting any cookies. This might take the form of a check box clearly labelled on the T’s & C’s screen for example.

Cookie Types

There are a few different categories of cookie, each presenting its own particular challenges.

Session Cookies

These are used to overcome the stateless nature of the HTTP protocol in tracking a user’s interactions with a web site during each visit. They exist only as long as a user is viewing a web site and are removed when the browser hosting the session is closed. For this reason they are viewed as less intrusive and if used simply to support the sites functionality are deemed to be exempt from a requirement to gain consent.⁵

Making users aware, with very prominent links to information about such cookies, is the advised approach to maintaining compliance.²

Persistent Cookies

These are cookies persisted between sessions. They can be shared across several sites and can be used to target advertising, or to record visitors preferences, or for analytical purposes. These types of cookies do require consent.

First and Third Party Cookies

First party cookies are those placed by web site the user is visiting (i.e. the “originating domain”) while third party cookies are placed by the web site on behalf of a domain not being visited by the user. For example if I visit www.ebay.co.uk and it places a cookie to record my user preferences this is a first party cookie, and if eBay then places a cookie on behalf of an analytics service, say analytics.google.com, this cookie is a “third party cookie”.

If a site is using third party cookies, the ICO recommend that the site owners have a contractual agreement with this third party governing their cookies behaviour.⁶

What Should You Do Now?

Doing nothing is not an option and is likely to bring the site owner into conflict with the law.⁷

The ICO recommends taking the following steps:

• Perform an audit of cookies being used i.e. identify cookies and their purpose, the data they hold, any links to (PII) data, their life time, their originating domain, and check existing privacy policy
• Assess how intrusive they are
• Where consent is deemed necessary decide how it might be obtained

The IOC guidance document then goes on to advise on a number of practical ways to acquire consent. These are mostly common sense but the more interesting are:

• In the case of Services being offered consent could be part of the T’s and C’s
• If the site has a user setup it could be obtained as a step in the setup process
• If the site offers features that require 3^rd party cookies enabling such feature might require consenting to cookies

Further Reading

See the ICO guidelines here.

For information about cookies in general the “All About Cookies” web site is hard to beat. It is located here.

¹ IOC Guidance on the rules on use of cookies and similar technologies [December 2011] p. 6

² as above p. 6-7

³ A subscriber is in the party which pays for the line (important in the case of a business) and a user is, well, a user.

⁴ as above p. 7

⁵ as above p. 8-10

⁶ as above p. 10

⁷ A fine of up to £500 000 is the maximum penalty the ICO can impose.

In mid 2011, ITW selected Magnolia as the CMS platform for the re-launch of their UK construction products website.  In parallel, they selected inRiver as their PIM (Product Information Management) platform for managing product data including product specification and configuration, spare parts and accessories, and pricing information.

In October 2011, ITW engaged Priocept to assist with the development of the Magnolia CMS platform and its integration with the inRiver PIM.  Priocept used its extensive knowledge of both Magnolia CMS, and the underlying Java Content Repository (JCR) platform, to assist ITW’s internal development team not only in the development of the new CMS based website, but also in defining an overall CMS and PIM solution architecture.  This architecture was designed to allow modelling of product data within a JCR content repository, and integration of Magnolia CMS with the inRiver PIM to allow transfer of data between the PIM and the CMS, in turn allowing publication of product data to the web using Magnolia CMS, while allowing the definitive product data to be managed within the core PIM system.

Priocept also worked on-site at ITW to assist their internal development team with the setup of the overall Magnolia CMS web development environment and build and deployment processes, ensuring that ITW’s internal development team were quickly up to speed and achieved productivity with a technology that was initially unfamiliar to them.

About Magnolia CMS

After its first release in 2003, Magnolia quickly became a leading content management solution for the Java platform. Due to its easy-to-use web interface and open standards such as JSR-170, it is being used in several thousand installations world-wide.

Priocept has been working with Magnolia since 2009 and we have been working with the Java Content Repository (JCR) platform that underpins Magnolia since 2007.

About inRiver PIM

inRiver PIM manages the creation, maintenance and distribution of product information.  This includes management of product inventories, product specifications, translation and management of multi-lingual content, versioning of product data and attributes, planning of product assortments, and management of product variations and interrelationships such as links between a main product and the accessories or spare parts available for that product.

For companies with a large number of product SKUs, and a complex product data model, the product cataloguing features available in a web-focussed e-commerce or CMS platform may not be adequate for managing the entire suite of product data.  In this scenario, deployment of a dedicated PIM platform which is then integrated with the web platform, will provide a best of breed solution for both the product management team and the web or online marketing team, without compromise in either area.

Contact Us

Please contact Priocept for more information on Magnolia CMS or assistance with the integration of CMS and PIM systems in general.

It is then easy to understand, that as a website owner you may occasionally want to make changes to your websites content, design or even entire structure. What you may not know is that by altering your site, whether it be:

• Tweaking your URLs (making them more appealing and easy to remember)
• Restructuring your web content
• Switching your CMS platform
• Changing your domain name

you place yourself in danger of adversely affecting the SEO equity of your site which often will have taken a long time and much investment to create.

It’s a sad fact that a very large number of website migrations result in a loss of Search Engine Result Page (SERP) rankings. If you were to consider that the site (www.mediarunsearch.co.uk) gains 64% of its traffic from the organic search engines positions, a slip in the rankings would be incredibly damaging for brand awareness and ultimately our business.

This is where SEO Migration comes in particularly useful. As a process it best works in 3 stages as described below.

Analysis

It is vital you know how your current (old) website works and how it’s being used. By understanding which pages are ranking highly in the SERPs, and which pages have high link equity, you can plan what is needed for each page to maintain or even improve their standings when launching a new site. This can be established by:

• Evaluating your traffic split and source
• Defining your high priority keywords
• Establishing what are the top landing pages
• Analysis and benchmark of existing link equity

Planning

Like anything planning is key. During a migration, the window of opportunity for a change round or alteration is like meeting someone famous off the TV. They’re generally shorter than you’d think! You have to make sure team members and developers know what they need to be working on and when and that someone is made responsible for this activity. Any lapse in time makes it more likely that your site’s rankings will be affected. So what specifically needs planning?

• Benchmarking rankings and traffic of your keywords
• Mapping URLs on a like for like basis
• Setting 301 rules
• Discovering and annotating high quality links

Implementation

Now that everyone knows what they’re doing and when, get stuck in! Given the strict time restrictions, you need to have someone leading the development team and ensuring everything is getting done on time. Checklist what you have planned and who is responsible. You are allowed to get a little flustered here. This is what we do to keep tempers at bay:

• Collaboration with web development teams
• Rolling 301s
• Cross checking HTTP status headers
• Optimise and repurpose links (simple 301s don’t cut it)
• Controlling and monitoring progress

By following these processes, you are able to have your cake and thoroughly enjoy it. You get the fresh, new site design that your users will like and you don’t throw away all the effort you invested in SEO.

This article was written by one of our guest bloggers, Mediarun, a leading SEO agency.

Drop us an email if you are attending the event and would like to discuss your project or support requirements.

The event runs from 8.30am to 5.30pm at the Tower Hotel, London, E1W 1LD. More information can be found at: http://www.sitecore.net/Events/TrendspotUK2012/

But Twitter also doesn’t have any concept of structured data or attachments associated with a tweet, which means that links have to be posted in the body of the tweet content. Aside from causing ugly looking content, this also causes a problem with long URLs that use up most of the 140 characters.

Twitter originally left the solution to this problem (shortening of links via an intermediary link) to third party services like http://tinyurl.com/ (and then http://bit.ly/ for those desperate to save another four characters).

However, more recently Twitter implemented its own link shortening service that converts all links to the form http://t.co/abcdefgh.  Twitter describes this new service as follows – “Twitter uses the t.co domain as part of a service to protect users from harmful activity, to provide value for the developer ecosystem, and as a quality signal for surfacing relevant, interesting Tweets.” – whatever that means.

Here’s why this t.co approach is completely broken:

1. First of all, link shortening is now not only automatic but is also enforced – you can no longer insert a link that is NOT shortened. This doesn’t make sense and Twitter’s rationale is weak, but by enforcing link shortening it just magnifies the impact of all the related issues that follow below.
2. “Shortened” links can actually get longer (“visit priocept.com” becomes “visit http://t.co/abcdefgh” which increases the link size from 12 to 20 characters!).  Twitter originally only implemented link shortening on links of 19 characters or longer.  But now they just “shorten” everything regardless.
3. Shortened links also means that references to brand names that look like web addresses get messed up and the brand name is lost, for example the tweet “I just checked out brandname.co.uk – great site” becomes “I just checked out http://t.co/abcdefgh – great site” which loses all its context and actually loses all value completely if you are offline and can’t click the link to find out where the link goes to. If you have a company name that ends in .com then you’ll have to put it in quotes every time or Twitter is going to strip your company name out!  Twitter claim that the original link will still be shown, but this doesn’t apply if you are viewing the tweet from a third-party application that doesn’t implement the “unshortening” process.
4. The reliance on the .co top level domain (assigned to the Republic of Colombia) is also very strange and unwise. Here we have a key piece of internet infrastructure used by millions and it relies on a domain run by Colombia? Who could presumably switch off the t.co service if they chose to?
5. Next there are the security implications of shortening links and hiding their ultimate destination. If I see a link to companyname.com, then I can take a view on whether I trust that company and wish to follow the link. But if I see http://t.co/abcdefgh then I have no knowledge of where I am going to end up and if it is a safe site to visit. So I have to fall back to trusting the tweeter who posted the link.
6. Next there is the issue of information loss with the use of t.co links. If I archive Twitter feeds, then there is a chance that in years to come when I look back at those Tweets, that any t.co links may not work. The domain may no longer exist, the service may have been taken down by Twitter, or Twitter may not even exist as a company any more. And if you think this seems likely, consider that historians could be reading through today’s tweets hundreds of years from now. Samuel Pepys’s diary wouldn’t be much use to us now if it contained content like “today I walked down abcdefgh street” and the lookup from abcdefgh to the real street name had been lost in the intervening hundreds of years.

But ultimately, the main reason that the whole t.co approach is truly broken is that it is a copy of a workaround implemented by tinyurl.com, bit.ly, etc. Twitter own the underlying platform so could have implemented a better solution rather than just copying someone else’s solution.

Why did they not just simply add support for structured metadata attached to a tweet? Then we could have links that were separate from the body of the tweet. This would eliminate the whole link shortening business, and also allow for big improvements in the user experience and readability of tweets by moving all that nasty http:// mess out of the body of the content.  Even the inventor of aitch-tee-tee-pee-colon-double-slash admits that it is a bit of a mess so we should be trying to use it less not more!

As one of the internet’s key services and most iconic brands, we should expect more innovation from Twitter and more focus on the user experience.