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

Chris Palmer wrote:
> Noah Mendelsohn wrote:
> > protocols by which they are accessed. If we recommend that most or
> > all resources be named with https-scheme names, then it becomes
> > much harder to re-enable proxying should that later become
> > desirable.
> As I outlined in my response to the remote island problem, it will
> still very much be able to re-enable proxying. But, the clients will
> have to knowingly and intentionally trust the proxies.

Hardly the same thing. Wearing my former-ISP hat, opting in to proxying
represents moving on to something different, not re-enabling something
proven which we stand on the verge of losing.

> We've seen what implicit trust has gotten us:

What I see, is the lack of a page integrity mechanism. Such sophomoric
efforts could be easily defeated at the user-agent layer by (at least)
alerting the user that their comms are being altered, even over HTTP.
The concept of implicit trust isn't at fault here, implementation is.


>From the article:

"'This is even at a more serious level than throttling traffic because
ISPs are going in and modifying traffic in transit and that's something
that they should not be doing,' Hoffman-Andrews said. 'They are paid by
their customers to be trusted conduit for data, and they should be
sending that data through faithfully rather than trying to insert or
remove things.'"

This is surprisingly naive for EFF. Sometimes customers don't pay for
services, in exchange for opting-in to DPI-based content injection. The
ToS clearly explaining the tradeoff, is by and large never read by the
users who complain.

The users who don't complain would mostly be surprised that a group
such as EFF thinks they're being defrauded or abused, somehow, for
opting in to something with their eyes wide open. Mostly, folks grok
the "no free lunch" concept. For example...

If you've been around webhosting as long as I have, you've had to deal
with legacy content of deceased customers. In many cases, their estates
are happy to have advertising injected into the content to fund ongoing
hosting of the bereaved's blog, domain, e-mail (handled by longtime
contributors), and other such housekeeping. If I had an ISP nowadays,
I'd brand this (DPI-based) offering as "eternal flame" service.

(I suspect I'm the only regular participant here who's ever even
remotely dealt with this issue firsthand.)

Just wondering how much consideration has been given to all the ISP and
webhosting customers out there who've, erm, sold their souls to the
devil in exchange for service. I'd be against it if I thought they were
being hoodwinked; instead, I find DPI-based services cromulent.

The alternative is dismissing and deprecating yet more viable business
models in the name of... well, if it were architectural purity then
maybe I'd be in favor, let's leave it at that.


IMO the gross deficiency of the Web as regards that document, is the
lack of a content integrity mechanism, as I've previously stated. Not a
lack of ubiquitous HTTPS.

> Middleboxes have to show honest value:

-1. This document is agenda-driven to the point of being a manifesto. I
was intrigued by the abstract and approached it with an open mind, but
was ultimately disappointed; extremely disagree is an understatement.

> > Whatever the final answer we choose, I we should remember that
> > changes affecting the naming of resources have effects over
> > decades, not just years. They are in that sense very hard to undo.
> Exactly right. We are now trying to undo implicit trust of
> untrustworthy middleboxes, because they threaten democracy. (Oh, and
> they threaten business too. I'm more concerned about democracy
> though.)

After 20 years as an entrepreneur, it's become apparent that my greatest
deficiency is a lack of ruthlessness; i.e. I'm too concerned about
democracy to be much of a capitalist. But I fail to see implicit trust,
if implemented correctly (the RFC Julian linked to seems an excellent
starting point), as detrimental to either democracy or profit.

Attacking the problem of untrustworthy middleboxes, while noble, fails
by seeing the problem as one of the existence of middleboxes, and
attempting to "solve" it by mandating HTTPS.


Received on Tuesday, 20 January 2015 07:26:10 UTC