With Google owning YouTube, the Internet’s principal delivery system for Flash-based video, it was perhaps inevitable that the company would bundle the Flash plug-in with its Chrome browser. The announcement came today from both Google and the team developing the open source Chromium component on which Chrome is based.
The move now officially places Google in contention with proponents of HTML 5, who had held out a glimmer of hope for a non-proprietary, non-plug-in video format for the standard’s new <VIDEO> element. In its blog post today, the Chromium team indirectly blamed the standards process for not having solved what it perceives as the problem of specifying how plug-ins should operate, and credits Mozilla — which makes Firefox — with helping to rectify that issue.
“The traditional browser plug-in model has enabled tremendous innovation on the Web, but it also presents challenges for both plug-ins and browsers,” reads today’s post from Google Vice President for Engineering Linus Upson. “The browser plug-in interface is loosely specified, limited in capability and varies across browsers and operating systems. This can lead to incompatibilities, reduction in performance and some security headaches.”
Upson credits Mozilla’s efforts to upgrade and improve the old Netscape plug-in API model, still called NPAPI. This model currently enables out-of-process plug-ins to operate essentially independently from the browser. Historically, it’s this independence that has been exploited by malicious users infiltrating victims’ systems through Adobe Flash. Under the new system proposed by Mozilla, code-named “Pepper,” processes launched through the browser would run through threads that are routed completely independently of browser and renderer threads. Specifically, the new thread model would block browser threads when plug-in threads are active, and vice versa, so that one would never have access to the other.
Consider it a kind of “anti-multithreading” that may very well be necessary in the age of Web applications.
But by citing Mozilla as the leader in this effort, Google may effectively be ceding responsibility for solving some of the most critical Flash security issues to date, to Mozilla. Until then, Upson concedes that the first Chrome dev build to contain the Flash plug-in will not yet have resolved a potential security risk: the separation between the Chrome tab processes and the Flash runtime. Part of Google’s (originally) innovative security model was its division of browser tabs into separate processes, so that when one tab crashes, the main browser remains stable.
One of the unanticipated side-effects of this model deals with Chrome’s approach to add-ons: They too are separate processes, all of which identify themselves to the operating system as Chrome. The screenshot above shows a list of active processes from Sysinternals’ Process Explorer, with the latest Chrome dev build 360.4. There’s only one tab running the Acrobat.com page, but note that Chrome appears twice in the list. That second instance appears to be the Chrome sandbox wrapped around the Flash add-on.
But it’s not. As Google’s Upson said today, despite appearances, the Flash instance which that second item appears to encapsulate is not completely covered by Chrome’s sandbox — its safe operating environment. There’s obvious reasons for that: Here, Flash Web apps are hosted in the client by the AIR runtime. There should only be one instance of AIR running within a client.
The reasons why were outlined in a 2008 white paper (PDF available here) written by a trio of university researchers who were employed by Google to design Chromium. It’s in “The Security Architecture of the Chromium Browser” that the designers explain the division of the browser kernel, which interacts with the operating system, from the renderer which is isolated in the sandbox. Plug-ins must run independently of the sandbox in order to fulfill the needs of their manufacturers, the group stated, even though doing so introduces a potential vulnerability. Notice which plug-in they picked as their case-in-point:
In Chromium’s architecture, each plug-in runs in a separate host process, outside both the rendering engines and the browser kernel. In order to maintain compatibility with existing web sites, browser plug-ins cannot be hosted inside the rendering engine because plug-in vendors expect there to be at most one instance of a plug-in for the entire web browser. If plug-ins were hosted inside the browser kernel, a plug-in crash would be sufficient to crash the entire browser.
By default, each plug-in runs outside of the sandbox and with the user’s full privileges. This setting maintains compatibility with existing plug-ins and web sites because plug-ins can have arbitrary behavior. For example, the Flash Player plug-in can access the user’s microphone and webcam, as well as write to the user’s file system (to update itself and store Flash cookies). The limitation of this setting is that an attacker can exploit unpatched vulnerabilities in plug-ins to install malware on the user’s machine.
Users could try running Chromium (and later Chrome), the group suggested, using the command line switch --safe-plugins, which would place all plug-ins under the protection of the renderer’s sandbox. But they’ll likely crash, they warned.
To address that problem, Adobe’s senior director of Flash engineering, Paul Betlem, said in a blog post today that his team will work with both Google and Mozilla to replace and improve NPAPI. “While the current NPAPI has served the industry well, it lacks the flexibility and power to support the pace of innovation we see ahead,” Betlem wrote. “We expect that the new API specification will offer some distinct benefits over the current technology available.”
One foreseeable outcome of this collaboration could very well be a community where at least some plug-ins are compatible with both Chrome and Firefox simultaneously. But another outcome that Adobe’s Betlem points to is a certain kind of unification, not just of the security model but of how the browser presents itself to the world. Think of it as “the Flash browser.”
“The new API is being designed with the flexibility to allow plug-ins to more tightly integrate with host browsers,” wrote Betlem. “The new plug-in API will provide performance benefits since the host browser will be able to directly share more information about its current state.”
Reaction to Adobe’s and Google’s move today was mixed on Google’s forums, with about two-thirds of respondents against the bundling and one-third vocally in favor. As supernova_00 wrote this morning, “Ugh. And here I thought we were all getting close(ish) to completely ditching Flash, and you guys decide to bundle Flash with Chrome. What the hell happened to open standards?”
Plus this from contributor Daniel Hansen: “Just when we thought that Google was the champion of HTML 5, they turn around and partner with Adobe on Flash to ensure that the Web remains a mess of proprietary brain damage.”
Support for the move centered around the notion that Flash is simply a fact of life on the modern Web that no arbitrarily imposed standard is likely to change overnight, or even in the next decade. “People must be really dumb if they think HTML 5 is going to kill Flash,” wrote Gabriel. “It’s used for so-o-o much more than cats playing piano. The sooner you realize this, the more Google’s move makes sense.”
There was also this from contributor Troy: “How is Flash not an open standard? The bytecode format of [Shockwave] SWFs is published. There are open-source tools for producing SWFs. The tool chain is open-source and free. The player is available on the three major desktop OSs, and now on many mobile devices, as well as several video game consoles. Its virtual machine is open-sourced. Sure, it’s not standard-certified by some international organization, but neither is HTML 5 (yet) nor is CSS3 (yet). It is a de facto standard, used by more Web sites and users than HTML 5, CSS3, Canvas, etc. Come on, folks, let’s be pragmatic.”
The bundling of Flash with Chrome does not change the relationship between the component and the browser, as indicated by the about:plugins page above. Notice its format changed with this latest dev build; it now includes (highly requested) Disable links that let you turn off plug-ins without uninstalling them. However, bundling Flash did add 2.4 MB to Chrome 5’s download size, plus a single new question to the startup procedure (shown below). In the dev build, to start using the Flash plug-in that’s distributed with the browser, you run Chrome from the command line, adding the switch --enable-internal-flash.
Using a Firefox 3.0 add-on created by developers in Hong Kong, Betanews was able to briefly establish a connection with the Internet via a proxy based in mainland China. With that proxy, we were able to confirm that searches performed using Google’s Hong Kong-based page were effectively blocked.
Firefox 3.0 reported the blockage with this message: “The connection to the server was reset while the page was loading” — a message from the browser, not from an ISP. We used version 3.0.16 of Firefox (an older edition) because it is the only version compatible with China Channel, a tool made for the express purpose of testing China’s filtering ability. It has not been upgraded for version 3.6.
Further tests using the same proxy connection revealed that filtering may not be limited to Google. Searches for innocuous topics using Baidu, the country’s leading search service known to employ its own filtering, were also blocked. We confirmed that the failed Baidu attempts were on account of blockage rather than just a dropped connection by browsing immediately to Xinhuanet, the country’s state-run news service.
Our proxy connection lasted for approximately eight minutes before all requests began timing out. During that period, we saw some evidence that, rather than just blocking Google specifically, China ISPs may be using a much broader form of blocking of .com addresses in general, at least with the range of IP addresses under which our successful proxy connection falls.
For example, we could not connect to Baidu’s home page using baidu.com. However, we were successful using baidu.cn, an address which, for clients outside China, is redirected to baidu.com anyway. Other .cn addresses were accessible, but betanews.com was not — and I doubt we draw the attention of Chinese authorities enough to earn a spot on its blacklist.
The proxy IP address from which we were successfully able to establish the connection, should you wish to try this test for yourself, was: 218.14.227.197:3128, which traces to Beijing. Port 3128 is normally associated with proxy servers.
Last month, Microsoft sent flowers to a mock funeral for Internet Explorer 6, in a show of support for the ideal that the old browser should be declared defunct worldwide. But for a few years yet, the company is still bound to support the product for those users (generally businesses) who refuse to upgrade it. That’s why new exploits that continue to target old browsers, such as IE6 and IE7, continue to get attention even a full year after the proper security fix — IE8 — has been deployed.
One of the libraries that, among other functions, helps IE to print is the target of an exploit released to the wild earlier this month. The exploit creatively overloads the system with JavaScript variables, then places function calls to IEPEERS.DLL. Once the library is effectively crashed, its used memory isn’t cleaned up, enabling binary code seeded into that memory to be executed — a classic use-after-free scenario.
Although various IE8 and Vista-era architectures protect Windows users from this scenario, Microsoft’s security team said today it will take the unusual step of issuing an out-of-band update tomorrow, two weeks ahead of the usual Patch Tuesday. The update will also serve as a “cumulative roll-up,” adding nine other fixes that had been planned for April 13.
Microsoft has said that Data Execution Prevention in IE8 is one of the effective workarounds for this exploit, at least until tomorrow. But the US Homeland Security Dept.’s US-CERT agency warns that DEP is only a partial fix, saying, “DEP should not be treated as a complete workaround, but DEP can mitigate the execution of attacker-supplied code in some cases.” US-CERT suggests that users instead disable Active Scripting, one of the perennially sensitive elements of the old ActiveX system.
Could the manufacturers of DVD players (no, not just Blu-ray, but the original DVDs) owe back royalties to Alcatel-Lucent for the use of patented technology by way of the MPEG-2 codec? The MPEG Licensing Authority had asserted that Alcatel may have structured its 2006 merger with Lucent in such a way that it could hide up to five patents in a special trust, and spring their overdue royalties on the video industry long after DVDs already began the march to obsolescence.
That assertion was being made in a Delaware courtroom earlier this month, in a trial pertaining to a lawsuit filed by the MPEG Licensing Authority back in 2007. Today, MPEG LA — which also collects royalties for the use of MPEG-2 — announced a settlement in the case, essentially amounting to a complete defeat for Alcatel-Lucent.
The five patents that Alcatel-Lucent had maintained in what it called the Multimedia Patent Trust (MPT), will now be submitted to MPEG LA with the possibility of inclusion in the portfolio it already licenses to manufacturers — and by “possibility,” we mean, virtual certainty.
The settlement brings to a close a dispute which threatened to get ugly, over the intellectual property rights for a relatively old — and many would argue, antiquated — way of encoding video. The dispute began when Microsoft, along with computer makers Dell and Gateway (now part of Acer), were first sued by the newly merged entity on behalf of the former Lucent. Alcatel was (and still is) a member of MPEG LA itself, but Lucent was not. At the time, Alcatel-Lucent maintained it set up the trust in order to protect patents from Lucent’s old Bell Laboratories portfolio, that it asserted had not been folded into the MPEG-2 Essential Patents portfolio of MPEG LA.
“The MPT was established at the time of the merger in 2006 because Lucent Technologies had certain patents at risk of losing value because of how the merger was structured,” reads a statement from Alcatel-Lucent General Counsel Steve Reynolds ten days ago. “To preserve their value over the life of the patents, Lucent created the trust and assigned those patents to it. The trust now owns and controls those assets. Proceeds from the trust go to Alcatel-Lucent and the Alcatel-Lucent Foundation.”
At the time the computer and software makers were sued, the total valuation of the suit was estimated at over $2 billion. But even the amount has been a matter of dispute, especially since a San Diego district court judge ruled in 2008 that the patents in this case were essentially…non-essential. That devalued them at the same time it appeared to indicate they did not belong in MPEG LA’s “Essential Patents” portfolio.
Referring to a correction that Bloomberg News had to make in a report earlier this month, Alcatel-Lucent’s Reynolds added, “Because the San Diego court determined that the patents were not infringed, and therefore were not essential, we do not see how MPEG LA could claim rights to these patents under any circumstances. Our understanding is that MPEG LA claims to have rights to essential patents. By court determination, the MPT patents in the San Diego lawsuit simply don’t meet that requirement. That should have been the headline, not a sensational number about a bogus and non-existent risk.”
Testimony in the trial was already drawing to a close. In a statement to Betanews this afternoon, MPEG LA said, “The resolution of the case is consistent with the relief MPEG LA sought in its complaint.”
Either the news media is convinced that Apple’s forthcoming iPad is the vehicle for delivering news publishing out of its funk, or it’s convinced that Apple is conspiring to circumvent the natural course of news with its own walled garden platform. In any event, in the portion of the universe where the two parties are evidently not in bed with one another, the BBC reports that it has been forced to indefinitely postpone the rollout of its iPhone/iPod touch/iPad newsreader app, after the EU’s trade group for newspapers complained it could pre-empt their plans to migrate online.
Today, the BBC Trust, which sets policy for the Corporation and serves as its board of directors, put a hold on next month’s planned release of the BBC news reader, which would have been distributed for free. The BBC is sustained by UK citizens who pay regular license fees, so on paper, the reason for the delay is to determine whether free distribution of the app goes against its mandate.
But BBC News didn’t muzzle its own impression of the Trust’s intent. In its report this afternoon, it noted the Trust’s citation of “representations from industry” as contributing to its postponement decision.
Last month, after the BBC first previewed its iPhone/iPad apps at Mobile World Congress, David Newell, director of Europe’s Newspaper Publishers’ Association, issued a public statement: “This is not, as the BBC argues, an extension of its existing online service, but an intrusion into a very tightly defined, separate market. Not for the first time, the BBC is preparing to muscle into a nascent market and trample over the aspirations of commercial news providers…We strongly urge the BBC Trust to block these damaging plans, which threaten to strangle an important new market for news and information.”
Two major London newspaper publishers, the Guardian and the Telegraph, had reportedly been working on upgrades to their own iPhone/iPad apps of their own, although they would likely charge for them. Another major paper, the London Times (part of the global News Corp. operation that also runs The Wall Street Journal) recently announced its intention to place exclusive content behind a paywall, where readers will be charged £2 per week for access.
In an online op-ed yesterday, the Times defended its decision, saying it believed true customers will recognize the value of investing in real journalism. However, it could not resist the temptation (the same one that tempts almost all other News Corp. properties to openly taunt its competitors) to throw a zinger at the BBC for its free Web app plans:
We believe many readers will be prepared to pay this relatively small amount because they value our journalism and they understand that nothing of value is free…We acknowledge the risk involved when much other good journalism is still available free online. However, we believe that if we are transparent with our readers and explain the financial realities, they will support our move. Ultimately we think that other newspapers will follow, and that the only free content online will be of inferior quality or supplied by the BBC. Even that organisation is finally beginning to realise it should stop trying to become a publisher online, and is cutting back on its massive internet spending.
That might have been the Times‘ entire contribution to the debate today, were it not for an insightful comment yesterday from one of its Austria-based readers: “In an EU that is launching a new strategy, EU 2020, which aims at a Digital Agenda to ensure all citizens have access to ICT and become digitally literate, in an EU that needs to act against increasing poverty and social exclusion, in an EU where the gap between the haves and the have-nots is widening, access to information and education is vital. In a Europe that has lifelong learning as a priority, that wants to be at the competitive edge, access to independent information is crucial…Should those who cannot afford quality papers just be exposed to this type of journalism?”
EU 2020 represents Europe’s long-range goals for the economic and social development of the continent. Part of that plan is the Digital Agenda, which now incorporates the continent’s equivalent of the US FCC’s Broadband Plan, plus the division of government policy that had, under the stewardship of Commissioner Viviane Reding, been called “the Information Society.” Today, the commissioner in charge of the Digital Agenda is Neelie Kroes, fresh from the end of her term in charge of competition.
In Comm. Kroes’ mandate last November, EC President José Manuel Barroso charged her with no less than the creation of a single market for European online services — effectively, one level playing field: “I would also like you to establish an integrated single market for the delivery of electronic services. The EU possesses massive creative, cultural and multilingual potential, which efficient ICT tools can help to tap and transform into productivity gains.”
Since that time, there’s been considerable debate over whether “single market” mandates the existence of a “single platform” — in other words, not any one manufacturer’s walled garden. Who, exactly, has the rights to deliver Europe’s single platform, if there is only to be one such platform?
In a speech in January, Comm. Kroes made it clear that she perceived any attempt to divide and conquer the online platform by any one player, as a violation of the principle of net neutrality: ISPs, she said, “shouldn’t be allowed to limit the access to service or content out of commercial motivation but only in cases of security issues and spamming.”
The organization that represents Europe’s many telcos, ETNO, is a cautious supporter of Commission’s version of the broadband rollout plan. It believes such a plan could expedite the construction of a single platform, fueled by private investment (as government regulators would prefer), and centering around…naturally, service providers.
Referring to EU 2020, ETNO Director Michael Bartholomew said in a statement last month, “The achievement of these goals will depend to a great extent on the deployment of high speed broadband infrastructure and on the capacity of the private and public sectors to fully exploit the benefits of broadband networks and services. The Digital Agenda could therefore be given greater priority and a horizontal, or cross-sector, role… In order to accelerate private investment in high speed networks, these objectives must be translated into practice by national regulators, under the guidance of the European Commission, by developing a more targeted and proportionate regulatory environment. The rules applying to next generation access networks must reflect the high risks involved as well as vivid competition on today’s broadband markets.”
The ETNO’s viewpoints are not exactly new. So the very next day after Comm. Kroes’ speech, it was against that backdrop — the implication that if you want private interests funding the platform, you must accept private interests running it — that the European newspaper publishers made their play: In a policy paper (PDF available here), the group argued that newspapers are critical to attaining literacy, and a crucial part of member nations’ educational platforms. But that component is under threat from Internet service providers who would undercut their interests by building their own “single platforms” for news dissemination on small devices.
The end result: Online news apps could make Europe’s citizens dumber.
ENPA believes that the enhancement of reading skills is closely connected to the issue of media literacy. In the context of the debate launched at European level on media literacy, ENPA has highlighted to EU and national decision makers that newspapers are essential actors of the knowledge economy, in particular in educating the young generation to understand and analyse better the role of the newspapers in the democratic and public debate.
…
At this moment, the sustainability of advertising revenues for press is under increasing pressure from market competition but also from legislative and policy restrictions. Although newspapers’ brand remain a reference for advertisers, for both printed and online versions, publishers are confronted to a challenging market situation where they have to compete with new market players such as telecom operators, search engines and internet services providers.
In certain countries, the dominance of these players on the advertising market is contested as it is the case in Italy where publishers decided to complaint [sic] to the competition authorities for abuse of dominant position of Google in the advertising area. Also in France, an investigation from the competition authority in this field is also considered.
At the light of the structural changes that the press is facing at this moment, ENPA asks the Commission to ensure that the new EU digital agenda provides the necessary conditions for the growth and the sustainability of the press sector in Europe, in particular in the field of copyright but also in the field of advertising.
Put another way, a single platform for continent-wide literacy already exists in the form of the press. By “the press,” we mean “newspapers” — not Google, not Apple, and not any turncoat that would join their cause, such as the BBC.
The puzzle for software companies as they adopt Web services is how to make them profitable. Anyone who tries the ad-supported model 1) plays against Google on its home turf; 2) risks working against application efficiency; 3) could raise the ire of users. And anyone who tries offering subscription to storage space 1) could easily be outdone by the first vendor to give away all its space for free; 2) faces an uphill value proposition against cheap local storage, and free synchronization such as Windows Live Sync solving the mobility problem.
Over the past several months, we’ve seen Adobe playing up collaboration as a key feature of its Acrobat.com service, even over portability — the element that’s most often associated with Adobe. Today, we have confirmation as to why: Inaugurating a potentially lucrative subscription strategy, Adobe hopes consumers will be willing to use Web apps such as Buzzword for free, while paying monthly for the capability to share documents.
“Our goal is to help you get more done faster by moving collaboration out of your e-mail and into an Acrobat.com Shared Workspace. Sorting your inbox on date to find the latest version of a co-authored document is not ideal,” writes Adobe product evangelist Ali Hanyaloglu Sunday afternoon. “E-mail was never intended to be a content management system, but for most of us, it’s certainly being pressed into that role. With Acrobat.com, we’ve been concentrating on helping individuals work together: I invite you to my document.”
The pricing model will be tricky: Adobe is pushing a $39/month subscription fee (first two months free for customers willing to pay annually), for an essentially unlimited sharing configuration. The “shared workspace” in this case refers to the group of documents (and folders) that are accessible by multiple people. Counter to the way housing works, your own space is yours but you pay to share it with others. The “shared workspace” is the storage area for documents that you create.
This is where it gets tricky: The shared workspace does not have an obvious size limit, and as Adobe’s FAQ makes clear, “There is no limit to the number of people you can invite into a single Workspace.” So the key reason one would want multiple workspaces is in order to designate different combinations of other Acrobat.com users with whom to share documents. At $39/month, you can have any number of such combinations; but for the intermediate “Basic” plan at $14.99/month or $149/year, you can have up to 20 workspaces.
So besides the limit on Web conferencing between the higher “Plus” and the intermediate “Basic” plans (20 people versus 5), it’s the right to share with more than 20 possible groupings of any number of collaborators, that Adobe has evaluated as a $250 annual premium.
In Sunday’s blog post, Hanyaloglu suggested one reason someone might want unlimited workspaces is to be able to publish to multiple groups of customers: “if you want to create an easy-to-use space to make it more efficient to serve your customers, create a workspace for each of them where you and they can easily share and collaborate.”
Adobe is characterizing its “Free” plan as more of a trial: one workspace with a three-person limit on video conferencing. There’s another interesting limit here, too: a five-document limit on PDF conversions — no such limit on the paid plans. Here’s where one realizes the risk Adobe is taking: When Hanyaloglu refers in his blog post to consumers’ e-mail inboxes full of “nothing but paper clips,” a huge chunk of those attachments (represented by paper clips in Outlook and other clients) are PDF files. Although PDF is now officially a free international standard, Acrobat software is still the key editing product for creating and publishing PDFs.
Arguably, a collaborative workspace where files exist “in the cloud” would not require PDF conversion nearly as much as a conventional work environment where documents are shared via e-mail. So Adobe’s new business model, in one sense, competes directly against Adobe’s old business model. It’s a gamble on an evolutionary path where the brand obsoletes its own product over time, or at least one function of that product — which is not the way planned migrations typically work. Imagine a Microsoft online service that gradually renders obsolete .DOCX files — that’s not likely to happen anytime soon.
Last May, Adobe introduced Presentations as an online venue for distributing presentations for conferencing, putting Adobe in more direct competition with PowerPoint. In a sense, that’s another direct bid to obsolete conventional PDF, which in the early 2000s was being geared as a PowerPoint competitor in itself. Although Adobe Presentations can be published as PDF files (PDF with instructions available here), that’s more of an export maneuver; Presentations are actually Flash animations — substantiating Adobe’s other principal platform.
In fact, you might interpret Adobe’s entire Web apps strategy more as a bid to make Flash competitive in the applications space against AJAX and JavaScript, than to prop up any document format — even if it used to be its own.
One of the extraordinary truths about the Internet as a mechanism is that the databases that enable every IP address to be resolved, are maintained and published by a very small number of organizations acting as a cooperative. The health of the entire network depends on these groups’ vigilance. One of these groups is Autonomica AB, a division of the Swedish ISP Netnod. It operates the “I” root server, which in recent weeks has been the apparent victim of a kind of spoofing attack that’s been harmless thus far, but could conceivably demonstrate the capability of one rogue element to pollute the entire Internet.
Thanks to the current state of affairs, some are now suspecting a China-based culprit. But as we all know with the Internet, just because a malicious server resides in one country doesn’t mean its malicious operator works there as well.
As first reported yesterday by Ars Technica‘s Iljitsch van Beijnum, engineers for the world’s root servers reported on their public mailing list that certain requests sent to the “I” server for authoritative information were being resolved in a peculiar manner. Normally a root name server responds with the address of authoritative servers for a top-level domain; and thanks to a technique called anycasting, the server doing the responding may not be the same one each time. But at least one such server somewhere was occasionally responding to specific requests to resolve addresses that have the text facebook, twitter, or youtube in them (for example, www.facebook.com or whattheheckcouldthismeanforfacebook.co.uk) with apparently random IP addresses that served no function at all, malicious or otherwise. Also, requests for information on specific IP address ranges were met with similarly spoofed responses, intermittently.
On Wednesday, a root server network operator in Chile reported being told by a local ISP that one of the “I” server nodes, i.root-servers.net, was responding to requests to resolve Facebook addresses with a random IP address. When the incidents occurred, the traceroute for the “I” server runs through China. Other operators familiar with China’s track record for tinkering with IP addresses were amazed, including one Dutch operator who responded, “Wow! This is stunning. I knew that China messed with DNS internally, but not that it leaked to the outside world.”
The symptom of DNS requests for records matching a certain text pattern being met with inaccurate data, follows a trend that researchers have noticed before — which is why China emerges as a leading suspect. In December 2007, a trio of NYU researchers published the findings of research they had conducted into the veracity of DNS requests from Chinese name servers. In their paper, “The Great DNS Wall of China” (PDF available here), they demonstrated how China-based DNS servers responded to DNS requests for domains whose names consisted of random alphanumeric characters (they couldn’t possibly exist), but whose subdomains contained certain “red-flag” phrases such as falungong, voanews, and minghui (which refers to the Buddhist Falun Dafa practice). The responses, which should have been confusing as well, instead appeared to be authoritative.
In a first round of tests in which Chinese servers were asked to resolve requests for 841 domain names for which five US-based servers were in complete agreement, the trio wrote, “We observed that almost all of the Chinese DNS servers returned tampered responses for 383-393 domains and that the number of distinct IPs returned for these responses was extremely low when compared to the uniqueness of the correct responses. In fact, 366 bad domains shared eight IP addresses.”
Then the group applied the nonsense domains, which the US servers couldn’t possibly resolve. “We found that, as expected, the canonical US servers returned a ‘domain does not exist’ for all of the nonsense domains. The Chinese servers exhibited different behavior. For both the domains with a control subdomain (i.e., www) and domains that had a keyword embedded as a subdomain, the majority of the servers returned a ‘domain does not exist.’ The nonsense domains with the censored domains embedded as the subdomain triggered the same type result as the previous experiment, returning the set of eight IP addresses.”
A representative from China’s network information center CNNIC denied his department’s involvement in any spoofing activity, to the operators’ mailing list.
On July 1, 2010, DNSSEC will be deployed at the root server level, enabling encrypted and secure communication there for the first time. Theoretically, this would disable the type of spoofing exhibited here.
As the Dutch network operator commented, “Given the nature of why this is happening, this is one of the first use cases I see for DNSSEC that actually is worth the administrative overhead. Preventing Kaminsky spoofing, which appears not to be happening anyhow, is not that exciting, and may not be worth the effort. But preventing nation states from globally changing DNS traffic (even if only by accident), far beyond their shores, might be a great idea.”
That prompted a Dutch security engineer to respond with a scenario whereby a hypothetical name server decides not to employ DNSSEC after all. In his scenario, that hypothetical server could respond to requests that mandate DNSSEC be turned on, with signed connections to false copies of root zone information. “If I can control all the roots, then DNSSEC buys you just a false sense of security,” he wrote. “Control the roots, control the data.”
In the latest check of progress in the development of the major Web browsers for Windows, the brand that helped Betanews launch its regular browser performance tests appears to be making a comeback effort: With each new daily build, the WebKit browser engine — running in Apple’s Safari 4.0.5 chassis — gains computational speed that it was sorely lacking.
Safari already leads Google Chrome in the rendering department, and posts scalability scores comparable to Opera 10.51, in Betanews’ Windows 7 Relative Performance Index suite. In this morning’s round of tests using WebKit daily build 56417 on Windows 7, Safari scored a very respectable 20.27, coming up just behind the latest stable Chrome 4.1 at 21.22.
To compete effectively against Chrome and Opera, Safari/WebKit has needed to post better SunSpider computational test scores. There’s definite improvement in that department, though Safari still has a ways to go: Today’s 55.74 relative score (almost 56 times better than Microsoft Internet Explorer 7’s score on Windows Vista SP2) reflects apparent improvement in the test browser’s date handling and string manipulation functions; in all other SunSpider categories, the test browser ties or just barely exceeds the stable Safari 4 scores. Safari 4 scores 48.87 overall on the SunSpider, while Chrome 4.1 scores 59.31. The latest dev build of Chrome 5 is the SunSpider leader with 75.82, followed by the stable Opera 10.51 with 70.70.
In the SlickSpeed CSS selectors battery, the daily Safari/WebKit is now running away with the lead with a 13.87 score over Opera 10.51 at 12.19, and the Chrome 5 dev build at 12.83. That shows how adept the new WebKit code is at manipulating CSS components in memory; anyone wanting to be “the HTML 5 browser” will need to master this department. But in the old school of layout — the HTML 1 <TABLE> element — Safari/WebKit also shows poise with an 8.26 score. Only Chrome 4.1 is ahead in that department with an impressive 9.49.
It’s with the new DFScale suite that I’ve intended to learn more of the whys-and-wherefores of browsers’ performance. Overall, Safari/WebKit’s speed score is in the middle of the field (37.12 versus Chrome 5’s 53.90), but its scalability scores are quite respectable (9.40 versus 10.93, respectively). What that means is, WebKit is very adept at finding new efficiencies when working with heavier workloads — a process I call “finding another gear.”
You can see this process at work in the numbers for the Merge Sort test: The stable Safari 4 took 8 ms (.008 seconds) to sort a 500-unit array, and 20.1 seconds to sort a 25,000 unit array. If the Merge Sort problem scaled linearly (it doesn’t), it would have taken Safari 4 0.4 seconds to sort the larger array. With the daily WebKit doing the JavaScript and rendering instead, the browser sorts the same 25,000 unit array in 9.8 seconds.
This same phenomenon would probably make Safari/WebKit the leader in the Heap Sort test as well, if it were capable of running the 10 million iteration test along with Chrome. For the Heap Sort grid numbers it can run (up to 1 million), it scales very impressively, starting out just about even with the latest Opera 10.52 snapshot (released yesterday), but then beating it at 1 million iterations at 3.1 versus 4.1 seconds. Safari/WebKit has a better time with scaling exponential problems higher than with linear problems like Euler’s Problem #14.
Long-time readers will recall there used to be a browser called Firefox that figured prominently in tests like ours. Well, the news hasn’t been good for Firefox in recent days, especially with scores from the daily builds of version 3.7 alpha dipping a few tenths (even after a scoring adjustment, see below), from 10.76 last week to 10.23 today.
One of the most stark differences in the way browsers work is revealed in the results of the Problem #14 test, between Firefox and Safari. Our “How it works and why” report goes into detail about the two phases of this test, called “naïve” and “optimized.” In assembling successive chains of numbers that follow two math rules, eventually one chain will run into a value that appears at the head of another chain. At that point, the “optimized” version of the test appends that other chain onto the end of the current one, while the “naïve” version blindly moves forward through to the end of the chain.
The Safari/WebKit daily build executes the “naïve” 1 million iteration Problem #14 test in about 7.9 seconds; and it shaves over three seconds off that mark in the “optimized” version, for a 4.7 seconds total. By comparison, the latest daily build of Firefox 3.7 Alpha 4 takes 94 seconds to run the “naïve” test. But optimization scales that number down to 6.8 seconds, which actually beats the stable Safari 4’s 6.9 seconds. The suggestion here is that Firefox tends…to…slow…way…do…wn as a chain gets longer and longer, whereas Safari only slows down very slightly. Again, this gets to the whole issue of scalability: the ability to find the extra gear as the workload increases.
Now, a slight scoring methodology change to note since our report last week: In the new DFScale suite, I noticed that variations in the time values for the lower grid numbers made for less-than-desirable oscillations in the averages. For example, in a few cases, a test where a browser would perform in 3 ms half the time and 2 ms the other half (when the real value is probably more like 2.5), would jostle the averages wildly. So for the time being, I’m not counting the time values in the lowest one or two grid numbers as among the time averages, although they still count as points toward scalability. The adjustment did affect the score for the IE9 Platform Preview…on the positive side. We’re now scoring it at 13.38 overall, a few ticks above last week.
A US Government Accounting Office report released yesterday (PDF available here) reveals an astonishing and counter-intuitive trend: Government agencies’ compliance with directives intended to improve information security has declined in inverse proportion to the amount of training they receive.
In a report to the House Government Management Subcommittee yesterday, the GAO cited increased awareness of the provisions of the Federal Information Security Management Act (FISMA), due to increased awareness training among the 24 federal agencies tested: 91% of employees in those agencies received testing in fiscal 2009, up 3% from the previous year. But specifically in light of increased exposure to the Gumblar Trojan and the Conficker worm, at least 17 of those agencies were reported to have enacted deficient responses to these increasing threats, including essentially assigning the entire job of security to just one person — against FISMA’s mandate.
Two of the agencies where GAO inspectors reported the most shocking problems were NASA and the Los Alamos National Laboratory. The GAO report chastised Los Alamos in particular: “Specifically, (1) risk assessments were not comprehensive, (2) specific guidance was missing from policies and procedures, (3) the training and awareness program did not adequately address specialized training needs for individuals with significant network security responsibilities, (4) system security plans were incomplete, (5) the system security testing and evaluation process had shortcomings, (6) corrective action plans were not comprehensive, and (7) contingency plans were incomplete and not tested. In addition, the laboratory’s decentralized management approach has led to weaknesses in the effectiveness of its classified cybersecurity program. Although the laboratory has taken steps to address these weaknesses, its efforts may be limited because LANL has not demonstrated a consistent capacity to sustain security improvements over the long term.”
The news for NASA was similar, particularly highlighting that agency’s failure to consistently detect and report security incidents. GAO believes that the problem isn’t one of poor software or even bad training. It’s a management problem, the report says — an apparent case of indecision about spreading the responsibility for security among everyone.
This despite the fact that the quantity of security incidents on government agency systems that were reported properly, has increased by some 400% over a three-year period.
GAO cites the continued need for a comprehensive national cybersecurity strategy, as outlined by President Bush in 2008 when he launched the Comprehensive National Security Initiative (CNSI). The Office suggests that CNSI be given more time to achieve the goals set out for it. But as one example from the report describes, the National Institute of Science and Technology’s recommendations for securing systems with Windows XP and Windows Vista, is still ongoing, and would be one of those programs that GAO recommends continue. It does not appear that this program, as implemented in 2008, would encompass the simple matter of upgrading to Windows 7.
The most powerful deterrent against the use of man-in-the-middle attacks against SSL/TLS-encrypted connections may be how much easier it may be to simply attack from the endpoint. Certainly “man-in-the-middle” sounds more sophisticated, and as a pair of well-known academic researchers are preparing to report, the phrase has actually become a “starburst” marketing point for the sale of digital surveillance equipment to government agencies.
But perhaps the most serious defect in the SSL system, allege Indiana University graduate student Christopher Soghoian and Mozilla security contributor Sid Stamm, lies in the ability of government agencies (or individuals acting in the name of government agencies) to acquire false intermediate certificates for SSL encrypted trust connections. Those certificates could enable them to, in turn, sign and authenticate Web site SSL certificates that purport to be legitimate collectors of personal information, such as banks.
In the draft of a research paper released today (PDF available here), Soghoian and Stamm tell the story of a recent security conference where at least one vendor touted its ability to be dropped seamlessly among a cluster of IP hosts, intercept traffic among the computers there, and echo the contents of that traffic using a tunneling protocol. The tool for this surveillance, marketed by an Arizona-based firm called Packet Forensics, purports to leverage man-in-the-middle attack strategies against SSL’s underlying cryptographic protocol.
“Using ‘man-in-the-middle’ to intercept TLS or SSL is essentially an attack against the underlying Diffie-Hellman cryptographic key agreement protocol,” reads a Packet Forensics sales brochure obtained by the researchers. “To protect against such attacks, public key infrastructure (‘PKI’) is often used to authenticate one or more sides of the tunnel by exchanging certain keys in advance, usually out-of-band. This is meant to provide assurance that no one is acting as an intermediary. Secure Web access (HTTP-S) is the best example of this, because when an unexpected key is encountered, a Web browser can warn the subject and give them an opportunity to accept the key or decline the connection. To use our product in this scenario, users have the ability to import a copy of any legitimate key they obtain (potentially by court order) or they can generate ‘look-alike’ keys designed to give the subject a false sense of confidence in its authenticity.”
As the researchers report, in a conversation with the vendor’s CEO, he confirmed that government agencies can compel certificate authorities (CAs) such as VeriSign to provide them with phony certificates that appear to be signed by legitimate root certificates.
So if someone is browsing a Web site whose SSL/TLS connection appears to be signed by a legitimate authority, and renegotiation (a big problem for SSL in recent months) enables the certificate securing that connection to be swapped out for a second one that appears to be signed using the same authority (because it was, but on order of a government agency), the browser may not inform the user. Suddenly a surveillance operative is acting as though he’d performed a man-in-the-middle attack like the one described in the sales brochure…but it’s not really the same. The operative doesn’t break the chain of trust in this scenario; instead, it falsifies the trust.
The researchers have developed a threat model based on their discoveries, superimposing government agencies in the typical role of the malicious user. They call this model the compelled certificate creation attack.
As Soghoian and Stamm write, “When compelling the assistance of a CA, the government agency can either require the CA to issue it a specific certificate for each Web site to be spoofed, or, more likely, the CA can be forced to issue an intermediate CA certificate that can then be re-used an infinite number of times by that government agency, without the knowledge or further assistance of the CA. In one hypothetical example of this attack, the US National Security Agency (NSA) can compel VeriSign to produce a valid certificate for the Commercial Bank of Dubai (whose actual certificate is issued by Etisalat, UAE), that can be used to perform an effective man-in-the-middle attack against users of all modern browsers.”
The researchers offered a number of such hypothetical attacks, most of which named governments and real certificate authorities (among them: VeriSign, Etisalat) by name, even though they repeatedly asserted they had no evidence that any of these governments or any of these CAs participated in such activity. “Nevertheless, VeriSign, the largest provider of SSL certificates in the world, whose customers include many foreign banks, companies and governments from countries that do not have friendly relations with the United States, also happens to make significant sums of money by facilitating the disclosure of US consumers’ private data to US government law enforcement and intelligence agencies. This fact alone may be sufficient to give some foreign organizations good reason to question their choice of CA,” they wrote.
The researchers do have a significant personal interest in this issue: They’re working on a Firefox add-on called Certlock, yet to be released, which will augment the warnings Firefox typically presents about unusual certificate behavior. Users will be given the opportunity, for example, to take note when a certificate signing one site has itself been signed by a root certificate authority in another country or district — for example, a “protected” Hong Kong Web service signed by mainland China.
As Stamm and Sogohian write, “When a user re-visits a SSL protected Web site, Certlock first calculates the hash of the site’s certificate and compares it to the stored hash from previous visits. If it hasn’t changed, the page is loaded without warning. If the certificate has changed, the CAs that issued the old and new certificates are compared. If the CAs are the same, or from the same country, the page is loaded without any warning. If, on the other hand, the CAs’ countries differ, then the user will see a warning.”
The question of whether a user should automatically trust all the certificates in his browser’s root store, became a sticky one for Mozilla earlier this year. At that time, the organization added the state-run China Internet Network Information Center (CNNIC) to its store of trusted roots, a decision which upset many Chinese users who have reason to believe China forges its own trust links in order to conduct man-in-the-middle (or from another aspect, “man-at-the-top”) surveillance.
“We Chinese users don’t trust CNNIC…CNNIC is an infamous organ of the Chinese Communist government to monitor and control the Internet in China,” wrote a Mozilla contributor last January, in response to a request for public comment. “For secret reasons they even distributed spyware by making advantage of their administration privilege. They’re one of the tools used by the CCP government to censor the Internet users. If CNNIC root certificate is added by default as Builtin Object, they can forge verified Gmail certificates to cheat the Chinese users by using MITM attack against the SSL protocol.”
Other contributors agreed there may not be due cause to withdraw CNNIC from Firefox’s root store, until specific evidence of claims such as this one emerges. In the meantime, many suggested the browser should arm the user with more information about the nature of the certificates he receives, as well as when and how trusted connections change. The problem with too much information, however — as Microsoft discovered with Windows Vista — is that users can eventually come to ignore it.
As another Mozilla participant queried in February, “Legitimate certificates do change over time…even Google has changed certificates a few times recently. Let me ask, how many of you — yes you, the Internet experts — have called Google to verify the change of the certificate? Let alone those writers, spiritual leaders, dissidents, farmers deprived of their land, parents whose children were buried in the bribed-to-poorly-built-school and were denied compensation and denied legal assistance, and relatives of Falun Gong practitioners whose organs are taken…You expect them to record and call to verify every certificate change?”
“Thanks to the efforts of the Federal Communications Commission, we now have a National Broadband Plan, which lays out a vision for a vibrant broadband and Internet marketplace,” began Verizon Executive Vice President for Public Affairs Tom Tauke, in a speech to the Washington think tank New Democrat Network yesterday. But that’s where the perfunctory appreciation stopped: “In my view, the current statute is badly out of date. Now is the time to focus on updating the law affecting the Internet. To fulfill broadband’s potential it’s time for Congress to take a fresh look at our nation’s communications policy framework.”
It was an important speech not only for who was speaking, but where it was spoken: NDN is perhaps the furthest thing from a libertarian free-enterprise institute. It’s a group of active Democrats who are celebrating the passage of step one of health care reform, and who believe that federal policy reform can reset and reinvigorate the public agenda, on issues including broadband buildout and human rights. Verizon cozying up to NDN would be like allying itself with Google…but then again, it has allied itself with Google.
What Tauke and Verizon appear to be doing is carefully connecting with the audience best equipped to move Verizon’s technology agenda forward, with a message that would seem more naturally tailored to suit that group’s opposition. In an amazing high-wire act yesterday that appears likely to be deemed successful, Tauke advocated to a group of supporters of FCC Chairman Julius Genachowski’s new federal Broadband Plan, a rewriting of telecom laws that could conceivably take the FCC out of the Internet picture altogether.
“Verizon’s effort over the last year or two to find common ground with Google and others on the issues of net neutrality, behavioral advertising, privacy protection, and other Internet policies, really brought home to me the dilemma we face,” Tauke continued. “Too often these important discussions about policy for the Internet degenerated into disputes over the statutory authority of the FCC. Then, with the Comcast / BitTorrent case, it became clear that the debate over jurisdiction wasn’t just an intellectual exercise. The authority of the FCC to regulate broadband providers under the so-called ‘Information Services’ title, or Title I, of the Communications Act was at best murky.”
Title I is the federal statute that effectively created the FCC, giving it the authority to regulate American communications systems. But that was in 1934, when there were the public airwaves and the telephone. That statute was amended in 1996, but the new language inserted a concept of “information services” whose regulation would fall under FCC guidelines. But the Internet isn’t just a two-way newspaper; business transactions take place here every moment. And the FCC has never had the authority to regulate business transactions. Title II of the statute applies to telephone networks, and one option under consideration is simply declaring broadband a telephone network.
If you ask the FCC commissioners outright, they’d say they don’t want either outcome — either to be the online equivalent of the FTC, or the modern overseer of the online Bell System. But denying either option, some say, would have the FCC forfeit its right to tell Comcast not to throttle BitTorrent traffic — the subject of the DC Court of Appeals case to which Tauke referred. There, judges have indicated they may very well rule in Comcast’s favor. If they do, the entire question of whether the FCC has the authority to execute the Broadband Plan, would be turned on its ear.
You’d think that would make Verizon happy. But in front of the NDN yesterday, Tom Tauke put a virtual piece of duct tape over that grin.
“One idea recently floated to solidify the FCC’s jurisdiction was to place broadband under the old rules that applied to telephone networks under Title II. To us, that clearly was outside the scope of the statute,” Verizon’s Tom Tauke told the New Democrat Network yesterday. “It also highlighted the danger of attempting to apply statutory provisions intended for the telephone industry of the 1900s to the communications and Internet world of the 21st Century. In confronting this hard question about jurisdictional authority, we also faced this policy question: If Title I and Title II don’t apply to the Internet space, what are you saying about the authority of government in this space?”
Long-time followers of the campaign for free enterprise among Internet stakeholders are familiar with the key phrase “light touch” — a phrase coined by former FCC Chairman Bill Kennard (who served under Pres. Clinton, and who is now US Ambassador to the EU). With respect to broadband, it represented Chairman Kennard’s perspective that government should only step in to keep competitors in bounds, but should otherwise let the market decide how the nation’s broadband network is built.
It was an ingenious campaign, largely because it quelled the growing arguments of legislators on both sides of the issue of the FCC’s role in broadband. Those opposed to the FCC having any role at all, on the grounds that the Internet was not like the public telephone network or the public airwaves, appreciated the FCC saying its own role should be limited. And those who favored more rigorous regulation of the market to stop unfair competition — for instance, from a potential behemoth such as AOL Time Warner — appreciated that the FCC would continue to keep a lookout for unfair business practices.
“The approach Bill Kennard talked about years ago of using a light regulatory hand to create a highly competitive marketplace has worked,” stated Tauke, praising a well-liked Clinton-era Democrat. “Now, we need to put in place a framework that will continue to encourage ongoing investment and innovation for this vibrant ecosystem we see. This should be the cornerstone for a refreshed policy framework.
“So what’s the problem? The problem is that the statute is irrelevant to the ecosystem that has developed. The Internet today hosts a quarter of the world’s population — close to two billion users. The Verizon network alone connects 100 million of these users with over 1.7 billion text messages and 50 million video/pictures exchanged, 400 million e-mails received, 8.7 petabytes of video streamed. There are new pressures and challenges and problems cropping up that policymakers didn’t consider a decade ago, such as the 5 billion potential cyber-threats monitored and acted upon each day.”
Next: The vision of an Internet without the FCC…
The vision of an Internet without the FCC
Now that the Broadband Plan (which some say is more a list of goals than a concrete agenda) has been published, there is renewed debate over whether a federal government agency should be dictating just how broadband buildout in this country is to be completed, and which companies should be the ones doing it in what areas. What Verizon would want is an authority comparable to Bill Kennard’s 1990s vision of the FCC in the broadband space. But if Julius Genachowski’s 2010s FCC resembles something different, maybe there’s a new way to go about realizing that early vision.
“The instinct is to impose regulation, but it’s a balancing act. We want order, but we also don’t want to hinder investment and innovation in this dynamic broadband and Internet marketplace. How do we accomplish this?” asked Tauke.
He immediately responded by saying he didn’t have all the answers. But then he adeptly proposed one: essentially, implicitly, and without fanfare, the creation of a new federal rulemaking authority overseeing just the Internet:
“Traditional agency ‘fact finding’ — often through notices or public requests for comment — are usually geared towards specific rules or regulatory outcomes. Instead, we could structure a process that uses the innovative, flexible and technology-driven nature of the Internet to address issues as they arise. Instead of the traditional rule-making process, federal enforcement agencies could structure themselves around an on-going engagement with Internet engineers and technologists to analyze technology trends, define norms to guide such questions as network management, and understand in advance the implications of new, emerging technologies. Technology leaders and experts from all players involved in the Internet should set up voluntary organizations and forums to provide advice, recommendations, and advisory opinions to government agencies. This will help inform the agencies’ role as backstops that deter damaging activities that undermine the vibrant competition and openness that defines the Internet.”
This new agency was nameless in Tauke’s speech, except for the fact that it did not bear the name “Federal Communications Commission.”
It should be a Republican plan. But Republicans aren’t in the majority at the moment (and if Tea Partiers keep throwing bricks through Congresspersons’ windows and leaving death threats on their answering machines, Republicans could end up staying there). Tauke’s proposal has the virtue of implicitly creating an entirely new government agency (that should be fun!). And it would empower that agency to give government grants to low-income households who would otherwise not be able to afford service — the kind of approach that resounds with more liberal agendas.
The NDN has yet to issue a response, though one is likely forthcoming, and will be well thought-out. And if it ends up supporting Tauke’s position, somewhere over the horizon, one might glimpse the face of Sun Tzu smiling.
The Betanews test suite for Windows-based Web browsers is a set of tools for measuring the performance, compliance, and scalability of the processing component of browsers, particularly their JavaScript engines and CSS renderers. Our suite does not test the act of loading pages over the Internet, or anything else that is directly dependent on the speed of the network.
But what is it measuring, really? The suite is measuring the browser’s capability to perform instructions and produce results. In the early days of microcomputing, computers (before we called them PCs) came with interpreters that processed instructions and produced results. Today, browsers are the virtual equivalent of Apple IIs and TRS-80s — they process instructions, and produce results. Many folks think they’re just using browsers to view blog pages and check the scores. And then I catch them watching Hulu or playing a game on Facebook or doing something silly on Miniclip, and surprise, they’re not just reading the paper online anymore. More and more, a browser is a virtual computer.
So I test it like a computer, not like a football scoreboard. The final result is a raw number that, for the first time on Betanews, can be segmented into three categories: computational performance (raw number crunching), rendering performance, and scalability (defined momentarily). These categories are like three aspects of a computer; they are not all the aspects of a computer, but they are three important ones. They’re useful because they help you to appreciate the different browsers for the quality of the work they are capable of providing.
Many folks tell me they don’t do anything with their browsers that requires any significant number crunching. The most direct response I have to this is: Wrong. Web pages are sophisticated pieces of software, especially where cross-domain sharing is involved. They’re not pre-printed and reproduced like something from a fax machine; more and more, they’re adaptive composites of both textual and graphic components from a multitude of sources, that come together dynamically. The degree of math required to make everything flow and align just right, is severely under-appreciated.
Why is everything relative?
By showing relative performance, the aim of the RPI index is to give you a simple-to-understand gauge of how two or more browsers compare to one another on any machine you install them on. That’s why we don’t render results in milliseconds. Instead, all of our results are multiples of the performance of a relatively slow Web browser that is not a recent edition: Microsoft Internet Explorer 7, running on Windows Vista SP2 (the slower of the three most recent Windows versions), on the same machine (more about the machine itself later).
I’m often asked, why don’t I show results relative to IE8, a more recent version? The answer is simple: It wouldn’t be fair. Many users prefer IE8 and deserve a real measurement of its performance. When Internet Explorer 9 debuts, I will switch the index to reflect a multiple of IE8 performance. In years to come, however, I predict it will be more difficult to find a consistently slow browser on which to base our index. I don’t think it’s fair for anyone, including us, to presume IE will always be the slowest brand in the pack.
Browsers will continue to evolve; and as they do, certain elements of our test suite may become antiquated, or unnecessary. But that time hasn’t come yet. JavaScript interpreters are, for now, inherently single-threaded. So the notion that there may be some interpreters better suited to multi-core processors, has not been borne out by our investigation, including from the information we’ve been given by browser manufacturers. Also, although basic Web standards compliance continues to be important (our tests impose a rendering penalty for not following standards, where applicable), HTML 5 compliance is not a reality for any single browser brand. Everyone, including Microsoft, wants to be the quintessential HTML 5 browser, but the final working draft of the standard was only published by W3C weeks ago.
There will be a time when HTML 5 compliance should be mandatory, and we’ll adapt when the time comes.
What’s this “scalability” thing?
In speaking recently with browser makers — especially with the leader of the IE team at Microsoft, Dean Hachamovitch — I came to agree with a very fair argument about our existing test suite: It failed to account for performance under stress, specifically with regard to each browser’s capability to crunch harder tasks and process them faster when necessary.
A simple machine slows down proportionately as its workload increases linearly. A well-programmed interpreter is capable of literally pre-digesting the tasks in front of it, so that at the very least it doesn’t slow down as much — if planned well, it can accelerate. Typical benchmarks have the browser perform a number of tasks repetitively. But because JavaScript interpreters are (for now) single-threaded, when scripts are written to interrupt a sequence of reiterative instructions every second or so — for instance, to update the elapsed time reading, or to spin some icon to remind the user the script is running — that very act works against the interpreter’s efficiency. Specifically, it inserts events into the stream that disrupt the flow of the test, and work against the ability of the interpreter to break it down further. As I discovered when bringing together some tried and true algorithms for our new test suite, including one-second or even ten-second timeouts messes with the results.
Up to now, the third-party test suites we’ve been using (SunSpider, SlickSpeed, JSBenchmark) perform short bursts of instructions and measure the throughput within given intervals. These are fair tests, but only under narrow circumstances. With the tracing abilities of JavaScript interpreters used in Firefox, Opera, and the WebKit-based browsers, the way huge sequences of reiterative processes are digested, is different than the way short bursts are digested. I discovered this, with the help of engineers from Opera, when debugging the old test battery I’ve since thrown out of our suite: A smart JIT compiler can effectively dissolve a thousand or a million or ten million instructions that effectively do nothing, into a few void instructions that accomplish the same nothing. So if a test pops up a “0 ms” result, and you increase the workload by a factor of, say, a million, and it still pops up “0 ms”…that’s not an error. That’s the sign of a smart JIT compiler.
The proof of this premise also shows up when you vary the workload of a test that does a little something more than nothing: Browsers like Chrome accelerate the throughput when the workload is greater. So if their interpreters “knew” the workload was great to begin with, rather than just short bursts or, instead, infinite loops broken by timeouts (whose depth perhaps cannot be traced in advance), they might actually present better results.
That’s why I’ve decided to make scalability count for one-third of our overall score: Perhaps an interpreter that’s not the fastest to begin with, is still capable of finding that extra gear when the workload gets tougher; and perhaps we could appreciate that fact if we only took the time to do so.
Next: The newest member of the suite…
The newest member of the suite
Decades ago, back when I tested the efficiency of BASIC and C compilers, I published the results under my old pseudonym, “D. F. Scott.” In honor of my former “me,” I named our latest benchmark test battery “DFScale.”
It has ten components, two of which are broken into two sub-components, for a total of 12 tests. Each component renders results on a grid which is divided into numbers of total iterations: 20, 22, 24, 30, 100, 250, 500, 1000, 10000, 25000, 50000, 100000, 250000, 500000, 1000000, and 10000000. Not every component can go that high. By that, I mean that at high levels, the browser can crash, or hang, or even generate stack overflow errors. Until I am satisfied that these errors are not exploitable for malicious purposes, I will not release the DFScale suite to the public.
On the low end of the scale, I scale some components up where the iteration numbers are too low to make meaningful judgments. So for a test whose difficulty scales exponentially — and rapidly — like the Fibonacci sequence, for instance, I stick to the low end of the scale.
Some tests involve the use of arrays of random integers, whose size and scale equally correspond to the grid numbers. So an array of 10,000 units, for example, would contain random values from 1 to 10,000. Yes, we use the fairer random number generator and value shuffler used by Microsoft to correct its browser choice screen, in an incident brought to the public’s attention in early March by IBM’s Rob Weir. In fact, the shuffler is one of our tests; and in honor of Weir, we named the test the “Rob Weir Shuffle.”
To ensure fairness, we randomize and shuffle the arrays that components will use (except for the separate test of the “Weir Shuffle”) at the start of runtime. Then components will sort through copies of the same shuffled arrays, rather than regenerate new ones.
Reiterative loops run uninterrupted on each browser, which is something that some browsers don’t like. Internet Explorer stops “runaway” loops to ask the user if she wishes to continue; to keep this from happening, we tweaked the System Registry. Chrome puts up a warning giving the user the option to stop the loop, but that warning is on a separate thread which apparently does not slow down the loop.
Each component of DFScale produces a pair of scores, for speed and scalability, which require Excel for us to tally. The speed score is the average of the iterations per second for each grid number. The scalability score is a product of two elements: First, the raw times for each grid number are plotted geometrically on the y-axis, with the numbers of iterations on the x-axis. We then estimate a best-fit line, and calculate the slope of that line. The lower the slope, the higher the score. Secondly, we estimate a best-fit exponential curve, representing the amount of acceleration a JIT compiler can provide over time. Again, the lower the curve’s coefficient, the flatter the curve is, and the higher the score.
Rather than attribute arbitrary numbers to that score, we compare the slope and coefficient values to those generated from a test of IE7 in Vista SP2. Otherwise, saying that browser A scored a 3 and browser B scored a 12, would be meaningless — twelve of what? So the final score on a component is 50% slope, 50% curve, relative to IE7.
The ten tests in the (current) DFScale suite are as follows:
The “Rob Weir Shuffle” – or rather, the fairer array shuffling algorithm made popular by Weir’s disassembly of the standard random number generator in IE.
The Sieve of Eratosthenes (which I used so often during the ’80s that several readers suggested it be officially renamed “The D. F. Sieve”). It’s the algorithm used to identify prime numbers in a long sequence; and here, the sequence lengths are determined by the grid numbers.
The Fibonacci sequence, which is an algorithm that produces integers that are each the sum of the previous two. Of the many ways of expressing this algorithm, we picked two with somewhat different construction. The first compresses the entire comparison operation into a single instruction, using an alternative syntax first introduced in C. The second breaks down the operation into multiple instructions — and because it’s longer, you’d think it would be harder to run. It’s not, because the alternative syntax ends up being more difficult for JIT compilers to digest, which is why the longer form has been dubbed the “Fast Fib.”
The native JavaScript sort() method, which isn’t really a JavaScript algorithm at all, but a basic test of each browser’s ability to sort an array using native code. In the real world, the sort() method is the typical way developers will handle large arrays; they don’t include their own QuickSort or Heap Sort scripts. The reason we test these other sorting algorithms (to be explained further) is to examine the different ways JavaScript interpreters handle and break down reiterative tasks. The native method can conceivably act as a benchmark for relative efficiency; and amazingly, external scripts can be faster than the native method, especially in Google Chrome.
Radix Sort is an algorithm that simulates the actions of an old IBM punch-card sorter, which sorted a stack of cards based on their 0 – 9 digits at various locations. No one would dare use this algorithm today for real sorting, but it does test each browser’s ability to scale up a fixed and predictable set of rules, when the complexity of the problem scales exponentially. Nearly all browsers are somewhat slower with the Radix at larger values, with IE8 dramatically slower.
QuickSort is the time-tested “divide-and-conquer” approach to sorting lists or arrays, that often remains the algorithm of choice for large indexes. It picks a random array value, called a “pivot point,” and then shuffles the others to one side or the other based on their relative value. The result are groups of lower and higher values that are separated from one another, and can in turn be sorted as smaller groups.
Merge Sort is a more complex approach to divide-and-conquer that is often used for sorting objects with properties rather than just arrays. It efficiently divides a complex array into smaller arrays within a binary tree, sorts the smaller ones, and then integrates the results with bigger ones as it goes along. It’s also very memory intensive, because it breaks up the problem all over the place. (If the video below doesn’t explain it for you, then at least it will give you something to temper your nightmares.)
Bubble Sort is the quintessential test of the simplest, if least efficient, methodology for attacking a problem: It compares two adjacent values in the array repetitively, and keeps moving the highest one further forward…until it can’t do that anymore, at which point, it declares the array sorted. As a program, it should break down extremely simply, which should give interpreters an excuse to find that extra gear…if it has one. If it doesn’t, the sort times will scale very exponentially as the problem size scales linearly.
Heap Sort has been said to be the most stable performer of all the sort algorithms. Naturally, this is the one that gives our browsers the most fits — the stack overflow errors happen here. Safari handles the error condition by simply refusing to crash, but ending the loop — which speaks well for its security. It cannot perform this test at ten million iterations. Other browsers…can force a reboot if the problem size is too high. Essentially, its task is to weed out high values from a shrinking array. The weeds are piled atop a heap, and the pile forms a sorted array.
Euler’s Problem #14 is a wonderful discovery I made while searching for a test that was similar in some ways to, but different in others from, the Fibonacci sequence. The page where I discovered it grabbed my attention for its headline, “Yet Another Meaningless JavaScript Benchmark,” which somehow touched my soul. The challenge for this problem was to find a way of demonstrating the “unproven conjecture” that a particular chain of numbers, starting with any given integer value and following only two rules, would eventually pare down to 1. The rules are: 1) if the value is even, the next value in the chain is the current one divided by 2; 2) if the value is odd, the next one is equal to three times the current one, plus 1. Our test runs the conjecture with the first 1000, 10000, 25000 integers, and so on. The problem should scale almost linearly, giving interpreters the opportunity to push the envelope and accelerate. In our first test of the IE9 Tech Preview, it appeared to be accelerating very well, running the first 250,000 integer sequence in 0.794 seconds versus 10.9 seconds for IE8. Alas, IE9 is not yet stable enough to run the test with higher values.
Problem 14 is also interesting for us because we test it two ways, suggested by blogger and developer Motti Kanzkron: He realized that at some point, future sequences would always touch upon a digit used in previous sequences, whose successive values in the chain would always be the same. So there’s no need to complete the rest of the sequence if it’s already been done once; his optimization borrows memory to tack old sequences onto new ones and move forward. We compare the brute-force “naïve” version to the smart “optimized” version, to judge the ability of a JIT compiler to optimize code compared to an optimization that would be more obvious to a programmer.
Next: The other third-party test batteries…
The other third-party test batteries
Since we started testing browsers in early 2009, Betanews has maintained one very important methodology: We take a slow Web browser that you might not be using much anymore, and we pick on its sorry self as our test subject. We base our index on the assessed speed of Microsoft Internet Explorer 7 on Windows Vista SP2 — the slowest browser still in common use. For every test in the suite, we give IE7 a 1.0 score. Then we combine the test scores to derive an RPI index number that, in our estimate, best represents the relative performance of each browser compared to IE7. So for example, if a browser gets a score of 6.5, we believe that once you take every important factor into account, that browser provides 650% the performance of IE7.
We believe that “performance” means doing the complete job of providing rendering and functionality the way you expect, and the way Web developers expect. So we combine computational efficiency, rendering efficiency (coupled with standards compliance tests), and scalability. This way, a browser with a 6.5 score can be thought of as doing the job more than five times faster and better.
Here now are the other third-party batteries we use for our Browser Test Suite 3.0, and how we’ve modified them where necessary to suit our purposes:
Nontroppo CSS rendering test. Up until recently, we were using a modified version of a rendering test used by HowToCreate.co.uk, whose two purposes have been to time how long it takes to re-render the contents of multiple arrays of <DIV> elements and to time the loading of the page that includes those elements. The reason we modified this page was because the JavaScript onLoad event fires at different times for different browsers — despite its documented purpose, it doesn’t necessarily mean the page is “loaded.” There’s a real-world reason for these variations: In Apple Safari, for instance, some page contents can be styled the moment they’re available, but before the complete page is rendered, so firing the event early enables the browser to do its job faster — in other words, Apple doesn’t just do this to cheat. But the actual creators of the test themselves, at nontroppo.org, did a better job of compensating for the variations than we did: Specifically, the new version now tests to see when the browser is capable of accessing that first <DIV> element, even if (and especially when) the page is still loading.
Here’s how we developed our new score for this test battery: There are three loading events: one for Document Object Model (DOM) availability, one for first element access, and the third being the conventional onLoad event. We counted DOM load as one sixth, first access as two sixths, and onLoad as three sixths of the rendering score. Then we adjusted the re-rendering part of the test so that it iterates 50 times instead of just five. This is because some browsers do not count milliseconds properly in some platforms — this is the reason why Opera mysteriously mis-reported its own speed in Windows XP as slower than it was. (Opera users everywhere…you were right, and we thank you for your persistence.) By running the test for 10 iterations for five loops, we can get a more accurate estimate of the average time for each iteration because the millisecond timer will have updated correctly. The element loading and re-rendering scores are averaged together for a new and revised cumulative score — one which readers will discover is much fairer to both Opera and Safari than our previous version.
Celtic Kane JSBenchmark.The new JSBenchmark from Sean P. Kane is a modern version of the classic math tests first made popular, if you can believe it, by folks like myself who tested compilers for computer magazines. QuickSort is covered here too, and in this case, JSBenchmark renders relative throughput during a given interval. There’s other problems too, including one called the “Genetic Salesman,” which finds the shortest route through a geometrically complex maze. It’s good to see a modern take on my old favorites. Rather than run a fixed number of iterations and time the result, JSBenchmark runs an undetermined number of iterations within a fixed period of time, and produces indexes that represent the relative efficiency of each algorithm during that set period — higher numbers are better.
SunSpider JavaScript benchmark. Maybe the most respected general benchmark suite in the field, SunSpider focuses on computational JavaScript performance rather than rendering — the raw ability of the browser’s underlying JavaScript engine. It comes from the folks who produce the WebKit open source rendering engine that currently has closer ties with Safari, but we’ve found SunSpider’s results to appear fair and realistic, and not weighted toward WebKit-based browsers. There are nine categories of real-world computational tests (3D geometry, memory access, bitwise operations, complex program control flow, cryptography, date objects, math objects, regular expressions, and string manipulation). Each test in this battery is much more complex, and more in-tune with real functions that Web browsers would perform every day, than the more generalized, classic approach now adopted by JSBenchmark. All nine categories are scored and average relative to IE7 in Vista SP2.
Mozilla 3D cube by Simon Speich, also known as Testcube 3D, is an unusual discovery from an unusual source: an independent Swiss developer who devised a simple and quick test of DHTML 3D rendering while researching the origins of a bug in Firefox. That bug has been addressed already, but the test fulfills a useful function for us: It tests only graphical dynamic HTML rendering — which is finally becoming more important thanks to more capable JavaScript engines. And it’s not weighted toward Mozilla — it’s a fair test of anyone’s DHTML capabilities.
There are two simple heats whose purpose is to draw an ordinary wireframe cube and rotate it in space, accounting for forward-facing surfaces. Each heat produces a set of five results: total elapsed time, the amount of that time spent actually rendering the cube, the average time each loop takes during rendering, and the elapsed time in milliseconds of the fastest and slowest loop. We add those last two together to obtain a single average, which is compared with the other three times against scores in IE7 to yield a comparative index score. We also now extrapolate a scalability score, which compares the results from the larger cube to the smaller one to see if the interpreter accelerated and by how much.
SlickSpeed CSS selectors test suite. As JavaScript developers know, there are a multitude of third-party libraries in addition to the browser’s native JS library, that enable browsers to access elements of a very detailed and intricate page (among other things). For our purposes, we’ve chosen a modified version of SlickSpeed by Llama Lab, which covers many more third-party libraries including Llama’s own. This version tests no fewer than 56 shorthand methods that are supposed to be commonly supported by all JavaScript libraries, for accessing certain page elements. These methods are called CSS selectors (one of the tested libraries, called Spry, is supported by Adobe and documented here).
So Llama’s version of the SlickSpeed battery tests 56 selectors from 10 libraries, including each browser’s native JavaScript (which should follow prescribed Web standards). Multiple iterations of each selector are tested, and the final elapsed times are rendered. Here’s the controversial part: Some have said the final times are meaningless because not every selector is supported by each browser; although SlickSpeed marks each selector that generates an error in bold black, the elapsed time for an error is usually only 1 ms, while a non-error is as high as 1000. We compensate for this by creating a scoring system that penalizes each error for 1/56 of the total, so only the good selectors are scored and the rest “get zeroes.”
Here’s where things get hairy: As some developers already know, IE7 got all zeroes for native JavaScript selectors. It’s impossible to compare a good score against no score, so to fill the hole, we use the geometric mean of IE7’s positive scores with all the other libraries, as the base number against which to compare the native JavaScript scores of the other browsers, including IE8. The times for each library are compared against IE7, with penalties assessed for each error (Firefox, for example, can generate 42 errors out of 560, for a penalty of 7.5%.) Then we assess the geometric mean, not the average, of each battery — the reason we do this is because we’re comparing the same functions for each library, not different categories of functions as with the other suites. Geometric means will account better for fluctuations and anomalies.
Next: Table rendering and standards compliance…
Table rendering and standards compliance
Nontroppo table rendering test. As has already been proven in the field, CSS is the better platform for rendering complex pages using magazine-style layout. Still, a great many of the world’s Web pages continue to use HTML’s old <TABLE> element (created to render data in formal tables) for dividing pages into grids. We heard from you that if IE7 is still important (it is our index browser after all), old-style table rendering should still be tested. And we concur.
The creator of our CSS rendering test has created a similar platform for testing not only how long it takes a browser to render a huge table, but how soon the individual cells (<TD> elements) of that table are available for manipulation. When the test starts, it times the duration until the browser starts rendering the table and then ends that rendering, from the same mark, for two index scores. It also times the loading of the page, for a third index score. Then we have it re-render the contents of the table five times, and average the time elapsed for each one, for a fourth score. The four items are then averaged together for a cumulative score.
Nontroppo standard browser load test. (That Nontroppo gets around, eh?) This may very well be the most generally boring test of the suite: It’s an extremely ordinary page with ordinary illustrations, followed by a block full of nested <DIV> elements. But it allows us to take away all the variable elements and concentrate on straight rendering and relative load times, especially when we launch the page locally. It produces document load time, document plus image load times, DOM load times, and first access times, all of which are compared to IE7 and averaged.
Canvas rendering test. The canvas object in JavaScript is a local memory segment where client-side instructions can plot complex geometry or even render detailed, animated text, all without communicating with the server. The Web page contains all the instructions the object needs; the browser downloads them, and the contents are plotted locally. We discovered on the blog of Web developer Ernest Delgado a personal test originally meant to demonstrate how much faster the Canvas object was than using Vector Markup Language in Internet Explorer, or Scalable Vector Graphics in Firefox. We’d make use of the VML and SVG test ourselves if Apple’s Safari — in the interest of making things faster — hadn’t implemented a system that replaces them with Canvas by default. (To embrace HTML 5, newer browsers will have to incorporate SVG; and IE9 is finally taking big steps in that direction.)
We use Delgado’s rendering test to grab two sets of plot points from Yahoo’s database — one outlining the 48 contiguous United States, and one set outlining Alaska complete with all its islands. Those plot points are rendered on top of Google Maps projections of the mainland US and Alaska at equal scale, and both renderings are timed separately. Those times are compared against IE7, and the two results are averaged with one another for a final score.
Acid3 standards compliance test. To the extent to which browsers don’t follow the most commonly accepted Web standards, we penalize them in the rendering category. Think of it like a Winter biathlon where, for every target the skier fails to shoot, he has to ski a mini-lap. The function of the Web Standards Project’s Acid3 test has changed dramatically, especially as most of our browsers become fully compliant. IE7 only scored a 12% on the Acid3, and IE8 scored 20%; but today, most of the alternative browsers are at 100% compliance, with Firefox at 93% and with 3.7 Alpha 1 scoring 96%. So it means less now than it did in earlier months to have Acid3 yield an index score of 8.33, which is the score for any browser that scores 100% thanks to IE7. Now that cumulative index scores are closer to 20, having an eight-and-a-third in the mix has become a deadweight rather than a reward.
So now, for the other batteries that have to do with rendering (all three Nontroppos and TestCube 3D), plus the native JavaScript library portion of the SlickSpeed test, we’re multiplying the index score by the Acid3 percentage. As a result, the amount of any non-compliance with the Web Standards Project’s assessment is applied as a penalty against those rendering scores. Today, only Mozilla and Microsoft browsers are affected by this penalty, and Firefox only slightly — all the others are unaffected.
The CSS3.info compliance test. Microsoft asked us, as long as we’re calling Acid3 a litmus test for standards, why don’t we also pay attention to the CSS3.info test for CSS compliance. It was a fair question, and we checked into it, we couldn’t find anything against it. There are 578 standard selectors in the CSS3 test, the fraction of which that each browser supports constitutes a percentage. It’s then combined with the Acid3 percentage to yield a total rendering penalty. (Yes, Microsoft argued its way out of a few points: IE8 scores 20% on the Acid3, but 60.38% on the CSS3.info, for a 40% allowable percentage instead of 20%.)
Next: Our physical test platform, and why it doesn’t matter…
Our physical test platform, and why it doesn’t matter
The physical test platform we’ve chosen for browser testing is a triple-boot system, which enables us to boot different Windows platforms from the same large hard drive. For the Comprehensive Browser Test (CRPI), our platforms are Windows XP Professional SP3, Windows Vista Ultimate SP2, and Windows 7 RTM. For the standard RPI test, we use just Windows 7.
All platforms are always brought up to date using the latest Windows updates from Microsoft, prior to testing. We realize, as some have told us, this could alter the speed of the results obtained. However, we expect real-world users to be making the same changes, rather than continuing to use unpatched and outdated software. Certainly the whole point of testing Web browsers on a continual basis is because folks want to know how Web browsers are evolving, and to what degree, on as close to real-time a scale as possible. When we update Vista, we re-test IE7 on that platform to ensure that all index scores are relative to the most recent available performance, even for that aging browser on that old platform.
Our physical test system is an Intel Core 2 Quad Q6600-based computer using a Gigabyte GA-965P-DS3 motherboard, an Nvidia 8600 GTS-series video card, 3 GB of DDR2 DRAM, and a 640 GB Seagate Barracuda 7200.11 hard drive (among others). Three Windows XP SP3, Vista SP2, and Windows 7 RC partitions are all on this drive. Since May 2009, we’ve been using a physical platform for browser testing, replacing the virtual test platforms we had been using up to that time. Although there are a few more steps required to manage testing on a physical platform, you’ve told us you believe the results of physical tests will be more reliable and accurate.
But the fact that we perform all of our tests on one machine, and render their results as relative speeds, means that the physical platform is actually immaterial here. We could have chosen a faster or slower computer (or, frankly, a virtual machine) and you could run this entire battery of tests on whatever computer you happen to own. You’d get the same numbers because our indexes are all about how much faster x is than y, not how much actual time elapsed.
The speed of our underlying network is also not a factor here, since all of our tests contain code that is executed locally, even if it’s delivered by way of a server. The download process is not timed, only the execution.
Why don’t we care about download speeds, especially how long it takes to load certain pages? We do, but we’re still in search of a scientifically reliable method to test download efficiency. Web pages change by the second, so any test that measures the time a handful of browsers consumes to download content from any given set of URLs, is almost pointless today. And the speed of the network can vary greatly, so a reliable final score would have to factor out the speed at the time of each iteration. That’s a cumbersome approach, and that’s why we haven’t embarked on it yet.
There are three major benchmark suites that we have evaluated and re-evaluated, and with respect to their authors, we have chosen not to use. Dromaeo comes from a Firefox contributor whom we respect greatly, named John Resig. We appreciate Resig’s hard work, but we don’t yet feel his results numbers correspond to the differences in performance that we see with our own eyes, or that we can time with a stopwatch. The browsers just aren’t that close together. Meanwhile, we’ve currently rejected Google’s V8 suite — built to test its V8 JavaScript engine — for the opposite reason: Yes, we know Chrome is more capable than IE. But 230 times more capable? No. That’s overkill. There’s a huge exponential curve there that’s not being accounted for, and once it is, we’ll reconsider it.
We’ve also been asked to evaluate Futuremark’s PeaceKeeper. I’m very familiar with Futuremark’s tests from my days at Tom’s Hardware. Though it’s obvious to me that there’s a lot going on in each of the batteries of the Peacekeeper suite, it doesn’t help much that the final result is rendered only as a single tick-mark. And while that may sound hypocritical from a guy who’s pushing a single performance index, the point is, for us to make sense of it, we need to be able to see into it — how did that number get that high or that low? If Futuremark would just break down the results into components, we could compare each of those components against IE7 and the modern browsers, and we could determine where each browser’s strengths and weaknesses lie. Then we could tally an index based on those strengths and weaknesses, rather than an artificial sum of all values that blurs all those distinctions.
This is as complete and as thorough an explanation of our testing procedure as you’re ever going to get.
What, exactly, would one be blocked from seeing now that the “Great Firewall of China,” as it’s been dubbed, separates citizens of mainland China from Google? This morning, Betanews used a fabulous Firefox 3.0 add-in tool called ChinaChannel, created by independent developers in Hong Kong, to set up a proxy connection using a China IP address, so we could peruse Google as though we were in China itself. Then using an ordinary copy of Opera 10.51 on the other side, we browsed Google.com.hk — the server to which Google is now redirecting Google.cn requests — using our regular US-based connection.
We’ve used this tool in the past, and we had an easier time obtaining a proxy connection with a China-based proxy. At first this morning, we found proxy servers were frequently denying connection requests, although repeated requests often got through after 10 or more tries. However, sometimes our connection only lasted as long as a minute.
Although Google’s PRC service status page reports its Images service is online, we noticed that from time to time, we were not able to obtain image results from searches. Sometimes image results did not appear within regular Web queries, when using the US-based Opera connection to Google.com.hk, the images did appear. Sometimes requests to images.google.com.hk turned up pages with empty frames but active links, as was the case for this unresolved search for pictures of nuclear weapons.
At other times, requests were blocked, using response messages that clearly originated from a China-based ISP, not from Google. And then from time to time, image requests for relatively innocuous subjects, like Sandra Bullock, were processed without trouble.
By mid-morning, however, it appeared the gig was up, as every request for a proxy connection ended up being blocked. ChinaChannel rotates its proxy requests through a list of services (including aiya.com.cn, chinanetcenter.com, and a few services whose names are now blanked out in their “Access Denied” messages) that, at one time, were open. Requests to Aiya were met with this message: “Access control configuration prevents your request from being allowed at this time. Please contact your service provider if you feel this is incorrect.”
What we were looking for was evidence to back up Associated Press reports this morning that Chinese censors are filtering — not blocking, but rather sifting through — Google searches. The tiny speck of evidence we were able to turn up suggests that China’s roadblocks at present are not that sophisticated. Conceivably, state-run ISPs may be blocking (or trying to block) requests specifically to the images subdomain of Google.com.hk. A successful block could result in the “Image results for…” portion of a straight Google Web query, from appearing in the list of results, without the ISP having to block the entire page. It’s like filtering, but without the filter.
The unresolved request for pictures of big things blowing up, could be attributed to the roadblock kicking in partway through an IP request that was about to be fulfilled, rather than a filter noticing a specific request for pictures of mushroom clouds.
In any event, it does appear as though China authorities are using crude, but effective, means of limiting access to certain assets. But why not block access to Google entirely? As we found during our brief proxy connection, although Google.cn requests are rerouted to the .HK domain, straight Web searches still go through.
One possible answer may be that an outright block of Google could make Google more popular in China than ever, if only in a symbolic sense. Thwarting access to picture searches keeps Google’s boat afloat, while taking the wind out of its sails. Users may be sympathetic to Google’s cause, but they’ll end up switching to Baidu anyway.
So don’t be surprised if, after a few weeks of this “politicalizationalized” standoff (if only Norm Crosby were still with us), the interim outcome is a report of a boost in Baidu market share.
A quick check of Baidu’s “Opening-up policy,” to borrow a phrase, reveals that certain search requests continue to be directly filtered. Taking a suggestion from engineer Ed Felten, we tried a search for the Buddhist group Falun Gong or Falun Dafa. The response was a connection refusal that our Opera browser processed as a closure — Baidu hung up on us. And just as before, Baidu would then refuse to process some subsequent requests for innocuous material that it would happily find for us before, such as the aforementioned Sandra Bullock, or for something called “beta news.”
However, Baidu would merrily pop back into existence following a search for Deng Xiaoping.
Contrary to popular belief, where there is censorship, there is usually an influx of capitalism. One case in point we stumbled onto this morning was a Web site that offers citizens in China and elsewhere a three-day free trial toward a subscription to a frequently updated list of free proxy servers, which it says will link individuals to services such as YouTube. Yes, now you can overcome the effects of state-run censorship…for a low monthly fee.
Now, I can’t speak for the relative effectiveness of online marketing campaigns in the Asia/Pacific region, but I’d have to say that if I were an English-speaking Chinese citizen, I’d be turned off of such a service the moment it presented me with this popup: Purporting to be a link to an auction site, it offered me a chance to bid on the list of active Chinese subscribers to the proxy service, for a starting bid of $1,500.
A spokesperson for Adobe told Betanews this afternoon that on the morning of April 12 at 11:00 a.m. EDT, the company will hold a global online launch event for all of the components of its Creative Suite 5.
Among the most anticipated new components — or as Adobe tends to present them in its periodic table, “elements” — is a vastly improved HD video rendering engine called Mercury. Unlike other manufacturers, Adobe tends to retain the cool names for its products and platforms even after public release. Mercury will utilize the graphics processing power of video cards to expedite the decoding and playback of HD-encoded formats, especially for the Premiere Pro editor.
But not just all video cards…specifically, Nvidia cards, by virtue of a development deal between Nvidia and Adobe. High-performance rendering will be made possible through the CUDA language developed by Nvidia, rather than the OpenCL language embraced by ATI and parent AMD. As former Tom’s Hardware journalist Theo Valich speculated last December, the reasons for this decision could be practical and not just political: “While AMD will tell you that they’re all for open standards and push OpenCL, the sad truth is that the company representatives will remain shut when you ask them about the real status of their OpenCL API,” Valich wrote. This is true, he continued, even when lead developers for software projects complain to ATI about the availability of drivers.
Another anticipated element in the CS5 suite is the premiere of Flash Catalyst, an alternative development engine for Flash applications geared more to designers and graphic artists — more of a competitor to Microsoft’s Expression Studio.
Searching for a defining principle in the war of words between Google and the Chinese government, even after Google’s move yesterday to redirect search traffic from the .CN domain to its uncensored .HK address, may be about as fruitless as filtering high prose from a cable TV political pundit show. In a bizarre demonstration of what’s being called “openness,” China’s state-run news service responded to Google’s move yesterday first with a “nudity” slide show (news photos over the years with naughty bits included), cushioning some op-eds designed to characterize Google as out-of-step not only with China’s progress, but with America’s.
Conforming with state laws governing expression, argues a Xinhua op-ed late yesterday, is just one of the globalization trends that many enterprises and business ventures must embrace when entering new territories. Why can’t Google, Xinhua asks, be more like KFC?
“All commodities come with some cultures and ideologies,” reads one new op-ed, entitled, “Can China Live Without Google?” “China definitely is influenced by the West, but the influence is mutual. People of a certain culture learn to know a different new thing, but the new thing also has to learn to suit its new customers. That’s why KFC serves Chinese porridge and McDonald’s provides Chinese food menus here.”
The Xinhua report casts suspicion on the notion, which it says was instigated by a March 20 article in the Washington Post, that without access to the most defining brand on the Internet — a singularly American brand — China will become an outcast nation. There’s no reason a foreign company can’t do business in China, it argues, but it cannot bring with it foreign influences that endanger the national security. That would run counter to the country’s “Opening-up Policy,” as it’s called when translated into English, which depends on China’s ability to foster a fair and competitive environment for foreign investment.
Part of the country’s broader “opening up” involved the 1997 handover of Hong Kong (where Google’s China search requests are now centralized) from British to Chinese authority. The agreement between China and the UK which made possible this handoff, triggered the creation of an exclusive Hong Kong Bill of Rights. Article 16 of that ordinance reads in part, “Everyone shall have the right to freedom of expression; this right shall include freedom to seek, receive and impart information and ideas of all kinds, regardless of frontiers, either orally, in writing or in print, in the form of art, or through any other media of his choice.”
The key phrase in that above sentence is “regardless of frontiers,” which seemed to mean at the time that the freedom for individuals to express opinions openly to the outside depends on their freedom to acquire information from the outside, beyond the borders or frontiers. (Hong Kong also maintains an independent judiciary authority from China.) Almost immediately after the handoff, however, China authorities made it clear they expected Hong Kong’s press to apply “self-censorship.”
The organization Reporters Without Borders periodically reports on the progress of Hong Kong’s ability to maintain a free press, including a free Internet, in the midst of the mainland’s oversight and expectations. A few years ago, those reports were looking somewhat bright and cheerful. But in recent years, they’ve turned more skeptical, especially in light of an incident during the 2008 Beijing Olympics. At that time, Hong Kong journalists were expected to be “carded” and regulated as foreign journalists, which meant their work might be subject to screening.
China still relies upon the fact that other countries — specifically, other countries’ investors — rely on the freedom of Hong Kong’s financial press, especially to trust reports of improved investment value in that country to be something other than state-run propaganda. Nonetheless, it’s becoming clear that China is treating Hong Kong more and more like its own version of Las Vegas, where whatever happens on the island stays on the island.
By moving to the island, Google avoids a direct confrontation with China, and the danger of “politicalization” that Xinhua states would ensue. But should the company go forth with plans to do a “Radio Free China” act from the comfort and exile of the island, it could find its message somewhat muted. China has an interest in keeping Hong Kong as a “special” enclave, and so long as Google does business behind those walls, it may end up actually serving the government’s interests anyway, serving as the demon of choice for anti-Western values when demonizing America or Europe would be untimely.
The puzzle for software companies as they adopt Web services is how to make them profitable. Anyone who tries the ad-supported model 1) plays against Google on its home turf; 2) risks working against application efficiency; 3) could raise the ire of users. And anyone who tries offering subscription to storage space 1) could easily be outdone by the first vendor to give away all its space for free; 2) faces an uphill value proposition against cheap local storage, and free synchronization such as ![An Acrobat.com workspace being shared. [Screenshot courtesy Adobe]](http://images.betanews.com/media/4760.jpg "An Acrobat.com workspace being shared. [Screenshot courtesy Adobe]")
So besides the limit on Web conferencing between the higher “Plus” and the intermediate “Basic” plans (20 people versus 5), it’s the right to share with more than 20 possible groupings of any number of collaborators, that Adobe has evaluated as a $250 annual premium.
In the latest check of progress in the development of the major Web browsers for Windows, the brand that helped Betanews launch its regular browser performance tests appears to be making a comeback effort: With each new daily build, the WebKit browser engine — running in Apple’s Safari 4.0.5 chassis — gains computational speed that it was sorely lacking.
“Thanks to the efforts of the Federal Communications Commission, we now have a National Broadband Plan, which lays out a vision for a vibrant broadband and Internet marketplace,” began Verizon Executive Vice President for Public Affairs Tom Tauke, in a speech to the Washington think tank 
Although 
By mid-morning, however, it appeared the gig was up, as every request for a proxy connection ended up being blocked. ChinaChannel rotates its proxy requests through a list of services (including aiya.com.cn, chinanetcenter.com, and a few services whose names are now blanked out in their “Access Denied” messages) that, at one time, were open. Requests to Aiya were met with this message: “Access control configuration prevents your request from being allowed at this time. Please contact your service provider if you feel this is incorrect.”
