Re: Clarification of CSP sandbox and workers
On Thu, Nov 6, 2014 at 5:10 AM, Deian Stefan de...@cs.stanford.edu wrote: I am implementing CSP for Workers in Firefox, but like to get a clarification on workers and the sandbox flag. Currently, a Worker can inherit or be accompanied by a CSP header. As written, the implications of the sandbox directive on the Worker context is not clear. [Following up on https://github.com/w3c/webappsec/issues/69] Arguably most of the sandbox flags don't make sense for Workers, but the empty directive (i.e., just sandbox) and sandbox allow-same-origin can have reasonable semantics. So, if a Worker inherits the CSP from the owner document (or parent worker in later specs) or is accompanied by a CSP header which has the 'sandbox' directive, should the worker script's origin be set to a unique origin? Or should we just ignore (and appropriately warn about) the sandbox flag for Workers and address the need for sandboxed Workers separately? This would affect what a worker can fetch, what storage it has access to, and which permissions it has (e.g. can it display a notification). Might be an interesting way to run untrusted code. But if we are going to do something like this Ian would have to define how the sandbox directives affect a worker environment. -- https://annevankesteren.nl/
Re: Clarification of CSP sandbox and workers
The CSP spec should just delegate to HTML here. If/when HTML defines sandboxing with regard to Workers, CSP will just start using those hooks. I'd agree, for example, that it does appear that sandboxing a worker into a unique origin could be interesting. It's not clear to me whether any of the other flags would be useful, though. Ian, WDYT? -mike -- Mike West mk...@google.com Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.) On Wed, Nov 12, 2014 at 9:45 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Nov 6, 2014 at 5:10 AM, Deian Stefan de...@cs.stanford.edu wrote: I am implementing CSP for Workers in Firefox, but like to get a clarification on workers and the sandbox flag. Currently, a Worker can inherit or be accompanied by a CSP header. As written, the implications of the sandbox directive on the Worker context is not clear. [Following up on https://github.com/w3c/webappsec/issues/69] Arguably most of the sandbox flags don't make sense for Workers, but the empty directive (i.e., just sandbox) and sandbox allow-same-origin can have reasonable semantics. So, if a Worker inherits the CSP from the owner document (or parent worker in later specs) or is accompanied by a CSP header which has the 'sandbox' directive, should the worker script's origin be set to a unique origin? Or should we just ignore (and appropriately warn about) the sandbox flag for Workers and address the need for sandboxed Workers separately? This would affect what a worker can fetch, what storage it has access to, and which permissions it has (e.g. can it display a notification). Might be an interesting way to run untrusted code. But if we are going to do something like this Ian would have to define how the sandbox directives affect a worker environment. -- https://annevankesteren.nl/
Re: Clarification of CSP sandbox and workers
+1 Mike West mk...@google.com writes: The CSP spec should just delegate to HTML here. If/when HTML defines sandboxing with regard to Workers, CSP will just start using those hooks. Reasonable, the issue also appears outside CSP: if I create a worker in a sandboxed iframe, what should its origin be? (Or should I not be able to create a worker in this case?) I'd agree, for example, that it does appear that sandboxing a worker into a unique origin could be interesting. It's not clear to me whether any of the other flags would be useful, though. Right, none of the other flags really make sense. (Though some of the flags similarly don't make sense when the sandbox directive is applied to a top-level page.) I do think it's reasonable to wait on the more general sandboxed worker idea, since some of the proposals in WebAppSec are thinking about this already. Thanks, Deian
[POSTPONED] Re: IndieUI Teleconference Agenda; 12 November at 22:00Z for 60 minutes
After discussion with Janina, we've had enough regrets on and off list that it seems we won't have quorum for today's IndieUI call. Therefore, we will postpone the call to next week. The next IndieUI call will be: Wednesday, 19 November at the usual time. Michael On 11/11/2014 8:44 PM, Janina Sajka wrote: Cross-posting as before ... What:IndieUI Task Force Teleconference When:Wednesday 12 November 2:00 PMSan Francisco -- U.S. Pacific (Standard) Time (PST: UTC -8) 4:00 PMAustin -- U.S. Central (Standard) Time (CST: UTC -6) 5:00 PMBoston -- U.S. Eastern (Standard) Time (EST: UTC -5) 10:00 PMLondon -- British (Standard) Time(BST: UTC +0) 11:00 PMParis -- Central European Time (CET: UTC +1) 6:00 AMBeijing -- China Standard Time (Thursday, 13 November CST: UTC +8) 7:00 AMTokyo -- Japan Standard Time(Thursday, 13 November JST: UTC +9) Where:W3C Teleconference--See Below * Time of day conversions Please verify the correct time of this meeting in your time zone using the Fixed Time Clock at: http://timeanddate.com/worldclock/fixedtime.html?msg=IndieUI+Teleconferenceiso=20141112T1700p1=43ah=1 ** Preliminary Agenda for IndieUI Task Force Teleconference 12 November 2014 Meeting: IndieUI Task Force Teleconference Chair:Janina_Sajka agenda+ preview agenda with items from two minutes agenda+ Holliday Scheduling; November-January agenda+Checkin with Web Apps' Editing TF [See below] agenda+ Editor's Report agenda+Requirements Use Cases Progress agenda+Testing Conversation; Polyfills agenda+ User Context Issues Actions https://www.w3.org/WAI/IndieUI/track/products/3 agenda+ Events Issues Actions https://www.w3.org/WAI/IndieUI/track/products/2 agenda+ Other Business agenda+Be Done Resource: TPAC Minutes Monday: http://www.w3.org/2014/10/27-indie-ui-minutes.html Tuesday:http://www.w3.org/2014/10/28-indie-ui-minutes.html Resource: Teleconference Minutes http://www.w3.org/2014/10/15-indie-ui-minutes.html Resource: Web Apps Editing TF Editing Explainer:http://w3c.github.io/editing-explainer/ User Intentions: http://w3c.github.io/editing-explainer/commands-explainer.html Resource: For Reference Home Page:http://www.w3.org/WAI/IndieUI/ Email Archive: http://lists.w3.org/Archives/Public/public-indie-ui/ Resource: Teleconference Logistics Dial the Zakim bridge using either SIP or the PSTN. PSTN: +1.617.761.6200 (This is a U.S. number). SIP: za...@voip.w3.org You should be prompted for a pass code, This is 46343# (INDIE#) Alternatively, bypass the Zakim prompts and SIP directly into our teleconference. SIP: 0046...@voip.w3.org Instructions for connecting using SIP: http://www.w3.org/2006/tools/wiki/Zakim-SIP Place for users to contribute additional VoIP tips. http://www.w3.org/2006/tools/wiki/Zakim-SIP-tips IRC: server: irc.w3.org, channel: #indie-ui. During the conference you can manage your participation with Zakim commands as follows: 61# to mute yourself 60# to unMute yourself 41# to raise your hand (enter speaking queue) 40# to lower your hand (exit speaking queue) The system acknowledges these commands with a rapid, three-tone confirmation. Mobile phone users especially should use the mute function if they don't have a mute function in their phone. But the hand-raising function is a good idea for anyone not using IRC. * IRC access An IRC channel will be available. The server is irc.w3.org, The port number is 6665 (Note this is not the normal default) and The channel is #indie-ui. * Some helpful Scribing and Participation Tips http://www.w3.org/WAI/PF/wiki/Teleconference_cheat_sheet For more on the IRC setup and the robots we use for agenda and speaker queuing and for posting the log to the web, see: - For RRSAgent, that captures and posts the log with special attention to action items: http://www.w3.org/2002/03/RRSAgent - For Zakim, the IRC interface to the bridge manager, that will maintain speaker and agenda queues: http://www.w3.org/2001/12/zakim-irc-bot - For a Web gateway to IRC you can use if your network administrators forbid IRC, see: http://www.w3.org/2001/01/cgi-irc - For more on W3C use of IRC see: http://www.w3.org/Project/IRC/
[Bug 25223] IDB exposes GC behavior
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25223 Jonas Sicking jo...@sicking.cc changed: What|Removed |Added Status|NEW |RESOLVED CC||jo...@sicking.cc Resolution|--- |LATER --- Comment #4 from Jonas Sicking jo...@sicking.cc --- I agree that it's unfortunate to expose GC behavior here. But I don't see any alternative solution. The only option I could think of would be to never close databases unless the .close() function is explicitly called. It's not clear that that's web compatible at this point though. So let's not hold up the v1 spec for this at the very least. -- You are receiving this mail because: You are on the CC list for the bug.
[Selection API] Plans regarding multiple ranges?
Hi all. The current draft of the Selection API states: This specification follows non-Gecko engines in restricting selections to at most one range, but the API was still originally designed for selections with arbitrary numbers of ranges. This explains oddities like the coexistence of removeRange() and removeAllRanges(), and a getRangeAt() method that takes an integer argument that must always be zero. If things change and multiple ranges are supported, there may (or may not) be associated accessibility needs to address or techniques to create. If multiple ranges are not supported, then there are clearly not such needs or techniques. So before we (PFWG) give it more thought, do you happen to know what your plans are for multiple ranges? In particular, if some non-Gecko engine added support for multiple ranges, would your API change to reflect that? Or are the corner cases just too unpleasant? Thanks in advance. Take care. --joanie
RE: [Selection API] Plans regarding multiple ranges?
I believe we should design this with multiple Ranges in mind. Otherwise multiple selection requires a lot of work in javascript. Even if we don't actually support multi-selection in V1, we should not block it for a future spec. -Original Message- From: Joanmarie Diggs [mailto:jdi...@igalia.com] Sent: Wednesday, November 12, 2014 12:15 PM To: public-webapps@w3.org Cc: W3C WAI Protocols Formats Subject: [Selection API] Plans regarding multiple ranges? Hi all. The current draft of the Selection API states: This specification follows non-Gecko engines in restricting selections to at most one range, but the API was still originally designed for selections with arbitrary numbers of ranges. This explains oddities like the coexistence of removeRange() and removeAllRanges(), and a getRangeAt() method that takes an integer argument that must always be zero. If things change and multiple ranges are supported, there may (or may not) be associated accessibility needs to address or techniques to create. If multiple ranges are not supported, then there are clearly not such needs or techniques. So before we (PFWG) give it more thought, do you happen to know what your plans are for multiple ranges? In particular, if some non-Gecko engine added support for multiple ranges, would your API change to reflect that? Or are the corner cases just too unpleasant? Thanks in advance. Take care. --joanie
Re: Clarification of CSP sandbox and workers
On Wed, 12 Nov 2014, Mike West wrote: The CSP spec should just delegate to HTML here. If/when HTML defines sandboxing with regard to Workers, CSP will just start using those hooks. I'd agree, for example, that it does appear that sandboxing a worker into a unique origin could be interesting. It's not clear to me whether any of the other flags would be useful, though. Ian, WDYT? Happy to add features if browsers are going to implement them. Just file a bug describing what the feature is. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [POSTPONED] Re: IndieUI Teleconference Agenda; 12 November at 22:00Z for 60 minutes
LOL. Its the first one I've been able to get on for months. Shame is I came back early from something personal for it (my phone was too battery-low to get email so I didn't know it was cancelled). Never mind, see you next week. andy After discussion with Janina, we've had enough regrets on and off list that it seems we won't have quorum for today's IndieUI call. Therefore, we will postpone the call to next week. The next IndieUI call will be: Wednesday, 19 November at the usual time. Michael On 11/11/2014 8:44 PM, Janina Sajka wrote: Cross-posting as before ... What:IndieUI Task Force Teleconference When:Wednesday 12 November 2:00 PMSan Francisco -- U.S. Pacific (Standard) Time (PST: UTC -8) 4:00 PMAustin -- U.S. Central (Standard) Time (CST: UTC -6) 5:00 PMBoston -- U.S. Eastern (Standard) Time (EST: UTC -5) 10:00 PMLondon -- British (Standard) Time(BST: UTC +0) 11:00 PMParis -- Central European Time (CET: UTC +1) 6:00 AMBeijing -- China Standard Time (Thursday, 13 November CST: UTC +8) 7:00 AMTokyo -- Japan Standard Time(Thursday, 13 November JST: UTC +9) Where:W3C Teleconference--See Below * Time of day conversions Please verify the correct time of this meeting in your time zone using the Fixed Time Clock at: http://timeanddate.com/worldclock/fixedtime.html?msg=IndieUI+Teleconferenceiso=20141112T1700p1=43ah=1 ** Preliminary Agenda for IndieUI Task Force Teleconference 12 November 2014 Meeting: IndieUI Task Force Teleconference Chair:Janina_Sajka agenda+ preview agenda with items from two minutes agenda+ Holliday Scheduling; November-January agenda+Checkin with Web Apps' Editing TF [See below] agenda+ Editor's Report agenda+Requirements Use Cases Progress agenda+Testing Conversation; Polyfills agenda+ User Context Issues Actions https://www.w3.org/WAI/IndieUI/track/products/3 agenda+ Events Issues Actions https://www.w3.org/WAI/IndieUI/track/products/2 agenda+ Other Business agenda+Be Done Resource: TPAC Minutes Monday: http://www.w3.org/2014/10/27-indie-ui-minutes.html Tuesday:http://www.w3.org/2014/10/28-indie-ui-minutes.html Resource: Teleconference Minutes http://www.w3.org/2014/10/15-indie-ui-minutes.html Resource: Web Apps Editing TF Editing Explainer:http://w3c.github.io/editing-explainer/ User Intentions: http://w3c.github.io/editing-explainer/commands-explainer.html Resource: For Reference Home Page:http://www.w3.org/WAI/IndieUI/ Email Archive: http://lists.w3.org/Archives/Public/public-indie-ui/ Resource: Teleconference Logistics Dial the Zakim bridge using either SIP or the PSTN. PSTN: +1.617.761.6200 (This is a U.S. number). SIP: za...@voip.w3.org You should be prompted for a pass code, This is 46343# (INDIE#) Alternatively, bypass the Zakim prompts and SIP directly into our teleconference. SIP: 0046...@voip.w3.org Instructions for connecting using SIP: http://www.w3.org/2006/tools/wiki/Zakim-SIP Place for users to contribute additional VoIP tips. http://www.w3.org/2006/tools/wiki/Zakim-SIP-tips IRC: server: irc.w3.org, channel: #indie-ui. During the conference you can manage your participation with Zakim commands as follows: 61# to mute yourself 60# to unMute yourself 41# to raise your hand (enter speaking queue) 40# to lower your hand (exit speaking queue) The system acknowledges these commands with a rapid, three-tone confirmation. Mobile phone users especially should use the mute function if they don't have a mute function in their phone. But the hand-raising function is a good idea for anyone not using IRC. * IRC access An IRC channel will be available. The server is irc.w3.org, The port number is 6665 (Note this is not the normal default) and The channel is #indie-ui. * Some helpful Scribing and Participation Tips http://www.w3.org/WAI/PF/wiki/Teleconference_cheat_sheet For more on the IRC setup and the robots we use for agenda and speaker queuing and for posting the log to the web, see: - For RRSAgent, that captures and posts the log with special attention to action items: http://www.w3.org/2002/03/RRSAgent - For Zakim, the IRC interface to the bridge manager, that will maintain speaker and agenda queues: http://www.w3.org/2001/12/zakim-irc-bot - For a Web gateway to IRC you can use if your network administrators forbid IRC, see: http://www.w3.org/2001/01/cgi-irc - For more on W3C use of IRC see: http://www.w3.org/Project/IRC/ andy andyhe...@axelrod.plus.com -- __ Andy Heath http://axelafa.com
Re: Bringing APIs for experimental hardware/software to the Web
On Wed, Nov 12, 2014 at 12:36 PM, Dimitri Glazkov dglaz...@google.com wrote: Nevertheless, I am optimistic. I would like to have this discussion and hear your ideas. OK. The following ideas are somewhat half-baked so don't judge me too harshly :-). Rapid deployment of experimental APIs in the browser clashes with our existing goals. It takes time to negotiate APIs, to create multiple interoperable implementations, to validate safety, etc. So I conclude we shouldn't bake them into the browser. Instead we could achieve most of our goals by enabling third parties to deploy experimental functionality in browser-independent, device-independent packages that can be used by --- and if necessary shipped alongside --- Web applications. To the extent we can do that, we make an end-run around the standardization problem. For software, this means we need a browser-based execution environment that can run the code that implements these APIs. I think for C/C++ code, we're nearly there already. For GPU code the situation is murkier and we need to solve it (but we already need to). Hardware is more challenging. I think here it makes sense to have low-level Web APIs for I/O, e.g. USB. So, when someone produces a sensor/actuator USB gadget with accompanying software, we should be able to compile the software for Web use, wrap an API around it that Web apps can use, and host it in any browser. This hits most of our goals: as long as the package remains available, there's compatibility; it's device-independent apart from the dependency on the specific gadget; and it works across browsers (though there's only one implementation of that specific component). Safety is a big concern with low-level hardware access. An obvious path would be to require some kind of trust decision for apps depending (indirectly) on privileged hardware access, but maybe there's a better way. For example, when you attach a USB device you're implicitly trusting the vendor already. What if the browser could extract a vendor domain name from the device (e.g. via a trusted registry) and granted I/O access to that device for packages loaded from that domain? A package could claim it provides a sanitized API to apps, freeing those apps from the trust decision requirement. When, inevitably, something goes wrong, either the package is patched or the browser is updated to stop trusting the package. Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo.
