July 17, 2006

Flash Player #9, Pt 3

Continued from Part 2.

"Content" is good because its (a)on-demand and (b)maintenance-free/seamless. But the Flash Player can update itself on-demand only through, and by the graces of, the browser's security model, and even then, only if you HAVEN'T RUN ANY FLASH CONTENT first.

That's right - if you saw Flash content that didn't require an update, even if you click through all the installation steps, and browser warnings, you (likely) STILL won't be able to look at new content that uses the new player unless you quit and restart your browser.


In some cases, you have to
reboot the computer.

And its hard to argue "no, we didn't want to
bypass the browser security model" when you have a system tray installing updates out-of-band.

To wit:
Flash Player?
(Quote: "Can someone tell me what 'Macromedia Flash Player' is. I had a message andan icon that I have never seen before pop up in my system tray telling methere was an update for M.F.P. I wasn't aware that I even had M.F.P. ")
I'm" fed up with Macromedia Flash Player

Ironically, all those Browser alerts to update become annoying quickly because of poor online advertising content - which prompts constantly to get a new Flash Player. And that ultimately drives users to upgrade, of course (so it works, but....)

I guess, what I'm getting to is:
(a) We never talked about Viewpoint Media Player "versions" because it was a meaningless concept. If you built content for the "latest" components, you could play that content, no ifs, ands, or buts.
(b) Content asynchronicity is an import aspect of the "Web-at-large"
(c) Code asyncroncity is a dicey, best-avoided problem - discreetly quantizable, at best

Hopefully with
Apollo (the new Flash runtime for the Desktop and beyond), Adobe will include some facilities for seamless and on-demand upgrading of the runtime itself.


That was a long walk off a short pier - what was I talking about again?


Michael said...

This is a wuzzle! There are potentially a half-dozen things going on here, so I'll mention just a few:

1. I care that code on my computer is secure, and that bad content can't do bad things.
2. I care that webpages load fast.
3. I don't like restarting & clicking on EULAs and whatever else.

#1 and #2 both work better with some sort of active autoupdate that's not content-driven.

#3 is an implementation detail that any sensible versioned plugin model should have.

Notably #3 was a feature of VMP (and it's a nice consequence of the loading model), but it's easy enough to implement otherwise. Flash (or a browser's plugin model directly) could be built on a versioned stub loader, and it would have the same benefits. And it could still actively update itself, provide protection against viruses, and load really fast.

Sree Kotay said...

You're a wuzzle! (what's a wuzzle? :))

1) Yeah - I don't think that code on-the-fly is a great idea security-wise, but truth is, I think (unfortunately) that source verification is the best practical solve over the near/medium term

2) I don't think "Background" driven is enough - like jar/Java, I think its got to be like CONTENT (on the fly, on demand); it should do that too, though

3) yup

I guess where I'm going is: virtualization is going to win the day eventually (likely Flash/Java/.NET style rather than) - and that the VM should be (a) as minimal as possible and (b) recognize if it requires native code to exist in the first place, it will likely require capabilities, extensions, fixes, etc. - i.e. it should treat itself as empoweredly (is that a word? :P) as it does code/content it executes

Sree Kotay said...

hmm. wuzzle....

oh, and, yes, I wish they WOULD address the stub/loader thing. I agree its not hard at all- but I'm thinking s that install/update is one of THE most important things content runtimes can/should do.

Imagine if browsers worked this way for HTML