Re: Pointer lock spec
On Wed, Apr 1, 2015 at 1:49 AM, Vincent Scheib sch...@google.com wrote: You raised this point in 2011, resulting in my adding this spec section you reference. The relevant bit being: ... a concern of specifying what units mouse movement data are provided in. This specification defines .movementX/Y precisely as the same values that could be recorded when the mouse is not under lock by changes in .screenX/Y. Implementations across multiple user agents and operating systems will easily be able to meet that requirement and provide application developers and users with a consistent experience. Further, users are expected to have already configured the full system of hardware input and operating system options resulting in a comfortable control the system mouse cursor. By specifying .movementX/Y in the same units mouse lock API applications will be instantly usable to all users because they have already settled their preferences. As of yet nobody has provided higher resolution values though. As an application developer I agree the unprocessed data would be nice to have, but I don't see it as essential. The benefits of system calibrated movement are high. Not requiring users to configure every application is good. And, as the Chrome implementation maintainer who has been in conversation with several application developers (Unity, Unreal, PlayCanvas, GooTechnologies, Verold, come to mind easily) this has not been raised yet as an issue. I distinctly remember playing games (and reading articles about) mouse coordinates in pixel-clamped ranges. Particularly when buying my first high resolution mouse this was quite an issue with some games. As now I had a very high precision pointing instrument, but viewpoint changes where pixel clamped. To get better resolution, I had to go to the OS setting, and ratched up mouse sensitivity to the max, then go to the game settings, and counteract that sensitivity setting so it became operable, hence extracting more ticks out of a flawed system. Of course once I closed the game again, I had to undo the OS mouse sensitivity setting again in order to make the desktop usable. It might be less of an issue then back when 1024x786 was the state of the art. But 1920x1080 is less than twice the horizontal/vertical resolution than back then, so I'm pretty sure this is still a significant issue, and pointers haven't gotten any less precise since then (however OSes haven't gotten any smarter with pointers). I'm not certain how to address this in the specification. I agree that poor rendering latency will impact the use of an application drawn cursor or other use, and that some applications and devices may have poor experiences. That said, what should we change in the specification, or what notes would you suggest are added to FAQ on this topic? This is essentially a whole-system integration issue. In order to fix it, the whole stack (drivers, I/O systems, kernels, shells, browsers, hardware) needs to get its act together: - I/O RTT latencies (input - screen) of more than 10ms is not an appropriate state of affairs for the year 2015. The benchmark number would be OS cursors, which are around 30ms. Even native games struggle to get below 60ms, and for browsers it's usually worse. - *One* millisecond on a modern computer (PCIe, sandybridge, ssd drive) runs 6000 floating point operations, 16'000 transfers on the bus, 160'000 cycles, ~40'000 ram load/stores - L1 latency ~0.25ms, ram latency ~0.8ms, SSD random access ~0.1ms So to put that into perspective, the I/O latencies we have today (let's go with ~100ms for browsers) is 1.25x million times bigger than ram latency, 1000x bigger than permanent storage latency. It's about 8x longer than it takes you to ping google across 6 hops. IO latencies in todays systems are insanely high. And the numbers haven't gotten much better in the last 20 years (in fact you could argue they've gotten a lot worse, but that's a topic for another day). So I think if you're writing any specification dealing with I/O. It should contain very strong language addressing latency. It can specify whole system latency requirements as a level of support queries. If a whole system is able to achieve 10ms latencies, the API should be able to indicate that fact (let's say support level gold), if it reaches 60ms, that's say silver, and 60ms that's support level turd. What's simply not sustainable is the frankly insane situation in regards to I/O latencies is gone unmentioned, unfixed and not made transparent. We tried that for the last oh 20 years. It. Doesn't. Work.
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.nils...@sonymobile.com wrote: A webapp could for example request permission to create a TCP connection to a certain host. That does not seem like an acceptable solution. Deferring this to the user puts the user at undue risk as they cannot reason about this question without a detailed understanding of networking. The best path forward here would still be standardizing some kind of public proxy protocol developers could employ: https://annevankesteren.nl/2015/03/public-internet-proxy -- https://annevankesteren.nl/
[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.commailto:firstname.lastn...@sonymobile.com sonymobile.comhttp://sonymobile.com/ [cid:image003.png@01D06C6E.1B5EBBA0]
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.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 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.
[Bug 24475] StorageQuota.supportedTypes should return a frozen Array
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24475 Arthur Barstow art.bars...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||art.bars...@gmail.com Resolution|--- |FIXED --- Comment #4 from Arthur Barstow art.bars...@gmail.com --- It appears Kinuko fixed this on Github via Issue https://github.com/kinu/quota-api/issues/3 and commit https://github.com/kinu/quota-api/issues/3#ref-commit-b1b0c63. Do you agree Kinuko and Domenic? Kinuko, BTW, now that you are using GH for this spec , perhaps this Bugzilla component should be: marked as Historical, the component no longer accept new bugs and Github Issues be used exclusively for this spec. WDYT? If you agree, I'll work with W3C staff to make this happen. -- You are receiving this mail because: You are on the CC list for the bug.
RE: [W3C TCP and UDP Socket API]: Status and home for this specification
See inline. BR Claes Claes Nilsson Master Engineer - Web Research Advanced Application Lab, Technology Sony Mobile Communications Tel: +46 70 55 66 878 claes1.nils...@sonymobile.commailto:firstname.lastn...@sonymobile.com sonymobile.comhttp://sonymobile.com/ [cid:image003.png@01D06C95.57D61840] From: Florian Bösch [mailto:pya...@gmail.com] Sent: den 1 april 2015 12:06 To: Nilsson, Claes1 Cc: public-sysa...@w3.org; public-webapps; Device APIs Working Group; Domenic Denicola; slightly...@chromium.org; yass...@gmail.com Subject: 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.nils...@sonymobile.commailto: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 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) [Claes] Agree but there are still use cases for legacy devices, e-mail and local network service discovery. But it is up to a decision if those use cases motivate a standardized API. 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. [Claes] Please read section 4, http://www.w3.org/2012/sysapps/tcp-udp-sockets/#security-and-privacy-considerations, and my reply to Anne 5 minutes ago.
Re: [W3C TCP and UDP Socket API]: Status and home for this specification
On Wed, Apr 1, 2015 at 3:58 PM, Nilsson, Claes1 claes1.nils...@sonymobile.com wrote: However, work is ongoing in the Web App Sec WG that may provide basis for a security model for this API. Please read section 4, http://www.w3.org/2012/sysapps/tcp-udp-sockets/#security-and-privacy-considerations I don't see anything there that makes TCP or UDP possible. It has # Explicit trust for the requesting webapp based on the security # system of the web runtime this API is implemented in. but no such thing exists (standardized). -- https://annevankesteren.nl/
RE: [W3C TCP and UDP Socket API]: Status and home for this specification
Hi Anne, This is a misunderstanding that probably depends on that I used the word permission, which people associate with user permission. User permissions are absolutely not enough to provide access to this API. However, work is ongoing in the Web App Sec WG that may provide basis for a security model for this API. Please read section 4, http://www.w3.org/2012/sysapps/tcp-udp-sockets/#security-and-privacy-considerations. I am trying to get to a point to see if a TCP and UDP Socket is possible to standardize taking the changed assumption into consideration, i.e. there will be no W3C web system applications. 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 sonymobile.com -Original Message- From: Anne van Kesteren [mailto:ann...@annevk.nl] Sent: den 1 april 2015 11:58 To: Nilsson, Claes1 Cc: public-sysa...@w3.org; public-webapps; Device APIs Working Group; Domenic Denicola; slightly...@chromium.org; yass...@gmail.com Subject: 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.nils...@sonymobile.com wrote: A webapp could for example request permission to create a TCP connection to a certain host. That does not seem like an acceptable solution. Deferring this to the user puts the user at undue risk as they cannot reason about this question without a detailed understanding of networking. The best path forward here would still be standardizing some kind of public proxy protocol developers could employ: https://annevankesteren.nl/2015/03/public-internet-proxy -- https://annevankesteren.nl/
RE: [W3C TCP and UDP Socket API]: Status and home for this specification
This distinction between user permission and general permission is key, I think. For example, I could naively imagine something like the browser auto-granting permission if the requested remoteAddress is equal to the IP address of the origin executing the API. Possibly with a pre-flight request that checks e.g. /.well-known/tcp-udp-permission-port-remotePort on that origin for a header to ensure the server is cooperative. (But I am sure there are security people standing by to tell me how this is very naive...) The async permissions style is flexible enough to allow any such techniques to come in to play. -Original Message- From: Nilsson, Claes1 [mailto:claes1.nils...@sonymobile.com] Sent: Wednesday, April 1, 2015 09:58 To: 'Anne van Kesteren' Cc: public-sysa...@w3.org; public-webapps; Device APIs Working Group; Domenic Denicola; slightly...@chromium.org; yass...@gmail.com Subject: RE: [W3C TCP and UDP Socket API]: Status and home for this specification Hi Anne, This is a misunderstanding that probably depends on that I used the word permission, which people associate with user permission. User permissions are absolutely not enough to provide access to this API. However, work is ongoing in the Web App Sec WG that may provide basis for a security model for this API. Please read section 4, http://www.w3.org/2012/sysapps/tcp-udp-sockets/#security-and-privacy-considerations. I am trying to get to a point to see if a TCP and UDP Socket is possible to standardize taking the changed assumption into consideration, i.e. there will be no W3C web system applications. 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 sonymobile.com -Original Message- From: Anne van Kesteren [mailto:ann...@annevk.nl] Sent: den 1 april 2015 11:58 To: Nilsson, Claes1 Cc: public-sysa...@w3.org; public-webapps; Device APIs Working Group; Domenic Denicola; slightly...@chromium.org; yass...@gmail.com Subject: 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.nils...@sonymobile.com wrote: A webapp could for example request permission to create a TCP connection to a certain host. That does not seem like an acceptable solution. Deferring this to the user puts the user at undue risk as they cannot reason about this question without a detailed understanding of networking. The best path forward here would still be standardizing some kind of public proxy protocol developers could employ: https://annevankesteren.nl/2015/03/public-internet-proxy -- https://annevankesteren.nl/
Re: [W3C TCP and UDP Socket API]: Status and home for this specification
On Wed, Apr 1, 2015 at 4:15 PM, Domenic Denicola d...@domenic.me wrote: For example, I could naively imagine something like the browser auto-granting permission [...] If there is a proposal for a security model that needs to be part of the document. There's no way this will get interoperable without specifying exactly what needs to happen. -- https://annevankesteren.nl/
RE: [W3C TCP and UDP Socket API]: Status and home for this specification
I think it's OK for different browsers to experiment with different non-interoperable conditions under which they fulfill or reject the permissions promise. That's already true for most permissions grants today.
Re: [W3C TCP and UDP Socket API]: Status and home for this specification
On Wed, Apr 1, 2015 at 4:27 PM, Domenic Denicola d...@domenic.me wrote: I think it's OK for different browsers to experiment with different non-interoperable conditions under which they fulfill or reject the permissions promise. That's already true for most permissions grants today. It's true when UX is involved. When UX must not be involved, it's a very different situation. For those cases we do spell out what needs to happen. -- https://annevankesteren.nl/
Re: [W3C TCP and UDP Socket API]: Status and home for this specification
On 2015-04-01 16:11, Anne van Kesteren wrote: On Wed, Apr 1, 2015 at 3:58 PM, Nilsson, Claes1 claes1.nils...@sonymobile.com wrote: However, work is ongoing in the Web App Sec WG that may provide basis for a security model for this API. Please read section 4, http://www.w3.org/2012/sysapps/tcp-udp-sockets/#security-and-privacy-considerations I don't see anything there that makes TCP or UDP possible. It has # Explicit trust for the requesting webapp based on the security # system of the web runtime this API is implemented in. but no such thing exists (standardized). Even if there was a technical standard for the web runtime, the distribution and vetting of secure applications would probably not be standard which is why I continue literally jumping up and down pointing in another direction which is based on COMBINING the Open Web with local, more or less proprietary applications which would do the dirty work (like they already do today). Unfortunately it seems that the browser vendors want to lock down everything leaving Web developers in a very disadvantaged position compared to their App-developing cousins. Regarding permissions involving the user, there are huge limitations in the Open Web: http://webpki.org/papers/permissions.pdf Anders
Re: [W3C TCP and UDP Socket API]: Status and home for this specification
On Wed, Apr 1, 2015 at 4:30 PM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Apr 1, 2015 at 4:27 PM, Domenic Denicola d...@domenic.me wrote: I think it's OK for different browsers to experiment with different non-interoperable conditions under which they fulfill or reject the permissions promise. That's already true for most permissions grants today. It's true when UX is involved. When UX must not be involved, it's a very different situation. For those cases we do spell out what needs to happen. I agree with Anne. What Domenic describes sounds like something similar to CORS. I.e. a network protocol which lets a server indicate that it trusts a given party. Not saying that we can use CORS to solve this, or that we should extend CORS to solve this. My point is that CORS works because it was specified and implemented across browsers. If we'd do something like what Domenic proposes, I think that would be true here too. However, in my experience the use case for the TCPSocket and UDPSocket APIs is to connect to existing hardware and software systems. Like printers or mail servers. Server-side opt-in is generally not possible for them. / Jonas
Re: [W3C TCP and UDP Socket API]: Status and home for this specification
It's a fair point, but without an origin authoritative opt-in it's not
gonna happen no matter what. Imagine say the displeasure of
awesomeEmail2000.com if trough some manner of XSS exploit (say in google
adds) suddenly millions of web-visitors connect to their email server
simultaneously...
On Wed, Apr 1, 2015 at 6:44 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Apr 1, 2015 at 6:37 PM, Florian Bösch pya...@gmail.com wrote:
On Wed, Apr 1, 2015 at 6:02 PM, Jonas Sicking jo...@sicking.cc wrote:
Not saying that we can use CORS to solve this, or that we should
extend CORS to solve this. My point is that CORS works because it was
specified and implemented across browsers. If we'd do something like
what Domenic proposes, I think that would be true here too.
However, in my experience the use case for the TCPSocket and UDPSocket
APIs is to connect to existing hardware and software systems. Like
printers or mail servers. Server-side opt-in is generally not possible
for them.
Isn't the problem that these existing systems can't be changed (let's
say an
IRC server) to support say WebSockets, and thus it'd be convenient to be
able to TCP to it. I think that is something CORS-like could actually
solve.
You could deploy (on the same origin) a webserver that handles the opt-in
for that origin/port/protocol and then the webserver can open a
connection
to it. For example:
var socket = new Socket(); socket.connect('example.com', 194);
-
RAW-SOCKET-OPTIONS HTTP/1.1
port: 194
host: example.com
-
HTTP/1.1 200 OK
Access-Control-Allow-Origin: example.com
- browser opens a TCP connection to example.com 194.
So you don't need to upgrade the existing system for server
authorization.
You just need to deploy a (http compatible) authorative source on the
same
origin that can give a browser the answer it desires.
Again, the use case here is to enable someone to develop, for example,
a browser base mail client which has support for POP/IMAP/SMTP.
It's going to be very hard for that email client to get any
significant user base if their install steps are:
1. Go to awesomeEmail2000.com
2. Contact your mail provider and ask them to install a http server on
their mail server
3. There is no step three :)
/ Jonas
RE: [W3C TCP and UDP Socket API]: Status and home for this specification
From: Boris Zbarsky [mailto:bzbar...@mit.edu] This particular example sets of alarm bells for me because of virtual hosting. Eek! Yeah, OK, I think it's best I refrain from trying to come up with specific examples. Let's forget I said anything... As in, this seems like precisely the sort of thing that one browser might experiment with, another consider an XSS security bug, and then we have content that depends on a particular browser, no? My argument is that it's not materially different from existing permissions APIs. Sometimes the promise is rejected, sometimes it isn't. (Note that either outcome could happen without the user ever seeing a prompt.) The code works in every browser---some just follow the denied code path, and some follow the accepted code path. That's fine: web pages already need to handle that.
Re: [W3C TCP and UDP Socket API]: Status and home for this specification
On Wed, Apr 1, 2015 at 7:03 PM, Domenic Denicola d...@domenic.me wrote: My argument is that it's not materially different from existing permissions APIs. Sometimes the promise is rejected, sometimes it isn't. (Note that either outcome could happen without the user ever seeing a prompt.) The code works in every browser---some just follow the denied code path, and some follow the accepted code path. That's fine: web pages already need to handle that. But they won't. Once web developers figure out the Secret Sauce to make it work in browser X and browser X has enough market share, they'll just add Secret Sauce and require X. And everyone competing with X will have to add support for Secret Sauce, whether they want to or not. -- https://annevankesteren.nl/
Re: [W3C TCP and UDP Socket API]: Status and home for this specification
On Wed, Apr 1, 2015 at 6:37 PM, Florian Bösch pya...@gmail.com wrote:
On Wed, Apr 1, 2015 at 6:02 PM, Jonas Sicking jo...@sicking.cc wrote:
Not saying that we can use CORS to solve this, or that we should
extend CORS to solve this. My point is that CORS works because it was
specified and implemented across browsers. If we'd do something like
what Domenic proposes, I think that would be true here too.
However, in my experience the use case for the TCPSocket and UDPSocket
APIs is to connect to existing hardware and software systems. Like
printers or mail servers. Server-side opt-in is generally not possible
for them.
Isn't the problem that these existing systems can't be changed (let's say an
IRC server) to support say WebSockets, and thus it'd be convenient to be
able to TCP to it. I think that is something CORS-like could actually solve.
You could deploy (on the same origin) a webserver that handles the opt-in
for that origin/port/protocol and then the webserver can open a connection
to it. For example:
var socket = new Socket(); socket.connect('example.com', 194);
-
RAW-SOCKET-OPTIONS HTTP/1.1
port: 194
host: example.com
-
HTTP/1.1 200 OK
Access-Control-Allow-Origin: example.com
- browser opens a TCP connection to example.com 194.
So you don't need to upgrade the existing system for server authorization.
You just need to deploy a (http compatible) authorative source on the same
origin that can give a browser the answer it desires.
Again, the use case here is to enable someone to develop, for example,
a browser base mail client which has support for POP/IMAP/SMTP.
It's going to be very hard for that email client to get any
significant user base if their install steps are:
1. Go to awesomeEmail2000.com
2. Contact your mail provider and ask them to install a http server on
their mail server
3. There is no step three :)
/ Jonas
RE: [W3C TCP and UDP Socket API]: Status and home for this specification
From: Jonas Sicking [mailto:jo...@sicking.cc] I agree with Anne. What Domenic describes sounds like something similar to CORS. I.e. a network protocol which lets a server indicate that it trusts a given party. I think my point would have been stronger without the /.well-known protocol thingy. Removing that: Do you think it's acceptable for browser to experiment with e.g. auto-granting permission if the requested remoteAddress is equal to the IP address of the origin executing the API? Does that seem like current permission API conditions (i.e. not standardized), or more like CORS (standardized)? However, in my experience the use case for the TCPSocket and UDPSocket APIs is to connect to existing hardware and software systems. Like printers or mail servers. Server-side opt-in is generally not possible for them. Right. My thrown-out-there idea was really just meant as an example of a potential experiment browsers could independently run on their own (like they do with other permissions today). It's not a proposal for the ultimate security model for this API.
Re: [W3C TCP and UDP Socket API]: Status and home for this specification
On Wed, Apr 1, 2015 at 6:02 PM, Jonas Sicking jo...@sicking.cc wrote:
Not saying that we can use CORS to solve this, or that we should
extend CORS to solve this. My point is that CORS works because it was
specified and implemented across browsers. If we'd do something like
what Domenic proposes, I think that would be true here too.
However, in my experience the use case for the TCPSocket and UDPSocket
APIs is to connect to existing hardware and software systems. Like
printers or mail servers. Server-side opt-in is generally not possible
for them.
Isn't the problem that these existing systems can't be changed (let's say
an IRC server) to support say WebSockets, and thus it'd be convenient to be
able to TCP to it. I think that is something CORS-like could actually
solve. You could deploy (on the same origin) a webserver that handles the
opt-in for that origin/port/protocol and then the webserver can open a
connection to it. For example:
var socket = new Socket(); socket.connect('example.com', 194);
-
RAW-SOCKET-OPTIONS HTTP/1.1
port: 194
host: example.com
-
HTTP/1.1 200 OK
Access-Control-Allow-Origin: example.com
- browser opens a TCP connection to example.com 194.
So you don't need to upgrade the existing system for server authorization.
You just need to deploy a (http compatible) authorative source on the same
origin that can give a browser the answer it desires.
Re: [W3C TCP and UDP Socket API]: Status and home for this specification
On Wed, Apr 1, 2015 at 7:03 PM, Domenic Denicola d...@domenic.me wrote: From: Boris Zbarsky [mailto:bzbar...@mit.edu] This particular example sets of alarm bells for me because of virtual hosting. Eek! Yeah, OK, I think it's best I refrain from trying to come up with specific examples. Let's forget I said anything... As in, this seems like precisely the sort of thing that one browser might experiment with, another consider an XSS security bug, and then we have content that depends on a particular browser, no? My argument is that it's not materially different from existing permissions APIs. I think it is. In cases like geolocation or notifications, the people writing the spec, and the people implementing the spec, were able to envision a reasonable permissions UI. For the TCP/UDPSocket APIs, no one, to my knowledge, has been able to describe a reasonable UI. Basically the spec contains a big magic happens here section. That's always bad in a spec. For example, it'd be bad if the CSS spec said figure out column sizes would make the table look good. The fact that we're talking about permissions doesn't make magic any more ok. Magic is different from leaving UI details up to the browser. / Jonas
Re: [W3C TCP and UDP Socket API]: Status and home for this specification
On Wed, Apr 1, 2015 at 9:00 PM, Anders Rundgren anders.rundgren@gmail.com wrote: Who would like to get something like that in their face when buying stuff on the web? 14% of users recognize changes in content of a security prompt. An MRI scan shows that at the second security prompt in a session a clear drop in visual processing occurs. The authors of the study suggest that security prompts be made such that they are as annoying and hard to habituate against as possible (Permissionities syndrome on steroids). This messages author suggests that if you do that, it's the fastest way to annoy the heck out of everybody in no time flat and get them to stop using whatever it is you're programming. Vista on steroids.
Re: [W3C TCP and UDP Socket API]: Status and home for this specification
On 2015-04-01 20:47, Jonas Sicking wrote: On Wed, Apr 1, 2015 at 7:03 PM, Domenic Denicola d...@domenic.me wrote: From: Boris Zbarsky [mailto:bzbar...@mit.edu] This particular example sets of alarm bells for me because of virtual hosting. Eek! Yeah, OK, I think it's best I refrain from trying to come up with specific examples. Let's forget I said anything... As in, this seems like precisely the sort of thing that one browser might experiment with, another consider an XSS security bug, and then we have content that depends on a particular browser, no? My argument is that it's not materially different from existing permissions APIs. I think it is. In cases like geolocation or notifications, the people writing the spec, and the people implementing the spec, were able to envision a reasonable permissions UI. For the TCP/UDPSocket APIs, no one, to my knowledge, has been able to describe a reasonable UI. Indeed. It seems that this problem is omnipresent for SysApps. Here a real-world example: http://www.sconnect.com/FAQ/#permissionrequest Who would like to get something like that in their face when buying stuff on the web? Anders Basically the spec contains a big magic happens here section. That's always bad in a spec. For example, it'd be bad if the CSS spec said figure out column sizes would make the table look good. The fact that we're talking about permissions doesn't make magic any more ok. Magic is different from leaving UI details up to the browser. / Jonas
Re: [W3C TCP and UDP Socket API]: Status and home for this specification
On 4/1/15 12:50 PM, Domenic Denicola wrote: Do you think it's acceptable for browser to experiment with e.g. auto-granting permission if the requested remoteAddress is equal to the IP address of the origin executing the API? This particular example sets of alarm bells for me because of virtual hosting. As in, this seems like precisely the sort of thing that one browser might experiment with, another consider an XSS security bug, and then we have content that depends on a particular browser, no? -Boris
Re: [W3C TCP and UDP Socket API]: Status and home for this specification
Oh, I should add one thing. I think that the TCPSocket and UDPSocket APIs are great. There is a growing number of implementations of proprietary platforms which are heavily based on web technologies. The most well known one is Cordova. Platforms like those were the original audience for the TCP/UDPSocket APIs and I think they would work great there. But of course it requires that those platforms are interested in implementing a cross-platform API, even it's its not a web API in the traditional sense. It might also mean that the API isn't well suited for discussion in the WebApps WG. I'll leave that discussion to others. / Jonas On Wed, Apr 1, 2015 at 8:47 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Apr 1, 2015 at 7:03 PM, Domenic Denicola d...@domenic.me wrote: From: Boris Zbarsky [mailto:bzbar...@mit.edu] This particular example sets of alarm bells for me because of virtual hosting. Eek! Yeah, OK, I think it's best I refrain from trying to come up with specific examples. Let's forget I said anything... As in, this seems like precisely the sort of thing that one browser might experiment with, another consider an XSS security bug, and then we have content that depends on a particular browser, no? My argument is that it's not materially different from existing permissions APIs. I think it is. In cases like geolocation or notifications, the people writing the spec, and the people implementing the spec, were able to envision a reasonable permissions UI. For the TCP/UDPSocket APIs, no one, to my knowledge, has been able to describe a reasonable UI. Basically the spec contains a big magic happens here section. That's always bad in a spec. For example, it'd be bad if the CSS spec said figure out column sizes would make the table look good. The fact that we're talking about permissions doesn't make magic any more ok. Magic is different from leaving UI details up to the browser. / Jonas
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]
Minutes IndieUI Teleconference 1 April 2015
http://www.w3.org/2015/04/01-indie-ui-minutes.html
