On 2015-04-02 11:46, Nilsson, Claes1 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.
That's the #1 problem; this is not recognized as high-priority mission.
In fact, the only activity I'm aware of are various efforts locking down browsers even
more, leaning web developers in a very disadvantaged position position compared to their
"App"-developing cousins.
Anyway, SysApps at least terminated "in style" :-)
WebCrypto.Next with hardware security on the menu OTOH did not :-(
https://lists.w3.org/Archives/Public/public-web-security/2015Feb/0034.html
Regarding permissions, I remain unconvinced that they address this issue in a reasonable way. An Android
"App" may ask for access to the Internet as well as to "Contacts". IMO, this has limited
value for the end-user since the App may send your contacts to a server somewhere which probably isn't what
you expected or wanted. Obviously we need a model where the code is "vetted" for
DoingTheRightThing(tm).
Anders
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'; '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
