On 2015-04-02 09:56, Jeffrey Yasskin wrote:
It seems like a CG is appropriate for the Sockets API. It's not clear
that a browser is going to adopt it unless the Trust & Permissions CG
comes up something, but if more native platforms like Cordova and FFOS
want to coordinate on a shared interface, a CG is a good place to
iterate on that. If it's successful in a CG, that may generate more
enthusiasm for putting it in a particular WG.
One of the reasons for some specs failing in the SysApps WG before the
whole thing failed was the inability to get 2 independent
implementations of specs. In a CG, you don't have to worry about that
and can try to develop it to the point where it has some support and can
move back to a WG.
Jeffrey
On Thu, Apr 2, 2015 at 2:46 AM, Nilsson, Claes1
<claes1.nils...@sonymobile.com <mailto:claes1.nils...@sonymobile.com>>
wrote:
Thanks for all replies to my mail below.
To address the “security/webapp permission to use the API”- issue
I see the following alternatives:
1.Keep as is: This means that the way permission is given to a
webapp to use the API is not defined by the TCP and UDP Socket
API, only methods to request permission and to check if permission
is given are defined and the implementation of the
security/permission system depends on the web runtime in which the
API is implemented. See section 4 to 8 in the specification:
http://www.w3.org/2012/sysapps/tcp-udp-sockets/#security-and-privacy-considerations.
As far as I understand this approach would make the API
implementable in legacy web runtimes such as FFOS, Chrome Apps and
Tizen and in “Webviews” used in by hybrid native-web apps in which
the security model is defined by the native environment.
Currently the API is not implementable in the normal open web
browser but may be in the future? If the web is going to evolve as
a capable application environment general solutions on the
security issues with exposing more powerful APIs must be solved. I
refer for example to ongoing work in Web Apps Sec WG and
Trust&Permission CG. SoMC has also experimented with “Trusted
Hosted Apps”,
https://lists.w3.org/Archives/Public/public-sysapps/2014Sep/att-0000/SoMC_FFOS_Trusted_Hosted_Apps.pdf.
The main issue here is if it is today (as SysApps now is dead) in
the scope for W3C to standardize APIs that only are implementable
in legacy web runtimes but currently are not implementable in the
standard open web browser context, even though it may be
implementable in the future assuming an improved security model ?
2.In the specification define a security model based on “same
origin”/CORS: This has been discussed on this thread and may be
possible. However, the drawback of this approach is that this
limits the scope of use cases. For example, discovery of and
communication with legacy devices in local networks.
3.In the specification define a security model for example based
on https:, content security policies (CSP), a signed manifest and
certificate pinning. This may be possible but I feel that such a
security model is a general solution and it fells as we then, in
an API specification, are defining a part of a web runtime.
Alternatives for the future of this API specification:
1.Move to a new CG
2.Move to DAP or Web Apps
3.Stop working on it and make it an informative Working Group Note
The decision of course depends on the use cases for this API and
the manner in which the use cases are implemented. Do we still
need a low level TCP and UDP Socket API to communicate with legacy
devices or could we rely on Web Sockets, Web RTC and higher level
approaches such as 2^nd screen API?
BR
Claes
*Claes Nilsson*
Master Engineer - Web Research
Advanced Application Lab, Technology
*Sony Mobile Communications*
Tel: +46 70 55 66 878
claes1.nils...@sonymobile.com
<mailto:firstname.lastn...@sonymobile.com>
sonymobile.com <http://sonymobile.com/>
Sony logotype_23px height_Email_144dpi
*From:*Nilsson, Claes1
*Sent:* den 1 april 2015 11:22
*To:* public-sysa...@w3.org <mailto:public-sysa...@w3.org>;
public-webapps; Device APIs Working Group
*Cc:* 'Domenic Denicola'; 'slightly...@chromium.org
<mailto:slightly...@chromium.org>'; 'yass...@gmail.com
<mailto:yass...@gmail.com>'
*Subject:* [W3C TCP and UDP Socket API]: Status and home for this
specification
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
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.
Today we can conclude that it has not been possible to standardize
a runtime and security model in SysApps. However, there still
seems to be an interest in the TCP and UDP Socket API, at least
from individuals at Google and Mozilla. For example, there has
been extensive work, supported by Google, to adapt this API to the
Streams API specification, https://streams.spec.whatwg.org/.
To meet the issue that we don’t have a standardized secure “web
system applications” runtime and that the current open web browser
sandbox is not secure enough for this kind of API (but the
security features are evolving through the Web Application
Security Working Group) 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.
If SysApps WG is closed and the scope of W3C is limited to APIs
that could be exposed the “normal browser context” (which is
evolving, once again referring to Web Apps Sec WG) a new home for
this API could be the Device API WG. A Community Group, similar to
what we have for Web Bluetooth and NFC, would also be a possibility.
WDYT?
Lastly, if there is a decision to continue to work on this API I
can remain as main editor. However, I can currently not commit to
more extensive tasks such as implementation and test cases.
Best regards
Claes
*Claes Nilsson*
Master Engineer - Web Research
Advanced Application Lab, Technology
*Sony Mobile Communications*
Tel: +46 70 55 66 878
claes1.nils...@sonymobile.com
<mailto:firstname.lastn...@sonymobile.com>
sonymobile.com <http://sonymobile.com/>
Sony logotype_23px height_Email_144dpi
