Robert Scoble: Tech’s Weinstein Moment

Earlier today I was stunned to read about the accusations of sexual harassment against Robert Scoble.  We aren’t friends, but we have friends in common and we have interacted remotely in the past.

I had no idea, no clue, that Scoble had harassed women. There are some people you might suspect of doing so, and some people you don’t, and before today I would have listed Scoble in the latter category. It just goes to show that on the internet, people don’t always know you’re a dog.

Regardless, this is a story that should be told far and wide, because Hollywood isn’t the only culture that has a problem. It’s difficult enough being a woman involved in the tech community; we don’t need sexual harassment in addition to the pervasive discrimination we face. In this field, practically every person in power is a man. How the hell do we get ahead if men see us either as incapable or an object of sexual gratification? Or both?

One of the people who Scoble sexually assaulted, Quinn Norton, wrote about the experience on Medium. It happened during an O’Reilly Foo Camp, an invite-only enclave of the currently hip and upcoming in the tech community. She was able to defend herself, but later on felt she had to ensure she wouldn’t lose her future invite to the event:

I checked in with the organizers after that to make sure I would still be invited again if I broke Robert Scoble’s nose for sexually assaulting me. They said sure. But neither me nor they did or said anything more. I can’t be sure why for anyone but me, but I know why I decided to stay silent. I never knew who that woman was, I never had a name, contact information, anything. But I knew she was likely to get uncovered and destroyed if I spoke up. I had protected myself, the way I had for years in the technology scene, by threatening what should have been a professional contact with violence. I realized I was part of the problem that night — a woman’s safety in her career environment shouldn’t require credible threats of violence.

But I knew she was likely to get uncovered and destroyed if I spoke up. Not Scoble, you notice, but the woman. The woman would have been destroyed.

Norton also discussed seeking a ‘path of redemption’ for Scoble :

I’m very mixed on this. I believe if we don’t provide paths of redemption for badly behaved people, we enable abusers as much as we do by remaining silent. I also believe we need to talk about these things plainly, and we need to seek to help and elevate the victims.

In my opinion, the ‘path to redemption’  philosophy is why this kind of behavior continues in Hollywood and in tech and every industry where most of the power figures are men—all the man has to do is express sincere-seeming contriteness, maybe go to therapy, and all will be forgiven.  It sends a signal to other men that if they get caught, they only need to grovel in the dirt for a bit and all will be well.

Maybe after 30 years in the industry, I’m cynical about ‘paths to redemption’. I do agree with Norton that we need to talk about these things plainly. However, I’m not seeing a lot of discussion about these events among those who know Scoble. We don’t know how much of this silence is because people are stunned, like me, and how much of the silence is because people are just waiting for it all to blow over.  Business as usual.

I’m especially unhappy with Tim O’Reilly right now because Foo Camp is him.  He’s the center of this particular universe. According to Business Insider

Founder Tim O’Reilly said the company banned Scoble from future events but admitted it “could have done more.”

Yes, he could have done more, and not just dump it on Sara Winge. For one, O’Reilly is in a position more powerful than Scoble’s. He could have helped to prevent future problems by saying a whole lot more about Scoble’s behavior before the accusations came to light this week. Other than the quote at Business Insider, I’ve not found anything he’s written specifically about Foo Camp, Norton, and Scoble. And he should.

One person did speak out, but he did so long ago. He was a young man named Aaron Swartz.

If you talk to any woman in the tech community, it won’t be long before they start telling you stories about disgusting, sexist things guys have said to them. It freaks them out; and rightly so. As a result, the only women you see in tech are those who are willing to put up with all the abuse.

I really noticed this when I was at foo camp once, Tim O’Reilly’s exclusive gathering for the elite of the tech community. The executive guys there, when they thought nobody else was around, talked about how they always held important business meetings at strip clubs and the deficiencies of programmers from various countries.

Meanwhile, foo camp itself had a session on discrimination in which it was explained to us that the real problem was not racism or sexism, but simply the fact that people like to hang out with others who are like themselves.

The denial about this in the tech community is so great that sometimes I despair of it ever getting fixed. And I should be clear, it’s not that there are just some bad people out there who are being prejudiced and offensive. Many of these people that I’m thinking of are some of my best friends in the community. It’s an institutional problem, not a personal one.



Moving to HTTP/2

I upgraded my server to Ubuntu 16.04, converted my websites over to HTTPs, and locked them in using HSTS. It would be a shame to stop here without making one last change: upgrading to the HTTP/2 protocol.

The web has been spinning along on HTTP 1.1 since 1997. It’s been a good and faithful servant. However, the protocol is also showing its age, leading to gimmicks and workarounds just to more readily process today’s web pages.

In 2015, the powers-that-be that brought us HTTP 1.1 released a new transport protocol: HTTP/2. According to a Google introduction on the new protocol:

The primary goals for HTTP/2 are to reduce latency by enabling full request and response multiplexing, minimize protocol overhead via efficient compression of HTTP header fields, and add support for request prioritization and server push.

We’ll look at the advantages to HTTP/2, as well as some of the gotchas associated with it. I’ll then cover what I needed to do on my site to get HTTP/2 up and running.

HTTP/2 is a binary rather than textual protocol

HTTP/2 is a binary protocol, rather than a textual one like HTTP 1.1. OK, that sounds peachy but what does it mean for the average website maintainer?

According to the HTTP/2 specification FAQ:

Binary protocols are more efficient to parse, more compact “on the wire”, and most importantly, they are much less error-prone, compared to textual protocols like HTTP/1.x, because they often have a number of affordances to “help” with things like whitespace handling, capitalization, line endings, blank lines and so on.

The communication between client and server is the same, supporting the same verbs such as GET, PUT, and so on. What’s different is the encoding of these messages. HTTP 1.1 used plain text, while HTTP/2 uses a binary encoding. HTTP 1.1 is human readable, while HTTP/1 was meant for machine access.

Moving from textual to binary won’t matter to most people, but does matter to those developing client or server applications.  For instance, Node.js currently provides an experimental module, HTTP/2, implementing the protocol. And, for the most part, major browsers now support its implementation.

What happens with browsers don’t support HTTP/2? The server should seamlessly downgrade to HTTP 1.1. There is, however, a downside to this, which I’ll get into a little later.

HTTP/2 supports header compression

Each transfer of data between server and client carries a load of metadata, or data about data, providing information about the data being transferred. HTTP 1.1 sent this metadata as plain text, which could add several hundred bytes to the transfer. This doesn’t sound like much, except if you consider how many data transfers occur daily.

According to Internet Live Stats, there are at least 40,000 Google searches a second.  This writing will be just one of over 3 million posted today. Who knows how many tweets are being tweeted, and Facebook posts being liked. I imagine that, at this moment, thousands are buying a pair of shoes online.

There’s more:  when you access a single web page, you’re also accessing other resources, such as images and CSS stylesheets.

All of these activities carry a load of metadata describing what’s happening: the verb for the transaction (GET or POST), the URL, and so on. Combined, sending this information as plain text adds an inordinate burden on the internet, which, in turns, slows the entire internet down for all of us.

HTTP/2 changes all of this by using HPACK, a header compression. Compressing the header data decreases the number of bytes transmitted, and increases the efficiency—not only of the individual requests but of the internet, as a whole.

Again, for the average person, we don’t see this change, and it has no impact on how we use the web. This is all behind the door stuff. However, not all of HTTP/2 is as transparent.

HTTP/2 supports multiplexing

When you access a web page using HTTP 1.1 your browser establishes a connection request using TCP, or Transmission Control Protocol, for each resource.  To keep one web page’s request from bogging down the entire server, host servers limit the number of TCP connections a browser could make. The requests for the page’s web resources have to share the connection, which means that some (many) of the requests would be blocked until previous requests had been satisfied.

The end result of this connection contention is a web page with hundreds of images, no matter how small, as well as dozens of CSS and JavaScript files, no matter how tiny, would be much slower than a web page with fewer resource requests, even though the resources requested with the latter may be larger.

To get around the connection limitation, people have created some interesting and convoluted workarounds.

One workaround is fairly standard: inlining. This means embedding JavaScript and CSS directly into the HTML page, rather than loading separate resources. With the broader support for SVG (Scalable Vector Graphics), graphics can also be embedded directly into the page. The theme this website uses features several SVG icons embedded in the page in the footer.

A more complex workaround is the use of image sprites. You’ll see these used extensively with online games. Image sprites are small, individual images all incorporated into one image file. When the web page is loaded, the larger image is pre-loaded. When one specific image sprite is accessed, CSS would be used to hide the rest of the larger image, only showing the one image.

An even more complex workaround to the connection limit is the use of domain sharding.

Since each TCP connection is limited to a specific domain, one way around the connection limit is to split the resources across several different domains, thereby increasing the number of connections. More connections mean less blocking and faster page loading.

Of course, both workarounds, image sprites and domain sharding, came with their issues. For instance, changing just one tiny image in the entire image file for the sprite file means that the entire file needs to be reloaded the next time the page is loaded. With domain sharding, you have to ensure resources are always stored in the same domain, or the resource will have to be re-cached, losing any performance benefits. There’s also an additional DNS lookup burden to using many domains, and it’s a heck of a problem once you utilize HTTPS: all domains need their own SSL certificate (unless you’re using an authority that can support wildcard * domains).

To summarize, image sprites and domain sharding are kludges. They’re kludges brought about because HTTP 1.1 doesn’t meet today’s web needs. They’re identical in nature to the one pixel transparent GIF we used to use before we had CSS to manage web page spacing, or the use of HTML tables to control a page’s layout.

The primary goal of HTTP/2 and the change bringing about the most impact is the protocol’s support for multiplexing. And this is the one that could most impact on the average person if that person is maintaining a website.

With HTTP/2, multiple resources in the same domain can be accessed concurrently on the same connection. No more blocking, and no need for multiple connections, either.

Think of attending an event at a stadium. At first, only one security checkpoint and entrance are open, and everyone is in a long line, waiting to get in. Now, think about what happens if suddenly ten more security checkpoints and entrances are opened up—the line splits into ten smaller lines, and people move proportionally faster.

Unlike some of the other HTTP/2 protocol changes, this is one that impacts on web designers and developers. Just as we optimized for HTTP 1.1, now we need to consider optimizing, or perhaps de-optimizing, for HTTP/2.

HTTP/2 on Burningbird

After all the other changes I made to my server it made no sense to stop before making the move to HTTP/2. In for a dime, in for a dollar.

The most important change I had to make in order to incorporate HTTP/2 is set my site up to serve pages via HTTPS. Most browsers will not support HTTP/2 from sites that don’t support SSL.

Next, I had to upgrade Apache. The version of Apache that comes standard with Ubuntu 16.04 (2.4.15) doesn’t provide support for HTTP/2. HTTP/2 support in Apache is stable and incorporated starting with version 2.4.17. However, versions earlier than 2.4.26 are considered insecure. So, I needed to upgrade my Apache to 2.4.27. Doing so required me to use a third party Apache package.

After first making a backup of my site using Linode’s snapshot facility, I used Ondřej Surý PPA for Apache2.x  to upgrade to 2.4.27 (all commands are run as sudo):

apt-get apt-get install software-properties-common python-software-properties
add-apt-repository ppa:ondrej/apache2
apt-get update
apt-get upgrade

I got a message about Apache2 and other dependencies being held back. I used dist-upgrade to install the held back packages rather than individually install each:

apt-get dist-upgrade

I tested the new Apache installation before proceeding. However, before I could enable HTTP/2 I had to make one more modification to my system.

Apache 2.4.27 doesn’t support HTTP/2 with the prefork MPM (multiprocessing module). However, the standard PHP installation that works with Apache is dependent on the prefork module. So, before I could change the MPM, I needed to change PHP to FastCGI. I followed HTTP2.Pro’s directions, except that I used the 7.0 version to enable FastCGI:

apachectl stop
apt-get -y install libapache2-mod-fastcgi php7.0-fpm
a2enmod proxy_fcgi setenvif
a2enconf php7.0-fpm
a2dismod php7.0

These commands install and enable the FastCGI module, and disable the previously installed PHP 7.0. I then disabled prefork MPM and enabled the event MPM, and restarted Apache:

apachectl stop
a2dismod mpm_prefork
a2enmod mpm_event
apachectl start

After I checked that FastCGI was working properly with my WordPress-enabled sites, I was ready to enable HTTP/2:

apachectl stop
a2enmod http2
apachectl start

To support the HTTP/2 protocol for my sites, I had to modify the virtual host file for each, adding in the following line:

<VirtualHost *:443>
  Protocols h2 http/1.1

What this line tells Apache is that the HTTP/2 protocol (h2) should be used when the site is accessed, unless the client doesn’t support it. Then, Apache should use HTTP 1.1.

After adding the protocol line to each virtual host, I restarted Apache. I then tested my new HTTP/2 with KeyCDN’s online HTTP/2 test tool.


If you access this web page with most modern browsers, you’re seeing HTTP/2 in action.

HTTP/2 degrades to HTTP 1.1

In the last section I mentioned that if you access this page with most modern browsers, you’re seeing HTTP/2 in action. As you can see from the Can I Use page for HTTP/2, all of the most used modern browsers support HTTP/2.

What happens if you use a browser that doesn’t support HTTP/2? The browser gracefully degrades back to HTTP 1.1. And therein lies a dilemma.

Once you’ve upgraded your site to using HTTP/2 you can get rid of the kludges. You can get rid of image sprites in support of individual image files. You can stop inlining script, CSS, and graphics. You can definitely get rid of domain sharding.

When you do, though, if your page is accessed by someone using a client that doesn’t support HTTP/2, your web page performance degrades, perhaps significantly.

So the key is to understand how people access your website. If the vast majority of access is via modern browsers that support HTTP/2, then you can make the protocol upgrade and begin the process of optimizing your pages for the new protocol.


Moving to HTTP/2 didn’t improve my website performance to a significant degree, primarily because I don’t use a large number of resources in my pages.

However, by upgrading to HTTP/2 now, I know that if I do add additional resources, my pages will still load quickly. I’m future-proofed.

( provides a very effective demonstration of the difference between the protocols.)

I’m still exploring the different HTTP/2 optimizations, including the number of concurrent streams (hence resources loaded) my Apache server supports (100 by default), as well as whether to incorporate the WordPress Server Push plugin. Another advantage to HTTP/2 is it supports server push, which means the site can push the resource to the client even before the client asks for it.

But these tweaks are best left to another day.

With the addition of HTTP/2 my site upgrade is complete.









The Slowness of IPv6

Sunspot on sun obscured by clouds

When I set up my new server and moved my DNS records to my name registrar, I also included records for my server’s IPv6 address (2600:3c00::f03c:91ff:fecf:250d), as well as the familiar IPv4 address (  Supporting both is known as dual stack.

I didn’t have to support IPv6 since I do have an IPv4 address, but if I’m going to do the shiny new with my site, I’m going to go shiny, new all the way.

Besides, there’s no more room at the inn with the old IPv4 system. We’ve run out of web addresses under the old IPv4 addressing system.  The current IPv4 system only allows for 4.3 billion addressed, and they’ve all been assigned.

Yeah, haven’t we been prolific on the web.

Continue reading “The Slowness of IPv6”

Moving to HTTPS: First, you upgrade everything

hummingbird on branch

I was one of the lucky folks who received an email from Google warning me that it was going to start marking input fields in my sites as unsafe. “Time to move to HTTPS”, it smugly informed me.

It irks me that we’ve given a company such power over us that it can force us into using technology before we’re ready. However, I knew it was a matter of time before I’d have to go to HTTPS, so decided to just bite the bullet and get it done.

But if I move to HTTPS, I’m making the task a component of an overall site upgrade.  That was my original intent all along…incorporating HTTPS into a total site makeover. Except my plan was to finish by year-end, rather than October. Best laid plans…

Continue reading “Moving to HTTPS: First, you upgrade everything”