Windows Phone 7: dropping a generation of developers

One of the less discussed aspects of the Nokia-MSFT deal is impact on developers. After all platforms stand or fall on the strength of their applications. (Steve Ballmer wanted every MSFT employee to take this message to heart.) Windows was able to leverage this virtuous cycle to deliver a stunning upset to Apple in the 1990s, by creating a very attractive environment for developers to enrich the platform one application at a time. Windows API was stable, through two decades as everything changed about the basic PC architecture. CPUs went from 16 to x64, multiple cores and SMP became common, GPUs gained a prominent role, the Network became a critical component of writing code. Windows programming still looked the same. In fact “app compat” became one of the major costs in operating system development– through heroic engineering effort, buggy applications relying undocumented APIs in some archaic version of the operating system were coaxed into working properly on the latest and greatest kernel, lest the incompatibility deter some customer from upgrading.

The same approach applied to mobile programming. Even before smartphones, MSFT pursued handhelds with PocketPC. A subset of the venerable windows API was still present, and later expanded into Windows Mobile. Any developer familiar with programming desktop applications could, with a little effort, write code for mobile devices. To a large extent Apple took the same approach to allow its developers to transition from writing Mac OS-X applications to targetting the iPhone/iPad.

So it came as a major surprise that WP7 dropped backwards compatibility. Native code is now verboten, only .NET applications can be written. In one bold stroke, MSFT may have lost a generation of developers who grew up scrutinizing the MSDN documentation for the subtleties of the classic Windows API. An even bigger question is whether they will be able to court new developers and gain mindshare among those contemplating a career in development. From the perspective of a newly minted computer science graduate trying to decide which programming language/environment to excel in, the options are:

  • Learn C/C++ and take up any systems programming task. (This includes traditional Windows applications, an admittedly endangered species.)
  • Learn Java and program either server applications, or dive into mobile development with Blackberry or Android– the new hotness.
  • Learn Objective C and write OS X or iPhone applications. Also known as “objectionable-C” this was an attempt (emphasis on attempt) to add object-oriented features to C before Stroustrup did it the right way with C++. Outside of Cupertino few people care about it.
  • Learn C# and .NET to program… what exactly? For all the work on promoting the idea that .NET is cross-platform and beats Java at its own game of write-once-run-everywhere, the technology remains very much tied to MSFT platforms. This used to be seen only for enterprise line-of-business applications, and web applications running on Windows server variants: before Windows Phone 7 came along and mandated managed code. The problem is these are highly specialized segment of the market. Much like learning Objective-C and Cocoa development, it is not a portable skill useful in any other context. Unlike OS-X/iPhone, WP7 does not have a commanding presence in the market and proven revenue model with an app store.

It is difficult to justify taking that last option, except as a way to capitalize on lack of competition. In other words, since every one else is writing for iPhone and Android, one viable strategy for ISVs may be churning out copy-cat WP7 applications styled after the popular ones on the leading platforms. But this is hardly a sustainable model, or an appealing proposition for a new developer seeking challenging work.

CP


Standardizing on a standards body

Greetings to the Open Web Foundation. OWF is a new organization for promoting community-driven specifications:

“The Open Web Foundation is an attempt to create a home for community-driven specifications. Following the open source model similar to the Apache Software Foundation, the foundation is aimed at building a lightweight framework to help communities deal with the legal requirements necessary to create successful and widely adopted specification.”

The next statement goes on to state that one of the objectives is to avoid creating a separate foundation for each new technology. Of course the natural reaction to that will be: “In that case, why are you creating yet another self-appointed standard organization? What is wrong with IETF or W3C?” To recap:

  • W3C is the World Wide Web Consortium. It maintains core standards related to the web: HTML, CSS, XML, XSL, XPath, SOAP– for the most part, anything involving angle brackets falls under the jurisdiction of the W3C. Most of these are commonly recognized, widely supported data formats or data manipulation frameworks. (By contrast W3C forays into protocol design such as PICS, P3P and SOAP have met with mixed results.) The consortium charters working groups and issues official, versioned specifications.
  • IETF is the Internet Engineering Task Force. IETF does not officially endorse standards. Its documents go by the more modest name RFC or “request for comments,” suggesting ideas in flux, perennially under editorial review, always open to improvement and changes. Yet many of the core protocols and specifications underlying the Internet can be attributed to an RFC. Email addresses? That would be RFC822. The HTTP protocol shuttling web pages around? RFC 2616. The official TLS protocol that gives us the peace-of-mind and security of the lock-icon on those pages? RFC 2246.

Ben Laurie seeks to preempt that question, also raised in the discussion group. Jury is out on the characterization of W3C as pay-to-play-cartel but the article does highlight a basic problem with IETF: being too inclusive. A former colleague at MSFT described it the requirements for participation in IETF as “a keyboard and Internet connection.” (We can also add: “… and an unshakeable conviction in the infallibility of your ideas.”) This model probably worked well when the workings of arcane protocols was of interest to the academic community only, and everyone that cared to participate started out on the same page, sharing common interests. Today the Internet is too large, the range of stake-holders too diverse and too much commercial success hinges on the outcome of standardization process to continue with that naive assumption of unified purpose.

That same colleague provided this insightful comment on the IETF process: It is a great forum to capture the dominant paradigm on paper and enshrine it as the Internet standard when consensus exists around one. It is not a very good forum for creating consensus in the first place, when everyone shows up at the table with different ideas and irreconcilable objectives. These words were uttered in the aftermath of the Sender ID meltdown where the working group rejected an anti-spam proposal from Microsoft.

OWF raises anew the question of who gets the privilege of a seat at the table once the IETF model (anyone is welcome or “no fool left behind”) is declared dysfunctional, because there is too much randomization. Intuitively those writing software to implement the standard emerge as obvious candidates. But are some implementors more equal than others? Surely not every crackpot with a copy of networking for dummies is entitled to derail the standard process. What about individuals who are recognized subject matter experts but not currently developing software in this space? Moving away from the core, how about companies whose products will be indireclty impacted? Do ISPs get a say in the development of a P2P filesharing protocol, considering it is their infrastructure about to get hammered? Does a firewall vendor get to express an opinion on anti-spam technology because they want to inspect traffic at the edge? Do other participants have the right to declare that they are not interested in supporting that scenario, shutting them out of a particular market segment? Even more controversially, what about companies whose business model is at risk from the existence of the technology? (Advertising networks, criticially dependent on third-party cookies for their existence, were participants in the working group tasked with developing the privacy standard P3P that Internet Exporer uses to manage cookies.)

Assuming that OWF gains any traction, at least one benefit will be forcing some soul searching inside IETF and W3C.

cemp


One week to Pwnie Awards

Move over Antoinette Perry. There is a new award in town and it will take place at the Black Hat briefings next week in Las Vegas. Pwnie awards will honor (shame?) moments of brilliance and ineptitude in the security research community. Highlights from this year’s crop of nominations include:

  • Kernel-mode remote code execution that works on XP, W2K3 and Vista. This after MSFT speculated that the bug would be very difficult to exploit in the real world.
  • Adobe Flash null pointer dereference. What appeared to be an innocuous crash that became a cross-platform, cross-browser remote code execution vulnerability after ISS’s Mark Dowd decided to take a closer look. Once again complements of Flash, continuing to undo any improvements in Internet Explorer security by introducing its own mediocre platform on top of an already fragile HTML/Javascript alliance that years of vulnerability research was finally starting to stabilize. All flash, no subtance but millions of users can’t be wrong: the dancing hamsters are clearly worth the risk of getting 0wned.
  • QuickTime– no vulnerability required, the nomination committee decided the entire application is one colossal mistake, mired in the 1990s quality control standards (“compiles without errors when most warnings are disabled”) and providing another example of insecure context switching.
  • DNS rebinding attacks. Using the web browser to VPN into the internal network behind a firewall. Considering that Kaminsky presented on the topic at last year’s Black Hat, this one has outlived its shelf life.
  • Safari carpet bombing. Note to Apple: forcing software on user machines is not a good strategy when you are awfully slow to fix publicly reported vulnerabilities.
  • Debian/OpenSSL not-very-random number generator debacle; also nominated for most epic failure.
  • Linus Torvalds for controversial views on vulnerability research and handling security bugs.
  • Overhyped bugs: DNS poisoning and unauthenticated UPnP control over network devices.

cemp


Vintage code, common hardware and value of backwards compatibility

A data point on the value of backwards compatibility. This is an area where MSFT is frequently slammed, for its insistence on favoring compatibility with past mistakes instead of throwing everything overboard to start over again– the way Apple has done with OS-X and later switching to Intel x86 chips.

Imagine having to demonstrate an application running on Windows Mobile to a crowded room full of security professionals. This code will not run on the emulator– and even if it did, emulation hardly makes for a compelling demo. “Code always wins” as the old MSFT adage goes and working code on an actual device is the golden standard. This is the predicament confronting the blogger next week. Slide decks are not a problem; they can run off a locally installed PowerPoint or OpenOffice instance (the import process still loses some details if the latest eye-candy from Office 2007 is used) or better yet run from the cloud-hosted Google Presently. Showing UI from the device is a different challenge.

Most phones can not project the view of their own display to an external monitor using a standard VGA, DVI or HDMI output. (Oddly enough a few can project other video over Bluetooth to specialized devices and there is nascent efforst to give phones projectors of their own.) Having a dedicated, fixed camera pointing at the phone was not an option in this setting. And since it is not possible for dozens of people to cluster around a single handset trying to get a peek at the tiny screen, one option is to capture static screenshots at relevant points and project these as part of the slide-deck.

Even that is non-trivial: there is no “print screen” functionality on Windows Mobile out of the box. One quick Google search finds several third-party substitutes, including a freeware version from Ilium software. Luckily the search results also unearthed a better solution. An entry on the Windows Embedded Blog dated November 2004 references a Remote Display application included as part of the Windows Mobile Power Toys. This is good news; power toys are officially unsupported applications typically written by MSFT developers on the side. According to the description Remote Display shows real-time view of the phone display mirrored on the desktop.  Much better than static screen-shots and the audience can now follow along with the exact flow.

One problem: the Power Toys are dated December 2003. Supported operating systems on the download page include W2K SP3– long defunct– as well as “Windows Mobile 2002 based smart-phones.” In other words, this code is archaic. The MSI installed without a problem on Vista, even bearing a proper Authenticode signature to keep the inane UAC prompt happy about reporting the author. But the first attempt to run it with an HTC Diamond failed with an error message about unknown CPU type on the device. Not surprisingly 5 years after the code was written, the architecture of mobile devices, as well as the operating system MSFT is shipping to run on these devices had become unrecognizable under the assumptions the original author had made. Vista does not even have a separate Active Sync component, instead Mobile Device Center handles synchronization with phones.

But the README file provided plan B: the instructions described what to do for that particular error. The recommended fix was to manually find the correct binary over for the mobile device and copy it over. There were not exactly many choices either: Windows CE 3.0, CE 4.0 and smartphones based on CE 4.0. Each OS SKU had a corresponding array of architecture choices, including x86, MIPS and ARM4. As for the device? It is running Windows Mobile 6 on ARMv5i.

So it was a surprise that copying the ARM4 binary built for CE4 worked: Vista could mirror the device screen in real time. Even more impressively, Remote Display works both ways: clicking on the phone UI from the desktop PC actually sends the mouse clicks to the phone, allowing the phone to be driven by the full-size mouse and keyboard combination.

This is one of the rare cases where the insistence on backwards compatibility paid dividends. Not only did the ARM processor have to remain backwards compatible and run binaries compiled for an earlier version, but Windows Mobile itself had to evolve such that code written for earlier CE variants could run without any changes.

cemp


GMail starts enforcing DomainKeys for eBay and PayPal

In a sign that Domain Keys Identified Mail deployments have become reliable enough to depend on, Google has started to enforce DKIM signatures on eBay and PayPal.

Quick recap: DKIM is an anti-spam scheme intended to block forged of email messages and verify the sender by using digital signatures. The  short version is every large email service provider signs messages originating from their site and the recipients verify them. Strictly speaking this is purely an authentication technology, defined by an open IETF standard– nothing prevents spammers from also signing their message but there is an implicit assumption that somewhere a reputation system will spring into existence to allow vetting the verified identities and blacklisting the miscreants. Microsoft has backed a competing solution called SenderID.

Major challenge with deploying these solutions is dealing with the “gray area.” If a message is properly signed by eBay, it is clearly coming from eBay. (Leaving aside the fact that eBay may have been handing out email accounts to its own sellers and one or more of them are spammers.) That email can be safely accepted. If the message is signed but the signature does not validate, it can be rejected– although even then there are edge cases where innocuous message modifications can cause the signature to invalidate. By design cryptographic signatures are designed to be very brittle; any change to the message invalides them. Domain Keys had to work around this.  But what about unsigned messages? It could mean that eBay does not implement the DKIM standard at all. Or perhaps they have not gotten around to deploying DKIM on all the servers. A large service may have hundreds of server dedicated to handling outbound email and the conservative approach is doing a small-scale pilot project first. The final possibility is the message did not originate with eBay and is indeed a forgery, an attempt at phishing for example. It’s important to distinguish these cases because the accept/reject decision for the message will be different.

Strictly enforcing DK would mean that unsigned messages are rejected but that can not be done until there is good reason to believe that the service provider has committed to signing 100% of outbound traffic. In October 2007 eBay (and PayPal, which is owned by eBay) announced plans for adopting DKIM. But until both services could commit to signing all traffic, strict enforcement could mean legitimate messages getting dropped or sent to the junk folder and unhappy users.

cemp


Customer lock-in and US mobile market

Dated story from The Unofficial Apple Weblog hints at the sad state of competition in the US wireless market. As the release date for the second-generation iPhone draws near, news stories pointed out that AT&T and Apple are trying harder to lock down the phones. The widespread use of jailbreaking on first generation phones caused AT&T to miss out on significant revenue as customers bought the devices  without any intention of signing up for the corresponding wireless service. This time around buyers are forced encouraged to surrender the money upfront: phones are pre-bricked according to CNet and must be activated in the store, along with minimum 2 year commitment to a wireless contract. (AT&T to Apple customers: “submit to our authority!”) Expect delays as the purchase itself got complicated by doing credit checks and all the other ceremonies that go with signing up for service plans.

It is still possible to purchase the device itself, but at steep premium. This is standard in the US market where phones are subsidized by the wireless service contract, and sold below cost. There are early-termination fees in case the user decides to part ways with the carrier before they generated enough revenue to offset the cost of the subsidy.  But there is still a gap in the logic as the TUAW points out in the article Doing the wacky AT&T math: it is still more economical to sign up for the contract and then break it after one month instead of purchasing the unlocked device.

On that note, Jonathan Zittrain was at Google NYC yesterday to talk about his recently published book “The Future of the Internet and how to stop it.” One of the highlights from the presentation involved a picture of Steve Jobs on stage discussing the application approval process for iPhone, describing the criteria used to decide when code is unworthy of running on the sacred device. Alongside the usual suspects “malicious” and “bandwidth hog” were one that captured Apple’s attitude towards open platforms: “unforeseen.”

cemp


3G iPhone and location privacy

An article from New York magazine rediscovers the age-old problem of location privacy in mobile devices. Titled iTagged: get ready for the stalkverse the alarmist piece vividly attempts to describe the dangers of having everyone else learn about our location:

Technology was certainly not supposed to know you were at the laundromat. Or the Yankees game. Or your co-worker’s apartment when you were supposed to be working late. But now when you’re at the laundromat, everyone will know.

All true but this is not a new problem being introduced by the iPhone. It is not even being aggravated by the phone having GPS. Global Positioning System sounds like a very neat feature but remains largely a red herring from the privacy point of view, because it is neither necessary or sufficient for tracking. It is not necessary because mobile operators have been legally required by FCC to be capable of locating their subscribers based on triangulating a position from cell phone towers. Dubbed enhanced-911 or E911 these regulations had a very simple objective: knowing where to send the ambulance, fire engine and police car when a 911 call is received. While the USA lagged and to this day continues to lag Europe and Japan in wireless adoption, the FCC correctly predicted that in the future more and more calls would be placed over phones that were not bound to a fixed location that could be looked up in the phone directory.

Not surprisingly the reception was mixed. Privacy advocates feared that they could be used for tracking individuals without oversight. (One ancient article from Infoworld points out that judges must approve any law enforcement access to location data.) Public safety groups pointed to scenarios when E911 was used to locate individuals in kidnapping cases and even urge users to change the settings on their phone to enable location at all times. These regulations were phased in over time, requiring that 95% of handsets sold in 2005 must be capable of radiolocation. Considering that the average lifetime of a handset is 18 months, a reasonable assumption is that all phones in use today support the feature. No GPS required.

GPS is also not enough because it requires line of sight to satellites– forget about it working indoors– and can be frustratingly slow to develop an initial fix. At best GPS adds to tracking capabilities when the subscriber is attending Burning Man, out of the range of cell phone towers. Of course without reception the phone has no way to report back the location to the would-be-stalkers in real time, but presumably it could store that  information for future upload when the handset has service again.

Where the iPhone could have a disruptive effect is the integration of the feature and its social acceptability. Some handsets today allow using the phone for driving directions, with real-time position information, placing the carriers in direct competition with the dedicated GPS units such as Garmin.  A few carriers such as Nextel directly advertise tracking as a feature for fleet management. These are strictly business applications; phones are carried by employees in charge of some asset that is owned by the company and the intention is tracking the asset more than the individual. Poster child is the trucking company with 18 wheelers criss-crossing the country that wants to know exactly where each truck is so they can re-route the one closest to Dubuque to pick up another load.

iPhone is strictly a consumer technology and one that defines the cutting edge. The moment a popular application comes along that requires the user to opt-in to location tracking, it will create social pressure for others to do the same. It will define the new standard for what is “acceptable” for location privacy. This is the main takeaway from the article:

Because you’ll be letting them know. Maybe not yet; you’re still shy, and think the laundromat is boring. But in a year or two, when everyone is doing it, that shyness will start to seem stupid. It will begin to seem rude not to tell—I mean, what’s wrong with the laundromat?

And some predictions for awkward consequences:

The initial etiquette screwups are going to be exquisite: not just the stalking, but the brand-new form or snubbing where you can see your friends gathering without you. You’ll feel wildly self-conscious for about six months. But soon it’s all going to seem normal and automatic.

Such a race-to-the-bottom is not unknown in privacy. The moment people started putting their personal lives up for display on Facebook, it created a pressure on others to become even more transparent. How long until there is a Facebook gadget that charts your location on a map? Forget about Dopplr and depending on the user to diligently report their wanderings; the next web 2.0 application with no regard for privacy can tap into that information straight from the iPhone.

cemp


Debian/OpenSSL vulnerability: subtle and fatal (1/2)

Most vulnerabilities in COTS software are quite blatant about their root causes and direct in their impact. A remote code execution vulnerability can be traced to a low level programming error and its immediate effect is likely an 0wned machine, or the next billion dollar self-propagating malware. Once in a while, a new extremely creative type of bug is introduced that defies this pattern. The flaw in the OpenSSL random number generator that affected Debian and Ubuntu is one of those rarities.

The short version: Debian developers attempted to fix a problem in OpenSSL that was flagged by static analysis software. (For other takes on the problem: my colleague Ben Laurie has taken the Debian maintainers to task and added some clarifications about the response, XKCD has neatly summed up the issue with a comic strip and Garntner argued that this incident is indicative of a deeper problems in open-source, just in time for a Coverity report that gave glowing reviews to open source projects for fixing issues identified by their technology.) It turned out the fix was much worse than the ailment

  • Motivation: specific problem flagged by the automatic analysis of source code was an instance of using uninitialized memory– something that ought not occur in an ordinary application and is almost always a bug. But a library implementing cryptographic functionality has unusual requirements. In this case the OpenSSL designers were intentionally using uninitialized memory to seed the randomness pool. C/C++ language lawyers will jump up and down at this point screaming that use of uninitialized variables on the stack is undefined by the language. “Undefined” meaning that the compiler is free to optimize out the code, insert an easter egg, cause the application to crash if it reaches that instruction etc. Pragmatically speaking on most CPUs, operating systems and compilers that OpenSSL will likely reach, the memory ends up retaining the junk that was written last time, and this unpredictability is exactly what is required for randomness.
  • Neglected wisdom: important point is that the bug was not causing OpenSSL to crash or misbehave. In the worst case, the memory region contained predictable data such as all zeroes, so there was no benefit in seeding a randomness pool with that. No problem because there were many other sources of randomness used. This is a good time to remember the classic engineering adage: “if it ain’t broke, don’t fix it.” Debian developers did “fix” it, but in doing so they removed the addition of all entropy to the pool, instead of simply removing the one instance that was questionable.
  • Outcome: OpenSSL random number generator was completely broken. This is a major problem when dealing with cryptography. Everything depends on keeping secrets; encryption only works to protect data from people who do not have the decryption key. When keys are not just random patterns but generated according to a very predictable pattern, they are no longer a secret. The surprising part is that the code did not have a “vulnerability” in the classical sense: OpenSSL would not crash on malformed data because of this, it would not start running somebody else’s code or cause the machine to become the latest inductee into a botnet. A security researcher looking for yet another buffer overrun would be disappointed to realize that nothing of the sort was introduced as a result of the Debian update.

(continued)

cemp


Next version of MSFT office to support open document format

The times they are changing for MSFT. A recent announcement that the next version of the Office suite will support new open source formats may be the most revealing example.

Interoperability is a complex strategic game but can be summarized this way: interop always helps the smaller competitors against a large established player. This is a standard consequence of network effects. Before Word had significant market share and was the small, scrappy upstart trying to gain a beachhead position against Word Perfect, it was imperative to read and write WP documents. This allowed customers to switch to Word but still continue to interoperate with the majority of people still using the more ubiquitous application. The developers for Word Perfect, on the other hand, have no incentive to help accelerate this switch, so their application would not recognize the new format. Here is a divergence from the golden rule of getting along in a network world: “be conservative in what you send out and generous in what you accept.” If interoperability were the only objective, every application would be able to open documents published by any other formats while itself using a very well narrowly-scoped that would be easy for these other applications to understand.

The same pressure applied to Excel when it was competing for market share against Lotus Notes. As MSFT Office became the de facto standard in the enterprise and eventually for consumers, this pressure gradually eased even though the import/export capability for the “legacy” formats remained. At some point the scales tipped and the burden shifts to the competing applications with smaller market share to work with the leading formats.

Open source software follows the same path: it was imperative for Open Office to be able to accept Word documents, as well as save new documents in Word format. This mean that every new release of Office required catch-up effort from the community to add necessary interop functionality. (It did not help that the office formats were largely undocumented and had to be reverse engineered until the XML based Open Office XML specification, which itself fueled another line of controversy during its push for standardization.) Same goes for cloud services: it is no coincidence that Word documents, Excel spreadsheets and PowerPoint presentations can be uploaded.

The announcement that MSFT Office will support the new open-source formats is not due to a tipping point in market share. Its current position remains virtually unassailable. Even the Apple commercials that try to mock PC platform as a square, clueless fellow are forced to pay a backhanded complement by emphasizing that the latest generation of Macs can run Office. Is this the sign that demand for interoperability has arrived? Is the golden rule a more compelling option than trying to create lock-in effects by using proprietary formats and breaking changes on every release that force open source alternatives to play catch-up? At least the European Union is not convinced and announced its own intentions to verify this:

“The Commission will investigate whether the announced support of Open Document Format in Office leads to better interoperability and allows consumers to process and exchange their documents with the software product of their choice.”

Between the competition from free Open Office, disruptive Google Apps for the Enterprise, Adobe trying to unify presentation layer with PDF and now additional regulatory scrutiny, it is getting interesting for the future of desktop productivity software.

cemp


Default settings and ecological impact

Do application settings reflect choices made by the user or the priorities of the developer? This questions comes up again and again, as the settings are linked to yet another unexpected negative outcome. The latest example is from ChangeTheMargins.com, courtesy of Good magazine.

Almost any interesting bit of software comes with a set of switches and knobs. The more complex the software, the more switches to fiddle typically. Sometimes the developers in a good-intentioned attempt to conquer the complexity reduce it to a series of multiple choice questions. How secure would you like that router? Low/medium/high. More likely there is an escape hatch left open for the tinkers, a custom or advanced option hiding in the UI that unlocks the full array of all possible configurations, to create the software equivalent of an extra-hot, 2% double-shot half-decaf mocha.

Unlike the whimsical Starbucks creations, application settings can have a wider reaching effects then the next caffeine buzz. Power settings are the obvious example: machines equipped with power management features that can either slow-down the CPU speed or hibernate altogether in response to low utilization can cut down on energy consumption. ChangeTheMargins picks a different battle; the choice of margins in Microsoft Word. Set to 1.25″ by default for left-right, the website argues for cutting that generous allotment of white-space down to three-quarters of an inch instead. There are detailed figures for exactly how much in paper, trees and dollars that will save.

All good advice. As for the interesting piece: the author is calling on Microsoft to set the defaults to 0.75″ in Office out-of-the-box. This raises an interesting question the extent that the current wasteful use of paper can be blamed on the developer and to what extent on the customers using that software. (Not to diminish the influence of middle-man along the way: the OEMs who install and configure that software on brand-new machines where it is bundled, the enterprise IT departments responsible for rolling-out Office to 10K desktops etc. In fact the website does have a stated goal for converting 5 corporations to sanction the narrower margins.) The issue of default can become a major headache to the vendor for three reasons:

  • There are too many conflicting interests– including occasionally that of the vendor itself– and out-of-the-box settings must strike a balance that can not please everyone
  • Anecdotal evidence suggests some fraction of users will not change settings. Especially anything marked “advanced” or “custom.” This makes it very hard to take the position that settings reflect user choice as opposed to user complacency. (This fact was impressed on the blogger when he worked on the P3P privacy settings for Internet Explorer 6.)
  • Most applications must ship with some defaults at least. For many years UI designers hated the idea of forcing a decision on the user at first-run or installation time, because it was disruptive to their Platonic ideal of user-friendly software. They pointed out, quite correctly, that such a question materializing out-of-context, when the user is already occupied with a different primary would simply be perceived as a distraction, leaving everyone looking for the “OK” button to make it go away. Without any basis for weighing the options the user might as well flip a coin. Fortunately UI designers have become more pragmatic about this over time, especially in the context of security. IE6 XP SP2 “Information Bar” and more recently in IE7 phishing filter do in fact prompt the user to make a decision the first time when the choice would have a material impact.

Yes, the default width of margins matter. But to put this in perspective: it matters much less than other options. Printing double-sided can cut down paper waste by 50%. What about configuring printers to default to double-side? Not that easy it turns out because most of them can not do auto-duplexing. This blogger cared enough about the functionality to find one that could, but there were few viable alternative for home-office use: Brother DL-5250DN handily won out. Manually printing double-sided is very slow and often impractical for large documents because the secondary feed tray can not accommodate very many sheets at once. But the high-end multipurpose scanner/fax/color-laser printer/photocopier machines the size of washer machines found in large enterprises can and ought to be configured to default to double-sided and not waste paper printing out cover pages to distinguish the jobs.

Finally there is the question of trade offs: using smaller fonts, using single-spacing instead of double-spacing or printing two pages on one side (50% magnification) can all cut down on paper wasted, but the expense of readability. One reason conservation efforts have not resonated with the American public in the past is that they evokes images of huddling together in the cold –reduce heating to curb carbon emissions– in a dimly-lit space whit with pale glow of florescent lights– more efficient than incandescent– after taking a cold shower. At some point the quality of the printed document may not meet the strict standards used for academic or legal correspondence for example. That brings us to the most promising solution: minimizing the need to convert electronic documents into hard-copy.

cemp


Follow

Get every new post delivered to your Inbox.