Slashdot Mirror
Slashback: Pie, Election, Alarm
Does he feel like Reese Witherspoon? Joe 'Zonker' Brockmeier writes "After many years of trying, Branden Robinson has finally won the Debian Project Leader election. Linux Magazine has an in-depth interview with Robinson about his plans as DPL, the problems that face Debian, and what it's like to finally win the election."
(We mentioned Robinson's election a few days ago.)
In lieu of perfection, fixability is a good start. gyardley writes "After discovering that a company called United Virtualities was making use of Flash's Local Shared Objects to silently restore my deleted cookies, I decided to combat this marketer behavior with a Firefox extension.
Objection 0.1 adds a 'Local Shared Objects' line to Firefox's Options > Privacy panel, allowing you to delete them as easily as you'd delete cookies. It's still pretty rudimentary - all or nothing deletion, working on Windows only - but Slashdotters are more than welcome to improve it. Since Local Shared Objects have the same functionality as cookies, we need the same amount of control over them as we do over cookies - and built into the browser, not tucked away in some obscure Macromedia page."
Sure, come on in, there's still some punch and snacks left, I think. orv writes "The Unichrome project has issued a response to VIA's recent open source announcement covered on Slashdot.
The response (and further comment) clarifies the current Unichrome driver situation and whilst welcoming VIA's move suggests that VIA should become more involved in existing open source projects rather than simply issuing repeated grand sounding press releases. The Unichrome project has provided and supported a full open source driver, including MPEG support, for the Unichrome and Unichrome Pro chipsets for the past two years."
But this implies that 'perky' is the desired state. dhalsim2 writes "Yahoo reports of a Smart Alarm Clock Set for Perky Wakeups. On the heels of Clocky comes this new alarm clock that will monitor a sleeper's brain waves to determine the best time to wake him up. The device uses a microprocessor within a headband that wirelessly transmits brainwaves to the clock. When the person is in a light sleep and is likely to wake up 'perky,' the alarm will go off. Brain wave monitoring? Sounds a lot like Plankton's Plan Z."
The unichrome link is broken:
http://unichrome.sourceforge.net/
The device monitors how deeply you are sleeping, if you are dreaming, etc. If you are woken up when you are sleeping lightly you are likely to wake up quickly, but if your alarm interrupts a dream you tend to wake up slowly and more tired. Have you ever woken up early and felt ready to go, but felt like sleeping til your alarm goes off... then when it does you feel tired? This prevents that by picking a time close to your target wakeup time (but before your cutoff time) when you are the least likely to wake up tired.
I'm probably not the first one who's thought of this but it seems to me that cookie abuse could be reduced dramatically without affecting most websites by doing the following:
"Disable cookies on all images that are being pulled from another domain."
That is, if a web page grabs an image from another domain (a banner, pixel, etc.) then pull it but don't send any of the cookie information for that image.
I mean isn't that the way that most developers track access across websites? You put a one-pixel image and set the cookie through there. Then by reading the http_refer, you know where they've been and associate it to a single user. To track across sites though, this pixel is usually on a separate domain than the site being accessed.
By the way, I originally thought to disable cookies on all images but realized some servers may do security checking via cookies before sending an image. But there is very little legitimate use for sending cookies on images that are outside the domain.
Also, the same could be said of ANYTHING that is pulled off a different domain including scripts, css, etc. If it is on the same domain, send the cookies. If not, then make the request but don't send the cookies.
I would say precious few sites would depend on this behavior and it shouldn't break anything except for the tracking (which we want to break). Not saying that a site couldn't be made to break on this but I can't think of many reasons why a site would.
By the way, I think cookies are great for the most part. SlashDot uses them, I use them, anything with a login (mostly) uses them. I find it humorous when people insist that cookies are evil and you shouldn't have a single one. You can just as easily fake a cookie for a session by sticking an ID in the URL which, personally, I think is worse. Now your personally identifying tracker is available for all to see.
Sunny
Be my Friend
Clocky is a clock for people who have trouble getting out of bed. When the snooze bar is pressed, Clocky rolls off the table and finds a hiding spot, a new one every day.
Indy Media Watch-Proctologist of the Internet
This may beat the 90-minute rule.
Sleep cycles are about 90 minutes long, so setting the alarm at a 90-minute interval from when you fall asleep will make it more likely that you'll wake up on the high side of sleep, and more likely that you'll feel refreshed. The rule fails if something disturbs your sleep pattern, though, which is where this device (if it exists) would be better.
There is no way that a cookie is relaying your email information. They only way a site can even look at a cookie is if they set it. Otherwise its a no go. The only way a cookie could contain your email address is you gave it previously to that site. In which case thats the source of your spam
I find it easier just to use the Flashblock extension. In the (very rare) event I need to run a Flash display, I just click the play button.