The Macalope takes a look at a Fortune piece headlined “Why Android Wear Will Give the Apple Watch a Run for Its Money”.

iPhone users won’t be able to download third-party apps either, though this should be less of a dealbreaker.

Sure, who likes downloading apps? Practically nobody. Most of those “billions of apps downloaded” numbers Apple likes to report come from one guy in Duluth, Minnesota.

This guy has it completely backwards. The tight integration required between today’s smartwatches and their tethered phones means that anything other than a first-party solution is going to be rough going. Apple Watch only works with iPhone, and iOS is tied down such that no other smartwatch is going to offer a competitive experience for iPhone users.

Like I wrote two weeks ago, this is why I think the stakes are higher for Apple with the new Apple TV this year than they were for Apple Watch last year. Set-top boxes aren’t integrated with your phone. An iPhone user can freely choose a Roku or Fire TV or Chromecast Chromestick and have a great experience. Apple TV has to be excellent, on its own, for it to succeed.

Today, April 24th, is when the Apple Watch officially launches for sale, even though many people will not receive their watches for weeks, if not months. Buildup to the Apple Watch has been totally unprecedented, as it has proven both a polarizing product, as well as one that has brought distinct demographics together in ways that I've never seen before. When else has a product been discussed so heavily by the tech industry, fashion industry, celebrity news industry, and watch industry all at the same time?

The article Apple Watch Review Chapter 1: Setup & First Day Experience first appeared on aBlogtoWatch and was written by Ariel Adams.

The other day, Federico asked about why people use web services such as IFTTT. I have a few of these that I use frequently, but the geekiest one is this: controlling my Mac with my car.

More specifically, when I turn my car’s ignition on or off in the parking lot at my office, Automatic triggers an IFTTT recipe, creating a text file in a special Dropbox folder which is monitored by launchd[1] and runs a shell script depending on which file is created.

It sounds more complicated than it is. No, really.

What can these shell scripts do?

There are many possibilities for what these scripts can do, but here are some examples of what I do.

When my ignition turns on

When my ignition turns on, that means that I am leaving my office, which could mean for lunch (I’ll be back in an hour), an off-site meeting (I’ll be back in an hour or two), or it’s the end of the day (I’ll be back tomorrow or the next business day).

• Make sure my Mac is locked
• Load CrashPlan
• Make sure my TimeMachine backup drive is mounted
• Make sure BitTorrent Sync is running
• Run SuperDuper[2]

When my ignition turns off

When my ignition turns off , that means that I am arriving at work.

• Unload CrashPlan[3]
• Unmount my SuperDuper drive [4]
• Launch apps that I want to use to start the day: BusyCal, OmniFocus, MailMate, etc.

If you use network drives, this would be a good time to (re)connect to them. You could also launch iTunes or Spotify if you listen to music at work. Basically anything that you normally wait for your computer to do when you first arrive at the office, you can get started before you even walk in the door.[5]

“Ok… how?”

Now that you hopefully understand the big picture overview, I’ll get into the specifics of how to put this together.

1. You need a car with an Automatic device.[6]
2. You need accounts with IFTTT and Dropbox.
3. Create a folder in Dropbox. This can be any folder, but I will be using /Users/jsmyth/Dropbox/IFTTT/Automatic/IgnitionAtWork/ in my examples.
4. A launchd plist in ~/Library/LaunchAgents/ which monitors the folder from step #3.
5. A shell script to run from the launchd plist. This can be called anything you want, but I will be using /usr/local/bin/IgnitionAtWork.sh in my examples.
6. Two geofenced triggers in the iOS IFTTT app: one which creates an “IgnitionOn.txt” file and one which creates an “IgnitionOff.txt" file.

Example launchd plist

Here is an example launchd plist.

• Change the Program key to be the name of the shell script
• Change the QueueDirectories key to point to the directory that you created.

Note that you cannot use ~ or $HOME to refer to your home directory in a launchd plist, you must provide the full, exact path.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.tjluoma.IgnitionAtWork</string>
    <key>Program</key>
    <string>/usr/local/bin/IgnitionAtWork.sh</string>
    <key>QueueDirectories</key>
    <array>
        <string>/Users/jsmyth/Dropbox/IFTTT/Automatic/IgnitionAtWork/</string>
    </array>
    <key>RunAtLoad</key>
    <false/>
</dict>
</plist>

(Note: this is available as a GitHub gist).

Save it to ~/Library/LaunchAgents/com.tjluoma.IgnitionAtWork.plist

Example shell script

The contents of IgnitionAtWork.sh are really up to you. This is just an example to show how you might put it together.

#!/bin/zsh -f

# Important! DIR _must_ be the same as whatever directory you used
# for `QueueDirectories` in the `com.tjluoma.IgnitionAtWork.plist`
DIR="/Users/jsmyth/Dropbox/IFTTT/Automatic/IgnitionAtWork/"

    # if the directory does not exist, exit
cd "$DIR" || exit 0

    # get rid of this file, which will cause `launchd` to keep triggering
rm -f .DS_Store

command ls -1 \
| egrep 'IgnitionOn|IgnitionOff' \
| while read line
do

case "$line" in
    IgnitionOn*)

        ###########################################################################
        ## BEGIN OPTIONAL SECTION for when Ignition is turned on
        ## Change this in this section to suit your needs
            # run BitTorrent Sync application
        open -a 'BitTorrent Sync'

            # mount TimeMachine drive, if not mounted
        [[ ! -d '/Volumes/TimeMachine' ]] && diskutil mount TimeMachine

        if (( $+commands[lock.sh] ))
        then
                # if the 'lock.sh' script is found, run it
            lock.sh
        else
                # otherwise, just lock screen by switching to login window
            '/System/Library/CoreServices/Menu Extras/User.menu/Contents/Resources/CGSession' -suspend
        fi

        ## END OPTIONAL SECTION for when Ignition is turned on
        ###########################################################################

            # This deletes the file so that launchd doesn't just keep triggering the script
        rm -f "$line"
    ;;

    IgnitionOff*)

        ###########################################################################
        ## BEGIN OPTIONAL SECTION for when Ignition is turned off
        ## Change this in this section to suit your needs

            # launch apps that you want to have run when you get to the office
            # these are just some examples
            open -g -a 'OmniFocus'

            open -g -a 'BusyCal'

            open -g -a 'MailMate'

        ## END OPTIONAL SECTION for when Ignition is turned off
        ###########################################################################

            # This deletes the file so that launchd doesn't just keep triggering the script
        rm -f "$line"
    ;;

esac

done

exit 0
# End of shell script

(This shell script is also available as a GitHub gist.)

Example IFTTT recipes on iOS

Step 1) Create IFTTT recipe for when the ignition turns ON in a specific area

When you launch the IFTTT iOS app, choose “Automatic” and then “Ignition turned on in an area” as the “Trigger”:

Note: If you are not in the area that you want to use as the trigger, you can manually select the area that you want to use, but it is easier to do this when you are already at the area that you want to use as the IFTTT trigger. For example, since I wanted the geofence to be the parking lot at my office, I waited until I was there before creating the IFTTT recipes.

Next, choose “Dropbox” and “Create a text file” as the “Select Action”:

This part can be a little confusing. When you first create the IFTTT recipe, it automatically chooses the folder (IFTTT/Automatic) and the filename for you. You have to select the recipe and tap “Edit”

then scroll down to change the filename and folder:

Step 2) Create IFTTT recipe for when the ignition turns OFF in a specific area

Once you have completed Step 1, repeat the process except when you launch the IFTTT iOS app, choose “Automatic” and then “Ignition turned off in an area” as the “Trigger” instead of “Ignition turned on in an area.”

There are a few provisos, a couple of quid pro quos…

This system is not foolproof.

Occasionally I realize that the IFTTT action failed to run for some reason. Launching the IFTTT app on my iPhone usually fixes this. The IFTTT iOS app can send you a push notification when recipes run, which is a good idea so that you know it is working. If Dropbox is not running, or if it is busy doing something else (like reindexing itself for the millionth time, not that I’m bitter), it might not sync the IFTTT file right away.

There have been times when I have been at the office for an hour and then suddenly Dropbox says “Oh, wait, here’s that file” and then launchd runs the “Oh, you have just arrived at the office!” script.

A few times I have been sitting at my desk after being at my office for a long time when suddenly I received an IFTTT notification that the ignition in my car had just started. It was a little disconcerting the first time it happened, but now whenever I notice that something isn’t working properly I just launch the Automatic and IFTTT apps on my iPhone, and that seems to solve the problem. (I assume these issues are caused when the iPhone runs out of RAM and kills off background processes, but that’s just a guess.)

Earlier this year, as revelations regards U.S. government/law enforcement snooping came to light, Apple published a “Commitment to Customer Privacy”. It says, in part:

Apple has always placed a priority on protecting our customers’ personal data, and we don’t collect or maintain a mountain of personal details about our customers in the first place. There are certain categories of information which we do not provide to law enforcement or any other group because we choose not to retain it.

For example, conversations which take place over iMessage and FaceTime are protected by end-to-end encryption so no one but the sender and receiver can see or read them. Apple cannot decrypt that data.

This week, security researchers at Quarkslab published a white paper disputing this, claiming, at the top:

• What we are not saying: Apple reads your iMessages.

• What we are saying: Apple can read your iMessages if they choose to, or if they are required to do so by a government order.

As Apple claims, there is end-to-end encryption. The weakness is in the key infrastructure as it is controlled by Apple: they can change a key anytime they want, thus read the content of our iMessages.

Writing at AllThingsS, John Paczkowski reports:

Asked by AllThingsD if the firms’s claim is legitimate, renowned security technologist Bruce Schneier replied with a definitive yes. “The researchers show that iMessage could be undetectably designed to intercept and read messages, not that it is designed to do so,” Schneier said.

But Apple insists it is not so motivated. And it stands by its June claims about iMessage’s security. Apple says that QuarksLab’s theory is just that — a theory, and one that would require a re-architecting of iMessage for it ever to be a threat in the real world.

“iMessage is not architected to allow Apple to read messages,” said Apple spokeswoman Trudy Muller in a statement to AllThingsD. “The research discussed theoretical vulnerabilities that would require Apple to re-engineer the iMessage system to exploit it, and Apple has no plans or intentions to do so.”

In other words, this is in many ways a semantic argument over the difference between can and could be. What Quarkslab’s research proves (I read the paper and admit I found it largely over my head — but I’ll accept Schneier’s vouching for its validity) is that Apple’s iMessage back-end could be designed to allow for Apple to intercept and read message content, and there is no way we, as iMessage users, would be able to detect it.

What Apple has said, and reiterated today, is that iMessage’s back-end is not in fact designed in that way — that there is no mechanism in the system for Apple employees to surreptitiously change the encryption key to allow for messages to be decrypted during transit.

Thus, I think Dan Goodin at Ars Technica took things too far in his report on Quarkslab’s findings, writing:

Contrary to public claims, Apple employees can read communications sent with its iMessage service, according to researchers who have reverse engineered it.

That’s not what Quarkslab proved. What they proved is that Apple could be, and that we as users have no way to verify cryptographically that they are not.

It comes down to Apple’s word.

If you believe or even suspect that Apple is lying about this, consider at least that Apple is taking an enormous risk by doing so. If they are in fact allowing law enforcement or the NSA to surreptitiously decrypt iMessage content, their corporate credibility will suffer an enormous, perhaps irrevocable loss if it ever comes to light. In the case of law enforcement, decrypted iMessage content used in a prosecution would necessarily need to be revealed as evidence in court. In the case of a secret agency like the NSA, it’s entirely possible that Edward Snowden is already in possession of proof of such a back door, and even if not, Apple would remain forever at the risk of another whistleblower revealing such a thing.

Leaving aside the moral implications of flat-out lying to their customers, I would think that if iMessage’s back-end were designed with a weakness exploitable by Apple as Quarkslab supposes, Apple would say or promise nothing with regard to iMessage’s susceptibility to server-side decryption than to compound that weakness with blatant lies to the contrary. To lie would be to take an enormous PR risk for a relatively small PR gain. I say “small PR gain” simply because I doubt most people who use iMessage even know their messages are supposed to be securely encrypted from end-to-end. I say “large PR risk” because if Apple’s statements regarding iMessage encryption are eventually discredited, the backlash in the press will be severe (and justly so).

(Sidenote: My understanding is that Apple does not store iMessage message content on its servers. Even in encrypted form, iMessage data is only in Apple’s hands while in transit. Once delivered, it’s gone. This is by design. In a discussion with a source at Apple earlier this year, I was told that some time ago word came down from the top that wherever possible,¹ Apple’s messaging services should be designed in a such a way that there is nothing — or, at least, as little data as possible — stored or logged for law enforcement agencies to ask for. And the same is true of decrypting content while in transit. An uncynical take on this: Apple cares about customer privacy and knows that storing nothing at all is the only way to protect it. A cynical take: Apple seeks to wash its hands of any possible involvement in such matters.)

Here's the bad news: the World Wide Web Consortium is going ahead with its plan to add DRM to HTML5, setting the stage for browsers that are designed to disobey their owners and to keep secrets from them so they can't be forced to do as they're told. Here's the (much) worse news: the decision to go forward with the project of standardizing DRM for the Web came from Tim Berners-Lee himself, who seems to have bought into the lie that Hollywood will abandon the Web and move somewhere else (AOL?) if they don't get to redesign the open Internet to suit their latest profit-maximization scheme.

Danny O'Brien from the Electronic Frontier Foundation explains the wrangle at the W3C and predicts that, now that it's kosher to contemplate locking up browsers against their owners, we'll see every kind of control-freakery come out of the woodwork, from flags that prevent "View Source" to restricting embedded fonts to preventing image downloading to Javascript that you can't save and run offline. Indeed, some of this stuff is already underway at W3C, spurred into existence by a huge shift in the Web from open platform to a place where DRM-hobbled browsers are "in-scope" for the WC3.

We pointed out that EME would by no means be the last "protected content" proposal to be put forward for the W3C's consideration. EME is exclusively concerned with video content, because EME's primary advocate, Netflix, is still required to wrap some of its film and TV offerings in DRM as part of its legacy contracts with Hollywood. But there are plenty of other rightsholders beyond Hollywood who would like to impose controls on how their content is consumed.

Just five years ago, font companies tried to demand DRM-like standards for embedded Web fonts. These Web typography wars fizzled out without the adoption of these restrictions, but now that such technical restrictions are clearly "in scope," why wouldn't typographers come back with an argument for new limits on what browsers can do?

Indeed, within a few weeks of EME hitting the headlines, a community group within W3C formed around the idea of locking away Web code, so that Web applications could only be executed but not examined online. Static image creators such as photographers are eager for the W3C to help lock down embedded images. Shortly after our Tokyo discussions, another group proposed their new W3C use-case: "protecting" content that had been saved locally from a Web page from being accessed without further restrictions. Meanwhile, publishers have advocated that HTML textual content should have DRM features for many years.

Lowering Your Standards: DRM and the Future of the W3C