Dave's Bit Bucket

Saturday March 08, 2008

Smartphone? Sun Ray!

As smartphones increase their memory capacity and implement increasingly sophisticated apps, losing (or being relieved of, under duress) your smartphone is rapidly becoming as serious a disaster as losing (or being relieved of) your laptop. Samsung even ran a billboard ad last year around Heathrow, to the effect of "how could people imagine running their lives without their Samsung smartphone" - to which my obvious reaction was, "what happens if someone nicks it, then?"

So, wouldn't it be excellent if - on parting company with your smartphone - you could make one 'phone call, either from home or a public 'phone box, to both turn your missing smartphone into something about as useful to a ne'er-do-well as a brick, and order a new smartphone which, once you receive it and get it registered, will automagically have access to your address book, documents, music, browser favourites, etc?

This is why, what you really need isn't actually a smartphone, but a smartphone-form-factor Sun Ray.

Admittedly, there are one or two downsides to having a Sun Ray instead of a smartphone. You'll need a continuous 3G connection, if you want the unit to be usable wherever you are - this would currently limit the take-up of such a unit to folk who very rarely stray outside metropolitan areas with major 3G coverage, such as central London. However, there's enough such people, that a device could probably be justified.

Also, while the fundamental point of smartphones, and indeed 'phones in general - the ability to make and receive voice calls - is still (AFAIK - my information may now be out of date...) "not quite there yet" on a Sun Ray in terms of being able to do interoperable VoIP, I've seen working VoIP implementations on Sun Ray which aren't quite production-ready yet, but which appear very close to being so.

Still, I've also been doing some thinking. While a bunch of applications specific to smartphone-form-factor Sun Rays would clearly have to be written bespoke and designed for a small-screen user interface, how might "something which is being used as a smartphone, yet which is being served from Solaris" benefit from security technologies such as Trusted Extensions?

Let's start by considering the 'phone book app. If I run my 'phone book app at a label which strictly dominates the label at which the apps which make my 'phone calls, handle Bluetooth connectivity, etc, are made, and I give my 'phone book app the privilege to write data down across labels, then I can set things up such that a connectivity app will only have a number or other connectivity details exposed to it, when a connection needs to be made.

Thus, practices such as Bluejacking would cease to be feasible, as the connectivity apps don't have the privilege to access 'phone book data.

Now, let's consider my 'phone-based web browser, or my 'phone-based copy of iTunes or similar. Where I want to run an app which needs to make external connections and upload data, I could run it at the same label as the rest of my connectivity apps, but give it the privilege to write data up, across labels. For a browser, it would still need to be able to read up (unless I had a separate "Favourites" app, which had the privilege to write URLs down and launch my browser at a lower label, much like GlennF's "safer browsing" prototype) which is, on consideration, probably the better way to go.

In fact, splitting apps into separate "uploader" (with write-up priv) and "player" (run at higher label, with "Favourites" potentially having write-down so that updates may be checked for) components, is probably the definitive way to go.

Suffice to say, if such an environment was built, nobody would be getting their hands on my 'phone book or my copies of S&M or The Ring, any more :-).

Does this have mileage, or what?

(2008-03-08 15:35:51.0) Permalink Comments [2]