Fwd: Jeff Jaffe's response to Issues of concern to the TAG (was: Re: Fwd: Issues of concern to the TAG)

A few minutes ago, I forwarded to this list a copy [1] of the TAG's recent 
note to Jeff Jaffe on issues of concern to the TAG. Here, with his 
permission, is a copy of Jeff's response, which includes several requests 
for additional analysis by the TAG. As previously noted, discussion here on 
www-tag is encouraged, but please try to use separate threads for the 
different topics discussed in the note. Thank you.

Noah

[1] http://lists.w3.org/Archives/Public/www-tag/2012Feb/0049.html

-------- Original Message --------
Subject:  Re: Issues of concern to the TAG
Date:  Sun, 12 Feb 2012 11:29:40 -0500
From:  Jeff Jaffe <jeff@w3.org>
To:  Noah Mendelsohn <nrm@arcanedomain.com>
CC:  TAG Member List <tag@w3.org>



Thanks for this input.  Several comments/questions in-line.

Jeff

On 2/12/2012 9:23 AM, Noah Mendelsohn wrote:
>
> Jeff:
>
> At our June, 2011 F2F meeting of the TAG, you requested [1] that we 
> periodically alert you to developments that we perceive as threatening 
> the technical integrity or success of the Web. This is the first such report.
>
>   * Weaknesses in the Certificate Authority System
>
>     HTTPS, the secure protocol used for access to resources identified
>     with https-scheme identifiers, depends on the the worldwide
>     hierarchical system of Certificate Authorities to validate that users
>     are connecting to the the correct sites. In 2011, various attacks on
>     CA systems led to the creation fraudulent certificate for known
>     sites, allowing man-in-the-middle attacks for SSL protected sites
>     (including social network sites, banks, etc...).
>

While this is clearly a problem for the Web, it is less clear to me who the 
TAG thinks should be addressing the topic.  If the issues are SSL security, 
it would presumably be addressed at the IETF.  Did the TAG decompose the 
problem enough to identify who should be doing what?

>  *
>
>
>     We highlight this issue for several reasons:
>      1. HTTPS is the foundational protocol for secure and private use of
>         the Web. When HTTPS is compromised, the Web becomes unsafe for
>         secure or private communication.
>      2. In some parts of the world, fraudulent certificates used in
>         conjunction with DNS hooks or other man-in-the-middle techniques
>         threaten the interception of politically sensitive
>         communications. Lives may be at risk as a result.
>      3. At the present time, there is no obvious solution that seems
>         likely to reduce the risk of fraudulent certificate creation to
>         an acceptable level.
>
>     The TAG has become aware of this issue through various news reports,
>     and also through a request from Harry Halpin that the TAG investigate
>     [2]. A discussion with Harry and Thomas Roessler is on the agenda for
>     the TAG teleconference of 19 January 2012.
>
Among many other important concerns, the impact on the W3C specifications 
level needs to be assessed.
>
>   * At it's F2F in January 2012, the TAG requested that we highlight this
>     to you as an issue of greatest importance.
>   * SPDY and HTTP
>
>     Recent developments suggest that competitors are emerging to HTTP
>     1.1, which is the core protocol of the World Wide Web. These
>     developments are motivated by the observation that HTTP is
>     inefficient in the many cases where a single Web page is assembled
>     from many separate concurrently retrieved HTTP resources, and also
>     that current implementations of HTTP put a strain on the lower layers
>     of the TCP stack (partly due to lack of or broken implementation of
>     some performance-related optional features of HTTP/1.1 as well as
>     some issues in TCP implementations, see Jim Gettys' and Kathleen
>     Nichols' ACM Queue article on Buffer Bloat [3]). Google's SPDY
>     protocol was created to address these performance issues; several
>     other proposals like HTTP over SCTP, or Waka are also being
>     investigated and are at differing maturity levels.
>
>     SPDY, which has benefited from the most implementation experience and
>     deployment, retains HTTP's application model including headers,
>     status codes, entity bodies etc., but multiplexes multiple HTTP
>     interactions in a flexible manner over a single SSL connection. SPDY
>     is already used by default for connections from Chrome to many Google
>     properties, and Firefox support for SPDY was recently deployed in
>     experiemental form, SPDY is on the roadmap of widely used HTTP
>     servers and open source libraries are starting.
>
>     We highlight this issue because HTTP is the core protocol of the Web
>     stack, and so any change, improvement or new version might have huge
>     impact on the whole Open Web platform. Existing deployments of SPDY
>     use SSL for tunneling through existing proxies, which raises
>     architectural questions relating to caching, certificate management,
>     etc. The TAG met during TPAC with Mike Belshe, one of the co-authors
>     of SPDY. At our recent F2F [4] we also met with Mark Nottingham (IETF
>     liaison with W3C), and discussed with him IETF plans in this area.
>     The TAG will continue to track developments relating to new versions
>     of or replacements for HTTP, but we are satisfied that at least for
>     the moment, the IETF is taking the appropriate steps in this space.
>   * Specifications with the same scope
>
>     Since the creation of W3C, specifications with what seemed to be the
>     same scope were developed. CSS and DSSSL in 1995 was an early
>     example. Issues start to arise when similar specifications are used
>     outside of their main context and clashes can occur:
>       o Canvas/SVG (although there are specific use cases for both)
>       o Microdata/RDFa (See below)
>       o XSL/CSS
>
>     Even more recently, XPath and CSS Selectors were subject of
>     discussions [5] that led to the understanding that it was not a
>     substantive issue. This happens when one set of technology
>     reengineers or adapts solutions done by another set of technologies.
>
>     The Microdata/RDFa conflict was raised during the TAG's review of
>     HTML5. It led to the creation of a Task Force[6], and the publication
>     of two documents (See [7][8]) to address some real identified issues.
>
>     As technology stacks evolve and cover new grounds, other collisions
>     can and will occur. The TAG, as part of its review activity will
>     continue to monitor such issues, and alert you when major issues are
>     detected.
>   * Native mobile & tablet applications vs. Web applications
>
>     Native application environments are currently the platforms of choice
>     of development of most applications for mobile devices. This is due
>     to a combination of factors:
>       o We lack a shared understanding of the security model for
>         privileged application as well as for application lifecycle
>         beyond the simplest cases.
>       o There is a functionality gap between the capabilities of native
>         platforms and the Web platform. This is primarily due to the fact
>         that, it is faster to ship a proprietary feature than the same
>         one through a specification with multiple interoperable
>         implementations.
>       o The "monetisation" ecosystem for Web applications is not as well
>         developed as for native applications that benefit from app stores.
>       o Projects that take a stab at creating mobile platforms based on
>         Web technology (e.g. WAC, Tizen) suffer from a lack of
>         documentation of the design preferences and best practices in Web
>         API design.
>
>     Because of this, there is a risk that barring a coherent push to
>     improve the core Web platform for mobile devices native applications
>     will remain dominant over the next ten years. This risk is however
>     mitigated by several factors:
>       o The W3C has a strong investment in improving the Web application
>         platform, notably in the mobile area.
>       o Many developers who ship their applications as native in fact use
>         so-called "hybrid" systems in which they create Web applications
>         that are wrapped in native containers. This enables them to
>         transition to Web applications with minimal effort.
>       o Major efforts are made in the industry to strengthen the Web as
>         an application platform, notably for mobile devices. These
>         include Mozilla's Boot To Gecko, Microsoft's Windows 8, and
>         Samsung + Intel's Tizen. Their experience is feeding into the
>         production of open standards.
>
>     As a result, there is a window of opportunity for the Web platform to
>     disrupt mobile application development faster than it did on the
>     desktop.
>

This is a key area of concern.  Did the TAG produce a specific list of 
features that would be appropriate for the Web platform to help it catch up 
in areas where it is currently behind?

>   * Distributed extensibility and CSS vendor prefixes
>
>     We're still trying to manage distributed extensibility, but the
>     mechanism the CSS WG was using is now under threat. Mozilla and Opera
>     are currently making plans to implement support for -webkit- prefixed
>     CSS properties in their respective browsers. They feel they are being
>     driven to this due to the large amount of mobile web content that
>     only provides -webkit- prefixed properties despite the availability
>     of equivalent prefixed properties on Gecko and Presto.
>
>     If browser vendors begin implementing other browser's proprietary
>     properties, the entire standards process is in danger of getting
>     usurped. This also puts the plan to apply vendor prefixes in another
>     areas (such as JavaScript) at risk as the primary purpose for having
>     vendor specific prefixes is being bypassed.
>
>     The CSS working group may make progress in limiting long-term
>     deployment of proprietary extensions that would be better
>     standardized, but prospects for success aren't entriely clear.
>

Did the TAG discuss solutions?  My instincts is that there is an 
opportunity to address this by speeding up the pace of standardization.  If 
everyone is using the same approach - why should everyone call it "webkit", 
why can't we just agree?

> We hope you find this to be useful.
>

Yes.

> Unless you suggest to the contrary, we will continue to prepare reports 
> like this for you approximately twice each year, as you requested in June.
>
> Also: in keeping with our mandate to work "in public" whenever practical, 
> the TAG is inclined to send copies of this and future reports to our 
> public mailing list.
>

Agreed.

> Since this work was done in response to your personal request for TAG 
> input, we wanted to first check whether you agree that doing so is 
> appropriate. Obviously, we will make exceptions if any future report 
> contains unusually sensitive or member-confidential information. Please 
> let me know what you would prefer.
>
> Thank you very much.
>
> Noah Mendelsohn
> For the W3C Technical Architecture Group
>
> [1] http://www.w3.org/2001/tag/2011/06/06-minutes.html#item02
> [2] http://lists.w3.org/Archives/Public/www-tag/2011Dec/0083.html
> [3] 
> http://delivery.acm.org/10.1145/2080000/2071893/p40-gettys.pdf?ip=146.115.66.224&acc=OPEN&CFID=78529281&CFTOKEN=40620254&__acm__=1326812344_a90ac6c94bc5fbbba599fda9ff0da640 
> <http://delivery.acm.org/10.1145/2080000/2071893/p40-gettys.pdf?ip=146.115.66.224&acc=OPEN&CFID=78529281&CFTOKEN=40620254&__acm__=1326812344_a90ac6c94bc5fbbba599fda9ff0da640>
> [4] http://www.w3.org/2001/tag/2012/01/06-minutes#item02 [5] 
> http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1236.html
> [6] http://www.w3.org/wiki/Html-data-tf
> [7] http://www.w3.org/TR/html-data-guide/
> [8] http://www.w3.org/TR/microdata-rdf/
>