• DrRenz (unregistered)

    How to successfully annoy your users even more:

    "This site doesn't need javascript. Please turn it off."

  • justsomedude (unregistered) in reply to Edward Royce
    Edward Royce:
    ...use Javascript...for doing -server side- coding...

    Holy [nsfw]! gasps

  • m0ffx (unregistered) in reply to BeOS easter eggs
    BeOS easter eggs:
    http://www.eeggs.com/items/15121.html
    
    #include <stdio.h> 
    #include <be/kernel/OS.h> 
    
    int main() 
    { 
        printf("%f\n", is_computer_on()); 
        printf("%i\n", is_computer_on_fire()); 
    }
    

    How this works is simple. The monitor has "The computer is ___ off" burnt into its screen such that it is visible when the computer is off. When the computer is on, the code displays the word 'not', making it read "The computer is not off." As for fire, well that unfortunately depends on the computer having the hardware smoke detector.

  • _dew_ (unregistered) in reply to JuanCarlosII
    JuanCarlosII:
    <noscript> <script type="text/javascript"> location.href = 'no_js.htm'; </script> </noscript>

    ... obviously.

    This was exactly the comment I was hoping for.

    captcha: tristique

  • Jay (unregistered)

    SOFTWARE DEVELOPMENT is to JAVASCRIPT as MASS TRANSPORTATION is to ____________

    (a) Ford Pinto

    (b) tricycle

    (c) train wreck

  • BitFlipper (unregistered) in reply to Not THAT Alex

    I think you mean Schrodinger.

    The cat is only interesting until the box is opened. After that who cares. This code on the other hand is a little more interesting. Look at the uncertainty of being able to open it. Or in this case execute the function. I am thinking this code is what you get if you take Schrodinger cat and smash it into Heisenberg’s tombstone. Maybe.

    Oh well back to CESR.

  • Mark Broadhurst (unregistered)

    Reminds me of the JS implementation on

    http://hasthelargehadroncolliderdestroyedtheworldyet.com/

    if (!(typeof worldHasEnded == "undefined")) { document.write("YUP."); } else { document.write("NOPE."); }

    While theirs is a joke this probally isnt.

  • (cs) in reply to RBoy
    RBoy:
    Sashlik:
    Leo:
    Brompot:
    Here we send and email, alert the receiver by SMS, ICQ them to check their phone and walk by to tell them they're wanted on ICQ. Just in case some medium fails.

    ICQ? Is it still 1999 where you work?

    We love ICQ here in Russia, and use it widely :)

    In Soviet Russia, you don't seek me, ICQ!

    I'll be here all week, try the veal.

    This has been quoted for awesomeness!

  • (cs) in reply to Anon
    Anon:
    Code Dependent:
    aggle-rithm:
    case(BATTERY_OPERATED_MARITAL_AID) return false;
    Wouldn't that more accurately be, BATTERY_OPERATED_BACHELORETTE_AID?
    Someone's never been married for 5+ years...
    Once for five, and once for eight. That was enough of that. Now I practice Katherine Hepburn's philosophy: Live close by, visit often.

    And they never have to bring Bob with them, either.

  • (cs) in reply to Edward Royce
    Edward Royce:
    No wonder so many people are doing sites in flash.

    Ugh don't even get me started on flash. It is so user unfriendly. Can't book mark. control of the interface is taken form the users hands. Need plugins.

  • Edward Royce (unregistered) in reply to justsomedude
    justsomedude:
    Edward Royce:
    ...use Javascript...for doing -server side- coding...

    Holy [nsfw]! gasps

    Honestly I don't see the point of server-side Javascript. It's not like there isn't a dozen languages that do server-side coding already. And considering how "loose" Javascript is in enforcing good coding behavior I'm really not that keen to see ever increasing amounts of bad server-side coding.

    Wikipedia on server-side Javascript

    PHP is bad enough for anybody when it comes to dealing with misspelled variable names. Why anyone would want a language that is even worse is beyond me.

    Seriously folks. We got enough tools for doing server-side coding. Hell there is even -COBOL- for doing server-side web programming.

    And Hell it certainly is.

  • Edward Royce (unregistered) in reply to DeLos
    DeLos:
    Edward Royce:
    No wonder so many people are doing sites in flash.

    Ugh don't even get me started on flash. It is so user unfriendly. Can't book mark. control of the interface is taken form the users hands. Need plugins.

    I was writing on the point of how much easier it is for the programmer and to hell with the user.

    If the user was important they'd learn to code and wouldn't be bothering me!

    :) lol.

  • (cs) in reply to FriedDan
    <script> window.location = "http://www.myuglywebsite.com/js_enabled.php"; </script>

    If Javascript = off then you're ok.

    If Javascript = on then the browser gets redirected.

    shrug that's what I know. Is there a better method?

    Hmm, easy enough to circumvent.

    For those who have missed the references.

    The <noscript> tag. Content inside this tag is only shown if JavaScript is turned off or if the browser does not support it.

    http://www.w3schools.com/TAGS/tag_noscript.asp

    Hmm, easy enough to circumvent.

    Until someone explains a better solution, I'm going with

    Move the super sensitive stuff to the server, and just add 'hey this probably isn't going to work right' in a noscript tag.

    as the best practice. Well next-best practices, I guess. Anything less than 100% functionality w/o javascript will have accessibility and security advocates calling for your head.

  • Edward Royce (unregistered)

    And in case anybody thought I was kidding:

    http://authors.aspalliance.com/aldotnet/examples/coboldotnet.aspx

    COBOL.NET!

    Ahhhh the joy of looking through thousands of lines of COBOL code trying to find where the missing "." is.

    There are some real freaks out there in computing community.

  • Crabs (unregistered)

    If they just did it backwards, this would work perfectly. Make the default page the error page, and if javascriptEnabled returns true send them to the real page.

    How is finding out if javascript is enabled hard, again? <noscript> still works, AFAIK.

  • (cs) in reply to obediah
    obediah:
    <script> window.location = "http://www.myuglywebsite.com/js_enabled.php"; </script>

    If Javascript = off then you're ok.

    If Javascript = on then the browser gets redirected.

    shrug that's what I know. Is there a better method?

    Hmm, easy enough to circumvent.

    For those who have missed the references.

    The <noscript> tag. Content inside this tag is only shown if JavaScript is turned off or if the browser does not support it.

    http://www.w3schools.com/TAGS/tag_noscript.asp

    Hmm, easy enough to circumvent.

    Until someone explains a better solution, I'm going with

    Move the super sensitive stuff to the server, and just add 'hey this probably isn't going to work right' in a noscript tag.

    as the best practice. Well next-best practices, I guess. Anything less than 100% functionality w/o javascript will have accessibility and security advocates calling for your head.

    I'm not sure what "circumvent" has to do with this. Usually this kind of checking is for sites that require JavaScript for some reason but need to fail gracefully in the event that it isn't there.

    What exactly is the case you're worrying about being circumvented here?

  • b01000100 (unregistered) in reply to Tempura
    Tempura:
    1) They appear on thedailywtf.com
    1. They appear on thedailywtf.com, because they made a wtf failure.
    [image]
  • Gordon (unregistered) in reply to BitFlipper
    BitFlipper:

    Oh well back to CESR.

    Oh well back to CERN. Fixed it for you.

  • (cs) in reply to FriedDan
    FriedDan:
    The <noscript> tag. Content inside this tag is only shown if JavaScript is turned off or if the browser does not support it.
    Does <noscript> alone fix the problem? Sure, it tells you when scripting is totally off. But it doesn't tell you when some scripting is on but JavaScript is nonfunctional. (Or is JavaScript the only kind of scripting that HTML ever has and ever will support?) </noscript>
  • SomeCoder (unregistered) in reply to DeLos
    DeLos:

    Ugh don't even get me started on flash. It is so user unfriendly. Can't book mark. control of the interface is taken form the users hands. Need plugins.

    Not to mention that said plugins are often buggy, slow, can be exploited, and also can be used to serve up some of the most irritating advertisements that mankind has ever known.

  • (cs)

    I once found similar code in the web app from an electricity services company which generated your bill. This came out while trying to understand why the F it didn't print properly on Firefox and "all right-clicks are disabled for your safety".

  • LouCypher (unregistered)

      Must be the same developer who made Marlboro website.  

  • (cs) in reply to AlpineR
    AlpineR:
    FriedDan:
    The <noscript> tag. Content inside this tag is only shown if JavaScript is turned off or if the browser does not support it.
    Does <noscript> alone fix the problem? Sure, it tells you when scripting is totally off. But it doesn't tell you when some scripting is on but JavaScript is nonfunctional. (Or is JavaScript the only kind of scripting that HTML ever has and ever will support?)</div></BLOCKQUOTE> <p>It should handle both cases properly, regardless of scripting language used.</p> <p>According to the W3C standard.</p> <BLOCKQUOTE class="Quote"><div>The NOSCRIPT element allows authors to provide alternate content when a script is not executed. The content of a NOSCRIPT element should only be rendered by a script-aware user agent in the following cases: <pre><code>* The user agent is configured not to evaluate scripts. * The user agent doesn't support a scripting language invoked by a SCRIPT element earlier in the document.</div></BLOCKQUOTE> </code></pre> </noscript>
  • (cs) in reply to FriedDan
    FriedDan:

    I'm not sure what "circumvent" has to do with this. Usually this kind of checking is for sites that require JavaScript for some reason but need to fail gracefully in the event that it isn't there.

    What exactly is the case you're worrying about being circumvented here?

    In this case, circumvention would mean getting access to the page requiring javascript without executing the javascript embedded in the page.

    The title of the article is "Bulletproof JavaScript Detection". You don't make something bulletproff unless you're worried about someone shooting bullets at you.

  • jordanwb (unregistered)

    Personally I think isComputerOn() is a bigger fail than the javascript one.

    DrRenz:
    How to successfully annoy your users even more:

    "This site doesn't need javascript. Please turn it off."

    Nice.

  • Keybounce (unregistered) in reply to Anonymous
    DeLos:
    so what is a good way to check for JS detection...
    Anonymous:
    The simplest way is to present the non-javascript version and turn on javascript functionality using javascript. If the javascript page is very different you may redirect the user with javascript.

    The best way is to make sure that the page works without javascript so you don't really care if the user has javascript enabled or not.

    No, no, no. First, if you actually do that, then you will not even need the JS, so you might as well not have it -- that puts programmers out of a job.

    Secondly, this person isn't asking how to detect JS; he's asking how to detect JS detection.

    Finally, keep in mind that with NoScript, you might be able to run some but not all of your script if it comes from different locations.

    Capcha:: What is "enim" anyways?

    Oh: <noscript> won't work if you have NoScript. Then, scripting is enabled but empty.

    Sigh. When will browsers actually let us choose from various page representations, rather than assuming that the "best" is the only one we want?

    Frankly the whole issue of Javascript on/off, issues with differences in functions, objects, DOM and other bullcrap makes writing web apps annoying at best and vastly irritating at worst.

    No wonder so many people are doing sites in flash.

    Just use "WebObjects". Everything is server-side, you serve a plain web page to the client, and Apple guaranteed when they took over NeXT that they would continue to support it -- would they lie?

  • Mark Draughn (unregistered) in reply to Edward Royce
    Edward Royce:
    Honestly I don't see the point of server-side Javascript.
    Well, it sure would be nice if the browser and the server shared a language. It would be one less thing to learn about web programming. You could validate user fields with the same code on both ends, and with a little framework support you could marshall objects back and forth between the server and the browser without having to implement everything twice. It's not a huge win---most apps don't need it---but there are cases where it would be nice.
  • hali (unregistered)

    This is actually better than the code my bank used to use. That had a similar function, only instead of just returning true, it checked if the browser was IE or Netscape. If you were using anything else that supported javascript you'd be taken to a page to tell you to get a browser that supported javascript. If you were using a browser without javascript support, of course, it let you right in...

  • (cs)

    i once won a Useless Utility contest where i had the user tell the program whether he could see any colors in the picture i was displaying. if he answered yes, it would determine that it was a color display.. not exactly the same, but still wtf'ish !

  • iMalc (unregistered)

    Commenting is enabled

  • (cs) in reply to Edward Royce
    Hell if you think this stuff is amusing you see Google the fools who want to use Javascript as their language for doing -server side- coding.

    shrug what can I say.

    Javascript syntax is quite nice. It makes rapid prototyping possible.

    Just strap a JIT compiler on or pre-process it into Java syntax.

    Re: Article I feel like an old fart for using <noscript> in this situation.

  • Keybounce (unregistered) in reply to BikeHelmet
    BikeHelmet:
    Hell if you think this stuff is amusing you see Google the fools who want to use Javascript as their language for doing -server side- coding.

    shrug what can I say.

    Javascript syntax is quite nice. It makes rapid prototyping possible.

    Just strap a JIT compiler on or pre-process it into Java syntax.

    Re: Article I feel like an old fart for using <noscript> in this situation.

    Actually, people have commented on the good side of using Javascript as a development language on Windows.

    You have rapid prototyping, and the ability to use (essentially) all of the windows libraries for access to system objects, windows, etc.

    Apparently, it works really nicely. I've never done it myself.

  • Great link for WTF source material buried in this article (unregistered)

    This is a test.

    If you can't see this message, please notify the blog operator so that they can troubleshoot the problem.

  • (cs) in reply to Mark Draughn
    Mark Draughn:
    Edward Royce:
    Honestly I don't see the point of server-side Javascript.
    Well, it sure would be nice if the browser and the server shared a language. It would be one less thing to learn about web programming. You could validate user fields with the same code on both ends, and with a little framework support you could marshall objects back and forth between the server and the browser without having to implement everything twice. It's not a huge win---most apps don't need it---but there are cases where it would be nice.

    In can understand the appeal of shared development on a theoretical level, but a real world implementation has some serious issues:

    1. This almost certainly means moving javascript to the backend rather than moving your backend language to the browser. Writing your entire application in javascript would be torturous if not impossible, so you still have to work in 2 languages.

    2. By sharing validation code, you end up running browser-hacks on your server.

    3. Complex validation will involve database queries and other supporting code that will need to be executed twice anyway (once to send data for the in-browser checks, and once again when the browser request comes back)

    4. Not everyone wants to expose all of their validation logic to the user. Either for security or IP reasons.

    Keep business logic validation in your business logic language, and perform simple, cursory checks on the client side. Make sure a credit card number is 16 digits and the expiry data is well formed in javascript, don't verify that the account is valid and has sufficient funds.

  • Sixnutz, MD (unregistered) in reply to Edward Royce
    Edward Royce:
    justsomedude:
    Edward Royce:
    ...use Javascript...for doing -server side- coding...

    Holy [nsfw]! gasps

    Honestly I don't see the point of server-side Javascript. It's not like there isn't a dozen languages that do server-side coding already. And considering how "loose" Javascript is in enforcing good coding behavior I'm really not that keen to see ever increasing amounts of bad server-side coding.

    Wikipedia on server-side Javascript

    PHP is bad enough for anybody when it comes to dealing with misspelled variable names. Why anyone would want a language that is even worse is beyond me.

    Seriously folks. We got enough tools for doing server-side coding. Hell there is even -COBOL- for doing server-side web programming.

    And Hell it certainly is.

    i'm not 100% on this, but I think you can do classic ASP in jscript. which would probably be somewhat masochistic, if it weren't for the fact the other choice was VB.

    captcha: nulla. as in "nulla nulla nulla".

  • Paul (unregistered)

    I once came across code (in a site I was handed to maintain) that was IE-only.

    It checked whether the browser was IE or any other browser ... and used JScript to do the check and display the error message that non-IE browsers weren't supported. It was live for several months before I got it and fixed it (to not do any browser check since there was nothing IE-specific there).

  • Anonymous Coward (unregistered)

    The logic there is almost as good as displayed by this website:

    http://www.hasthelhcdestroyedtheearth.com/

    captcha: distineo

  • Paul (unregistered) in reply to Paul
    Paul:
    I once came across code (in a site I was handed to maintain) that was IE-only.

    It checked whether the browser was IE or any other browser ... and used JScript to do the check and display the error message that non-IE browsers weren't supported. It was live for several months before I got it and fixed it (to not do any browser check since there was nothing IE-specific there).

    Sorry, I just realized some people mightn't know what JScript is ... it's the IE-only dialect of JavaScript so if you visited the site in e.g. Firefox, you got a half-rendered page that told you nothing.

  • fanha (unregistered)

    The real WTF is the number of pages that don't even think of this. This is laughable but at least more thoughtful than tons of other pages out there who just plain didn't even think to support/test non-javascript. In theory now that they know their mistake, it could probably be ported to support no javascript fairly expediently. So this is a relatively low-cost WTF fortunately.

  • (cs)

    Reminds me of when I worked for the Eudora group at Qualcomm. We had a whole wall full of "I forgot my password and can't check my mail, can you please email it to me?" tech support emails.

    I never understood what it took for someone to send an email like that.

  • (cs) in reply to wee
    wee:
    Reminds me of when I worked for the Eudora group at Qualcomm. We had a whole wall full of "I forgot my password and can't check my mail, can you please email it to me?" tech support emails.

    I never understood what it took for someone to send an email like that.

    Then you're clearly not very imaginative. If they were able to EMAIL YOU the request, then clearly they have an alternate EMAIL address that you can send a password to. Most of us have more than one e-mail address.

  • (cs) in reply to jlintz
    jlintz:
    So this is why the stock market crashed

    Nope, that'll be the function

    double rnd(double)
    that I uncovered the other day. No, it didn't produce a random number (at least not intentionally), but attempted to round a floating-point number by converting to decimal, rounding that to the appropriate number of decimal places, then converting back to floating point.

    Addendum (2009-03-16 17:06): N.B. That function didn't really cause the crash.

  • (cs) in reply to Edward Royce
    Edward Royce:
    And in case anybody thought I was kidding:

    http://authors.aspalliance.com/aldotnet/examples/coboldotnet.aspx

    COBOL.NET!

    Ahhhh the joy of looking through thousands of lines of COBOL code trying to find where the missing "." is.

    There are some real freaks out there in computing community.

    It's a combination of comfort zone and resistance to change. I had a boss a while back who was a COBOL programmer from way back. I can remember, although we had VB.Net and the brand-new C# to work with, he sighed wistfully and said he couldn't wait until Cobol.Net came out.

  • (cs) in reply to obediah
    obediah:
    In can understand the appeal of shared development on a theoretical level, but a real world implementation has some serious issues:
    1. This almost certainly means moving javascript to the backend rather than moving your backend language to the browser.
    How would you do that? I think if you could somehow change the language ont he client, that's the first thing most developers would do. But as things are, it seems we're stuck with javascript there after all, as ugly as the language may be.

    (At least if you don't use framewors like GWT, which is an awesomeness in its own right)

    Writing your entire application in javascript would be torturous if not impossible
    Not really. There are many techniques and frameworks that fix a big part of JS's flaws. Also, keep in mind that about 2/3 of Firefox and Thunderbird are written in Javascript, not to mention the heaps of extensions. Apparently the developers didn't go mad yet :)
    2) By sharing validation code, you end up running browser-hacks on your server.
    1. Complex validation will involve database queries and other supporting code that will need to be executed twice anyway (once to send data for the in-browser checks, and once again when the browser request comes back)

    2. Not everyone wants to expose all of their validation logic to the user. Either for security or IP reasons

    In a sane system, there'd probably be some code you run exclusively on the server (and which would not be exposed to the web), some code you just run on the client and some code you run on both sides. As for executing the code twice... so what? As long as I don't have to write it twice, I'm fine.

    I think what server-side JS would really make easier is graceful degradation of AJAX sites. So far, if you make really heavy use of JS and DHTML (like, e.g. the GMail client) you basically have to duplicate all your logic on the server in case the client supports no JS. Of your server code were in JS too, though, you could just execute those parts on the server and store your document model in a session.

    ... and perform simple, cursory checks on the client side.
    Once again, the right tool for the job. If you're just writing a web interface for an in-house app, go on. But you your job is to create a flashy web 2.0 ajax site, that isn't really an option.
  • (cs) in reply to WhiskeyJack
    WhiskeyJack:
    wee:
    Reminds me of when I worked for the Eudora group at Qualcomm. We had a whole wall full of "I forgot my password and can't check my mail, can you please email it to me?" tech support emails.

    I never understood what it took for someone to send an email like that.

    Then you're clearly not very imaginative. If they were able to EMAIL YOU the request, then clearly they have an alternate EMAIL address that you can send a password to. Most of us have more than one e-mail address.

    Or, they have set their mail client to memorize their password for them and now six months later, the first time they try to use the webmail interface, realise they have no idea what it is. And all their mail client will tell them is that it's "*******".
  • jDeepbeep (unregistered) in reply to OneMHz
    OneMHz:
    This WTF wins the intertubes.

    ... but only if Javascript is turned on.

  • Mr.'; Drop Database -- (unregistered) in reply to Jay
    Jay:
    SOFTWARE DEVELOPMENT is to JAVASCRIPT as MASS TRANSPORTATION is to ____________

    (a) Ford Pinto

    (b) tricycle

    (c) train wreck

    (d) unicycle

  • Bix Lee (unregistered) in reply to Code Dependent
    Anon:
    Code Dependent:
    Someone's never been married for 5+ years...
    Once for five, and once for eight. That was enough of that. Now I practice Katherine Hepburn's philosophy: Live close by, visit often.

    Yer doing it wrong (43 years, same wife).

    Bix

  • Pauldy (unregistered)

    Wow for once a true WTF story, I'm gona guess it is fake.

  • sumoman (unregistered)

    There is one idiot proof solution

    <head>
    <noscript>
    <meta id="metaRefresh" http-equiv="refresh" content="0;url=/markup.html"/> 
    </noscript>
    </head>

Leave a comment on “Bulletproof JavaScript Detection”

Log In or post as a guest

Replying to comment #:

« Return to Article