Flash Cookies and DOM storage

[leecovuk]

Hello again,

Does the February Sidki config assist privacy with any tracking issues presented by Flash cookies and DOM storage?
I ask having seen the following addon for Firefox :-

https://addons.mozilla.org/en-US/firefox/addon/6623

Should I/we install that, or does Sidki + Prox already cover this ground? If so, is there a specific config level or filter(s) that need to be turned on?

Thanks a lot,
Lee

[whenever]

Sidki mentioned flash cookie blocking in the 2009-01-14 beta notes but I don't know the details behind: http://sidki.proxfilter.net/prox/other/BetaNotes.txt

Quote:Additions/improvements include: Flash cookie blocking, routines deciding
which JSON data are filter-worthy, XHTML ready.

[sidki3003]

DOM storage is hardly ever used in the wild yet.

LSOs are commonly used, e.g. for storing your chosen volume at YouTube (soundData.sol), but also for Flash cookies.

The config is blocking the obvious Flash cookies which are (otherwise) called by a web page. It can't block those called by another Flash object, e.g, a movie.

On match, and if the bug isn't set to appear outside the visible area, you'll see a little bug image, like here:
http://thisisnotpitchfork.com/

[ProxRocks]

in regards to "It can't block those called by another Flash object, e.g, a movie."

from here - http://prxbx.com/forums/showthread.php?t...06#pid9906 -

(Nov. 17, 2008 06:02 PM)Graycode Wrote:  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.

[ProxRocks]

(May. 07, 2009 11:28 AM)sidki3003 Wrote:  On match, and if the bug isn't set to appear outside the visible area, you'll see a little bug image, like here:
http://thisisnotpitchfork.com/

cool!

[43unite]

In Firefox dom.storage.enabled can be set to false. This disables dom storage.

As Graycode indicated, linking items such as ~/.macromedia/Flash_Player/#SharedObjects and ~/.macromedia/Flash_Player/macromedia.com/support/flashplayer/sys/#* to /dev/null prevents saving/storing LSOs while preserving the user's global settings.sol. Flash functions normally.

http://en.wikipedia.org/wiki/Data_sink
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).
http://en.wikipedia.org/wiki/End-of-file
End-of-File, commonly abbreviated EOF, is a condition where no more data can be read from a data source.

[leecovuk]

Thanks for the replies here.

Would it be preferable then, to indeed use that addon along with Prox + Sidki?
Assuming the addon is correctly made and what its blurb says is true, it sounds to me it would do more in the area of removing tracking Flash cookies than Prox+Sidki.

What do we think?
or would it in fact conflict negatively with Prox+Sidki?

Thanks again,
Lee