Honeypot.net

Hi kid! You don’t know me, but I’m one of those “Internet expert” kind of guys they interview when something bad happens. I won’t bore you with the details, but let’s just say that I make big computer systems for a living and I know how they work.

I’m not your mom or dad, or a teacher, or your church leader, or your coach, or a cop. I don’t know you, either, and honestly, I don’t care about you personally so much that I’d want to scare you or exaggerate things or otherwise lie to you.

I love the Internet, and I’m pretty proud of this amazing place that my friends and I have built. There’s a lot of great stuff on it, and I truly think it’s one of the best things that people from all over the world have ever come together to create. I think we did a pretty good job, for the most part.

The thing is, it’s also easy for bad things to happen on the Internet. I’m not talking about stuff like child predators or terrorists or hackers trying to steal your iTunes credits. Yeah, those things exist. But yes, the news exaggerates them a lot to scare you and to make you want to watch more of the news (see how that works?). I don’t want to do that. The truth is, you’re way more likely to have trouble from the wrong people seeing things you’ve written or pictures you’ve sent than you are from any Stranger Danger.

Social networks are awesome. I use the same ones you do - and some that you don’t even know about yet - to talk to my friends the same way you talk to yours. I think they’re great. However. Every single one of them tells the same lie: that you can click a “keep all my stuff private!” checkbox and all your stuff will stay private. If you only hear one thing I’ve said today, let it be this:

They. Are. Lying.

Oh, they don’t mean to. The people who made Facebook and Twitter and WhatsApp are smart people who try awfully hard to do a good job. However, making giant computer systems like that is super difficult and it only takes one itty bitty mistake in a giant tangle of a million moving pieces for it all to break. When you see a setting like “only share this with my friends”, what it really means is “should we try to keep this private and hope that we did everything 100% correct and didn’t screw something up somewhere?”

But none of that really matters anyway, not when your “friend” can take a screenshot of your messages on their phone. Say you just told your BFF about your crush. You checked the little “don’t share this!” box and the computer guys did their job and the privacy stuff works just like it’s supposed to. And because they think it’s funny, your BFF clicks the buttons to take a screenshot so they can tease you about it later. Guess what: now there’s another copy of your message, but this one doesn’t have that little “don’t share this!” box next to it.

The rule in computing is “if you can read it, you can copy it”. There are some smart people who waste their time trying to break that rule so that you can’t make copies of movies or music or video games, but, well… did you pay for every one of those songs on your iPhone? Yeah, thought so. That’s what I mean, though. If it’s easy to copy songs and movies and video games, how hard is it to copy a screenshot of your text message conversation or - ahem - one of “those” pictures?

So after all that, here’s what I tell my own kids:

• If it’s on the Internet, everyone can see it. No exceptions. Everyone. I’m saying this as one of the guys who helped make the Internet. Trust me on this one.
• Do not put stuff on the Internet if you don’t want everyone to see it.
• Before you put stuff on the Internet, imagine who the worst possible person to see it in the entire world would be. What if your teacher read it? What if your mom or dad saw the picture? If the answer is “oh, wow, that would really suck”, then don’t put it on the Internet.
• If it’s on a computer or cell phone or iPad, it’s on the Internet. You wouldn’t believe how many ways there are for a note or photo to get automatically backed up or copied around to some computer somewhere that you don’t have any control over.
• This one is mainly (but not only) for girls: odds are, some day he won’t be your boyfriend anymore. Do you want a pissed off ex-boyfriend to have “those” pictures to share at school?
• Don’t. Reuse. Your passwords. I read the news stories you don’t, the ones about how some instant messaging company had their password database hacked into and stolen. That means someone has a whole list like “CoolKid23 uses the password MyDogStinks”, and then they go around to other websites and try to log in with those same usernames and passwords. Make up different passwords for each website and chat program you use. Write them down on a piece of paper and leave it at home if you have to, or use a “password manager” program to do it for you. Yes, I know this sounds paranoid and geeky. But I’m telling you this with my hand on my heart: this is important. It’s something you have to do. It’s a pain in the butt, but that’s just the way it is.

Have I scared you? If I did, I’m sorry. There are people who want to scare you because that’s how they think they can get you to listen. I’m not one of them. But I do want to tell you the truth about how things on the Internet actually work. This is important stuff, and it’s only going to get more important as we share more of our lives with our friends on the Internet.

I’m still proud of this great big network we’ve built, and I use it every day of my life. The Internet has a lot of exciting things to offer. Use them and have fun! Just be smart, and be a little suspicious before you send a message or a picture. Don’t share the things you don’t want the whole world to see.

OK? OK. Glad we had this talk. Now do your homework.

This is my letter to the FCC on September 12, 2014 regarding the upcoming net neutrality decision making process:

I am a Comcast customer, and I am paying them for a 100 million bit per second connection. Comcast has a monthly data cap of 300 billion bytes (or about 3 trillion bits) per month. At the speeds I’m paying full price for, I can use up my entire monthly data allotment in about 8 hours.

More simply, my monthly Comcast payment entitles me to use my Internet connection at full speed for one third of one day per month.

Esteemed colleagues, I find it disingenuous that Comcast and their peers claim that they need to charge more to carry the services I want to use, all while constricting my paid usage to one ninetieth of my connection’s capacity and raking in record profits. There is simply no fiscal credibility to their claims and I urge you to look upon them with due skepticism.

The FCC has received millions of letters supporting net neutrality rules against Internet slow lanes. Most of these have been form letters written by various citizen-friendly organizations and submitted by casual site visitors. Most of the individually written letters are various restatements of why net neutrality is important. All of those are good, but it’s also important to remind readers of these letters that anti-free-market groups like NCTA and its constituents have no legitimate counterarguments. They claim to need Internet slow and fast lanes to make money, but the industry makes huge amounts of money while delivering some of the worst Internet service in the developed world.

Comcast earned 3.3 billion dollars in net income in the second quarter of 2014, all while allowing customers to use only one ninetieth of the utility they’ve paid for. The only valid explanation for their strident opposition to net neutrality is sheer greed.

No good article about the Bay Area misses jokes at hipsters in their hoodies, whether biking through The Mission or chairing board meetings in The Valley. It’s an easy laugh and a nodding wink to your audience to assure them that you’re on their side, that you know how silly grown adults look in their kiddie jackets. But consider:

• San Francisco is walkable, and people take advantage of it. My stroll from the bus terminal to my office is about a mile, and the sidewalks teem the whole way.
• Layering is crucial. The weather changes rapidly from warm to cold, gray and windy and then back. Clothes have to adapt from comfortably light to guarding from the elements quickly and easily.
• The city is humid. A light sweat from walking stays on you, and nylon clothes become waterlogged and sticky within blocks.
• The city is windy. Synthetic fleece jackets are great, until a breeze picks up and cuts through the coarse cloth. I’ve never been so cold as when I was near the shore in a thick fleece.
• Sun gives way to drizzle in minutes. Between the rain and the wind, it’s always smart to pack a hat.

Distilled, that means the ideal outerwear is of natural fiber to let sweat through while keeping wind out. It has a zipper and can go from breezy to windproof. It has a hat.

You know: a hoodie.

The humble jacket is a perfect fit for the local climate, where the weather is rarely great but is never bad. They’re warm in the winter and protective in the summer. You can buy one for a few dollars from street vendors, or spend more for a handmade work of urban art.

Making fun of a San Franciscan for wearing a hoodie is like teasing a Minnesotan for wearing a coat and scarf. Yes, we love our hooded jackets. Why shouldn’t we?

Originally published on the Crittercism Engineering Blog and reprinted with permission.

by Kirk Strauser on April 8, 2014

CAP theorem hates you and wants you to be unhappy

Some guy who isn’t fun at parties came up with the CAP theorem, which basically says it’s impossible to be consistent and available at the same time. In short, things will break and clients will lose access to a storage backend, or units in a storage cluster will lose the ability to talk to their peers. Maybe those servers are crashed. Even worse, maybe they’re up and running but a network outage means they can’t reach each other, and each part is still accepting writes from clients. Our enemy, CAP theorem, says we have to choose between:

• Keeping our data consistent, at the price of not being able to make progress when parts of the database cluster are unavailable.
• Keeping the database cluster available, at the price of some parts of it being out of sync with others and resolving any conflicts later.

Consistency brings pain

In any case, we have to decide what happens when we want to write to a record. Let’s assume for demonstration sake that a record is a bag of opaque data that the backing store doesn’t really understand; imagine a JSON blob, or a bit of XML, or whatever other datatype your favorite database doesn’t natively support.

Let’s also assume we have a consistent database. Either it’s a single server that’s running or not running, or it’s a cluster that only accepts requests if all nodes are online and synchronized. In short, we can always trust our database to Do The Right Thing.

Here’s how consistent workflows evolve from the most innocent of intentions.

First attempt: blind writes

We want to write a record, so we write it! Easy-peasy.

1. Write out an entire record
2. Profit

Second attempt: read-update-write

Ouch! Two requests want to update the same record. Both of them write out its entire contents, but only the last one wins.

1. Request A writes out {"foo": "bar"}
2. Request B writes out {"baz": "qux"}
3. Request A cries salty tears
4. Request B gloats and gets punched

That’s not good. The answer, then, is surely to read what’s there, update it, and write the results back out:

1. Request A fetches the record with its initial value of {}
2. Request A updates the record to {"foo": "bar"}
3. Request A writes the record with the its new value
4. Request B fetches the record with A’s value of {"foo": "bar"}
5. Request B updates the record to {"foo": "bar", "baz": "qux"}
6. Request B writes the record with the combined value

They shake hands and go home. And at 2AM, the Ops pager goes off because every write requires a read to get the pre-existing value. But let’s pretend IO is free and infinite. This algorithm is chock-full of race conditions. At our scale, here’s what’s going to happen many times per second:

1. Request A fetches the record with its initial value of {}
2. Request B fetches the record with its initial value of {}
3. Request A updates the record to {"foo": "bar"}
4. Request B updates the record to {"baz": "qux"}
5. Request A writes the record with only its new value
6. Request B writes the record with only its new value, overwriting A’s

And now we’re right back where we started.

Third attempt: locks everywhere!

Looks like we’ll need to lock each record before updating it so that only one request can mutate it at a time. We care about uptime so we have a highly available distributed locking system (ZooKeeper, Redis, a highly motivated Amazon Mechanical Turk, etc.). Now our workflow looks like:

1. Request A acquires a lock on the record
2. Request B attempts to acquire the same lock, but fails
3. Request A fetches the record with its initial value of {}
4. Request A updates the record to {"foo": "bar"}
5. Request A writes the record with only its new value
6. Request A releases the lock
7. Request B attempts to acquire the same lock, and succeeds this time
8. Request B fetches the record with A’s value of {"foo": "bar"}
9. Request B updates the record to {"foo": "bar", "baz": "qux"}
10. Request B writes the record with the combined value
11. Request B releases the lock

That actually worked! Of course, it took two reads and two writes of the database and fives calls to the lock manager and Ops wants to set fire to your cubicle because their call duty phone won’t stop buzzing.

But let’s assume that we have a free and infinite lock manager. What happens if Request A never completes the transaction and releases its lock, maybe because of network problems, or the node it was on died, or it couldn’t write to the database, or [insert your own pet scenario here]. Now we can’t make progress on B’s request until the lock expires, or until we break the lock and potentially overwrite A’s updates. For all our efforts, we’re still not in a much better place than we started.

Side note about the locking manager

Any distributed lock manager has to solve all of the same problems we’re listing here. Even if we use this pattern, we haven’t made the root problem go away: we’ve just shifted it to another piece of software. The CAP theorem means that a lock manager optimized for consistency has to sacrifice availability, so in the event of a network outage or failed locking manager node we still can’t get any work done.

But eventual consistency brings joy and unicorns!

Consistency is critical for many reasons. I’d much rather queries to my bank be slow or unavailable than incorrect! There are times and places when we want the properties that consistency buys, regardless of its price.

But there aren’t many of them at our scale.

What we want is eventual consistency, or a promise that the database will make its best effort to make its records return their current values. This pattern extends to both the database we use to store our records, to the way in which we generate and process those records.

Solution: journaled updates

Instead of treating our record like an atomic chunk of data, we’ll treat it like a list of atomic chunks of data representing updates that clients want to make.

1. Request A appends its update of {"foo": "bar"} to whatever happens to already be in the record
2. Request B appends its update of {"baz": "qux"} to the record
3. Much later, if ever, Request C fetches all the values from the record and combines them into a final data structure. In pseudocode:

def materialize(query):
    result = dict()
    for key, value in query.records():
        result[key] = value
    return result

In our example, that would fetch the list of updates [{"foo": "bar"}, {"baz": "qux"}] and combine them into a single record like {"foo": "bar", "baz": "qux"}. This is a very fast operation for any sane amount of updates.

Our primary usage pattern is “write many, read rarely”. Most of the events recorded by our system will never be viewed individually, but might be used to calculate trends. This solution allows us to trade a small (but fast and easy) bit of post-processing for a huge bit of not having to worry about requests clobbering each other, locking semantics, or mixing reads with writes.

Ordering is still hard

This solution isn’t magic, though. It doesn’t define how to reconcile conflicts between updates, and we still have to make those decisions.

Time and time again

The simplest method is to store each record’s timestamp and replay them in order. However, it’s impossible to guarantee ordering between timestamps generated across more than one host. Two database servers might be off from each other by a few seconds, and NTP only seems like a solution until you’ve actually tried to count on it. The one situation where this is feasible is when requests to update a given record are all generated by the same client. In this case, we can use the client-generated timestamp to reasonably represent the correct ordering of updates.

Understand our data

Another approach is to make smart decisions about the data we’re storing. Suppose a certain key, foo, may only ever increase. Given a set of updates like [{"foo": 23, "foo": 42, "foo": 17}], the correct resolution would be {"foo": 42}. This requires an understanding of the data, though, and isn’t something we’d want to pursue for customer-generated inputs.

TL;DR

Math says you can’t have both consistency and availability. At our scale, availability wins the argument and eventual consistency carries the day.

I’m a sucker for the idea of ritual. When I learn about a traditional, labor-intensive practice like shining shoes, oiling boots, or a complicated car washing regimen, I’m always drawn to try it myself. I imagine having the same meditative experience as the person convincing me to try their routine: feeling a connection to my ancestors, appreciating the finer things, tasting the rewards of patience, and such. So when I read an article about wet shaving a year ago, I could hardly wait to get started.

In practice, though, I hate ritual. I’ll pay a few bucks to have someone else shine my shoes. San Francisco Bay Area climate isn’t very hard on boots, whether I’ve diligently oiled them or not. Automatic car washes are popular for a reason. Basically, I run out of patience for things that take too long just for the sake of taking too long.

One recent morning, I found myself wondering if I actually enjoyed wet shaving or if I’d be better off going back to a can of foam and an 8-bladed disposable razor. Millions of guys do it the new way, after all - should I rejoin them?

No. For me, wet shaving is clearly better for two specific reasons:

• It’s way cheaper. It’s like the laser printer business model of charging more up front but offering dirt cheap supplies. After the initial purchase, consumables cost less than $10 a year.
• I haven’t had a single ingrown hair since I started. Modern razors always leave me with a few bumps on my neck and cheekbones, but that problem has completely disappeared.

Yes, it takes longer than I’d like and still carries more trappings of ritual than I care to think about. Still, it’s a little luxury that’s measurably nicer and I don’t think I’ll give it up.

I use and happily recommend:

• Merkur 34C heavy duty razor
• Tweezerman shaving brush
• Art of Shaving classic stand
• Astra Super Platinum blades
• Art of Shaving pre shave oil

Update:

Garrick Dee wrote another nice introduction to the subject at the Grooming Essentials blog.

I probably sound like I gripe all the time, but that’s really not what I’m like. I’m an optimist and happy by nature. It’s just that I have high expectations for how things could be and I’m disappointed when I see people fall short of their potential. I don’t complain about companies that are trying their best but fall short. I call out the ones that could be so much better but don’t seem to have the desire to see it through.

Update: 2021-05-27

This is still getting traffic for unknown reasons. Today, in 2021, the problem is long solved. DEVONthink 3 syncs perfectly with itself and with DEVONthink To Go. Again, this is purely historical and not a reflection of the state of things today.

Also, I have no idea why this post is suddenly so popular again. Help me out and let me know how you found this page? I’d sure appreciate it!

Update: 2016-09-17

In July 2016, DEVONtechnologies released DEVONthink 2.9 with an entirely new sync engine. It’s like a brand new program and synchronization has been flawless. Although I’ve only been using the new version for a couple of months now, it feels better, faster, and deterministic in a way the older ones never did.

At this point, I’m cautiously optimistic that all of the problems I wrote about below are fixed and obsolete. My fingers are crossed!

I’m keeping this post up for historical reasons but I don’t think that it’s relevant anymore.

Q: I have DEVONthink Pro Office and I want to sync my home and work computers so that I can access documents in both locations. How can I do that?

A: You can’t. Give up. It won’t work reliably.

Q: No, really. How do I do that?

Longer A: Seriously, give up. It doesn’t work and you’ll just get angry and frustrated. Trust me.

I use and love DEVONthink Pro Office as a document manager. Pretty much every piece of information I come across goes into it, whether scans of utilities bills, PDFs of software manuals, Twitter messages I starred, or the complete collection of RFCs. If there’s any chance I might ever want to find something again, DTPO stores it. Its most important feature is the uncanny ability to return exactly the search results I want when I need to find something. Second only to that is its AI-powered “see also” feature: “you seem to be reading up on an obscure technical subject. You might also be interested in the author’s blog posts about it, some guy’s master’s thesis on the main algorithm, and the popular alternative version written by a teen living in a favela in São Paulo.”

It’s that good. And I’m still desperate to find anything else to replace it.

The main problem is that DTPO refuses - just flat-out digs its heels in and resists - syncing reliably for more than a few days at a time. The pattern always goes like this:

• I start off optimistic, determined that this time will be different.
• At home, I add a sync connection to Dropbox, or to my own WebDAV server which has been syncing OmniFocus and other apps successfully for years.
• I sync one of my medium-sized (2GB or so) databases to that connection.
• I select the Synchronize menu option and wait several hours as my data gets pushed up to the server.
• At work, I set up the same connection and import the database. Then I select Synchronize and wait a few hours as all my data comes back from the cloud.
• I use it for a couple of weeks until I start getting random sync errors that cause it to stop halfway through without copying across all my new documents.
• After going through all the troubleshooting tips on their forum (of which there are many because this seems to happen to a lot of people), I give up and resign myself to the dreaded “Clean Location…” button which deletes all documents off the remote server.
• I walk away from it for a few weeks so that I don’t throw my laptop out the window.

So I exaggerated a little. It is possible to reliably sync two machines running DTPO:

• Pick one to be the primary machine.
• Pick the other to be the secondary.
• Do all your editing work on the primary. When you’re happy with it, use rsync or some other file copier to nuke what’s on the secondary and make it identical to the primary, losing any changes you might’ve made there.
• If you’re at work and want to add a document, just email to yourself at home and import it into DTPO there later when you’d rather be playing with your kids, washing the dog, or doing anything else in the entire world.

That’s how you reliably sync DTPO. Anything else is just a ticking time bomb.

I had a wonderful experience buying new Rockport shoes from Brown Brothers Shoes in Alameda a couple of months ago, to the point that I wrote a gushing Yelp review and told all my friends to go there.

Oops.

My two-month-old Rockport shoes (which I wear only to work at my desk job) already need to be re-soled. The hard rubber heels have worn through so that now I’m walking on the soft foam cushion, and that can’t possibly last too long. I took them back to the same store and found that they’re a lot better at selling shoes than at helping customers.

First, the salesman said that it was probably because I wear arch supports in them. That would seem ridiculous even if they weren’t the insoles that I bought from their own store at their own suggestion. Next, he recommended a local shoe shop and sent me packing. I asked if they sold other, more durable walking shoes, like some I could wear from my bus stop to the office and still have them last more than two months. The salesman said that no, these are the best.

My shoes are in the shop now and I should have an estimate for fixing them by Monday. Hopefully it’ll be cheap enough that I can have them to wear for a few weeks while I shop for replacements. I don’t know what they will be, but they won’t be Rockports and I won’t be getting them at Brown Brothers.

In the process of moving to another state, we decided to sell my car to some friends. This turned out to be much harder than anticipated.

I admit that this is entirely my fault and I deserve to be made fun of for it, but we couldn’t find the title. It could be that the bank which financed the loan never sent it to us. It could be that it’s in our safe deposit box in our last city and that I’ll find it next month when I go back for the rest of our stuff. Or maybe I’m just a bad document caretaker and I lost it along the way. I don’t know. But the end result is that we don’t have the title and needed to have a duplicate issued before we can sell the car.

Late May

I called the county clerk’s office to ask how to apply for a duplicate title. The clerk was very helpful and friendly, and offered to look up the necessary information while I was on the phone. I gave her my car’s VIN and my personal information, and she came back with the unwelcome news that the bank still had a collateral lien on the car. I pointed out that I bought it used in 2000 and didn’t have a 12-year loan on a used Oldsmobile, and that I hadn’t been arrested for chronic non-payment of the loan. She laughingly agreed that I’d clearly paid it off, but needed a notarized lien release from the financing bank before she could issue a new title.

When I tried to find contact information for that bank, I discovered they had been acquired by another bank in 2004 and no longer existed.

OK. So.

Early June

I called the new bank, Regions, and explained the situation. They were more pleasant and easier to work with than I’d feared, but couldn’t find any information about my paid-off-9-years-ago loan from their subsidiary. They took all my information, though, and agreed to send a lien release if they couldn’t find proof that I still owed them money. That seemed perfectly fair and reasonable — from a bank! — and I sat back to wait for the letter to arrive.

It didn’t arrive.

Late June

I called Regions again. They were missing some information from the lien release application form (but weren’t sure exactly which information) and needed to re-file it. Given how nice they were and that I wasn’t even their customer any more, I didn’t protest or complain too much.

July

A couple of week later, the official, notarized lien release came in the mail. The VIN wasn’t quite identical to the one I gave them, but I hoped the county clerk would call it “good enough” and accept the note.

Now we were ready to apply for the replacement title. The state’s form required that Jen and I both have our signatures notarized, so on a sunny Saturday, we drove to a nearby UPS Store and paid up. We stuffed the lien release letter, the application, and a check for $14 in an envelope and mailed it to the county clerk’s office.

August

Not a peep from the county clerk. I didn’t rush things because, well, government office… But after a few weeks of silence, I called to check on the application.

The county clerk never received it.

The notarized application? The check? The necessary, certified original copy of the lien release? Lost forever to the mail system.

I asked the clerk if I could just take the car out back and burn it, as that might be the easiest way to dispose of it. She asked me to please not to.

I sheepishly called Regions again to explain the situation, apologize profusely, and to ask them to please send me yet another copy of the lien release. They cheerfully agreed to and collected all my information to fill out the request form.

I called US Bank to cancel my lost check and they told me there was a $30 change to stop payment on a $14 note. I told them not to bother and that I’d take my chances.

Now

And that’s where it stands. All I wanted to do is sell my car, and it’s involved the county clerk, three banks (one of them out of business), a UPS Store, and the post office. As of today, I’m no closer to the goal than I was two months ago.

As a side note: yeah, it was my fault for losing the original title (if I ever even had it). But I wouldn’t have been able to transfer the title to the new owners without the lien release anyway, so this was destined to be a pain in the butt in any case.

While I almost never buy extended warranties, conventional wisdom is that you should always buy AppleCare for an Apple laptop. You have up to a year after buying your laptop to purchase the extended coverage. At a high level, you’re basically buying an insurance policy for a piece of hardware with a specific serial number. Why does Apple make this so difficult?

I bought my MacBook Pro directly from Apple’s website. Here’s how AppleCare purchase should work:

• I log in to their store website.
• I view my order history and find my laptop.
• Apple has my MacBook Pro’s serial number on file with this order, and they also have a list of equipment covered by AppleCare. Since my laptop isn’t already covered, the site displays a “Buy AppleCare” button next to it.
• I click the “Buy AppleCare” button, choose to use my billing information that Apple already has on file, and click “Buy it now”.
• I get a confirmation email and move on to other things.

A lot of people bought their laptops through other sources, like local dealers, chain retail stores, and so on. Since Apple might not have any record of their purchase, here’s how that process should work:

• A customer visits Apple’s store website.
• Under “Mac Accessories”, they click “AppleCare”.
• They see a new form titled “What’s your Mac’s serial number?” and a link to how to find that information.
• When the user enters their serial number, the website looks up that part information and selects the appropriate AppleCare plan for their hardware.
• They add the plan to their cart and check out normally.
• The user gets a confirmation email and moves on to other things.

In reality, the process is far less polished and, well, un-Apple-like:

• I logged into their store website and looked for a process like the one I described above.
• When that failed to materialize, I browsed around until I found the AppleCare plans in the store.
• After some rooting around, I found the correct plan and added it to my cart.
• I was given the option of picking my plan up in an Apple Store or having it mailed to me. Wait, what? Pickup? Mail? For a warranty? Fine — mail it.
• After a couple of days, my AppleCare plan arrived in the mail. It came in a large cardboard box with a tiny cardboard box inside it. The tiny box contained some printed material and a registration number, but no Apple stickers or anything else I’d actually want.
• Per instructions, I went to a separate section of the Apple website and entered my laptop’s serial number (which they already have on file from when I bought it last year!) and the AppleCare registration number (which they already have on file from when I bought it a few days earlier!).
• I agreed to the Terms of Service, which were identical to the now-completely-unnecessary printed copy that came in the box.
• After submitting those numbers, Apple asked if I wanted my coverage certificate sent by email or by postal service. “Telegraph” and “carrier pigeon” were not available options, so I chose email.
• Apple informed me that I’d successfully completed my application, that my registration was now in progress, and that I would receive my certificate when they had finished verifying my registration.
• That was over 12 hours ago. I didn’t get any kind of confirmation email, but my browser history helped me find the status page so I could check in on it today. It’s still stuck at “Registration in progress”, presumably while Gertrude from Accounts finds my punchcard in the filing cabinet.

I’d probably shrug the ordeal off if I were dealing with Best Buy, Microsoft, or some other company not known for their customer service. But Apple? This was the opposite of the kind of experience they usually provide and I’m disappointed that the process was so clumsy.