Google, Microsoft, Yahoo, PayPal Go After Phishers With New E-Mail Authentication Effort
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.
Mozilla Questions Web Orthodoxies With ‘Pancake’
Mozilla Labs has launched a new project designed to question the web as we know it, including what some might think of as the web’s sacred cows — like whether or not we need to see URLs.
Pancake, as the new project is known, will help Mozilla, “better understand what people do on the web, why and how they do those things, and how we can make those things easier and more efficient.” The goal of Pancake according to Mozilla’s new, awesomely titled Director of Pancake Stuart Parmenter, is to play with “huge concepts, monumental problems and occasionally crazy ideas.”
Among the ideas in Pancakes’ sights that many might consider crazy is questioning whether users need to care about the URL. Note that no one is questioning the URL itself, just whether or not the user needs to be concerned with it. Indeed Pancake won’t be the first time Mozilla has questioned whether or not the user needs to know about URLs, nor is Mozilla alone on that score, Google’s Chrome team has also experimented with hiding the URL bar.
Might there be some better means of letting the user know where they are, where a link leads and all the other things URLs currently do? That’s exactly the sort of question that Pancake wants to ask. We’ll never know the answer, and possibly never push the web in interesting new directions, if no one is asking the question.
If you consider the URL bar a sacred part of the web browser, fear not, no one is taking way your URL bar. The goal of Pancake is not to force anything down your throat, but to make the web better. That might mean, as Parmeter writes, “inventing new metaphors and new systems,” but the main goal of those new metaphors and systems is to “give users greater power and control within the modern web.”
In that sense it’s difficult to tell exactly what Mozilla plans to do with Pancake. In the immediate future Pancake will be rolling out its first prototype app, but the announcement is extremely vague about what that app might involve. Historically Labs projects are a very mixed bag. For every very successful Labs effort — like the syncing features that are now a standard part of Firefox — there are several others that have been quietly shelved (Ubiquity anyone? Prism?).
Pancake’s first prototype app — whatever it may be — will be released within the next few months. In the mean time you can check out the new wiki page or join the Pancake Google Group. All the other usual Labs pages — documentation, roadmap, designs and other content — will come in the weeks ahead.
Jokes for Nerds: Wat Moments in Programming
If you ever doubt your nerdery, head on over to Destroy All Software and watch the video of programmer Gary Bernhardt’s Wat talk. If you find yourself laughing, rest assured, you’re a nerd.
The talk comes from CodeMash 2012, where Bernhardt took a few moments to highlight a few WAT? (link NSFW) moments in some of the web’s favorite languages like Ruby and JavaScript.
Seriously JavaScript, what’s up with this:
> [] + {}
[object Object]
> {} + []
0
HTML5 Video on the Web Today
The hype surrounding HTML5 video has thankfully receded from the high water mark of 2011. But the absence of hype doesn’t mean HTML5 video is a thing of the past. In fact, while it’s true that HTML5 video still can’t completely match all of the features available in Flash, the state of HTML5 video on the web continues to improve with every new browser release.
For a very thorough rundown of exactly where and how well HTML5 video works on the web right now, check out the excellent report on the state of HTML5 video from Long Tail Video. Put together by the makers of JW Player, an HTML5 video player toolkit, the state of HTML5 video report is mercifully free of any evangelism for any particular technology. Instead it offers a level-headed look at reality, answering the basic questions — where can you use HTML5 video? How well will it work for users? And when will you need Flash fallbacks?.
HTML5 video enthusiasts will be happy to know that the state of native video on the web is looking better these days. Two-thirds of all the browsers on the web now support the HTML5 video tag. Support for the various video tag attributes has improved as well, with both Safari and Chrome offering full support.
Still, for all the bright points in the report, there is clearly still a need for Flash fallbacks if you want your video to reach the widest possible audience. With older versions of Internet Explorer still lingering (IE 9 and up support the HTML5 video tag) and the lack of support for closed captions and audio descriptions in any browser, Flash will likely remain the only option for at least some portion of the web for some time.
The good news is that, in some cases, the state of HTML5 video will be improving very soon, for example Firefox 10, which will be released in final form very soon, will support native fullscreen playback.
For more details on which parts of HTML5 video work and which don’t in today’s browsers, be sure to read through the full report.
Twitter Adds Responsive Design Tools to Bootstrap 2.0
Twitter is gearing up for the release of Bootstrap 2.0, the second major version of its popular open source front-end toolkit for web developers.
Bootstrap 2.0 will arrive Jan. 31, but if you’d like to take it for a spin today you can help test the pre-release build. Just head on over to GitHub and checkout the branch, 2.0-wip.
Bootstrap is designed to help you get your website up and running as fast as possible. Somewhere between a CSS framework and a “theme,” Bootstrap offers an HTML, CSS and JavaScript base for your designs, including built-in forms, buttons, tables, grids and navigation elements. Among Bootstrap’s more impressive tricks is the grid layout tool, which is based on the 960 grid system, with support for advanced features like nested and offset columns.
Bootstrap 2.0 will solve one of the bigger complaints about Bootstrap 1.0 — it was not responsive. To embrace a more responsive approach for mobile devices, Bootstrap is moving to a flexible 12-column grid system. The 2.0 release also includes some updated progress bars and customizable gallery thumbnails, but perhaps the best news is that, at just 10kb (gzipped), Bootstrap 2.0 remains an impressively lightweight framework.
While Bootstrap offers good browser support, with all the modern options covered you should be aware that it won’t work with Internet Explorer 6. To see some real world examples of what you can do with Bootstrap, head on over to the unofficial showcase, Built with Bootstrap on Tumblr.
Photo by Mike Love/flickr/CC.
Video: When We Build
The web is buzzing, and rightly so, about Wilson Miner’s incredibly inspiring talk from the 2011 Build Conference in Belfast. You may recognize Miner’s name from his role in developing Django, as part of the team that built Apple.com or as one of the founders of Everyblock.
Miner’s talk is not your typical web developer talk; in fact, he hardly mentions the web for most of it. Rather, Miner focuses on the broader impact that technologies, and the developers and designers who create them, have on our world, and how that world in turn shapes us. Miner reminds us that we aren’t building “just websites” but shaping the world we will live in for much of the foreseeable future. And, as the Alistair Smith quote shown in the talk says, “at times of change, the learners are the ones who will inherit the world, while the knowers will be beautifully prepared for a world which no longer exists.”
So turn off your music, throw the video in fullscreen mode and give it 38 minutes. Trust us, you won’t be sorry.
After you’re done be sure to visit Miner’s website, which has links to all the material used in the talk, including books, videos, music and images for anyone who would like to learn more.
Google Works on Internet Standards with TCP Proposals, SPDY Standardization
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
‘HTML5 Please’ Helps You Decide Which Parts of HTML5 and CSS 3 to Use
Keeping track of the ever-evolving HTML5 and CSS 3 support in today’s web browsers can be an overwhelming task. Sure you can use CSS animations to create some whiz-bang effects, but should you? Which browsers support it? What should you do about older browsers?
The first question can be answered by When Can I Use, which tracks browser support for HTML5 and CSS 3. You can then add tools like Modernizer to detect whether or not a feature is supported, so that you can gracefully degrade or provide an alternate solution for browsers that don’t support the features you’re using. But just what are those alternate solutions and polyfills? That’s what the new (somewhat poorly named) HTML5 Please site is designed to help with.
HTML5 Please offers a list of HTML5 elements and CSS 3 rules with an overview of browser support and any polyfills for each element listed (CSS 3 is the much more heavily documented of the two, which is why the HTML5 emphasis in the name is perhaps not the best choice). The creators of the site then go a step further and offer recommendations, “so you can decide if and how to put each of these features to use.”
The goal is to help you “use the new and shiny responsibly.”
HTML5 Please was created by Paul Irish, head of Google Chrome developer relations, Divya Manian, Web Opener for Opera Software, (along with many others) who point out that the recommendations offered on the site “represent the collective knowledge of developers who have been deep in the HTML5 trenches.”
The recommendations for HTML5 and CSS 3 features are divided into three groups — “use”, “use with caution” and “avoid”. The result is a site that makes it easy to figure out which new elements are safe to use (with polyfills) and which are still probably too new for mainstream work. If the misleading name bothers you, there’s also Browser Support, which offers similar data.
If you’d like to contribute to the project, head over to the GitHub repo.
The Disneyfication of Tech
Truth is this — users are caught between tech and media. Neither of them is looking out for our interest. Each of them own politicians each owns tech. The tech industry is better at tech (no surprise) and the media industry is better at a lot of other things, including getting Congress to do their bidding.
I’ve been warning the news publishers to be careful about viewing Twitter and Facebook as if they were equivalent to the web. This would be like Kodak trusting Apple to handle its digital photography strategy. We know now how that turned out.
Twitter and Facebook are rich and getting richer. Either of them could easily buy a struggling but independent news organization. Then where would you be if you were dependent on them to distribute news? It would be like the Times depending on Murdoch to print their daily paper. Instead the Times invested in their own printing plant, presumably so they could have better control of the product, both from a creative and tactical standpoint. If Murdoch owned the presses and the trucks, who do you think would deliver the most timely news? They have to think about Twitter that way. At some point they will come to see themselves as a media company, if they don’t already.
Caught in the middle is the original idea of the Internet and the web, that people could be media instead of just consuming it. For that to continue, enough people have to see their future as publishing independently, and enough people have to read independently of corporate media, neither originating from Silicon Valley or Hollywood, to keep the flame alive.
I still hope that there’s a remnant of the idealism of tech. That there was value in the personal-ness of PCs. The net is the same way. We need to make it ever-easier for people to own and run their own infrastructure. People think it’s hard, but it doesn’t have to be! Each of us can have the equivalent of a printing plant, that’s the magic of tech. No harder to keep running than a laptop. To those people in tech who still hold to the ideal of free communication unrestricted by government or corporations, please use some of your profits to help guarantee the future of an independent Internet.
Otherwise, I think we can all see this clearly now, the net will be a single amorphous Disneyfied mess, not too far down the road.
This post first appeared on Scripting News.
Dave Winer, a visiting scholar at NYU’s Arthur L. Carter Journalism Institute, pioneered the development of weblogs, syndication (RSS), podcasting, outlining, and web content management software. A former contributing editor at Wired magazine, Dave won the Wired Tech Renegade award in 2001.Follow @davewiner on Twitter.
Google Tweaks Search Results to Punish Ad-Heavy Websites
Google has tweaked its search algorithm to punish websites with excessive advertising “above-the-fold,” that is, websites that stack the top of the page with nothing but advertisements.
According to Google, “rather than scrolling down the page past a slew of ads, users want to see content right away.” To help users get to that content, Google may drop ad-heavy websites from its search results.
Google says that the change will only affect about one in 100 searches, and emphasizes that websites using what Google’s Distinguished Engineer and SEO guru Matt Cutts calls “ads above-the-fold to a normal degree” will not be affected.
Instead the change is designed to punish sites that “go much further to load the top of the page with ads to an excessive degree or that make it hard to find the actual original content on the page.” In other words, if a site is so packed with ads that people can’t find what they’re looking for then Google isn’t going to send them to that site anymore.
While the distinction seems clear at first glance, digging deeper reveals some potential confusion for webmasters — for example, what role does screen size play? On a netbook, for instance, Google’s own search results page is almost entirely taken over by advertisements, not the actual search results (i.e., the content).
Google on a netbook screen: Ads are in red, search results in green
At small screen resolutions, Google’s own search results page is one of the worst offenders when it comes to advertising clutter obscuring content. That seeming hypocrisy may leave some webmasters wondering what constitutes “a normal degree of ads” and how screen size affects what is defined as “normal.” Sticking simply with what Google has written about the change, copying Google’s search results page is probably not a good idea in this case.
Cutts does encourage webmasters view their websites at different screen resolutions, suggesting that screen size does play a role, but unfortunately he doesn’t offer any details about what that role is or how it affects the algorithm’s new layout ranking scheme.
Connect with ZionCG