As I've mentioned a few times on this list and in the long ago past, I think
that the way to go is to make a hardware software system that assumes no piece
of code is completely benign. This was the strategy of the B5000 long ago, and
of several later OS designs (and of the Internet itself). Many of these ideas
were heavily influenced by the work of Butler Lampson over the years.
The issue becomes: you can get perfect safety by perfect confinement, but how
do you still get things to work together and make progress? For example, the
Internet TCP/IP mechanism only gets packets from one place to another -- this
mechanism cannot command a receiver computer to do anything. (Stupid software
done by someone else inside a computer could decide to do what someone on the
outside says -- but the whole object of design here is to retain confinement
and avoid the idea of commands at every level.)
In theory "real objects" are confined virtual computers that cannot be
commanded. But most use of "objects" today is as extensions of data ideas. Once
you make a setter message, you have converted to a data structure that is now
vulnerable to imperative mischief.
In between we have hardware based "processes" that are supposed to be HW
protected virtual computers. These have gotten confused with storage swapping
mechanisms, and the results are that most CPUs cannot set up enough of them
(and for different reasons, the interprocess communcation is too slow for many
purposes).
A hardware vendor with huge volumes (like Apple) should be able to get a CPU
vendor to make HW that offers real protection, and at a granularity that makes
more systems sense.
In the present case (where they haven't done the right thing), they still do
have ways to confine potentially non-benign software in the existing gross
process mechanisms. Apple et al already does this for running the web browser
that can download Javascript programs that have not been vetted by the Apple
systems people. NaCl in the Chrome browser extends this to allow the
downloading of machine code that is run safely in its own sandbox.
It should be crystal clear that Apple's restrictions have no substance in the
large -- e.g. they could just run non-vetted systems as in the browser and
NaCl. If you want more and Apple doesn't want to fix their OS, then maybe
allowing them to vet makes some sense if you are in business and want to use
their platform.
But the main point here is that there are no technical reasons why a child
should be restricted from making an Etoys or Scratch project and sharing it
with another child on an iPad.
No matter what Apple says, the reasons clearly stem from strategies and tactics
of economic exclusion.
So I agree with Max that the iPad at present is really the anti-Dynabook
Cheers,
Alan
>________________________________
> From: Robin Barooah <ro...@sublime.org>
>To: Fundamentals of New Computing <fonc@vpri.org>
>Sent: Wednesday, March 14, 2012 3:38 AM
>Subject: Re: [fonc] Error trying to compile COLA
>
>
>
>
>On Mar 14, 2012, at 2:22 AM, Max Orhai wrote:
>
>But, that's exactly the cause for concern! Aside from the fact of
>Smalltalk's obsolescence (which isn't really the point), the Squeak plugin
>could never be approved by a 'responsible' sysadmin, because it can run
>arbitrary user code! Squeak's not in the app store for exactly that reason.
>You'll notice how crippled the allowed 'programming apps' are. This is simple
>strong-arm bully tactics on the part of Apple; technical problems "solved" by
>heavy-handed legal means. Make no mistake, the iPad is the anti-Dynabook.
>>
>
>
>To my mind writing Apple's solution off as 'strong-arm bully tactics' obscures
>very real issues. Code expresses human intentions. Not all humans have good
>intentions, and so not all code is well intentioned. Work at HP labs in the
>90's showed that it's impossible, even if you have full control of the virtual
>machine and can freeze and inspect memory, to mechanically prove with
>certainty that a random software agent is benign. So when code is exchanged
>publicly, provenance becomes important.
>
>
>Apple's solution is as much technical as it is legal. They use code signing
>to control the provenance of code that is allowed to execute, and yes, they
>have a quasi-legal apparatus for determining what code gets signed. As it
>stands, they have established themselves as the sole arbiter of provenance.
>
>
>I think one can easily argue that as the first mover, they have set things up
>to greatly advantage themselves as a commercial entity (as they do in other
>areas like the supply chain), and that it would be generally better if there
>was freedom about who to trust as the arbiter of provenance, however I don't
>see a future in which non-trivial unsigned code is generally exchanged. This
>is the beginning of a necessary trend. I'd love to hear how I'm wrong about
>this.
>
>
>My suspicion is that for the most part, Apple's current set up is as locked
>down as it's ever going to be, and that over time the signing system will be
>extended to allow more fine grained human relationships to be expressed.
>
>
>For example at the moment, as an iOS developer, I can allow different apps
>that I write to access the same shared data via iCloud. That makes sense
>because I am solely responsible for making sure that the apps share a common
>understanding of the meaning of the data, and Apple's APIs permit multiple
>independent processes to coordinate access to the same file.
>
>
>I am curious to see how Apple plans to make it possible for different
>developers to share data. Will this be done by a network of cryptographic
>permissions between apps?
>
>
>>-- Max
>>
>>
>>On Tue, Mar 13, 2012 at 9:28 AM, Mack <m...@mackenzieresearch.com> wrote:
>>
>>For better or worse, both Apple and Microsoft (via Windows 8) are attempting
>>to rectify this via the "Terms and Conditions" route.
>>>
>>>
>>>It's been announced that both Windows 8 and OSX Mountain Lion will require
>>>applications to be installed via download thru their respective "App Stores"
>>>in order to obtain certification required for the OS to allow them access to
>>>features (like an installed camera, or the network) that are outside the
>>>default application sandbox.
>>>
>>>
>>>The acceptance of the App Store model for the iPhone/iPad has persuaded them
>>>that this will be (commercially) viable as a model for general public
>>>distribution of trustable software.
>>>
>>>
>>>In that world, the Squeak plugin could be certified as safe to download in a
>>>way that System Admins might believe.
>>>
>>>
>>>
>>>On Feb 29, 2012, at 3:09 PM, Alan Kay wrote:
>>>
>>>Windows (especially) is so porous that SysAdmins (especially in school
>>>districts) will not allow teachers to download .exe files. This wipes out
>>>the Squeak plugin that provides all the functionality.
>>>>
>>>>
>>>>But there is still the browser and Javascript. But Javascript isn't fast
>>>>enough to do the particle system. But why can't we just download the
>>>>particle system and run it in a safe address space? The browser people
>>>>don't yet understand that this is what they should have allowed in the
>>>>first place. So right now there is only one route for this (and a few years
>>>>ago there were none) -- and that is Native Client on Google Chrome.
>>>>
>>>>
>>>>
>>>> But Google Chrome is only 13% penetrated, and the other browser fiefdoms
>>>>don't like NaCl..... Google Chrome is an .exe file so teachers can't
>>>>download it (and if they could, they could download the Etoys plugin).
>>>>
>>>
>>>_______________________________________________
>>>fonc mailing list
>>>fonc@vpri.org
>>>http://vpri.org/mailman/listinfo/fonc
>>>
>>>
>>_______________________________________________
>>fonc mailing list
>>fonc@vpri.org
>>http://vpri.org/mailman/listinfo/fonc
>>
>
>_______________________________________________
>fonc mailing list
>fonc@vpri.org
>http://vpri.org/mailman/listinfo/fonc
>
>
>
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
