Lets improve our security!


  • Discourse touched me in a no-no place

    AES is an American (duh) student loan provider. Also known as a financial institution. For a few years now, standard practice has been for financial institutions to use wish-it-was-two-factor-authentication. Basically, you present your username, they present you with a purportedly secret combination of an image and a phrase so you can validate they are who they say they are, and then you present them with your password. At least it's a reasonable facsimile of two-WAY authentication, and generally a Good Thing. My credit union finally got around to introducing a similar process last month, as did Verizon Wireless.

     

    So I logged in to pay my bills today and found this notice:

    Yep. They're removing that step. Supposedly because people whined about it.

     

    I mean, yeah, as financial institutions go, this one is the one with the least to gain by breaking into it (OH GOD WHAT ARE THEY GOING TO DO, PAY MY LOANS?)

    But there is information that would be quite useful for identity theft. Even goddamn soul-sucking Verizon understands that they have a duty of care with that stuff.



  • Student loan websites are consistently the worst. I don't know that I've ever seen one of them that didn't have some assinine restriction on the special characters that are permissable, which always makes me very nervous about what the hell they're doing on the backend.



  • So the site has a login form that submits over https. But it's served over unsecured http. So the https protects you only if there's a man-in-the-middle attacker that doesn't have the ability to send packets.



  •  At least they're increasing the length of the password. From 5 to 7, I assume. They still won't allow "weird characters" like spaces or punctuation, because their programmers are all "Password hashing? WATS DAT?"


  • Discourse touched me in a no-no place

    @Ben L. said:

    So the site has a login form that submits over https. But it's served over unsecured http. So the https protects you only if there's a man-in-the-middle attacker that doesn't have the ability to send packets.
    No, it's technically just about OK, but you'll find it (comparatively) hard to figure out if things are properly secured before handing over your credentials. It's not what I'd call actually competent, and these cock-ups are disturbingly common because of a modern myth that “HTTPS is expensive!!!” Bah.


  • Discourse touched me in a no-no place

    "HTTPS is expensive", so they're (presumably) buying an even more expensive EV certificate? Because trusting the entire certificate chain and browser manufacturer to vouch for the identity of a target site based on the fact that they spent a few extra dollars is better than the target site giving you evidence that they are who they say they are based on a shared secret? Because it saves one 'pointless' screen?



  • My financial institution's website used to be http://secure.exampleonline.com.au. (example is the name, which is a common English word). They used the word online because of an old restriction in the .com.au space on these common words. They also get bonus points: accessing this URL via https would yield a certificate error (the actual secure site was on a different domain). They have since moved to www.example.com.au.



  • @Lorne Kates said:

    They still won't allow "weird characters" like spaces or punctuation, because their programmers are all "Password hashing? WATS DAT?"
     

    Can anyone explain why sites don't allow "weird characters"? Is it because they interpret the password as base64 and so save bits on the server?



  •  because they don't hash and want to preven the 'or 1 = 1 abuse



  • I suppose they don't use parameterized statements either, but still, wouldn't it be enough to prohibit the apostrophe?


  • Discourse touched me in a no-no place

    @levbor said:

    Can anyone explain why sites don't allow "weird characters"?
    Because their database handling is shit? Because they want to ensure that everyone can type in the password on every device? Because they flipped the sense in the password security checker?



  • @ratchet freak said:

     because they don't hash and want to preven the 'or 1 = 1 abuse

     

    Yup. It's a 100% clear indicator that the people who made the website don't understand password handling, security or prepared statements. Expect that site to be compromised at some point. Don't store anything valuable with them. Assume your password has already been revealed to anyone and everyone with malicious intent; if the password matches the password you use for the email address on file, change that email account's password immediately.

    Behind the scenes, some devs had this conversation:

     Dev 1: "It's weird, when I concatenate the value from the password textbox to the SQL statement-- y'know the one where we select from users where username matches the input and password matches the input-- if there's any weird characters the database goes funny."

    Dev 2: "What weird characters?"

    Dev 1: "I dunno-- those ones on, like, the top row I think?  I think we need to copy and paste some code from Stackoverflow that prevents users from typing those characters when they're on the Password box."

    Dev 2: "That's a great idea! Stackoverflow is the store where we got the Javascripts that copyrights the page by preventing users from right clicking and stealing our images!"

    And it goes downhill from there. 

     



  •  no sql escaping is much more complicated than just escaping apostrophies and even libraries get it wrong, always parameterize statements



  • I never understood how the two-way thing is supposed to work. What attack does it actually prevent?

    I've only ever seen this on one (American) banking site and I don't see how it can stop the malicious site contacting the real site with my ID and then serving up what the original site shows. "We are who we say we are" doesn't seem like a difficult task if your users are used to looking for the https: address. Does it help the bank tracking down the IP address of the fake site so they can get spoof sites shut down more quickly?



  • @Qwerty said:

    I never understood how the two-way thing is supposed to work. What attack does it actually prevent?

    I've only ever seen this on one (American) banking site and I don't see how it can stop the malicious site contacting the real site with my ID and then serving up what the original site shows. "We are who we say we are" doesn't seem like a difficult task if your users are used to looking for the https: address. Does it help the bank tracking down the IP address of the fake site so they can get spoof sites shut down more quickly?

    It seems more secure, which is all that really matters.


  • @ratchet freak said:

     because they don't hash and want to preven the 'or 1 = 1 abuse



    Actually, it's more likely to be an encoding problem. As in, when you have a front end web server with a specific encoding sending data to a backend mainframe server with a different encoding, special characters that may not exist in the backend encoding scheme cause problems. And you can't change the mainframe encoding cause it's been set that way since 1970 and nobody is going to risk changing it.

    edit: It's still dumb, because the password should be getting hashed on the front end and the hash sent to the backend, but it's possible that they are interfacing with a backend layer that takes the password itself in cleartext. Probably on the design philosophy of "hey, lets just take the existing password authentication from the mainframe and use that instead of spending a bunch of time and money developing a new thing to do what it already does."

     



  • @Qwerty said:

    I never understood how the two-way thing is supposed to work. What attack does it actually prevent?

    I've only ever seen this on one (American) banking site and I don't see how it can stop the malicious site contacting the real site with my ID and then serving up what the original site shows. "We are who we say we are" doesn't seem like a difficult task if your users are used to looking for the https: address. Does it help the bank tracking down the IP address of the fake site so they can get spoof sites shut down more quickly?

    It makes it harder for malicious links in emails/websites to go phishing for your account login credentials. Because they won't have the special image (presumably, since if they have the image, they already hacked the server and shouldn't need to phish at all) to serve to you to verify they are your bank, so when they ask for your username/password, you can see that your special image wasn't on the page before you put in a password. Then you stop and say "AHA I AM NOT GOING TO GIVE YOU MY PW YOU CRAZY HACKERS YOU", and close your browser.



  • @Snooder said:

    Actually, it's more likely to be an encoding problem.

    I think this is more likely the case when it comes to major sites like banks or credit cards.

    But for your 1-man hobby forum website type places, I'd still guess it's to prevent sql hacks.



  • @Qwerty said:

    I never understood how the two-way thing is supposed to work. What attack does it actually prevent?

    I've only ever seen this on one (American) banking site and I don't see how it can stop the malicious site contacting the real site with my ID and then serving up what the original site shows. "We are who we say we are" doesn't seem like a difficult task if your users are used to looking for the https: address. Does it help the bank tracking down the IP address of the fake site so they can get spoof sites shut down more quickly?

    It's definitely intended to stop phishing, but it can be defeated the way you said. Yahoo used a "custom login picture" for a while, except it was kept in a client cookie and not sent by the server. I don't think it lasted very long.

    It is unreasonable to expect users to look at the URL every single time they enter a password (especially if you never tell them to). I'm generally paranoid with security, and I still forget it every now and then. This could all be solved if HTTP or HTML had a decent user authentication protocol, so that the user could authenticate to the browser and the browser could authenticate to the server (and only that server). But hey, HTTP's only been around for 23 years, so it's understandable that nobody has gotten around to it.



  • @darkmattar said:

    It makes it harder for malicious links in emails/websites to go phishing for your account login credentials. Because they won't have the special image (presumably, since if they have the image, they already hacked the server and shouldn't need to phish at all) to serve to you to verify they are your bank

     

    Because in order to get that image, they'd need my username, which I just gave them?



  • @cdosrun said:

    Because in order to get that image, they'd need my username, which I just gave them?

    True, but if a single proxy is logging hundreds of user image requests to your server, you're likely to notice and catch them doing it. I will grant you that if the bank isn't watching their access logs for repeat visits from 1 IP for multiple customers, it's not going to stop a damn thing.
    A regular phishing attack wouldn't require proxying data from the real server in order for it to work.



  • @Snooder said:

    It's still dumb, because the password should be getting hashed on the front end and the hash sent to the backend

    No, the backend should never accept or test password hashes generated by the client; if it's going to do that, it might as well not bother hashing passwords at all, since anybody who steals a copy of the server-side password database immediately gets everything they need to impersonate any account holder.

    The client should send a base64-encoded password (over SSL to defeat eavesdroppers) that the server will then hash and test; better still, the client and server can have a little conversation per RFC5802. If the client always transfers passwords encoded as base64, there is no reason at all why the server should ever need to decode one (and thereby have it become subject to its own encoding vagaries) before hashing it. I have never seen a backend character encoding that can't handle A-Z, a-z, 0-9, +, / and = which is all you ever need in a base64-encoded field, but even if you did have the world's mouldiest mainframe on the backend you could use client-side base32 or base16 encoding for password transfer instead.



  • @Weng said:

    "HTTPS is expensive", so they're (presumably) buying an even more expensive EV certificate? Because trusting the entire certificate chain and browser manufacturer to vouch for the identity of a target site based on the fact that they spent a few extra dollars is better than the target site giving you evidence that they are who they say they are based on a shared secret? Because it saves one 'pointless' screen?

    EV certs are a scam, but the whole CA system is a scam. I always tell people to go for EV certs if they're doing a site where end-users because the extra hundred bucks a year is worth it just for the bullshit marketing effect.



  • @Ben L. said:

    So the site has a login form that submits over https. But it's served over unsecured http. So the https protects you only if there's a man-in-the-middle attacker that doesn't have the ability to send packets.

    Meh, that's a problem, but the whole fucking SSL ecosystem is a problem. I mean, there's a good chance the first hit to the domain is over HTTP, so at that point shit really isn't secure. You're only really safe if you only use HTTPS on the site (assuming you don't pay attention to things like the URL bar and guaranteeing that every resource is served from HTTPS). Google had a thing where Chrome would "pin" some sites so even if you tried to go to the HTTP site Chrome itself redirected you to the SSL site, but it was a list that was hard-coded in the Chrome source and managed by-hand. That sucks if you're a small-time site, but they pinned the big hitters (Google, Hotmail, Yahoo, FB, Paypal, etc.) so it probably prevent that vast, vast majority of SSL-hijacking monkeyshines.



  • @morbiuswilters said:

    if they're doing a site where end-users because

    what does that sentence even



  • @Ben L. said:

    @morbiuswilters said:
    if they're doing a site where end-users because

    what does that sentence even

    Wow, I left off one word and broke your parsing algorithm. I think there are AIs from the 70s who had better context-awareness than that.

    But, yes, it should have read "where end-users login". In other words, an EV cert would be pointless for something like an API gateway, a personal site or an internal site, but if you have customers using it, just pay the extra $100. If $100 is too much for your company, you might start asking the hard questions, like "Has the office been putting tranqs in my coffee and sucking out my blood plasma while I'm unconscious to try and make ends meet?"



  • @morbiuswilters said:

    @Ben L. said:
    So the site has a login form that submits over https. But it's served over unsecured http. So the https protects you only if there's a man-in-the-middle attacker that doesn't have the ability to send packets.

    Meh, that's a problem, but the whole fucking SSL ecosystem is a problem. I mean, there's a good chance the first hit to the domain is over HTTP, so at that point shit really isn't secure. You're only really safe if you only use HTTPS on the site (assuming you don't pay attention to things like the URL bar and guaranteeing that every resource is served from HTTPS). Google had a thing where Chrome would "pin" some sites so even if you tried to go to the HTTP site Chrome itself redirected you to the SSL site, but it was a list that was hard-coded in the Chrome source and managed by-hand. So that's not really much help.


    Actually, it doesn't require you to ask Google to add you, and it's a standard outside of Chrome. It's actually quite nice.

    Basically all you have to do to make sure people never go to the http: version of your site after they've been to the https: version once is to add a single header: Strict-Transport-Security: max-age=some big number of seconds, like a year or whatever



  • @Ben L. said:

    @morbiuswilters said:
    @Ben L. said:
    So the site has a login form that submits over https. But it's served over unsecured http. So the https protects you only if there's a man-in-the-middle attacker that doesn't have the ability to send packets.

    Meh, that's a problem, but the whole fucking SSL ecosystem is a problem. I mean, there's a good chance the first hit to the domain is over HTTP, so at that point shit really isn't secure. You're only really safe if you only use HTTPS on the site (assuming you don't pay attention to things like the URL bar and guaranteeing that every resource is served from HTTPS). Google had a thing where Chrome would "pin" some sites so even if you tried to go to the HTTP site Chrome itself redirected you to the SSL site, but it was a list that was hard-coded in the Chrome source and managed by-hand. So that's not really much help.


    Actually, it doesn't require you to ask Google to add you, and it's a standard outside of Chrome. It's actually quite nice.

    Basically all you have to do to make sure people never go to the http: version of your site after they've been to the https: version once is to add a single header: Strict-Transport-Security: max-age=some big number of seconds, like a year or whatever

    That's not the same thing. Do you actually read shit before hitting reply? Yes, that's a nice feature, but it obviously does nothing to protect a user who hits the HTTP site first and is hijacked.



  • @morbiuswilters said:

    @Ben L. said:
    @morbiuswilters said:
    @Ben L. said:
    So the site has a login form that submits over https. But it's served over unsecured http. So the https protects you only if there's a man-in-the-middle attacker that doesn't have the ability to send packets.

    Meh, that's a problem, but the whole fucking SSL ecosystem is a problem. I mean, there's a good chance the first hit to the domain is over HTTP, so at that point shit really isn't secure. You're only really safe if you only use HTTPS on the site (assuming you don't pay attention to things like the URL bar and guaranteeing that every resource is served from HTTPS). Google had a thing where Chrome would "pin" some sites so even if you tried to go to the HTTP site Chrome itself redirected you to the SSL site, but it was a list that was hard-coded in the Chrome source and managed by-hand. So that's not really much help.


    Actually, it doesn't require you to ask Google to add you, and it's a standard outside of Chrome. It's actually quite nice.

    Basically all you have to do to make sure people never go to the http: version of your site after they've been to the https: version once is to add a single header: Strict-Transport-Security: max-age=some big number of seconds, like a year or whatever

    That's not the same thing. Do you actually read shit before hitting reply? Yes, that's a nice feature, but it obviously does nothing to protect a user who hits the HTTP site first and is hijacked.

    Oh, yeah, it also doesn't support IE, so it's about as useful as strong, masculine, heterosexual character in a Wes Anderson film.



  • @morbiuswilters said:

    EV certs are a scam, but the whole CA system is a scam. I always tell people to go for EV certs if they're doing a site where end-users because the extra hundred bucks a year is worth it just for the bullshit marketing effect.
    I remember applying for a SSL certificate about 10 years ago (long before EV) - the procedure was pretty long, and involved all sorts of checks by the CA. A few years later domain-validated certificates appeared, for which you only needed to be able to receive e-mail at specific addresses on it. Last year a client wanted an EV certificate, and the checks (and cost) were about the same as 10 years ago for regular cert.



  • @ender said:

    @morbiuswilters said:
    EV certs are a scam, but the whole CA system is a scam. I always tell people to go for EV certs if they're doing a site where end-users because the extra hundred bucks a year is worth it just for the bullshit marketing effect.
    I remember applying for a SSL certificate about 10 years ago (long before EV) - the procedure was pretty long, and involved all sorts of checks by the CA. A few years later domain-validated certificates appeared, for which you only needed to be able to receive e-mail at specific addresses on it. Last year a client wanted an EV certificate, and the checks (and cost) were about the same as 10 years ago for regular cert.

    Yes. But it doesn't matter how detailed the checks are because:

    1. An EV cert and DV cert have the same technical value. Just because you go to the trouble of getting an EV cert does not mean a hacker needs to. All they need is hack your email (and sometimes not even that) and they can get a DV cert from your domain. How many end-users will know the difference?

    2. Popular browsers like Chrome and FF have something like 1000+ certs they trust to sign. Do you trust every single one of those? Before you answer, remember some CAs have been so shitty they've signed certs for hackers for Facebook or Microsoft, or they've used shitty cert options which makes their certs hackable. Oh, and for added comfort, the Chinese and United States governments also have easy access to their own trusted CA certs. Thank God they have no interest in eavesdropping on conversations or stealing data.

    3. That's not even to mention that countries like Spain and Turkey can sign certs. I hear the Spanish government's so hard-up for cash they'll give you a fraudulent cert and a handy for twenty USD and a hit of black tar heroin. Not a bad deal.



  • @morbiuswilters said:

    I hear the Spanish government's so hard-up for cash they'll give you a fraudulent cert and a handy for twenty USD and a hit of black tar heroin. Not a bad deal.

    Wonder what you can get that Crimean Attorney General to do for a fifty spot...


  • Discourse touched me in a no-no place

    @morbiuswilters said:

    Oh, yeah, it also doesn't support IE, so it's about as useful as strong, masculine, heterosexual character in a Wes Anderson film.
    You have to support IE still? Much is explained.


  • Discourse touched me in a no-no place

    @Snooder said:

    Actually, it's more likely to be an encoding problem. As in, when you have a front end web server with a specific encoding sending data to a backend mainframe server with a different encoding, special characters that may not exist in the backend encoding scheme cause problems. And you can't change the mainframe encoding cause it's been set that way since 1970 and nobody is going to risk changing it.

    edit: It's still dumb, because the password should be getting hashed on the front end and the hash sent to the backend, but it's possible that they are interfacing with a backend layer that takes the password itself in cleartext. Probably on the design philosophy of "hey, lets just take the existing password authentication from the mainframe and use that instead of spending a bunch of time and money developing a new thing to do what it already does."

    There's also a fair chance that they've also replaced the old mainframe system with something that precisely emulates it, and at great cost (because “they can't risk changing any of the clients”). It's like a version of the “this is my great-grandfather's axe” story, but without any sort of happy ending; until someone decides to point out that the emperor is butt-naked and prancing down the middle of Main Street, everyone's going to just keep on pretending and layering crap on crap. The more I hear of what really happens inside banks (and other related institutions, like insurers), the less I wish to know.


    No, Morbs. That particular emperor is now in his late 50s; it's not an image you (or anyone else even vaguely sensible) would want to contemplate.



  • @dkf said:

    @morbiuswilters said:
    Oh, yeah, it also doesn't support IE, so it's about as useful as strong, masculine, heterosexual character in a Wes Anderson film.
    You have to support IE still? Much is explained.

    IE 10+ is a substantially better browser than Firefox or Safari. I don't know about Opera, because nobody has actually ever downloaded Opera; it's more of a primordial myth than anything.



  • @morbiuswilters said:

    Google had a thing where Chrome would "pin" some sites so even if you tried to go to the HTTP site Chrome itself redirected you to the SSL site
    That's good for security, but it tends to break a lot of public WiFi hotspots, because it prevents the hotspot from redirecting you to the Terms of Service that you have to accept to get to any other site. Nothing loads, and there's no explanation of why.



  • @morbiuswilters said:

    I don't know about Opera, because nobody has actually ever downloaded Opera; it's more of a primordial myth than anything.
    Earlier today I came across an old file I had forgotten about.  It's a screen shot of Altavista, made while running Opera, dated December 2001, which I'm pretty sure is the last time anyone ever used either of those.



  • @dkf said:

    @morbiuswilters said:
    Oh, yeah, it also doesn't support IE, so it's about as useful as strong, masculine, heterosexual character in a Wes Anderson film.
    You have to support IE still? Much is explained.
    IE still has huge market share. If you don't support it, you're either an obnoxious FOSStard, a hipster presumably working for a website whose name is missing one or more vowels, or really not interested in customers. What's more, any IE version greater than 9 is a solid browser (I actually think 9 is pretty good, too, but others whose opinions I respect are mixed on it). I'd go so far as to say that IE11 is excellent. The days of IE6 support are at an end; even IE8 is tolerable by comparison.



  • @El_Heffe said:

    Opera
    @El_Heffe said:
    Altavista
    I'm sorry. Nobody here speaks Sanskrit.



  • @HardwareGeek said:

    @morbiuswilters said:
    Google had a thing where Chrome would "pin" some sites so even if you tried to go to the HTTP site Chrome itself redirected you to the SSL site
    That's good for security, but it tends to break a lot of public WiFi hotspots, because it prevents the hotspot from redirecting you to the Terms of Service that you have to accept to get to any other site. Nothing loads, and there's no explanation of why.

    Google's motto for some time has been "We're not happy 'til you're not happy."



  • @bstorer said:

    IE still has huge market share.

    "Slow down.. what share?"

    @bstorer said:

    (I actually think 9 is pretty good, too, but others whose opinions I respect are mixed on it).

    IE9 is as good as FuehrerFox, which means it's a flaming stretch of the Ganges. IE10+ is better than FF.

    @bstorer said:

    The days of IE6 support are at an end; even IE8 is tolerable by comparison.

    Yeah, when I hear people bitch about IE I figure they either don't do web development and are just working off three-year-old prejudice, or else they really suck at their job.



  • @morbiuswilters said:

    Google's motto for some time has been "We're not happy 'til you're not happy."
    Don't blame Google for your shortcomings. If you have wants and needs which cannot be easily monetized, then you'll have to get new wants and needs.



  • @morbiuswilters said:

    Yeah, when I hear people bitch about IE I figure they either don't do web development and are just working off three-year-old prejudice, or else they really suck at their job.

    For all the vitriol you hear about IE, even when it was bad it wasn't that bad.

    I used to annoy IE bitchers by asking, "what exactly is it that IE6 couldn't do but Firefox could? How come Google can get Gmail to run fine on IE6 and your shitty company can't?"

    "But IE requires more testing and bug-fixing!!!" Yeah, that's called "QA". You're supposed to be doing it for ALL the browsers, idiots.



  • @blakeyrat said:

    I used to annoy IE bitchers by asking, "what exactly is it that IE6 couldn't do but Firefox could? How come Google can get Gmail to run fine on IE6 and your shitty company can't?"
    The biggest problem I had with IE6 was that it lingered for way too long. It behaved differently - and worse - than everything after, including IE7, but you had to continue to support it for what felt like eons because so many people were still using it.



  • @blakeyrat said:

    "How come Google can get Gmail to run fine on IE6 and your shitty company can't?"

    "Not enough Fake Internet Money."

    @blakeyrat said:

    "But IE requires more testing and bug-fixing!!!" Yeah, that's called "QA". You're supposed to be doing it for ALL the browsers, idiots.

    I like to simplify my job as much as possible, so that even a slightly-drunk monkey could do it. Then I hire that monkey and I'm free to spend my days pursuing my life's work: Bob Vila image macros.


  • Discourse touched me in a no-no place

    @bstorer said:

    IE still has huge market share. If you don't support it, you're either an obnoxious FOSStard, a hipster presumably working for a website whose name is missing one or more vowels, or really not interested in customers.
    Or serve a different profile of users who aren't stuck with such ancient stuff. (I understand that IE11 is no longer nearly as big a problem, but my day-to-day doesn't require dealing with that sort of thing at all.)



  • @dkf said:

    @bstorer said:
    IE still has huge market share. If you don't support it, you're either an obnoxious FOSStard, a hipster presumably working for a website whose name is missing one or more vowels, or really not interested in customers.

    Or serve a different profile of users who aren't stuck with such ancient stuff. (I understand that IE11 is no longer nearly as big a problem, but my day-to-day doesn't require dealing with that sort of thing at all.)

    Yeah, still plenty of big company / government customers who are still dragging their heels and using IE8. Once they get past that, quality of life improves, but we're not all there yet.



  • @blakeyrat said:

    For all the vitriol you hear about IE, even when it was bad it wasn't that bad.



    I take it you never had to support IE 5.5 for Mac?

    That was. lets just say, "challenging" for web dev.

    IE6, which was out for Windows at the same time, was, by comparison AMAZING and BLAZINGLY fast. Mac never got another version of IE, which is not very surprising.



  • @boomzilla said:

    Yeah, still plenty of big company / government customers who are still dragging their heels and using IE8. Once they get past that, quality of life improves, but we're not all there yet.

    IE8 is dragging their heels? I still need to support IE6 for my big company customer (but they're an insurance company so massively out of date is expected).



  • @locallunatic said:

    @boomzilla said:
    Yeah, still plenty of big company / government customers who are still dragging their heels and using IE8. Once they get past that, quality of life improves, but we're not all there yet.

    IE8 is dragging their heels? I still need to support IE6 for my big company customer (but they're an insurance company so massively out of date is expected).

    Yes, it is. You've got it even worse, of course. It took XP going EOL to get my company to finally move on to Win 7 (meaning that as recently as about a year ago, you'd get XP installed on a new machine). I think they may have allowed IE7 back then, but I'd already put Linux on mine, so I'm a little unclear about those timelines.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.