- 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>
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: https://nakedsecurity.sophos.com/2015/01/23/how-the-obamacare-website-healthcare-gov-leaks-private-data/ 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. -Eric > > timbl > > director hat off >
Received on Monday, 23 February 2015 03:32:15 UTC