Why I don’t want to know your password

I’ve realized that over the course of my career I’ve had to cultivate a professional disinterest about some things.  You might even call it “learned blindness” – when I am helping people with a computer problem, I’ve developed a practice of not seeing certain things.

One of things that I don’t see – nor do I want to hear – are passwords.  They are other people’s secrets, like that spreadsheet the CFO has with everyone’s salary info.  (I’ve actually had to help someone with a spreadsheet like that, twice in my career.)  I don’t want to see that information – it’s the definition of “not any of my business”.

It sounds funny when I tell people that I don’t want to know their passwords… they trust me, after all, or they don’t think their password is very important.  Or maybe they share it with others anyway.  The best analogy that I have to explain this is that passwords are like gossip: people listen to gossip because they are curious about others’ secrets.

In most roles I’ve had, I possessed the master key to all of my organization’s data – I could, if I were “curious”, look at anyone’s email, access any of their files (sure, there’s computer code, but there are also pictures), or even eavesdrop on their phone conversations or web browsing.  In fact, because I’ve had responsibilities for monitoring email and phone systems, I see “traffic” – not the contents of email messages, but as I’m watching the logs I see calls and emails senders and receivers.

If you think about it, I can’t be curious about the data under my control because it undermines the trust that my colleagues have in me to protect it.  Being exposed to information that I have no need of is like being exposed to gossip – the only way to really be above gossip is to not listen, to refuse to be present when people are talking.

To even discern whether something supposedly “secret” is also “sensitive” means that I’m already hearing it.  So, that’s why I have a blanket policy of not wanting to be told secrets – like passwords – that I don’t have a need to know; because I might have the “ability” to find out, I want to train myself to not be interested.

One more thing: systems should be engineered so that secrets are minimized or securely shared.  For example, most applications that require a password use encryption to ensure that no one can see the actual passwords – all that system can do is take an input and reply that it matches the stored password or not. When you’re talking to someone who is an administrator, they can’t tell you what your passwords is – though they can change it for you, or change it themselves and then access your data.  But they can’t then change it back to what it was beforehand, so these actions are detectable.  I try to architect processes so that I don’t collect data that I don’t need – like authentication credentials.

It’s great that people trust me – even people who don’t like me very much trust my standards.  But discretion – keeping confidences – starts by not knowing them.

Happy IPv6 Launch Day!

IPv6 Launch Day – 06Jun12 00:00 UTC

My background may or not be all that unusual: I’ve picked up lots of things that I didn’t set out to learn; responding to topical areas that my employers wanted me to learn or following what I thought was interesting and what I was attracted to – that’s created somewhat of a patchwork of areas of knowledge.

One thing that’s been difficult, sometimes, is forcing my attention away from whatever is on fire today and learning new stuff.  As I’ve mentioned recently, I have had some great opportunities to get taken in different directions.

Here’s one: about two years ago, at a BBLISA talk, I finally got to learn about this amorphous thing off in the distance, IPv6.  Like a lot of technology, getting your arms around a new concept is trying partly because most education seems to be oriented towards those who are learning something wholly new for the very first time, as in how TCP/IP works.

This is what BBLISA is really great for: I know lots about the “current” IP already (“IPv4”); assume that I understand the protocol stack and how lots of services are implemented on it, please, and explain to me what is different and new.  That was an excellent session.

So, I put together IPv6 connectivity on and out of my home network, to the IPv6 Internet.  Last year, as World IPv6 Day approached, I decided that I wanted my externally-hosted personal site available on IPv6, too, so I set up a mirror with a new provider… this year, the whole site has been moved, including my mailhost (Dovecot/Postfix).  All that’s left is Amazon Web Services – (going to be making any announcements soon, AWS?) – which hosts some content (like images and large file downloads such as from my BBLISA presentation).

As of now, 06Jun12 00:00 UTC – it’s Launch day.  Today, the sites listed in the Launch site are supposed to be fully IPv6-enabled, and as they say “This time it is for real”.  I’m happy to be part of this.

Getting Things Done: OmniFocus

I like tools. As a technologist, you might say tools are what I do.  Not all that I do – but it’s an important part.  In the hope that some of the great tools I’ve found might be of interest, this is my first post about some of the most important tools in my bag.

In 1986, working as a consultant, I purchased a seemingly overpriced small notebook that promised to help me manage my time and become more efficient.  This system, called “Time/Design” occupied the same market as the “Filofax” and “Franklin-Covey” planners; T/D was from Europe and was being heavily marketed by one of those companies that I think of as “Sharper Image” wannabes.

It was rather expensive, as I recall, and of course once one purchased the “system”, well, it wasn’t going to update itself for the next calendar year.  But the people in the pictures looked “productive”, and I needed something, so I bought in.

Somehow, a few months later, I learned of a seminar on the system.  There was a workshop being given in Newton (Mass.), right down the road.  It also wasn’t cheap, but it seemed like it would be worthwhile and so I signed up.

That was my introduction to David Allen, who has gone on to write a number of books, starting with Getting Things Done and a practice called GTD; over the years he has refined the thinking and processes and spawned significant interest in implementing these techniques in software.

Initially, much of the work was to answer questions like “how do I use Microsoft Outlook/Lotus Notes to help me” in the context of GTD workflows.  However, several years ago, standalone applications started to arrive to serve as the framework for what you could casually call your “To do lists”.

The first one that I worked with extensively is one that I adopted, called OmniFocus, developed by The Omni Group.  The core of the product was initially developed as a set of scripts and templates for Omni’s OmniOutliner, itself a pretty neat tool for creating documents that are best expressed in an “outline” with a hierarchical structure.  As of today, OmniFocus is available for the Mac and iOS platforms, there’s robust sync technology across devices that I’ve come to rely on.

Why OmniFocus?  I’ve become enthusiastic about several OmniGroup’s products.  The principal reasons have to do with design, both the thought and care that have gone into workflow (especially for OmniFocus), but also because the same level of effort brought to the visual design of the applications.  I’ve learned that I’m a visually-oriented person; this characteristic seems to be echoed in Omni’s products.

What I think of as the core tenets of GTD are:

• A focus on determining the next action (physical) to move a project or task towards it’s goal.
• “Capturing” those tasks, the projects or goals they represent, and the commitments that underly them – out of your head and into an external, trusted device/place/list/system.
• Acknowledgement that we’re really not that good at multitasking; we’re best off concentrating on one thing at one time by delegating all of that “on our mind” to whatever system we have.
• A practice of periodically reviewing our goals, projects, and what we have completed.  Re-figure that next action for each of our goals and projects, and add it to the system.  Experience that little flash of satisfaction of checking off that “done” box.  Allow some creativity to creep in envisioning project outcomes.
• Understanding that there are contexts for taking those next actions: either location, the availability of certain tools (like Internet connectivity, or a phone), people, etc., and being able to figure out what can be done in the current context (I’m in the North End, what can I get at the store here?).

OmniFocus supports this process.  It makes it pretty easy to capture stray thoughts, roughly order things, assign contexts to tasks, review, and maintain a level of comfort that it’s all in there, safely.

I’ve found that there are a lot of people who will read a description of something like this, and think that it’s either unnatural, too much work, too contrived, or inessential.  I certainly respect those opinions; you might even make the analogy that there’s a certain level of faith in this approach and if you’re not feeling it – then none of this will be of any help.

However, for me and many others, this process has been useful.  Set aside, if you wish, the technology; the implementation is an individual project.  And GTD is not perfect, I have my own difficulties with it and keenly experience some of its shortcomings – but if this catches your attention, you might find it – and apps like OmniFocus – well worth your time to research.

References:

1. David Allen, DavidCo website.
2. Getting Things Done, Amazon/Paper, Amazon/Kindle
3. OmniFocus from The OmniGroup.
4. Merlin Mann’s 43 Folders site.
5. GTD Times site (“The hub for all things GTD”, from David Allen).

What Systems People Do

When many people think of systems people – for example, systems administrators, or IT staff – they wonder what we spend our time doing, when we’re not sitting with our customers and actively working to help fix what’s broken.

While in larger organizations there are people whose job descriptions read “IT Support”, many of us have significant other responsibilities.  What are we doing when the alarm bell (or telephone, or ticket system) isn’t ringing?

Often, the answer is that we’re building things.  This time breaks down partly to projects that we’re tasked to do – say, installing new hardware or software, or network upgrades.  But I’ve had a nice opportunity to consider what happens without tickets, phone calls, or support tasks.

What I’ve concluded is that I think about two things:

First, there’s what’s new to learn.  Arthur C. Clarke once wrote that “the well-stocked mind is safe from boredom,” and a corollary to this might be that one who is hungry to learn can never be sated.  It’s amazing to me how much of the important technology in the IT world is available for free, either because it’s open source, or because there are formal programs allowing access to technology for free or at significantly reduced costs though developer/support programs.  I’m thinking of much Oracle technology (free) and Microsoft systems (available at a nominal cost) – for purposes of evaluation, testing, etc. (effectively, “non-production use”, depending on the specifics of the licenses).

In addition, with the commoditization of the vast majority of computer hardware, courtesy of Intel, along with virtualization platforms, it’s pretty easy for a curious technologist to get exposure to a wide variety of applications and operating systems.  There’s also “the cloud” – in which one can “rent” a virtual server for $.08/hour (Amazon) or $19.95/month (Linode).  There are others, of course, but these are examples of what I personally use.

The second thing that I think about is the question of how to understand the ways in which things break – or to put it another way, what lessons one can learn from outages, errors, breakdowns, and failures of hardware, software, networks, applications, security, or human organizations.  What this means in practical terms is an emphasis (in my time and effort, at least) in thinking about how to monitor systems, traffic, the environment and myself.  What can I instrument?  What can I learn about a complex collection of systems and applications by collecting data?  What patterns can I see, and what can I predict?

“Paying attention” is essential to understanding what we’re doing.  Having the time to improve how I do this has been an experience that has given me a better perspective on how to be better at the work I do.

SELinux: A belt to go with my suspenders

The old adage is that if you really want to keep your pants up, you’ll have a belt and suspenders.

Word for the day – “Interrotron”

I was taken by a short film (okay, short video, if you insist) referenced in today’s New York Times app.

It’s about a man standing along the route of the Kennedy assassination, who was carrying (and under) an umbrella on that sunny day in November, 1962.  A thought-provoking production by Errol Morris, and not what you might assume.

What really caught my eye, though, was a credit at the end of the video for the “Interrotron Tech”.

A what?  It turns out that rather than an adjunct to waterboarding (what was suggested to me by the name), it’s a variation on the teleprompter where the subject of the interview sees the image of the director (that is, the person performing the interview) in front of the camera lens the same way a person giving a speech or working a newscast sees text – and the setup is replicated for the director, who sees the interview subject.

The point of this?  Says Morris, this actually allows a true face to face interview – eye contact – through the camera.  The conversation is carried on by two people who are looking at each other in the eye, just as you and I might when talking, but the interviewee is looking at us.  Morris invented this, and has used it for several of his works.

What a fascinating word, though.

Fixing a MacSlowdown

Here was an interesting issue.

Take this test: one slow Mac.  Why?

Deja Vu

I’ve been told that as a new parent, there is an eerie moment the first time when they find themselves saying something to their kids – a feeling as the words come out of their mouths – the realization that they are saying to their kids exactly what their parents said to them in the same circumstances, 20 or 30 years ago.  They have an immediate inescapable realization that they are “becoming their parents”.

I had a similar technological moment not long ago, talking to my parents-in-law about Facebook.  They were not entirely clear on what Facebook is, or why people use it.  I explained as best as I could the concept of “friend” as a verb; and wrapped up my thoughts this way:

     “Facebook isn’t really the best way to communicate with me.  I’m not on it very often; in fact I find that I really don’t have the time to spend to check in with it frequently, and don’t feel the need to do so either.”

Boing!  As I was expressing this thought, my brain was pulled back to the mid-1990s.  I had been enthused about a new technology called email, and had gotten my father set up on America OnLine. And now  in 2011 I had the stunning feeling that I’d heard this before… my father explaining that he just didn’t have time to check the computer every day to see if he’d gotten any messages.  Why would he want to do that, he said, as after all people could always call him on the phone if they wanted.  And I, in my late 20’s or early 30’s couldn’t communicate the excitement, no, the necessity of this new (to him) way to keep in touch.

It’s 2011; we all use email and the web, but the composed-form email message is “history” to more and more of the Millennials that I encounter.  It’s txt and Facebook and Twitter now.

Is it incipient obsolescence to argue about whether this is true, desirable, or meaningful?

iPad Time

What do you know, I’m actually on the vanguard for once.

I skipped the first generation of the iPad because “circumstances” were not propitious for the investment in an unknown technology.  Or, to put it another way, I simply didn’t have a way to justify the cost… with uncertain “benefit” to counter $500-$800 in outlay.

(Compare and contrast with my my lack of an iPhone – mostly a result of my strong dislike of at&t and its predecessors – although not of course helped by the costs for the device and the required data plans.)

But having passed up the iPhone, I did decide that the second-gen iPad was a worthwhile investment.  Made a bit easier by paying with our 21st century equivalent of S&H Green Stamps, credit card points.

So, I admit to scheduling a trip down to the Back Bay on 11 March, the day of the unveiling, and I don’t have to describe for anyone the sheepish “late to the party” feeling of seeing the lines down Boylston Street block, the a block of Fairfield, and then a significant remaining queue down Newbury.  Okay, yes, I didn’t get there for almost a full hour since the lines opened, but still…

As my friend Linda might have put it, “dontcha want it just a bit too much?”.  She would, of course, be correct.  But I had to do something…

Here’s the question I asked (ignorant, of course, as to how constrained the supply would be, even weeks later): how long am I willing to stand in line for this?  Seriously, though I thought at the time the choice was only between waiting a few more days, if I wanted one more quickly was I willing to wait?  And if so, what would be the best strategy?

Here is what I decided: I would be willing to experience the delight of cooling my heels for 90 minutes, but no more.  After all, I’d never been at an Apple launch before… but given what I saw that Friday, I suspected that any Saturday line would be seriously longer than that hour and a half.

The optimization I arrived at was that I would spend that 90 minutes waiting for the store to open Saturday morning.  I would get there at 0830 for the 1000 opening; if the line then seemed to me to be more than minimal I would just forego the thrill.  (I did make one adjustment: normally I would never drive downtown, but I realized that with a 20 minute investment in an easy drive I could cut my losses if there turned out to be a raving horde.)

There was no horde.  I got there a bit earlier than planned (because of the drive vs. the T), and found myself #15 in line.

It turned out to be exactly two hours to wait and then complete the transaction, getting just in under the parking meter.  Good strategy – and pretty happy customer.  I’m not usually the guy with the newest, shiniest kit, but for once it’s nice to be there.

Fun in the Cloud – Backing Up – Part 4

Simple Sync to the Cloud

Keeping backup sets in sync

The last part post described my implementation of rsync into Amazon Web Services (AWS), with storage on the Simple Storage Service (S3) and an rsync target server supported by Elastic Compute Cloud (EC2).

So, that’s it, right?  This can support any sort of data; along with a mirroring function it should be sufficient.  And that would be correct, but we’re not done yet.