Doesn't JavaScript functionality require support in PPAPI?
How do you plan to support WebCL without support in Pepper?
Den fredagen den 2:e augusti 2013 kl. 00:06:22 UTC+2 skrev Andrey Khalyavin:
The work on OpenCL support haven't even started and there are no plans to start this work. Sorry.
-- Andrey Khalyavin
On Thursday, August 1, 2013 1:42:29 PM UTC-7, Fernando Carvalho wrote:Dear Native client community,I'm very excited about the possibilities that Native Client is giving to Web developers.So I would like to ask if there are chances to add OpenCL support to NaCl.I know that even in the browser, there is no stable WebCL implementation, and this capability may be something that should first be supported, before OpenCL could be imported to NaCl.Thus the question here is also about in what stage GPU general purpose processing is in the browser?Many thanks,--
Fernando
--
You received this message because you are subscribed to the Google Groups "Native-Client-Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to native-client-di...@googlegroups.com.
To post to this group, send email to native-cli...@googlegroups.com.
Visit this group at http://groups.google.com/group/native-client-discuss.
For more options, visit https://groups.google.com/groups/opt_out.
On Fri, Aug 2, 2013 at 5:21 PM, Faldegast <fald...@gmail.com> wrote:
Doesn't JavaScript functionality require support in PPAPI?JavaScript has nothing to with PPAPI, it's directly embedded in renderer. Flash needs PPAPI, though - but even in this case interface can be exposed to Flash and not exposed to NaCl's untrusted code.But for any feature to be available via PPAPI and/or via JavaScript it must be implemented in browser core first. Then and only then JavaScript/PPAPI bindings can be provided - and JavaScript usually receives features before PPAPI.How do you plan to support WebCL without support in Pepper?Who said anything about supporting WebCL any time soon? There are some WebCL experiments floating around (not backed by Google AFAIK), but they were experiments two years ago and they still are just an experiments. When and if they'll become something more we can start talking about PPAPI/NaCl access.
Den fredagen den 2:e augusti 2013 kl. 00:06:22 UTC+2 skrev Andrey Khalyavin:
The work on OpenCL support haven't even started and there are no plans to start this work. Sorry.--
-- Andrey Khalyavin
On Thursday, August 1, 2013 1:42:29 PM UTC-7, Fernando Carvalho wrote:Dear Native client community,I'm very excited about the possibilities that Native Client is giving to Web developers.So I would like to ask if there are chances to add OpenCL support to NaCl.I know that even in the browser, there is no stable WebCL implementation, and this capability may be something that should first be supported, before OpenCL could be imported to NaCl.Thus the question here is also about in what stage GPU general purpose processing is in the browser?Many thanks,--
Fernando
You received this message because you are subscribed to the Google Groups "Native-Client-Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to native-client-discuss+unsub...@googlegroups.com.
Oh, I assumed that Javascript and Flash was sandboxed in order to reach maximum security.
How can a PPAPI plugin become trusted enough to have access to the functionality Flash have?
Could I write a trusted plugin that are still able to sandbox part of itself as untrusted code?
To unsubscribe from this group and stop receiving emails from it, send an email to native-client-di...@googlegroups.com.
On Wed, Aug 7, 2013 at 7:53 PM, Faldegast <fald...@gmail.com> wrote:
Oh, I assumed that Javascript and Flash was sandboxed in order to reach maximum security.They only have outer sandbox. NaCl process has two. Understandable, really: in both cases we have JITs which are not supposed to produce vulnerable code while NaCl process executes user-provided CPU code directly. There were some talks about using NaCl to make renderer and/or Flash more secure, but this will be huge project and even if it'll eventually happen it'll not happen any time soon.
How can a PPAPI plugin become trusted enough to have access to the functionality Flash have?You must convince Chromium (or Chrome if we are talking about plugins like Flash or PDF) developers to ship your plugin as part of default installation. And even then it's not guaranteed.
Could I write a trusted plugin that are still able to sandbox part of itself as untrusted code?
You probably can, but this is not something worth doing, really: you can not distribute said plugin. It must be manually installed and future versions of Chrome can break it without warnings. Thus, practically speaking, trusted plugin is useful step for porting, but not for much more:
Den fredagen den 2:e augusti 2013 kl. 15:37:52 UTC+2 skrev khim:
On Fri, Aug 2, 2013 at 5:21 PM, Faldegast <fald...@gmail.com> wrote:
Doesn't JavaScript functionality require support in PPAPI?JavaScript has nothing to with PPAPI, it's directly embedded in renderer. Flash needs PPAPI, though - but even in this case interface can be exposed to Flash and not exposed to NaCl's untrusted code.But for any feature to be available via PPAPI and/or via JavaScript it must be implemented in browser core first. Then and only then JavaScript/PPAPI bindings can be provided - and JavaScript usually receives features before PPAPI.How do you plan to support WebCL without support in Pepper?
Who said anything about supporting WebCL any time soon? There are some WebCL experiments floating around (not backed by Google AFAIK), but they were experiments two years ago and they still are just an experiments. When and if they'll become something more we can start talking about PPAPI/NaCl access.
Den fredagen den 2:e augusti 2013 kl. 00:06:22 UTC+2 skrev Andrey Khalyavin:
The work on OpenCL support haven't even started and there are no plans to start this work. Sorry.--
-- Andrey Khalyavin
On Thursday, August 1, 2013 1:42:29 PM UTC-7, Fernando Carvalho wrote:Dear Native client community,I'm very excited about the possibilities that Native Client is giving to Web developers.So I would like to ask if there are chances to add OpenCL support to NaCl.I know that even in the browser, there is no stable WebCL implementation, and this capability may be something that should first be supported, before OpenCL could be imported to NaCl.Thus the question here is also about in what stage GPU general purpose processing is in the browser?Many thanks,--
Fernando
You received this message because you are subscribed to the Google Groups "Native-Client-Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to native-client-discuss+unsubscri...@googlegroups.com.
To post to this group, send email to native-cli...@googlegroups.com.
Visit this group at http://groups.google.com/group/native-client-discuss.
For more options, visit https://groups.google.com/groups/opt_out.
On Wednesday, August 7, 2013 8:25:21 PM UTC+2, khim wrote:On Wed, Aug 7, 2013 at 7:53 PM, Faldegast <fald...@gmail.com> wrote:
Oh, I assumed that Javascript and Flash was sandboxed in order to reach maximum security.They only have outer sandbox. NaCl process has two. Understandable, really: in both cases we have JITs which are not supposed to produce vulnerable code while NaCl process executes user-provided CPU code directly. There were some talks about using NaCl to make renderer and/or Flash more secure, but this will be huge project and even if it'll eventually happen it'll not happen any time soon.As I come from a .NET/Java perspective on how to handle these things I assumed that there was one sandbox and that the JavaScript compiler just generated NaCl code like the .NET and Java solutions generate CIL/bytecode.
This to pose a problem for my project because I was planning to rely on NaCl sandboxing entirely and from your information it seams like that's not going to be possible.
How can a PPAPI plugin become trusted enough to have access to the functionality Flash have?You must convince Chromium (or Chrome if we are talking about plugins like Flash or PDF) developers to ship your plugin as part of default installation. And even then it's not guaranteed.We are talking about LightSpark and icedtea-web and similar on Linux which means Chromium package developers have to be convinced.
For my specific needs I can always build my own packages on the suse build servers. So what I'm asking is how do I do this if I am the Chromium developer?
Frankly the current plans to retire NPAPI without having a easy way to make equivalent PPAPI plugins will be a problem, as both LightSpark and icedtea-web are currently NPAPI.
Could I write a trusted plugin that are still able to sandbox part of itself as untrusted code?
You probably can, but this is not something worth doing, really: you can not distribute said plugin. It must be manually installed and future versions of Chrome can break it without warnings. Thus, practically speaking, trusted plugin is useful step for porting, but not for much more:This is no different than what plugins usually have to deal with. Why do you think that all new browser versions are Q&A-tested by both Fedora and Ubuntu for weeks before being pushed into the repositories? Frankly I am beginning to think that it might have been a better idea to base NaCl on existing tech like Mono or OpenJDK which has sandboxing models that are quite mature and can do everything I have asked about.
If I want to extend Java with OpenCL I would make an "Installable extension" which means I would put a JAR in $jre/lib/ext and then Java Applets would be able to access it. As it would be a system library (by being in lib/ext) it would be able to use OpenCL or whatever low-level API:s i desire.
Den fredagen den 2:e augusti 2013 kl. 15:37:52 UTC+2 skrev khim:
On Fri, Aug 2, 2013 at 5:21 PM, Faldegast <fald...@gmail.com> wrote:
Doesn't JavaScript functionality require support in PPAPI?JavaScript has nothing to with PPAPI, it's directly embedded in renderer. Flash needs PPAPI, though - but even in this case interface can be exposed to Flash and not exposed to NaCl's untrusted code.But for any feature to be available via PPAPI and/or via JavaScript it must be implemented in browser core first. Then and only then JavaScript/PPAPI bindings can be provided - and JavaScript usually receives features before PPAPI.How do you plan to support WebCL without support in Pepper?
Who said anything about supporting WebCL any time soon? There are some WebCL experiments floating around (not backed by Google AFAIK), but they were experiments two years ago and they still are just an experiments. When and if they'll become something more we can start talking about PPAPI/NaCl access.
j
To unsubscribe from this group and stop receiving emails from it, send an email to native-client-di...@googlegroups.com.
On Sat, Sep 28, 2013 at 12:21 PM, Faldegast <fald...@gmail.com> wrote:
On Wednesday, August 7, 2013 8:25:21 PM UTC+2, khim wrote:On Wed, Aug 7, 2013 at 7:53 PM, Faldegast <fald...@gmail.com> wrote:
Oh, I assumed that Javascript and Flash was sandboxed in order to reach maximum security.They only have outer sandbox. NaCl process has two. Understandable, really: in both cases we have JITs which are not supposed to produce vulnerable code while NaCl process executes user-provided CPU code directly. There were some talks about using NaCl to make renderer and/or Flash more secure, but this will be huge project and even if it'll eventually happen it'll not happen any time soon.As I come from a .NET/Java perspective on how to handle these things I assumed that there was one sandbox and that the JavaScript compiler just generated NaCl code like the .NET and Java solutions generate CIL/bytecode.There are exist port of V8 to NaCl, you can try to use it if you wish.
This to pose a problem for my project because I was planning to rely on NaCl sandboxing entirely and from your information it seams like that's not going to be possible.It's possible (as I've noted there are discussions about doing exactly that), just hard. It'll be large work if you'll decide to go that route.
How can a PPAPI plugin become trusted enough to have access to the functionality Flash have?You must convince Chromium (or Chrome if we are talking about plugins like Flash or PDF) developers to ship your plugin as part of default installation. And even then it's not guaranteed.We are talking about LightSpark and icedtea-web and similar on Linux which means Chromium package developers have to be convinced.Probably. Then you can do the same thing PPAPI Flash are doing. You can either use NaCl and run it in separate process (but this will be challenge because of synchronization issue), or you can try to do in-process PPAPI plugin (although I'm not sure how well-documented this capability is).
For my specific needs I can always build my own packages on the suse build servers. So what I'm asking is how do I do this if I am the Chromium developer?There are documentation for PPAPI developers, etc:
Frankly the current plans to retire NPAPI without having a easy way to make equivalent PPAPI plugins will be a problem, as both LightSpark and icedtea-web are currently NPAPI.I understand your pain, but that's the whole point: PPAPI was developed because it's hard to implement proper sandboxing and keep the basic NPAPI model intact.
Could I write a trusted plugin that are still able to sandbox part of itself as untrusted code?
You probably can, but this is not something worth doing, really: you can not distribute said plugin. It must be manually installed and future versions of Chrome can break it without warnings. Thus, practically speaking, trusted plugin is useful step for porting, but not for much more:This is no different than what plugins usually have to deal with. Why do you think that all new browser versions are Q&A-tested by both Fedora and Ubuntu for weeks before being pushed into the repositories? Frankly I am beginning to think that it might have been a better idea to base NaCl on existing tech like Mono or OpenJDK which has sandboxing models that are quite mature and can do everything I have asked about.
If I want to extend Java with OpenCL I would make an "Installable extension" which means I would put a JAR in $jre/lib/ext and then Java Applets would be able to access it. As it would be a system library (by being in lib/ext) it would be able to use OpenCL or whatever low-level API:s i desire.