Need a car?



  • I found this in a reddit post. I actually burst out laughing. My co-workers think I'm crazy now. Well, they always thought I was crazy.


    <a href="http://www.lingscars.comm/>LingsCars



  • Looks like a 1996 website but it has a twitter feed!

    It's the site owner's feed I think. This is spammed on it: "Does your Website look like this? http://t.co/zxo1I5tiRP We can help! :) #websitedesign #design #gatineau #ottawa #Website"

    Ow wow I just scrolled down an I think my brian BSOD.



  • Take a look at the source. ASCII art FTW!



  • This guy knows exactly what he's doing. This is Chuck Testa territory.

    @LingsCars said:

    ...how it works!

    1. Choose a car to lease or get a quote
    2. Fill in online car leasing proposal form
    3. Get accepted for contract hire finance
    4. Sign a lease order form
    5. Complete posted documents
    6. Take lease delivery, like Chinese takeaway
    7. Drive and show off & impress stupid friends
    8. After a few years, order a new lease car or walk away... you have no commitment!


  • MESS WITH MY WEBSITE, AND YOU'RE DEAD!



  • @LingsCars said:

    		<!--[if lte IE 7]>
    <style>
    div#troll{
    margin-top:0px;
    position:absolute;
    z-index:99999;
    left: 40%;
    top: 200px;
    }
    </style>
    <![endif]-->



  • Ok, did you see the game? There's a game in Flash, and for iOS!

    I think the guy knows exactly what he's doing here. I mean, ASCII art, Flash/iOS game, IE7 troll and more. I think he's doing this on purpose and because he can.



  •  It has to be a joke. Who in their right mind would rent a Reliant Robin for $240/month, especially when they have a DMC-12 on offer?

     



  • That was posted here ages ago but I can't find it on Google so I'm not going to make a "dupe" post.



  • @mikeTheLiar said:

    This guy knows exactly what he's doing. This is Chuck Testa territory.
    I know you may not have seen very many of them in the wild, but you do know that Ling is not a guy don't you? Ling is in fact something called a "woman".



  • @NoOneImportant said:

     It has to be a joke. Who in their right mind would rent a Reliant Robin for $240/month, especially when they have a DMC-12 on offer?

     

    Well if you try and order the Delorean, Ling points out that it's a J-O-K-E



  • @mikeTheLiar said:

    MESS WITH MY WEBSITE, AND YOU'RE DEAD!
    Lighten up, Francis.



  • If I was a car salesman, I'd go out of my mind waiting for a customer to show up. If I knew how to write html and a few other tricks, I'd probably spend my downtime making really funky websites for my dealership too.



  • @OzPeter said:

    @mikeTheLiar said:
    This guy knows exactly what he's doing. This is Chuck Testa territory.
    I know you may not have seen very many of them in the wild, but you do know that Ling is not a guy don't you? Ling is in fact something called a "woman".

    I was also under the impression it was a dude until I saw the newspaper clipping near the bottom.



  • @blakeyrat said:

    That was posted here ages ago but I can't find it on Google so I'm not going to make a "dupe" post.

    Well if it's that old she had plenty of time to fix the planet collision bug by now. She's probably using Git and can't figure out how to merge files.



  • I have a plugin called "web of trust' installed that warns me when going to (previously identified) dodgy websites... http://www.mywot.com/en/scorecard/lingscars.com?utm_source=addon&utm_content=warn-viewsc



  • @OzPeter said:

    @mikeTheLiar said:
    This guy knows exactly what he's doing. This is Chuck Testa territory.
    I know you may not have seen very many of them in the wild, but you do know that Ling is not a guy don't you? Ling is in fact something called a "woman".

    shock horror dramatic chord brain melt


  • Note: I live inside this website Monday to Friday 9am-6pm, to give you the very best service and make your experience a happy one! - I am Ling, accept no substitute

    I live in an apartament that's tidier and less messy than that, and I'm a college student.

    Personally, I think this webpage has seeped from an alternate universe, where iOS, CSS and all these things have been invented just like here, but all the web designers in the 90's thought to themselves "Eh, the World Wide Web as it is today is the peak of our creativity, we can't possibly top that". Though...

    EU cookie law. Piss off Von Rumpy. Me... I hammer visitors to death with cookies, so I can find out what they want. EU Cookie Law Cookies allow my website to serve visitors the content they need. Get used to it. The EU cookie law is an ass. - Ling

    ...he has some valid points.


  • Discourse touched me in a no-no place

    @Maciejasjmj said:

    ...he has some valid points.
    At the risk of repeating something already pointed out, that's not a 'he'.



  • @Maciejasjmj said:

    Though...

    EU cookie law. Piss off Von Rumpy. Me... I hammer visitors to death with cookies, so I can find out what they want. EU Cookie Law Cookies allow my website to serve visitors the content they need. Get used to it. The EU cookie law is an ass. - Ling

    ...he has some valid points.

     

    I was hoping the EU cookie law would actually get sites to think about their use of cookies, and not do stupid things like send a new cookie on every keystroke, when I'm not logged in or doing anything non-anonymous. Apparently not, though.

    So far, my response has been to, every now and then, accept and reject cookies at random whenever I get sufficiently annoyed. I haven't observed any sites breaking when I do this (given that I don't do it when I'm actually intending to log in), which makes me suspect that the cookie are completely pointless, or at least, not to my benefit.

    I might go one step further some time in the future and just randomly perturb their contents, to see if that breaks sites. If even that doesn't do the trick, then I conclude that sites that claim that their cookies are strictly necessary are just simply lying, and sites that claim their cookies are useful in any way at all (and yet don't break when I do that) are also lying.

     


  • Considered Harmful

    @ais523 said:

    So far, my response has been to, every now and then, accept and reject cookies at random whenever I get sufficiently annoyed. I haven't observed any sites breaking when I do this (given that I don't do it when I'm actually intending to log in), which makes me suspect that the cookie are completely pointless, or at least, not to my benefit.

    I might go one step further some time in the future and just randomly perturb their contents, to see if that breaks sites. If even that doesn't do the trick, then I conclude that sites that claim that their cookies are strictly necessary are just simply lying, and sites that claim their cookies are useful in any way at all (and yet don't break when I do that) are also lying.


    Wow, you really showed them, when you made their analytics a fraction of a fraction of a percent inaccurate a couple times a day!



  • I posted this on snoofle's job ad thread before I realised that there is a whole thread dedicated to the coding masterpiece that is longscars;

    Ling (the woman behind that website / car lease business) was on Dragons Den in the UK (not sure whether there's a US version, but you pitch to entrepeneurs) and she is certifiably insane. That's a real website up there, unsurprisingly, all handmade by Ling. She makes a ton of money, though...

    She can even lease you a delorean! Get yourself a delorean!



  • @skotl said:

    She can even lease you a delorean! Get yourself a delorean!
     

    I tried to use that joke and got yelled at. 



  • @ais523 said:

    I conclude that sites that claim that their cookies are strictly necessary are just simply lying, and sites that claim their cookies are useful in any way at all (and yet don't break when I do that) are also lying.

     

    Cookies are becoming obsolete because they are not well-suited for mobile (they are uploaded with each request and that does not help an upload bandwidth that already sucks). It's the circle of life because all the same tricks to optimize websites for dial-up connections in the late 90s are becoming useful again, thanks to mobile phones. Glad to see that 15 years of IT innovation brought us back to removing whitespace and not closing html tags to save bandwidth.


  • Considered Harmful

    @Ronald said:

    @ais523 said:

    I conclude that sites that claim that their cookies are strictly necessary are just simply lying, and sites that claim their cookies are useful in any way at all (and yet don't break when I do that) are also lying.

     

    Cookies are becoming obsolete because they are not well-suited for mobile (they are uploaded with each request and that does not help an upload bandwidth that already sucks). It's the circle of life because all the same tricks to optimize websites for dial-up connections in the late 90s are becoming useful again, thanks to mobile phones. Glad to see that 15 years of IT innovation brought us back to removing whitespace and not closing html tags to save bandwidth.

    Doesn't everyone have 4G by now?



  • @Ronald said:

    Cookies are becoming obsolete because they are not well-suited for mobile (they are uploaded with each request and that does not help an upload bandwidth that already sucks).

    Just to recap:

    • Mobile phones don't have enough bandwidth to upload 100 bytes of text in an HTTP header.
    • Mobile phones have a user agent that is more than 100 bytes long
    • Making this post required me to upload 500kB of tags (which I'm sure the forum ignored completely)


  • @Ronald said:

    Cookies are becoming obsolete because they are not well-suited for mobile (they are uploaded with each request and that does not help an upload bandwidth that already sucks).

    I feel like we've had this conversation just a couple weeks ago but, whatever:

    So what do you recommend we use instead of cookies?

    I've heard claims similar to yours in the past, but I've never once heard a reasonable scenario where the typical e-commerce site could run without using cookies.



  • @joe.edwards said:

    @Ronald said:
    @ais523 said:

    I conclude that sites that claim that their cookies are strictly necessary are just simply lying, and sites that claim their cookies are useful in any way at all (and yet don't break when I do that) are also lying.

     

    Cookies are becoming obsolete because they are not well-suited for mobile (they are uploaded with each request and that does not help an upload bandwidth that already sucks). It's the circle of life because all the same tricks to optimize websites for dial-up connections in the late 90s are becoming useful again, thanks to mobile phones. Glad to see that 15 years of IT innovation brought us back to removing whitespace and not closing html tags to save bandwidth.

    Doesn't everyone have 4G by now?
    ...but still a 500MB/month cap.



  • @Ronald said:

    Cookies are becoming obsolete because they are not well-suited for mobile (they are uploaded with each request and that does not help an upload bandwidth that already sucks)

    My 3G phone has better upload bandwidth than my home ADSL. Hurry up NBN!



  • @blakeyrat said:

    @Ronald said:
    Cookies are becoming obsolete because they are not well-suited for mobile (they are uploaded with each request and that does not help an upload bandwidth that already sucks).

    I feel like we've had this conversation just a couple weeks ago but, whatever:

    So what do you recommend we use instead of cookies?

    I've heard claims similar to yours in the past, but I've never once heard a reasonable scenario where the typical e-commerce site could run without using cookies.

    The problem with cookies is that they are sent with every single request to the domain, even if it's an image tag which obviously won't use the cookie data (unless you use something funny like imageresizer). You can work you way around this by using different domains for static content but that's a bit tedious.

    Basically the idea is to extend the concept of cookieless session and to allow it to work across multiple connections so you don't need to store 3k of shit on the client that he will send with every single request. Stuff like this.

    There was a study done by Yahoo a while ago that demonstrated that a 3k cookie cause a 150ms slowdown. Another study by Amazon shown that every 100ms of latency cost them 1% in sales. And a while ago Google found that 500ms latency caused a 20% drop in traffic. If you just have a website with pictures of you cat nobody cares but if mobile customers are a big part of the business and they are not locked-in this is important stuff.



  • @Ben L. said:

    @Ronald said:
    Cookies are becoming obsolete because they are not well-suited for mobile (they are uploaded with each request and that does not help an upload bandwidth that already sucks).

    Just to recap:

    • Mobile phones don't have enough bandwidth to upload 100 bytes of text in an HTTP header.
    • Mobile phones have a user agent that is more than 100 bytes long
    • Making this post required me to upload 500kB of tags (which I'm sure the forum ignored completely)

    No, the real recap is that you significantly overestimate your grasp of key issues in mobile connectivity.



  • @joe.edwards said:

    @Ronald said:
    @ais523 said:

    I conclude that sites that claim that their cookies are strictly necessary are just simply lying, and sites that claim their cookies are useful in any way at all (and yet don't break when I do that) are also lying.

     

    Cookies are becoming obsolete because they are not well-suited for mobile (they are uploaded with each request and that does not help an upload bandwidth that already sucks). It's the circle of life because all the same tricks to optimize websites for dial-up connections in the late 90s are becoming useful again, thanks to mobile phones. Glad to see that 15 years of IT innovation brought us back to removing whitespace and not closing html tags to save bandwidth.

    Doesn't everyone have 4G by now?

    When you design for mobile, you can't expect that end users will have access to the highest possible bandwidth and lowest possible latency that their provider supports. Either you adapt your content dynamically depending on the latency you can detect (to be reevaluated after each request) or you think about the guy that will need to access stuff on your website while he's on the road between Calexico and Yuma.

    Even for non-mobile it's important to think about real life. Some people will access your site while using a shitty wifi at Howard Johnson or tethering on their mobile which has a spotty 2-bars connection. If your page makes 25 requests because "CSS sprites are tedious" or other stupid reason and you cookies are "only" 1k it's 25k you're uploading for no reason.



  • @Ronald said:

    @blakeyrat said:
    So what do you recommend we use instead of cookies?

    Basically the idea is to extend the concept of cookieless session and to allow it to work across multiple connections so you don't need to store 3k of shit on the client that he will send with every single request. Stuff like this.

    So your alternative to cookies is... cookies?

    Also, your argument is basically this: @Ronald said:

    STUDIES HAVE SHOWN THAT EATING 100000 KILOPOUNDGRAMS OF SUGAR COOKIES IS BAD FOR YOU. THEREFORE, ANY QUANTITY OF SUGAR COOKIES IS DEADLY AND MUST BE BANNED FROM HUMAN CONSUMPTION. EVEN LOOKING AT A SUGAR COOKIE WILL GIVE YOU DIABETES AND CANCER AND HERPES.


  • @Ronald said:

    Basically the idea is to extend the concept of cookieless session and to allow it to work across multiple connections so you don't need to store 3k of shit on the client that he will send with every single request. Stuff like this.

    Ok, saying "cookieless session" doesn't answer shit, it just reinforces the question: how do you track a session without cookies?



  • @blakeyrat said:

    @Ronald said:
    Basically the idea is to extend the concept of cookieless session and to allow it to work across multiple connections so you don't need to store 3k of shit on the client that he will send with every single request. Stuff like this.

    Ok, saying "cookieless session" doesn't answer shit, it just reinforces the question: how do you track a session without cookies?

    There you go.



  • @Ben L. said:

    @Ronald said:
    @blakeyrat said:
    So what do you recommend we use instead of cookies?

    Basically the idea is to extend the concept of cookieless session and to allow it to work across multiple connections so you don't need to store 3k of shit on the client that he will send with every single request. Stuff like this.

    So your alternative to cookies is... cookies?

    Also, your argument is basically this: @Ronald said:

    STUDIES HAVE SHOWN THAT EATING 100000 KILOPOUNDGRAMS OF SUGAR COOKIES IS BAD FOR YOU. THEREFORE, ANY QUANTITY OF SUGAR COOKIES IS DEADLY AND MUST BE BANNED FROM HUMAN CONSUMPTION. EVEN LOOKING AT A SUGAR COOKIE WILL GIVE YOU DIABETES AND CANCER AND HERPES.

    Since you think that posting random screenshots that means nothing is a way to support your point, here is one that proves I'm right.





  • Ronald, I seriously suggest you see a doctor. I think your brain might be broken.



  • @Ronald said:

    @blakeyrat said:
    @Ronald said:
    Basically the idea is to extend the concept of cookieless session and to allow it to work across multiple connections so you don't need to store 3k of shit on the client that he will send with every single request. Stuff like this.

    Ok, saying "cookieless session" doesn't answer shit, it just reinforces the question: how do you track a session without cookies?

    There you go.

    So your solution to having a few hundred characters in a cookie that doesn't get shared between users is adding a few hundred characters to every url on your site and letting users unintentionally share their account by copying a link?



  • @Ronald said:

    There you go.

    Ok let's humor you. Here's the second result.

    It says:

    @Stack Overflow User said:

    Cookieless session state uses the same principles, but doesn't use cookies to pass the session identifier around. Normally, this is passed as a parameter on the querystring.

    e.g.

    http://www.somewebsite.com/page.aspx?sid=jrkwojeqrojq3op349023231234r23rf2

    And here's why you're an idiot:

    The most obvious deal-breaker is that this method CANNOT be used on an e-commerce site, because if the link were shared to a friend/buddy/whoever, the session would also be shared. For example, I could add an item into my cart, give you the URL of an item I'm looking at, then you are sharing the same session I am-- if you add to your cart you've also added to mine. WTF!

    You can "solve" that by typing in another piece of data, for example the browser's IP. But oh wait, your cellphone's IP will change like crazy for literally no reason, so now not only is your session implementation stupid, it's actually BROKEN on mobile. Which seems to counter your main point.

    The second reason is: putting the session cookie value in the URL doesn't take any less space than putting it in the fucking cookie in the first place. So you save nothing.



  • @blakeyrat said:

    The most obvious deal-breaker is that this method CANNOT be used on an e-commerce site, because if the link were shared to a friend/buddy/whoever, the session would also be shared. For example, I could add an item into my cart, give you the URL of an item I'm looking at, then you are sharing the same session I am-- if you add to your cart you've also added to mine. WTF!

    The second reason is: putting the session cookie value in the URL doesn't take any less space than putting it in the fucking cookie in the first place. So you save nothing.

    For a typical web page, the browser will make multiple requests (one for the company logo, one for the background image, etc), none of which would contain the session ID in the URL. With each of those requests the browser will happily upload the cookies for the entire domain. That means all the cookies for the domain uploaded for each request to ANY content hosted on that domain. This quickly adds up to a lot more than having the ID in some of the URLs (which I never suggested in the first place). Read my other answer in thread about the studies that Yahoo, Amazon and Google have done on the impact of useless added latency - interesting numbers.

    As for the security thing: you don't blindly take a URL or id, you need to match the client, and this is typically done using the same technologies as ad trackers. On a mobile it could be, depending on the platform, the UDID, or a hash on the MAC address, or Apple IDFA.



  • @Ben L. said:

    @Ronald said:
    @blakeyrat said:
    @Ronald said:
    Basically the idea is to extend the concept of cookieless session and to allow it to work across multiple connections so you don't need to store 3k of shit on the client that he will send with every single request. Stuff like this.

    Ok, saying "cookieless session" doesn't answer shit, it just reinforces the question: how do you track a session without cookies?

    There you go.

    So your solution to having a few hundred characters in a cookie that doesn't get shared between users is adding a few hundred characters to every url on your site and letting users unintentionally share their account by copying a link?

    No.



  • @Ronald said:

    @blakeyrat said:

    The most obvious deal-breaker is that this method CANNOT be used on an e-commerce site, because if the link were shared to a friend/buddy/whoever, the session would also be shared. For example, I could add an item into my cart, give you the URL of an item I'm looking at, then you are sharing the same session I am-- if you add to your cart you've also added to mine. WTF!

    The second reason is: putting the session cookie value in the URL doesn't take any less space than putting it in the fucking cookie in the first place. So you save nothing.

    For a typical web page, the browser will make multiple requests (one for the company logo, one for the background image, etc), none of which would contain the session ID in the URL. With each of those requests the browser will happily upload the cookies for the entire domain. That means all the cookies for the domain uploaded for each request to ANY content hosted on that domain. This quickly adds up to a lot more than having the ID in some of the URLs (which I never suggested in the first place). Read my other answer in thread about the studies that Yahoo, Amazon and Google have done on the impact of useless added latency - interesting numbers.

    Even though that's not true, please do explain how a 20 byte session ID cookie is worse than a 20 byte user-visible session ID in the URL.

    Oh, you didn't suggest URL session IDs? That's right. In fact, you suggested absolutely nothing. So unless your nothing can uniquely identify users, I think the sane people are going to keep using cookies, honey.



  • Man. When fucking Ben L is calling you out as an idiot, man... that's when you know you're an idiot.



  • @Ben L. said:

    Even though that's not true, please do explain how a 20 byte session ID cookie is worse than a 20 byte user-visible session ID in the URL.

    If you start reading the thread, and not just the replies to your own posts, you will see that I already explained it twice. It's not because you mommy is still spoon-feeding you that other people have to do it to.

    @Ben L. said:


    Oh, you didn't suggest URL session IDs? That's right. In fact, you suggested absolutely nothing. So unless your nothing can uniquely identify users, I think the sane people are going to keep using cookies, honey.

    Again, I already explained it. But if you are happy with cookies then keep using cookies - with your current level of experience and skill set it's not like you are likely to have any impact whatsoever on actual users anyways.



  • @blakeyrat said:

    Man. When fucking Ben L is calling you out as an idiot, man... that's when you know you're an idiot.

    Well if that's what you think, there is obviously no point in keeping this discussion going. If you feel that this proves any kind of point, be my guest, but IMHO the only idiotic thing to do is to ignore a new approach because you don't understand at first how it is implemented or because some guy on a forum did not describe it simply enough for you to get it immediately.

    And if you call people idiots because you disagree with (or don't understand) the technical solutions they provide, don't come back crying like a little bitch about not being able to have serious discussions like you did a few weeks ago. Wuss.



  • @Ronald said:

    And if you call people idiots because you disagree with (or don't understand) the technical solutions they provide,

    You didn't provide a solution. You provided an alternative that had far more drawbacks than benefits, and frankly does not work.



  • @blakeyrat said:

    @Ronald said:
    Basically the idea is to extend the concept of cookieless session and to allow it to work across multiple connections so you don't need to store 3k of shit on the client that he will send with every single request. Stuff like this.

    Ok, saying "cookieless session" doesn't answer shit, it just reinforces the question: how do you track a session without cookies?

    The link gives an example of what someone claims to be a "cookieless session" using something they call "51Degrees.mobi-.Net Mobile Framework" (WTF kind of name is that?):
    The following code stores the
    last date and time the application received a request from the mobile
    device in the Mobile Profile. If the value is present when the page is
    subsequently requested a label is added to the page to display the
    previous value.

    protected void Page_Load(object sender, EventArgs e)
    {
        // Get the last accessed time from the mobile profile if it exists.
        string lastAccessedTime = MobileProfile["LastAccessedTime"] as string;
         
        // If the last accessed time exists then add a label to the page indicating
        // the last time the mobile device requested a page from the application.
        if (lastAccessedTime != null)
        {
            Label label = new Label();
            label.Text = String.Format("Last Accessed Time: '{0}'", lastAccessedTime);
            Page.Controls.Add(label);
        }
         
        // Store the last accessed time for future reference.
        MobileProfile["LastAccessedTime"] = DateTime.UtcNow.ToString();
    }

    The MobileProfile will persist data over a longer period of time than the Session. Data will not be flushed if the mobile device's browser is closed, the web site changed or the device restarted.

    Is this really a solution?  Is this really better than using cookies?  If there really is a better alternative to cookies why isn't everyone using it already?



  • @El_Heffe said:

    The link gives an example of what someone claims to be a "cookieless session" using something they call "51Degrees.mobi-.Net Mobile Framework" (WTF kind of name is that?)

    At the moment there are two major vendors for mobile detection: 51degrees.mobi and ScientiaMobile. Both are a fork from the WURFL project. Those are serious players in that business and if you haven't heard of them it's because you don't write apps for mobile. I provided a link to the .Net sdk because blakeyrat is (as far as I can tell) a .Net guy, but 51degrees supports (to some extent) .Net, Java, Php, Python and C. I never used ScientiaMobile because their prices are too high (it's free only if the client agrees to open-source the application that uses their mobile database).

    @El_Heffe said:

    Is this really a solution? Is this really better than using cookies? If there really is a better alternative to cookies why isn't everyone using it already?

    A mobile is very different from a PC or laptop. The key differences are: single-user paradigm, no right-click, no hover, larger hit area for buttons (because of the size of fingers), higher network latency and weaker processing resources (CPU and RAM). So if you design a web app that will have a significant mobile user base and you just use a slightly tuned CSS to accommodate mobile users, the end result will be pretty lame.

    Cookieless sessions rely first and foremost on uniquely identifying the client (then it's easy to match him to a session that is persisted in a database). If you don't want to pay for a proprietary framework (like 51degrees) you still can do a lot using free libraries (like phonegap.com) that makes it easy to use geolocation and the device UDID. You can also use other means such as detecting the browser configuration (see how unique you are using this demo from the EFF).

    So at the moment there is not one major technology that replaces cookies but you can work around them and on a mobile this is worth it. It would be convenient if mobile vendors could agree on something, like Google supporting Apple IDFA, but that fragmentation is not something new. Web development has been done for years with browser-specific limitations (that's why stylesheets are filled with -webkit and -moz prefixes).



  • I'll be blunt here: UDID or IDFA or a rabbit out of a hat, whatever, it still needs to be sent, so it uses up bandwidth same as a cookie.

    If your point is that its size is smaller than typical cookies, then you should be advocating responsible use of cookies, just for a small ID, instead of their complete replacement.

    If your point is it is limited to only some requests instead of all requests, the same can be accomplished with cookies using cookie path or different domains, if needed. My oppinion of the situation is that it isn't needed - provided that the previous point is addressed - no matter how many requests you make, 20 bytes more or less is not important. But if you disagree, you have a solution with cookies, without reinventing the internet.

    EDIT: Also, lets not fool ourselves here. UDID and IDFA and whatnot are not being introduced for the purpose of keeping a session within a single website. They are intended for tracking you across multiple sites and they can all die in horrible pain along with their creators and supporters as long as I'm concerned.



  • Cookies are only becoming obsolete because frameworks like jQuery and Dojo make it easy to build entire applications in JS, not because of bandwidth considerations. Good riddance anyway.


Log in to reply