Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Privacy

20 Hours a Month Reading Privacy Policies 161

Posted by kdawson from the half-the-bailout-every-year dept.
Barence sends word of research out of Carnegie Mellon University calling for changes in the way Web sites present privacy policies. The researchers, one of whom is an EFF board member, calculated how long it would take the average user to read through the privacy policies of the sites visited in a year. The answer: 200 hours, at a hypothetical cost to the US economy of $365 billion, more than half the financial bailout package. Every year. The researchers propose that, if the industry can't make privacy policies easier to read or skim, then federal intervention may be needed. This resulted in the predictable cry of outrage from online executives. Here's the study (PDF).
Censorship

Submission + - Removal of Anti-Scientology Videos on Youtube (eff.org) 1

Submitted by Anonymous Coward
An anonymous reader writes: From the EFF webpage: "Over a period of twelve hours, between this Thursday night and Friday morning, American Rights Counsel LLC sent out over 4000 DMCA takedown notices to YouTube, all making copyright infringement claims against videos with content critical of the Church of Scientology."

Comment Re:Please enter your credentials here: (Score 1) 157

by chrisv (#21911296) Attached to: Firefox Spoofing Bug Puts Passwords At Risk

The realm is only half of the identifying element - the URL requesting authentication is the other half. For basic authentication (RFC 2617, section 2), the realm value is only for the server sending it; if another server (identified typically by [ http/https, hostname, port ]) sends me a WWW-Authenticate header with the same realm name specified, for the purposes of authentication it is a different realm. In digest authentication (section 3), it is possible to have credentials go across multiple servers, but such servers have to be specified in the initial WWW-Authenticate header in a "domain" parameter; otherwise, the authentication is again only available to the server sending the WWW-Authenticate header in the first place.

Ultimately, unless your system, DNS server, proxy server (if you're using one), gateway, or the target server, have been broken into, obtaining the credentials for any given realm is going to be difficult; if your system has been broken into, this is pointless because they could just as easily install a keylogger to capture the authentication information as it's being entered; if your gateway has been broken into, then unless you're performing all authenticated transactions over HTTPS and/or not using HTTP Basic authentication, the information is going across there in cleartext anyway, and tcpdump is all that's needed to extract it. Since the proxy server tends to exist at the gateway level anyway, the same issues apply there. As far as the target server goes - you can either capture the authentication info there, or, since you've got permissions to do anything the webserver is capable of, including generally accessing the authentication DB, just grab the authentication information and be done with it.

So... good luck at attempting to reuse the exact realm of another server - since, for the purposes of comparing authentication realms, the realm name is little more than a token which identifies a given protection space on a single server (or multiple explicitly specified servers in HTTP Digest, but that's still explicit).

Slashdot Top Deals

To the systems programmer, users and applications serve only to provide a test load.

Close