Individual Risk Management (Personal IT Security) and Browser Cache Management Post: 303033322

Sponsored Content

The Lounge What is on Your Mind? Individual Risk Management (Personal IT Security) and Browser Cache Management Post 303033322 by Neo on Wednesday 3rd of April 2019 07:56:15 AM

04-03-2019

Administrator

Quote:

Originally Posted by bakunin

You asked for a scenario where this might pose a risk to the user: let us say i search Google for ways to overcome personal debt repeatedly. If one of the "advertisement partners" of Google is the next bank and if Google is able to identify me across sessions i may well have lowered my credit rating effectively by doing that research - even if it might not even be for me. Given, that is a constructed example and includes a lot of conjecture - but the girl getting advertisement for baby food before even her parents were aware of her pregnancy was real. It is not a lot different (not in scope and definitely not in technical background) from what i presented here.

Yes, that first example is "constructed" and not really realistic.

The second is a real example, but that example is not because of "cookies and caches"... it was because the girl had made purchases with Target and so Target (a retail chain in the US) sent her a paper flyer in the mail based on her purchases.

Quote:

Pole identified 25 products that when purchased together indicate a women is likely pregnant. The value of this information was that Target could send coupons to the pregnant woman at an expensive and habit-forming period of her life.

Neither of your examples are related to clearing cookies and caches.

The first is just a fantasy based without facts or details.

The second is well documented NOT to be related to cookies or web caches, but is related to the computer records of the purchases of the girl in the story. The article ends with an apology:

Quote:

On the phone, though, the father was somewhat abashed. "I had a talk with my daughter," he said. "It turns out there's been some activities in my house I haven't been completely aware of. She's due in August. I owe you an apology."

Can we please stick to the facts of "cookies" and "caches" which you advised people to clear "for their own good".

Neither of the scenarios you posted are relevant to that. I am sorry to inform!!

On the other hand, even if the girl in the "real story" above cleared her cookies and cache, she would have still got the coupons because she was targeted (marketing) because of her purchase history with the company in their database, not because of "cookies" or "caches" in browsers.

Neo

View Public Profile for Neo

Visit Neo's homepage!

Find all posts by Neo

LEARN ABOUT DEBIAN

sux

SUX(1)								   User Commands							    SUX(1)

NAME

       sux - wrapper around su which will transfer your X credentials

SYNOPSIS

       sux [OPTS] [-] [[username] [ARGS]]
       suxterm [OPTS] [-] [username]

DESCRIPTION

       sux is a wrapper around the standard su command which will transfer your X credentials to the target user.

       Note, suxterm forces ARGS to be 'xterm', and will try to launch an xterminal window.

QUICK CALLING

	'sux user' and 'sux - user' behave just like su but transfer $DISPLAY and the X cookies.

OPTIONS

       --untrusted
	      To generate an untrusted cookie, see 'xauth'.

       --timout <period>
	      To generate a temporary cookie for <period> seconds, see 'xauth'.

       -m,-p --preserve-environment
	      In  this	case  sux will override XAUTHORITY to the so that xauth does not try to use the original user's .Xauthority file (which it
	      obviously could not do anyway due to access rights).

       --no-cookies
	      Just transfer DISPLAY, not the cookies. You could do this if you have already transfered the cookies in  a  previous  invocation	of
	      sux.

       --copy-cookies
	      Copy the cookies using xauth. This is the default method (and only method most of the time).

       --use-xauthority
	      Instead of transfering the cookies, set the XAUTHORITY environment variable to access the original .Xauthority file.  There's a cou-
	      ple caveats with this method. First, due to the access right issues it's only usable by root. But even then it may not work  if  the
	      .Xauthority  file is accessed via NFS, e.g. if the home directories are on NFS (note that this is quite dangerous already since your
	      cookies will travel unencrypted over the network). Then, if root runs commands like xauth add/remove,  the  .Xauthority's  ownership
	      will  belong  to him. This will leave the original user in trouble as he will no longer be able to access X! So only use this option
	      with great care. Finally, this method does not work if you also want to use '--untrusted' or '--timeout'.

       --display
	      specify which display to use (in case of having more than one available).

AUTHOR

       Originally written by Francois Gouget <fgouget@free.fr> Manpage written by Millis Miller <millis@faztek.org>

REPORTING BUGS

       Report bugs to <millis@faztek.org>.

COPYRIGHT

       Copyright (C) 2003 Free Software Foundation, Inc.
       This is free software; see the source for copying conditions.  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICU-
       LAR PURPOSE.

SEE ALSO

       su (1), xauth (1)

sux 1.0 							     Sept 2003								    SUX(1)