W3C home > Mailing lists > Public > www-tag@w3.org > February 2015

Re: Don't cache things against content providers' wishes. Re: Draft finding - "Transitioning the Web to HTTPS"

From: Eric J. Bowman <eric@bisonsystems.net>
Date: Sun, 22 Feb 2015 20:31:52 -0700
To: Tim Berners-Lee <timbl@w3.org>
Cc: Mark Nottingham <mnot@mnot.net>, Mark Watson <watsonm@netflix.com>, Henri Sivonen <hsivonen@hsivonen.fi>, David Sheets <kosmo.zb@gmail.com>, Noah Mendelsohn <nrm@arcanedomain.com>, Public TAG List <www-tag@w3.org>
Message-Id: <20150222203152.d81896ff47e5e505ecb65b86@bisonsystems.net>
Tim Berners-Lee wrote:
> But also, when things should be a laws (or regulations, etc), then we
> should say that too.  This community can't just work by making
> internet protocols, it has to make or suggest laws too. The system is
> one of machines operating under protocols and people/companies
> operating under laws.  To make a system which works you have to have
> both parts defined together.

Laws, no; policy derived from intent, yes. REST advocacy below...

> It is is counterproductive to say that technology and policy should
> be discussed in different fora.

True, that.

> The text may be just useful to how the protocols assume people will
> interact, it may be used to actually draft rules and regulations and
> policy and legislation. 

I'd rather say "guide the drafting of" based on notions of architecture
which apply from one TAG regime to the next, therefore can't be
dismissed as ad-hoc; as related to common implementation decisions,
backed up by use-cases.

> Should ideally it be illegal to cache things against the
> content-owner's wishes, then?

That's rough, because my take on the protocol has been to never cache
data I don't want cached, otherwise it may be cached forever, i.e. by
archive.org. How can it be illegal to break a promise the protocol
never made?

> Should it be illegal for an ISP to inject anything (like javascript)
> of any sort into anything (like http: HTML pages) ?

Sure, except most affected users opted in to such schemes. Should we
outlaw _that_? Especially when RFCs exist which say user concerns are
paramount? I know, I'm a PITA, sorry TBL.

> Making it illegal doesn't stop the remote outright criminal or the
> oppressive regime.  But it stops corporations and institutions, like
> ISPs and SNSs and content providers in many countries.  It means that
> the incentives tip, can make the system run a whole lot more
> smoothly, and we can focus the  energy and the technical measures
> more effectively.

Maybe. But maybe we could re-embrace intermediaries participating in
Web communication, thereby disincentivizing pursuit of what we'd like
to declare "illegal" as the only means left for their developers to
stay in business.

Another approach would be analogies in WWW-Arch directed beyond Web
developers, e.g. addressing policy concerns. As opposed to declaring
this sort of RPC approach illegal:


The TAG could somehow publish something which states that the Web is
not intended for direct mapping to RPC interfaces, as doing so goes
against Web Arch and leads to unintended consequences. The Web's been
around long enough to have the luxury of case studies to point to, and
in the case of proper URI allocation-scheme design, there couldn't be a
better example (particularly as it's public-sphere) than healthcare.gov.

Which is RPC vs. REST, as naked as it gets. Just being able to call RPC
out as a recognizably stupid design pattern for the Web, would go a lot
further than attempting to find precedent for calling it illegal. Let
the policy-makers and courts decide, based on TAG guidance.

The government went out and hired developers experienced, and
successful, at producing RPC-oriented websites. Which in this case
compromise user privacy, HTTPS notwithstanding. Which is another danger
in applying the anointing oil to ubiquitous HTTPS -- it gives a false
sense of security belied by the underlying technology, when that tech
is used improperly, especially to RPC Web developers who don't know any
better, but may now reassure their customers that they're following
best practices for security and privacy (which really they aren't, and
never began to be, and HTTPS isn't a band-aid for that).

But the TAG has never really committed to REST and declared RPC design
to be harmful. So it's hard to fault healthcare.gov developers for
following established custom and practice. Let that be Exhibit A of the
downside in TAG not commenting on policy, let alone from a standpoint of
architecture. REST architecture, at that. What healthcare.gov did,
regardless of what the GOP says about it, strikes me as more ignorant
than nefarious.

If they'd only claimed to be RESTful, it wouldn't have taken 'til Jan
2015 for this problem to come to light... REST obsolete? No, it's more
pertinent than ever, IMNSHO.


> timbl
> director hat off
Received on Monday, 23 February 2015 03:32:15 UTC

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