I’ve been using the DVR feature of Plex since the first beta version, and it replaced an aging Mac+EyeTV setup I was using before. Bought a HDHomeRun device, and I’ve been pretty happy with the setup since the beginning. The main issue I have with the DVR feature is the EPG. For one of the channel I record a lot from (Télé-Québec), the EPG data is very bad. It’s missing a lot of shows (it has holes), and shows will sometimes start at a different time in the EPG than in reality, making me miss a few minutes at the beginning of the end of the shows I record, or complete episodes.

For quite some time now, Plex has been plagued with a bug preventing Google Chrome users from watching YouTube videos they saved into their Watch Later queue. Being a fan of Chrome (I’m not using anything else really), Plex, and their Watch Later queue, which I populate using both IFTTT (widget: IF new RSS item THEN send email to [my_plexit_email_address]) and their Plex It! bookmarklet, I decided to further debug the issue.

I’ve been using mint.com since 2010. I was happy with the service; it worked pretty well, most of the time. But recently, I decided it just wasn’t worth the risks. So I unlinked all my banking accounts, and then deleted my mint account. Since then, I replaced it with a custom solution: my own mint.com alternative. In no particular order, here’s what I did / how it works. My banking credentials (usernames, passwords, security questions answers) are stored only on my (Mac) computer, in Keychain.

Trying to update dependencies in a PuPHPet/Vagrant virtual machine using vagrant provision, but getting SSL errors when it tries to install gems? Example: $ vagrant provision ==> netlift-web: Running provisioner: shell... [...] Unable to download data from https://rubygems.org/ - SSL_connect returned=1 errno=0 state=error: certificate verify failed (https://api.rubygems.org/specs.4.8.gz) [...] The issue is explained on rubygems.org, but basically, the CA Certs included in the PuPHPet VM you are using do not include the required CA cert (GlobalSign Root CA).

So Nissan published new versions of their mobile apps for the Nissan LEAF, with upgraded security. A-Good-Thing™. But doing so, they added an unnecessary level of complexity on their API: the passwords sent by the mobile apps are now encrypted! I battled most of the evening, trying to find how they encrypt the passwords, to be able to reproduce it, and I as finally able to! [1] They encrypt the passwords using “Blowfish/ECB/PKCS5Padding”, and the key is a string returned by the API before the login API endpoint is used.

The symptoms were hard to notice at first: downloaded files would sometimes be corrupted, especially large files; attempts to fix those downloads (using par2) would more often than not fail. Then it became bizarre; calculating the checksum of those files would sometimes, but not always, result in different values.

When buying things in the US from Canada, there are often different options to pay: PayPal, credit cards, etc.

In my case, I am (too) often paying for my voip.ms line (DID and usage). Despite being a Canadian company, they only charge in USD, probably because they need to pay their providers in USD, and don’t want to lose money when the exchange rate is abysmal (1.40 CAD = 1 USD right now!)

When paying an invoice in USD from Canada, not all payments methods are equals. Some will charge more to convert currency. PayPal in particular is pretty bad.

App Transport Security is a feature that improves the security of connections between an app and web services. The feature consists of default connection requirements that conform to best practices for secure connections. Apps can override this default behavior and turn off transport security.

Transport security is available on iOS 9.0 or later, and on OS X 10.11 and later. Source

What does that mean?

That unless you change something in your iOS app’ plist, your app will not be able to communicate with unsecure HTTP servers, when it runs on iOS 9.

That’s a good thing really; Apple is trying to force people to update their HTTP servers to use the latest HTTPS protocols & recommendations: TLS 1.2, SHA256 or better, forward secrecy.

Maybe you just want to back them up for when something goes wrong, or maybe you want to set up a new two-factor authentication app on a platform that Authy doesn’t support (cough Windows Phone cough). Whatever your reasons, if you want to export your TOTP secret keys from Authy, their apps or support guys won’t be much help to you.

The trick, that I just used to install all my existing TOTP secrets in the Microsoft Authenticator app, is to change one of their app of which we have the source, namely their Chrome app, to show us what we want.

Google Reader is going away later this year. This means those of us using RSS to keep in touch with the world will need to find an alternative to be able to get our fix using our different devices.

I still remember the pre-Google Reader days of RSS, when RSS clients were silos that talked to nobody. This meant that trying to read articles on a PDA (Palm Zire anyone?), and on a PC, forced us to skip a bunch of articles each time we switched from one to the other… Solutions for this problem existed at the time, but were convoluted, and not that pleasant. i.e. I don’t want to go back there!

This morning, I read a post by Ruth John, aka @Rumyra, about how she used IFTTT (If-This-Then-That) to inject the content of a RSS feed into the Pocket read-it-later service. This stuck me as a good idea, so I started with a Yahoo Pipe that took my OPML, and merged all articles into one feed, and I inputed that into IFTTT, and chose Pocket as the target. Sadly, that didn’t work so well; IFTTT has known issues with Yahoo Pipes RSS feeds. Next option: just do it myself!