This observation seems intuitively obvious in Europe and pearl-clutchingly shocking in America:
What’s perfectly acceptable behaviour when you are a relatively small company becomes outright illegal (and rightly so) when you become dominant in an industry.
We’re in a rare moment when a shift just may be possible; the previously intractable and permanent-seeming systems and platforms are showing that they can be changed and moved, and something new could actually grow.
The fix for the internet isn’t to shut down Facebook or log off or go outside and touch grass. The solution to the internet is more internet: more apps, more spaces to go, more money sloshing around to fund more good things in more variety, more people engaging thoughtfully in places they like. More utility, more voices, more joy.
There’s a time for linguistics, and there’s a time for grabbing the general public by the shoulders and shouting “It lies! The computer lies to you! Don’t trust anything it says!”
We also have a culture in which arrogance is rewarded rather than kept in check, and people can see that with enough shameless bluster you might become the richest person in the world or the president of the United States. There is no quick fix for the problem—if I offered one, I would be the very kind of bullshitter I strive to avoid being—but we at the very least need to recognize what it is we are trying to change. We are trying to create a culture of thoughtfulness and insight, where people check carefully to see whether what they’re saying is true, and excessively egotistical people are looked upon with deep suspicion. With time and patient effort, perhaps we can create a world in which the people who rise to the highest offices and reap the greatest rewards are not also the ones who are most full of shit.
I must remember to try this out-of-office email strategy.
I’ve lately been trying an exercise where, when reading anything by or about tech companies, I replace uses of the word “infrastructure” with “means of production.”
Brilliant!
Earlier this year, at Indie Web Camp Düsseldorf, I got replies working on my own site. That is to say, I can host a reply on my site to something on another site.
The classic example is Twitter. In fact, if you look at all my replies, most of them are responding to tweets (I also syndicate these replies to Twitter so they show up there just like regular tweet replies).
I’m really, really glad I got replies working. I’ve been using this functionality quite a bit, and it feels really good to own my content this way.
At the time, I wrote:
So I’m owning my replies now. At the moment, they show up in my home page feed just like any other notes I post. I’m not sure if I’ll keep it that way. They don’t make much sense out of context.
I decided not to include them on my home page feed after all. You’ll still see them if you go to the notes section of my site, but I decided that they were overwhelming my home page a bit. They also don’t show up in my RSS feed.
I’m really happy that I’m hosting my replies, and that I’ve got URLs for all of them, but I don’t think I want to give them the same priority as blog posts, links, and regular notes.
Last week was a bit of an event whirlwind. In the space of seven days I was at Indie Web Camp, Beyond Tellerrand, and Accessibility Club in Düsseldorf, followed by a train ride to Utrecht for Frontend United. Phew!
Indie Web Camp Düsseldorf was—as always—excellent. Once again, Sipgate generously gave us the use of their lovely, lovely space for the weekend. We had one day of really thought-provoking discussions, followed by a day of heads-down hacking and making.
I decided it was time for me to finally own my replies. For a while now, I’ve been posting notes on my own site and syndicating to Twitter. But whenever I replied to someone else’s tweet, I did from Twitter. I wanted to change that.
From a coding point of view, it wasn’t all that tricky. The real challenges were to do with the interface. I needed to add another field for the URL I’m replying to …but I didn’t want my nice and minimal posting interface to get too cluttered. I ended up putting the new form field inside a details element with a summary of “Reply to” so that the form field would be hidden by default, and toggled open by hitting that “Reply to” text:
<details>
<summary>
<label for="replyto">Reply to</label>
</summary>
<input type="url" id="replyto" name="replyto">
</details>
I sent my first test reply to a post on Aaron’s website. Aaron was sitting next to me at the time.
Once that was all working, I sent my first reply to a tweet. It was a response to a tweet from Tantek. Tantek was also sitting next to me at the time.
I spent most of the day getting that Twitter syndication to work. I had something to demo, but I foolishly decided to risk it all by attempting to create a bookmarklet so that I could post directly from a tweet page (instead of hopping back to my own site in a different tab). By canabalising the existing bookmarklet I use for posting links, I just about managed to get it working in time for the end of day demos.
So I’m owning my replies now. At the moment, they show up in my home page feed just like any other notes I post. I’m not sure if I’ll keep it that way. They don’t make much sense out of context.
Then again, I kind of like how wonderfully random and out-of-context they look. You can browse through all my replies so far.
I’m glad I got this set up. Now when Andy posts stuff on Twitter, I’m custodian of my responses:
@AndyBudd: Who are your current “Design Heroes”?
adactio.com: I would say Falcor from Neverending Story, the big flying dog.
A nice little tutorial from Aaron.
Watch the prep time increase as you make more and more of a recipe’s ingredients from scratch.
I guess Carl Sagan was right. To make an apple pie from scratch, you must first invent the universe.
What’s happening right now at the US border is heartbreaking and inexcusable. We’re donating 25% of all profits today and tomorrow (June 19 & 20) to RAICES, to help reunite detained immigrant parents and children.
The latest edition of the excellent History Of The Web newsletter is called The Day(s) The Web Fought Back. It recounts the first time that websites stood up against bad legislation in the form of the Communications Decency Act (CDA), and goes to recount the even more effective use of blackout protests against SOPA and PIPA.
I remember feeling very heartened to see WikiPedia, Google and others take a stand on January 18th, 2012. But I also remember feeling uneasy. In this particular case, companies were lobbying for a cause I agreed with. But what if they were lobbying for a cause I didn’t agree with? Large corporations using their power to influence politics seems like a very bad idea. Isn’t it still a bad idea, even if I happen to agree with the cause?
Cloudflare quite rightly kicked The Daily Stormer off their roster of customers. Then the CEO of Cloudflare quite rightly wrote this in a company-wide memo:
Literally, I woke up in a bad mood and decided someone shouldn’t be allowed on the Internet. No one should have that power.
There’s an uncomfortable tension here. When do the ends justify the means? Isn’t the whole point of having principles that they hold true even in the direst circumstances? Why even claim that corporations shouldn’t influence politics if you’re going to make an exception for net neutrality? Why even claim that free speech is sacrosanct if you make an exception for nazi scum?
Those two examples are pretty extreme and I can easily justify the exceptions to myself. Net neutrality is too important. Stopping fascism is too important. But where do I draw the line? At what point does something become “too important?”
There are more subtle examples of corporations wielding their power. Google are constantly using their monopoly position in search and browser marketshare to exert influence over website-builders. In theory, that’s bad. But in practice, I find myself agreeing with specific instances. Prioritising mobile-friendly sites? Sounds good to me. Penalising intrusive ads? Again, that seems okey-dokey to me. But surely that’s not the point. So what if I happen to agree with the ends being pursued? The fact that a company the size and power of Google is using their monopoly for any influence is worrying, regardless of whether I agree with the specific instances. But I kept my mouth shut.
Now I see Google abusing their monopoly again, this time with AMP. They may call the preferential treatment of Google-hosted AMP-formatted pages a “carrot”, but let’s be honest, it’s an abuse of power, plain and simple.
By the way, I have no doubt that the engineers working on AMP have the best of intentions. We are all pursuing the same ends. We all want a faster web. But we disagree on the means. If Google search results gave preferential treatment to any fast web pages, that would be fine. But by only giving preferential treatment to pages written in a format that they created, and hosted on their own servers, they are effectively forcing everyone to use AMP. I know for a fact that there are plenty of publications who are producing AMP content, not because they are sold on the benefits of the technology, but because they feel strong-armed into doing it in order to compete.
If the ends justify the means, then it’s easy to write off Google’s abuse of power. Those well-intentioned AMP engineers honestly think that they have the best interests of the web at heart:
We were worried about the web not existing anymore due to native apps and walled gardens killing it off. We wanted to make the web competitive. We saw a sense of urgency and thus we decided to build on the extensible web to build AMP instead of waiting for standard and browsers and websites to catch up. I stand behind this process. I’m a practical guy.
There’s real hubris and audacity in thinking that one company should be able to tackle fixing the whole web. I think the AMP team are genuinely upset and hurt that people aren’t cheering them on. Perhaps they will dismiss the criticisms as outpourings of “Why wasn’t I consulted?” But that would be a mistake. The many thoughtful people who are extremely critical of AMP are on the same side as the AMP team when it comes the end-goal of better, faster websites. But burning the web to save it? No thanks.
: seriously, just give me a bloody opt-out from this knock-off web
— Alex Russell (@slightlylate) January 14, 2017
Ben Thompson goes into more detail on the tension between the ends and the means in The Aggregator Paradox:
The problem with Google’s actions should be obvious: the company is leveraging its monopoly in search to push the AMP format, and the company is leveraging its dominant position in browsers to punish sites with bad ads. That seems bad!
And yet, from a user perspective, the options I presented at the beginning — fast loading web pages with responsive designs that look great on mobile and the elimination of pop-up ads, ad overlays, and autoplaying videos with sounds — sounds pretty appealing!
From that perspective, there’s a moral argument to be made for wielding monopoly power like Google is doing. No doubt the AMP team feel it would be morally wrong for Google not to use its influence in search to give preferential treatment to AMP pages.
Going back to the opening examples of online blackouts, was it morally wrong for companies to use their power to influence politics? Or would it have been morally wrong for them not to have used their influence?
When do the ends justify the means?
Here’s a more subtle example than Google AMP, but one which has me just as worried for the future of the web. Mozilla announced that any new web features they add to their browser will require HTTPS.
The end-goal here is one I agree with: HTTPS everywhere. On the face of it, the means of reaching that goal seem reasonable. After all, we already require HTTPS for sensitive JavaScript APIs like geolocation or service workers. But the devil is in the details:
Effective immediately, all new features that are web-exposed are to be restricted to secure contexts. Web-exposed means that the feature is observable from a web page or server, whether through JavaScript, CSS, HTTP, media formats, etc. A feature can be anything from an extension of an existing IDL-defined object, a new CSS property, a new HTTP response header, to bigger features such as WebVR.
Emphasis mine.
This is a step too far. Again, I am in total agreement that we should be encouraging everyone to switch to HTTPS. But requiring HTTPS in order to use CSS? The ends don’t justify the means.
If there were valid security reasons for making HTTPS a requirement, I would be all for enforcing this. But these are two totally separate areas. Enforcing HTTPS by withholding CSS support is no different to enforcing AMP by withholding search placement. In some ways, I think it might actually be worse.
There’s an assumption in this decision that websites are being made by professionals who will know how to switch to HTTPS. But the web is for everyone. Not just for everyone to use. It’s for everyone to build.
One of my greatest fears for the web is that building it becomes the domain of a professional priesthood. Anything that raises the bar to writing some HTML or CSS makes me very worried. Usually it’s toolchains that make things more complex, but in this case the barrier to entry is being brought right into the browser itself.
I’m trying to imagine future Codebar evenings, helping people to make their first websites, but now having to tell them that some CSS will be off-limits until they meet the entry requirements of HTTPS …even though CSS and HTTPS have literally nothing to do with one another. (And yes, there will be an exception for localhost and I really hope there’ll be an exception for file: as well, but that’s simply postponing the disappointment.)
No doubt Mozilla (and the W3C Technical Architecture Group) believe that they are doing the right thing. Perhaps they think it would be morally wrong if browsers didn’t enforce HTTPS even for unrelated features like new CSS properties. They believe that, in this particular case, the ends justify the means.
I strongly disagree. If you also disagree, I encourage you to make your voice heard. Remember, this isn’t about whether you think that we should all switch to HTTPS—we’re all in agreement on that. This is about whether it’s okay to create collateral damage by deliberately denying people access to web features in order to further a completely separate agenda.
This isn’t about you or me. This is about all those people who could potentially become makers of the web. We should be welcoming them, not creating barriers for them to overcome.
JP Rangaswami also examines the rise of the platforms but he’s got some ideas for a more sustainable future:
A part of me wants to evoke Jane Jacobs and Christopher Alexander when it comes to building sustainable platforms. The platform “community” needs to be cared for and looked after, the living spaces they inhabit need to be designed to last. Multipurpose rather than monoculture, diverse rather than homogeneous . Prior industrial models where entire communities would rely on a single industry need to be learnt from and avoided. We shouldn’t be building the rust belts of the future. We should be looking for the death and life of great platforms, for a pattern language for sustainable platforms.
This is the clickbaitiest of titles, but the post has some good sobering analysis of how much traffic driven by a small handful players. It probably won’t make you feel very cheery about the future.
(For some reason, this article uses all-caps abbreviations for company names, as though a stock ticker started generating hot takes: GOOG, FB, AMZN, etc. It’s a very odd writing style for a human.)
Ethan quite rightly points out some semantic sleight of hand by Google’s AMP team:
But when I hear AMP described as an open, community-led project, it strikes me as incredibly problematic, and more than a little troubling. AMP is, I think, best described as nominally open-source. It’s a corporate-led product initiative built with, and distributed on, open web technologies.
But so what, right? Tom-ay-to, tom-a-to. Well, here’s a pernicious example of where it matters: in a recent announcement of their intent to ship a new addition to HTML, the Google Chrome team cited the mood of the web development community thusly:
Web developers: Positive (AMP team indicated desire to start using the attribute)
If AMP were actually the product of working web developers, this justification would make sense. As it is, we’ve got one team at Google citing the preference of another team at Google but representing it as the will of the people.
This is just one example of AMP’s sneaky marketing where some finely-shaved semantics allows them to appear far more reasonable than they actually are.
At AMP Conf, the Google Search team were at pains to repeat over and over that AMP pages wouldn’t get any preferential treatment in search results …but they appear in a carousel above the search results. Now, if you were to ask any right-thinking person whether they think having their page appear right at the top of a list of search results would be considered preferential treatment, I think they would say hell, yes! This is the only reason why The Guardian, for instance, even have AMP versions of their content—it’s not for the performance benefits (their non-AMP pages are faster); it’s for that prime real estate in the carousel.
The same semantic nit-picking can be found in their defence of caching. See, they’ve even got me calling it caching! It’s hosting. If I click on a search result, and I am taken to page that has a URL beginning with https://www.google.com/amp/s/... then that page is being hosted on the domain google.com. That is literally what hosting means. Now, you might argue that the original version was hosted on a different domain, but the version that the user gets sent to is the Google copy. You can call it caching if you like, but you can’t tell me that Google aren’t hosting AMP pages.
That’s a particularly low blow, because it’s such a bait’n’switch. One of the reasons why AMP first appeared to be different to Facebook Instant Articles or Apple News was the promise that you could host your AMP pages yourself. That’s the very reason I first got interested in AMP. But if you actually want the benefits of AMP—appearing in the not-search-results carousel, pre-rendered performance, etc.—then your pages must be hosted by Google.
So, to summarise, here are three statements that Google’s AMP team are currently peddling as being true:
I don’t think those statements are even truthy, much less true. In fact, if I were looking for the right term to semantically describe any one of those statements, the closest in meaning would be this:
A statement used intentionally for the purpose of deception.
That is the dictionary definition of a lie.
Update: That last part was a bit much. Sorry about that. I know it’s a bit much because The Register got all gloaty about it.
I don’t think the developers working on the AMP format are intentionally deceptive (although they are engaging in some impressive cognitive gymnastics). The AMP ecosystem, on the other hand, that’s another story—the preferential treatment of Google-hosted AMP pages in the carousel and in search results; that’s messed up.
Still, I would do well to remember that there are well-meaning people working on even the fishiest of projects.
Except for the people working at the shitrag that is The Register.
(The other strong signal that I overstepped the bounds of decency was that this post attracted the pond scum of Hacker News. That’s another place where the “well-meaning people work on even the fishiest of projects” rule definitely doesn’t apply.)
Make Twitter Great Again:
Fix Twitter is a browser extension to always show “replying to” in replies and threads along with an option to restore the old-school @-mentions.
These statements aren’t true. But they are repeated so often, as if they were truisms, that we run the risk of believing them and thus, fulfilling their promise.
I’m at Indie Web Camp and we’re onto the second day, which involves hacking on stuff (the first day involved discussing stuff).
I’ve had my head down attempting to implement webmentions on my site—basically a simpler form of pingback.
This probably won’t work, and this is the first basic step, but if you write a reply to this post on your own site, you should be able to ping me by entering your post’s URL into the form under this post.
Now, this is just a first run so all I’m doing is gathering the pings—I’m not actually going to fetch and parse your post; that step can come later. But if you want to help me kick the tires on this, write something on your site that links to this post and then enter your post’s URL below.
Quotably offers a nice well-ordered interface onto Twitter conversations.