In the UGP, there's always a user. When a site is instantiated, there is a user associated with the Canvas/Easel of that site. 

Some of these objects are owned by the user. Others are owned by the local console.

Clipboard for copy / cut / paste / drag / drop ("ccp/dd").

     -> on the console? If the user owned it, he/she could cut and paste between consoles (ooooh! Fancy trick!).

Storage for objects. Each user has his own "suitcase" which has an object hierarchy (folders containing folders and objects).

• Not accessable to sites? The user must manually ccp/dd. 
• This is where user's desktops are kept, each with a background and window layout.

Devices (on the console, preferences stored with the user):

• Sound (3D sound / 5.1 speakers / multiple sinks + sources / volume controls on each site)
• Filesystem access: hard disk, CD/DVD, USB key or memory card...
• Webcams, scanners
• Printers  

Notification:

• Messages to the user (or sent to other users) (urgent / info /  debug)
• Log transcripts (one on each window)
• Emails for later reading.
• Forums?
• Chat?

Keys for public encryption (of course, protected by the user)

Settings (for user, for console)

• Individual site preferences
• Preferences for classes??
• Keyboard layout
• Mouse settings (accel, etc)
• All device settings, really: webcams, printers, etc.
• Personal information, e.g. name, location, photo
• Whether the user wants Sites to play an optional soundtrack (so that it doesn't clash with their own background music). 

Dominions:

• Hosted dominions (on the console or server)
• SiteBrowser preferences for new dominions for sites.

User services could be managed using this cool trick:

chatBox := user getByClass: ChatBox.

If the user already has made a ChatBox, that singleton will be returned. Otherwise the user is asked if they want to make one. The User object has a dictionary of Class->instance associations which it uses to look up these user-specific singletons. This way, any class can become a new service.

I'm not sure where the user object will come from. Options I've thought of so far are:

• Make it a permanently available literal made by the compiler - which somehow changes when multiple users access an object??? Keep in mind that it is hypothetically possible that one image might host several users, so it can't really be a class variable or global variable in an image.
• Make it a "global variable" in a namespace? Again, how then are multiple users accessed?
• It is passed to the application by the Canvas / Easel. 

If the Canvas or Easel pass it to the application, then the Canvas could follow the pattern above...

MySite>>initWith: anEasel "a callback handler"

     user := anEasel getByClass: User. "Allows for upgrades of the user implementation"

     log := anEasel  getByClass: Log.

     sound := anEasel getByClass: BasicSound.

     locale := user getByClass: LocaleSettings.

     " I like this approach. "

The dictionary holding the classes needs to be secure to prevent a class implementing its own hash.

User Authentication

Users need a public/private key pair. This could come from:

• Ideally, a USB key chain. You can buy special cryptographic USB dongles. Usually these are used for software licensing.
• Other peripherals, such as RFID cards, smart cards, or software on a smart phone or PDA.
• File storage. This is less secure but cheap and convenient:
• A USB drive.
• Hard disk.
• A network disk. This would be common in businesses: the user's keys are stored in their roaming profiles or private network directories. Logging in to the OS would authenticate them and map their private network drives. These keys need to be found automatically by the VM for convenience - perhaps a registry setting or a configuration file?
• From a database or shared object (with username and password to access it). This lets users log in using only a username and password - and it can be used as a back-up for a hardware dongle.
• Er... QRCode on paper, and a scanner or webcam...
• Typing it in manually (which would be only useful to restore the key)
• From memory, for temporary use. 

If there isn't an available key pair, a temporary pair could be made. This would be useful for public access. Keys should also be optionally protected with a password - especially if they are stored and accessable by the OS. Password protection could prevent people stealing the private key.

There must be settings to help find the location of the key. Perhaps well-known locations for settings could be used, such as settings files in the home directory on Linux (or in /etc), or registry entries on Windows. 

Typically on Linux, a hidden directory (e.g ".ugp/") would be used to store files. This could contain the key pair files, or a settings file which determines where keys are searched. The image would possibly also scan USB devices, listening for dongles. Perhaps this directory could be non-hidden and also contain the binary files, caches and executables? If a USB drive is used, then the binaries could optionally be stored there as well.

If a USB drive contains a key pair, they should be in a well-known location such as under a special directory name.

Multiple identities could be logged in at the same time. Each window would allow setting the user (a drop-down?).

Under windows, a registry entry would list the locations to look for keys.