There are a lot of really great ways to communicate securely over the ‘Net. The trouble is, they’re virtually all user-unfriendly.

Today I’d like to start a discussion on making browsing safer and friendlier for everyone. I call it the “Safer Browser” initiative. I’ll discuss a feature virtually all browsers currently implement, why it makes browsing safer, how browser vendors can make it friendlier to use, and how application developers could help us all out.

Part one: what browsers currently offer.

Nearly every web browser allows a user to connect a TLS certificate with their own profile. These client certificates can sign the requests being made from a user’s browser. This is a feature that I believe only enterprises may actually employ. It’s nontrivial to set up on a regular person’s computer. Large prime numbers get involved. Thus, few civilians really use client certificates. Since no customers present client certificates, site owners pretty much ignore them too. Hence, the chicken-and-egg problem is that few sites care to accept client certificates, so why should browsers bother to use them too?

Part two: how browsers need to change.

I propose that new installations of web browsers automatically generate a certificate for the customer as part of the installation process. Now that the world is essentially using multi-user computers, associating a user’s profile with their own TLS certificate can be more safely done than 10 years ago. If FireFox, IE, Chrome, Safari, and Opera begin generating client certificates for the purpose of identifying the current user, using the web will become much safer.

In order for the public to begin benefitting from stronger encryption, browsers must begin creating (and using) client certificates on behalf of the customer. By creating a certificate on behalf of the customer, a tipping point can be achieved. If we remain as we are now, with customers having to generate their own, or Heaven forfend, having to pay a fee every year to renew their identity with Verisign, things will never really change in the defaults of browsing safely.

So, browsers must start out creating a certificate for end users. Since the end user isn’t really a part of the transaction (other than maybe providing a password for the keychain), it may be a good idea to separate the generated certificate into a separate store from what is currently available.

Part three: how sites can make use of this.

Now that we’ve got browser vendors providing certificates for their users, let me describe how I see sites taking advantage of this.

Imagine a banking website. Whenever a user is prompted to log in, a check can be easily made to verify that a user has provided a client certificate. The log in procedure could then add some extra fields to the log in form to connect the certificate with the log in credentials the user is now providing. This would allow the user to bypass the next login if they’re using their own trusted browser.

Taking this further, a smart, security-conscious banking site could offer to deny any logins from browsers that are not offering the same certificate that the user is currently providing. This would immediately lock out bad guys (e.g. crackers) and good guys (e.g. Mint) alike. The upside is that we’ve now established a very strong bond of trust between the browser the customer is now using and the bank. I would recommend that sites offer the ability to connect multiple certificates to a customer’s account, and to develop handshaking procedures that require a previously-connected browser in the chain to vouch for a new addition. The result is that the username and password are less valuable in the event of a theft. If my credentials are stolen, I still get a bit of say-so in allowing some other browser to log in with them!

Summary

So, browsers now generate certificates inside a user’s profile, and try to send them to sites using HTTPS by default. Sites now can associate such certificates with a login to more strongly identify that particular user.

Now that this is happening, sites can reduce the amount of effort involved in requiring “security questions” that are easily spoofed via machines in the middle of the connection. In addition, passwords become a secondary token of identification, and sites that have them stolen are not as easily utilized.

I think the benefits to both customers and site owners are obvious (although the site owner does need to do some work on their part). Browser authors are also benefitted by locking-in the customer to using only their browser as part of their online experience (which some power-users like myself would probably cringe at), which should make the organizations that create those browsers happy too. I think this plan is feasible, so let’s go out and make browsing safer.

Here are my thoughts as I had (time to type) them.

• Does the public care how fast a computer boots up? There’s got to be an acceptable tolerance that has already been met by the Google Chrome OS efforts.
• The presenter has a Jeff Goldblum vibe going on.
• The demo was from code checked into trunk? Wonder if the demo will fall on its face at some point …
• I hope the UI changes for “application tabs”; favorite icons aren’t the best way to identify different properties. A plus will be that it becomes more useful for an app developer (I’m looking your way, Atlassian) to use separate favicons for its products.
• The favicons do have the benefit of being i18n-friendly.
• Panels remind me of the old Google Notebook Firefox add-on. I wonder if Gmail will use panels for its chat window.
• Note to self: games do not necessarily mean 3D.
• Multiple windows feels a lot like virtual desktops.
• I hope Google posts their use cases along with their source code. I doubt it will happen, but one can hope.
• Google has got to be working hard to keep Microsoft Office online from breaking in Chrome.
• The video sure ends abruptly.

I think Google has a hard sell in front of them; I’d love to know who Chrome OS is for. I know I would love a fast, little netbook that is really good at the few things it should do, but we have a 25 year history of PCs that continue to reinforce comparisons between things that have keyboards, pointing devices, and monitors. Perhaps Google doesn’t want many folks actually using Chrome OS but want to leverage it as an experiment to create more markets for web applications. Maybe they were really inspired by the One-Laptop-Per-Child project and want a cheap, useful PC to be able to be disseminated.

This is very cool; I’m all for finding innovative ways to help people regain their independence. Good job Honda.

• operations such as “send an email,” “buy some stock,” or “donate money to a politician” exist on the web
• usually complex sites and web applications use frameworks that maps these sorts of operations to HTML forms and/or HTML links
• these frameworks do not differentiate between “safe” and “unsafe” operations (where “safe” means you can perform this operation 1 or more times without worry of side-effects)
• web browsers automatically fetch inline images regardless of the server they’re sent from
• a bad guy can combine the two points above into a single page that automatically attempts to perform unsafe operations

Once you consider the implications of this, it’s a very, very scary thought that some random MySpace page can potentially steal money from you.  With the rise of great sites such as Reddit, Yahoo! Buzz and Digg pointing people to intriguing headlines and interesting pages hundreds of times a day things become very scary.

Here’s what you (as a customer) need to know and need to practice.

Always Log Out from any site you have financial information connected to.  This one step can significantly change the game with regards to CSRF attacks.  CSRF attacks mainly require one to be logged in to a system to work.

The second big tip provides much more safety, but is a much less friendly way to surf the web: use Firefox and download the NoScript extension.  NoScript essentially gives you per-domain (e.g. “google.com”, “josh-peters.name”) permissions for executing scripts.  In addition, NoScript does a great job of keeping up-to-date with the techniques of the bad guys and can block potential attempts to many targets of CSRF.

Finally, disable images in HTML mail.  This prevents your email reader from behaving like a browser (i.e. automatically download images for you).  Most email clients will allow you to enable images selectively, so your mom’s email with HTML stationery won’t break.  However, be warned that if you do enable per-sender HTML mail you put yourself at risk of the sender’s security and virus protection.

Surf safely!

Here’s the video from siggraph:

Way neat! This just sold me on an (eventual) upgrade to Photoshop CS4 (from CS1).

I think this is just an excuse to take a helicopter to work every morning.

A technique I commonly use is to overload CSS classes and transform the elements via client-side Javascript. For example, if I have a control with a class of “required” I can, via Javascript, enforce requirements on the control. I would love it if I could also set the “aria-required” attribute in the same manner and have it work in screen readers.

Can anyone give me an idea of whether or not this works?

Actually, now that I think about it, I’d really like to see something like this done to the script of a whole host of movies. Just how pretty can we render the f-word? How connected is the word “what” in Pulp Fiction?

see here for details