For several years now I have tracked my effort using org-mode in
Emacs, for work and other projects. This has a variety of
advantages and disadvantages, but for some time now I have felt a
number of its disadvantages keenly. Specifically, it is somewhat
painful to check in and out of tasks on multiple computers, and the
reporting interface, while powerful, always sends me to the
documentation.
I have surveyed the open source time tracking field several times,
but never really walked away feeling like there was a tool
substantially superior to what I was using. Most tools either
required a web browser/server, weren't really targeted toward my use
case, or were no less complicated than org-mode clock tables.
Thus et was born. et provides a command-line
interface to time tracking and has limited support for distributed
operation. It is implemented in ruby and makes some effort to be a
good caretaker of your data. Tasks in et form a tree
structure, so it can be used to track several different domains as
subtrees; e.g., it can track both work and hobby projects
independently.
et is far from a finished project, and the initial release
version number (0.1.0) reflects this. However, it is far enough
along that I am using it as my primary time tracking tool, so it may
be useful to others, as well.
One of the features of the
Sputnik 3
laptop I'm using these days that no doubt contributes to its
impressive battery life is peripherals that can power down
substantially when not in use. This capability, coupled with the
general disdain for freedom and privacy that has dominated public
policy in the US (and a substantial part of the rest of the Western
world) since 2001, has been making me suspicious lately.
You see, when the sound card in this laptop powers up, something
(probably a change in DC bias in the amplifier circuitry, but I
don't know) causes the speakers to emit a quiet pop. Often
the proximate cause for this is obvious; starting a media player,
adjusting sound levels in the mixer, playing a video on
Hulu, etc. Sometimes,
however, it is not.
Along the lines of my desire to
jail Skype, I try to sandbox my
web browsing. I disable most plugins entirely, require positive
confirmation for the remainder to load, use different browsing
profiles for different authentication domains (e.g.,
Google+,
Facebook) and
different activities (work, personal), disable most prediction and
tracking features, and generally try to keep things tame. That
said, at the end of the day, I kind of have to trust my browser to
do its part. I use
GoogleChrome (which I realize has some
nontrivial degree of irony, given the foregoing; maybe I'll write
more about that later), which is of course not open source —
that means I can't even verify entirely what it claims to be doing
or even should be doing. Not that one can realistically do
so with an open source browser, either, as large as they are, and
particularly when installed as a binary package.
Of course, with the continued adoption of HTML5, more and more
complex functionality is available directly to web pages without the
involvement of plugins. This includes a fair amount of multimedia
capability. Even then, the browser is supposed to ask before it
allows access to anything but simple playback (and maybe for that,
too).
Therefore, when I'm poking around the web for whatever purpose, and
I hear that little pop sound, and I don't see any little
speaker icons in the Chrome tab bar or hear any audio, I get a
little bit concerned. If nothing is playing, why did the sound
system power up? Maybe something just opened the output
device, but maybe the browser isn't doing its job and the data is
going in the other direction! This happens with some
frequency — certainly several times a week, and possibly
several times a day. It's hard to pinpoint the frequency with much
accuracy, since virtually any ambient noise will mask the sound.
This sort of thing is the real damage of invasive anti-terrorism
policies. Some have recently been saying it's the damage done by
Snowden, or Wikileaks, or some other agitator, but the fact of the
matter is that those people didn't create the problems,
they just publicized them. Keeping us safe and keeping us afraid
don't have to be the same thing, and I really shouldn't have to
worry if it's Big Brother when my computer makes a funny sound.
A couple of years ago, had I expressed such sentiments, I would have
been accused of becoming a tin foil hat wearer. Today it's tough to
levy that accusation. That can probably be laid at the
feet of Snowden et al.
As recent news events have driven home time after time, secure
communications is a difficult yet important aspect of modern life.
What “secure” may mean differs from person to person and
from topic to topic, but certainly the typical person is somewhat
uncomfortable with the idea that anyone — and in particular,
large corporations or the government — might be eavesdropping
on their casual communications. There are exceptions, and there are
people who believe that only criminals should have something to
hide, but for the moment let's assume that some measure of secrecy
in private communications is warranted and/or desirable. This post
is a commentary on some of the technologies that make it possible
(or difficult or impossible, in many cases) to achieve secure
communications on an instant messaging (IM) network.
I'm going to play a little bit fast and loose with terminology to
help keep it understandable, but I also want it to be accurate. In
particular, when I say that communication is secure, I
mean private, specifically. For the purposes of this post,
that effectively means encrypted and using some sort of
authentication protocol to ensure that it's encrypted to the right
person. The details are out of scope.
Please contact me if you notice
any particular discrepancies or incorrect statements, either arising
from loose terminology or other errors.
First, where I'm coming from: I believe that essentially all
communications should be secured, and I believe that that security
should be very strong. By “very strong,“ I mean that it
should be effectively impossible for any third party to eavesdrop
without the acquiescence of a party participating in the
communication. I have a fair amount of history in computer
communications. I am a long time developer on the Pidgininstant messaging client
and related software. I am on the board of directors for
Instant
Messaging Freedom, Inc., a
non-profit organization “whose goal is to support free instant
messaging software.” Instant messaging is
important to me as a communication technology filling the gap
between real-time spoken communication and e-mail.
Types of IM security
There are a number of ways in which an IM conversation can be
"secured", and not all of them have the same properties. First,
there is using a secure connection, such as SSL or TLS
between your computer and your IM service's computer. Second, there
is end-to-end security, such
as Off-the-Record Messaging
(OTR). Then there are
additional, more complicated options that we won't discuss —
but they basically break down to a combination of one or the other
of the above, or one of the above with a different remote endpoint.
(\textit{E.g.,} end-to-end security between you and a remote user's
IM server to query her current status.)
Secure IM connections
A secure connection to the server protects your connection from
eavesdropping on the local network and the path between you and your
IM service (provided that it's done correctly), but it does not
protect your conversation from the IM service itself and it does not
tell you anything about whether the user you're chatting with is
using a secure connection. Despite these weaknesses, a secure
connection to the server is critically important, because
it protects a large amount of private information. Things like
buddy lists, status updates (online, offline, away, etc.)
from your buddies, and your own status updates pass through this
connection and are not necessarily targeted to any specific other
user, which makes end-to-end encryption difficult.
This is the limit of security offered by most commercial IM
services. There are a few exceptions, like AIM's encrypted IM, but
often they have a similar effective security model — for
example, the only proof that the encrypted channel you're talking on
is actually terminated at the remote user (and not the IM service's
servers) is a certificate signed by ... the IM service itself. (The
details of why this is not sufficient are outside the scope of this
post. Maybe I'll write some more on that later.)
End-to-end security
End-to-end security protects your communication from
eavesdropping all the way to the other user. If some
person or organization wants to read your messages, they have to do
so at your computer or your interlocutor's computer. There are a
small number of protocols that support this directly, but mostly not
in a particularly useful way (see the discussion of AIM encrypted IM
above).[1]
The usual solution for end-to-end encryption is a third-party
protocol carried on top of the IM session. There are several such
protocols, but by far the most popular is the previously-mentioned
Off-the-Record. OTR
provides end-to-end encryption for two-party conversations with
authentication of the remote user and a variety of desirable
encryption protocol characteristics. (It also
provides repudiability for situations where that may be
important.)
What end-to-end security cannot provide is protection for
all of the stuff that's intended for a very broad
audience.[2] Such
data (things like away messages, online status, and buddy lists) is
typically [3]
handled by the service's servers on behalf of its users, in such a
way that necessitates more-or-less trusting the servers with the
information. (This is a reason not to put sensitive information in
your status message!)
Secure connections with end-to-end security
Given the individual limitations of these two forms of data
security, we arrive at the inescapable conclusion that, for instant
messaging services, they are complementary rather than
redundant or simply unrelated. Secure connections to the servers
provide best-effort protection for group chats, administrative
information, and metadata, while end-to-end security provides strong
protection for conversation content.
The pros and cons of federation
Traditional IM networks are monolithic, walled gardens — if
you want to chat with a user on the network, you get an account with
the single service provider for that network. There have been
limited exceptions to this over the years (e.g., MSN Live
Messenger and Yahoo! Messenger offer(ed) some degree of
interoperability), but for the most part, not only have networks
been incompatible, there have been sole providers within those
networks.
This kind of structure means that, while your metadata and
administrative information are only ever managed by a single entity
(the monolithic service provider), that service provider also
sees all of the related metadata etc., and it's
necessary some giant faceless corporation. That corporation stores
your buddy lists, knows when you talk with whom, knows when you're
away or idle, and all kinds of other behavioral information.
Moreover, it has you in a lock — if you want to talk to your
buddies, you have to use its services.
The alternative to the monolithic single-provider network is
a federated service. In a federated service, multiple
(possibly unrelated) service providers cooperate in a network tied
together by a common protocol, allowing users of different service
providers to interact with each other without worrying about whose
service is provided by whom.
In a federated structure, you still have to trust your
service provider with all of your metadata and administrative
information, but you don't necessarily have to trust any of
the other service providers in the network. In fact, in
the general case, most of them don't even know you exist! Some
portion of your data will necessarily be shared with the servers
your friends and interlocutors are associated with, but you can
scope that sharing to a greater or lesser degree. On the other side
of the coin, you also have to place at least a small amount of trust
in third-party providers with whom you have no specific
relationship, if you want to talk to people on those providers'
servers.
The quintessential federated network
is XMPP, previously known
as Jabber. XMPP is a widely federated network,
wherein anyone can run an IM server and become a service
provider for other users. Conversations between users work a lot
like email; if I want to chat with you, I send a message to my
server, it forwards it to your server, which forwards it to you.
The return path is the same in reverse. Not only can anyone put up
an XMPP server, but the protocol is entirely open and
well-documented, so there are literally dozens of server
software implementations and thousands of providers already in the
network. Those providers range from large, commercial entities
(such as Google's Google
Talk, now known
as Hangouts) to tiny
servers serving just one user.
The huge benefit of federation is the freedom to choose your
service provider. Moreover, to change that service
provider. With an open federated network like XMPP, you can even be
your own service provider if you so desire. That's a kind
of communications freedom that no monolithic provider can ever
provide, by definition.
It is my opinion that the federated structure is a superior
solution, security, privacy, and freedom-wise, to old-style
monolithic IM networks. The majority of your sensitive data
(administrative information, complete buddy list, etc.) is
kept and managed by only one entity, and is parceled out to
third-party entities only as required to provide the services you
specifically request. In the specific case of a closed group of
users (such as a corporate or organizational server), it may be
contained entirely. I am also a strong advocate of open standards
which federated solutions tend to require (to make federation
possible), and which XMPP certainly provides. The ability to pick
up your data and move it to another service provider with limited
(or nonexistent) loss of functionality is an extremely powerful
argument for the freedom of a federated solution.
Today's best practices
The foregoing basically points to a simple best practices
recommendation for IM freedom and security: use XMPP, find a server
you trust, ensure that you're using TLS encryption, and employ an
end-to-end security solution like OTR when it matters.
(Unfortunately, without complete penetration of end-to-end security
solutions, “when it matters” is the best we can do.
Even then it can be hard to achieve!) Today, with the availability
of a number of large XMPP service providers with federation and open
registration
(Google,
DuckDuckGo,
Jabber.org,
or dozens of others),
as well as many fine XMPP clients (including, of
course Pidgin, finch,
and Adium), getting an XMPP account
and finding your friends is relatively painless. Many of them will
already be available if you simply add gmail address as a buddy in
your XMPP client.
Secure connections are not yet provided by all XMPP servers. Among
servers that do provide secure connections to clients, not all
provide secure connections to other servers. (If you recall the
email-like communication model of XMPP, this means that your
communicatiosn with users on other servers would not be secured
between servers, even assuming you trust both servers.)
The excellent xmpp.net
directory of public XMPP servers provides ratings for
client-to-server and server-to-server communications security; look
for A-rated servers. If you set up your own
server, xmpp.net also provides a
security validator that can be used to ensure your personal
server is up to snuff.
Improving the situation
Going forward, there are a number of efforts underway to further
improve the already rather good connection security situation in the
XMPP network. Notably,
the XMPP
manifesto is (documentation of) an effort to transition the
entire federated XMPP network to secured connections by May 19,
2014.
The end-to-end security situation is still a little underdeveloped,
in my opinion. OTR is great, but its protocol-independent nature
leaves it with a level of integration that isn't as complete as it
could be. I have some
early-draft notes
on desirable features for a new XMPP end-to-end encryption
protocol, but a lot of work remains to be done on the topic
— and much of it by people with stronger crypto chops than I
have.
What you can do now
The takeaway from all of this? Ditch your AIM, MSN Live Messenger,
Yahoo! Messenger, or whatever other IM services you're currently
using, and get on board with a federated XMPP provider. Follow the
recommendations in best practices,
above. Use a public server or install your own, but do it sooner
rather than later. Make sure you're using TLS (or SSL, if you have
to) to protect your connections, and consider installing OTR.
Then, when you're done with that, start bringing your friends over.
Talk to them about the benefits of freedom in IM services, describe
the insecurity of communication on traditional commercial IM
services, simply tell them you're not dealing with a closed IM
service any more, or whatever. Point them at this article, if you
think it will help. XMPP already has critical mass, it's simply a
matter of expanding the borders.
If you have the necessary background, consider contacting me about
working on an integrated end-to-end encryption and authentication
solution for XMPP. Join the devel@conference.pidgin.im XMPP MUC and
indicate your interest.
Footnotes
[1]SILC is an example of a service
that provides native secure connections and native
end-to-end encryption. Unfortunately, it is no longer a maintained
codebase, it is not well-supported by IM clients
(though libpurple, and thus Pidgin
does support it), and it has a problematic federation model.
[2]
“Cannot“ is a bit strong here, but I believe that, given
the current state of the art of encryption protocols and mechanisms,
it's true enough to use for the moment. Secure multiparty
broadcasts with hundreds of recipients would be very
expensive using standard techniques. The literature may (and
probably will) have some answers to this problem in the future, but
for now, I'll say cannot.
[3]
I say typically here because I know of no non-local-network service
that handles this any other way. Local network messaging (like
Apple's
Bonjour) has other solutions to
this problem. Generally, however, you send your status updates to
the server and it distributes them (possibly by way of other
servers, in a federated protocol) to interested parties on your
behalf.
I have enabled Disqus comments
for posts on this blog; I've already received a few (not many, of
course) emails regarding posts, maybe this will help such
conversations stick closer to the blog posts if there's material
of relevance to others.
On the one hand, I think the social web has greatly improved the
potential for positive feedback within communities increasing
the amount of signal available. (Alas, the noise is also
increased!) On the other hand, I am not entirely comfortable
with the linking of accounts and tying together of fairly large
amounts of information across multiple domains and topics.
Disqus, being a third-party comment service, does serve to link
users who might interact with this blog with external services
that mine that information. I have allowed anonymous (guest,
in Disqus terms) commenting with moderation, to help combat
this for those who want to minimize the breadcrumbs.
I get far more feedback on the technical articles
on this site. If this trial goes well, perhaps I'll use Disqus
to add comments to those articles (or at least the most popular
ones). I find it more likely that every article will have a
depressing “0 Comments” link at the bottom, and an
empty Disqus entry begging for first posts.
I've been using the
DellXPS 13
Developer Edition (AKA “Sputnik 3”)
for about a week now, and it's time for a follow-up
to my first
impressions review. All in all, I think I hit on most of the
critical points in that first review, but there are a few things
worth clarifying or reiterating, and some new experiences to relate.
That's what this post is.
Overall impressions
All in all, I'm still very pleased with this machine. I
have a few
gripes about the system software, some annoyances with the
finish (more on that later), and a tiny bit of lingering sticker
shock, but I am happy with its performance, portability, and
apparent durability. I think it was a good selection for my needs,
and I doubt I could have done substantially better.
Software
The experience of reinstalling Ubuntu12.04, its supposedly supported
operating system, woke me up to the fact that not all
is entirely happy in Linux laptop support-land. I was
unable to get a different distribution installed with some limited
futzing (although I'm pretty confident it can be done, given some
effort), and 12.04 is getting a little long in the tooth, so that's
a little bit annoying.
Aside from that, I tried out both Unity and XFCE4
before ultimately returning to my old standby, FVWM. Neither of the former
two did anything for me, and both had fatal flaws with respect to
window focus and placement. However, the combination of
needing/wanting various “laptop-y” features and the
desire to generally refresh my desktop integration experience has
led me to spend a bit more time putting FVWM together with the
desktop infrastructure that has sprung up since the last time I paid
much attention. I'm still using FVWM
and rxvt-unicode
as my primary
(non-Emacs)
environment, but I've now hooked in NetworkManager, gnome-keyring,
libnotify, and various other functionality to a greater or lesser
degree. I'm
using stalonetray
for a notification area (I was previously using a program called
wmsystray, and the original author
expressed amazement at its continued existence some years
ago), some sort of policy kit daemon for gnome-keyring support, and
nm-applet to talk to NetworkManager.
Some people wouldn't call that “desktop integration,”
but it's a step forward for me.
The sound situation is not ideal at all. ALSA card 0 is the HDMI
output, which is inconvenient, and Pulse does some sort of weird
thing where if I mute any of three separate channels on ALSA card 1
(the regular sound card), it mutes all three. Unfortunately,
unmuting requires unmuting each one individually, and all three
(master, speakers, and PCM) are required for sound output. I was
able to work around that by using alsamixer -D
pulse, which presents exactly one playback and one record
channel, and mutes appropriately. Oh, and the reason I wound up
using alsamixer at all? I couldn't
find a system tray audio control that even had mute.
Suspend and hibernate work fine once
the xfce4-power-manager applet is
loaded, which is fine, because I'm using it for battery and charging
status indication anyway. It doesn't notify me of impending suspend
due to low battery, though, so that's taken me by surprise a couple
of times. Its preferences suggest that it will, but I haven't seen
it.
Other than sound quirks, and some agedness issues stemming from
Ubuntu 12.04, I'm finding little to complain about in the
software department. I mean, it's Linux.
Drivers
We've been
over the
networking thing already, so I won't repeat it here, but it's a
little annoying. Still, I expect it to get better as time goes on.
There are some more annoying driver (or perhaps more correctly,
driver integration) issues. For example, the Fn keys on the
keyboard. Some of them work perfectly (display brightness, for
example), but some of them do nothing at all. None of the
media keys (play, volume, etc.) generate a keysym that I
can tell, and neither do they just Do their Thing. I assume they
use some sort of new-fangled communication mechanism to talk to DE
software (they work in Unity, for example), but I've been unable to
figure out what it is. It's not X keysyms, it's not ACPI button
presses, and it's not dbus. Suggestions are welcome on this front,
because I'm not really sure where else to look. I'd really like for
at least the mute and volume up/down buttons to work in FVWM.
The touchpad, while generally awesome, has its driver
disappointments as well. For example, three- and four-finger
gestures don't seem to generate any X11 events, although the
touchpad seems to recognize them (because they don't generate motion
or click events, either). For the most part it's fine, though,
after getting cozy with synclient
— I initialize it with synclient
TapButton3=2 HorizTwoFingerScroll=1 VertEdgeScroll=0 on each
login.
Other than those few things, Everything Just Works. No complaints
about that!
Hardware
It's awesome. That's really the bottom line. It's small, light,
has an expansive screen in spite of it, and (relatively speaking)
screams when it spins up those cores. The battery life is 6+ hours
(sometimes as much as 7-8) under realistic (for me) loads. The
qualifier there is that, while I'm a deep systems guy
for a real-time Java vendor,
and I do a lot of editing for development on my laptop, I
actually do my compiling mostly on dedicated compilation
machines. My typical CPU load is pretty low. That said, it will
play streaming video or do Google hangouts for extended periods of
time without complaint.
I still think the touch screen is gimmicky. I've tried to use it a
few times, but a laptop screen just isn't in a particularly good
location for poking with a finger — particularly when it
declares itself to be 96x96 DPI and everything is tiny. It
also doesn't act like a touch display in a lot of ways. For
example, touch and drag doesn't scroll, and neither does two finger
touch and drag. I'm pretty sure the hardware is multitouch, but it
doesn't seem to multitouch. Maybe something will come along to
change my mind on this front, but as of now I don't get it.
The top surface (palm rests and bezel) and keyboard both show
fingerprints like it's their job. I mean, it's actually kind of
amazing they can print with such minimal contact. It makes the
thing look a little bit grungy and well-used, even though it's
almost brand new. My hands aren't normally greasy or sweaty,
either.
The built-in camera is pretty underwhelming. Its contrast is
distractingly high in almost all indoor lighting conditions, and it
displays a fair amount of noise. It works, but it could certainly
be better. On the other hand, I've heard no complaints about audio
quality from the associated microphones, so that must be OK.
Conclusions
As they say on the 'bay, A++++++ would buy again; great
transaction!. A little bit of software love from Dell (say, an
update to 14.04 when it comes out in April, and completed multitouch
for the touchpad) would improve the experience even more.