« swipe left for tags/categories
swipe right to go back »
Maybe everyone knows this, but it took me a while to realize that almost all of my performance issues with Google Apps were related to my DNS configuration. Once I switched all my machines and routers to Google Public DNS all of my performance problems went away.
It’s remarkable. Simply hard code DNS to 188.8.131.52 and 184.108.40.206. Problem solved.
My office, condo, and house in Keystone are all on Comcast. For the last month I’ve been struggling in each of them. There are days that Gmail feels almost unusable – five to ten second waits between messages. Web performance was “good enough” so I assumed it was a Gmail problem.
Nope – it was a Comcast DNS problem.
In hindsight, this is kind of obvious. But wow, what a difference it made.
I woke up this morning to several articles about Bitcoins. From Dave Taylor’s explanation in the Boulder Daily Camera to a paywall article that you can’t buy with bitcoins (ironic) in the NY Times (A Bitcoin Puzzle) to Fred Wilson’s blog (A Note about Bitcoin), I was surrounded by words about them.
We have an awesome CEO list that covers plenty of topics. Early in the week I posted a link to Fred Wilson’s post Buying Your Holiday Gifts With Bitcoin. That generated a fun discussion including lots of “what are bitcoins and why do I care”; “here’s what they are” kind of things. And then Kwin Kramer of Oblong weighed in with a phenomenal essay. It follows.
I’m with Seth; I think bitcoin is interesting on several levels, including as a real-life experiment with a semi-decentralized currency.
Bitcoin is a software engineer’s implementation of money (as distinct from, for example, a politician’s, banker’s, or economist’s).
There’s a lot of overlap between bitcoin fans and folks with strongly libertarian views. Many of bitcoin’s most vocal proponents see bitcoin as a currency, a replacement for currencies that are created and managed by governments. These folks tend to view bitcoin as a sort of electronic version of gold, a new currency that’s not a “fiat” currency.
I’m deeply skeptical of this set of ideas. First, and very generally, I don’t tend to think that dis-intermediating government institutions is a useful goal in and of itself. I would describe a well-run central bank like the United States Federal Reserve the way Churchill described democracy: the worst solution to the problem of managing a monetary system, except for all those other forms that have been tried from time to time.
In addition, core design decisions in the bitcoin spec make bitcoin a pretty terrible store of value and unit of account, which are two things we expect from a currency.
As has been noted in this thread, the total number of bitcoins is capped at 21,000,000. Currently there are about half that number of bitcoins in circulation. The rate at which new bitcoins are mined is designed to decrease over time. This means the bitcoin market behaves more like a commodity market than like a currency market, prone to volatility and some specific kinds of market pathologies. In my view the fact that the money supply can’t be “managed” by a central bank that is able to turn various “knobs” (interest rates of several kinds, the amount of money in circulation) is a bug, not feature!
The cap also means that a bitcoin-denominated monetary system will be a system built around deflation — the opposite of how the monetary system we use today is constructed. Over time, prices will fall, rather than rise. Economists generally view deflation as a problem. If prices get cheaper over time, all the time, people have strong incentives to delay purchases and to save money. If everyone saves, rather than spends, economic growth is impossible.
Economists have lots of tools for talking about this stuff. And, while economists often disagree violently with each other, the collective knowledge in the field is important and valuable. To draw an analogy, non-programmers can and often do have very insightful things to say about digital technology. But it’s definitely worth talking to experienced programmers when trying to understand a particular platform, protocol, or application.
I’m not an economist, but I find convincing the economists’ consensus that deflation is “bad.” At the very least, I’d argue that we don’t know how to build a stable monetary system on top of a currency that is fundamentally deflationary.
On the other hand, even if bitcoin makes for a poor currency, it may well be a very useful payment mechanism. The original bitcoin paper focuses heavily on this aspect of the system design.
To explain this a little more, we can think about how we use US dollars in normal, every-day life. I usually keep some printed dollar banknotes in my pockets. These banknotes — these “dollars” — are a store of value. (They’re worth something in an economic sense.) The banknotes are also a unit of account. (Lots and lots of things I encounter every day have prices denominated in dollars.) Finally, each banknote is a payment mechanism — a transaction mechanism. I can hand over a banknote to most people I might want to buy something from. They’ll accept it. We’ll both know what that means.
But physically handing over a “dollar” isn’t the only payment mechanism I regularly use. I have credit cards, and checks (sort of — that’s kind of changing), and now some other electronic payment mechanisms like PayPal and Amazon points.
It’s possible to separate the functions of value store, unit of account, and transaction mechanism. They fit together neatly and are systemically related, but they’re three different things.
The bitcoin peer-to-peer transaction protocol is pretty cool. It’s basically strong cyptography, good timestamps, and a consensus protocol for blessing transaction reporting.
Which boils down to a way to “hand someone cash” electronically. With no trusted third party having to broker the handover. And, theoretically, anonymity for both the payer and the payee.
As a software person, I think of this as a platform. A new electronic payment platform that may have significant advantages over most of the existing ones. To get broad adoption, platforms need killer apps. So far, there aren’t killer apps for bitcoin. But there are some possible raw materials for killer apps. Cheaper international payments. Completely anonymous electronic payments. But the great thing about platforms is that it’s often quite hard to predict early on what the killer apps might be. Particularly for the really disruptive ones.
A couple of final caveats. It’s not clear (at least to me) whether it’s possible to separate the currency aspects of bitcoin from the transaction platform aspects. If bitcoin does turn out to be a flawed currency, that could be a problem even if the transaction platform stuff is really useful.
Also, the bitcoin platform is pretty new and there may be some fatal flaws in the design of its anonymity features and its transaction log. For example, the transaction log is a global, permanent thing. To verify any bitcoin transaction you have to have a full record of every bitcoin transaction ever. That’s okay now; the system is small. Our computers and networks will keep getting faster as bitcoin use increases. But a broadly used currency will have to be able to support a lot of transactions. Maybe the design can be patched, either in a technical sense or in a social/institutional sense. But we don’t really know.
At dinner last week, my long time friend Dave Jilk (we just celebrated our 30th friendship anniversary) tossed a hypothesis at me that as people age, they resist adopting new technologies. This was intended as a personal observation, not an ageist statement, and we devolved into a conversation about brain plasticity. Eventually we popped back up the stack to dealing with changing tech and at some point I challenged Dave to write an essay on this.
The essay follows. I think he totally nails it. What do you think?
People working in information technology tend to take a producer perspective. Though the notion of a “lean startup” that uses both Agile and Customer Development approaches is ostensibly strongly customer focused, the purpose of these methodologies is for the company to find an maximize its market, not specifically to optimize the user experience. The following is an observation more purely from the perspective of the consumer of information technology.
On average, as people age they resist adopting new technologies, only doing so slowly and where the benefits compellingly outweigh the time cost and inevitable frustrations. This resistance is not necessarily irrational – after a number of cycles where the new technology proves to be a fad, or premature, or less than useful, we learn that it may behoove us to wait and see. We want to accomplish things, not spend time learning tools that may or may not help us accomplish something.
Consequently, for many decades the pattern has been that technology adoption is skewed toward younger people, not only because they have not yet built up this resistance, but also because they are immersed in the particular new technologies as they grow up.
But something new is happening today, and it is evidence of accelerating rather than merely progressive technology change. Discrete technology advances are giving way to continuous technology advances. Instead of making a one-time investment in learning a new technology, and then keeping up with the occasional updates, it is increasingly necessary to be investing in learning on a constant, ongoing basis.
I will provide three examples. First, application features and user interfaces are increasingly in a state of continuous flux. From a user perspective, on any given day you may connect to Facebook or Gmail or even a business application like Salesforce.com, and find that there are new features, new layout or organization of screen elements, new keystroke patterns, even new semantics associated with privacy, security, or data entered and displayed. This is most prominent in online systems, but increasingly software updates are automatic and frequent on mobile devices and even full computer systems. On any given day, one may need to spend a significant amount of time re-learning how to use the software before being productive or experiencing the desired entertainment.
My mother is 86 years old. For perspective, when she was 20, television was a new consumer technology, and room-sized digital computers had just been invented. She uses the web, Yahoo mail, and Facebook, impressive feats in themselves for someone her age. But every time Yahoo changes their UI, she gets frustrated, because from her perspective it simply no longer works. The changes neither make things better for her nor add capabilities she cares about. She wants to send email, not learn a new UI; but worse, she doesn’t really know that learning a new UI is what she is expected to do.
Middle-aged people like me are better prepared to cope with these changes, because we’ve gotten used to them, but we still find them frustrating. Perhaps it is in part because we are busy and we have things we need to get done, but it is interesting to see how much people complain about changes to the Facebook interface or iOS updates or what have you. We can figure it out, but it seems more like a waste of time.
Young people gobble up these changes. They seem to derive value from the learning itself, and keeping up with the changes even has a peer pressure or social esteem component. Yes, this is in part because they also have fewer responsibilities, but that cannot be the entire explanation. They have grown up in a world where technology changes rapidly. They didn’t just “grow up with social media,” they grew up with “social media that constantly changes.” In fact, not only do they keep up with the changes on a particular social media service, they are always exploring the latest new services. Several times a year, I hear about a new service that is all the rage with teens and tweens.
A second example that is more esoteric but perhaps a leading indicator, is the rise of continuous integration in software development, not just with one’s own development team but with third-party software and tools. No longer is it sufficient to learn a programming language, its idiosyncrasies, its libraries, and its associated development tools. Instead, all of these tools change frequently, and in some cases continuously. Every time you build your application, you are likely to have some new bugs or incompatibilities related to a change in the language or the libraries (especially open source libraries). Thus, learning about the changes and fixing your code to accommodate them are simply part of the job.
This situation has become sufficiently common that some language projects (Ruby on Rails and Python come to mind) have abandoned upward compatibility. That’s right, you can no longer assume that a new version of your programming language will run your existing applications. This is because you are expected to keep up with all the changes all the time. Continuous integration, continuous learning. Older coders like me view this as a tax on software development time, but younger coders accept it as a given and seem to not only take it in stride but revel in their evolving expertise.
My final example, a little different from the others, is the pace of client device change. From 1981, when the IBM PC was introduced, until about 2005, one could expect a personal computer system to have a lifespan of 3-5 years. You could get a new one sooner if you wanted, but it would have reasonable performance for three years and tolerable for five. By then, the faster speed of the new machine would be a treat, and make learning the latest version of DOS, and later Windows, almost tolerable. Today, five years is closer to the lifespan of a device category. Your recent smartphone purchase is more likely to be replaced in 2017 by a smart watch, or smart eyewear, as it is by another smartphone. You won’t just have to migrate your apps and data, and learn the new organization of the screen – you will have to learn a new way to physically interact with your device. Hand gestures, eye gestures, speaking – all of these are likely to be part of the interface. Another five years and it is highly likely that some element of the interface will take input from your brain signals, whether indirectly (skin or electromagnetic sensors) or directly (implants). When you say you are having trouble getting your mind around the new device, you will mean it literally.
The foregoing is primarily just an observation, but it will clearly have large effects on markets and on sociology. It suggests very large opportunities but also a great deal of disruption. And this transition from generational learning to continuous learning is not the last word. Technology will not just keep advancing, it will keep accelerating. As the youth of today, accustomed to continuous learning, reach their 40s and beyond, they will become laggards and slow to adopt in comparison with their children. Even continuous learning will no longer be sufficient. What will that look like?
When LinkedIn posted LinkedIn Intro: Doing the Impossible on iOS I was intrigued. The post title was provocative (presumably as intended) and drew a lot of attention from various people in the security world. Several of these posts were deeply critical which generated another post from LinkedIn titled The Facts about LinkedIn Intro. By this point I had sent emails to several of my friends who were experts in the email / SMTP / IMAP / security ecosystem and was already getting feedback that generally trended negative. And then I saw this post titled Phishing With Linkedin’s Intro - a clever phishing attack on Intro (since fixed by LinkedIn).
All of this highlights for me my general suspicion around the word “impossible” along with the complexity that is increasing as more and more services interconnect in non-standard ways.
One of the thoughtful notes I got was from Scott Petry – one of my good friends and co-founder of Authentic8 (we are investors). Scott co-founded Postini and a bunch of email stuff at Google after Google acquired Postini in 2007. Following are his thoughts on LinkedIn Intro.
I am all for seamless integration of services. And while “man in the middle” is commonly seen as a pejorative, the MITM approach can enable integrations that weren’t readily available previously.
Postini, which started life as a spam filtering service became a huge email MITM enabling all sorts of email processing not available on the mail server itself. Seamless integration was a big part of our success – companies pointed their mx record to Postini, Postini filtered and passed the good stuff on to the company’s mail server. While controversial in 1999, DNS redirect-based services have become accepted across all ports and protocols. Companies such as Cloudflare, OpenDNS, Smartling, and more all offer in-line services that improve the web experience through DNS-level MITM-type model. Simple to configure and high leverage. They just aren’t thought of as MITM services.
Extending functionality of services by authorizing plug-ins to gain access to your data can be really useful as well. I use Yesware in Gmail to help track messages and automate responses when I send company-related marketing/sales emails. It’s a great service, enabling functionality not previously available, and you could think of this as a man in the middle as well. It is important to point out that in the case of Yesware and DNS style integrations, I need to explicitly approve the integration. The details are made available up front.
New levels of integrated services are coming online daily. And vendors are getting more and more clever with APIs or skirting them altogether in order to get their app in front of us. It’s natural to be sucked in by the value of these services and it’s easy to overlook any downside. Especially given that for many of them, the people who are paid to think about security ramifications aren’t in the loop. They can be installed and configured by end users, not IT. And most users take the security for granted … or overlook it all together.
Last week, on the LinkedIn engineering blog, details on the new LinkedIn Intro app were shared. Intro integrates dynamic LinkedIn profile information directly into the iOS email app. It didn’t get much attention when it was launched, but once the engineering team blogged about how did the impossible to integrate with the iOS email client, the story blew up.
Details on their approach here (http://engineering.linkedin.com/mobile/linkedin-intro-doing-impossible-ios).
LinkedIn Intro does a beautiful job of auto-discovering your environment and auto-configuring itself. A click or two by the user, and they’re up and running with active LinkedIn data in their email app.
All this clever engineering hides the fact that LinkedIn is accessing your email on your behalf. Intro uses an IMAP proxy server to fetch your mail where they modify it, then deliver it to your iPhone. Classic Man in the Middle.
If you remember setting up your mail service on your iPhone, it is a bit clunky. You need to know the host names of your service, the ports, encryption values, etc. It isn’t easy. But you don’t do any of this with Intro. Instead of going through the usual configuration screens on iOS, Intro uses Apple’s “configuration profiles” capability auto discover your accounts and insert their servers in the middle. And since it uses OAuth to log in, it doesn’t even need to ask for your credentials.
They do such a good job of hiding what they’re doing that the significance of the data issues were lost on everyone (except the security researchers who raised the brouhaha).
This weekend, LinkedIn made another blog post. In their words, they wanted to “address inaccurate assertions that have been made” and “clear up these inaccuracies and misperceptions”. The post, here (http://blog.linkedin.com/2013/10/26/the-facts-about-linkedin-intro/) followed the PR playbook to the letter.
With one small exception concerning a profile change, the post does nothing to clear up inaccuracies and misperceptions. Instead, their post lists their reassurances about how secure the service is.
Even with these assurances, the facts remain. LinkedIn Intro pipes your email through their servers. All of it. LinkedIn Intro inserts their active web content into your email data. At their discretion.
With its clever engineering, Intro became a violation of trust. And worse, potentially a massive security hole. If the research community didn’t raise the alarm, the details of Intro’s integration wouldn’t have hit the radar.
I think the lesson here is two-fold:
1) We live in a world where our data is scattered across a variety of disparate systems. It is incumbent on us to understand the risks and weigh them against the reward of the shiny new app promising to make our lives better. If something appears to be too good to be true, it probably is.
2) Vendors need to be more transparent about what they’re doing with our data. Especially if the vendor has a spotty reputation in privacy and security realms. If they’re not, the Internet community will do it for you.
My long time friend Terry Kawaja (history question – which Colorado-based company was Terry once CFO of) from Luma Partners sent me his latest parody video titled Use Bitcoin. I knew it was a parody of something, but I didn’t remember “Wear Sunscreen” (which I saw when it first came out in the late 1990′s) until I read the liner notes on Terry’s Youtube post.
Both are awesome. But to really grok how awesome Use Bitcoin is, you have to watch Wear Sunscreen first. It follows.
Now – Use Bitcoin.
Count me inspired. And amused.
If you want something serious from Terry, his 20 minute State in the State of Digital Media 2013 is definitely worth watching.