Forum Moderators: open
By tagging your browser with a Flash object containing a unique ID, United Virtualities can recognize an individual PC and restore the deleted cookie data. Flash allows "shared objects" to be saved on the PC, which some clever person deduced could be an alternate form of unique identification.
Pretty soon you'll have to reformat your hard drive every week or so just to be sure...
Can PIE tags be set or read by 3rd party domains?
Sadly, no. Unless the 3rd party domain has permission to do so by the original domain...You have to know all about developing in Flash to find out how. Flash Player comes with a built-in Security model to prevent this kind of action.
C'mon, that's no secret - Macromedias "security model" essentially consists of putting a small text file in the root of the domain. That's for Flash files / Flash applications though - here we're taking about Flash cookies that does not need Flash applications to work as far as i can see from what i've read sofar. But perhaps i'm wrong?
If so, please tell me specifically what is wrong and please also state specifically what is right. I take great interest in these subjects and i do honestly want to know where i'm right and where i'm not.
Anyway, it's not that i don't want to trust you, so please don't take this personal. It's just that the field of tracking is not just any field to me - you really have to come up with some specifics here:
What - exactly - are those easier methods you mentioned? What - exactly - are the larger of our worries and how does those relate to this thread? How - exactly - are Cookie and SO problems solved? What - exactly - does microsoft updates have to do with this issue?
Any specifics on this will be really appreciated - if you don't provide specifics even when asked, then it's hard to take your posts on these subjects seriously.
Again, don't take this personal - no offence is intended. If i'm wrong about matters of specific interest i prefer to be corrected sooner than later, so please enlighten me :)
Our members include many extemely sharp and successful marketers - and that means as users they are much more tuned into to the issues and potential abuses. Engineers often do not conceive of the seamier uses of the technologies they create - it's just not in their nature.
Since this particular topic has now hit the public level (at least the technical and/or marketing public) that also means that some of the most devious minds in the tech world are also looking at it. We've had some really startling exploits devised in recent times. Jpgs comes quickly to mind for me, as an example.
I want this to be a non-issue. I'm certainly not convinced of that so far. There are two concerns actually - how can I use this technology, and how can I be used BY it.
As an example, web servers can get hacked. Could a hack simply inserty third party permissions? It could sit on the server unnoticed for a while, and then be exploited by a phishing scam, for instance.
What - exactly - are those easier methods you mentioned? What - exactly - are the larger of our worries and how does those relate to this thread? How - exactly - are Cookie and SO problems solved? What - exactly - does microsoft updates have to do with this issue?
Frankly, I don't care whether you think I know anything, my question to you is what drives this curiosity? I develop software. There are loopholes in everything. In fact, we put them in there on purpose. The easiest example: What if you forget your Windows Logon Password? Oh no, reformat and reinstall, all data is gone...No, you hit F8 at startup go into safe mode and change it to whatever you want. Why did they do that? They could have just left you locked out of your computer and your personal data gone forever. EVERY program is designed like that. You may not know where to look, but there's always a cake move to make to get in. Why? For that same reason, what if you get yourself (the engineer who created the program) locked out? Now what? Now your consumers are all over your back because there's no way out and all hell breaks loose.
Now I'll answer your question. The easiest way to track users is "spyware." Believe it or not. You don't know it's there and it isn't a virus so no virus software is going to solve that issue. Let me ask you this: How many times have you installed something on your computer? 1 time is enough to get spyware. What's stopping the company that produces the products you install from including spyware that you wouldn't ever notice? Hmmm, we don't care because we don't know. Now how can you get it from the web to the user's computer? Well you have a computer, and the internet, you figure it out. You know what's installed on your computer, how many times the program pings a server, contacts a web service, opens a socket connection...all under your nose right? Of course not, hell I don't even worry about that b.s. and I develop software. Why should we? The average computer user doesn't even know they have an issue. And they don't seem to care until dumb cookie scams and sharedobject issues come up. That's what I hate. And guess what else, Spyware is designed solely for tracking users, otherwise it would be called a virus.
However, because this approach -- restoring deleted cookies by using Flash -- is just now breaking into the news, there is a natural impulse to understand this approach more thoroughly along with all of its implications.
And that is the specific topic of this thread. A more general discussion of user tracking belongs on another of our forums, not this one.
You mentioned above that 3rd party PIE objects are possible with the "agreement" of the domain hosting the page. How is that agreement given? And do the objects fall under P3P, from a user agent standpoint?
<edited for spelling>
[edited by: tedster at 7:34 am (utc) on April 4, 2005]
Unless the 3rd party domain has permission to do so by the original domain...
And users will be justly upset because it should only work if the 3rd party domain has permission to do so by the user.
If "flash cookies" can be set by a site without the user having the opportunity to prevent it and then the permission to read that info can be passed around from site to site without the users permission, then the same users who manage their cookies will probably find it easiest to disable Flash completely.
EVERY program is designed like that. You may not know where to look, but there's always a cake move to make to get in. Why? For that same reason, what if you get yourself (the engineer who created the program) locked out?
*EVERY* is a stretch. Certainly this would presume that you are speaking for or about the software that I've developed for commercial markets. This is just not going to happen in my case because only *one* sharp customer has to figure it out and any goodwill is toast. Forever. No amount of spin is going to make the stink go away. The rationale behind this decision is that I treat client machines with the respect that I expect my machines to be treated.
I was very interested in your claimed surefire techniques at first but less so now. It seems that you are depending on the ability to install software on a remote system. This dependence is not of much interest to the readers here. The readers here are interested in tracking techniques which can be implemented solely within the confines of the browser without any dependencies on third party software.
If you have a technique to share which is not dependent on external executables and works reliably within the confines of the client browser, I am sure that there a number of readers of this thread, including myself, that would be interested in examining it.
++
Me?..I'm terrified about the levels of radioactivty in single pixel gifs served from other servers :o
Welcome to WebmasterWorld anyway..
The issue about Flash is that it's an inroad onto a visitors computer, like an exploit, the sort of thing we usually patch for. In other words, I've got my system locked up tight, no spyware (trust me on that one), not a virus in 3 years, and yet there were shared objects, before I locked this up as well.
It's just another exploit route that the general public was unaware of, and once made aware it will be another blow to public confidence.
I've seen computers infested withing minutes of going online after a clean install with all sorts of scanning up, jsut while they were getting updates and patcehs (and even after). I've known people practically give up on computers because of the onslaught of nasties. I even know absolute non-techies keep two computers, one for email and internet and the otherone so tehy ahve a functional system when the net computer goes belly up.
These people will not look kindly on yet another threat to they private properity (their computers), and it can only harm us all in hte long run.
SN
It's all very well giving the option to turn the shared memory off but imo it should be opt-in not opt-out.
SN
[clickz.com...]
Interesting but it's way too bleeding edge. Not everyone has flash installed; macromedia is already instructing people on how to disable it. No thanks.
If "flash cookies" can be set by a site without the user having the opportunity to prevent it and then the permission to read that info can be passed around from site to site without the users permission, then the same users who manage their cookies will probably find it easiest to disable Flash completely.
The user has a 5 second choice...and keep flash enabled, because it is a great technology. All they have to do is disable sharedobjects if they so wish. It takes meesly 3 clicks to do it.
"SO's can store many orders of magnitude more information than a cookie can and are also not affected by browser settings but by the Flash player settings," said Quarto-vonTivadar.
This is not entirely true. SharedObjects composed of text just like cookies.
It seems that you are depending on the ability to install software on a remote system. This dependence is not of much interest to the readers here. The readers here are interested in tracking techniques which can be implemented solely within the confines of the browser without any dependencies on third party software.
When you get down to the point, what you're really doing is cheating. Also, what's the point of tracking someone not interested in your products? That's why you only track those that are...hence where the root of all this comes to light. Every internet user uses a browser. To invest in tracking every internet user, what does your company gain? Plus the best you'd track is there browser version, every time they visited.
I'm still unable to discern the special methods from these replies.
What special methods are you referring to? I answered all the previous questions. I never stated anything about special methods. I said "easier" methods. But, from what I understand this forum to be I guess the easier methods are completely dependent upon experience and job field. And I am not responsible for that. With that said, I am no mentor. It's not my responsibility to spill any information, and frankly I shouldn't and choose not to. I wanted to make a point to this thread that this paranoia and flash sharedobject scare is pointless. That user's must resort to disabling the Flash plugin simply to defeat a harmless object which is in fact very harmless, and that can be toggled on and off at will, is a move of ignorance.
You made two specific claims which you have studiously avoided fully addressing in your subsequent posts.
1)
EVERY program is designed like that. You may not know where to look, but there's always a cake move to make to get in. Why? For that same reason, what if you get yourself (the engineer who created the program) locked out?
2) and that you have some reliable method to track users, which to the assertion that it depends on installing additional binaries, you responded:
When you get down to the point, what you're really doing is cheating. Also, what's the point of tracking someone not interested in your products? That's why you only track those that are...hence where the root of all this comes to light. Every internet user uses a browser. To invest in tracking every internet user, what does your company gain? Plus the best you'd track is there browser version, every time they visited.
My reaction to this is "Huh?"
No one has said you must share what you did not originally disclose.
I think however, that a number of people here, including myself, are calling your bluff.
Not a poker player, but I think the phrase is something like "show'em or fold'em"
++
This is indeed my business, or at least part of it (however large that task might seem). It is also the task of many other businesses that i work with. It's called Audience Measurement, and spyware just isn't an option.
Everything here has to have a high level of transparency and adhere to pretty tough standards regarding techniques as well as privacy - as defined by eg. organizations such as ESOMAR, and ISO.
I perhaps should have stated that, as i can see from your post above that you think in terms of product-specific, or site-specific, tracking. That is an entirely different ballgame, i'll have to agree with that. And yes, "there is always another way to do it", as the saying goes - ultimately, just by being on the internet you are being tracked already.
So, i basically misunderstood your posts, and i apologize for that.
That said, i consider myself pretty informed on all aspects of tracking, including, say "non disclosed techniques" that would not be fit for the purpose above. Those particular techniques just aren't the topic of this thread.
C:\Documents and Settings\<% your login %>\Application Data\Macromedia\Flash Player\#SharedObjects
%USERPROFILE%\Application Data\Macromedia\Flash Player\example.com\dir\sharedobject.sol Does anyone know why they're there and not in the #SharedObjects folder?
cmatcme
However, I have always wondered when they would come under the same level of privacy/security scrutiny that cookies have. It looks like that time is now. But I guess it was only a matter of time before advertisers started to (ab)use the technology.
To a large degree all the security and privacy arguments surrounding the use of Shared Objects are the same as cookies. However, the issue that makes PIE quite sneaky is that it can be used to backup and store all the data in a cookie as a Shared Object, and if the user deletes the necessary cookie, the “PIE-enabled” ad, detecting that there is no cookie but that there is data in the Shared Object, will repopulate the cookie the next time it is served. Which can only be seen as a deliberate attempt to subvert the user’s intentions.
This can only serve to irate and/or worry end users in the same way they did about cookies. It doesn’t matter how harmless a text file may be in reality, it’s the end user’s fear and resentment of having their privacy surreptitiously manipulated that will result in a backlash.
In addition to any fears or concerns in principle, no matter how unfounded they may be, the unorthodox methods of administrating Flash Shared Objects can surely only further increase users’ concerns. Right clicking on a piece of Flash and selecting “settings” accesses the security options. The Settings panel that pops up is an object rendered inside the flash player itself - it’s not a system window. Already this is slightly unorthodox. From here you can edit settings for the domain that the current movie is in. However, to edit the global settings, you need to click the “Advanced” button. Rather than opening an application window, as you would expect, this takes you to a page on the Macromedia site: [macromedia.com...] At first glance this looks like a simple content section. Having taken the time to read and understand the content, a user has to follow the links within the content to edit their global settings. These take you to more HTML pages, such as: [macromedia.com...] Within this HTML page sits a Flash movie that allows you to set your global privacy settings. It even lists all the domains that have set Shared Objects, which you can then edit/delete/block/allow!
To me this seems crazy. Imagine if Microsoft insisted that you had to log on to a page on their site in order to get a list of, and manage, all the cookies IE had set?
So while I personally don’t feel too affronted by the idea of a site using Shared Objects, I think the manner in which users can take control of them is so unusual that it is detrimental.
Macromedia should integrate Flash’s security settings directly into the various browser’s interfaces to make the whole process more intuitive and transparent, which will hopefully allay any fears of Shared Objects before it reaches the same level of paranoia surrounding cookies.
MrMiles, that's a really useful thing, kudos. Perhaps you could answer this question:
In order to manipulate SharedObjects, do you need a Flash movie or "swf" file - or, can you do it entirely by means of JavaScript?
(what i've read sofar is not clear on this issue)
("~" is your user folder.)
Added: MrMiles, Welcome to WebmasterWorld!
I’ll try to clarify a few technical issues surrounding Shared Objects. Forgive me if I’m repeating what has already been mentioned, or if you know it all already. And forgive me if I seem to be droning on (hey, it's been a quiet afternoon in the office).
Shared Objects (on a PC at least) are stored in:
C:\Documents and Settings\<username>Application Data\Macromedia\FlashPlayer\#SharedObjects\
Followed by a series of subfolders that mimic the domain and path of the location of the SWF that set the SharedObject.
Shared objects are saved as .sol files. I don't know much about the formatting, but it seems to be some sort of proprietary Macromedia encoding. Opening them in a text editor will reveal a bit of information, but a lot of nonsense too. Several clever chaps out there have managed to reverse-engineer them to the point of building SOL viewers and editors that allow you to inspect the stored data in a meaningful way.
Shared Objects can store many types of data including: Strings, Numbers, Booleans, Arrays, Objects, Dates and XML Objects. Possibly more. These types of data are then ready to use when reading back the Shared Object – so, for example, you don’t have to parse a comma-delimited text list to get back an array, you simply refer to the array as a native object. I guess the parsing process is all built into the player and the SOL format.
Each domain can set an unlimited number of Shared Objects of any size, restricted only by the user-allocated storage space permitted for that domain (default is 100k, maximum is unlimited).
Shared Objects are persistent across sessions and don’t / cant be set to automatically expire after any given time.
Shared Objects can only be set and read by SWF files, as they are being actively displayed in the browser. Shared Objects cannot be directly set or read by client-side JavaScript, nor through server-side processes.
SWF files, by default, will only have read/write access to those Shared Objects it has created itself or by other SWFs on that same domain.
SWFs on one domain cannot directly access the Shared Objects set on another domain. For example, a SWF on www.baddomain.com cannot directly read Shared Objects set by www.gooddomain.com.
When comparing domains, the security model for Shared Objects and SWFs will always compare the domain the actual SWF is being served from, rather then the HTML page it is served within. So an SWF from domain A, embedded within an HTML page from domain B, will still only be able to read/write Shared Objects associated with domain A.
It is possible to explicitly grant cross-domain sharing of Shared Object data, but only through the following work-around. For domain B to read a Shared Object set by domain A, domain A would need to host a “setter” SWF movie, SWF-A, that did all the reading/writing of Shared Objects associated with domain A. Domain B would then need to host a “reader” SWF, SWF-B, that internally loaded SWF-A. Then, only if SWF-A explicitly allowed access from Domain B, would SWF-B be able to read data within SWF-A. This means that a site could intentionally share Shared Objects with SWFs on other, explicitly defined, domains. But what it prevents is a devious site trying to surreptitiously import and hijack a SWF from an unsuspecting site. So, www.baddomain,com could not load and read a SWF set by www.gooddomain.com without the site owner’s specific consent.
In addition to this, it’s perfectly possible for a SWF file to post any data contained within a Shared Object back to the server – or even to another domain (although that requires both domain’s doing a little work to permit access to and from each other) – in exactly the same way that Flash can send and receive other data via the standard data handling methods.
So, at the end of the day, you still have to trust the issuer of the Shared Objects - that they won’t abuse, harvest, and share the collected data with inappropriate parties.
