As promised, a number of folks at Adobe have been digging into questions raised about what data is being gathered by Adobe applications, what’s being uploaded & tracked, etc. It’s an ongoing investigation, but in the interest of sharing info as quickly as possible, I’d like to pass along what we’ve gathered so far.
One of the most alarming claims (made by readers posting on Slashdot and elsewhere) is that Adobe apps are surreptitiously uploading users’ serial numbers. Adobe engineer Tobias Hoellrich has spent a bunch of time analyzing the issue and has posted his findings and methodology on his blog. Short story: "Based on my analysis, I don’t see any evidence that serial-numbers are being sent to either *.adobe.com or *.2o7.net." This info matches everything else I’ve been able to learn on the subject: the welcome screen SWF is not gathering/uploading serial numbers or other personal info.
There is one instance in which Adobe applications do upload a user’s serial number: during product activation. During that process (which has been around for roughly four years), an encrypted copy of the serial number is uploaded to the activation server. Note that activation is not the same thing as registration. The registration process (during which you supply your name, contact info, etc.) is optional and is not connected to activation (which does not include that kind of personal data). Details are available in the activation FAQ. None of this is new, nor is it related to the welcome screen SWF, but it’s worth mentioning for the sake of clarity & disclosure.
Tobias’s post doesn’t discuss the controversial "2O7.net" URL being in conjunction with the welcome screen SWF. Adobe staff are getting in touch with stats-tracking firm Omniture to get more info. As soon as I have more to share on that front, I’ll post it here.
0 thoughts on “What data do Adobe apps gather & upload?”
I am very glad and positive that you bring this issue in to light from your own perspecitve. It all sounds ok, and in the end it will probably turn out to be at least a quite reasonable reason enough why this is happening.
But… There are now new questions to be answered:
Your own engineers had to examine TCP packets from your own applications.
Why, why, why does not Adobe know what information their own applications send?
Why can you not get some internal documantation on this?
I mean, if anyone should know, Adobe engineers should know. There should be someone at your company responsible for what kind of network activity your applications generate.
Seems to me we now have something different in regards to security to worry about: Lack of internal Adobe documentation on what external companues can do with Adobe application data.
[There are a couple of issues (besides the holiday shutdown) that have made the info-gathering harder than one might like. One is that the welcome screens were first implemented in their current form in 2003 in Macromedia apps, pre-Adobe/MM hookup. The longer ago something was done, the more time is generally needed to track down the how’s & why’s of what was implemented. Another challenge is that some Adobe Web engineering is done in India, and there’s an obvious time difference between there & California.
So, I wouldn’t conclude that no one at Adobe knows what the apps are doing; rather, it’s just that Tobias’s info happened to become available first (because he took the initiative and worked on this stuff over the holidays), and I’m posting info as I get it. –J.]
Adobe staff are getting in touch with stats-tracking firm Omniture to get more info. As soon as I have more to share on that front, I’ll post it here.
Correct me if I’m wrong, but in my experience Omniture would just supply the URL, the fact that tracking is done as an IP rather than a URL rests in the hands of Adobe. Omniture just supplies the API, they won’t implement it in your site for you.
[I don’t want to spread half-baked info, so I’m going to continue holding off on answering until I hear details from people with more expertise here. –J.]
It was probably just an honest mistake with no deceitful intent, in which case I think a promise that in the future tracking will done in a more transparent manner would be enough for most people.
Thanks for the update.
I’m sure this news will put many conspiracy theorists minds at ease while they look for something else to worry about. It was almost comical (At least from my end, probably not yours 🙂 how fast the fear mongering spread over the net, condemning Adobe. I even saw it mentioned once that Photoshop’s built in anti-counterfeiting technology was somehow calling the Feds.
Not that this isn’t something worth worrying about (personal privacy) but if the ONLY thing they thought it was sending back is your serial number, so what. I don’t care if Adobe knows I open Photoshop 18x a day.
Ok, so they’re using my internet connection to send back what, like 4k of data when I do open Photoshop, I could see it being an issue if we were still on 300 baud modems, but we aren’t.
Slippery slope blah blah, One company sends a little data, the next company sends more, and so on, next thing you know they get our Social Security number and blood type every time we launch an app. Won’t happen.
In other news prolonged exposure to GIMP causes baldness.
Adobe has to ask an external company what it’s doing with Adobe’s customers data?…..
[That’s not it. People have been asking specifically about the use of the *2O7.net domain, which is owned by Omniture. They’ve been asking why Adobe apps would call a URL that seems designed to look like a local IP address. Given that Omniture created the domain & has been using it with other clients (e.g. Apple), it seems only fair to ask them for clarification/history before posting more info. –J.]
Personally I’m more troubled by the fact that Adobe ‘claims’ that it needs to talk with a 3rd party because they don’t know what that 3rd party is doing with Adobe’s data. Surely Adobe would not allow that data to leave the company without knowing who where and why, that would seriously bother me and many others I would think.
Not that I am claiming Adobe is doing anything we should worry about, just that it doesn’t seem to know why and what…
Thanks for your fast work on this. Not all of us are reactionary tin foil-hat wearers, and we appreciate you donning the asbestos underwear and letting us know what’s up.
Thanks for the clarification on my comments John.
(this may be a little controversial, so I’ll understand if it is spiked)
One thing I have noticed about Omniture is that the vast majority of Management/Directors appear to be connected with the Mormon church – as I believe Warnock/Geschke are.
Can’t wait for someone to pick up on that and run with ‘Mormon conspiracy to capture non-believers’ data…’ story
John, once again I am very pleased and grateful that you have kept an open door policy on the discussion of this matter and your openness on other potentially sensitive issues. You have kind of become a corner stone of adobe confidence and honesty. Thanks.
[Thanks for saying so, Alex. –J.]
I appreciate the openness and willingness to research and publish the facts. Privacy issues always need good, factual input. For what it’s worth, I’d be more comfortable with a global statement that “no serial numbers are transmitted to Adobe, Inc. or any of its affiliates or suppliers” (except in the case of activation). Your post is limited to transmission to adobe.com and/or 207.net, which can be construed very narrowly. I know you don’t control the policymakers who could make that global disclaimer, but it might be helpful for them to hear the concern.
[FWIW, I believe your understanding is correct: serial numbers are transferred only via activation, and they’re not shared with non-Adobe parties. –J.]
Re: Mormons: Ugh. This isn’t even worth pursuing. Omniture is based in Utah.
60% of Utah residents are Mormons.
So it makes sense that pretty much any company physically located in Utah is headed by Mormons.
That said, they’re being sneaky bastards by using addresses of the form 192.168.x.2o7.net. This is clearly designed to be misleading and avoid casual detection. There’s a special spot in hell reserved for deceptive marketers like this, right next to spammers who use false return addresses–sometimes my own–to defeat filters.
Thanks for keeping up on this… but, as if it hasn’t been made super duper clear… it’s the deceptive subdomain that I personally have the biggest problem with. I’m patiently (well…) I’m waiting for the explanation of that. The other info is good to know too.
[Understood. We’re working on it. –J.]
And yet I tend to see this issue falling by the wayside and being lost the rest of life’s daily activities.
It’s purely appalling that one has to analyze packets being sent to determine what is and isn’t being sent. Didn’t your company write the software? Didn’t your company go through an audit process before releasing the product? Shouldn’t someone on the development team know what they programmed?
Let me put on the hat of tinfoil hat wearing, fear mongering, FUD spreading, and the world is going to END at NOON for just a moment.
Examining raw packets is useless unless you know what has been done to the data before it has been sent. For example, if I have my serial number, or “personally identifiable information” as the corporations like to call it, and I encrypt it, compress it, or manipulate it is some form before it sent, when and engineer looks at the raw packets being sent, they aren’t going to know what is being sent. It would be no different that the data being changed into “Pig Latin” when you (as the engineer) has absolutely no knowledge of what “Pig Latin” is or how to read it.
“Ymay erialsay umbernay oneyay wotay hreetay ourfay isyay iddenhay inyay histay exttay”
After all, if I change the data into “Pig Latin” before it’s sent in the and look at the raw packets as they are sent, and have no idea what “Pig Latin” is, there is absolutely no personally identifiable information in that line.
Yet, on the other end, with someone that receives it, and does know what “Pig Latin” is and how to read it, you get this:
“My serial number one two three four is hidden in this text”
So, with the “TinFoil_Hat” still on, when you are dealing with a company has partnered with a deceptive 3rd party company, one can really question the validity of the engineers “professional opinions” when they examine only the raw packets. The raw packets being sent appear to have no identifiable information, but unless you know what the starting data is, or where it came from, you really don’t know what is being sent.
Packets are one thing; what data is being sent in those packets; this is another thing; What has been done to the data before they were sent in packets is the real question. The only way to determine that is to look at the raw source code or talk to the developer(s). Until that is done, and verified, your tinfoil hat crowd is not going to be satisfied.
So as you can see, we really don’t know anything more that what we knew before. Sure the raw packets may not appear to send anything, but until one looks at the source and see what in-fact is being sent, looking at packets is completely useless.
One could even argue (and quite easily I may point out) that this whole thing could be a part of the plan to sweep things under the mat, and give the illusion of “saving face” while attempting to regain some trust. But again, it could easily be counter argued that this isn’t the case and that one who would even consider this is a paranoid tinfoil hat wearing FUD spreading monger.
I can’t remember who specifically said it, but if I recall he worked at E-eye and in an article he stated [paraphrasing] that: “There are two kinds of people in this world: Those that have blind faith in the good of technology, and those that question, “Yes, this may good for the intended purpose, but what happens if it’s not used for it intended purpose?” It’s very similar to the question of “Who watches the watchers?”
As you can probably guess, I fall into the second category.
So what does it all mean? Until the code is looked at specifically and it is revealed exactly what information is being sent in those packets this entire thing and this blog, and the attempt to regain trust is a moot thing.
“While all answers are replies, not all replies are answers.” This is why I just see it falling by the wayside, and just disappearing into history with many replies, but being left with out any real answers.
PS: Andyay esyay, Iyay ouldcay ebay onsideredcay ayay infoiltay athay earingway ongermay.
Perhaps my previous post didn’t taken in the account of the methodologies that were used in this particular case of testing. [to be quite honest, I didn’t notice the methodologies link at first]
Regardless, I think it really shows a point that it’s in Adobe’s best interest to really view and consider the model of “opt-in” rather than “opt-out.”
Even still, with the deceptive 192.168 address, that still leaves a very *SOUR* taste in my mouth regarding trustworthiness of Adobe and their process of due diligences when it comes to their partners/3rd party partnerships.