Tech —

OS X 10.10 Yosemite: The Ars Technica Review

For the first time in forever, the Mac could be noticed by someone.

Applications

Every application seems new in Yosemite thanks to the system-wide visual overhaul. Many applications have been rearranged to take advantage of new title bar configurations. And a few have been given entirely new interfaces. Here are some of the highlights.

Safari

Yosemite ships with Safari 8, the most substantial visual update to Safari since the abortedSafari 4 beta’s “toppy tabs.” We already covered most of the changes to Safari’s toolbar, but tabs add an unexpected twist. Since Safari uses in-window blending, changing tabs within a single window immediately changes the content scrolling up “behind” the toolbar. This means the same window can change its appearance in dramatic ways as you cycle through tabs.

Switching tabs within a single Safari window can drastically affect its appearance. These are not four separate windows! This is one window, and we’re calling it… Safari 8.

There’s a new option (enabled by default) to show Spotlight suggestions in Web address search results. This includes the full range of possible Spotlight sources (Wikipedia, iTunes media and apps, map locations, movies currently in theaters, etc.), but only the top result is shown in Safari.

Spotlight suggestions in Safari address bar search results.

One more new toolbar-related feature will surely raise some geek eyebrows. When the combined address/search bar does not have the input focus, it no longer shows the full URL of the current page. Instead, it shows just the domain name (e.g., apple.com) or, if the current page was loaded via SSL with an extended validation certificate, a padlock icon and the organization name associated with the SSL certificate in green text.

The URL of this page is http://www.apple.com/watch/, but only apple.com is displayed.

This page uses SSL with an extended validation certificate. Only the name of the requesting entity is shown.

The new address bar looks nearly identical to the one in Safari for iOS. On an iPhone, horizontal space is so constrained that the choice not to show the full URL is understandable. On an iPad, this is less true, but there’s an argument to be made for consistency. On the Mac, however, horizontal space is abundant, and pixel-for-pixel symmetry with iOS is decidedly out of fashion.

There are at least two other reasons to bring this interface to the Mac, however. The first is security. When the full URL is shown, it’s possible to fool users into thinking they are on a familiar website when they’re actually on a phishing site. One way to do this is by using a very long domain name that happens to begin with what looks like a legitimate domain name. For example, in the screenshot below, the URL may appear at first glance to be a Google search, but it’s actually a very long subdomain of my-malicious-site.com (which is not visible because the address bar is not wide enough).

A simple phishing attack using a very long domain name.

Apple is not the first browser vendor to consider drastic measures to address this issue. Google recently experimented with replacing the URL with what it calls an Origin Chip. Google’s explanation of this change cites both security concerns and the precedent set by iOS.

All major desktop browser vendors, including Apple, have existing features meant to combat URL-based phishing attacks. These features usually add new elements to the address bar that cannot be faked by confusing URLs (e.g., a separate badge showing the owner of the site’s SSL certificate). Some browsers also display the domain and path portions of URLs in different text colors or weights. But all of these approaches suffer from the same problems that enable the very phishing attacks they’re meant to prevent: inattention and confusion. The people who don’t notice or don’t know how to interpret these subtle signs are exactly the people most in need of help.

This leads to the second reason to bring the iOS-style address bar to Safari on the Mac: simplicity. Though we technology enthusiasts may consider URLs an integral and well-understood part of our Web browsing experience, the vast majority of people have little interest in URLs beyond the one part of them that is commonly understood: the domain name. Everyone knows what google.com is, but few people know or care about the alphabet soup of text that may follow the domain name.

If you accept this premise, the iOS-style design follows naturally. Rather than adding elements to the address bar or trying to visually differentiate the components of the URL, Apple has chosen to reduce the visible address to the one part that people understand—which also happens to be the one part that matters when it comes to avoiding URL-based phishing attacks.

If you don’t accept this premise, well, chances are good that you know a bit more about computers than the average person—but that doesn’t necessarily mean you’re wrong. I confess, I also have my doubts about the complete irrelevance of URLs. Even if most people don’t understand the details, good URL design can and should use the address bar to convey location information beyond just the domain name. This is especially true given the dismal state of page titles on the Web, thanks both to SEO and general laziness.

Either way, I think all parties can agree on one thing: Apple should at least include an option to display the full URL for people who really do need to see it (e.g., Web developers). Happily, that option does indeed exist in the “Advanced” section of Safari’s preferences. Unhappily, this option does not allow the address field to get any wider. As discussed earlier, some amount of empty space in the toolbar is needed to provide a reasonable drag target for moving the window. The address field does get wider along with the window, but even with the default flexible spaces removed from the left and right sides of the toolbar, the address field stubbornly refuses to take up much more than 40 percent of the width as the window expands to fill the screen.

Also, even with the “full website address” option enabled, favicons are not visible unless the address field has the input focus. And like other search fields in Yosemite, the address field center-aligns its contents when it doesn’t have the input focus, but it switches to left-aligned (with an animation) when it gains focus. This makes for a lot of sliding around and waiting in a field that some people (e.g., Web developers) use many, many times a day.

Safari 8 has a few more new settings to tweak. There’s now a separate preference for what Safari should do on startup: open a new window or restore all windows from the previous session. As in the recent Safari 7.1 update, the privacy-focusedDuckDuckGo joins Google, Yahoo, and Bing as a search engine choice in Safari 8.

WebGL has graduated from the Developer menu and is now enabled by default. Allowing webpages to execute code on the GPU presents many new security challenges. Apple claims to have met these challenges by revising its graphics drivers to be resilient in the face of malicious or just plain buggy code. It’s taken Apple a long time to get here; WebGL was added to WebKit five years ago. As with other Safari plug-ins, WebGL can be controlled on a per-website basis. It can also be disabled entirely in the Security section of Safari’s preferences.

[Update: An earlier version of this review stated that Apple had softened its stance on third-party cookies in Safari 8. This is not the case. The default “Allow from websites I visit” setting in Safari 8 behaves the same as the default setting in Safari 7. It’s just differently worded. We apologize for the error.]

Safari’s new cookie-handling setting, “Allow from current website only,” will only accept cookies whose domains match the sending website. This is somewhere between the default setting (“Allow from websites I visit”) and completely blocking all cookies.

Safari’s subtly new cookie preferences.

Private browsing is no longer a mode in Safari. Apple has adopted Google’s approach to this feature, right down to the keyboard shortcut (command-shift-n), by adding a “New Private Window” option to the File menu. Private windows are distinguished by the dark gray background in their address fields.

A new Private Window in Safari. Pity about the explanatory message that’s truncated instead of wrapped.

Private windows prevent Safari from recording visited pages, search history, and text entered into forms. For Safari as a whole, the “Clear History and Website Data…” option in the History menu now offers several (also Chrome-like) options to limit the time span of the operation.

Safari adopts another useful feature from Chrome: clear history for a limited time range.

Though I didn’t get a chance to test these claims, Apple is touting Safari’s ability to browse the web for two hours longer than Chrome or Firefox on a single battery charge. Furthermore, thanks to its “native” support for Netflix playback (i.e., without having to install any plugins), Apple claims Safari has a three-hour advantage over Chrome and Firefox when watching videos from this service.

As usual, the new Safari provides a nice speed bump over the old version. The most significant new optimization is in the JavaScript engine. Safari 8 uses the LLVM compiler back end to optimize JavaScript code that has executed frequently enough to make the compilation time worthwhile. The WebKit development team has posted a detailed technical overview of this new system, dubbed the Fourth Tier LLVM JIT, or FTL for short. This, along with the three preexisting optimization tiers employed by WebKit, highlights just how much engineering time and effort goes into making a dynamic language like JavaScript execute quickly. (This will be relevant later.)

Share this story

John Siracusa
John Siracusa has a B.S. in Computer Engineering from Boston University. He has been a Mac user since 1984, a Unix geek since 1993, and is a professional web developer and freelance technology writer. Emailsiracusa@arstechnica.com//Twitter@siracusa