Re: [W3C TCP and UDP Socket API]: Status and home for this specification
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. Jeffrey On Thu, Apr 2, 2015 at 2:46 AM, Nilsson, Claes1 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 TrustPermission CG. SoMC has also experimented with “Trusted Hosted Apps”, https://lists.w3.org/Archives/Public/public-sysapps/2014Sep/att-/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 2nd 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 firstname.lastn...@sonymobile.com sonymobile.com [image: Sony logotype_23px height_Email_144dpi] *From:* Nilsson, Claes1 *Sent:* den 1 april 2015 11:22 *To:* 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
Re: [W3C TCP and UDP Socket API]: Status and home for this specification
Hi all. You've mistakenly cc'ed my father on this thread. Here's my address. On Wed, Apr 1, 2015 at 2:22 AM, Nilsson, Claes1 claes1.nils...@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 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 firstname.lastn...@sonymobile.com sonymobile.com [image: Sony logotype_23px height_Email_144dpi]
Re: Proposal for a Permissions API
The Permissions API moved to the WebAppSec WG, and there's an open
call for comments on publishing its FPWD:
https://lists.w3.org/Archives/Public/public-webappsec/2015Mar/0131.html.
It would probably make more sense to discuss in that group.
On Sat, Mar 21, 2015 at 2:47 PM, Florian Bösch pya...@gmail.com wrote:
Time to revise this topic. Two data points:
1) Particularly with pointerlock (but also with other permission prompts
that sneak up on the user) I often get the complaint from users along the
lines of I tried your stuff, but it didn't work. or I tried your stuff,
but it asked me to do X, I don't think it works.
2) MRI scans show that user attention dramatically drops when presented with
a security prompt:
http://arstechnica.com/security/2015/03/mris-show-our-brains-shutting-down-when-we-see-security-prompts/
Permission/Security prompts are bad UX. Particularly the kind you need to
prompt the user with along the way. And within that, even worse are the ones
that pop up again and again (like the fullscreen popup).
On Wed, Oct 1, 2014 at 7:34 PM, Jeffrey Yasskin jyass...@google.com wrote:
On Wed, Sep 3, 2014 at 3:29 AM, Mounir Lamouri mou...@lamouri.fr wrote:
On Wed, 3 Sep 2014, at 04:41, Jonas Sicking wrote:
I'm generally supportive of this direction.
I'm not sure that that the PermissionStatus thing is needed. For
example in order to support bluetooth is might be better to make the
call look like:
permissions.has(bluetooth, fitbit).then(...);
That's more Permission than PermissionStatus, right?
What you proposed here would probably be something like that in WebIDL:
Promise has(PermissionName name, any options);
But really, we could make that option bag be a dictionary because it
gives good context about what you are passing like what does fitbit
means here? Is that a black listed device or a white listed one? The one
you want to target?
I agree that it might be unusual to have a required name than might
often be used alone but it makes the API way more javascript-y and self
explanatory. IMO, this call is nicer to read than the one you wrote
above:
permissions.has({ name: 'bluetooth', devices: 'fitbit' });
because I understand what the call is trying to do. In addition, as you
pointed, it gives a lot of flexibility.
Belatedly, I'd like to suggest a slightly different model. Instead of
trying to stuff arbitrary queries into the permissions.has() call,
maybe expose the current permissions as data, and let the application
inspect them using custom code. This is likely to work better for
Bluetooth, since we're planning to have pages request devices by the
Services they expose, not their deviceIds, and a page may want to
check for either an available device exposing some services, or that a
device they've already opened hasn't been revoked.
Getting permission revocation to update a UI correctly is also an
interesting problem. You could expose an event on permission change,
but given that templating frameworks are moving toward
Object.observe() to update themselves in response to model object
changes, that would require developers to write extra code to
propagate the permission changes into their models.
So what if navigator.permissions just _was_ a suitable model object?
Make it, say, a Map from permission-name to an object defined by the
permission's standard, and extend Map to expose enough synthetic
change records that Object.observe(a_map) is useful.
Jeffrey
Re: Proposal for a Permissions API
On Wed, Sep 3, 2014 at 3:29 AM, Mounir Lamouri mou...@lamouri.fr wrote:
On Wed, 3 Sep 2014, at 04:41, Jonas Sicking wrote:
I'm generally supportive of this direction.
I'm not sure that that the PermissionStatus thing is needed. For
example in order to support bluetooth is might be better to make the
call look like:
permissions.has(bluetooth, fitbit).then(...);
That's more Permission than PermissionStatus, right?
What you proposed here would probably be something like that in WebIDL:
Promise has(PermissionName name, any options);
But really, we could make that option bag be a dictionary because it
gives good context about what you are passing like what does fitbit
means here? Is that a black listed device or a white listed one? The one
you want to target?
I agree that it might be unusual to have a required name than might
often be used alone but it makes the API way more javascript-y and self
explanatory. IMO, this call is nicer to read than the one you wrote
above:
permissions.has({ name: 'bluetooth', devices: 'fitbit' });
because I understand what the call is trying to do. In addition, as you
pointed, it gives a lot of flexibility.
Belatedly, I'd like to suggest a slightly different model. Instead of
trying to stuff arbitrary queries into the permissions.has() call,
maybe expose the current permissions as data, and let the application
inspect them using custom code. This is likely to work better for
Bluetooth, since we're planning to have pages request devices by the
Services they expose, not their deviceIds, and a page may want to
check for either an available device exposing some services, or that a
device they've already opened hasn't been revoked.
Getting permission revocation to update a UI correctly is also an
interesting problem. You could expose an event on permission change,
but given that templating frameworks are moving toward
Object.observe() to update themselves in response to model object
changes, that would require developers to write extra code to
propagate the permission changes into their models.
So what if navigator.permissions just _was_ a suitable model object?
Make it, say, a Map from permission-name to an object defined by the
permission's standard, and extend Map to expose enough synthetic
change records that Object.observe(a_map) is useful.
Jeffrey
[push] Consider renaming push notification to push message in the Push API spec
The term push notification in https://dvcs.w3.org/hg/push/raw-file/tip/index.html#dfn-push-notification seems to confuse people into thinking that the user will be notified/bothered when such a message arrives. This is reinforced by the fact that iOS uses push notification for exactly that: a way to notify the user based on a message from a server. See https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/WhatAreRemoteNotif.html. Since the spec already uses the name PushMessage for the thing delivered by a push notification (https://dvcs.w3.org/hg/push/raw-file/tip/index.html#pushmessage-interface), it seems like push message would be a good replacement for the current ambiguous name. Thanks, Jeffrey Yasskin P.S. I'm not subscribed to public-webapps@, so please cc me if you want me to reply.
