If I were the philosopher-king of the world


  • All measurements would be metric, even in America. This would include recipes. (“T” is different from “t”? Why?)
  • The 12-hour clock would be abolished in favour of a 24-hour clock.
  • Time zones would be abolished. Every clock would be set to GMT, Beijing time, I don’t care, just make it consistent.
  • Dates would be written in compliance with ISO 8601.
  • Daylight savings time would be abolished.
  • The calendar would be reformed to something that makes sense.
  • Academic references and style guidelines would be standardised across all disciplines and publications once and for all. Academic citations would be hyperlinked in all electronic versions.
  • Usernames and passwords would be gone forever.
  • AAA batteries would be illegal
  • DRM would be illegal, and for that matter, copyright / patent law would be a very different thing.
    • Maybe copyright on a creative work would last 28 years only, with no extensions? (Ahem, Disney.)
  • There would be a universal maximum wage, indexed to a universal minimum wage, and a guaranteed basic income.
  • The laws regarding royal succession for Canada would be changed such that the queen of Canada is chosen by random lottery among Canadian citizens.

I have opinions.


    title = {If I were the philosopher-king of the world},
    journaltitle = {The Grey Literature},
    author = {Benjamin Gregory Carlisle},
    address = {Montreal, Canada},
    date = 2014-01-31,
    url = {https://www.bgcarlisle.com/blog/2014/01/31/if-i-were-the-philosopher-king-of-the-world/}


Carlisle, Benjamin Gregory. "If I were the philosopher-king of the world" Web blog post. The Grey Literature. 31 Jan 2014. Web. 21 Feb 2019. <https://www.bgcarlisle.com/blog/2014/01/31/if-i-were-the-philosopher-king-of-the-world/>


Carlisle, Benjamin Gregory. (2014, Jan 31). If I were the philosopher-king of the world [Web log post]. Retrieved from https://www.bgcarlisle.com/blog/2014/01/31/if-i-were-the-philosopher-king-of-the-world/

“Toward a bitcoin authenticator” or “getting rid of usernames and passwords, redux”


I make it no secret that I hate passwords. I hate them so much. I have even previously written on the subject, suggesting an algorithmic way of generating login credentials would be preferable.

Turns out, this method is already being used in some places, kinda

There already exists a fairly widely accepted manner of confirming identity that’s pseudonymous and persistent, and already installed on a fairly large number of computers—namely, bitcoin. If you download a bitcoin wallet or make a web wallet, you can generate as many bitcoin addresses as you like. It doesn’t cost anything, and no one else will have the same address as you.

Much ink has been spilled over the potential of bitcoin as an alternative currency, but a little-remarked-upon feature of bitcoin addresses is that you can use them to cryptographically sign a message, which other people can use to verify that the address in question is indeed yours. If you want to try it out, in Bitcoin-Qt, click File > Verify message … and you will see a window for signing and verifying messages. You can enter whatever text you like, and sign it with your bitcoin address.

So if Alice wanted Bob to prove that he owned a particular bitcoin address, Alice could choose a random string of letters and numbers and tell Bob to sign it with his address. Bob could send back the signature, which Alice could use to confirm that the message was signed by the address in question. This is pretty nifty, but it’s not super-useful, unless you’re very interested in confirming that someone has the means to pay for something in bitcoin.

That’s until you realise that …

This whole process could be automated and used as a web service’s login credentials

So imagine you were running some sort of web-based service where you wanted to have users log in. Right now, the normal way to log in is by having users provide choose a username and password. The weakness of this process is of course, the password, although the use of email addresses to restore forgotten passwords is also pretty insecure.

As far as passwords go, there are weaknesses on the user side, the transmission of the credentials, and the storage of credentials on the server side. Altogether, there are lots of ways that passwords can be stolen. There is no need to go into detail about how passwords are bad here.

An alternative might be to use a bitcoin address as your username. This would eliminate the need to choose a password at all.

Similarly to the case of Alice and Bob above, if Bob was going to log into Alice’s website, Bob would indicate that his identity is his bitcoin address, 1HYDtPQueJRa8tdxXqkKa8peZEJN1iKi57, and then Alice’s website could automatically generate text like the following:

[Log in 1HYDtPQueJRa8tdxXqkKa8peZEJN1iKi57 to www.alicewebsite.com valid until 2014-01-29 20:00 +0:00 GMT]

Bob could sign that message with his bitcoin address, giving him the following signature:


You can check yourself that the message was properly signed with the given address using most bitcoin wallet software and on a number of web-based apps as well. Alice’s website could check that Bob’s signature was correct, and allow him to log in with the bitcoin address as his identity. Alice’s website could be programmed to recognise that signed message only once and only for only a few minutes.

In fact, this authentication process is already in use by some bitcoin mining pools. Eligius, for example, has no user names other than the bitcoin address used to send payouts for mining. Whenever a miner wants to make changes to her account, the service generates a code to be signed, and when it is properly signed, the changes are accepted. This means that there is no password list on the Eligius server to steal, and none to remember for its miners. It’s pretty clever, really.

There are a lot of good reasons why even non-bitcoin-related web services might want to adopt this method of authentication

The system is pretty simple. You just have to remember which address you used as your account.

The upside to using bitcoin addresses for login credentials are many. There are no passwords to be stolen / forgotten / recycled by users, and no list of passwords on the server. A system like this also protects one against the case in which Alice, the person running the web service is maliciously collecting user passwords.

Not only that, but a lot of people already have a bitcoin wallet. The algorithm for signing messages is standard, and the software is free and open-source.

There are some downsides to a bitcoin authenticator too

The first thing that people notice about bitcoin addresses is that they’re long and seemingly random strings of letters and numbers, which can be off-putting. We’re used to human-readable usernames, so that we can log in to our accounts on strange computers, with passwords that we also remember.

There isn’t really a way around this. This system is designed to prevent login credentials from being simple enough to be remembered by a human. That said, there’s nothing preventing a web service from allowing you to have a “handle” or a “real name” associated with your bitcoin address that could be human readable.

As far as logging in on multiple devices go, this might present a bit of a challenge, since a bitcoin address’ private keys are usually only kept on one device—the wallet on your computer, or in an app on your phone. A well designed web service could allow for a user to associate multiple bitcoin addresses together, so that she could log in to the same account on different devices that have different bitcoin addresses on them.

If you lose the private keys for your bitcoin address, there’s nothing anyone can ever do to recover them. You can see this as a bug or a feature. If you want to close an account on a web service forever, just trash the private keys for that bitcoin address, and no one can ever open it again. But if you have a hard drive crash, and you didn’t think to make a backup, or if you lose all your backups simultaneously, then there’s nothing that can be done for you.

Private keys, like anything digital, can be stolen—either by a person with a USB drive who’s physically at your computer, or by malware. Then again, this is also true of your encrypted password lists, and I think it would make the situation no worse than what we currently have with the username/password paradigm.

What’s next

MediaWiki is free and open source software. It is most famously used as the software that Wikipedia runs on. Because it is free software, anyone can take the source code and make a fork of the project, in which she adds her own new features. Same thing goes for WordPress. There’s part of me that’s very strongly tempted to fork both of these projects such that they allow bitcoin addresses for authentication, and then lobby to have it merged back into the main project.

But then the holdup for projects like these is always one of acceptance, rather than just the technical re-programming of the software. Anyone have contacts at MediaWiki or WordPress or other free/open-source projects, who would be open to this kind of suggestion?

Table 1: Levels of security for bitcoin wallets and analogues in user authentication

Bitcoins Passwords
Cloud Web-wallets
“Like letting a stranger hold a wad of cash for you”
E.g. Blockchain.info
Cloud-based password managers
“A million times better than what most people do”
e.g. LastPass
Local Locally stored bitcoin wallet
“At least it’s not a web wallet”
E.g. Bitcoin-qt, with encryption not enabled
List of passwords on local computer only
“At least you’re not using the same password for everything”
E.g. Excel spreadsheet on desktop
Local, encrypted Locally stored and encrypted bitcoin wallet
“Not the worst, but don’t keep your life savings there”
E.g. Pretty much any wallet has encryption by default
Locally stored and encrypted password list
“This is what most users would aspire to”
E.g. Keychain Access on the Mac
Offline Paper wallet or private keys on offline computer only
“The gold standard for bitcoin wallet security”
E.g. Bitcoin Armory paper wallet

(Edit 2014 Jan 29: Added Table 1 to aid in responding to Morty’s comment below.)


    title = {“Toward a bitcoin authenticator” or “getting rid of usernames and passwords, redux”},
    journaltitle = {The Grey Literature},
    author = {Benjamin Gregory Carlisle},
    address = {Montreal, Canada},
    date = 2014-01-29,
    url = {https://www.bgcarlisle.com/blog/2014/01/29/toward-a-bitcoin-authenticator-or-getting-rid-of-usernames-and-passwords-redux/}


Carlisle, Benjamin Gregory. "“Toward a bitcoin authenticator” or “getting rid of usernames and passwords, redux”" Web blog post. The Grey Literature. 29 Jan 2014. Web. 21 Feb 2019. <https://www.bgcarlisle.com/blog/2014/01/29/toward-a-bitcoin-authenticator-or-getting-rid-of-usernames-and-passwords-redux/>


Carlisle, Benjamin Gregory. (2014, Jan 29). “Toward a bitcoin authenticator” or “getting rid of usernames and passwords, redux” [Web log post]. Retrieved from https://www.bgcarlisle.com/blog/2014/01/29/toward-a-bitcoin-authenticator-or-getting-rid-of-usernames-and-passwords-redux/

Getting rid of the username / password paradigm forever


The username / password paradigm for user authentication is ubiquitous, but rife with problems. Even with the use of a password manager, they are awkward and insecure. They are easily lost or forgotten, they are used in many locations for multiple accounts, and they are not changed as often as they should. Even people who are aware of best practices for passwords often do not follow them. Using a username / password authentication system is just a way of asking users to engage in behaviours that put themselves at risk. I propose a protocol whereby passwords are replaced by a piece of software or hardware that authenticates a user’s log-in, without the need for passwords at all.


Instead of allowing the user to choose a password at sign-up, the service in question and the user should both agree on a cryptographic hashing function, a number identifying what service and account name are being authenticated, a randomly-chosen salt (string of characters prefixed to something before passing through a hashing function) and a web address to post credentials to, on log-in.

A desktop / smartphone app for generating valid credentials

The identifier, the hashing function, the salt and the address to which credentials are to be posted would be saved to an encrypted file managed by a specially-designed application on a smartphone, desktop computer or on specialised hardware. This app or hardware would need to be able to read QR codes, save and recall data from a small database, perform the hashing function to generate valid credentials, and then post them to the provided web addresses.


When a user wants to log in to a service, she types her user name and the service in return shows a link or a button to click after authenticating and a QR code (also displayed as text that can be copied to the phone or computer clipboard). This QR code contains the identifier indicating which service is being authenticated and a randomly-generated string of letters and numbers. We will call this the “challenge string.” On the server-side, the challenge string will be tagged with the timestamp when it is provided to the user, and credentials generated with it will be valid for five minutes only, and will only be valid once.

When the user scans the QR code with her smartphone or other hardware, it reads the indicator for the service it is authenticating, as well as the challenge string. The user can also copy / paste the text into an app, in the case that she’s signing on to a site using her phone or is using the desktop version of the app. It would also be possible to write a plug-in for Firefox or Chrome, for example, that allows the user to right-click the QR code or the text equivalent and it brings up a “generate and submit credentials” button.

The app would then prefix the salt provided at sign-up to the challenge string, then pass it through the agreed-upon hash and submit that to the address that the service provided in the first place. On the server-side, the service would also take the challenge string and perform the same function, for comparison.

This tells the service that an authorised user is attempting to log in with the generated code. If it is the case that the credentials submitted to the web service are the same as the credentials that are expected, given the salt and hashing function, and if they are submitted before the challenge string expires, then the link or button that was provided along with the QR code is activated—on clicking it, the site logs the user in to the service in question.

The user does not need to remember anything but her user name, and does not type a password at any point.


Wifi interception

If you’re on a strange wifi or something, someone could intercept the challenge string, wait a few minutes, and try claiming that it was her who authenticated it.

Possible solution: Invalidate a challenge string if a user claims to have authenticated it when she hasn’t yet. Allow only one log-in attempt per challenge string. Close a previously authenticated session if a user attempts another log-in.

Note that this is no worse than the username / password paradigm. If a malicious user was sophisticated enough to use this to hijack an authentication, she could certainly also record a username and password sent over her wifi, which would not only allow her to log in once, but any number of times, until the password is changed.

What if someone finds out your hashing function and salt?

The weakest link in the chain here is of course the secrecy of the hashing function and salt. These could be compromised if someone gains access to your phone or in the case of malware. This is no worse than using a password manager. (And certainly more secure than using a cloud-based password manager.)

Possible solution: Build an expiry date in to each password. Keep the list of credential-generating functions and salts and their associated accounts encrypted.

What if my phone dies?

Then you’ve lost all your passwords. You’ll have to restore your phone from a backup, or there would have to be an “I forgot my password” button.

Possible solution: A function that generates hashing functions / salts based on a root string of random letters and numbers and the web address of the account being authenticated. In this case, the root string of random letters and numbers could be printed on a piece of paper, to be kept somewhere secure, and used to generate all the salts and hashes, in the case of a destroyed phone.


  • No one has to remember any passwords.
  • No recycling of passwords.
  • Instead of a single password for a service, the software generates a new password for every session according to (incomplete) instructions that are randomly generated at the time of log-in.

What it would take for this to work

For this to work, someone would need to write these smartphone / desktop apps to process the code and submit credentials. The smartphone / desktop app that generates the credentials would need to be open-source. I know I would want to know that the developer isn’t building himself a back-door into other people’s accounts.

Then, a standard library of functions and examples of how to use this system would need to be published. It would have to be an open standard, and it would have to be dead-simple to integrate into other software.

What I like about this idea is that it’s all within the realm of possibility. I personally have the ability to write all of this (although it would be nice to have some help).

Finally, adoption of this protocol on a large scale would need to take place, which I suppose is the tricky part. Once the protocol is formalised and some software libraries are written, I suppose a good place to start would be looking for other open-source projects (like WordPress) and either forking them so that they include this, talking to the development team or writing a plug-in or something so that they have the option of using this alternate authentication protocol.

Has someone already done something like this? Could it be made to work?

Maybe someone else has already invented this, and it just never caught on. Does anyone know if someone has attempted to replace the username / password like this before?

Can you see any glaring holes in this system that I’ve overlooked? I admit, I have little formal CS training, and it is entirely possible that I have missed something important.

Does anyone want to collaborate on this? I would seriously be interested in getting rid of passwords forever, but I don’t think I can do it alone. We can put it in the Creative Commons or whatever.

I just don’t want to have to use passwords anymore.


    title = {Getting rid of the username / password paradigm forever},
    journaltitle = {The Grey Literature},
    author = {Benjamin Gregory Carlisle},
    address = {Montreal, Canada},
    date = 2013-08-6,
    url = {https://www.bgcarlisle.com/blog/2013/08/06/getting-rid-of-the-username-password-paradigm-forever/}


Carlisle, Benjamin Gregory. "Getting rid of the username / password paradigm forever" Web blog post. The Grey Literature. 06 Aug 2013. Web. 21 Feb 2019. <https://www.bgcarlisle.com/blog/2013/08/06/getting-rid-of-the-username-password-paradigm-forever/>


Carlisle, Benjamin Gregory. (2013, Aug 06). Getting rid of the username / password paradigm forever [Web log post]. Retrieved from https://www.bgcarlisle.com/blog/2013/08/06/getting-rid-of-the-username-password-paradigm-forever/

How to play “Dave’s Famous Telephone Charades”


Dave’s Famous Telephone Charades is a party game that requires a minimum of 4 “participants,” as well as a certain critical mass of reasonably creative “audience members,” probably no less than 4. It was a perennial favourite of my circle of friends when I was an undergrad at Western.

Here’s how it works:

  1. Players 1–4 go to a separate room where they can’t see or hear the audience members talking.
  2. The audience members choose a scene to be acted out silently by the players.
    • The instructions for the scene to be acted out should be simple—aim for 1 sentence.
    • The scene should lend itself easily to physical movement and interpretation.
    • The scene must be something that can be acted out silently.
    • Examples include: “washing the dishes,” “an otter in its natural habitat,” “a day in the life of a …”
  3. Player 1 comes back to the room with the audience, where he is told the scene to be acted out. He is given 10 seconds to think about what exactly he will do.
  4. Player 2 comes into the room and watches player 1 silently act out the scene given to him. The scene should be about 30 seconds long, tops. To be clear: no one tells players 2–4 what the scene is until after the game is finished.
  5. Player 3 enters and player 2 acts out the scene from memory, not knowing the instructions that were given to player 1.
  6. Player 4 enters and player 3 acts out the scene from memory.
  7. Player 4 acts out the scene as best he can from memory, narrating what it is she thinks she is acting out.
  8. Player 3 corrects player 4.
  9. Player 2 corrects player 3.
  10. Player 1 reveals the instructions she was given in the first place.

This sort of game only works with certain kinds of people in the right sort of mood, but when you have the right combination of people with the right sort of energy all together in the same place, it can be hilarious.


    title = {How to play “Dave’s Famous Telephone Charades”},
    journaltitle = {The Grey Literature},
    author = {Benjamin Gregory Carlisle},
    address = {Montreal, Canada},
    date = 2013-04-7,
    url = {https://www.bgcarlisle.com/blog/2013/04/07/how-to-play-daves-famous-telephone-charades/}


Carlisle, Benjamin Gregory. "How to play “Dave’s Famous Telephone Charades”" Web blog post. The Grey Literature. 07 Apr 2013. Web. 21 Feb 2019. <https://www.bgcarlisle.com/blog/2013/04/07/how-to-play-daves-famous-telephone-charades/>


Carlisle, Benjamin Gregory. (2013, Apr 07). How to play “Dave’s Famous Telephone Charades” [Web log post]. Retrieved from https://www.bgcarlisle.com/blog/2013/04/07/how-to-play-daves-famous-telephone-charades/

Semantic video indexing app


The newest version of Mac OS, called “Mountain Lion,” includes “Dictation,” which is a piece of system software that takes speech and converts it to text. This is nothing new, of course. I remember that I had a piece of dictation software for my old Windows 98 PC. You had to “train” the software to understand what you said, and even then it was wildly inaccurate, but in principle, this sort of software has existed for a long time. Dictation on Mac OS is much better than the one I had back in 1998, but of course it is not perfect.

That particular piece of software I had on my PC was not built in to the operating system. I had to pay for it. Not only that, but because it didn’t work very well, I never got another dictation programme again. But now that this one is built into the OS, I think I’m going to try an experiment.

Here’s my inspiration: In Star Trek, every character keeps a “log,” and because it’s the future, it’s an audio log. In The Next Generation, they were often shown as video (b)logs. Sometimes, in order to advance the plot, a character would be shown searching through his own (or another person’s) logs. What was interesting was that the search would usually be a semantic keyword search. Something like, “Computer, show me all log entries relating to the warp core” (or whatever they were interested in at the time). With dictation software now a standard feature in OS X, we’re at a point where we could write an app that does exactly what the computer did in Star Trek.

The workflow will be as follows: Take a video (or a set of videos) that you’re interested in, and extract the audio. Divide the one big audio file into hundreds of smaller (say, ten-second-long), overlapping audio files that are annotated with their start time in the original video. For each of these smaller files, pass them through the dictation software and generate a text file that includes the text that has been generated by the system’s text-to-speech dictation software. And voilà, you have generated a time-encoded text index for your video—just like the one on YouTube, but you wouldn’t have to upload the file.

Wrap this all up in a shiny OS X app wrapping and put it on the App Store. Sell it for $0.99.

Then, if you had a bunch of videos—say, seasons 5–6 of Doctor Who, and you wanted to find all references to “the Silence,” you could install the app, have it index your iTunes library, and then do a search through your videos for certain keywords or phrases.

Actually, this might work. If anyone wants to collaborate with me on this one, hit me up in the comments.

Edit: I take it back. A quick experiment with Dictation indicates that we are nowhere near having the technology to be able to do this.


    title = {Semantic video indexing app},
    journaltitle = {The Grey Literature},
    author = {Benjamin Gregory Carlisle},
    address = {Montreal, Canada},
    date = 2012-08-16,
    url = {https://www.bgcarlisle.com/blog/2012/08/16/semantic-video-indexing-app/}


Carlisle, Benjamin Gregory. "Semantic video indexing app" Web blog post. The Grey Literature. 16 Aug 2012. Web. 21 Feb 2019. <https://www.bgcarlisle.com/blog/2012/08/16/semantic-video-indexing-app/>


Carlisle, Benjamin Gregory. (2012, Aug 16). Semantic video indexing app [Web log post]. Retrieved from https://www.bgcarlisle.com/blog/2012/08/16/semantic-video-indexing-app/

The Carlisle-Desroches Quidditch Hoop Construction Manual


I discovered last week that the Carlisle-Desroches Quidditch Hoop Construction Manual was incorporated into the latest version of the IQA rulebook! Hooray!

We never received any official notice from the IQA—we found out about this when one of my teammates noticed a reference to the design on the IQA site. Anyway, we’re honoured, and this has inspired us to put some more work into it. Also, one of the members of the McGill Quidditch team has asked us to re-think the bases for the hoops this summer.

Hence, we plan to build, test and release the Mark II Carlisle-Desroches Quidditch Hoop over the course of the summer. The new design which will be the same as the original, but with an alternate base that’s probably made of PVC rather than the current bucket-o-concrete. For the record, I like the bucket-o-concrete, but some have raised concerns about safety. They’re afraid that people will hit their heads.


    title = {The Carlisle-Desroches Quidditch Hoop Construction Manual},
    journaltitle = {The Grey Literature},
    author = {Benjamin Gregory Carlisle},
    address = {Montreal, Canada},
    date = 2012-04-26,
    url = {https://www.bgcarlisle.com/blog/2012/04/26/the-carlisle-desroches-quidditch-hoop-construction-manual/}


Carlisle, Benjamin Gregory. "The Carlisle-Desroches Quidditch Hoop Construction Manual" Web blog post. The Grey Literature. 26 Apr 2012. Web. 21 Feb 2019. <https://www.bgcarlisle.com/blog/2012/04/26/the-carlisle-desroches-quidditch-hoop-construction-manual/>


Carlisle, Benjamin Gregory. (2012, Apr 26). The Carlisle-Desroches Quidditch Hoop Construction Manual [Web log post]. Retrieved from https://www.bgcarlisle.com/blog/2012/04/26/the-carlisle-desroches-quidditch-hoop-construction-manual/

Solid dairy confinement


Solid Dairy Confinement

Solid Dairy Confinement

I am in the process of writing a post on the 2011 Quidditch World Cup, but I’m too tired to finish it right now, and I haven’t even gone through the photos yet.

So in the meantime, here’s something I pulled out of the file on my computer marked “not quite ready for public consumption.”

I’ve thought for a while that the attached image or something like it, would be good on a t-shirt. I think it’s funny. And it’s not the worst idea I’ve ever had for a t-shirt design.

Incidentally, the linked image is sized to make it fit nicely onto an iPhone lock screen.


    title = {Solid dairy confinement},
    journaltitle = {The Grey Literature},
    author = {Benjamin Gregory Carlisle},
    address = {Montreal, Canada},
    date = 2011-11-15,
    url = {https://www.bgcarlisle.com/blog/2011/11/15/solid-dairy-confinement/}


Carlisle, Benjamin Gregory. "Solid dairy confinement" Web blog post. The Grey Literature. 15 Nov 2011. Web. 21 Feb 2019. <https://www.bgcarlisle.com/blog/2011/11/15/solid-dairy-confinement/>


Carlisle, Benjamin Gregory. (2011, Nov 15). Solid dairy confinement [Web log post]. Retrieved from https://www.bgcarlisle.com/blog/2011/11/15/solid-dairy-confinement/

How to tell someone’s fortune


I have to admit, I can’t take full credit for this idea. Steps 1–3 were Pickles’ idea. This technique will only work if you have a smartphone and you take public transit regularly.

  1. Sign up for a Twitter account and a Google+ account.
  2. Next time your bus or métro is late, open Twitter and Google+ on your smartphone and search under “nearby” for tweets and posts that make reference to the bus or métro stop where you are. (A Twitter user’s first instinct, when his or her bus or métro is late, is to tweet about it.)
  3. When you’ve found a recent tweet about your particular public transit problem, try to identify who it is that wrote it. Often you can do this from the person’s profile photo and by seeing who is fiddling with a smartphone.
  4. Read back on that person’s tweets and try to infer 5 or 6 minor but specific details about that person’s life that couldn’t be guessed from the person’s appearance. Memorise these.
  5. Look for one major thing, like a fight with a family member or an assignment at work or school, that is recent enough to not have been resolved yet. Try to guess what it is that the person would like to hear about that.
  6. Approach.
  7. Ask to see the person’s palm, or the pattern of coffee grinds in the bottom of her cup, or (my personal favourite) grab the person’s earlobe, and say, “Your pagh is strong, my child.”
  8. Use the minor details that you have gleaned from his or her Twitter or Google+ feed to gain the person’s trust. (E.g. “Your roommate—she doesn’t do the dishes very regularly, does she?” or “Did you just get a promotion at work?”)
  9. Act surprised about something, and then play “hard to get.” (E.g. “Oh! Isn’t that something!” / “What?” / “I don’t know if I should tell you. It’s about [major detail from step 5].”)
  10. Let the person offer you money. Begrudgingly accept.
  11. Tell the person what he or she wants to hear. (“Your brother puts up a tough exterior, but deep down he forgives you.”)
  12. Cackle, disappear in a puff of smoke.

If any of you actually has an opportunity to try this, let me know how it works out.


    title = {How to tell someone’s fortune},
    journaltitle = {The Grey Literature},
    author = {Benjamin Gregory Carlisle},
    address = {Montreal, Canada},
    date = 2011-08-13,
    url = {https://www.bgcarlisle.com/blog/2011/08/13/how-to-tell-someones-fortune/}


Carlisle, Benjamin Gregory. "How to tell someone’s fortune" Web blog post. The Grey Literature. 13 Aug 2011. Web. 21 Feb 2019. <https://www.bgcarlisle.com/blog/2011/08/13/how-to-tell-someones-fortune/>


Carlisle, Benjamin Gregory. (2011, Aug 13). How to tell someone’s fortune [Web log post]. Retrieved from https://www.bgcarlisle.com/blog/2011/08/13/how-to-tell-someones-fortune/

GPS, governors and traffic police


When a police officer stops you on the road to issue you a ticket for speeding and you’re only 20 km/h over the limit on a major highway, generally the real reason you’re receiving the ticket is not one of safety. If the issue was safety, your licence would be taken away, your car would be impounded and the fine would be much higher.

This is what is done (in Ontario at least) when someone is caught speeding 50 km/h over the limit. We rightly think that this is dangerous behaviour, and the coercive powers of the state are brought in to make sure it doesn’t happen.

In the case of a ticket for 20 km/h over the limit on a highway, the real reason is one of revenue. This isn’t necessarily a bad thing, but the way that this tax is being applied brings about some irrational consequences.

What we have currently is a “speed limit” (as posted on signs—usually 100 km/h on the highway) and then an actual limit (as enforced by police—usually 150 km/h on the highway). For speeds at or below the “speed limit” (as posted), the highway is free to use. For all the speeds between the posted an the enforced limit, there’s a non-zero chance that you will be required to pay a fee to use the highway at that speed. The chance that you will be required to pay the fee increases with the amount of time that you are driving above the “speed limit” (as posted), and the amount of the fee increases with how much faster than the “speed limit” you are driving.

This is essentially a pay-as-you-use tax applied to drivers who want to exceed the speed limit, but instead of applying the tax equally among the community of drivers, we use a lottery—a random number generator (the distribution of traffic police in space and time) to decide who will pay.

So if v is your speed when caught by the police and t is the number of minutes you are speeding, let us take p(t) to be the probability that you will be caught speeding by the police (p is a function of time), and f(v) is the amount of the fine that you will pay (f is a function of your speed when caught). So if you are rational, you can expect to pay p(t)∙f(v) dollars for speeding at speed v for t minutes.

Unfortunately, people don’t expect to pay that much. Humans aren’t rational. They blame it on bad luck when they get caught, and they chalk it up to their own cleverness when they get away with it. Everyone wants (and expects) to be the lucky one who gets away with not paying anything.

It is the fact that this tax is applied in a probabilistic way that makes people act irrationally. Have you ever noticed that traffic slows down considerably when drivers see a traffic cop on the side of the road? There is no reason for that. By the time you see the police officer, it’s already over. He knows how fast you’ve been going, and if he’s going to radio his partner to pull you over, slowing down won’t help you out at this point.

This randomised way of distributing taxes brings in a number of other inefficiencies too. I don’t have any data to back this up, but I think it has a negative impact on our attitudes toward law enforcement. On being caught speeding by a traffic officer, who among us hasn’t thought, Don’t you have something better to do? It is also, I think, a poor use of a police officer’s time to have them standing on the side of the road with a device for measuring the speed of passing vehicles and a radio.

There are already a few technologies that exist today that could combine to solve all of these inefficiencies and irrational behaviours.

There are relatively cheap GPS machines that can indicate what the speed limit is in any given stretch of highway with very high accuracy. There are also governors—machines that regulate the speed at which a vehicle can drive, regardless of the preferences of the driver.

I propose that instead of using the “who’s gonna get caught by the police?” lottery to decide who pays the “driving over the posted limit” tax, we could use a GPS/governor system to limit and tax the use of highways at speeds greater than the posted limit.

First off, a GPS/governor system could actually enforce strict speed limits where we want them. For example, we do not want drivers to be able to drive more than 150 km/h on the highway under any circumstances. As a society, we’ve made that clear in the laws that we’ve enacted. A GPS/governor could actually prevent a car from accelerating beyond that speed. Or in the city, a GPS/governor could strictly prevent going over 30 km/h in a school zone. It would not be a matter of punishing offenders—the technology just would not allow for breaking the rules.

Then, in cases where we have already decided that we do want to allow for a certain amount of speeding, but we want to tax it, like in the case of a car travelling at 120 km/h on the highway, a GPS/governor could record the time that the driver is over the limit, and by how much. The area under that function would be the fine, and you could make that to be equal to what one would rationally expect to pay under the current system, if one was caught exactly as much as one would expect to be. So, if you are speeding for t minutes at speed v, at the end of the month, you would receive a bill from the Ministry of Transportation for exactly p(t)∙f(v) dollars. You’ll note that it’s the same amount that a rational person speeding exactly the same amount should expect to pay under the current system.

Such a system would free traffic officers to be watching for actually dangerous driving practices (texting while driving, extremely aggressive driving, etc.), and it would save money in the long run.

The difference is that all the people who think that it’s their own cleverness that has allowed them to get away with speeding will hate a system like the one I’m suggesting.


    title = {GPS, governors and traffic police},
    journaltitle = {The Grey Literature},
    author = {Benjamin Gregory Carlisle},
    address = {Montreal, Canada},
    date = 2011-08-12,
    url = {https://www.bgcarlisle.com/blog/2011/08/12/gps-governors-and-traffic-police/}


Carlisle, Benjamin Gregory. "GPS, governors and traffic police" Web blog post. The Grey Literature. 12 Aug 2011. Web. 21 Feb 2019. <https://www.bgcarlisle.com/blog/2011/08/12/gps-governors-and-traffic-police/>


Carlisle, Benjamin Gregory. (2011, Aug 12). GPS, governors and traffic police [Web log post]. Retrieved from https://www.bgcarlisle.com/blog/2011/08/12/gps-governors-and-traffic-police/

Sweden Sour Pork


The Swedish Chef

Bork bork bork

The result of a mispronunciation of “sweet-and-sour pork,” Sweden sour pork is a great culinary idea for someone looking to make it big in the competitive and lucrative world of naming foods that don’t sound very good in a way that makes them sound nearly the same as other more popular foods.

To pull it off properly, though, you’d need to be a chef from Sweden. A Swedish Chef, if you will.


    title = {Sweden Sour Pork},
    journaltitle = {The Grey Literature},
    author = {Benjamin Gregory Carlisle},
    address = {Montreal, Canada},
    date = 2011-02-18,
    url = {https://www.bgcarlisle.com/blog/2011/02/18/sweden-sour-pork/}


Carlisle, Benjamin Gregory. "Sweden Sour Pork" Web blog post. The Grey Literature. 18 Feb 2011. Web. 21 Feb 2019. <https://www.bgcarlisle.com/blog/2011/02/18/sweden-sour-pork/>


Carlisle, Benjamin Gregory. (2011, Feb 18). Sweden Sour Pork [Web log post]. Retrieved from https://www.bgcarlisle.com/blog/2011/02/18/sweden-sour-pork/


Tag bag

Recent comments

Old posts

All content © Benjamin Carlisle