Speaking of YouTube.......

[43unite]

(Nov. 17, 2008 01:35 PM)ProxRocks Wrote:  that SUCKS!!!

True.

[ProxRocks]

interesting, NO registry settings at all...

here's the dealio, the GLOBAL settings performed by jumping through the hoops by going to Adobe.com's "settings" page is a single file that CCleaner will ERASE so do NOT think that just 'cause you set the Global Settings ONCE that you are done with them, "set-and-forget"...

if you use CCleaner to clean Applications->Multimedia->Adobe Flash Player, then your global settings are ERASED also!...


so here is the "fix", set them d@mn Global Settings, go to your user-name's "\Application Data\Macromedia\Flash Player\macromedia.com\support\flashplayer\sys" folder, COPY settings.sol and save it somewhere nice...

now when you run CCleaner (or equiv.), RECREATE that folder structure and COPY that settings.sol back in...

CCleaner should NOT be deleting "that" file, but i don't have the "time" to COMPLAIN to CCleaner's maker so that they "fix" their 'flop'...

[43unite]

(Nov. 17, 2008 03:10 PM)ProxRocks Wrote:  the GLOBAL settings performed by jumping through the hoops by going to Adobe.com's "settings" page is a single file that CCleaner will ERASE so do NOT think that just 'cause you set the Global Settings ONCE that you are done with them

if you use CCleaner to clean Applications->Multimedia->Adobe Flash Player, then your global settings are ERASED also!...

CCleaner should NOT be deleting "that" file, but i don't have the "time" to COMPLAIN to CCleaner's maker so that they "fix" their 'flop'...

Open CCleaner. Options > Exclude > Add File

Enter the path to settings.sol, something like...
C:\Documents and Settings\[system] Administrator\Application Data\Macromedia\Flash Player\macromedia.com\support\flashplayer\sys\settings.sol

A menu option to locate the file is available for this.

Once this path is entered the main settings.sol file that contains your global settings should then be excluded from processing.

Note - If Flash website data is stored, each website folder may contain its own settings.sol file that contains individual settings for that site in particular. CCleaner will delete all of these unless instructed not to.

[Graycode]

(Nov. 16, 2008 12:22 PM)43unite Wrote:  My Linux distro is configured to send this garbage to /dev/null so it is impossible for that data to be stored on my system.

That's almost what I do in Windows.

(Nov. 17, 2008 01:24 PM)43unite Wrote:  Global setting must be done on site. Adobe actually accesses and displays your system settings. It is the only way to change them.

Yes but I prefer to not have settings or other of their SOL crud at all.

(Nov. 17, 2008 03:10 PM)ProxRocks Wrote:  so here is the "fix", set them d@mn Global Settings, go to your user-name's "\Application Data\Macromedia\Flash Player\macromedia.com\support\flashplayer\sys" folder, COPY settings.sol and save it somewhere nice...

now when you run CCleaner (or equiv.), RECREATE that folder structure and COPY that settings.sol back in...

Interesting topic. I'm definitely in the minority since I allow very few Flash into a browser. So anyway ...

C:\Documents and Settings\USER-NAME\Application Data\Macromedia\Flash Player\ ...

Long ago I removed the \Macromedia\ directory and replaced it with a FILE having the same 'Macromedia' name. The file content doesn't matter, zero-length is fine. Now when the software tries to create its sub-dirs with cookies & other data within that supposed directory, they can't. There is never anything contained within my \Macromedia because it's been made into a File, and thus is no longer capable of permanently storing that crud.

Almost all SWF still works normally. A few occasionally go silent, perhaps because they're relying on being able to store some crud that I wouldn't want. That may not be the solution that works for everyone. If you delete that file the software will recreate its directory structure.

The method works because Windows won't allow both a file and a directory to exist with the same name within the same path. I think Linux would, so linking it to /dev/null there would be equivalent.

[lnminente]

Nice reading here! Thank guys!

Using now CCleaner to delete acrobat files excludying the main .sol

Graycode, nice tip, but take a look sometimes to the macromedia file, maybe in a future update this tip will not work anymore.

[ProxRocks]

(Nov. 17, 2008 06:02 PM)Graycode Wrote:  in the minority since I allow very few Flash into a browser. So anyway ...

C:\Documents and Settings\USER-NAME\Application Data\Macromedia\Flash Player\ ...

Long ago I removed the \Macromedia\ directory and replaced it with a FILE having the same 'Macromedia' name

COOL! i like this "fix" even better (still "testing")...

and btw, unless i'm helping out the Proxo community, i do NOT allow Flash into my browser either (it's not even installed for Opera/Firefox)...

[43unite]

In Unix-like operating systems, /dev/null or the null device is a special file that discards all data written to it (but reports that the write operation succeeded), and provides no data to any process that reads from it (yielding EOF immediately).

So once configured it's like an OS 'black hole'. These pointers can be set wherever the user desires no data or record created/saved.

In addition, my OS is configured so that all caches (including Firefox) and all /tmp files & folders are saved into RAM. These are either immediately deleted upon app termination, or 100% gone with shutdown.

(Nov. 17, 2008 06:02 PM)Graycode Wrote:  The method works because Windows won't allow both a file and a directory to exist with the same name within the same path. I think Linux would

No, it won't.

(Nov. 17, 2008 06:02 PM)Graycode Wrote:  Almost all SWF still works normally. A few occasionally go silent

Everything works fine here.

[ProxRocks]

yeah, works here too...
think we found an AWESOME fix, that is until "Big Brother" catches on, "Oh crap, they're not letting me drop my .sol, i'll drop into "system32" (or Linux equiv.) instead"...

[43unite]

(Nov. 17, 2008 07:37 PM)ProxRocks Wrote:  yeah, works here too...
think we found an AWESOME fix, that is until "Big Brother" catches on, "Oh crap, they're not letting me drop my .sol

The *.sol files are for user specified options & restrictions. They either reflect the global settings, or user defined changes from the global settings. They are there to specify, preserve and insure user privacy & configuration choices. They themselves are not malware. Some users want different privacy/storage options for different sites that vary from their global choices. That's all. CCleaner's factory default just removes them all unless instructed otherwise.

[Oddysey]

Hey, lookie here, I hatched a can o' worms! Lots of stuff to ponder over, but one thing's for sure - ProxRocks and I see eye-to-eye right down the line - there's not much point in going to a website that insists that it can control my computer better than I can. Oh really???? Would you care to place a little wager on that, Mr. Adobe?

I also like Graycode's method, I hadn't really thought about tricking software that way, hmmm.......

For today's history lesson, we'll find out that Linux (and *nix of all flavors) have no lock on the NUL device. In fact, it was there in IBM's JCL-OS (Job Command Language OS), and has been present in every OS since, no matter who makes 'em. Even the Commodore C-64 OS had a NUL device.

In the Microsoft OS world, ever since Dos 1.0 (and I still have my original copy of 1.1, I was a bit late to the party for 1.0), NUL has been a part and parcel of the gizzards of all OS's deriving and descending from that venerable start in life. You don't configure it so much as you simply use it. One way would be to copy a file to the NUL device, like so: (at a command prompt: )

copy *.tmp > nul

Not very useful, but wait, it gets better...... If I don't want to see any resulting messages from a command, I 'redirect' them to the NUL device, like so:

for %f in (*.*) do if exist d:%f del %f

This would spew out the error message "File not found" for every file that existed in the current directly, but not on D:. To cure that, enter the command like this:

for %f in (*.*) do if exist d:%f del %f > nul

That last part says to the OS 'any messages for the screen, send them instead to the NUL device'. Simple, neat and clean.

One more item, and this is useful, even in a GUI world. If we want to know if a directory exists, then we can query the OS like so:

if exist d:\somedir\nul echo "Yep, it's here"

The point being, the NUL device exists everywhere, except for non-existent folders.

I'm sure you can figure out what to do from there, eh?
</pedantics>

HTH



Oddysey

(Hey Ralph, how's my memory on that one? )

[Oddysey]

Oh, and I'm glad to hear that deleting the .sol files doesn't harm the user experience to any noticable degree. I'll try out the "file instead of directory" method for the next few days, and report back. Stay tuned.



Oddysey

[43unite]

(Nov. 17, 2008 10:43 PM)Oddysey Wrote:  Oh, and I'm glad to hear that deleting the .sol files doesn't harm the user experience to any noticable degree.

Again, the .sol files merely contain user settings. So by deleting them you lose your settings (restrictions over Flash behavior). For example, my main (only) settings.sol file contains such items as: %TCSO, settings, gain, echosuppression, defaultmicrophone, defaultcamera, defaultklimit, defaultalways, crossdomainAllow, crossdomainAlways, secureCrossDomainCacheSize, allowThirdPartyLSOAccess, trustedPaths, safefullscreen along with my user selected option for each.

(Nov. 17, 2008 10:43 PM)Oddysey Wrote:  For Today's history lesson, we'll find out that Linux (and *nix of all flavors) have no lock on the NUL device.

I included those /dev/null hints in case anyone else was using Linux. Great that a similar solution is available for other platforms.

I'm not Ralph, but your memory seems pretty good to me!

[Oddysey]

43;

I'm under the impression that .sol files can also hold private data that the serving site doesn't need to see. One of mine, out of maybe 14 or 15 of 'em (I forget just how many now, the bloodbath was pretty gruesome), had a set of path statements to a majority of my installed programs!

So, are we damned if we keep 'em, and damned if we dump 'em? There must be a way of getting control over what's stored within them, and what gets sent to whichever server. Perhaps a new line of Fake SOL's, taking after Prox'Rocks's Fake Cookies?



Oddysey

[43unite]

(Nov. 18, 2008 01:35 AM)Oddysey Wrote:  I'm under the impression that .sol files can also hold private data that the serving site doesn't need to see.

You may find it interesting & helpful to take a look at these sites:

http://en.wikipedia.org/wiki/Local_Shared_Object
At the bottom is a section titled: Editors and toolkits

http://www.cnblogs.com/bluekylin/archive...36144.html
directly edit the file settings.sol using a sol editor

http://www.swishzone.com/index.php?area=...tutorials&
do=page&action=detailed&link_id=197
(The above URL would not display properly. So I intentionally split the URL onto two lines. Just paste it back together.)
This tutorial shows you how you can use Flash's Shared Objects to store and retrieve data from your website visitors local system.

[43unite]

(Nov. 18, 2008 04:33 AM)43unite Wrote:  http://www.cnblogs.com/bluekylin/archive...36144.html
directly edit the file settings.sol using a sol editor

Here's "Sol Editor" running on Linux with my main (only) settings.sol file loaded. Didn't see any tracking ID's nor anything else suspicious. Only my settings.