Monthly Archives: November 2013

Coin: Tempting but problematic

Wouldn’t it be great to carry just one credit card that could replace all the cards in your wallet?

Well this new digital credit card device called coin might make that possible. The video on their site shows you how this works. In brief, you swipe your card through a reader attached to your iPhone, the data is transferred to the device by bluetooth low energy and then the device can set its magnetic strip to mimic any card you’ve loaded into it. Yes, that’s right, you select a “card” on the coin display and then swipe the coin device just like a credit card.

While this sounds great, it looks to me like it has numerous problems. Here are the first few that come to mind.

The first one is acceptance. While asking the cashier of a shop in San Francisco to swipe a device instead of a card might work, I’m doubtful an hourly worker at restaurant here in the Mid-West is going to go for it. It does’t look like a real credit card and won’t pass the typical visual inspection a cashier does on a card. There’s no signature. The expiry and security code are on the display. I would imagine getting rejected more often than not.

The second one is that I believe that use of this device is beyond the limits the credit card companies put on how the card data can be used and stored. The Coin folks say in their FAQ that they are pursuing PCI DSS Certification, which will be critical. Failing to be certified to hold and transmit credit card data could result in a directive from the credit card companies to shops to not accept transactions from this device. Also, it might influence what the credit card companies are willing to do in the event of fraud.

The brings up the third issue, fraud. While I already feel a little uncomfortable giving my card to wait staff who walk off to ring up by bill, giving them this device gives them access to several cards. Coin’s answer to this concern is a proximity based lockout that engages when the device is away from your phone. Could the device be hacked and the data easily downloaded? Can a waiter switch cards, either on purpose or on accident? How about other uses? Can you swipe hotel room key cards and store them in the device? That could cause some interesting problems…

And yet… It sure is cool. I would use one if the problems with it were less.

Mavericks syslog server configuration

For you OS X server admins out there, the syntax to enable syslogd to act as a syslog server has changed under Mavericks and OS X Server v3.

As before, convert the plist from binary into xml using plutil:

sudo plutil -convert xml1 /System/Library/LaunchDaemons/com.apple.syslogd.plist

The open the plist in your favorite editor and look for <key>Sockets</key>. The \<dict\> block after this key holds the information that used be in the dict block following <key\>NetworkListener</key>, except now the information goes in a sub-block called BSDSystemLogger. The default BSDSystemLogger block looks like this:

<key>BSDSystemLogger</key>
<dict>
        <key>SockPathMode</key>
        <integer>438</integer>
        <key>SockPathName</key>
        <string>/var/run/syslog</string>
        <key>SockType</key>
        <string>dgram</string>
</dict>

This creates a UNIX socket in /var/run. To enable remote logging, we want a network socket on the syslog port. To get that, simply change the above block to this:

<key>BSDSystemLogger</key>
<dict>
        <key>SockType</key>
        <string>dgram</string>
        <key>SockServiceName</key>
        <string>syslog</string>
</dict>

Save the plist. You can re-convert it to binary if you like or just leave it in XML. Unload and reload the plist and syslog will start and accept remote syslog data.