Re: [W3C TCP and UDP Socket API]: Status and home for this specification

On Wed, Apr 1, 2015 at 11:22 AM, Nilsson, Claes1 <
Claes1.Nilsson@sonymobile.com> wrote:

> Hi all,
>
>
>
> Related to the recent mail thread about the SysApps WG and its
> deliverables I would like to make a report of the status of the TCP and UDP
> Socket API, http://www.w3.org/2012/sysapps/tcp-udp-sockets/.
>
>
>
> Note that this specification is still being worked on. Latest merged PR
> was March 30. I think it is time for a new Public Working Draft.
>
>
>
> This API is used to send and receive data over the network using TCP or
> UDP.
>
> Examples of use cases for the API are:
>
>    - An email client which communicates with SMTP, POP3 and IMAP servers
>    - An irc client which communicates with irc servers
>    - Implementing an ssh app
>    - Communicating with existing consumer hardware, like internet
>    connected TVs
>    - Game servers
>    - Peer-to-peer applications
>    - Local network multicast service discovery, e.g. UPnP/SSDP and mDNS
>
> Some of these usecases are served suitably by WebSockets and WebRTC (once
it reaches good deployment state). Of course there's drawbacks to that (a
bit of overhead, some weird semantics, some restrictions and zero legacy
integration)

The TCP and UDP Socket API is a phase 1 deliverable of the SysApps WG.
> SysApps was originally chartered to provide a runtime and security model so
> that it would be possible to open up sensitive APIs to SysApps enabled
> runtimes. Accordingly, it was assumed that the TCP and UDP Socket API would
> be exposed to such a “trusted runtime”. Looking at existing TCP and UDP
> Socket APIs they are implemented in proprietary web runtimes, FFOS and
> Chrome, which provide a security model for installed packaged web runtimes.
>
I don't particularly like the idea of priviledged webapps unless absolutely
necessary.


> I recently added “permission methods”, partly inspired by the W3C Push
> API. A webapp could for example request permission to create a TCP
> connection to a certain host. The ambition is to isolate the permission
> system from the socket interfaces specifications and the manner in which
> permission to use this API is given differs depending on the type of web
> runtime the API is implemented in. For example, a web runtime for secure
> installed web applications may be able to open up this API so that no
> explicit user content is needed, while an implementation in a web browser
> may use a combination of web security mechanisms, such as secure transport
> (https:), content security policies (CSP), signed manifest, certificate
> pinning, and user consent to open up the API.
>
I'd like to point out the permissionities syndrome. There are two parts to
this syndrome, the first is the use of an ever growing list of complex
permissions for users to manage. Good examples of that are:
http://codeflow.org/issues/permissions.jpg , http://i.imgur.com/pTzdLnI.png
, http://i.imgur.com/MY5o9MP.png etc. The second part is recent research
has shown that showing people security prompts makes them turn off their
brain, literally,
http://www.extremetech.com/computing/201698-mri-scans-of-the-brain-show-why-we-ignore-security-warnings

Also note, most people don't know what a browser is, they certainly don't
know what a host is, and even if they knew, they couldn't gauge the
security implications of what it means they're saying yes to.