You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!

Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.

If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.

Having a problem logging in? Please visit this page to clear all LQ-related cookies.

Introduction to Linux - A Hands on Guide

This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.

When one "deletes private data" in both the Linux and Windows versions of Opera 10 (and the latest bug fix) it triggers the installation of a tracking cookie from www.kelkoo.com. The only way to get rid of it is to manually go in and delete it.

One person has referred to it as a "bundled cookie."

So far there has been nothing from "management" at Opera explaining this cookie and its purpose. A bug report has been made, but it was not removed from the latest release (bug fix).

Does this mean there are other cookies that users are not seeing? What are the ethics involved? Seems downright sleazy and unethical to me.
Thanks.

If you disable network access for Opera, then run Opera for the first time (or with a clean profile like 'opera -pd ~/.opera_testprofile') then close it, there is a bookmark for that site in bookmarks.adr. AFAIK the cookie jar does not contain a cookie for the site. So it could be that Opera tries to retrieve the favicon which could trigger the cookie getting set. A healthy dose of paranoia is commendable but if you want to talk devious behaviour it (in my book) comes nowhere the default Firefox behaviour of actively querying URI's when you click a bookmark entry once (like if you want to change properties)...

Just FYI, this problem turned out to be a "favicons" (whatever that is), in this case, kelkoo.com (a tracking site), setting a cookie.
I'm not sure exactly why "favicons" should be allowed to set cookies and I'm not sure of the ethics of doing such a thing, but, regardless, I have Opera set up to only accept cookies from the sites I visit and to delete them upon exit.
This was fixed in build #4609.

There are several about:config entries that revolve around FF querying "safe sites", a.k.a. "vetting your search for you" which can be set to "disable".

Directly to the point: I am not *certain* that these entries affect bookmarks specifically, or how, if they do (like as UnSpawn suggests, querying the URI if you're simply changing bookmark properties -- which I don't like either).

One or more of the provided links or posts at the above thread, shows you the about:config entries to prevent automatic vetting of your searches.

Until someone else can identify a means of disabling the URI queries on such actions as editing bookmark properties, I'd start by opening wireshark and seeing what happens when you edit a bookmark (purely informational, I know; it doesn't much help you turn off the behavior).

And FYI: "favicons" are the tiny icons that appear in your address-bar, or beside bookmark entries. The name comes from "Favorites + Icons"