Major e-mail providers, including Google, Microsoft, and Yahoo are teaming up with PayPal, Facebook, LinkedIn, and more, to implement a new system for authenticating e-mail senders to try to prevent the sending of fraudulent spam and phishing messages.

The protocol that powers e-mail, SMTP, dates back to a more trusting era; a time when the only people who sent you e-mails were people you wanted to send you e-mails. SMTP servers are willing to accept pretty much any e-mail destined for a mailbox they know about (which is, admittedly, an improvement on how things used to be, when they’d accept e-mails even for mailboxes they didn’t know about), a fact which spammers and phishers exploit daily.

Making any fundamental changes to SMTP itself is nigh impossible; there are too many e-mail servers, and they all have to interoperate with each other, an insurmountable hurdle for any major change. So what we’re left with is all manner of additional systems that are designed to give SMTP servers a bit more information about the person sending the e-mail, so that they can judge whether or not they really want to accept the message.

The two main systems in use today are called SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail). Both systems use DNS to publish extra information about the e-mail sender’s domain. SPF tells the receiving server which outgoing servers are allowed to send mail for a given domain; if the receiving server receives mail from a server not on the list, it should assume that the mail is fraudulent. DKIM embeds a cryptographic signature to e-mail messages and an indication of which DNS entry to examine. The receiving server can then look up the DNS entry and use the data it finds to verify the signature.

These systems are not perfect; though both are used widely, they haven’t been adopted universally. This means that some legitimate mail will arrive that doesn’t have SPF or DKIM DNS entries, and so mail servers can’t depend on its presence. Common legitimate operations can also break them; many mailing list programs add footers to messages, which will cause rejection by DKIM, and forwarding e-mails causes rejection by SPF. As a result, failing one or other test is not a good reason to reject a message.

These systems also make it hard to diagnose misconfigurations; receiving servers will typically just swallow or ignore mails sent by systems with bad SPF or DKIM configurations.

The large group of companies, which includes the biggest web mail servers and some of the most common corporate victims of phishing attempts, is proposing a new scheme, DMARC (“Domain-based Message Authentication, Reporting & Conformance”), in an attempt to tackle these problems. DMARC fills some of the gaps in SPF and DKIM, making them more trustworthy.

DMARC's position within the mail receipt process (illustration by dmarc.org)

DMARC is based on work done by PayPal in conjunction with Yahoo, and later extended to Gmail. This initial work resulted in a substantial reduction in the number of PayPal phishing attempts seen by users of those mail providers, and DMARC is an attempt to extend that to more organizations. As with SPF and DKIM, DMARC depends on storing extra information about the sender in DNS. This information tells receiving mail servers how to handle messages that fail the SPF or DKIM tests, and how critical the two tests are. The sender can tell recipient servers to reject messages that fail SPF and DKIM outright, to quarantine them somehow (for example, putting them into a spam folder), or to accept the mail normally and send a report of the failure back to the sender.

In turn, this makes SPF and DKIM much safer for organizations to deploy. They can start with the “notification” mode, confident that no mail will be lost if they have made a mistake, and use the information learned to repair any errors. DMARC also allows recipients to know if a domain should be using SPF and DKIM in the first place.

Without a global rollout, DMARC can’t solve all phishing and spam problems. The companies that have signed up to support the project include major recipients of phishing attempts—the various free e-mail providers—and sites against which phishing attacks are regularly made. Mail sent between the organizations will be verified using the SPF/DKIM/DMARC trifecta. Anyone using the major mail providers and the major services should see a substantial reduction in fraudulent mail. Senders and recipients who want to receive similar protection can implement DMARC themselves by following the specification that the DMARC group is working on.

Given the constraints imposed by SMTP, we may never get an e-mail system that is entirely free of malicious and annoying junk. SMTP e-mail was never designed to be trustworthy, and systems like SPF and DKIM are constrained by the inadequacies of SMTP’s design. Nonetheless, mechanisms such as DMARC can still make a big difference, and with the support of these major companies, e-mail might get that little bit safer.

This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.

Illustration by dmarc.org

As part of Google’s continuing quest to dole out web pages ever more quickly, the search giant has proposed a number of changes to Transmission Control Protocol (TCP), the ubiquitous Internet protocol used to reliably deliver HTTP and HTTPS data (and much more besides) over the ‘net.

Google’s focus is on reducing latency between client machines and servers, and in particular, reducing the number of round trips (either client to server and back to client, or vice versa) required. When data is sent over a TCP connection, its receipt must be acknowledged by the receiving end. The sending end can only send a certain number of packets before it must wait for an acknowledgement. The time taken to receive an acknowledgement is governed by the round-trip time (RTT). With high bandwidth, high latency connections, clients and servers can end up spending most of their time waiting for acknowledgements, rather than sending packets.

When a new connection is made, a computer may initially send three packets before acknowledgement is required. Google wants to increase this to 10. With 10 packets, a browser can typically deliver an entire HTTP request to a server before it has to stop and wait for a reply.

TCP connections require a certain amount of negotiation between client and server, requiring a round trip, before data can be sent. Google is proposing to modify TCP so that some data can be sent during that negotiation, so that the server will have it on hand already, and can start processing it straight away.

TCP waits a predetermined time (the RTO or retransmission timeout) for acknowledgments to arrive. If the RTO expires, unacknowledged packets are assumed lost and retransmitted. This ensures that if the data has been lost in transmission that the sender is never waiting for an acknowledgement that will never arrive. This timeout value varies according to the network conditions and RTT, with a default of three seconds. Google wants to reduce this default to 1 second, so that if data has been lost, neither end needs to wait so long before it has another go.

Finally, Google wants to use a new algorithm to adjust how TCP connections react to packet loss. Packet loss can indicate networks that are congested, and TCP reacts by reducing the rate at which data is sent when this congestion is detected. The company claims that the algorithms currently used to respond to this packet loss can exact too great a penalty, making connections slow down too much and for too long, and that its new algorithm is better.

In addition to these proposed changes, Google is also suggesting other modifications, especially to make TCP recover better on mobile networks.

Changing TCP is not to be taken lightly. The protocol is already suffering due to buffer bloat undermining its built-in handling of network congestion. While Google’s proposed changes are well intentioned and might improve network performance, they come with the risk that an overlooked problem or a bad interaction with other traffic could cause widespread damage to the internet.

The proposed changes to TCP to reduce latencies and start sending data sooner are a continuation of previous work Google has done to try to make web serving, in particular, faster. The company has previously proposed other modifications to protocols such as SSL to similarly accelerate data transmission.

More far-reaching than these SSL tweaks is Google’s proposed alternative to the HTTP protocol that underpins the web: SPDY.

Initially, SPDY was a proprietary Google protocol implemented only in Google’s Chrome browser. That’s changing, however. Amazon’s Silk browser includes SPDY support, and Firefox 11 will include preliminary SPDY support. Partially motivated by SPDY’s uptake, the IETF’s HTTPbis Working Group — the team of industry experts tasked with maintaining and developing the HTTP specification — is considering the development of a new specification, HTTP/2.0, with the goal of improving the performance of HTTP connections. The working group will solicit suggestions from the industry, and with two, soon to be three implementations already, SPDY is likely to be well placed among those suggestions.

This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.

Photo: Ariel Zambelich/Wired.com

Microsoft has released the fourth preview of Internet Explorer 10. As is the case with previous Platform Previews, the release is aimed at developers: the new features are important to those creating rich, complex web applications, but will have less impact on web users.

However, even web developers might struggle to get too excited about the latest preview, because they probably won’t be able to run it: it only works on the Windows 8 preview release that Microsoft shipped at its BUILD conference in September.

Safely share data between domains with IE10's CORS

The new features include Cross-Origin Resource Sharing (CORS), JavaScript typed arrays and binary file manipulation, and HTML5 video subtitling. Typed arrays and support for binary files enable much better performance for JavaScript applications that handle binary data, such as images and audio.

CORS provides a safe way for JavaScript applications to use services offered by different providers. Traditionally, JavaScript has been restricted by the same-origin policy: a script can only have full access to content that is hosted at the same domain, port, and protocol. This provides security by preventing theft of, for example, cookies and page data by objects included from other sites.

CORS allows one application to expose its data to another application even when the same-origin policy would otherwise deny such access. This is useful for creating “mashup” applications that combine web services from multiple different providers.

Microsoft has positioned its Platform Previews as a way to let developers test and provide feedback on new features so that they can inform Microsoft of bugs, and guide the development of new specifications. The first two Platform Previews for Internet Explorer 10 were made available to users of Windows 7. This preview, however, is not. If you want to use it, you’ll have to use the Windows 8 Developer Preview.

The third preview was in the same position; Microsoft did not release a Windows 7 version of Platform Preview 3. Instead, the version of Internet Explorer that shipped with the Windows 8 Developer Preview was the third preview. Though Internet Explorer 10 will support Windows 7 when released, web developers wanting to test the software now will have to use an unsupported, not-even-beta operating system to do so. And while they can do so using a virtual machine, doing so will disable most or all of the hardware acceleration features found in the browser, making it a second-rate experience.

This is a decidedly odd move. Internet Explorer 10 is going to be fundamental to Windows 8 in a way that no past version of the browser has been. HTML and JavaScript are one way for developers to create new touch-friendly Metro-style applications, and this support will be built on Internet Explorer 10.

But as important as Metro-style applications are to Microsoft, the browser will still have a substantial user base on Windows 7, and the web developers of today are far more likely to be using Windows 7 than they are Windows 8. Regular non-Metro web applications still matter. Effectively excluding this group from the preview—the group most likely to have valuable feedback and insight—makes one wonder what the entire purpose of the scheme is.

This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.

A couple of interesting things happened in the world of Web browser usage during October. The more significant one is that Internet Explorer’s share of global browser usage dropped below 50 percent for the first time in more than a decade. Less significant, but also notable, is that Chrome for the first time overtook Firefox here at Ars, making it the technologist’s browser of choice. [Ed. Note: That still hasn't happened at Webmonkey, but it's very close. See below for more stats.]

Internet Explorer still retains a majority of the desktop browser market share, at 52.63 percent, a substantial 1.76 point drop from September. However, desktop browsing makes up only about 94 percent of Web traffic; the rest comes from phones and tablets, both markets in which Internet Explorer is all but unrepresented. As a share of the whole browser market, Internet Explorer has only 49.58 percent of users. Microsoft’s browser first achieved a majority share in—depending on which numbers you look at—1998 or 1999. It reached its peak of about 95 percent share in 2004, and has been declining ever since.

Where has that market share gone? In the early days, it all went Firefox’s way. These days, it’s Chrome that’s the main beneficiary of Internet Explorer’s decline, and October was no exception. Chrome is up 1.42 points to 17.62 percent of the desktop browser share. Firefox is basically unchanged, up 0.03 points to 22.51 percent. Safari grew 0.41 points to 5.43. Opera has been consistently falling over the last few months, and it dropped again in October, down 0.11 points to 1.56 percent.

Net Applications

In spite of Android sales now outstripping iOS sales, iOS users are far more abundant on the Web. Mobile browsing is currently a much smaller market, with 5.5 percent of Web usage conducted on smartphones and tablets. This small market is also a lot more volatile than the desktop market. Mobile Safari was up by 6.58 points last month to 62.17 points. The biggest single loser was the Android browser, dropping 2.91 points to 13.12 percent. Symbian, BlackBerry and Opera Mini also registered falls, down 2.15 points to 2.55 percent, 0.64 points to 2.04 percent, and 0.27 points to 18.65 percent, respectively.

Net Applications

The trend graph says it all: Firefox’s share is flat, with Chrome driving all Internet Explorer’s losses.

Net Applications

Safari’s long-term dominance in mobile is clear. Also clear is that Android’s sales growth isn’t at all reflected in its Web usage.

Net Applications

The upgrade trends show a familiar story. Chrome users, who for the most part receive updates automatically, switch to new versions quickly and efficiently. Chrome’s “tail” is growing ever longer, though, with about 2 percent of desktop browser users—about 14 percent of Chrome users—using old versions. That number is growing every month, and it appears to be resilient.

Net Applications

Firefox retains its clean split between people on the new, rapid release versions (4-9) and those on the old stable version (3.6). The rapid release users are upgrading fairly quickly, though the cut-overs are neither as rapid nor as automated as those of Chrome. However, almost a quarter of Firefox users are sticking with version 3.6. Until and unless Mozilla produces a stable edition with long-term support, this is unlikely to change.

Net Applications

Internet Explorer, however, continues to see major usage of old versions. Internet Explorer 6 and 7, which aren’t current on any supported version of Windows, are still the version used by 25.4 percent of Internet Explorer users, 13.38 percent of desktop users as a total. These are people that can upgrade to either Internet Explorer 8 (if they’re using Windows XP) or Internet Explorer 9 (if they’re using Windows Vista), but who have, for some reason, refused to do so. Internet Explorer 8 users appear to be switching to Internet Explorer 9 at a slow but steady rate, with the former down about a point, and the latter up by about a point.

The browser usage here at Ars Technica continues to be unusual, with Firefox and Chrome over-represented on the desktop, and Android showing a much stronger performance among mobile user than is seen on the wider Web.

A compelling case can be made that the causes for these two phenomena—Internet Explorer’s decline, and Chrome’s growth—are closely related. They represent the influence of the computer geek.

Ars Technica’s unusual usage figures are not surprising when considering its audience: visitors to the site tend to be technologists and early adopters: Ars readers were among the first to switch to using Firefox as their browser of choice, and similarly they’re leading the way with Chrome. While Internet Explorer’s decline, Firefox’s flatlining, and Chrome’s growth have happened faster at Ars than the broader Web, the underlying trends are the same. [Ed. Note: Webmonkey's browser stats are roughly the same as of October 31st. Chrome has yet to overtake Firefox among Webmonkey's perhaps more developer-heavy audience, but it's gaining on Firefox every month. For the month of October 33.4 percent of you were using Firefox, 32.4 percent Chrome and only 16.0 percent Internet Explorer.]

This is perhaps not surprising. Ars has more than its fair share of IT decision-makers, both in corporate environments and home environments (I’m sure that many of us know the perils of being the “computer guy” roped in to fix the problems plaguing friends’ and family’s machine). It might be a few months before a Chrome-using Ars-reading geek starts to recommend it to friends and family, or a few years before he gets approval to roll the browser out across the company whose computers he maintains, but the migration will happen. Technology decisions are usually made by technology people—and technology people read Ars, ditched Internet Explorer for Firefox a few years ago, and are now switching to Chrome.

Firefox appealed to the geek demographic by offering tabs, a wealth of extensions, and active development: geeks enjoy new things to play with, and a browser that’s frozen in time, as Internet Explorer 6 was, holds no appeal. Chrome in turn offered a focus on performance and stability, even more active development, and the cachet of being built by Google. Chrome was also quick to offer obvious but useful things such as built-in, robust session restoration, and a useful new tab page (something Internet Explorer 9 replicated, and which is currently in beta for Firefox). Bundling Flash also removed a potential headache, by ensuring that a potentially buggy plugin was kept current and up-to-date. On top of all this, Google has been vocal in pushing its view of how the Web should work, with the VP8 video codec, the SPDY Web protocol, and most recently, the Dart scripting language.

A browser that doesn’t appeal to this demographic won’t receive the benefit of this kind of on-the-ground advocacy. Mozilla is working to bring some of Chrome’s appealing features to Firefox, with its new development schedule and future features such as tab isolation, and though this is currently causing some headaches—there are continued issues with extension compatibility—Firefox’s market share is for the most part holding steady. Once Mozilla can get rid of the annoying wrinkles and make updates as pain-free as Chrome’s, it might start to win back the attention of the techie demographic. Especially if Mozilla can come up with a viable IT-friendly long-term support option.

Meanwhile, Microsoft is strenuously avoiding this same demographic. Internet Explorer lacks small but significant creature comforts such as resizeable text boxes, built-in spell checking, and session restoration, and while it does offer certain extensibility points, they fall a long way short of those offered by Firefox, and as such, its extension ecosystem is a whole lot less rich. It’s not enough for Internet Explorer to be a solid mainstream browser: the less technically engaged users who switched to Firefox because a trusted authority told them to aren’t going to spontaneously switch back to Internet Explorer, even if it is good enough for their needs. They’re going to wait until their techie friend next fixes their PC and tells them that they should consider switching to Internet Explorer because it’s “better”. Just as they did for Firefox and do for Chrome.

Internet Explorer is still an important browser, with a userbase large enough that few developers can afford to ignore—though sites that don’t need global appeal may well be able to safely ignore Internet Explorer 6—and at current rates it will remain important for a few years yet. But until and unless Microsoft makes its browser appeal to the influential geek demographic, it looks as if Internet Explorer has nowhere to go but down.

This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.

See Also:

• Mozilla Brings Sharing to the Browser With ‘Firefox Share’
• Mozilla, Microsoft Join Forces for ‘Firefox With Bing’
• Chrome 15 Released with… Improved Start Page
• Metro-style Internet Explorer 10 Ditches Flash, Plugins