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
