Michael Turner wrote:
> > >Java delivered over the Web went over like a lead balloon.
> >
> > How about, "How well would Flash have done if Macromedia had to
> > approve every Flash file?"
>
> OK, but Flash was always about...well, about flash. Java (applets)
> held out the promise of more, but ended up being heavier without
> adding anything over Flash.
Flash has grown up to be almost as functional as Java applets, but it
wasn't always that way.
> > I don't think security on the handset against malicious programs
> > (the point behind both the sandbox and Qualcomm's certification)
> > is about protecting your personal data.
>
> No, but it might be about protecting corporate data, in the case of
> BREW. Or corporate image, depending on the severity of the spoof.
>
> > What you need to do is stop people replacing the interface, or
> > sniffing the browser for credit cards, or making voice calls to
> > premium-rate numbers in Moldavia when the phone's in your pocket:
> > you need to restrict access to the handset functions.
>
> Just as browsers running applets needed to restrict access to the
> rest of the computer. Thereby restricting applet usefulness to the
> point of being essentially useless.
Not at all. They give the site designer more flexibility in
displaying information and allowing the user to interact with it.
They're extensions to the browser, not new applications.
> > The applets you load that need personal info - be they personal
> > banking or B2E (business to employee - the new buzzword - watch
> > for it in Red Herring in 6 months) will use SSL to get it from a
> > remote server.
>
> Assuming you haven't been tricked into using the wrong applet,
> anyway.
Applets can be signed too. I don't know whether Java phones are
capable of checking signatures, though, and the issues involved are
kind of hard for the average user to understand. (I don't think that
using a single hard-coded CA helps, though.)
> > As I understand it, the advantage of BREW is not the security,
> > but the execution speed, because the code runs natively. (I
> > think) the use of certification instead of a sandbox is part of
> > this.
>
> Execution speed and/or handset cost. Certainly it adds something to
> the cost of a JavaPhone that it's running a garbage-collecting
> interpreted language.
Java isn't an interpreted language. Garbage collection adds to memory
costs but not hugely, and it's better than having memory leaks. But
as I understand things, KVM somehow sidesteps this by limiting dynamic
memory allocation?
> I'm not sure how Microsoft was planning to handle this issue with C#,
> which supposedly always runs natively.
.NET applications are compiled to an intermediate language (IL) and
then to native code later on, just like Java. .NET does garbage-
collection, just like Java.
(Don't take this as bashing either Java or .NET; in my view these are
points in favour of both, for most applications.)
<snip>
[ Did you check the archives? http://www.appelsiini.net/keitai-l/ ]
Received on Tue Apr 24 01:50:41 2001