Slashdot Mirror
Twitter Bug Locks Out Many Users
TechCrunch and ZDNet are among the many sources to report that many users are having trouble right now signing in to Twitter, and that the company is working right now to fix the glitch. As ZDNet describes the problem, According to Twitter's server response at the time of writing, most of 2015 has happened, and we are heading into a bright new 2016 in a couple of days time. Querying Twitter's HTTP response headers at https://twitter.com returns a time stamp dated one year into the future: "date: Mon, 29 Dec 2015 02:09:37 UTC". Consequently, users of Twitter's popular Tweetdeck application have experienced seeing every incoming tweet appear with a time stamp reporting the tweet to be from 365 days ago. At the same time that Twitter's servers began returning the incorrect date, some users of Twitter's official Android app were logged out of the service, and unable to log in again via the app. Users of some third-party Twitter applications have also reported being locked out of their apps.
Quantum mechanics does let you slightly violate relativity, sending very short messages back from the future.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
This is it, y2kxiv ! Damn you for not listening...
year?
I got in just long enough to see #lahar is trending.
How can I believe you when you tell me what I don't want to hear?
They are using ISO Year for the Date header, for some reason. (the last 3 years wouldn't have been affected)
As Mon Dec 29, 2014, is ISO year 2015, Week 1, Day 1.
The Last-Modified header is showing the correct date and time.
The Date: header is not.
Last-Modified: Mon, 29 Dec 2014 00:59:30 GMT
Date: Mon, 29 Dec 2015 00:59:30 UTC
So, they're using the "G" rather than "Y" designator for displaying the date (if C based)
As all the other fields are correct, but they are using the ISO Year, rather than Calendar Year.
It's a subtle issue, but a rather silly one.
And clients, can probably see that either a) Mon Dec 29, 2015 doesn't exist (invaild date); or is b) Ignore monday, and 2015-12-09 is too far out of range for a new session token.
There are still people running around claiming that the Y2K problem was a hoax or overrated ...
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Good catch!
"Go to CNN [for a] spell-checked, fact-checked summary" -- CmdrTaco
However will I notify the world if I fart?
I do not fail; I succeed at finding out what does not work.
Yes. That's why the safety record of airliners has plummeted as computers control more and more of the cockpit and air traffic control towers, why antilock braking systems controlled by computers are universally derided as dangerous, why robotic surgery is outlawed in every civilized country, and why pacemakers were outlawed after a brief, tragic experiment with them ended in the computer putting a virus in the victim's brain and using the host as a primitive version of Skynet.
Or maybe ... just maybe ... the software controlling critical safety systems is written to a different standard of quality than the software controlling fucking Twitter.
vi ~/.emacs # I'm probably going to Hell for this.
Oh, shut the fuck up you scare mongering twit.
I heard robot car carnage and immediately became turned on. When does this reality begin?
So you're saying that Twitter was designed by the same people that did the accelerator controls for Toyota?
I see even classic Slashdot is now pretty much unusable on dial up anymore.
More than 13 years after the war in Afghanistan began, President Obama capitulated today to the Taliban at a ceremony in Kabul.
It is expected that war efforts will be directed to Iraq and Syria in a bid to salvage the War on Terror.
More news to come later on Twitter.
... then find out who wrote the code and audit all of their other project contributions. Just saying.
I'd think a person with such a low slashdot ID would be around long enough to not throw mechanical problems in a computer/software safety issue. NASA and NHTSA said it was mechnical errors (The accelerator could physically stick to the floor or could be held down by the floor mat.). They still got a jury ruling against them, because it could have been cosmic rays flipping bits and and not a PEBKAC. I'd give cosmic rays hitting the right bit inside a car in the right circumstances a lower chance than people doing silly things with their accelerator, but I was no member of that jury. Cosmic bits flipping the right bit PEBKAC.
None of those things you describe even comes close to autonomous automobiles.
Only the State obtains its revenue by coercion. - Murray Rothbard
I'm thinking one of the date formatters is using a capital Y rather than a lower case y and hence rendering year of week which is 2015 for this week.
Yes. That's why the safety record of airliners has plummeted as computers control more and more of the cockpit and air traffic control towers
Sounds like someone hasn't got the memo that we've lost not one, but 2 planes this year. Simply lost mid flight, no idea where they went.
To me, Twitter is like an improved RSS reader. Very useful to keep up with the headlines. Also, great way to utilize horizontal screen estate is to tuck TweetDeck next to the web browser.
Sounds like someone hasn't gotten the memo that increased news exposure != an increased rate of occurrence. IIRC, 2013 was the lowest year in two decades in terms of lost aircraft. This year hasn't been particularly notable, either.
You're thinking wrong
#andnothingofvaluewaslost
I've been unable to post updates on my love of staplers!
And there was silence as no one cared who you thought was an idiot and no one was around for you to high five after serving your ice cold burn on the internet.
What happens, if you do not "keep up with headlines" ? NOTHING!
Twitter is as useless as all the rest of the "social" "media" crap out there. It's a massive waste of your time.
How about write a tests for dates across the log in and authentication system. If you want a problem to never happen again you build processes to analyze code and test for mistakes like this, otherwise I'm sure the developer who wrote this has already learned how to handle dates better than most. Besides it is shockingly easy to make mistakes in calculating and displaying time if your not working with a libraries that handle it for you and it will happen again.
Shut up.
Nor do the algorithms that control Twitter.
Ascalante: Your bride is over 3,000 years old.
Kull: She told me she was 19!
They are using ISO Year for the Date header, for some reason. (the last 3 years wouldn't have been affected)
Care to elaborate on this a bit? The only ISO standard I know of that says anything about dates is ISO 8601, which just deals with date/time representations. There's nothing in there I know of that could actually change the year on you (unless it happens to be the last day of the year and you are far enough from the UTC time zone).
http://en.wikipedia.org/wiki/ISO_week_date#Disadvantages
Ahhh. That's fiscal year stuff. I had no idea that was even in ISO. I'm guessing the coder at Twitter who accidentally used it didn't either.
So now this makes sense: Today happens to be the first day of the fiscal year 2015. That field was using UTC as well, so basically as soon as it hit midnight GMT, blam. And as the GP said, the dates happened to match up the last two years, so nobody noticed the bug for 3 years.
Smarter would probably be to do a seek-and-destroy on all code using fiscal years, since that seems to be the source of the problem. If one person made that mistake, others may as well.
No, except that in many cases the impact of failure begins to be comparable. It would be interesting to see data though on:
1. How many times auto pilot makes enough of a mistake to cause loss of life
2. How many times anti lock brakes fail and result in an accident that wouldn't have occurred without them
3. How many times a surgery robot fails and causes a patient to die, or necessitates drastic action on part of the supervising surgeon
4. How many times a pacemaker fails in an unexpected way causing damage to the user
The point was that if twitter goes down, then a bunch of people have to go somewhere else to get their social media fix and some businesses lose a medium on which to attempt to launch a viral ad campaign.
If somebody botches it up, it's a bit of lost revenue.
Somehow, autopilot software has been designed robustly enough such that:
1. You don't hear of a lot of severe accidents resulting from bugs in auto pilot software
2. Airlines find them reliable enough such that they continue to allow their pilots to use it
Thus, they have somehow managed to design such that there are no tiny bugs that cause huge problems.
OMG!! The sky is falling! (" 'Tis better to keep your mouth shut and be thought a fool than to open it and remove all doubt" - A. Lincoln)
Yeah, bug my ass, when there were members of both GNAA and RussellLeague Tweeting about using a 0day to gain control of the Twitter API servers and changing the dates (their cache dates were also changed to 1981), as well as being prepared to do a username and password dump of every single Twitter account that uses the app API.
They were also targeting Anonymous, going so far as to demand full admin control of the @YourAnonymousNews account and publicly exposing the password to the account of one of the Anon members who runs @YourAnonymousNews.
The GNAA members in question were even offering access (and so was RussellLeague) to various Twitter 0day account hacks for $100 BTC per account targeted.
Twitter is as useless as all the rest of the "social" "media" crap out there. It's a massive waste of your time.
Exactly! Why can't all those people using twitter do something constructive with their time? You know, like posting smug AC comments on Slashdot.
I wish I were as sure of anything as some people are of everything
I've driven a car that had its antilock brake system decide the car was stuck in a skid when it wasn't. Which of course greatly increases your stopping distance. I nearly hit someone else in front of me, the only reason I didn't hit them is I swerved to the shoulder and was half in the ditch. Had the antilock brakes not interfered I would've stopped safely with lots of time. I'm just glad it wasn't a pedestrian crosswalk when that happened. I've been against them since then.
Since then I've stuck with my 30 year old car. Nothing fancy, it just works. And dammit, when I step on the brakes it actually applies them!
Remember this conversation, about five years from now.
You can't synthesize a general rule from systemic failures? Keep It Simple Shithead.
Planes do fail by software errors.
http://en.wikipedia.org/wiki/Q...
http://it.slashdot.org/story/1...
http://en.wikipedia.org/wiki/A...
Antilock brakes are very simple systems, and you have a mechanical backup as well. But, for the record, I don't like computer controlled brakes. I drive a mechanical car.
If ABS do fail or malfunction, I doubt anyone is keeping track as to how or when. As no one keeps track, you can't perceive systemic failure as a problem. They'd have to fail massively for anyone to care.
Robots don't operate very much, and frankly I certainly don't want a piece of software cutting on me. It's not outlawed for the same reason automated cars aren't outlawed. Not enough experience to perceive failure, and an unwillingness to acknowledge failure when it does happen. And civilized countries allow voting via computer programs as well - the ultimate in unpercievable failure.
Pacemakers can fail via deliberate malware infestation, or an EMP attack or accident, or a software bug. Just because you don't know of a failure doesn'[t mean it doesn't happen.
Here's some automated software injuries:
http://en.wikipedia.org/wiki/T...
http://www.ccnr.org/fatal_dose...
As to your point about a software bug failure on Twitter being different than a software bug in a car running half a billion lines of code:
You make my point for me. Twitter failed from one point. Just one point. Half a million lines of code have damn near an infinite chance of:
1. Failure through complexity. Any real-world programmer knows that hyper-complex systems can have cascading weirdness.
2. Failure through sensor failure, processor failures, bus failures, and similar failures we can't anticipate.
http://it.slashdot.org/story/1...
http://www.cs.tau.ac.il/~nachu...
And Google's robot car had to be rebooted twice during its certification run.
3. Failure through an the inability to program a PC to anticipate all the possibilities that a car swarming with other cars in a real world situation. One can't program that.
4. Failure through vulnerability to outside attack. Software on a network is very vulnerable; one hundred percent so. Physically, a high energy radio pulse fired at a car, or a whole highway of cars, would cause carnage. Carnage would be multilation and death, what happens when steel boxes swerve randomly around at 70 mph with no driver.
5. The problem isn't about ALL cars failing. One car can fail and crash the cars around it. For the system to work, all cars have to work 100% perfectly all the time.
An car - driver is eating a sandwich. Car computer failure would crash the car instantly, depending. Carnage.
An airplane - plane is, generally speaking, in the air most of the time. If the computers fail, somehow, the pilot can take control with time enough to avoid contact with other planes or the ground.
Car - failure, milliseconds to react, car may not even let you drive. Plane: seconds or minutes to recover and land.
I'm only pointing out the obvious failure points. Others will happen. I wistfully recall posting on Slashdot about the vulnerability of a NFC card being read without the owner's knowledge; I was mocked as an ignoramus. I just pointed out physics didn't rule out building a concealed reader, or very powerful pulse generator. Both have happened.
I await the stories of failed robot cars in the coming years, and either th
You have no imagination and too much confidence in your coding abilities. The world isn't a video game. As I pointed out in my longer response, robot airliners and other craft have gone wild and hurt and killed people. Refusal to look is not a rebuttal. (But of course it is- any problem can be solved by a more expensive solution combined with a complete refusal to look at any evidence that contradicts the solution).
Software piloting is fine. On a plane, with a priesthood of techs looking after it daily, and with pilots who have (one would hope) both the opportunity and the ability to take control if the computer pilot goes fuckyup. In a car, there is no time to recover, worst case, the "pilot" is playing a video game, the car's maintenance is up to the pilot, and the car is surrounded by other cars that will be in a lot of trouble from the rogue car. No comparison.
http://en.wikipedia.org/wiki/L...
Medical[edit]
A bug in the code controlling the Therac-25 radiation therapy machine was directly responsible for at least five patient deaths in the 1980s when it administered excessive quantities of X-rays.[13][14][15]
A Medtronic heart device was found vulnerable to remote attacks in March 2008.[16]
Funny: I remember this story. The USS Yorktown BSODed at sea when it let Window NT helm the ship.
http://en.wikipedia.org/wiki/U...
Smart ship testbed[edit]
From 1996 Yorktown was used as the testbed for the Navy's Smart Ship program. The ship was equipped with a network of 27 dual 200 MHz Pentium Pro-based machines running Windows NT 4.0 communicating over fiber-optic cable with a Pentium Pro-based server. This network was responsible for running the integrated control center on the bridge, monitoring condition assessment, damage control, machinery control and fuel control, monitoring the engines and navigating the ship. This system was predicted to save $2.8 million per year by reducing the ship's complement by 10%.
On 21 September 1997, while on maneuvers off the coast of Cape Charles, Virginia, a crew member entered a zero into a database field causing an attempted division by zero in the ship's Remote Data Base Manager, resulting in a buffer overflow which brought down all the machines on the network, causing the ship's propulsion system to fail.[6]
Anthony DiGiorgio, a civilian contractor with a 26-year history of working on Navy control systems, reported in 1998 that Yorktown had to be towed back to Norfolk Naval Station. Ron Redman, a deputy technical director with the Aegis Program Executive Office, backed up this claim, suggesting that such system failures had required Yorktown to be towed back to port several times.[7]
In 3 August 1998 issue of Government Computer News, a retraction by DiGiorgio was published. He claims the reporter altered his statements, and insists that he did not claim the Yorktown was towed into Norfolk. GCN stands by its story.[8]
Atlantic Fleet officials also denied the towing, reporting that Yorktown was "dead in the water" for just 2 hours and 45 minutes.[7] Captain Richard Rushton, commanding officer of Yorktown at the time of the incident, also denied that the ship had to be towed back to port, stating that the ship returned under its own power.[9]
Atlantic Fleet officials acknowledged that the Yorktown experienced what they termed "an engineering local area network casualty".[7] "We are putting equipment in the engine room that we cannot maintain and, when it fails, results in a critical failure," DiGiorgio said.[7]
I'm not going to look at all your links because they prove nothing other than that computer-controlled systems sometimes fail. Of course they do, nothing is 100% reliable. But it is possible to fail gracefully. For instance, antilock brake systems have two identical computers doing the same calclations; if they disagree on what to do, the system fails gracefully and reverts to manual brake control. In the case of an automated car failure, graceful failure would be using a backup system to pull over to the side of the road, brake, and turn on emergency flashers. If this also fails, simply braking or disengaging the accelerator would be the next failure mode. i have no idea why you would assume that professional engineers would consider a car "randomly swerving at 70 miles an hour" an appropriate response when one of the 2-5 redundant primary computers failed, but I assure you they would not. There are many other ways to ensure the creation of reliable software; there is an entire field here and won't post a literature survey here. I'll just leave you with this: to be safer than human control, computers don't have to fly a plane perfectly, just better than the average pilot. To be safer than human control, computers must only drive safer than the average driver.
vi ~/.emacs # I'm probably going to Hell for this.
http://it.slashdot.org/comment... Great thread on this subject. Here's a good post by a better writer than I:
"we already fixed it. its called 'trains'. (Score:5, Insightful)
by decora(1710862) on Tuesday December 20, 2011 @12:54AM (#38430976) Journal
the idea that a bunch of automatically piloted vehicles is somehow a better solution to city transport than mass-transit, it boggles my mind.
real people do not have money to maintain their cars properly. things are going to break. there are not going to be 'system administrators' to fix all the glitches that come up when cars start breaking down after a few years.
there will be problems. do i know which problems? no, but i know the main problem.
arrogance amongst revolutionaries. it is historically a pattern of the human species. declaring that nothing could go wrong is usually a precursor to a lot of things going wrong. not because the situation was unpredictable, but because human beings in an arrogant mindset tend to make a lot of mistakes, be reckless, and try to cover their asses when things go wrong.
but successful engineering is the anti-thesis of arrogance. nobody worth his salt is going to say 'what could go wrong'? they are going to have a list of 500 things that could go wrong, and all the ways they have tried to counter-act those wrong things happening."
In a video game they can. In the real world, they will fail to do so; Google and others are simply positing that the robot can drive better. It can on a test track. In the real world, no.
Again, I love this posting from 2010: (Great thread on this very subject, probably influenced me.) Better informed posters than I.
http://it.slashdot.org/story/1...
This post http://it.slashdot.org/comment...
"we already fixed it. its called 'trains'. (Score:5, Insightful)
by decora(1710862) on Tuesday December 20, 2011 @12:54AM (#38430976) Journal
the idea that a bunch of automatically piloted vehicles is somehow a better solution to city transport than mass-transit, it boggles my mind.
real people do not have money to maintain their cars properly. things are going to break. there are not going to be 'system administrators' to fix all the glitches that come up when cars start breaking down after a few years.
there will be problems. do i know which problems? no, but i know the main problem.
arrogance amongst revolutionaries. it is historically a pattern of the human species. declaring that nothing could go wrong is usually a precursor to a lot of things going wrong. not because the situation was unpredictable, but because human beings in an arrogant mindset tend to make a lot of mistakes, be reckless, and try to cover their asses when things go wrong.
but successful engineering is the anti-thesis of arrogance. nobody worth his salt is going to say 'what could go wrong'? they are going to have a list of 500 things that could go wrong, and all the ways they have tried to counter-act those wrong things happening."
Well said. Proof will be in the testing... on real roads with real cars. Oy.
After all, dealing with date and time is such a radically new concept, mishaps are to be expected. Time is cutting edge technology, we didn't used to have that until recently.