“Closing the Gun Show Loophole”

“Closing the gun-show loophole” has become a cause célèbre of American progressives.

As a European liberal living in the US, people expect me to march in lock-step with American progressives, and are surprised that I think this is a crock of shit.

Above all else, I am an empiricist and a realist.

The supposed purpose of “closing the gun show loophole” is to reduce the number of firearms falling into the hands of violent criminals, so it is reasonable to ask “where do criminals get their guns?” The best evidence we have is a 2002 report by the Department of Justice's Bureau of Justice Statistics (BJS) based on two surveys of inmates in state and federal prisons.

The upshot of this BJS report is that (roughly speaking) 40% of felons got their guns from friends and family, 40% got them from street or other illegal sources, and 20% purchased them from a variety of legal sources including gun shows where 0.6% and 0.7% got their guns. We don't know how many of the inmates surveyed would, at the time they acquired their guns, have passed a background check.

So, the long and the short of it is that “closing the gun show loophole”, at best, has the potential to reduce the number of firearms falling into the hands of criminals by 0.7%. All of the other sources, the sources where 99.3% of criminals get their guns, are still open.

In other words, the evidence indicates that “closing the gun show loophole” is utterly pointless.

What Google Can Learn from Amazon

Google are getting into retailing cell-phone service with Project Fi.

If you think about it, this is the first time Google has really gotten into retailing to the general public. Up to now, all of their services have been free to the consumer and paid for by business.

But it seems that, in their hubris, Google have decided to “wing it” in retail, rather than learning from the practices of people who've perfected it. Their first lesson is that the rules are different for a mom & pop store and a megacorp. In particular, where a small operation can often get away with an apology when they mess up; a megacorp can't.

The small operation gets away with an apology when a person in a genuine position of responsibility explains the extenuating circumstances and apologises to the customer with a modicum of sincerity. Even a bodega will usually make some kind of tangible gesture — a freebie, a sample, a discount, or something — by way of apology.

Logistically, a multi-billion dollar corporation cannot apologise in the same way, or the Board would have no time for anything but apologies. Consumers are also cynical of large corporations, and understand that the only meaningful way for a large corporation to express appreciation or contrition is with something of monetary value.

So a scripted pseudo-personal apology from a powerless support drone in Nevada is hollow and disingenuous, equivalent in sincerity to silently mouthing “I'm sorry” while giving the middle finger and winking.

The trick for a corporation is to give the disgruntled customer something that they value more highly than its cost to the company. Amazon understand this very well. They will give you a $5 or $10 credit or a month's free extension to your Prime subscription at the drop of a hat. You can't spend it anywhere else, you have to remain a customer to use it, they're guaranteed to get it back, they only pay cost for what you buy with it, and you'll probably buy something that you otherwise wouldn't that's worth more than the credit. Ultimately, it probably only costs them $1 to give you $5.

Google may be the Titans of Online Searching & Advertising, but they can still learn a thing or two from the Titans of Online Retail.

Google Project Fi(asco)

If you haven't heard, Google is getting into cell service with Project Fi(asco).

If the technology works, the fee structure has the potential to put the cat amongst the pigeons of the cell service oligopoly. I love it!

Like many Google projects going all the way back to Gmail, there's an “invite” stage before it's rolled out everyone, so I applied for, and got, an invitation. Yay!

But if you're thinking of doing the same, I'd say “don't bother”, for a number of reasons:

• the sign-up process is misleading: your phone won't, in fact, leave the warehouse in the advertised 1-2 days, but in 5-6 weeks;
• it took filling out an online form followed by a 3-day farce of 11 emails to and from 4 different support personnel — Melissa, Dave the Would-Be Helper (marks for effort), Christina the Rude (or illiterate), and Tenisha — to arrive at the conclusion: cancelling the order;
• none of these people have the power to actually do anything unless you count writing chirpy corporate inanities and regurgitating FAQs;
• if my experience is representative, one in four won't even bother reading your email before “replying”; and
• at no time did they offer any kind of meaningful gesture of goodwill.

In short, Google is getting into the cell service business by misleading you about lead-times; then, if you call them on it, you get the middle-finger from impotent Comcast-grade support. Boo!

All 3 major cellphone service providers in the US are in the Customer Service Hall of Shame (positions 5, 7, & 8). Looks like Google wants to join them. What a pity.

Shortcomings of SFCU Online Banking

Like most people at Stanford, I bank with Stanford Federal Credit Union (SFCU).

Their lacklustre online banking system is fine for rudimentary day-to-day stuff, but it has a few dusty corners with some, frankly, ludicrous omissions and worryingly amateurish “features”.

Let's stick with tradition and talk about “Alice and Bob”, who are both SFCU customers.

I can think of three things off the top of my head...

Shortcoming #1

Suppose Alice and Bob have some shared monthly expense that happens to be paid out of Alice's checking account. Bob wants to set up a scheduled transfer of, say, $100 to Alice's checking account on the 1st of every month. It was easy for Bob to do one-time transfers to Alice, and it was easy for Bob to set up scheduled transfers between his own savings and checking accounts, so putting the two together is doable, right?

Wrong.

Ironically, Bob can set up scheduled transfers to any account at any other bank using the ABA routing code and account number, but the external application/service SFCU use rejects SFCU's own ABA routing number. After some back-and-forth with SFCU customer service, their solution — to Bob wanting to set up a scheduled monthly transfer to Alice's account at the same branch of the same bank — was to mail Alice a monthly check.

Just thinking about it makes me smile. Was I wrong when I said “ludicrous”? Maybe I should've said “hilarious”.

Shortcoming #2

Suppose Alice and Bob have a shared checking account. They want to open a second one. Bob clicks through to the screen for opening a new account, and there — much to his surprise and satisfaction — is a check-box that says “Share this account with Alice”. Strangely, Alice doesn't see this check-box when she tries, but Bob ticks the box and moves on.

Easy-peasy, right?

Wrong.

The “feature” simply doesn't work. After some back-and-forth with customer support, they tell Alice that she and Bob will just have to come in and fill out a paper form.

Here's how it should work:

• The New Account page has a shared account option (via a tab, separate page, or whatever, the HCI/UI/UX details are unimportant to the current argument) with, inter alia, a text-box to enter the other customer's customer number
• Alice fills in Bob's customer number and clicks OK.
• Bob gets an email, clicks on a link, logs in, and it takes him to a page that says “Alice wants to open a shared checking account with you.”; it has 2 buttons “Accept” and “Decline”.
• If Bob accepts, the account is opened.
• If Bob declines, it isn't and Alice gets a message to that effect

They clearly thought of giving customers the ability to open joint accounts via the online banking system, otherwise the check-box wouldn't exist, so why didn't they actually implement it? And if they subsequently decided that they weren't going to implement it, why is the check-box still there?

Either support the feature or don't. It's not hard.

Shortcoming #3

The final shortcoming is simultaneously the most trivial and the most concerning. The previous two are oversights. Irritating, perhaps, but really just oversights or missing features.

The online banking system has an integrated messaging system for customer support. It also has a timer that logs you out automatically after a period of time. I'm sure you can guess… Yes, it can try to log you out while you're typing. Apparently resetting the JavaScript timer that's already there on every keystroke was too much.

But that doesn't really concern me. Again, it's just an oversight, and because you are prompted before being automatically logged out, it's not a critical issue.

What gives me cause for concern is that the messaging system only allows alphanumeric characters plus a list of “allowed special characters”.

What this suggests is that the developers, quite rightly, feared:

• a SQL injection attack; and/or
• HTML special characters — like “<”, “>”, and “&” — being entered by the client, and later interpreted by the customer service agent's browser, such that the message entered by the client was not faithfully presented to the customer service agent.

These are legitimate fears and it is right that the developers should take measures to defend against them. What's worrying is that the only way they could see of defending against them was to have an allowed list of characters, which suggests that the developers were either lazy and sloppy or just plain incompetent, and nobody at SFCU knew enough to reject this amateurish hack.

If there's one thing I don't want to suspect was developed by dilettantes and acceptance tested by ignoramuses, it's the online banking system I use.

Using a C++ Flex Lexer with a C++ Bison Parser

I recently found myself revisiting lexing and parsing as part of my research. It's one of those cases where I would get away with ad-hoc parsing with line-splitting and regular expression matching, but the canonical alternative might ultimately turn out to be worth some extra effort for a number of reasons.

Many years ago, I wrote a SQL DDL parser as part of some object-relational mapping research into a “mutual containment” object model for transparently representing junction tables in relational databases. Even if I do say so myself, it was a neat idea. I don't know if anyone else has since thought of it independently and implemented it.

So, I decided to revisit flex and bison, the most popular versions of the venerable and classic compiler construction tools, lex and yacc. This time around, though, I anticipated a possible need for two parser/lexer subsystems, so I was interested in the C++ capabilities of both tools, since the “vanilla” C code they emit uses global variables.

The GNU Bison Manual has A Complete C++ Example that, unfortunately, rather narrowly interprets what it means to be “complete C++ example” to mean “an example where the bison bits are in C++”, and uses the vanilla flex lexer with global variables.

I found a few examples of using flex and bison with C++, but even the best of them only address one or the other, go off on irrelevant tangents, are short on explanation, contain outright misleading comments, use deprecated constructs, or all of the above.

All I wanted, was the minimal example of how to use a C++ flex lexer with a C++ bison parser. Some kind of “addendum” to the “complete” C++ example from the bison manual would be perfect!

*Crickets*.

So now, ladies and gentlemen, for your enjoyment, I have added to my Bitbucket “miscellany”, such an elucidation of Modifying the Bison “Complete C++ Example” to Use a C++ Flex Lexer as I formerly desired.

It's not as easy as it sounds.