Re: [Sugar-devel] [GSoC] progress report
2009/6/5 Tomeu Vizoso to...@sugarlabs.org: On Thu, Jun 4, 2009 at 22:42, Lucian Branesculucian.brane...@gmail.com wrote: 2009/6/4 Tomeu Vizoso to...@sugarlabs.org: On Wed, Jun 3, 2009 at 22:00, Lucian Branescu lucian.brane...@gmail.com wrote: Since I missed the meeting, here goes. I've had a really hectic past few days, with 2 exams, just getting my laptop back and constantly fighting my Uni network restrictions. But it's better now, finished with exams and I figured out how to trick the proxies. I played around with a template Site Specific Browser based on Browse, almost identical up to now. I think I have SSB generation mostly figured out, I need to start implementing it. I will probably have to either change the existing bookmark mechanism or add a new one, because bookmarks (specifically bookmarklets) should be part of data, not state. I also tried Tomeu's technique for getting Gears to work, but that xulrunner bug prevents any permissions being granted. My initial plan was to test Gears with GMail, but it's not quite possible right now. I'll look into it, but I'd rather not have to build xulrunner. I think we can workaround the dialog sizing issue in hulahop, ping me in IRC and we can see what we can do. Sizing isn't really an issue. The permission dialog appears and is the size I would expect, but there's nothing in it. That sounds like a problem with the gears installation (cannot find the chrome). Once you solve that, you will find that the user cannot grant privileges to the site because the dialog is too small. Oh. Also, now I'm more inclined to do the dbus functionality through pyxpcom, mostly because of security issues. In my experience with Flash activities using Gnash, rather than giving access to the full DataStore API it's much more practical to provide some very simple state-saving functionality at first. If the python side can tell the JS side to load a buffer of data, and can ask it to hand a buffer to save in the DS, we can make 90% of activities work with very little effort. We can always make available later the full API or even generic DBus access. Saving state is not really an issue. At least current web apps are built so that they do not lose any data if they suddenly die and some of them also resume from where the left off. For most, it would be enough to save the URL. Well, I was talking about saving state to the journal. Ideally, it would be better to serialise the webview, if possible. What do you mean by that? I had this wild idea that I should be able to pickle the WebView and store that. However, since I decided to use Browse as much as possible, I realised that Browse already does all the integration with the Journal, except for extensions (like Gears). So Browse should probably be fixed to store the extension profiles as part of state, not data, but I'm not sure if that is correct behaviour. Thanks, Tomeu Regards, Tomeu This http://sandbox.movial.com/wiki/index.php/Browser_DBus_Bridge#Gecko_version_notes would provide dbus accessibility directly to javascript and I'd need to handle security around that. Since my dbus needs are limited, I prefer to instead do everything python-side and inject javascript objects that do simple things (notifications, sounds, etc.). Of course, dbus is still a secondary objective. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [GSoC] progress report
On Fri, Jun 5, 2009 at 16:01, Lucian Branesculucian.brane...@gmail.com wrote: 2009/6/5 Tomeu Vizoso to...@sugarlabs.org: On Thu, Jun 4, 2009 at 22:42, Lucian Branesculucian.brane...@gmail.com wrote: 2009/6/4 Tomeu Vizoso to...@sugarlabs.org: On Wed, Jun 3, 2009 at 22:00, Lucian Branescu lucian.brane...@gmail.com wrote: Since I missed the meeting, here goes. I've had a really hectic past few days, with 2 exams, just getting my laptop back and constantly fighting my Uni network restrictions. But it's better now, finished with exams and I figured out how to trick the proxies. I played around with a template Site Specific Browser based on Browse, almost identical up to now. I think I have SSB generation mostly figured out, I need to start implementing it. I will probably have to either change the existing bookmark mechanism or add a new one, because bookmarks (specifically bookmarklets) should be part of data, not state. I also tried Tomeu's technique for getting Gears to work, but that xulrunner bug prevents any permissions being granted. My initial plan was to test Gears with GMail, but it's not quite possible right now. I'll look into it, but I'd rather not have to build xulrunner. I think we can workaround the dialog sizing issue in hulahop, ping me in IRC and we can see what we can do. Sizing isn't really an issue. The permission dialog appears and is the size I would expect, but there's nothing in it. That sounds like a problem with the gears installation (cannot find the chrome). Once you solve that, you will find that the user cannot grant privileges to the site because the dialog is too small. Oh. Also, now I'm more inclined to do the dbus functionality through pyxpcom, mostly because of security issues. In my experience with Flash activities using Gnash, rather than giving access to the full DataStore API it's much more practical to provide some very simple state-saving functionality at first. If the python side can tell the JS side to load a buffer of data, and can ask it to hand a buffer to save in the DS, we can make 90% of activities work with very little effort. We can always make available later the full API or even generic DBus access. Saving state is not really an issue. At least current web apps are built so that they do not lose any data if they suddenly die and some of them also resume from where the left off. For most, it would be enough to save the URL. Well, I was talking about saving state to the journal. Ideally, it would be better to serialise the webview, if possible. What do you mean by that? I had this wild idea that I should be able to pickle the WebView and store that. I'm not sure if that would work, my guess is that debugging that would be quite hard. Keep also in mind that there are XPCOM and GObject instances as part of WebView's state, so pickling all that would be a problem. However, since I decided to use Browse as much as possible, I realised that Browse already does all the integration with the Journal, except for extensions (like Gears). So Browse should probably be fixed to store the extension profiles as part of state, not data, but I'm not sure if that is correct behaviour. What do you mean by extension profiles? And about state vs. data? When I talk about the journal, I use to refer to all the stuff that the activity stores in the journal as the activity state. Metadata would be the structured part of the state and data would be a blob containing the rest of the state. Regards, Tomeu Thanks, Tomeu Regards, Tomeu This http://sandbox.movial.com/wiki/index.php/Browser_DBus_Bridge#Gecko_version_notes would provide dbus accessibility directly to javascript and I'd need to handle security around that. Since my dbus needs are limited, I prefer to instead do everything python-side and inject javascript objects that do simple things (notifications, sounds, etc.). Of course, dbus is still a secondary objective. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [GSoC] progress report
On Wed, Jun 03, 2009 at 05:31:03PM -0400, Benjamin M. Schwartz wrote: I am not knowledgeable about the present state of D-Bus isolation in Rainbow, but if it is insufficient it should be fixed in Rainbow, not in the browser. The bigger problem is that there's no (working) rainbow support at all in Sugar 0.84 and currently nobody is working on it for 0.86 (I might do it, but the version stuff goes first). CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [GSoC] progress report
2009/6/4 Sascha Silbe sascha-ml-ui-sugar-de...@silbe.org On Wed, Jun 03, 2009 at 05:31:03PM -0400, Benjamin M. Schwartz wrote: I am not knowledgeable about the present state of D-Bus isolation in Rainbow, but if it is insufficient it should be fixed in Rainbow, not in the browser. The bigger problem is that there's no (working) rainbow support at all in Sugar 0.84 and currently nobody is working on it for 0.86 (I might do it, but the version stuff goes first). This is a big problem. But pushing security concerns down to the activity level clearly is no solution; it is multiplying the work two different times, once for doing it in the wrong place and again for doing it many times. So I'd agree, webify should not worry about DBus security. Jameson ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [GSoC] progress report
On Wed, Jun 3, 2009 at 22:00, Lucian Branescu lucian.brane...@gmail.com wrote: Since I missed the meeting, here goes. I've had a really hectic past few days, with 2 exams, just getting my laptop back and constantly fighting my Uni network restrictions. But it's better now, finished with exams and I figured out how to trick the proxies. I played around with a template Site Specific Browser based on Browse, almost identical up to now. I think I have SSB generation mostly figured out, I need to start implementing it. I will probably have to either change the existing bookmark mechanism or add a new one, because bookmarks (specifically bookmarklets) should be part of data, not state. I also tried Tomeu's technique for getting Gears to work, but that xulrunner bug prevents any permissions being granted. My initial plan was to test Gears with GMail, but it's not quite possible right now. I'll look into it, but I'd rather not have to build xulrunner. I think we can workaround the dialog sizing issue in hulahop, ping me in IRC and we can see what we can do. Also, now I'm more inclined to do the dbus functionality through pyxpcom, mostly because of security issues. In my experience with Flash activities using Gnash, rather than giving access to the full DataStore API it's much more practical to provide some very simple state-saving functionality at first. If the python side can tell the JS side to load a buffer of data, and can ask it to hand a buffer to save in the DS, we can make 90% of activities work with very little effort. We can always make available later the full API or even generic DBus access. Regards, Tomeu This http://sandbox.movial.com/wiki/index.php/Browser_DBus_Bridge#Gecko_version_notes would provide dbus accessibility directly to javascript and I'd need to handle security around that. Since my dbus needs are limited, I prefer to instead do everything python-side and inject javascript objects that do simple things (notifications, sounds, etc.). Of course, dbus is still a secondary objective. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [GSoC] progress report
I've tried the javascript-dbus bridge and it works nicely in firefox and epiphany-gecko. It triggers a security dialog, so I'll stop worrying about random scripts on the internet making exploits targeting Sugar. However, the bridge doesn't work in Browse. The logs don't say anything relevant. 2009/6/4 Lucian Branescu lucian.brane...@gmail.com: 2009/6/4 Tomeu Vizoso to...@sugarlabs.org: On Wed, Jun 3, 2009 at 22:00, Lucian Branescu lucian.brane...@gmail.com wrote: Since I missed the meeting, here goes. I've had a really hectic past few days, with 2 exams, just getting my laptop back and constantly fighting my Uni network restrictions. But it's better now, finished with exams and I figured out how to trick the proxies. I played around with a template Site Specific Browser based on Browse, almost identical up to now. I think I have SSB generation mostly figured out, I need to start implementing it. I will probably have to either change the existing bookmark mechanism or add a new one, because bookmarks (specifically bookmarklets) should be part of data, not state. I also tried Tomeu's technique for getting Gears to work, but that xulrunner bug prevents any permissions being granted. My initial plan was to test Gears with GMail, but it's not quite possible right now. I'll look into it, but I'd rather not have to build xulrunner. I think we can workaround the dialog sizing issue in hulahop, ping me in IRC and we can see what we can do. Sizing isn't really an issue. The permission dialog appears and is the size I would expect, but there's nothing in it. Also, now I'm more inclined to do the dbus functionality through pyxpcom, mostly because of security issues. In my experience with Flash activities using Gnash, rather than giving access to the full DataStore API it's much more practical to provide some very simple state-saving functionality at first. If the python side can tell the JS side to load a buffer of data, and can ask it to hand a buffer to save in the DS, we can make 90% of activities work with very little effort. We can always make available later the full API or even generic DBus access. Saving state is not really an issue. At least current web apps are built so that they do not lose any data if they suddenly die and some of them also resume from where the left off. For most, it would be enough to save the URL. Ideally, it would be better to serialise the webview, if possible. Regards, Tomeu This http://sandbox.movial.com/wiki/index.php/Browser_DBus_Bridge#Gecko_version_notes would provide dbus accessibility directly to javascript and I'd need to handle security around that. Since my dbus needs are limited, I prefer to instead do everything python-side and inject javascript objects that do simple things (notifications, sounds, etc.). Of course, dbus is still a secondary objective. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [GSoC] progress report
Lucian Branescu wrote: Also, now I'm more inclined to do the dbus functionality through pyxpcom, mostly because of security issues. This http://sandbox.movial.com/wiki/index.php/Browser_DBus_Bridge#Gecko_version_notes would provide dbus accessibility directly to javascript and I'd need to handle security around that. Personally, I recommend that you not worry about this. Sugar is designed with the assumption that Activities can be arbitrary untrusted code, and so they are run in jails that prevent them from taking actions not explicitly permitted by the user. This includes various kinds of D-Bus actions. I am not knowledgeable about the present state of D-Bus isolation in Rainbow, but if it is insufficient it should be fixed in Rainbow, not in the browser. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
