Of course, we have the minor problem that nobody in government has glanced at or otherwise considered the contents of the Constitution since... I'm going to say 9/12/2001.
The 911 dispatchers require additional equipment, not the police and fire departments mentioned in the summary. They just go wherever the dispatcher says to go.
Billions? We're not fruit flies. Even if Gen1 produces 20 females who all start reproducing at age 12 (obviously this biological thought experiment ignores social bounds) and also produce 20 more females, you're "only" at 64m people in Gen7. Who, by the way, are all retarded from all the inbreeding.
Most (if not all) of Facebook's account settings pages go over an HTTPS connection. I'd be astonished if there isn't one for auth that's secure-only, since it's effectively pointless if you're trusting cookies that could have been exposed over an http request for requests that require decent authentication.
Of course, Facebook is hardly known for its security. I turned on the HTTPS-everywhere setting the moment it was available on my account. I did spot a "c_user" secure-only cookie that contained only my user ID... god help us if that's what they authenticate against.
$hash = crypt($plaintext, '$2a$07$1234567890123456789012');//use algorithm of choice if ($hash_from_db === $hash) login(); else invalid_password();
So yeah, it really is as easy as switching the calls*. Sending the password in plaintext to the database and letting the query hash it is just stupid - not only does it limit your hashing options to those supported by the database, but you're sending that plaintext password to a different machine over a non-secure channel (assuming your DB and web servers are two separate systems, of course). Then anyone on the network can just sniff the connection between web and db boxes. Not good.
This is also a problem for memcache, which is wide open to the world if you're on most virtual "cloud" hosting, like rackspace cloud or aws, unless you've configured the firewall correctly. Just telnet into a random 10.x.x.x system on port 11211 from a $10/month cloud server and see what you get. It's not even password protected. If you're registered on any site with moderate traffic, there's a decent chance your information can be leaked without the database being directly compromised. Not having a private backchannel for your cloud-based website is very dangerous with a misconfigured set of iptables rules.
Of course, this only applies to "real" websites, not some out of date wordpress install on a $2/month godaddy hosting plan. Those are beyond hopeless.
*Well, ignoring the fact that you need to deal with legacy passwords. That just sucks. But upgrade on next login, and force expiration of all old passwords after so much time has elapsed.
It's Google algorithm, they can do whatever the hell they want with it. Hell, they might actually have to - the MPAA would probably try to get a gag order on anything that went to trial. And as noted above, "Google may temporarily or permanently remove sites from its index and search results if it believes it is obligated to do so by law, if the sites do not meet..."
It's not like we, as people connected to the internet, have an SLA from Google. Sure, we expect them to return the best results, and if they de-index all content relating to major motion pictures and that negatively impacts our browsing, we're free to Bing away. But unlike ISPs that are merely providing data, Google is providing a (free) service and have no legal obligations to keep it neutral (at least to my knowledge, IANAL)
Google's response: removing all search results for MPAA-backed content. MPAA collapses. Job well done, boys. "Suicide by Google" is certainly an interesting way to finally snuff yourself out.
You don't distribute the RAW, just process it. Send only small (not suitable for print) and/or watermarked images until you have the licensing fee in hand if you're trying to get money for the photos. Once they pay, they get a full-res, non-watermarked jpeg. You know, exactly like how stock photo sites work - at least from the buyer's perspective.
A massive undertaking by programmers worldwide in order to prevent a catastrophic meltdown. Completed just in time in a way that's transparent to the rest of the world, making it seem like no big deal.
Yeah, actually it'll probably be quite a lot like Y2K in that sense.
This seems pretty similar to Gmail's aliasing - append anything after a plus sign to your email address (ex firehed+slashdot@gmail.com) and it goes to your main inbox. If that address is compromised, just filter anything addressed to that account.
Microsoft seems to have a few advantages here, though. First, it's a lot more seamless. Second, there are tons of websites that incorrectly validate email addresses and treat + as an illegal character, which it is not (hell, you can go directly to an IP address instead of a domain, although nobody ever would), so by extension it's harder to use as a throw-away address. And third, it's pretty obvious you've done it, and websites can just s/\+[A-z0-9.-]+@gmail.com/@gmail.com/g it into oblivion.
Of course, in order to get this functionality, you need to use hotmail. Aren't those already throw-away accounts by definition?
Abuses like this aren't exactly like speeding (which aside from being quite possible to do without trying or even realizing it, is relatively harmless) - you have to go out of your way to set up wiretaps and perform other actions that violate America's core values. I can accept a small handful of instances where the time required to go through the proper channels (warrants, etc) would have taken too long, but that should be the exception rather than the rule - and some five thousand times per year is hardly an exception. That basically means one of three things - the process is broken, these people are doing things they have no need, right, or reason to do, or federal policy has agreed upon our constitution being worthless. If the latter is the case, fine - bring on the revolution, since we've voided the existence of our government and all of the laws it has created.
Of course not. Restricting access to, for instance, medical records could result in a fatal allergic reaction to a medicine that would have been caught with that data. But on the flip side, an attacker having access to that data could make a kill that much easier.
Data is not the problem, nor is access. People that want to do harmful things are the problem. Fix them, not the data.
"...often use mobile phones as detonators with the bomber's handler, who is usually watching their charge, sending the bomber a text message to set off his or her explosive belt at the moment when it is thought they can inflict maximum casualties "
Strictly speaking, yes. The term they should* be using is "unmetered". Unlimited should mean not only unmetered, but that your pipe is also infinitely wide, which is obviously impossible.
* If it was, in fact, unmetered. Which is almost never the case. In theory I've inherited my old "unlimited" iPhone plan, but it's hardly relevant as I only use about 400MB/month. Yay for WiFi.
You have one thing on the page going over http and invoke the wrath of the browser gods. Combined with third-party apps, you have a recipe for disaster. Relatively speaking, getting everything set up for the CDN is trivial.
Speaking as someone who works on an HTTPS-only site, there are a lot of little things that really add up to being a huge pain in the ass. Embedded videos are always a problem (*cough*Vimeo*cough), and it's easy to come across odd little dependencies through a piece of analytics code or what have you that throws a red flag.
It would be really nice if you could embed something in the certificate or the HTML (that cannot be modified by JS) that allows browsers to selectively include HTTP content in an HTTPS page without going nuts. There's generally no value in having images or most other static resources over HTTPS, but it's currently all or nothing.
Now just get the comment linking to work as you'd expect (and as a subset of that, having the score slider thing also work correctly) and I'm a happy camper.
Huh. Sure enough, having 3 slashdot tabs open is eating an entire core for me (out of 8, so meh - but still...). Spending five seconds with Chrome's JS profiler reveals the guilty party: adupdate:
So, run this very computationally-intense function (that selector is pretty bad, and the width calculation is disgusting) in a continuous loop. Nice work, guys. The goal of this is what, exactly? Continually scan the width of the banner ad, and if it's not 728px, hide it, otherwise show it? Oooookay....
I could see this as valid to run... once. Even once every five seconds, if there's a good reason for it. But calling itself again after a 0ms delay? *sigh*
I must be the only one not having this problem. The font seems to be the same size as just about every other page I've seen (inspector says 13px Arial, which definitely falls in "typical" range), and scales correctly with zooming the page - in or out. Of course, zooming continues to be miserably slow, but that's a ton of document reflowing to do (fluid-width sites always seem much slower to zoom, which makes enough sense) so that's not *entirely* Slashdot's fault.
FWIW, this is Chrome 8.something on OS X. Looks the same in Firefox.
Indeed. Opening a slashdot v2 page would lock up my browser completely for several seconds while some sort of massive javascript fail was occurring - really nasty when skimming google reader and opening half a dozen pages. Doesn't appear to be the case anymore. Still a bit slow to scroll (even on my 8-core workstation with 10GB RAM) but I guess that's a hazard of having hundreds of nested comments cluttering up the DOM.
Depending on what you're searching for, ads can actually be the most relevant result. While I generally avoid clicking ads, if I'm looking for products, then I'm looking for a store, and dicey review aggregator sites are of no help to me, but the company willing to spend a dollar to get me as a customer happens to be exactly what I need. I'm going to click what appears to be the most relevant result, which on occasion actually is an ad.
And it's in their best interest to ensure the ads are as relevant as possible, not because they get clicked more (earning them more money), but because it makes the search results appear more relevant. If the search results appear to suck because crappy ads are bubbling to the top, people will take their searches elsewhere. From what I hear, it's very difficult (and expensive) to fix that bad reputation as an advertiser with Google - that's to say that wasting ten grand on lousy ads will cost another 20-40k in lower-ranking but good ads before Google will start to trust you again and let your stuff make it to the top of the page.
Bottom line is that you're right - ad results don't need to be better than the search results. People expect to click around a bit to find what they want. But consistently having crap at the top of the page would drive people to try other search engines, so the ads still need to be reasonably well targeted.
Slashdot Mirror
Of course, we have the minor problem that nobody in government has glanced at or otherwise considered the contents of the Constitution since... I'm going to say 9/12/2001.
The 911 dispatchers require additional equipment, not the police and fire departments mentioned in the summary. They just go wherever the dispatcher says to go.
Billions? We're not fruit flies. Even if Gen1 produces 20 females who all start reproducing at age 12 (obviously this biological thought experiment ignores social bounds) and also produce 20 more females, you're "only" at 64m people in Gen7. Who, by the way, are all retarded from all the inbreeding.
Most (if not all) of Facebook's account settings pages go over an HTTPS connection. I'd be astonished if there isn't one for auth that's secure-only, since it's effectively pointless if you're trusting cookies that could have been exposed over an http request for requests that require decent authentication.
Of course, Facebook is hardly known for its security. I turned on the HTTPS-everywhere setting the moment it was available on my account. I did spot a "c_user" secure-only cookie that contained only my user ID... god help us if that's what they authenticate against.
$hash = crypt($plaintext, '$2a$07$1234567890123456789012'); //use algorithm of choice
if ($hash_from_db === $hash)
login();
else
invalid_password();
So yeah, it really is as easy as switching the calls*. Sending the password in plaintext to the database and letting the query hash it is just stupid - not only does it limit your hashing options to those supported by the database, but you're sending that plaintext password to a different machine over a non-secure channel (assuming your DB and web servers are two separate systems, of course). Then anyone on the network can just sniff the connection between web and db boxes. Not good.
This is also a problem for memcache, which is wide open to the world if you're on most virtual "cloud" hosting, like rackspace cloud or aws, unless you've configured the firewall correctly. Just telnet into a random 10.x.x.x system on port 11211 from a $10/month cloud server and see what you get. It's not even password protected. If you're registered on any site with moderate traffic, there's a decent chance your information can be leaked without the database being directly compromised. Not having a private backchannel for your cloud-based website is very dangerous with a misconfigured set of iptables rules.
Of course, this only applies to "real" websites, not some out of date wordpress install on a $2/month godaddy hosting plan. Those are beyond hopeless.
*Well, ignoring the fact that you need to deal with legacy passwords. That just sucks. But upgrade on next login, and force expiration of all old passwords after so much time has elapsed.
It's Google algorithm, they can do whatever the hell they want with it. Hell, they might actually have to - the MPAA would probably try to get a gag order on anything that went to trial. And as noted above, "Google may temporarily or permanently remove sites from its index and search results if it believes it is obligated to do so by law, if the sites do not meet..."
It's not like we, as people connected to the internet, have an SLA from Google. Sure, we expect them to return the best results, and if they de-index all content relating to major motion pictures and that negatively impacts our browsing, we're free to Bing away. But unlike ISPs that are merely providing data, Google is providing a (free) service and have no legal obligations to keep it neutral (at least to my knowledge, IANAL)
Google's response: removing all search results for MPAA-backed content. MPAA collapses. Job well done, boys. "Suicide by Google" is certainly an interesting way to finally snuff yourself out.
But /dev/null came with my system for free!
You don't distribute the RAW, just process it. Send only small (not suitable for print) and/or watermarked images until you have the licensing fee in hand if you're trying to get money for the photos. Once they pay, they get a full-res, non-watermarked jpeg. You know, exactly like how stock photo sites work - at least from the buyer's perspective.
A massive undertaking by programmers worldwide in order to prevent a catastrophic meltdown. Completed just in time in a way that's transparent to the rest of the world, making it seem like no big deal.
Yeah, actually it'll probably be quite a lot like Y2K in that sense.
This seems pretty similar to Gmail's aliasing - append anything after a plus sign to your email address (ex firehed+slashdot@gmail.com) and it goes to your main inbox. If that address is compromised, just filter anything addressed to that account.
Microsoft seems to have a few advantages here, though. First, it's a lot more seamless. Second, there are tons of websites that incorrectly validate email addresses and treat + as an illegal character, which it is not (hell, you can go directly to an IP address instead of a domain, although nobody ever would), so by extension it's harder to use as a throw-away address. And third, it's pretty obvious you've done it, and websites can just s/\+[A-z0-9.-]+@gmail.com/@gmail.com/g it into oblivion.
Of course, in order to get this functionality, you need to use hotmail. Aren't those already throw-away accounts by definition?
Yes, they are.
Which I only know after searching Wikipedia to figure out what the hell everyone was talking out, the uncultured slob that I am.
Abuses like this aren't exactly like speeding (which aside from being quite possible to do without trying or even realizing it, is relatively harmless) - you have to go out of your way to set up wiretaps and perform other actions that violate America's core values. I can accept a small handful of instances where the time required to go through the proper channels (warrants, etc) would have taken too long, but that should be the exception rather than the rule - and some five thousand times per year is hardly an exception. That basically means one of three things - the process is broken, these people are doing things they have no need, right, or reason to do, or federal policy has agreed upon our constitution being worthless. If the latter is the case, fine - bring on the revolution, since we've voided the existence of our government and all of the laws it has created.
Of course not. Restricting access to, for instance, medical records could result in a fatal allergic reaction to a medicine that would have been caught with that data. But on the flip side, an attacker having access to that data could make a kill that much easier.
Data is not the problem, nor is access. People that want to do harmful things are the problem. Fix them, not the data.
Come on, it's right in TFS.
"...often use mobile phones as detonators with the bomber's handler, who is usually watching their charge, sending the bomber a text message to set off his or her explosive belt at the moment when it is thought they can inflict maximum casualties "
No, but if our normal clamoring about privacy is consistent with this story, it hopefully required them to get a warrant first. That can take time.
Strictly speaking, yes. The term they should* be using is "unmetered". Unlimited should mean not only unmetered, but that your pipe is also infinitely wide, which is obviously impossible.
* If it was, in fact, unmetered. Which is almost never the case. In theory I've inherited my old "unlimited" iPhone plan, but it's hardly relevant as I only use about 400MB/month. Yay for WiFi.
You have one thing on the page going over http and invoke the wrath of the browser gods. Combined with third-party apps, you have a recipe for disaster. Relatively speaking, getting everything set up for the CDN is trivial.
Speaking as someone who works on an HTTPS-only site, there are a lot of little things that really add up to being a huge pain in the ass. Embedded videos are always a problem (*cough*Vimeo*cough), and it's easy to come across odd little dependencies through a piece of analytics code or what have you that throws a red flag.
It would be really nice if you could embed something in the certificate or the HTML (that cannot be modified by JS) that allows browsers to selectively include HTTP content in an HTTPS page without going nuts. There's generally no value in having images or most other static resources over HTTPS, but it's currently all or nothing.
Holy crap, they actually fixed it. Thanks, guys.
Now just get the comment linking to work as you'd expect (and as a subset of that, having the score slider thing also work correctly) and I'm a happy camper.
Huh. Sure enough, having 3 slashdot tabs open is eating an entire core for me (out of 8, so meh - but still...). Spending five seconds with Chrome's JS profiler reveals the guilty party: adupdate:
adupdate(){
if($("#tophat #fad1 img, #tophat #fad1 iframe, #tophat #fad1 embed, #tophat #fad1 div, #tophat #fad1 table").width()!=728) {
$("#tophat").remove();
setTimeout("adupdate()",0)
}else{
$("#tophat").show();
setTimeout("adupdate()",0)
}
}
So, run this very computationally-intense function (that selector is pretty bad, and the width calculation is disgusting) in a continuous loop. Nice work, guys. The goal of this is what, exactly? Continually scan the width of the banner ad, and if it's not 728px, hide it, otherwise show it? Oooookay....
I could see this as valid to run... once. Even once every five seconds, if there's a good reason for it. But calling itself again after a 0ms delay? *sigh*
Please fix this, guys.
I must be the only one not having this problem. The font seems to be the same size as just about every other page I've seen (inspector says 13px Arial, which definitely falls in "typical" range), and scales correctly with zooming the page - in or out. Of course, zooming continues to be miserably slow, but that's a ton of document reflowing to do (fluid-width sites always seem much slower to zoom, which makes enough sense) so that's not *entirely* Slashdot's fault.
FWIW, this is Chrome 8.something on OS X. Looks the same in Firefox.
Indeed. Opening a slashdot v2 page would lock up my browser completely for several seconds while some sort of massive javascript fail was occurring - really nasty when skimming google reader and opening half a dozen pages. Doesn't appear to be the case anymore. Still a bit slow to scroll (even on my 8-core workstation with 10GB RAM) but I guess that's a hazard of having hundreds of nested comments cluttering up the DOM.
Still, I'll take it.
I don't think excuses ripen with age.
Although with what old people get away with, I could be very wrong.
Depending on what you're searching for, ads can actually be the most relevant result. While I generally avoid clicking ads, if I'm looking for products, then I'm looking for a store, and dicey review aggregator sites are of no help to me, but the company willing to spend a dollar to get me as a customer happens to be exactly what I need. I'm going to click what appears to be the most relevant result, which on occasion actually is an ad.
And it's in their best interest to ensure the ads are as relevant as possible, not because they get clicked more (earning them more money), but because it makes the search results appear more relevant. If the search results appear to suck because crappy ads are bubbling to the top, people will take their searches elsewhere. From what I hear, it's very difficult (and expensive) to fix that bad reputation as an advertiser with Google - that's to say that wasting ten grand on lousy ads will cost another 20-40k in lower-ranking but good ads before Google will start to trust you again and let your stuff make it to the top of the page.
Bottom line is that you're right - ad results don't need to be better than the search results. People expect to click around a bit to find what they want. But consistently having crap at the top of the page would drive people to try other search engines, so the ads still need to be reasonably well targeted.
Scroll down. WAY down. EE serves the same content to google, they just don't make it obvious. That said, I completely agree about blacklisting.