They are a good fallback, I think he is talking about using things such as Local storage, session storage, or global storage. Since the site is their mobile site I see no reason why they aren't using the new technology available to us since most mobile devices would be able to use it. DOM storage seems to be a better fit for shopping carts than cookies anyways.
It's not about the shopping cart. It's about all the session data, especially for authentication. While you could use Dom storage for storing a session ID, you would have to send that through to the server with every request which you get for free with cookies.
Additionally, cookies can be marked as http only or even as secure, making it very hard to lose the token by virtue of a fire sheep like, or even just XSS attack.
For that reason, I personally would prefer a site using (session) cookies to one hacking it via DOM storage any day.
And finally, depending on the store you might want to persist the shopping cart between visits- likely across machines. Thus, the cart should be stored on the server and not in DOM storage.
Cookies are stored on the client just like DOM Storage, so nothing is free when it comes to requests and communicating with the server. I understand that both still have their place. Though I generally prefer to use DOM Storage for most things now depending on the use case. I also complete agree about keeping server-side session data.
with "free" I meant without additional effort for the developer.
When you set a cookie with a Set-Cookie header, the client will automatically send the cookie with all further requests.
When you put the session-ID somewhere in DOM storage, you have to manually amend all requests with that session-ID - either by appending it as a get parameter or, when you do nothing but AJAX, as an additional request header - but whatever you do, it's considerably more effort.
Also, looking at our logs, I see way more users with DOM storage disabled than with cookies disabled, but that might just be my user base.
Alright, thanks for the clarification on "free", I realized that is what you might have meant after posting.
That last bit about your logs is surprising, thanks for that bit of info. I may need to go do the same. Either way I use a storage wrapper so I am accommodating both types of users.
It's probably necessary for click tracking. Macy's will pay either a CPC or a CPA for traffic coming into their website, and that includes traffic to their homepage.
keeping a session id in the URLs is way less secure as it is susceptible to XSS attacks, it can leak in referer headers, it can be accidentally shared by people copy & pasting the URL and by extension, the session ID might even end up in a search engine and depending on your bad luck, the bots might visit the page just often enough so the session doesn't expire on the server at which point an authenticated session is in the search engines.
Session cookies on the other hand can be marked as http-only, mitigating XSS in many browsers (there are some that still screw this up with XmlHttpRequest) and by not having the session id in the url, the id is much less likely to be shared with others, nor to appear in search engines.
Also, it keeps the URLs nice looking.
So why exactly would one want to disable session cookies?
Because of all of the above reasons, I'd much rather keep users with cookies disabled away from my application than to subject them to the ugly URL fallback which will impact their security much, much more than the perceived privacy loss of session cookies (which go away when you close the browser)
