Slashdot Mirror

I'm wondering if there is an example of something like an e-commerce site (therefor few/little ads) and is something more complicated than a Google question.

How well does, say, Phil's Hobby Shop work with script off?

Disclosure: Phil's Hobby Shop employs me.

Traditional Complexity rules ARE bad.

Would it be bad to retain the "must contain a letter" rule if the password is long enough? This RC car shop has these rules: 8-15 characters with at least 1 letter and 1 digit, or 16+ characters with at least 1 letter.

It's not PayPal itself, but the login page for Phil's Hobby Shop can work without JavaScript. The only part that changes with script off is that you have to submit with a blank password in order to enable "Show password as I type".

I hope you do realize I did not say "all".

Perhaps you're right that my worldview is skewed by the fact that I work on an e-commerce site as my day job.

Anyway, yes, I would pass session ID in the URL (after all, neither cookies contain a cart's contents, just an ID), and would not worry about users. Those using URLs should know what that is, the rest have buttons.

And then you get people who return to the home page by using an in-browser function that deletes everything after the hostname, with the result "I went back to the front page of the store to look for something else to add to the cart. Why was my cart emptied?" Even people who know how a URL is structured don't know which specific query parameter holds the session ID. And even the tinier minority of users who both know how a URL is structured and correctly guess which query parameter is the session ID delete one too many characters from the URL.

Worse yet: "Why did this unauthorized charge appear on my account? I put in my credit card number but decided not to place the order." The answer is that you shared the URI of a product that included your session ID, and someone else completed checkout with your payment credentials.

Many website developers today seem to think that his/her web pages only need to load on the fastest computers as the sole page open in the browser. I think of them as "greedy" websites, because they are greedy with the end-users' compute resources.

Would you say Phil's Hobby Shop is greedy?

From the article: "Passcodes that have a length of 20 or more can contain any character type an end user wants, including all lower case letters." And sites like Phil's Hobby Shop have lowered "complexity" requirements for sufficiently long passwords. I'm glad the passphrase concept is catching on. To what extent can xkcd be credited with awareness of passphrases?

Or a site deciding to use a different URI schema because it it better for SEO and not caring about compatibility?

Search engines count inbound links as one of the factors in the rank of a particular document. Keeping old URIs working alongside your new URIs keeps your old inbound links working, which can only improve the placement of the documents on a site. When I moved Phil's Hobby Shop to a different shopping cart package, I had the 404 handler try to interpret the old cart's URI schema and route requests to product search.

OK, let's back up a second and make sure that we are not kidding ourselves into thinking that any music played on a computer cannot somehow be recorded.

The record labels and movie studios have become comfortable with analog reconversion for private use that includes a DAC-speaker-microphone-ADC or DAC-display-camera-ADC in the path, just not digital reconversion that doesn't include this highly lossy step. Besides, a lot of video streams are considered rentals, and the provider wants to deter users from keeping the video past the rental period, which is a violation of terms of service.

I'm also not going to google for you how to maintain session state without cookies.

I just did, and I'm going to explain why I don't like the solutions that I found on the first couple pages of results.

• Associating a session with an IP address allows session hijacking if multiple users are behind one NAT or proxy.
• Including the session ID in all URLs and as a hidden input in all forms is fragile: someone using the back button would end up starting a new session. And as this page points out, it's more vulnerable to session hijacking when a user shares a link to product pages that happen to include old session IDs that may refer to private information.
• Storing a session ID in the modification date of an image is also fragile, as it causes session loss when a device's RAM fills up and the user's browser starts purging things from cache. I don't see how it would work anyway, as there's nothing to associate the HTML page load with the image load other than the IP address, which I mentioned above.
• window.name requires JavaScript and doesn't obey the same-origin or even same-domain policy.
• HTTP authentication requires users to register and log in before shopping, which users find prohibitively inconvenient.
• This page recommends making an order form that lets users copy and paste SKUs from another browser window and key in quantities, but it's almost as inconvenient as a phone order.

What keywords should I have used instead?

But as long as you make sure that the back buttons works, on all pages, all the time, even on your landing page

Cookies handle the back button better than the leading cookieless solution (session ID in URL) does.

you will be a much better developer.

I have tried to keep to this philosophy on an online store that I maintain on behalf of my employer, even though it does use a session cookie, does use the occasional (optional) animation, and does use the occasional (optional) script. We don't use anything like the Facebook/Twitter/Google+ social recommendation crap that too many sites use.

Phil's Hobby Shop appears to get away with calling them radio control airplanes and helicopters.

It's well known that they do this sort of stuff -- regularly sweeping money into a bank account will also get your account frozen.

When I first read your comment, I thought PayPal might do this to encourage people to spend the money in their PayPal accounts within the eBay-PayPal ecosystem, so that PayPal can milk 3% off each transaction. But then I realized that sweeping money into a bank account was commonplace among businesses whose suppliers don't accept PayPal, such as a business that buys radio control cars from a distributor and sells them on eBay or on its own web site. Is it really that much easier easier for an online retailer that sells physical goods to provide itemized invoices than for a company that sells services?

Generally, I hate forums that build their own password systems rather than using OpenID or Google Sign In or even Facebook login

This shopping cart uses OpenID and Google sign-in, but OpenID sign-in doesn't work for Yahoo! because Yahoo!'s OpenID provider uses redirects for the verification step and PHP cURL doesn't follow redirects if an open_basedir is set.

HTTP can be cached easily

Resources served over HTTPS, such as style sheets, scripts, and images, can be cached just as easily by the client as resources served over HTTP. Yes, I'm aware that some web browsers disregard far-future Expires dates and exclude from disk cache so as not to leak HTTPS resources to other applications that can access the same file system. On the other side of a connection, the server can and ideally does cache portions of dynamic pages that seldom change. For example, some of the modules on Phil's Hobby Shop are generated once every 20 minutes or so, and the site map is updated about once a day.

But neither of those is particularly applicable to downloads of a large (multiple megabytes), relatively static resource such as an APK file. The server's operator can choose to let a CDN close to the client cache large downloads so that the packets making up the download doesn't have to go through quite as many transit links. Or by "caching" are you referring specifically to a transparent proxy operated by the client's ISP?

and doesn't require processing overhead for the encryption

Are you referring to the client side of the connection or the server side? On the client slide, mobile devices have been able to decrypt in real time since at least the release of the original iPhone. If you're referring to a battery life hit, I imagine that a lot of users spend more megabytes browsing Facebook than downloading or updating applications, and Facebook already has to be encrypted in order not to leak the user's session cookie to users of Firesheep. And if your server's CPU can encrypt as fast as its network interface can shoot out packets, there's little noticeable overhead. TLS might be expensive when you're rapidly handshaking to create new connections, but there aren't quite as many new connections when bulk-encrypting APK file downloads sized in the multiple megabytes.

HTTP can be cached easily

Resources served over HTTPS, such as style sheets, scripts, and images, can be cached just as easily by the client as resources served over HTTP. Yes, I'm aware that some web browsers disregard far-future Expires dates and exclude from disk cache so as not to leak HTTPS resources to other applications that can access the same file system. On the other side of a connection, the server can and ideally does cache portions of dynamic pages that seldom change. For example, some of the modules on Phil's Hobby Shop are generated once every 20 minutes or so, and the site map is updated about once a day.

But neither of those is particularly applicable to downloads of a large (multiple megabytes), relatively static resource such as an APK file. The server's operator can choose to let a CDN close to the client cache large downloads so that the packets making up the download doesn't have to go through quite as many transit links. Or by "caching" are you referring specifically to a transparent proxy operated by the client's ISP?

and doesn't require processing overhead for the encryption

Are you referring to the client side of the connection or the server side? On the client slide, mobile devices have been able to decrypt in real time since at least the release of the original iPhone. If you're referring to a battery life hit, I imagine that a lot of users spend more megabytes browsing Facebook than downloading or updating applications, and Facebook already has to be encrypted in order not to leak the user's session cookie to users of Firesheep. And if your server's CPU can encrypt as fast as its network interface can shoot out packets, there's little noticeable overhead. TLS might be expensive when you're rapidly handshaking to create new connections, but there aren't quite as many new connections when bulk-encrypting APK file downloads sized in the multiple megabytes.

Most sites that are unusable without javascript could have easily been coded to be usable. Are drop down menus really so critical?

How do you recommend that users navigate to another subcategory of a web site without script and without multiple large page loads? For example, consider a product category tree that uses script to allow users to expand and collapse categories. I'm open to your suggestions about interaction models that do not involve 1. JavaScript or 2. resending 198 kB of unchanged text just to change 2 KiB.

WMDC is the slowest program in the history of mankind

I worked for a company developing warehouse software for a bunch of Symbol (now Motorola) barcode scanners running Windows CE. I worked around the dain bramage by running the application on a web server and presenting the user interface through the included Internet Explorer over Wi-Fi. Then I used the included ScanWedge app to turn scans into keypresses and form submissions, and it's still in use at Phil's Hobby Shop.

The log-in and sign-up pages on Phil's Hobby Shop have a "Show password as I type" checkbox. Is this what you were looking for?

Is the short paragraph on this login page good enough?

Why are these websites loading cookies the moment you go to a page, before you can even login or present them with data that is worthwhile to have in a cookie?

Take Phil's Hobby Shop for example. When you display a product's page, it adds the product to a list of recently viewed product pages, which is displayed at the left side of the product page. And to separate your list from other users' lists, it needs to store an anonymous session identifier in a cookie called philshobbyshop_sessionid. These anonymous sessions end after 16 hours and do not identify a user unless the user clicks "Log in" to convert the session to a logged-in session. All this is explained on the site's privacy policy.

Why are these websites loading cookies the moment you go to a page, before you can even login or present them with data that is worthwhile to have in a cookie?

Take Phil's Hobby Shop for example. When you display a product's page, it adds the product to a list of recently viewed product pages, which is displayed at the left side of the product page. And to separate your list from other users' lists, it needs to store an anonymous session identifier in a cookie called philshobbyshop_sessionid. These anonymous sessions end after 16 hours and do not identify a user unless the user clicks "Log in" to convert the session to a logged-in session. All this is explained on the site's privacy policy.

Does the Raspberry Pi ship with a gamepad or even a standard case? Perhaps the advantage of the Ouya is that it comes "ready to run": already in a case, with a gamepad, and with a download store installed. It's like the difference between an R/C plane kit and a ready-to-fly plane.

Does the Raspberry Pi ship with a gamepad or even a standard case? Perhaps the advantage of the Ouya is that it comes "ready to run": already in a case, with a gamepad, and with a download store installed. It's like the difference between an R/C plane kit and a ready-to-fly plane.

Where's the edit button when you need it?

It's called "preview".

The primary missile it's used to intercept are pretty primitive. Think along the same lines as the kind most readers here would have built out of cardboard from an Estes kit.

The primary missile it is made to intercept is made of metal.

So is it still pretty much a metal cased version of the products seen here?

Since you claim MOST of your apps are in idle states? Then, why on EARTH do you BOTHER with multiple core cpus then??

Because multicore CPUs have become cheap. A bargain-basement Atom laptop either has a 1 1/2 core hyperthreaded CPU or a true dual-core CPU. In either case, two cores (one for the interactive task, and one for background tasks) should be enough for the mass market until computer science figures out how to make multithreading of a single interactive task easy for programmers.

Oh, on what "floors me" here? Python & Delphi apps I wrote that WAIL on strings... it's expensive, & filebound on loads (init. loads & then TONS of stringwork)...

At work I have big batch processes written in Python that wail on flat-file data feeds with hundreds of thousands of rows. These run on a quad-core server several times a day. But I'd guess the average home or office user, the user targeted by the sort of mass-market products sold in Walmart and Best Buy, is what you call a "grandma does email only user".

I already have a job. Lunch costs me $2.16 including sales tax.

As opposed to the sign-up page at Phil's Hobby Shop, which pretty much advertises that it's 936-compliant.

What the fuck does it mean to be "compliant" with a comic strip? You just get more and more retarded with every post, don't you?

As opposed to the sign-up page at Phil's Hobby Shop, which pretty much advertises that it's 936-compliant.

How in the hell are they making pages four times that size?

I can think of a few causes:

• Some of it probably comes from JavaScript frameworks such as JQuery that abstract over the differences between IE and all the other browsers, which implement W3C DOM.
• Some tools that generate HTML auto-indent the HTML to make it easier for a human to read in Notepad instead of leaving out the indentation and letting the tree of elements speak for itself. This ends up putting a lot of extra space or tab characters into the mark-up, and a lot of web servers can't gzip it away because they don't gzip dynamic pages.
• Extra divs needed to work around the lack of rounded corners and the like in IE.
• Banner rotation scripts on the front pages of online stores such as Phil's Hobby Shop might rotate among three 40 KiB JPEGs.
• If scrollable elements within the page have images, the web browser might fetch all the images, even those not yet scrolled into view. Again, on Phil's Hobby Shop, scroll down to the list of paint-by-numbers near the bottom.
• New sites are more likely to use custom fonts in headings. These can be either Flash fonts for IE or TrueType fonts embedded with CSS @font-face for everything else.
• Though CSS can hide boxes on a mobile device, you're still sending all the HTML. It's possible to send lighter HTML to mobile user agents, but for one thing, a lot of Slashdot users are under the impression that user-agent detection is deprecated, and for another, there have been some legal problems with a user-agent database. Some sites just punt on this and push mobile users to their iOS or Android app.

For example, my whole comment could be enclosed in a author="devent" tag, a content="comment" tag and a topic="Firefox Too Big To Link On..." tag.

They're working on that, and it's called microformats. I'll grant that it's not there yet.

I think search for new content must be an integral part of the web.

It is an integral part of existing web sites. For example, Phil's Hobby Shop supports full-text search of every product's description. It's just that I can't see a way for web sites to federate on this, especially as web sites try to become more "sticky" and keep users from navigating away to view a competing site's ads.

I'm pretty sure the latter. There are plenty of ways to have fun without video gaming.