I work for a bank and security is a major concern. We are currently using a cname on Adobe's collection servers (e.g. stats.bank.com) in order to have Adobe serve first party cookies on the bank.com domain. Our security council now says we shouldn't provide Adobe with a new SSL cert for stats.bank.com because it is too risky and if stats.bank.com is compromised and someone attacks our customers then we our liable due to it being our brand and all the cookie data is exposed as well as leaving customers open to malware attacks. So we have the following options:
Here are our thoughts:
1) Too expensive
2) We thought it was a good solution but then the cost came up. It seems like it would be very costly to build that type of infrastructure due to the volume of calls.
3) Adobe's 3rd party namespace blocked too much.
4) Seems to maybe be a solution but still concerned about 3rd party being blocked.
I was wondering if anyone has had to deal with these type of security concerns and what the solution was. Also what are the drawbacks of solution #4 in particular?
There is no personally identifiable or personal information at all in Adobe's tracking cookie.
Before I say anything else, based on what you have said, let me just say that I think your security council is either misinformed about Adobe's tracking cookie or else blowing things unrealistically out of proportion.
The visitor id (s_vi) cookie is just that: a cookie that contains a visitor id value. Here is an example of what the cookie value looks like:
[CS]v1|2A933F6C05079103-6000110EA000D3F3[CE]
The value has nothing to do with a visitor's personal information or data or anything like that. It is a randomly generated value that sticks to the visitor for as long as the cookie persists.
Cookies that are created for any custom coding you do are NOT the same thing
See, this is where I think some people may be confused. Here is a common scenario to explain: member id tracking. A visitor when they first come to your site is anonymous. They login to your site and now your site knows who they are.
From a tracking perspective, it is common to have a prop and/or eVar that reflects this. So on pages/hits where you don't know the visitor, you wouldn't pop anything, or maybe you'd pop some default "anonymous" or "unknown" or "logged out" value. Then when the visitor logs in, you pop the prop/eVar with a value that your site recognizes as a member or account id.
Maybe this id is their email address. Maybe it's a randomly generated value. Maybe it's a username. Point is, it's something to uniquely identify the visitor within your own site's system.
So let's say you write code where upon login, you pop prop1 with the value and then you decide to make use of Adobe's getAndPersist plugin. This plugin basically takes a value and puts it into a cookie and then retrieves the value each time the plugin is called. The idea here is that you only have to do the work to come up with the value from your end one time and then Omniture will persist it from there. This is particularly useful for when you want a value to pop for each page/hit but may not have easy access to replicate or scope the logic to all areas of your site, particularly across subdomains.
So now you have a cookie set by Adobe Analytics code from this. This has nothing to do with the s_vi cookie at all.
Firstly, it is something you explicitly set, even if it is just to get the ball rolling. Secondly, the value is not stored in the s_vi cookie; it is stored in a separate, 1st party cookie.
Even if you have FPC tracking, it is still set in a separate cookie. The actual cookie name depends on what plugin you are using (or using Adobe's s.c_w cookie write function yourself), and also whether or not you are using the combined cookie plugin (in which case it will be put in s_sess or s_pers, depending on what you set the expiration to be)
Now.. if you do have FPC implemented, you can obviously overwrite that cookie with your own value. And you can obviously make that value whatever you want it to be, including something personal to the visitor. But that's not Adobe's doing; that's your doing.
The overall point here is that whether you make the visitor tracking 1st party or 3rd party, that's a completely separate cookie that has nothing to do with personal data.
You may have custom coding that contains personal data and you may put that data into cookies, even using Adobe Analytics functions, but that is not the same thing. It will always be first party cookies (impossible for js to write 3rd party cookies), and the cookies will always be separate.
Nonetheless, the s_vi visitor id may be used to indirectly get personal data
I'm sure the next thing heard will be something along the lines of "But it doesn't matter, it's a unique id for the visitor, and it's in Adobe, and so is this other data, and you can use the visitor id to find the data within Adobe!"
And this is true. However...
Firstly, in order for there be personally identifiable data to be found within Adobe Analytics, you have to explicitly put it there. For example, you have to set stuff like:
s.prop1='jon doe'; // name
s.prop2='4321 1111 1111 1111'; // credit card #
s.prop3='04/2020'; // exp date
s.prop4='123'; // security number
I don't think I should have to tell you that this is a supremely bad idea, but point is, this isn't Adobe collecting that info, it is you doing it. And it's not in the s_vi visitor id cookie, nor can it ever be (again, unless you have fpc imp and decide to explicitly overwrite the cookie with those values..).
So that data, along with the visitor id, goes off to Adobe servers. So there's the next road block: getting access to the data within Adobe. The bad guy would have to have a Adobe Analytics user account under your company, and it would have to have proper permissions to gain access to that data.
And even then, Adobe doesn't actually expose the visitor id value in the reports. So in order to get the data associated with a certain visitor id, you need access to data warehouse, or to be listed as a supported user and request raw hit logs from ClientCare.
I guess the overall point here is that all by itself, that visitor id isn't really the dangerous thing. It's not the personal data, and being able to make use of it to find specific data associated with it would involve acts of extreme foolishness about storing personal data on Adobe servers in the first place, as well as gaining access to said servers/interfaces.
All that aside..
Okay, so maybe you don't care about all of that stuff above. Or maybe none of that convinced your security council to budge. You're moving away from Adobe FPC imp and that's all there is to it. So let's talk about the options you listed and your concerns about them.
Bring reporting in-house
You said this is "too expensive." You know, I gotta be honest here.. this is a bit laughable, coming from a bank! But seriously..
Perhaps you thought it too expensive from a building-from-the-ground-up-from scratch perspective? If this is the case, have you considered options for ones that have already been built, that you can put on your own server and customize or build off of from there?
Webtrends offers this. Frankly, I loathe Webtrends as a tracking solution, but it does offer ability to put it on your own server (last I heard, anyways). Also, Piwik is a really good open source solution.
Filtering proxy
I'm not quite sure what you mean by this. This sounds a lot like FPC tracking.. except having a means to scrub all requests of personal data before it goes to Adobe? Well if that is the case, I'd go back to the point about sending personal data to Adobe in the first place. But okay, maybe you aren't doing that, but want to have an extra measure of precaution just in case; fair enough.
So maybe you setup a service on your end that sends all requests to stats.bank.com and it scrubs stuff and maybe even has a mapping of values (like visitor id). In principle, this isn't really a complex script, so again I have to wonder why cost is an issue, especially coming from a bank.. but whatever..
Sticking with Adobe's 3rd party cookie implementation
If you want to go back to 3rd party cookie tracking using a domain owned by Adobe, instead of using the default 2o7.net domain, I suggest you consider their new(er) 3rd party cookie implementation for Regional Data Collection.
Rolling your own 3rd party cookie implementation
As far as I am aware, Adobe does not offer any kind of service involving you specifying a domain name for them to purchase/own and collect data from as a 3rd party implementation.
The closest service to this is the first party cookie tracking. So, you if you have www.bank.com, normally you'd specify something like stats.bank.com (something on the root domain) and that's FPC tracking.
However, you can tell Adobe to use for example stats.someotherdomain.com (assuming you own and control it) and they can implement FPC tracking for that domain. Then, when you implement tracking on www.bank.com, that effectively becomes 3rd party cookie tracking.
The caveat though is that you still own that domain, so I can only assume that on some level, you will still be liable for it (I'm not a lawyer). However, maybe this will be enough to appease your security council, worth bringing it up to them.