In the recent kerfuffle over the prevalence of the
-webkit CSS prefix and the lack of corresponding prefixes for other browsers, we told you that the problem was with developers, not WebKit browsers. Instead of writing code that will work in any browser many developers are coding exclusively for WebKit and that’s a problem.
But mobile expert Peter-Paul Koch, better known in the web developer community as just PPK, argues that the real problem is not WebKit, nor is it even web developers’ fascination with WebKit. The real problem is the developer-created monoculture of the iPhone.
According to Koch, “web developers don’t care about WebKit…. They care about the iPhone.”
The interesting thing about Koch’s argument is that he doesn’t claim there is actually a monoculture of the iPhone on the web. In fact, he cites some of Mozilla’s web crawler stats which seem to say just the opposite. Instead Koch believes the problem is in our heads, so to speak.
“What we have here is an iPhone monoculture; not in the stats, but in web developers’ minds,” writes Koch. “This is the fundamental problem we must address.”
The cure, says Koch, is to diversify tutorials and examples. “Start talking about testing in mobile non-WebKit browsers (i.e., Opera),” he writes. “Start talking about other platforms besides iPhone (and Android). Start talking about mobile diversity, instead of showing the iPhone over and over and over again.” What do you do if the only phone you have to test on is the iPhone? Well, there are emulators available for most phones, including Opera’s very powerful mobile emulator which can simulate all kinds of phones and connections. And don’t forget that Opera Mini is available for the iPhone if you’d like to at least test your site in something other than Mobile Safari.
Google’s Chrome development team is working on a system to automatically generate passwords, which would help users secure their online identities with passwords that would be diversified across different sites, and are randomized and thus harder to guess. Detailed in developer documentation on the Chromium Project site, the system would detect account sign-up pages and “add a small UI element to the password field” giving the user the option of letting Chrome manage the password for them.
Initial versions of the system would create passwords on an individual basis, at the user’s request. But Google’s development team states that “At some point in the future it might also be possible for us to automatically change all of a user’s passwords when we realize that their account is hijacked.” The developer documentation notes that the feature would make Google “a higher value hijacking target,” than it already is, although “Google is already a high value target so this shouldn’t change much.”
Chrome can already store passwords, a common feature in modern browsers, and it syncs them across computers, with the passwords encrypted in transit and at rest in Google data centers. The idea of auto-generating passwords is not new, either. Password management software such as 1Password and LastPass can already generate passwords and automatically input them into web forms. But these tools cost money and require additional software downloads. Although it’s not clear when it will become available, Google’s scheme would make storing and generating passwords a pre-installed feature of the browser.
The first challenge noted by the Chrome development team is detecting sign-up pages, which is accomplished by looking for elements such as “an account name field and two password fields.” Next, the Chrome password generator must come up with a secure password that meets the site’s requirements—many sites require digits, special characters or certain lengths. Because the password generator may choose a password that doesn’t meet the site’s requirements, the user is given a chance to review the suggested password before selecting it.
“If they accept the prompt then we pop up a small box which is prepopulated with what we think is an acceptable random password,” the Chromium development document says. “The reason we don’t just choose a password for them is that many sites have requirements (e.g. must have one digit, must be alphanumeric, must be between 6 and 20 characters) some of which may be contradictory between sites. So we will choose a default generator that will work on most sites, but users may need to change our password if it doesn’t work.”
The Chromium team is still looking for a “way to authenticate to the browser to enable this feature,” and will have to find a workaround for sites that have autocomplete turned off.
“Any website that has autocomplete turned off will not be able to be protected,” the document states. “Going by current phishing attacks, this means that 40-70% of phishing pages can’t be protected against. Once this feature is rolled out we probably want to see if we can get around this problem. Maybe we can get users to re-authenticate to the browser before logging into such sites.”
How much do you trust Google?
Google is often criticized for invading users’ privacy, as the company makes much of its revenue by serving up personalized ads to users based on their web browsing habits and even the contents of their e-mail. However, the development of technology to generate more secure passwords seems like a good-faith effort to protect users from online attacks, and isn’t so far removed from the already-existing practice of browsers storing passwords.
Google’s password-generator will likely be appealing to many because of the sheer convenience of it. But users will have to decide for themselves just how much of their online activities they want to trust with Google.
In the long run, Chrome developers say the solution should be browser sign-in coupled with the OpenID authentication standard. However, “getting most sites on the Internet to use OpenID will take a while,” the Chrome team states. “In the meantime it would be nice to have a way to achieve the same affect of having the browser control authentication.” Since many people re-use passwords across sites, randomization will go a long way toward better security, making it harder for attackers to steal a user’s entire online identity.
This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.