I'm assuming that the data would only go one way. In that case, the permission would be, an app without P_NETWORK would not be able to request opening of apps with P_NETWORK. No new permissions needed, just careful attention to the ones we have.
On Fri, Apr 11, 2008 at 7:53 AM, Eben Eliason <[EMAIL PROTECTED]> wrote: > On Fri, Apr 11, 2008 at 9:45 AM, Benjamin M. Schwartz > <[EMAIL PROTECTED]> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > > > > > Eben Eliason wrote: > > |> > 3. Need easy way to group links to activities, such as in a > lesson > > |> > plan. > > |> > > > |> > Use Case: > > |> > Kid reads through geometry tutorial and clicks on first activity > > which > > |> > opens up Dr. Geo. After finishing w/ Dr. Geo he does some more > > reading > > |> > in the tutorial and then clicks on a second link which opens up > a > > |> > related GCompris activity. > > |> > > > |> > We need a way to launch different activities from within a > graphical > > |> > context, e.g. a tutorial. HTML is the most practical way to do > this. > > I > > |> > know there are issues w/ Rainbow and activities calling other > > activities > > |> > but this is very important to the learning process. > > |> > > |> Interesting, would like to know what Eben thinks about it. > > | > > | This is an interesting idea, and one I don't really have a direct > > | solution for, at present. One potential option, and perhaps the most > > | interesting, is also a fair bit of work. It entails adding a > bitfrost > > | permission (does it already have one?) akin to P_EXEC or something > > | similar, which allows an activity to make a request to the shell to > > | launch another activity, passing it a URI (could be a file, could be > a > > | URL, etc) and having it ask the user to confirm the action. With > such > > | an approach, any activity that wanted could embed links to other > > | activities, or to web sites. If we build this into the shell, and > > | offer it as a permission, I don't believe that it will pose any > > | security problems*. > > | > > | * I could be very wrong, though. > > > > IMHO, the best solution is the one already used by Browse in the case > of > > PDF downloads. The files are downloaded, and then the Journal is asked > to > > present the user with information about the item and the option to > launch > > it. This is akin to how most modern browsers handle media files that > will > > launch outside the browser. They present a window saying "You are > > downloading a file of type "PDF". Would you like to open it using > > "Document Viewer"?" They also offer a drop-down list of alternative > > applications. > > > > Letting the Journal handle all open requests improves usability, in my > > view, by ensuring that the user can always postpone an opening action, > or > > choose an alternative handler. I also think it improves security, by > > avoiding a number of potential DoS, privilege escalation, and > information > > disclosure (e.g. #6837, #6838) problems. > > In case I was unclear, that is just the kind of thing I was > suggesting. I think that the shell should expose a "launcher" > service, which will do just the kinds of things you mention here. The > UI would all be handled by the shell, not the activity making the > request. Perhaps if it's always done this way through the shell > service, we don't even need a permission. > > - Eben > _______________________________________________ > Sugar mailing list > [email protected] > http://lists.laptop.org/listinfo/sugar >
_______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
