[squeak-dev] Re: Future of Squeak, and outsider's view

Stephen Pair stephen at pairhome.net
Wed Jul 1 19:06:17 UTC 2009


On Wed, Jul 1, 2009 at 1:59 PM, Eliot Miranda <eliot.miranda at gmail.com>wrote:

>
>
> On Wed, Jul 1, 2009 at 10:12 AM, Stephen Pair <stephen at pairhome.net>wrote:
>
>>
>>
>> On Wed, Jul 1, 2009 at 12:18 PM, Eliot Miranda <eliot.miranda at gmail.com>wrote:
>>
>>>
>>>
>>> On Tue, Jun 30, 2009 at 6:15 PM, Stephen Pair <stephen at pairhome.net>wrote:
>>>
>>>>
>>>>
>>>> On Tue, Jun 30, 2009 at 8:48 PM, Eliot Miranda <eliot.miranda at gmail.com
>>>> > wrote:
>>>>
>>>>> On Tue, Jun 30, 2009 at 1:38 PM, Stephen Pair <stephen at pairhome.net>wrote:
>>>>>
>>>>>>
>>>>>>  I can see a potential need in cases where a body of code is designed
>>>>>> to interface with some already present service (for example, a phone dialer
>>>>>> application designed to use an AddressBook service).  But, in such a system,
>>>>>> you wouldn't want to allow monkey patching anyway out of security concerns
>>>>>> (if you could override the AddressBook interface, your code could
>>>>>> potentially access information that the owner didn't want your code to
>>>>>> access).
>>>>>>
>>>>>
>>>>> But how do you override your own AddressBook?  Bringing a new one into
>>>>> existence is one thing, but modifying your fully-populated one implemented
>>>>> by someone else is another thing altogether.  If the system is so
>>>>> architected then it is presumably trivial to create a new instance, move the
>>>>> data across and replace the old with the new.  But if the system isn't (e.g.
>>>>> for security or ip concerns) then you can't.  But these issues operate at a
>>>>> higher level than the language/module/update level right?  The issues with
>>>>> monkey patching are to do with keeping software maintainable and
>>>>> comprehensible to software authors.  The issues of mutable extensible
>>>>> systems also involve their users, and that's more than I can think about
>>>>> right now :)
>>>>>
>>>>
>>>>
>>>> Overriding your own AddressBook would be a problem of loading in new code and migrating the instances (pretty much like software works today where you load a new version of an application and it has to update your existing database(s)).
>>>>
>>>
>>>
>>> That's a fine scheme.  My point is that unless the system is so architected you can't necessarily do that.
>>>
>>
>> LoL...well, of course...if the problem were already solved, there would be
>> no point in contemplating possible solutions.
>>
>>
>>>   Look at the iPhone for example; there are lots of restrictions on what a user can accomplish and
>>> there is software therein to detect attempts to hack around these
>>> restrictions and break things like software update when you try and update a
>>> hacked phone.  So your model only works in an architecture which supports
>>> it.  Since Newspeak doesn't encompass a complete device architecture it
>>> can't provide an update schema for it.  Expecting a language to address this
>>> is IMO a category error.
>>>
>>
>> Didn't someone once say that the operating system is where you resolve all
>> of the inadequacies of your language (or something to that effect)?  ;)
>>
>>
>>> When one starts talking about for example a Smalltalk system running on
>>> bare hardware (e.g. Squeak NOS) then the system can encompass the entirety.
>>>  So we should first try and evolve Newspeak to NewspeakNOS and ten we can
>>> see how an evolved NewspeakNOS would address these update issues.
>>>
>>
>> I don't think you need to go to such lengths to either show that such a
>> scheme would work, or to get use out of it if it does.  Regarding your
>> iPhone example, it takes the discussion beyond the realm of that which we
>> have control and into the realm of interfacing with legacy systems in which
>> none of these kinds of issues have been considered or addressed.  Take and
>> example of upgrading the AddressBook on the iPhone platform (where it's a
>> third party tool over which you have no control other than to upgrade it)
>> while having it still work with say a custom Dialer app that you wrote.  You
>> are free to upgrade either of them independently so long as they both
>> support a common interface.  If the interface were version controlled, you
>> can deal with this problem in a pretty rational manner for an end user (when
>> you go to the AppStore and try to upgrade the AddressBook app, it could
>> alert you that "this new version of the AddressBook no longer supports
>> version 1 of the AddressBook API and since we see that you have a registered
>> dependency form some Dialer app on version 1.0, we can pretty much guarantee
>> that it's going to break your Dialer app, are you sure you want to do this?"
>>  You could then independently upgrade the Dialer app.
>>
>> To bring this back to monkey patching...no, you cannot monkey patch the
>> AddressBook API, but you can create a new version of some framework (with as
>> many customizations as you desire) for use in your Dialer app while the,
>> while the AddressBook continues to use some other version of that very same
>> framework concurrently.  Of course, Cocoa is not going to support this kind
>> of thing (at least not today), but it doesn't preclude apps in some other
>> language that has Newspeak style modularization from doing this (regardless
>> of whether it's running on bare metal or not).
>>
>> I think I've run out of steam on this topic for now.
>>
>
> Hi Stephen,
>    apologies for apparently being obstructive.  I was just trying to
> properly frame the discussion.  I want to separate linguistic from system
> issues.  Your first question was an excellent one
> and asked if linguistic mechanisms could resolve the issue and I said why I
> thought not.  I didn't realise you were shifting ground to propose solutions
> and thought you were still discussing linguistic mechanisms.  Apologies.
>  Please don't run out of steam because I'm not going with the flow.  I hope
> I get where you're aiming at now.
>
>
> Could you extend your scenario with the potential for malware to attempt to
> patch the AddressBook and suggest ways one can legitimately patch the
> AddressBook and at the same time protect it from unwarranted modification?
>

Well, when you download the malware code, instantiate it and give it a
handle to your AddressBook interface, as long as that interface doesn't let
you do reflective things (like adding new methods) and doesn't let you do
other destructive or undesirable things, then no matter how nefariously
intentioned the malware is, it won't be able to do anything that you didn't
explicitly give it the ability to do by exposing capability.  This is what E
is all about isn't it?  And part of what Newspeak aims to address as well.

To legitimately patch the AddressBook, and do it in safe(ish) manner (I
believe at some level, you have to have trust...after all, you trusted the
original AddressBook code with your data) you would expose access to
completely read (but not write) your address book objects...you would not
expose access to the outside world...this new code would then migrate your
data and setup the new address book code...you would then test out the new
address book, and when, to you satisfaction it is handling you data in a
responsible manner, you would expose any additional capabilities the address
book needs (for example, send a vCard over bluetooth), then you would
redirect your address book interfaces to the new code and data (you would
need some means of forcing active clients off the old AddressBook
implementation and onto the new).

I imagine much of the manual and careful steps above could be fully
automated if you really trust the publisher of the code (so trust networks
might be relevant).  But, the you are still making a high level decision
regarding to what degree you trust a given bit of code.  In both cases, you
are exposing only the capability that you expect is needed and you are
holding back access to facilities that would enable the foreign code to do
something it's not supposed to do.

(btw, you've alluded to some of Newspeak's synchronization plans, I'm not
familiar with those (not sure if they've written extensively about those
plans yet).  So, they might have some good ideas around this stuff that I'm
not bringing to this discussion because I haven't read up on it)

- Stephen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090701/5d9582fd/attachment.htm


More information about the Squeak-dev mailing list