I have no inside details on AT&T or Facebook, but what you've described is almost certainly the problem. AT&T very likely use fairly aggressive caching proxies, especially lately to help mitigate their infamous capacity issues. I'd say that what happened here is pages are being cached without proper regard for cookies. That's fine for sites that don't have custom accounts, and only use cookies for tracking various page view statistics. But Facebook (like nearly every other site in the world that requires a login) issues a cookie to identify you, once you've entered your credentials. So that cookie is how the server knows it's you, and not somebody else. If AT&T's forward caching proxies ignore this cookie, and just give you the most recent page served from Facebook, you're sure to hijack somebody else's session. And, since your first request sends your new credentials, the person you've hijacked (if still online) will now have passively hijacked your session, explaining the last scenario from TFA where sessions appeared to have been swapped.
Could California declare "no more swastikas" and force Activision to edit California editions of Wolfenstein, or would the U.S. overrule that decision?
I'm not sure how serious you were, but (sorry in advance for a car analogy) California already requires stricter emissions rules than most other states, and car makers of all kinds (US and imports) must comply in order to have their cars sold in that state.
Unless a state law is somehow challenged and found to be unconstitutional, it would stand. One would guess that the display of swastikas would be protected speech (and thus laws against it unconstitutional). However, given the attention to "hate crimes" apparently gaining a lot of focus, you never know.
That's an excellent idea for general "stay in touch" communications, and even blogging about their travels, but he also mentioned a business, and commercial use of ham radio is prohibited.
The submitter and nearly everybody else here seems to have totally missed the most relevant aspect, namely that this was fundamentally an IT problem.
There was a gas-gauge style graphic on the cars.gov web site, which displayed "real time" status of funds remaining. As of Thursday evening, the it was still showing $779 million remaining for most cars (excluding certain trucks) out of the initial $1 billion, and the last update time for the display clearly indicated 10:00am. Meanwhile dealers were already waving off customers, telling them that the program was suspended. Consider that you tell your boss in the morning that your project is going fine, with 3/4 of your budget remaining, only to realize by that same afternoon that your budget has actually been over-spent.
There are several IT angles here. First, when the program officially started July 25, there was only a single server hosting both the consumer and the dealer interfaces. The site was unusably slow for dealers to submit; this caused the first wave of the backlog to begin. They eventually split the application onto two servers; you can see even now that they suffixed/dealer/ as a URL path to the php pages, indicating which components are being served from the hastily added new server.
The initial backlog was magnified in the second wave, as the site has a horribly counter-intuitive user interface, meaning dealers were submitting large documents multiple times for each form page. The system requires scanned documents to be attached, and of course you can imagine what resolutions might be used by technically-naive dealers.
So the IT systems say that only 40,000 deals have been entered into the system. Only the reality is that well over 200,000 deals have been done, and they didn't realize this because they trusted the metrics. There's a 5-to-1 backlog, only 4 days into the program. Meanwhile, reports surface that a typical dealer says 150 deals were submitted to the site, yet only 30 submission confirmations were received in return, and every single one was a rejection.
Yes, I'd pin this fiasco squarely on the shoulders of the incompetent IT developers who built a crappy system that was totally inadequate for the task (but don't forget the incompetent managers that let it happen, blindly followed broken metrics, etc.). I think it's lucky that this was detected at all; this backlog could easily have gone undetected for months, in which case the program might have been overspent by many times over!
Yes, this story is indeed an interesting Technology tale, but unfortunately the submitter and editor seem to have entirely missed that point.
But the question remains -- and I don't pretend to know the answer -- whether this particular job would more properly have gone to someone who actually has a tech background.
I didn't mean to evade your original question. For what it's worth, my take is that if you can at all accept my premise above (that the field is tremendously immature) the answer to this question becomes largely insignificant. Using a somewhat holistic definition of "properly" in this context, the answer quite obviously is yes. But I see this as little more than a hypothetical answer that presumes a more mature field.
As it is, I'm not sure it makes sense to even debate this matter, until it becomes at least moderately uncommon for a non-technical person to take on such a role. Right now (and for decades to come, I might suggest) this simply doesn't qualify as an extraordinary case within this field.
Though in a way it all serves as a humbling reminder of how far the IT field has yet to evolve, from a more practical perspective I just don't find this to be an intriguing disparity; it's merely a rather banal (albeit high-profile) example of what is still a very prevalent attitude.
By the way, I don't intend any disrespect to you for posing the question, nor do I find it inappropriate to discuss in this forum. In fact, I quite appreciate that you considered my posting and replied; I'm sure you've been flooded with countless other responses.
The legal profession has arguably been around since the dawn of civilized society. IT simply hasn't existed as a profession for any substantive time, in the grand scheme of things. If all IT workers refused to work under somebody, who hasn't "been doing it longer" than they, there would hardly be any IT workers at all. Think way back to the first few decades of the legal profession; don't you suppose quite a few lawyers worked for non-lawyers?
Suppose suddenly every organization needed a legal department in this fledgling time. There aren't enough lawyers (let alone any with vast experience) to go around, so you find somebody basically competent and hopefully well-versed in the concepts, and ask them to build a team of legal experts. This person then leverages any success and eventually becomes highly prized as an executive who can bring the right resources to bear, despite limited (if any) actual legal expertise.
Further keep in mind that there's no equivalent to a "bar" concept in IT, and there's not even (yet, perhaps) a consensus that this is desirable. So there's not really a reliable mechanism to allow one to decide whether a person is minimally competent. You virtually have to be an expert yourself to recognize another expert in the IT field with any confidence.
Basically I think you're neglecting the fact that the IT field itself is still extremely immature; I'd guess it will take at least a few more career-generations to reach the state where IT people are supervised exclusively by IT people.
Microsoft should ask this MSDN blogger to do some UI consulting for them.
One could say that a feature that mysteriously turns itself on and off is worse than a feature that simply doesn't work. At least when it doesn't work, it predictably doesn't work. Human beings value predictability.
Consistency in an operating is indeed a high priority, but the designers at Microsoft think they know better and suggest "Because Windows adapts to how you use your computer, the menu items you use most will be automatically displayed in the future. So the next time you open the menu, you might not need to expand it."
Nobody wants floppy drives to spin up as soon as a disk is inserted. That just makes them think they've been attacked by a computer virus. It'd all just be a lot of work for a feature nobody wants.
If only they had remembered this lesson. Some years later they considered it vastly different to spin up a CD upon insertion. Then they figured they'd not only do that, but also trust the media enough to blindly start executing code from it.
I did have to call them to, my truck was broken into, I was actually surprised they finger printed when they were obviously dealing with a junky stealing stereo's for a fix.
If I were a cynical type, I'd suggest that perhaps they were just taking that as an opportunity to collect your fingerprints.
For what it's worth, one is an Ivy League university in New York City, the other is not. TFS is wrong but TFA is right; the editor and/or submitter must be having trouble with copy and paste.
The PDF described the attack in detail. The attacker opens a new ING account in your (logged-in) identity, transfers any amount of your money from your personal linked account into "your" new ING account, adds any arbitrary payee (the attacker's own ING account, opened previously), then transfers funds from "your" new ING account to the attacker's ING account. They say it's been fixed, but please don't presume this wasn't a major issue.
who knows of or sees these things in order to oppose them?
Anybody. The marks are published weekly for opposition. The latest few are available as PDF downloads free of charge; follow the link and you can even subscribe to the paper copy (for merely $1,536/year).
I had exactly this problem you describe, with two different Conext UPS devices. As far as I can tell, the AVR system simply doesn't work, even with a good fully-charged battery. Yes, AVR is supposed to smooth out exactly these kinds of low voltage situations, where you have another high-draw device on the same circuit. Both UPS devices ended up giving a hardware fault LED/beep code after about two years, and the only answer from Conext (really APC) was to buy a replacement unit (with some nominal credit if I returned the Conext). I've never had any problems with any (of the many) APC devices I've used over the years, beyond changing batteries more often than I'd like. I always try to get the devices with AVR; these don't click over to battery during these low voltage situations, which seems (anecdotally) to keep the batteries in better shape for longer.
The "solution" is to get a real APC, ideally a model with AVR, or a workaround is to plug the printer into a totally different circuit (often meaning another room, assuming you're talking about a residence). I've found that Conext devices are a lot less expensive for a very good reason.
I'll assume you're not trolling here. If you find you're ever kicking off all your users to deploy an update, you're doing it wrong. Session persistence is supported by most useful production servers. This can be used to share sessions among nodes of a very small cluster (even two instances of the server running on one machine) or simply save the sessions to disk and restore them after restarting the system. With a little forethought regarding backward compatibility, you won't have any problems. And your users will still be logged in.
The third-best solution is what's been done today. We just made it a lot harder to exploit the vulnerability--typically about 16000 times harder, depending on your configuration.
It seems to me that this was the fifth-best solution. In fourth place would be just using TCP instead of UDP for all traffic. It's already supported in every existing client and server, we just need to deprecate UDP; it could be done today. This would make it far harder than simply enlarging the range of guessable numbers by a handful of bits.
In third place (which is what I'd really like to see) would be using TLS over that TCP, with server validation, plus optional client validation. This uses totally stock libraries that already exist on essentially every platform.
I'd like to preemptively address any performance concerns, by saying I don't care. This won't come close to clogging our precious tubes, and we're talking about cached results anyway, so don't bother complaining about one extra TLS/TCP set of handshakes every few minutes or hours. Security always has a price in terms of convenience, and this is it.
GeoTrust announced it "signed a definitive agreement to be acquired by VeriSign" in May 2006. The acquisition was finalized around September 2006. They're still issuing QuickSSL Premium certs from Equifax.
For what it's worth, this whole article is a dupe from 2006.
Even more blatant (and even longer ago) Soap Operas started this trend. They're known as such because the whole point of every episode was to sell cleaning products to the viewers, by a combination of product placement and in-show advertising (typically given by the main actors, in character). This concept started on radio in the 1930s and continued into television over the next two decades.
Agreed, and further I think a lot of folks here are ignoring the probability that this massive object will hit more than just a single satellite. There are a lot of satellites packed into a rather constrained geosynchronous orbit. Further, even if it doesn't actually hit anything at all, it will certainly cause a number of nearly-missed satellites to have their orbits altered dramatically, perhaps irreversibly. So we'll likely have catastrophic communications failures, at the exact time we'll need to collaborate to determine our collective fate (and, hopefully, generate some mitigation strategies).
I haven't checked the Cox TOS lately, but don't they prohibit running a home web server like all the other residential internet providers? Yes. They may not actively police it, of course, but there it is.
I just don't see many admins willing or even thinking to do searches for referers accessing the *images* since images are often cached by the browser They could be compelled to do so, if served a subpoena. That's the whole idea here, by the way, and not all lawyers are technically incompetent (and no, I'm not a lawyer).
So all the "perp" would have to do for most sites would be to visit the main page directly, and then view everything else via google's cache and the only trace they'd leave was that they visited the main site and left. Yes, I know, there are many ways to avoid being logged; I mentioned several in each of my postings, and surely there are many more. Even your workaround isn't guaranteed to work, in cases where the site happens to have any non-shared image on the page (such as a text-as-graphic heading; not a best practice, but not exactly unheard of). Anyway, the idea here is that simply using Google's cache to browse a page--and taking no further steps--is in itself insufficient to keep you out of the server logs that are being subpoenaed in this case. I'm not sure why you're belaboring the point, to be honest, as it seems you agree with this main premise, yet you continue to note additional counter-measures (which I agreed existed) and harp on the impracticality of something that (I claim) is actually quite straightforward to demand via subpoena and implement in practice. I suppose we'll just have to agree to disagree on that latter point.
I suspect you don't fully understand how this works, forgetting the legal aspects for a moment.
If you access Google's cache, at what point do you foresee it accessing the original page? Presuming use of a typical web browser in default configuration, nearly immediately. As soon as the first page specifies any image, your browser will dutifully go request that image from the original site. Note that use of text-only non-script browsers like lynx (or having the equivalent plug-ins) means your browser will refuse to load images, scripts, and so forth, so of course that avoids this issue. Further, as others rightly noted, if you (manually) append the strip=1 parameter to the URL, you'll get a page that already has these links stripped out by Google, but again this requires action taken on the part of the user. My whole original point was that it's not simple a matter to just use Google's cache to somehow protect yourself; that alone is not going to help.
Without that they will have to check all the images, etc. and while any access to those images might be logged with the referer, it will be much harder to prove any of this beyond a reasonable doubt since the images would be shared with other pages. I think this is where you're misunderstanding something. The referer will pinpoint exactly which page prompted the image to be fetched in the first place, and will inexorably tie the image to the page (yes, the one you got from Google's cache) to the IP address of your browser. Again, some browsers/configurations will hide the referer, but this is clearly not a typical setup. The point is that all they need to do is search the logs for a referer pattern that matches a copy of the page in question (as displayed from Google's cache), which is nearly trivial. Just because the images are "shared" doesn't mean you can't very easily find the instances where they've been accessed from pages that weren't served from your server.
Technologically speaking, you're correct; legally speaking, maybe not so much. Now that's where I fully agree with you, because I was never trying to address the legal aspects. First, even if they did have your IP address, it might be tremendously difficult to actually prove that it was actually you at the controls, let alone whether you bothered to read the page the browser was displaying. My (only) point was that TFS implied that--without doing anything else--simply accessing pages from Google's cache would protect you, and that's simply not true. You seemed to imply in your reply that it was a more theoretical than practical point, but it's actually extremely easy to generate a search to pull out exactly which IP addresses have accessed any cached versions of any of your pages.
Slashdot Mirror
I have no inside details on AT&T or Facebook, but what you've described is almost certainly the problem. AT&T very likely use fairly aggressive caching proxies, especially lately to help mitigate their infamous capacity issues. I'd say that what happened here is pages are being cached without proper regard for cookies. That's fine for sites that don't have custom accounts, and only use cookies for tracking various page view statistics. But Facebook (like nearly every other site in the world that requires a login) issues a cookie to identify you, once you've entered your credentials. So that cookie is how the server knows it's you, and not somebody else. If AT&T's forward caching proxies ignore this cookie, and just give you the most recent page served from Facebook, you're sure to hijack somebody else's session. And, since your first request sends your new credentials, the person you've hijacked (if still online) will now have passively hijacked your session, explaining the last scenario from TFA where sessions appeared to have been swapped.
[citation needed] pretty sure most spam is not illegal.
Citation: CAN-SPAM Act
Post-It notes have the distinct advantage that no computer virus or Trojan can steal it.
Yes, that's perfectly safe, until you have to type it into a computer for any reason.
Could California declare "no more swastikas" and force Activision to edit California editions of Wolfenstein, or would the U.S. overrule that decision?
I'm not sure how serious you were, but (sorry in advance for a car analogy) California already requires stricter emissions rules than most other states, and car makers of all kinds (US and imports) must comply in order to have their cars sold in that state.
Unless a state law is somehow challenged and found to be unconstitutional, it would stand. One would guess that the display of swastikas would be protected speech (and thus laws against it unconstitutional). However, given the attention to "hate crimes" apparently gaining a lot of focus, you never know.
That's an excellent idea for general "stay in touch" communications, and even blogging about their travels, but he also mentioned a business, and commercial use of ham radio is prohibited.
Does anyone have a source with more relevant information about this product?
One would have to assume it's similar to this story from early last year. I'm surprised it's not listed as a "Related Story" in the summary.
The submitter and nearly everybody else here seems to have totally missed the most relevant aspect, namely that this was fundamentally an IT problem.
There was a gas-gauge style graphic on the cars.gov web site, which displayed "real time" status of funds remaining. As of Thursday evening, the it was still showing $779 million remaining for most cars (excluding certain trucks) out of the initial $1 billion, and the last update time for the display clearly indicated 10:00am. Meanwhile dealers were already waving off customers, telling them that the program was suspended. Consider that you tell your boss in the morning that your project is going fine, with 3/4 of your budget remaining, only to realize by that same afternoon that your budget has actually been over-spent.
There are several IT angles here. First, when the program officially started July 25, there was only a single server hosting both the consumer and the dealer interfaces. The site was unusably slow for dealers to submit; this caused the first wave of the backlog to begin. They eventually split the application onto two servers; you can see even now that they suffixed /dealer/ as a URL path to the php pages, indicating which components are being served from the hastily added new server.
The initial backlog was magnified in the second wave, as the site has a horribly counter-intuitive user interface, meaning dealers were submitting large documents multiple times for each form page. The system requires scanned documents to be attached, and of course you can imagine what resolutions might be used by technically-naive dealers.
So the IT systems say that only 40,000 deals have been entered into the system. Only the reality is that well over 200,000 deals have been done, and they didn't realize this because they trusted the metrics. There's a 5-to-1 backlog, only 4 days into the program. Meanwhile, reports surface that a typical dealer says 150 deals were submitted to the site, yet only 30 submission confirmations were received in return, and every single one was a rejection.
Yes, I'd pin this fiasco squarely on the shoulders of the incompetent IT developers who built a crappy system that was totally inadequate for the task (but don't forget the incompetent managers that let it happen, blindly followed broken metrics, etc.). I think it's lucky that this was detected at all; this backlog could easily have gone undetected for months, in which case the program might have been overspent by many times over!
Yes, this story is indeed an interesting Technology tale, but unfortunately the submitter and editor seem to have entirely missed that point.
It is better to set the gulity free than to punish the innocent.
The more interesting societal issue: At what ratio?
But the question remains -- and I don't pretend to know the answer -- whether this particular job would more properly have gone to someone who actually has a tech background.
I didn't mean to evade your original question. For what it's worth, my take is that if you can at all accept my premise above (that the field is tremendously immature) the answer to this question becomes largely insignificant. Using a somewhat holistic definition of "properly" in this context, the answer quite obviously is yes. But I see this as little more than a hypothetical answer that presumes a more mature field.
As it is, I'm not sure it makes sense to even debate this matter, until it becomes at least moderately uncommon for a non-technical person to take on such a role. Right now (and for decades to come, I might suggest) this simply doesn't qualify as an extraordinary case within this field.
Though in a way it all serves as a humbling reminder of how far the IT field has yet to evolve, from a more practical perspective I just don't find this to be an intriguing disparity; it's merely a rather banal (albeit high-profile) example of what is still a very prevalent attitude.
By the way, I don't intend any disrespect to you for posing the question, nor do I find it inappropriate to discuss in this forum. In fact, I quite appreciate that you considered my posting and replied; I'm sure you've been flooded with countless other responses.
The legal profession has arguably been around since the dawn of civilized society. IT simply hasn't existed as a profession for any substantive time, in the grand scheme of things. If all IT workers refused to work under somebody, who hasn't "been doing it longer" than they, there would hardly be any IT workers at all. Think way back to the first few decades of the legal profession; don't you suppose quite a few lawyers worked for non-lawyers?
Suppose suddenly every organization needed a legal department in this fledgling time. There aren't enough lawyers (let alone any with vast experience) to go around, so you find somebody basically competent and hopefully well-versed in the concepts, and ask them to build a team of legal experts. This person then leverages any success and eventually becomes highly prized as an executive who can bring the right resources to bear, despite limited (if any) actual legal expertise.
Further keep in mind that there's no equivalent to a "bar" concept in IT, and there's not even (yet, perhaps) a consensus that this is desirable. So there's not really a reliable mechanism to allow one to decide whether a person is minimally competent. You virtually have to be an expert yourself to recognize another expert in the IT field with any confidence.
Basically I think you're neglecting the fact that the IT field itself is still extremely immature; I'd guess it will take at least a few more career-generations to reach the state where IT people are supervised exclusively by IT people.
One could say that a feature that mysteriously turns itself on and off is worse than a feature that simply doesn't work. At least when it doesn't work, it predictably doesn't work. Human beings value predictability.
Consistency in an operating is indeed a high priority, but the designers at Microsoft think they know better and suggest "Because Windows adapts to how you use your computer, the menu items you use most will be automatically displayed in the future. So the next time you open the menu, you might not need to expand it."
Nobody wants floppy drives to spin up as soon as a disk is inserted. That just makes them think they've been attacked by a computer virus. It'd all just be a lot of work for a feature nobody wants.
If only they had remembered this lesson. Some years later they considered it vastly different to spin up a CD upon insertion. Then they figured they'd not only do that, but also trust the media enough to blindly start executing code from it.
I did have to call them to, my truck was broken into, I was actually surprised they finger printed when they were obviously dealing with a junky stealing stereo's for a fix.
If I were a cynical type, I'd suggest that perhaps they were just taking that as an opportunity to collect your fingerprints.
For what it's worth, one is an Ivy League university in New York City, the other is not. TFS is wrong but TFA is right; the editor and/or submitter must be having trouble with copy and paste.
The PDF described the attack in detail. The attacker opens a new ING account in your (logged-in) identity, transfers any amount of your money from your personal linked account into "your" new ING account, adds any arbitrary payee (the attacker's own ING account, opened previously), then transfers funds from "your" new ING account to the attacker's ING account. They say it's been fixed, but please don't presume this wasn't a major issue.
who knows of or sees these things in order to oppose them?
Anybody. The marks are published weekly for opposition. The latest few are available as PDF downloads free of charge; follow the link and you can even subscribe to the paper copy (for merely $1,536/year).
I had exactly this problem you describe, with two different Conext UPS devices. As far as I can tell, the AVR system simply doesn't work, even with a good fully-charged battery. Yes, AVR is supposed to smooth out exactly these kinds of low voltage situations, where you have another high-draw device on the same circuit. Both UPS devices ended up giving a hardware fault LED/beep code after about two years, and the only answer from Conext (really APC) was to buy a replacement unit (with some nominal credit if I returned the Conext). I've never had any problems with any (of the many) APC devices I've used over the years, beyond changing batteries more often than I'd like. I always try to get the devices with AVR; these don't click over to battery during these low voltage situations, which seems (anecdotally) to keep the batteries in better shape for longer.
The "solution" is to get a real APC, ideally a model with AVR, or a workaround is to plug the printer into a totally different circuit (often meaning another room, assuming you're talking about a residence). I've found that Conext devices are a lot less expensive for a very good reason.
I'll assume you're not trolling here. If you find you're ever kicking off all your users to deploy an update, you're doing it wrong. Session persistence is supported by most useful production servers. This can be used to share sessions among nodes of a very small cluster (even two instances of the server running on one machine) or simply save the sessions to disk and restore them after restarting the system. With a little forethought regarding backward compatibility, you won't have any problems. And your users will still be logged in.
The third-best solution is what's been done today. We just made it a lot harder to exploit the vulnerability--typically about 16000 times harder, depending on your configuration.
It seems to me that this was the fifth-best solution. In fourth place would be just using TCP instead of UDP for all traffic. It's already supported in every existing client and server, we just need to deprecate UDP; it could be done today. This would make it far harder than simply enlarging the range of guessable numbers by a handful of bits.
In third place (which is what I'd really like to see) would be using TLS over that TCP, with server validation, plus optional client validation. This uses totally stock libraries that already exist on essentially every platform.
I'd like to preemptively address any performance concerns, by saying I don't care. This won't come close to clogging our precious tubes, and we're talking about cached results anyway, so don't bother complaining about one extra TLS/TCP set of handshakes every few minutes or hours. Security always has a price in terms of convenience, and this is it.
GeoTrust announced it "signed a definitive agreement to be acquired by VeriSign" in May 2006. The acquisition was finalized around September 2006. They're still issuing QuickSSL Premium certs from Equifax.
For what it's worth, this whole article is a dupe from 2006.
Even more blatant (and even longer ago) Soap Operas started this trend. They're known as such because the whole point of every episode was to sell cleaning products to the viewers, by a combination of product placement and in-show advertising (typically given by the main actors, in character). This concept started on radio in the 1930s and continued into television over the next two decades.
Agreed, and further I think a lot of folks here are ignoring the probability that this massive object will hit more than just a single satellite. There are a lot of satellites packed into a rather constrained geosynchronous orbit. Further, even if it doesn't actually hit anything at all, it will certainly cause a number of nearly-missed satellites to have their orbits altered dramatically, perhaps irreversibly. So we'll likely have catastrophic communications failures, at the exact time we'll need to collaborate to determine our collective fate (and, hopefully, generate some mitigation strategies).
Sony manufactures batteries for several major laptop vendors. Follow the money.