There’re a bunch of stories floating around about how hard it is to switch cable providers. I just want to get those out of the way: they’re mostly not true. You don’t, for example, have to pay Teksavvy for a year upfront. That said, there were some rough patches — which mostly seemed to be oligopolistic roadblocks designed to favor incumbents.

I took notes during the transition, and I’ll present those here. But first, pictures! Here’s speed under Rogers. This is one of the reasons Canada has famously bad internet service:

And here’s Teksavvy crushing Rogers’ download speed with a less expensive plan:

I was surprised to see Teksavvy’s upload speed at around half of Rogers’, but my home up-spout doesn’t need to be fat — I’m mostly sending requests to trigger downloads. Still, Teksavvy’s communication around that could have been clearer. It was a small disappointment.

On to the numbers. Here’s the breakdown of what it cost to switch in cold, hard Queenbacks:

Twenty-six months from now the savings from leaving Rogers will surpass the costs of changing to Teksavvy, all while enjoying a faster connection — it’s a no-brainer. There are also potential cost savings in the router — I wanted 802.11ac support so I bought the highest-testing unit on Tom’s Hardware — and in the modem, which you can find cheaper online.

It’s very disappointing to see both disconnection and reconnection fees adding over 33% to the total cost, when the actual change seems to be who’s billing me for using extant infrastructure. Again, this seems to be a boon to incumbents — a deterrent against and penalty for leaving their garden.

A final note about costs: I am *sure*, but I have no proof, that our Rogers service included a free router-modem as a promotion when we signed up. On reviewing our bills it turns out that was probably a misrepresentation by the sales associate — we’ve been charged a monthly rental fee for the thing this whole time, rolled into the price.

“With an honest man no contract is necessary. With a dishonest man no contract is sufficient.”

So yeah: a failure of judgement on my part — trusting a Rogers employee (presumably one on commission) was a bad move. Here are some qualitative points about the switch:

• It takes 30 days to disconnect from Rogers (another perk of being the incumbent). Just tell them you’re leaving the province if you want to avoid the up-sell and begging when you call to cancel.
• I scheduled Teksavvy connection the day after Rogers disconnection. Disconnection happens around midnight, so you don’t have Internet on disconnection day. Connection happens during business hours on connection day. Result: about 32 hours with no internet. The horror… the horror… j/k: I tethered my phone and shared the connection — have a backup plan.
• Try to schedule Teksavvy connection a day or two before Rogers disconnection. It might cut your downtime to zero: see what happens.
• TekSavvy’s billing system is a bit goofy — it gives you something like three warnings before canceling your order. I confirmed my order and then it warned me to confirm again (“strike two of three”)! I responded to that right away and accounting sorted it out.
• TekSavvy generally has fantastic, responsive email support across all departments.
• There was a *slight* hiccough in setup because our building is weird and they couldn’t identify the apartment by postal address. Teksavvy called me to fix it right away, weeks before it would have been an issue.
• No on-site installation was necessary (whereas Rogers sent a tech).
• TekSavvy’s hold music is dubstep.

I’ll update if there’s more to say, but so far, so good. I’m very pleased with the result. It feels good to get out from under Big Telecom. Payin’ less and gettin’ more — bro, I know that feel.

But I didn’t intend that. It just came out that way because of my feels, bro.

Anyway, here’s what it looked like through Storify’s cracked mirror:

]]> http://mentalpolyphonics.com/posts/broformance/feed 0 http://mentalpolyphonics.com/posts/the-changing-face-of-mpf http://mentalpolyphonics.com/posts/the-changing-face-of-mpf#comments Mon, 01 Apr 2013 18:04:02 +0000 Jack http://mentalpolyphonics.com/?p=18104 This site is probably going long-form: fewer, longer posts, excluding this one; maybe some better surfacing and curation (I have more buzzwords now that I’m a media pro).

I’m also going to be purging our history, I’m just thinking about a reasonable way of doing that. Jared’s post about quitting Evernote is probably going to be the zero-history cutoff as it accounts for approximately 20% of our daily traffic.

We started in 2006, and the project has been of inestimable value to me: literally life-changing. Thank you, everyone.

It’s possible to recurse (almost-)infinitely into paranoia with digital security. So, for example, the accusation (which I haven’t verified) that TrueCrypt’s binary checksums never match those of its manually compiled source is troubling. The mitigation is to do a security audit of the public code yourself and then compile your own version, which presumably you would do with a compiler whose code you’ve audited for security and compiled by hand into machine code to avoid recursive definition attacks. This is after you’ve done the same for your operating system. And your hardware.

But then: what’s the value of what you’re protecting and what are you actually defending it against? If you’re a normal person actually worried about advanced persistent threats (read: states) then you’re probably better off not using digital technology and seeking professional help. Let me reiterate that: if you’re an other-wise normal person who seriously thinks your gcc binaries have been compromised by a state actor, you should probably go see a psychologist. I talk to mine about paranoia all the time, and even I’m not that crazy

So, my goal is simply to present a very low target profile to people looking for someone to fuck with. You don’t need to outrun the bear, you just need to outrun Fatty McGee. With those caveats in mind, here’s what I’ve been up to:

• Preferring Firefox and locking it down by disabling cookies, having it delete everything on close, and installing HTTPS Everywhere, AdBlock, HTTPS Finder, and NoScript. A good synergy here is that it forces me to re-login to all accounts, which keeps me…
• Doing a rolling reset of all of my passwords using Mountain Lion’s built in password assistant. Every time I log-in to a service I generate a new, strong password and save it in a password vault (KeyChain). I’m going to keep doing this until I’ve cycled through every account and made its credentials unique. It’s just a better policy to compartmentalize the inevitable failures, even for throwaway accounts.
• Enabling full disk encryption on all devices and requiring a strong wake password.
• Enabling two factor authentication for all services that offer it.
• Shredding all paper documents that are even slightly sensitive. If they can’t be shredded they are locked in a safe. Document confetti is disposed of in batches: a little this week, a little next week. I’ve been known to dispose of confetti in handfuls spread across different locations. We also have a hardened mailbox.

This is all in addition to running my internet connection, at times, through a for-pay European VPN service I trust (ipredator.se). I’ve also double-checked my firewall settings and, at times, have been running a non-exit Tor relay on the theory that a network that’s more secure for you is also more secure for me.

There are a couple of major outstanding items on my security todo list. I’d like to set up…

• …an encrypted cloud drive. Maybe TrueCrypt on Dropbox, but GPG is probably a more secure encryption provider. And mega.co.nz is probably a better cloud service (in terms of size and maybe security — I dig their deniability model). Maybe TrueCrypt + Google Drive is the most practical and usable.
• …email encryption, but the usability problems of PKIs destroy the network effects necessary to make that sensible.
• …a way of accessing my passwords without physical, double-authenticated access to my home machine. Currently, if a session expires while I’m out and about, the app is dead. A possible mitigation is to set up a home VPN or, as above, encrypted cloud storage.

There’s a common fallacy often presented to the public: that there’s a tradeoff between security and privacy. “We need to have less privacy, because terrorists hate our freedom.” It’s pretty easy to dismantle logically: A locked house is both more secure and more private.

However, the actual dichotomy I’m noticing is that there is a big tradeoff between security and usability. This makes much more intuitive sense: Having to regularly two-factor authenticate in a browser set to never remember you is mildly annoying, just like it’s mildly annoying to have to lock and unlock your house (and arm and disarm your alarm) all the time.

Another example of poor security usability is the web itself: I often find myself dropping into less secure browsing modes to get sites to function. A surprising example is Google Maps, which is entirely unusable over HTTPS. Most sites take hard usability hits under NoScript. My iCloud account is so secure right now I can’t actually fully authenticate into it.

All of these security measures have polarized the risk of breach: The points of failure — “the keys to the kingdom” — are access to my home computer with knowledge of its passphrase and access to my phone with knowledge of its passphrase. This means storing my passwords on my home computer is actually less secure than storing them in the cloud: My cloud presence is largely mediated by two-factor authentication, so even with physical access to my house a digital attacker would also need access to my phone.

If something unfortunate happened to my phone, intentionally or otherwise, as of today it would take significant effort to reconstruct my online identities. I might need a wallet chain

My friends are mostly strategy gamers, and this was my response to one asking me to join his group of regional mayors. I decided it wasn’t a nice email to send to a friend who was inviting me to play a game, so I lightly-revised and slightly-expanded it before publishing it here instead.

Last, this is essentially a review-of-the-reviews — a metareview — and I should mention I’ve never actually played the game. Hopefully the reasons why will be clear.

—

To acknowledge my own bias in all of this upfront: I think EA is one of Satan’s more pustular stinking tentacles. I do not give them the benefit of the doubt.

I’ve been reading the articles about the server issues, the small city sizes, the poor traffic AI design, etc. All that aside, I have three observations:

1) Not doing an offline mode is a terrible PR move. It is technically possible, and simple enough that there’s a fan mod that does it. Refusing to do so, repeatedly, and equivocating as to its technical feasibility is an odd-feeling combination of lying to fans while ignoring them. It’s bad art, bad business, and bad entertainment. It’s the kind of thing you do when you’re dictating to your audience instead of listening to them.

It strikes me that a feature-restricted offline client would make an excellent free-to-play version of the game, and that connecting to a server to open up extra features should be what costs money. They compare it to playing WoW offline, while not seeming to understand that WoW is largely offline in terms of content. In WoW’s case you pay monthly to connect your fat client to the server. Warsong Gulch’s geometry isn’t streamed, it’s local. That’s why players need to install game updates instead of just having the changes show up one day on the server.

That nonsense about “moving calculations into the cloud” grates on me every time (Maxis GM) Lucy Bradshaw says it too. “Servers” aren’t “the cloud” — if the game had been built to use the cloud there would have been no traffic problems (because clouds typically scale to demand) but it would have cost EA more. A technical point, maybe, but to me it beggars her credibility.

2) I feel really bad for the software people who had to deal with the server debacle. That must have been a worse, deeper level of hell than the one that incinerated me. Given EA’s reputation they were probably coming off a prelaunch crunch and ended up going straight into a postlaunch firestorm. That’s like being promised you’ll get shot at the end of a forced march but instead you’re forced to build a pyramid — and *then* get shot.

I don’t want to help make death march game development more profitable than it already is. In fact, I’m toying around with the notion of creating a “cruelty free”-type certification for games that would highlight poor treatment of developers (who should unionize).

3) Once again, games journalism has been shown to be fundamentally compromised. It seems EA managed to convince a bunch of writers that server problems shouldn’t effect the review score while simultaneously insisting that the core gameplay experience requires a server. This is clearly jibberish, but hey: why expect people to bite the hand that feeds them?

That said, I hear it looks pretty at night.

This is a pretty great deconstruction of gender roles in games. Interactive entertainment, despite some progress, still has significant gender portrayal problems (as does Hollywood).

I like her usage of “damseled”. It seems to assume that the characters exist outside of their representation, which is pretty radical (and might be true), and that their particular creators do them violence through stereotypical gender portrayal.

“With the way that the game works, we offload a significant amount of the calculations to our servers so that the computations are off the local PCs and are moved into the cloud. It wouldn’t be possible to make the game offline without a significant amount of engineering work by our team.”

Their server problems clearly arose because they’re not using the cloud, which isn’t just a new name for the client/server architecture. Their system is clearly not dynamically adding new virtual servers to balance demand, for example.

Sometimes I run across developers who do not want to use source control. Their typical reason is that it will take too long and the project schedule is already tight.

I use the following scripts to route around their intransigence. I started with the idea of scraping a team’s publicly-visible code and throwing it into Subversion. Luckily this particular team was working on a WebDAV-enabled server, so I refined the idea to:

1. Every hour:
2. Connect to WebDAV.
3. Download everything.
4. Commit to SVN.
5. Disconnect from WebDAV.

I’m not saying this is the best way to accomplish my goal, it’s just the current solution. All of this code lives, on my Mountain Lion machine, in ~/scripts. This is mount_dav.sh:

#!/bin/sh
mkdir /Volumes/dav
chmod 777 /Volumes/dav
expect ~/scripts/mount_dav.expect
echo WebDAV mounted!

expect is a new one for me. It lets you enter “interactive” sessions with text-based interfaces, which is useful for commands that ignore stdin, like mount_webdav. Here’s mount_dav.expect:

#!/usr/bin/expect
set timeout 60
spawn /sbin/mount_webdav -i http://dav.fakevendor.com/ /Volumes/dav/
expect "name:" {
send "jack.fake.name\r"
}
expect timeout {
exit
} "word:" {
send "whutp4ssbr0\r";
exp_continue
}

As I said, expect is new to me, so I mostly just stole that off Stack Overflow examples: it waits for a username/password prompt and supplies my credentials (which is bad — it should grab them from Keychain Access or something). So, with those two scripts, if you do…

> sh ~/scripts/mount_dav.sh

… it’ll mount the WebDAV filesystem at /Volumes/dav. Now it’s simple to operate on locally. Our security policy blocks rsyncs which are actually remote, but since we’re locals we’re allowed to hang (sync_svn.sh):

#!/bin/sh
sh ~/scripts/mount_dav.sh
rsync -auv /Volumes/dav/project /Users/jack/project/trunk
cd /Users/jack/project/trunk
/opt/subversion/bin/svn add * --force
cat ~/scripts/password | /opt/subversion/bin/svn commit -m "Autocommit." --username jackfake
cd -
sh ~/scripts/umount_dav.sh

That copies the project to the SVN trunk, force-adds everything to the repository, and commits with an automatic message.

rsync -auv, roughly, archives all updated files verbosely. I needed to --force the svn add * to make it recursive (otherwise it skips things). Here my password is stored in another file with stronger access controls, but that’s still a bad place for it. The last line calls umount_dav.sh, which cleans up the WebDAV mount after we’re done with it:

#!/bin/sh
/sbin/umount /Volumes/dav
echo WebDAV unmounted!

Simple. Okay. Where are we? Turns out we’re almost done:

1. Every hour:
2. Connect to WebDAV.
3. Download everything.
4. Commit to SVN.
5. Disconnect from WebDAV.

This was also a cool project because it was my first (!) foray into cron. Here’s crontab_svn_dav, in ~/scripts:

#min hour mday month wday command
00 */1 * * * sh /Users/jack/scripts/sync_svn.sh

Which means “run sh /Users/jack/scripts/sync_svn.sh on the stroke of every hour”. Now, finally, to kick it all off run:

crontab crontab_svn_dav

And at the turning of the hour you’ll get system mail that looks something like this:

from:	 Cron Daemon 
to:	 jack@jacks-macbook-pro.local
date:	 Fri, Mar 8, 2013 at 4:00 PM
subject: Cron  sh /Users/jack/scripts/sync_svn.sh
spawn /sbin/mount_webdav -i http://dav.fakevendor.com/ /Volumes/dav/
Username: jake.fake.name
Password:
WebDAV mounted!
building file list ... done
project/css
project/css/index.css
project/index.html
[...]
sent 3270 bytes  received 102 bytes  293.22 bytes/sec
total size is 642335  speedup is 190.49
Sending        project/css/index.css
Transmitting file data .
Committed revision 2387.
/Users/jack
WebDAV unmounted!

You can see in that (fake) output that someone changed index.css since the last sync, and that change has been committed to SVN. If there are no changes, nothing commits. The daemon messages will slowly fill your system mailbox, which is kind of a pain to get at, so, in a trick I learned back at Octonet and again this afternoon…

> echo jack@fakeemail.com >> ~/.forward

… forwards your system mail to an account of your choice. The nice thing about this is the reports from the cron daemon can be filed away with whatever email management system you already use.

It can be hard to debug something that runs once per hour, so if you…

> crontab -e

… and change it to…

#min hour mday month wday command
*/1 * * * * sh /Users/jack/scripts/sync_svn.sh

… then the job will run every minute. If you want to see what jobs you have scheduled…

> crontab -l

… will list them, and to stop them (all) from running:

> crontab -r


Areas for improvement:

• Error handling.
• Remove hardcoded paths.
• Secure credential storage.
• Remove cds, which are there for SVN convenience.
• chmod 777 might be unnecessary.
• Could do SVN branching and tagging instead of dumping on trunk.
• Could disconnect from WebDAV after the rsync (ie: release the resource ASAP).
• git-svn ?

It has lots of nudity, obv, and co-stars Rutger “Tears in the Rain” Hauer.