Solipsism Gradient

Panasonic quickly followed with the Words Gear. 1024×600 pixels at 211 dpi, half the weight of the Sony Reader, and the form factor is like a paperback with 20mm sawed off the bottom. It has an SD card slot, which is a good idea, and the design looks better; however it seems to use a standard LCD screen instead of e-paper, which means lower battery life.

So, Sony’s Reader is out. This seems to be the first e-book reader that uses electronic paper and has a chance to be more than just a brief clunky curiosity.

The specs aren’t all that good, though. On the positive side, the display has a reasonable 170 dpi (200 to 300 is considered optimal for simulating actual paper) and battery life is reasonable at 7500 page turns. On the negative side, the display shows just 800×600 pixels and the dimensions aren’t ideal – slightly larger than a standard paperback, although a little thinner. From the pictures, the lines are too short for my taste, and 4-level grayscale isn’t enough to do proper antialiasing. And $349 is a little on the expensive side. It plays MP3 files but with only 64MB of memory that’s not much use.

My ideal e-book reader would have a 200 dpi screen which reproduces exactly the printable area of a standard paperback, which would mean a screen 1200 pixels tall and 700 pixels wide. Since the device has to compete against paperbacks, dimensions, weight and (ideally) price should be very similar. The Connect Store shows weirdly mixed prices; some, around the $6 level, not totally unreasonable, while others are in hardcover range. Come on, it’s not as if e-books have to pay for all that overhead of printing, binding, distributing, shipping, remaindering, and so forth. $4 should make e-books more accessible while at the same time paying better royalties to authors.

In 1989, Ben Bova wrote Cyberbooks, a funny and prescient tale of what would happen if such a subversive device as a cybernetic book would actually be brought on the market. Well, he didn’t foresee the emergence (only a very few years later) of the tubes, erhm, Internet, but it’s still a very readable story. Needless to say it seems to have sunk with very few traces; it’s out of print and Amazon has no cover picture available, and I know nobody else who has a copy.

Coming back to the present, I believe Apple should take a shot at this device. Jonathan Ive can do a much better design than the Sony Reader with one cerebral hemisphere tied behind his back, and a 1200×700, 200 dpi screen with 16 or more gray levels will certainly leave the labs soon.

Posted by Um dia a menos:
Um dia a menos linked to this post

Neutralidade

Carlos Afonso escreve no Oppi:

A neutralidade da Internet, como já alertava Lawrence Lessig há cinco anos, significa que os provedores de acesso e de infovias não podem controlar como os usuários utilizam a rede. Não podem censurar datagramas nem …

In 1980, rocket engineer G. Harry Stine, writing under the pen name Lee Correy, published a quite good SF novel called “Star Driver“. In the story, an unemployed astronomer/pilot helps a small aerospace company invent and debug a “skyhook”: a device that converts energy into linear thrust without having anything to thrust against. Stine envisions it as a rod-shaped special alloy resonator fed by a careful synthesized waveform generator. The first prototype is built into a small plane that uses the device to attain record altitude.

Now there’s news of an invention which promises to do just that. (The article may not be available for long; there’s also a PDF explaining the theory of the device.) It’s basically a cone-shaped hollow resonator fed by a microwave generator. Current models generate up to 300mN of thrust – enough to levitate about one ounce of weight against gravity – from a 1KW generator. This sounds puny but is already better than current ion thrusters used in some space probes.

Roger Shawyer, the inventor, plans to modify superconductors now used in particle accelerators to make the thruster more efficient. He says 30KN per KW might be possible if the considerable practical obstacles can be overcome; this would be enough to levitate a 3-ton car.

The WikiPedia article lists many objections to the device’s theory, and it may turn out not to be practical or widely usable. Still, it’s always interesting to see how life can imitate fiction.

Update: Yes, I know that the device violates conservation of momentum; but I think it’d be cool that it might work by what Terry Pratchett calls “something quantum”, in spite of the obvious theoretical faults.

Adam has posted a response on the installer authorization issue:

I don’t believe they’re even calling that function to gain root, honestly, because it follows the authorization file. It can’t not. They’re doing something else and I believe that’s a red herring here. There’s no way to call that function and have it not consult the database, so they’re doing something internal to get around it. Be that a SUID program somewhere or some private call, they’re getting around the clause in authorization that says the user needs a password.

Well, that’d be a surprise to me, but it’s not impossible. I’ll try to find some time to do a test package and some rooting (oops!) around inside the Installer before writing more about this.

Adam Knight the codepoet, whom I link to quite often from here, has an article out on Mac Geekery, ominously called “How a Malformed Installer Package Can Crack Mac OS X“:

There exists a pretty significant interface problem with the Apple Installer program such that any package requesting admin access via the AdminAuthorization key, when run in an admin user account, is given full root-level access without providing the user with a password prompt during the install. This is even explained in Apple’s Installer documentation as proper behavior. The distinction between the AdminAuthorization and RootAuthorization keys is, simply, whether or not the admin user is prompted for a password; the end powers are exactly the same and it is up to the creator of the package as to if he will be kind enough to ask for a password…

Well, at first glance this looks like a pretty serious security hole. Let’s see what that Apple documentation says about this:

This is actually quite clear. If the installer package asks for the same level of privileges that the logged-in user already has, authorization is not required; meaning, it won’t ask for a password. Which makes sense; after all, to log in as root or as an administrator you must know the root or an administrator’s password to start with – usually. If the packages needs higher privileges to do its stuff, the user will be “prompted for authorization”. This autorization will be used for two purposes: setting permissions on the installed files, and for running pre- and post-installation scripts. We’re concerned only about the second purpose. Before going into that, let me explain a few things.

First of all, using an installer package is pretty much, nowadays, a good thing only when you’re installing something that messes with the system’s folders, or that executes scripts that do restricted things. Installing a kernel extension, updating the system frameworks, setting up servers and startup/login items are common examples. It’s frightfully infra-dig to make a package just to install your application in /Applications. In other words, just the presence of an installer package on a disk image should be pretty much an indication that something uncommon will happen if you double-click it.

So, the common perception is that for an installer package to mess with the restricted system folders is that it should ask for root authorization, and therefore you’ll be asked for a password – since you’re not running as root to begin with. Or shouldn’t be; the root account comes disabled by default on Mac OS X. And since most packages do it this way, this perception is reinforced; it’s become pretty much automatic to double-click on a package, type in your administrator password at the prompt, and “boom” (can’t remember who says that ).

So Adam strongly recommends:

Run as a normal user. Open files you trust. Stick to that and you’ll be fine.

Read his recommendations and follow at least some of them. I’d add: use Charles Srstka’s excellent Pacifist software to see what’s being installed, and where, before running the Installer – for one, Pacifist doesn’t run pre- and post-installation scripts contained in the package, so it’s not an Installer replacement.

The tricky part comes when the package asks for admin authorization. Mac OS X installs the first user as an administrator, and it’s required to have an administrator account present – after all, if you had none, the system would become quite unmodifiable. So, the recommended practice is to set up your system in this first account, then set up a second non-admin user account and use this for your normal activities; switch back to the admin account only when installing software.

Unfortunately, Apple seems to have found this confusing for “normal” users, and I’d tend to agree. A significant amount of explanation would have to be inserted into the setup application, especially as this not-normally-used “user” would also have a home folder where stuff would not be visible by the day-to-day user. There’s even the option of setting the machine to boot automatically into a certain user, and I’d say many non-technical users click this to speed up booting and to avoid having to remember their password every day. Unfortunately, as a side-effect of these circumstances, most users are running as an administrator without having had to type in the administrator password at all.

Now let’s suppose you get a (underhandedly malicious) installer package and double-click on it without examining its contents beforehand. You think it can’t mess up much as it will ask for a password if it does anything serious, right?

Wrong. True, it will ask for a password if it wants root authorization – but then, you’re already conditioned to type in your password anyway. But if it asks for admin authorization and you’re already running as an admin, it won’t ask for a password at all, and merrily use the admin authorization you gave it (by logging in!) to muck about with your system.

Now wait a minute. Why does this admin authorization which is not root authorization let the installer run scripts as root, as Adam proved by a test package? Isn’t that a serious bug and security hole, as he claims?

Well, yes and no. The answer lies in a file called /etc/authorization. This is an XML file in property list format which defines the various rights a process can ask for when using the Authorization Framework, and defines a set of rules that are applied when this happens. The principles involved are quite complex, and I’m still learning to understand them fully. Here’s a paragraph from that documentation:

When a user who is a member of the admin group logs on to the system, for example, the user’s credential (that is, the fact that they have entered a valid admin user name and password) is saved in the global credentials cache. Then when this user attempts to modify a system preference, Security Server finds the credential in the cache and does not display an authentication dialog.

which confirms what I said above. And later on:

Not all installers require authorization – only those that need special privileges to copy files to restricted directories, make changes to restricted files, or set setuid bits.

An installer is a special case because unlike other applications, an installer is usually run only once. Due to the limited use, Authorization Services provides a function to invoke your installer to run with root privileges. It is up to the user to determine if the installer is from a trusted source.

So far so good; but why in, practice, do admin privileges mean “run as root”? Well, in that XML file we have the following section:

      <key>system.privilege.admin</key>
      <dict>
         <key>allow-root</key>
         <true/>
         ...
         <key>group</key>
         <string>admin</string>
         <key>shared</key>
         <false/>
         <key>timeout</key>
         <integer>300</integer>
      </dict>

Translating this into a slightly less geeky form, this is the autorization right requested by the AuthorizationExecuteWithPrivileges() call, which is the one used by the Installer. It can be granted to users of the “admin” group, is granted automatically to the root user, and times out in 5 minutes. AuthorizationExecuteWithPrivileges(), in turn, is the system call to run a script as root; which is allowed for administrators, as we’ve seen.

In other words, everything is certainly “behaving as expected”; it’s not a bug, it’s a mistaken assumption: “anything that runs as root will ask for authentication when run by an admin user”. That’s certainly not true. However, I don’t deny that the Installer could be more explicit here, either not calling AuthorizationExecuteWithPrivileges() for its scripts when admin authorization is asked for (which might break some existing packages), or by showing a separate alert at the beginning, saying “this package will run its scripts as root”. Let’s suggest this to Apple and see what happens…

I just found a very nice and interesting gallery of disk images. I decided against using disk images early on when I found that, more often than not, some local setting of the user’s Finder would make the icons move around, usually confusing less experienced users.

But these look so nice, I may change my mind now; I wonder if it might be worth it to file a bug suggesting that icons on locked disk images should snap back into their positions.

Many thanks to Jim Matthews of Fetch Softworks for remembering that I had the original idea of putting a symbolic link to /Applications on the disk image. I now see that most people are simply putting in a Finder alias instead of a symlink… I’m not so sure this is a good idea. It works quite well in Tiger, but it will store your boot disk name at the very least, and perhaps even break if the user has a secondary volume which has that same name.

So, Zune is coming in November. Contrasting with what we’re used to get from Apple, no detailed tech specs or prices were released. The screen has the same 320×240 pixel dimensions that Apple uses, but it measures 3″ diagonal (instead of Apple’s 2.5″). That is, the pixels are 20% larger. The large photos on Microsoft’s site appear smoothed in some way, since no individual pixels can be seen.

What is known of the feature set is… interesting. AAC support, WiFi support for letting friends try out songs, and a FM radio. I suppose FM radio is still in wide use in the US, but I doubt that people will want to pay extra to have it built-in by default. Same goes for WiFi; the impact on battery life won’t be too positive, especially if it’s turned on by default. AAC support may be an effort to get people to migrate from the iPod. There seems to be no built-in recording capability.

I’ve also seen a screenshot of the Zune store. Much like the new iTunes/Store theme, it seems to have a consistent visual appearance. It’s much darker and (to my untrained eyes) more webpage-like. Curiously they use all-lowercase titles in the “source list” where Apple now uses all-uppercase. The last item (“My Zune”) is conspicuously different in that regard. The UI also wastes space on the bottom by reproducing the Zune’s buttons. I’ll be interested to see if anybody complains that this deviates from the normal Windows interface…

All in all, I don’t think Apple has much to worry about in the short term.