[Much deleted here about flash, java, etc.]
Ben:
> 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.)
Actually, I suspect it helps enormously: Especially if certified by a
company with Quality Communications literally spelled into its name,
and hardcoded so that no amount of hacking can change that.
Digital signatures are an interesting innovation that don't enjoy
much consumer understanding at the moment. There's so little
*there*, there. Tying them to a company supplies a "there."
An innovation is successful when it's been successfully marketed, and
and an essential part of marketing is to tie the quality-guarantor
company's name to an otherwise-troubling concept in the customer's
mind. Digital signatures are a troubling concept to most - no
ink, no paper, so without your own eyes as a backup, who do you
trust?
BREW could therefore be QualComm's bid to own the concept of
"security" in wireless corporate apps - worth a bundle to whoever
can do pull it off.
Yes, it rubs us techies the wrong way - "owning" an idea - but most
consumers would actually prefer that their purchased embodiments
be based on ideas "owned" by someone who can be held accountable
for failures of implementation - and the closer to the actual vendor of
the directly-consumed product/service, the better.
This is perhaps why you can argue with some people 'til you're blue in
the face about the security advantages - or at least the security
*competitiveness* - of open source software products, and still leave
them unconvinced. To them, it's enough that "nobody owns it outright"
to leap to the conclusion: "nobody cares enough whether it's safe, and
it's otherwise far more exposed than proprietary code."
> Java isn't an interpreted language.
A matter of perspective, I guess. To me, virtual machine
code is interpreted; JIT compilation is an optimization of
an interpreter.
> Garbage collection adds to memory
> costs but not hugely, and it's better than having memory leaks.
I'm a little more concerned about the computation overhead, and
I guess I take a Darwinian view of memory leaks - apps that
bleed to death *should* die. ;-) Hey, don't get me wrong -
mea culpa! This even includes something I've written and am
supporting right now - I'm trying to convince the client that the
app's hemophilia is only a symption of terminal cancer....
> But
> as I understand things, KVM somehow sidesteps this by limiting dynamic
> memory allocation?
Dunno. Would like to. Anybody?
-m
leap@gol.com
[ Did you check the archives? http://www.appelsiini.net/keitai-l/ ]
Received on Tue Apr 24 07:33:23 2001