text/plain

The Muse

There’s a writer living in my head, and he’s a genius.

Or so he tries to convince me, as his prose flows freely day in and out, filling most idle moments– while I’m showering, driving, dining, taking out the trash, or performing any of the other mundane tasks of daily life. His prose is brilliant– his points always well aligned, his recall of long-ago events and facts uncannily perfect, and his agility in seamlessly transitioning from one topic to the next is above reproach. He never needs spell-check or a thesaurus, and he never struggles to find the right way to approach the topic. His efforts are frequently interrupted by periods of basking in the glorious reception he imagines for his easy labors, and is certain that untold rewards are sure to follow.

Unfortunately, this genius is a huge jerk.

As soon as a spare moment is found in which hands can be placed upon a keyboard or a notepad, he’s either nowhere to be found, or not “in the mood” to rehash old topics that were perfectly formed in the ether… to commit such brilliance using a device so banal as a keyboard is an insult, it seems, and he won’t deign to be part of such an endeavor.

Over the years, I’ve found that the only way to write is to just type, painfully, whatever drivel comes to mind, scaffolding up the roughest of approximations of what he might say, providing nary a distraction to amuse him. With false start after false start, rewrite after rewrite, I suffer until he comes out, clucks his tongue at my pathetic efforts, and begins to guide my fingers on the keyboard. He bridles at the annoyance of checking facts (rolling his eyes in disdain each time an inaccuracy is found—“the piece would be better if I was right!” he argues) and groans each time my feeble mind grapples with a word choice.

When a throwaway tweet gets 300 times the pickup of a hard-scribed blog post, he groans and rants at the inanity of the mortal world.

But what alternative is there?

-Eric

Unsecure Content

Chrome has landed their change that allows you to mark unsecure (HTTP) content as insecure or dubious. Visit chrome://flags/#mark-non-secure-as to set the toggle. You can choose to mark as Dubious:

…or as Non-Secure:

The expectation is that eventually one of these modes will be the default for sites that are transferred over insecure protocols like HTTP.

Personally, I’m not really a fan of either piece of iconography; to me, showing the lock at all implies that the site has some amount of security and maybe it’s just not perfect.

I’m hoping that after some transition period, we’ll end up with a more prominent notification that explains what the issue is and why humans might care.

In December of last year, I made the following proposal with tongue only slightly in cheek:

Meet “Nosy”, your HTTP-content indicator:

Of course, Nosy’s got a lot of things to say:

nosy2

Sites and services need to use secure protocols like HTTPS because users expect it. No, not all users will expect to see the letters HTTPS and probably don’t understand hashes, ciphers, and public key encryption. But they expect that when they visit your site, it was delivered to them unmolested, privately, and as you original designed it. And the only way to realistically ensure that these expectations are met is to use HTTPS.

Update: While the mock screenshot above was never built, Chrome Security’s Lucas Garron wrote the awesome Ugly HTTP Chrome extension, a very simple extension that helps make it much more obvious when you’re on a non-secure site by color-shifting the content of the page itself.

-Eric Lawrence

HTTP Caching Public Service Announcement

There are many interesting thing to say about HTTP caching. I’ve blogged about them a lot in the past.

Today’s public service announcement to clear up two extremely common misconceptions:

1. The no-cache directive does not mean “do not cache” (even though IE versions prior to IE10 implemented it that way).

What it really means is do not reuse this item from the cache without first validating with the server that it is fresh.

If the no-cache directive does not specify a field-name, then 
a cache MUST NOT use the response to satisfy a subsequent request
without successful revalidation with the origin server.

2. The must-revalidate directive does not mean “you must revalidate this resource with the server before using it.”

What it really means is do not reuse this item from the cache after it expires without first validating with the server that it is fresh. It’s basically saying: “Don’t ignore the Expires and max-age directives.” Which a client absolutely shouldn’t be doing anyway.

If the response includes the "must-revalidate" cache-control
directive, the cache MAY use that response in replying to a
subsequent request. But if the response is stale, all caches
MUST first revalidate it with the origin server.

-Eric

Browser Benchmarks

Back in December, I predicted that Microsoft wouldn’t release the Project Spartan beta until it bested all of its competitors on the major benchmarks: SunSpider, Kraken, and Octane. I was wrong—the first beta was released with only minor script performance improvements. That changed with build 10061 of Windows 10, and Spartan now does beat everyone else on their own benchmarks.

Running Windows 10 on my new 2015 Dell XPS13 i5-5200U, I get the following scores:

Browser	SunSpider	Kraken	Octane
Spartan/IE 10061	122.7ms	1444.44ms	23652
Chrome 43 beta 2357.37	255.5ms	1557.7ms	22656
Firefox 37.0.2	204.2ms	1498.4ms	21762

Now, some of these “victories” are within the margin of error, and it’s very possible that upcoming versions of Chrome and Firefox will improve their performance on slow outliers (e.g. Chrome’s score on Octane’s MandreelLatency is just 22% as fast as Spartan’s). But anyone surprised at Microsoft’s great results is overlooking the fact that some of the world’s best compiler developers and architects work for Microsoft and their attention has increasingly been turned toward JavaScript.

Of course, script performance is important, but it’s far from the only way to measure a browser. Standards-compliance, network performance, ease-of-use, security, end-user features and many other aspects determine your experience with a browser. There are many different tests (subjective and less-subjective) for these aspects, although each has its own biases. But just to give one example, with all its feature flags turned on, Spartan ekes out a score of 402/555 on the (questionable, but easily run) HTML5Test.com while Firefox and Chrome score 449 and 526 respectively.

Hamstringing JavaScript

Of course, your numbers might be wildly different than those above, for one major reason: security software.

Every year for Microsoft’s annual AV summit, the IE Team puts together a chart of the impact of AV on browser performance, showing the variation across the top 20 AV products (the variation is huge). They don’t want to publish this data, but the impact ranges from “bad” to “absurdly unbelievably bad.” The best products impact performance by ~15%, the worst slow the browser by 400% or more. Several of the products crash the browser entirely and can’t be benchmarked fully. Conducting these benchmarks correctly is difficult—you need to account for every piece of software running on the machine and ensure that the test conditions are entirely fair (hardware, software, updates, etc); as a consequence, many of the “public” benchmarks are rather inaccurate.

Why hasn’t the IE team released their numbers? My guess is that it’s to try not to anger the AV companies, all of whom have been muttering “antitrust antitrust antitrust” under their collective breath ever since Microsoft integrated an entirely decent antivirus package into Windows 8.

Personal anecdote: I have Symantec Endpoint Protection running on a machine with a high-end i7-4771 CPU; even after unticking all of the “optional” protection features I can find in the Symantec control panel, the Octane score in Chrome 43 is 11659. On the same hardware in the same browser version without Symantec installed, the Octane score is 32555, 279% of the original score.

The devastating impact of antivirus on browsing performance is one reason why your portable devices feel magically fast—on a AV-unhindered i7, IE11 runs SunSpider in 70ms. Add AV and it runs in 350ms. The IPad Air, running with Safari’s slower script engine, runs it in 380ms. Mobile devices offer “Desktop Class” performance only because your desktop has been wrecked.

Antivirus software is too often a cure that’s as bad as the disease. The business model of AV rewards noisy products, and the desire for “checkbox parity” leads to a race to shove its tentacles in all sorts of places they don’t belong (e.g. the internal data structures of the browser). Unfortunately, even beyond antitrust concerns, Microsoft is very limited in its ability to deal with horrible AV products due to court precedents that say that AV can pretty much get away with doing anything it wants in the name of “protecting the user.”

You might ask: “Without my security software, aren’t I at risk?”

Yes, you are. But security software provides surprisingly little protection, as this delightful photo of a colleague’s laptop shows. In the foreground, the AV software promising that the user is protected. In the background, the ransom UI demanding payment to decrypt the documents that have just been mangled.

Awkward screenshot

Even worse, “security” software itself often introduces vulnerabilities into otherwise secure systems.

Advice

Want to be protected and stay fast?

Upgrade to Windows 8.1 or later.
Leave SmartScreen Application Reputation enabled.
Leave the built-in antivirus enabled.

Or get a Chromebook.

– Eric Lawrence

Velocity Conference – 2015 Santa Clara

I’ll be speaking at my third (or fourth?) Velocity Conference in Santa Clara California one month from now. I’m always excited to go to Velocity; it’s a conference full of great talks, and more importantly, smart people working on important problems.

My talk, HTTPS in 2015, delivers a whirlwind overview of HTTPS, from how it works to why you need to use it to secure your sites and services.

Anyone watching the news knows that securing your websites and services using HTTPS has never been more important. In this talk, a former browser security program manager covers the best practices for using HTTPS today. Topics covered in this session include ciphers and hash algorithms, forward secrecy, handshakes and protocols, and new browser features like HSTS and PKP. We’ll talk about exciting developments in 2015 that will make securing your site simpler than ever before, even as attackers get ever more sophisticated. Explore how attackers circumvent HTTPS, and what you can do to help protect your visitors and keep customers safe from snoops and bad guys. Secure all the things!

Leading up to the conference, the fine folks from O’Reilly conducted a little mini-interview with me you can read here HTTPS – The S stands for User Experience.

I hope to meet some of you at the conference! If you haven’t registered yet, you can use code ericl20 to save 20%, but hurry—prices go up May 1st.

-Eric

PS: O’Reilly has got you covered if you need to convince your boss.