Fwd: Issues of concern to the TAG

At the TAG's F2F meeting in June of 2011, Jeff Jaffe asked us to 
periodically provide him with reports on technical and architectural issues 
that the TAG believes should be of concern to the W3C. We provided our 
first such report to Jeff last week, and with his permission, I am 
forwarding this copy to www-tag@w3.org.

Discussion is encouraged, but since multiple topics are covered, it may be 
helpful if you change the subject line of any responses so that we can keep 
separate threads for the various issues. Thank you.

Noah

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


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...).

    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.
  * 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.

We hope you find this to be useful. 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. 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/