[Sugar-devel] Advice request: XO sound recording

[James Simmons]

Walter,

I agree that we can't support .82 forever, but at the time I wrote my
Activities (and the book) it was a big issue since that's what most
deployments were using.  I haven't looked at Object Chooser since
then.  It may well have improved, but I would guess that it is still
slow and ugly and not an adequate replacement for the kinds of things
I'm doing in View Slides and Sugar Commander, or what the Library
Activity was going to be doing.

I fully understand the need for limiting Journal access while doing
networking, but I would think that we could implement that in such a
way that Activities could still have Fun With The Journal the rest of
the time.

I just got a proof copy of "Make Your Own Sugar Activities!" which
finally has text the right size, good page breaks, and a terrific hand
drawn cover illustration.  It's finally good enough to sell on Lulu.
I know I'll have to revise it some day, but I'm hoping that day is a
few months off at least.

James Simmons


On Mon, Oct 4, 2010 at 9:44 AM, Walter Bender <walter.bender at gmail.com> wrote:
> On Mon, Oct 4, 2010 at 10:15 AM, James Simmons <nicestep at gmail.com> wrote:
>> Sascha,
>>
>> I fully support the way Activities are not allowed write access to
>> anything but the datastore and their own directories.  I even support
>> not being able to list out Journal entries at the same time you do
>> network access.  If we get to the point where an Activity cannot list
>> out Journal entries (other than using the Object Chooser) at any time
>> then I've got a beef.
>>
>> I have tried the Object Chooser.  In Sugar .82 it had some serious
>> bugs, could not list out only those entries you wanted to look at, and
>> was slow and ugly.  A big part of my book is explaining how to write
>> Activities that will run on .82 as well as later versions of Sugar,
>> and there was no way to make the Object Chooser a part of that
>> strategy.  As a result I did not discuss it in the book, but did
>> describe how to write your own object choosing code.  What I described
>> works well and answers a legitimate need.  In my opinion, nothing I am
>> recommending would allow anyone to make a malicious Activity (assuming
>> that listing entries in the data store was blocked during network
>> access).
>
> Whereas all of the major Sugar deployments (.uy, .pe, .py. etc.) are
> transitioning to 0.84 or 0.88, there is less of a concern in my mind
> to make activities run "on .82 as well as later versions." That said,
> I would want activities to run on 0.82, but perhaps in a lesser form
> than on more recent Sugar releases.
>
> -walter
>
>> James Simmons
>>
>>> Date: Mon, 04 Oct 2010 10:11:00 +0200
>>> From: Sascha Silbe <sascha-ml-reply-to-2010-3 at silbe.org>
>>> Subject: Re: [Sugar-devel] Advice request: XO sound recording
>>> To: sugar-devel <sugar-devel at lists.sugarlabs.org>
>>> Message-ID: <1286177910-sup-2358 at twin.sascha.silbe.org>
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>> Excerpts from James Simmons's message of Mon Oct 04 01:28:03 +0200 2010:
>>>
>>>> There is a chapter called "Fun With The Journal" which has examples of
>>>> listing out Journal entries.  What you need to do is figure out what
>>>> the MIME type of the Ogg entries in the Journal are and write code to
>>>> list them.  Then you can put the entries in a GTK table and select
>>>> them from there.
>>>
>>> Just a word of caution: While access to the data store is unrestricted
>>> because nobody got around to implement the access controls, this won't
>>> be the case forever. In general you should only assume that you have
>>> access to the entry belonging to the currently running activity session
>>> (P_DOCUMENT [1,2]). The Object Chooser is a powerbox [3] that will grant
>>> your activity access to an additional entry selected by the user (and
>>> only that one entry, nothing else).
>>>
>>> While activities can request additional permissions [4] only certain
>>> combinations will be granted automatically. In particular listing data
>>> store entries is mutually exclusive with network access [5]:
>>>
>>>>> We solve this by allowing programs to request read-only permissions for
>>>>> one type of document (e.g. image, audio, text, e-mail) at installation
>>>>> time, but making that permission (#P_DOCUMENT_RO) mutually exclusive
>>>>> with asking for any network access at all. A photo viewing program, in
>>>>> other words, normally has no business connecting to the Internet.
>>>
>>> While the user can explicitly grant activities additional permissions,
>>> we should be careful not to train them to do this for a significant
>>> number of activities as it would make the system pointless and vulnerable
>>> to the attacks we're trying to guard the users against (e.g. [6]).
>>>
>>> Sascha
>>>
>>> [1] http://wiki.laptop.org/go/OLPC_Bitfrost#P_DOCUMENT:_file_store_service
>>> [2] http://dev.laptop.org/git/security/tree/bitfrost.txt#n874
>>> [3] http://en.wikipedia.org/wiki/File_dialog#Powerbox
>>> [4] http://wiki.sugarlabs.org/go/Development_Team/Low-level_Activity_API#Permissions_Declarations
>>> [5] http://wiki.laptop.org/go/OLPC_Bitfrost#P_DOCUMENT_RO
>>> [6] http://wiki.laptop.org/go/OLPC_Bitfrost#Compromising_privacy_2
>>> --
>>> http://sascha.silbe.org/
>>> http://www.infra-silbe.de/
>>> -------------- next part --------------
>>> A non-text attachment was scrubbed...
>>> Name: signature.asc
>>> Type: application/pgp-signature
>>> Size: 490 bytes
>>> Desc: not available
>>> Url : http://lists.sugarlabs.org/archive/sugar-devel/attachments/20101004/466091fe/attachment-0001.pgp
>> _______________________________________________
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>
>
>
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
>