W3C home > Mailing lists > Public > www-tag@w3.org > December 2014

Re: Draft finding - "Transitioning the Web to HTTPS"

From: Eric J. Bowman <eric@bisonsystems.net>
Date: Wed, 10 Dec 2014 01:14:08 -0700
To: Chris Palmer <palmer@google.com>
Cc: Melvin Carvalho <melvincarvalho@gmail.com>, Mark Nottingham <mnot@mnot.net>, "www-tag@w3.org List" <www-tag@w3.org>
Message-Id: <20141210011408.7c70ac63ba55cb9ceed00a4c@bisonsystems.net>
Chris Palmer wrote:
> Why are you here then?

Because I'm still a stakeholder, even if I only ever care about one
website moving forward. My POV has shifted to that of "content creator"
albeit one with 20 years (1994-2013) of nuts-and-bolts experience, six
of those as an ISP, eight of those as a webhost. I believe the small-
business content-creator perspective has historically been lacking in
TAG deliberations, and that my experience qualifies me to give voice to
that perspective.

> > I doubt I'm the only independent developer whose business has
> > literally been killed by "Transitioning the Web to HTTPS" but it's
> > a big reason I won't have anything to do with independent Web
> > development any more. If people didn't think they _need_ HTTPS, I'd
> > still be in the business of providing cost-effective hosting
> > solutions which scale through traffic flurries by way of shared
> > public caching.
> Really? HTTPS is why you are no longer in the web business? Really?

I said it's a big reason. Try to put yourself in the shoes of a forum
operator wondering where everyone's gone. We can endlessly debate the
reasons for that, but one is certainly the difficulty for contributors
to do previously-simple tasks like embedding a video.

Copy https video url + paste into http post = empty iframe. Solving
this problem by dropping the 's' programmatically is subject to breakage
if a video provider starts rewriting http to https. Updating the
implementation to https comes with its own problems vis-a-vis years
worth of archival content and overly-complex software implementations.
Educating contributors is a non-starter.

I don't care to charge clients to play Whack-a-Mole, nor do I care to
run the risk of being sued for nonperformance when my solutions break
overnight due to third-party changes beyond my control. And I will
never steer clients to solutions monetized by treating them as products
not customers.

The main reason for the career change, is I've lost the war without
ever losing a battle. Whether we're talking deprecation of <acronym> or
the utility of REST or any number of other issues I won't admit to
being wrong about even if I concede defeat, how can I move forward as a
Web developer? I can stick to my ways and sacrifice clients, or embrace
change and sacrifice my credibility (not to mention starting over at
square one, experience-wise).

This dinosaur will "take Door #3, Monty."

> Do you know that CloudFlare is offering $0 CDN service via HTTPS?

Do I care? No, as with any free offering the tradeoff is becoming
someone else's product to monetize, instead of their customer to be
served. One look at their TOS reinforces this notion, i.e. Section 11
(surprised they don't want my first-born son), or the last sentence of
Section 10. Same old story -- "overutilizing server resources" leads to
termination, with no definition given of acceptable levels of resource
utilization. No notice + no appeal + no third-party mediation = no
sense in going that route for those of us not on our first pony ride.

> Were any of the sites you deployed so high-traffic that they lived and
> died by transparent intermediary caches?

It's actually easier to deal with high-traffic multinationals for whom
the costs of high-end solutions are justifiable. My bread-and-butter
small-business clients over the years need squid, because cost-effective
five-nines hosting requires staying under a bandwidth cap, beyond which
surcharges exist which are not cost justifiable.

Going with three-nines hosting is not a cost-effective solution, as
Murphy's Law dictates that those several hours of downtime will always
occur when they cause the most damage. The lost business never justifies
the cheaper solution, so I've long architected and implemented sites to
leverage shared intermediary caching into greater reliability. Many of
my (now-former) clients' last encounter with *any* downtime was 9/11.

Received on Wednesday, 10 December 2014 08:14:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:57:08 UTC