Stability

Chrome is fast and stable most of the time.  But as a web developer, I work with a lot of flaky websites with flaky markup and flaky JavaScript.  And in about a month of using Chrome as my primary browser, I’ve encountered a handful of cases where a tab would lock up for an inordinate amount of time, often requiring me to just kill it.

It’s very likely, almost guaranteed, that bad JavaScript was at fault.  It’s also possible that I just happened to find some Chrome weaknesses, and of course every browser has their own.  But at the end of the day I am looking for a browser I can use, not debug, and I’m going to use the one that performs most stably without hiding problems that need fixing.

Non-standard ports

Ugh.  This again.  Firefox seems to think that ports 80 and 443 are the only ports the Internet runs on, but at least they have the common decency to let me disable this.  Chrome doesn’t and this heavy-handed approach to security is just bad.  Bad bad bad.

I understand that most people will only need ports 80 and 443.  I understand that most people need security settled for them, and don’t want to know about it under the hood.  I understand that security almost always comes at the cost of convenience.  But at the end of the day, I want a web browser, not a ports 80 and 443 browser.

The only way to explicitly allow other ports is with command line switches!  For such a modern browser made by such a  modern company, I’m baffled as to why they would use such an archaic means of enabling a feature that – let’s face it – a lot of us are going to want.  We may be a minority, but we’re a big one.

Case-sensitive search

When I’m searching a page for a certain string, I usually want case sensitivity.  Again, as a programmer, I’m often interested in finding instances of “Do”, but not every instance of “do” as well.  The lack of case sensitivity makes the page search feature absolutely useless in many situations, leaving me instead with the only option of scouring through the page by hand looking for what I’m after.

If I understand any good reason why this feature was omitted, I might be more forgiving.  But I don’t see any reason for a technical limitation, and the thread in the issue tracker doesn’t shed much light, either.  The final note on it states that

URL / History / Search / LOOK HOW MANY THINGS FIT INSIDE THIS BAR Bar

I love the Firefox “Awesome Bar”.  It’s awesome.  I don’t love the Chrome URL bar.  It tries too hard to be everything and in my experience, usually fails.  Whereas Firefox’s URL bar gets me to pages I frequent with one or two keystrokes, with Chrome I usually find myself trying to work with it, eventually giving up, and just digging through my history or searching for what I was after the hard way.

If I have a local machine named “fudd” and I type “fudd” into Chrome’s URL bar, I get search results about “fudd”.  If I really want to visit “fudd”, I have to either include the “http://”, or create a wonky default search engine to trick it into constructing the URL I asked for.

Okay, okay, you can point out that an actual URL needs to include the “http://”, and this is a PEBKAC situation.  But the fact is that every web browser I’ve ever used implies the “http://” if one isn’t typed, and maybe I just fear change, but I kinda liked it that way.  It makes sense.  You could also point the finger at me for calling it the “URL bar” when it’s apparently called the “omni box”, but that’s where the URL goes so that is the URL bar.

I see the value in combining the URL bar with the search bar, but I see the value in not doing that, too.  Simply put, the previous link is a perfectly viable hack that I shouldn’t have to do to fake-disable a feature that I don’t want.  If the options let me control just how omni my omni box was, I would be satisfied, but they don’t without the aforementioned hack.

Until next time…

I gave it the old college try.  Chrome is an awesome browser and is definitely on my list to try again in several months when they’ve hopefully broadened their target audience a bit.  It’s fast, it’s as modern as it gets in terms of supporting new technologies, and its integrated developer toolbar has been great.  I really wanted this to be my new browser.

But it seems to me that either they’re making a browser for the common user — and only the common user — or they still have a bunch of refining to do.  As someone who does a lot of atypical but perfectly valid stuff with my browser, stuff that I imagine a lot of other programmers are doing as well, it doesn’t meet my needs.  It almost does.  I wish it did.  But alas…

One way to do this is by using PHP to generate a JavaScript variable mapping object ID to a set of data about the object, and then including the ID in the markup in some way, such as <div class="id-123">.... This works, but it complicates the implementation and is just not elegant.

The solution I found was to include a small snippet of JS at the top of every page that allowed me to add PHP data to the markup in such a way that it would be associated with specific elements. It looks like this:

<div class=”address”>
<div class=”jsdata” title=”address-id”><?php echo $id;?></div>
<span>123 Lollipop Lane, Mushroom Kingdom 84297</span>
</div>

In this case it’s just a numeric value, but it could just as easily contain a JSON-encoded object using json_encode. Supporting this is incredibly simple and gracefully degrades if support isn’t there. First, this needs to be included in the stylesheet:

.jsdata {display:none;}

This way nobody sees this data ever. Next, you include the JavaScript to do the work. My implementation is below, using jQuery, but it could be implemented without it without must more effort.

jQuery(function($) {
$(‘.jsdata’).each(function() {
var node = $(this).parent(),
raw = $(this).text(),
parsed = $.parseJSON(raw),
title = $(this).attr(‘title’) || ‘jsdata’;

node.data(title, parsed);
$(this).remove();
});
});

Anyhow, this is old news that I’m only posting about because it seems from here like they haven’t learned anything from the experience.

Plain text password fields.

During registration you are asked for a password.  Unlike on every other place on the web that I’ve ever visited in the history of ever, they use use text fields for this instead of the masked password field you’re used to seeing.

Risk: Anyone looking over your shoulder can see your password in plain text.

Solution: This one is mind-boggling easy.  Their text field just needs to be a password field.

Non-secure transmission of credentials.

When you register, log in, or update your profile, all of this is done over HTTP as opposed to HTTPS.  If you manually add the HTTPS you can access securely, and it looks like the form will submit securely as well.  Otherwise, you’re out of luck.  I want to give them a point or two for using proper password fields when changing your password, but it seems to vary from password field to password field.

Risk: Anyone who can snoop your network traffic can see your password every time you login, register, or change your password.  That’s probably a lot of people, unless you’re plugging right into POF’s web server, in which case unplug quick before your computer catches something.

Solution: They seem to have a working and current SSL certificate.  Maybe they forgot about it?  The solution is for them to require HTTPS for all authenticated traffic.  On top of preventing their users’ passwords from being common knowledge, it is also a necessary step in preventing various session-related attacks.

Plain-text transmission of passwords, probably storage too.

Did you forgot your POF password?  Let them know and they’ll generate a cryptographically token that they email you, requiring you to click it before emailing you a randomly generated password that you can use once to log in before changing your password.  No, I’m just kidding, they just email you your password in plain text.

Risk: Anyone who can snoop traffic between POF’s mail servers and your mail servers can see your password.  Further, since this is your password they send, and not a randomly generated one, users are not encouraged to change their password.  Thus, a user’s leaked password is likely to stay their password because they have no reason to change it.

In addition, if they have your password in plain text it likely means they’re storing it that way, or at least they have an automated way of acquiring it that way.  In either case, it means that if somebody breaks into their database (like they did a few months ago), they immediately have a list of usernames and passwords to have fun with.

Solution: Passwords should always be stored using a one-way hashing algorithm with a salt.  This way if someone steals 10M usernames and passwords, they have to spend a lot of time (depending on the strength of your users’ passwords) cracking each one.  Time that POF could use to notify users and engage in damage recovery.  This is so easy to accomplish that I’ll never understand why any professional website stores passwords in plain text.

As for emailing passwords in plain text, don’t.  Ideally they would use a random token emailed to your inbox to confirm intent, and then would use some other shared secret (“Security Questions”) to confirm that you are who you are, before prompting you to update your password.

Summary

For a website that claims on their website to “[work] hard to make sure our users’ accounts are safe and secure,” I’m skeptical where all that hard work is going.  I see security WTFisms around the web all the time, but this is the first time I’ve cared enough to write about it simply because of the level of inattention shown here combined with how popular the site is.  These are Security 101 rules that are being broken, and there’s no good reason for it.

In addition to that, there’s the fact that they were breached earlier this year.  According to Markus’ blog post:

Plentyoffish is bringing on several security companies to perform an external security audit, and will take all measures necessary to make sure our users are safe.

However I have to question either the capabilities of all of these security companies, or POF’s commitment to following through on recommendations that came out of these audits.  As someone who has conducted security audits for businesses and government institutions, I can say that the three holes I mentioned above would be reported on day one of the audit.

I recently read this article about PvP in Guild Wars 2, by John Peters, and it introduced a new level of excitement for me.  For as long as Guild Wars 2 has been on my radar, I’ve also been playing Team Fortress 2, and over time I’ve noticed TF2 becoming more and more role-playing-ish with the ability to collect and equip weapons that offer a direct in-game advantage.  And I’ve thought to myself, wouldn’t it be terrific to mesh traditional MMORPG-style gameplay with the quick-action style of a FPS like TF2.  And to my delight, as you can see, they’ve done exactly that.

One of the important similarities between TF2 and GW2 is that you continue to play on the server you choose until you decide to leave, and in that time teams can be shuffled around.  As opposed to a game like World of Warcraft, where the Alliance and Horde are always the opposing sides, in Guild Wars 2 you’re all part of the same overall community.  Forget gameplay for a minute; from a social standpoint this just breeds a better game.  Sure, there’s always trolls, but in general it’s been my experience that people are a lot nicer to each other when they know that the guy who just wtfpwned them might be on their team next round, or that their absolutely moronic teammate might be on the other team next round.

Personally I think it sounds great on paper, and based on my time playing TF2, I expect it to play out just as well.  I’m betting the player base will agree as well.  You can also note that many gameplay elements demo’d for Guild Wars 2 are starting to show up in bits and pieces in World of Warcraft as well.  Just sayin.

http://www.garfieldtech.com/blog/magic-benchmarks

At the same time, while it’s true to say it takes longer to use one method over another, it’s worth keeping in most cases the time spent over 2 million iterations was still around three seconds or less.  A three second cost would mean .0015 millisecond cost each, on average.  If it’s not something you’re likely to do thousands of times (call_user_func), you’re looking at a completely reasonable cost.  If you’re doing it more than that, you might want to consider refactoring your code to do it less.

One sentence version
Access resources by RESTful URL internally as well as on the front-end, and apply permissions layer there.

I like to hear myself talk
I am working on user-generated content publishing website. One of the important features is granular control over who does or does not have access to a resource. The application was already constructed to be RESTful, meaning each resource (content, author, category, etc…) had its own URL, like http://www.example.com/content/this-one-time-at-band-camp. Normally, a RESTful application means it provides a RESTful interface to visitors, but is not used internally.

What I came up with was a single function for fetching a resource, either internally or for an end-user. Thus a visitor would request “/content/foobar” by entering that into their browser. The application would load that story by requesting “/content/foobar” from the same function that would handle the end-user request as well. This function would see if a handler was registered for that URL pattern, fetch the object, and return it in some format: HTML for front-end requests, or the actual object for internal requests (incidentally, this also made it easy to return resources in other formats as well, like XML, JSON, CSV, plain-text, graphic, and so on).

I constructed a permissions layer at the at that function. Basically, when some library (ie. the “content” library) wants to claim URL space (“/content/*”), it registers a handler object capable of responding with the resource in the requested format. The handler also must define an authorization method that gets checked first, and must return true to allow the request. This way, publicly or internally, User A can’t access User B’s content if this isn’t explicitly allowed by the implementation. The default behavior is to deny it, which serves the purpose of being a very obvious problem that needs to be solved, removing the likelihood of negligence.

Now, I should point out that in my implementation, this is basically just a polite front-end to the data layer, but not a gate. If there’s some truly legitimate reason why I feel I need access to a resource for purely internal reasons and promise to be good with it, I can access the data layer directly to get it. I haven’t found a need to do this, however.

So I like to do my part and click on all political banners I see, and then close them almost immediately.  It gives me peace of mind knowing that they’re paying for a visit I don’t make, and probably off-setting their election predictions which makes me doubly happy.

Don’t give in to voter apathy.  Do your part and click all the political banners you see, and then close them right away before you catch something.

console.clear();

function test(x1, x2, x3, x4, x5) {
x1 = 0 || 1;
console.log(‘X1: %o’, x1); // 1

x1 = x1 || 2;
console.log(‘X1: %o’, x1); // 1

x2 = x2 || true ? 1 : 2;
console.log(‘X2: %o’, x2); // 1

x2 = x2 || ‘false’;
console.log(‘X2: %o’, x2); // 1

x2 = x3 || false ? 1 : 2;
console.log(‘X2: %o’, x2); // 2

//   null || 1  || 2  || null || null
x3 = x4   || x1 || x2 || x3   || x5;
console.log(‘X3: %o’, x3); // 1
}

test();

Background
For a brief background, I was working on a feature using a bunch of different classes. These classes could be manipulated by the end-user by changing around options, adding and removing items from lists, and so on. I thought it would be simple and convenient to just serialize these objects right into the database (I was working within a schema and was limited to using a single text blob, so one way or another I was going to be serializing data).

The problem
Originally, my classes used nothing but private members and accessors where needed. More recently, I wanted to change some of these private members to public, and when I did so my existing serialized objects broke! What I found was this:

When PHP attempts to unserialize() data containing private members into a class that contains public members of the same name, it produces an object that has both the private and public members of the same name.

So I ended up with an object who had two members, both with the same name, and $this->member was only returning the public member. The private member, which actually held information, was inaccessible. I looked for some magic __wakeup hackery to work around this but failed. Ultimately, since my code changes were now relying on public behavior, I used __get and __set to mimic it, along with a comment block explaining why I have all private members, and all exposed directly via __get and __set. Ugly, ugly stuff.

The lesson
Be careful what you do with serialized data, especially if you’re planning to keep it around for a while. You can modify the methods of your serialized class all you want, since methods are not serialized, but your data structure (the members) may become much trickier to update in the future.

I didn’t test this all fully, so I’m not sure what exactly is required to trigger this problem. For example, I know that replacing serialized public members with private members causes problems… what about the other direction? What about removing a public member from the class – would this cause the serialized public member to show up anyhow? I’m guessing it would.