Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Slashback Graphics Mozilla Software The Internet Debian Toys News

Slashback: Pie, Election, Alarm 158

Slashback this evening with another batch of updates and responses to previous Slashdot posts, including: how Firefox users can avoid post-cookie Web tracking (for now), more on open-source graphics drivers, and an alarm clock that sounds perfect for annoying a spouse. Read on for the details.

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."

This discussion has been archived. No new comments can be posted.

Slashback: Pie, Election, Alarm

Comments Filter:
  • Broken Link (Score:4, Informative)

    by Anonymous Coward on Thursday April 14, 2005 @08:07PM (#12240006)
    The unichrome link is broken:

    http://unichrome.sourceforge.net/ [sourceforge.net]

  • Re:Uhhhh (Score:5, Informative)

    by Sparr0 ( 451780 ) <sparr0@gmail.com> on Thursday April 14, 2005 @08:16PM (#12240060) Homepage Journal
    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.
  • Cookie Madness (Score:5, Informative)

    by shirai ( 42309 ) on Thursday April 14, 2005 @08:47PM (#12240233) Homepage
    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.
  • by Indy Media Watch ( 823624 ) on Thursday April 14, 2005 @08:58PM (#12240290) Homepage
    Clocky [mit.edu] 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.
  • by eco2geek ( 582896 ) <eco2geek.gmail@com> on Thursday April 14, 2005 @09:05PM (#12240335) Journal
    ...referenced above, and in the previous YRO article [slashdot.org], to set your privacy preferences, or use a Firefox extension. All you have to do is right-click on a Flash object in a web page to bring up a context menu, and choose "Settings..." (although one wonders if this could be disabled at the Flash object author's choosing).

    (Actually, I find it more disturbing that a Flash object in a web page could access a local webcam or microphone. Has anyone seen this capability in use?)

    Thanks to "bigtallmofo" for bringing this to our attention in the previous YRO article. Who knew?

  • Alarm clocks (Score:4, Informative)

    by Sir Holo ( 531007 ) * on Thursday April 14, 2005 @09:09PM (#12240355)

    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.
  • by jessmeister ( 225593 ) on Thursday April 14, 2005 @09:22PM (#12240431) Homepage
    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
  • by mckyj57 ( 116386 ) on Thursday April 14, 2005 @10:19PM (#12240773)
    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."


    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.
  • by Daengbo ( 523424 ) <daengbo&gmail,com> on Thursday April 14, 2005 @10:56PM (#12240999) Homepage Journal
    xmms has a plugin for this, called "Alarm." It might be easier for you to set the alarm once for the whole week (different times for each day...)
  • by Short Circuit ( 52384 ) * <mikemol@gmail.com> on Thursday April 14, 2005 @11:01PM (#12241019) Homepage Journal
    HTTP authentication would require the server to track session state.
  • by poofyhairguy82 ( 635386 ) on Thursday April 14, 2005 @11:01PM (#12241024) Journal
    A couple things:

    Xorg (I bought an NVIDIA card just to use its new features). Fading and transparacy is awesome.

    Much better art.

    Community

    Newer version of GTKPod.

  • Re:Wakeup watch... (Score:1, Informative)

    by Anonymous Coward on Thursday April 14, 2005 @11:07PM (#12241060)
    This guy is blogging about it, but it doesn't seem so positive. http://waterflavored.blogspot.com/ [blogspot.com]
  • by sqlrob ( 173498 ) on Thursday April 14, 2005 @11:54PM (#12241305)
    That's what companies like DoubleClick do, and MSN pulls tricks to allow the cookies to work across domains.

    And it's tied to the domain of the site placing it, not the IP. Many sites have an image from the ad trackers (a single, invisible pixel, aka web bug) for placing the cookie. Those images can also be in e-mails that are rendered as HTML (look below the final </html> in the message source, they're commonly there)

  • by Ford Prefect ( 8777 ) on Friday April 15, 2005 @07:32AM (#12242886) Homepage
    Why is it that no one uses the HTTP authentication mechanism for logins, and instead makes cookies do the job?

    Because the standard HTTP authentication mechanism is a bit ... Crap?

    The standard, most widely supported 'Basic' version makes the browser send the username and password in plaintext on every page request. Okay, without SSL, any login mechanism will transmit the password at least once, but 'Basic' makes it a bit too easy for packet sniffers and the like.

    Also, a bit more seriously, there's no standard way of getting the browser to clear its cached username and password beyond quitting the browser completely. It's as if someone entirely forgot that part of the standard, and thus it's a bit annoying.

    Cookies are a useful side-route around these problems; I rewrote my standard login system thingy recently to use a cookie containing a username and a long 'hash' string - the password is only transmitted once, then that login session is tied to a specific IP address (or rather, range of addresses to take account of multiple proxy servers and similar). It's hardly hyper-secure, but it's an improvement, and it's far easier to do with cookies than with any standard HTTP authentication.

    I do agree that cookies are horribly overused. I only ever set them when I absolutely need to store information client-side (and then it's only ever a reference to stuff stored in a database on the server) - other programmers seem to set as many cookies as they can, in the hope that some might be useful...

If you have a procedure with 10 parameters, you probably missed some.

Working...