I don't have the answer, but I do have some context, observations. (Warning: This is long, and the only useful info in it is how to think about problem description. If you've got real work to do, then don't waste time reading my blogpost here.... ;-)
First and most important, the way to confirm that you have addressed an issue is by being able to make the problem occur on demand, and to tell others how they can also make it happen on demand. That way they can test whether they can stop it from occurring.
A "Steps to Reproduce" is not what you must do to see the problem. A "Steps to Reproduce" is what an engineer needs to do to see the problem. You may not be able to instruct others completely, and knowing what you did is certainly a first step, but a steps-to-repro description should be written from the reader's point of view, not the writer's.
And intermittent problems are certainly the most difficult and timeconsuming to address. We need to be able to make the problem happen with assurance, in order to assure that it has been truly removed.
Check out the comments in the thread -- "I read in a forum that someone else had the problem too" -- that's not a useful comment. If a capability is not working on your system, then we all believe you, and want to improve things. There's no need to prove that other people have it. What we need to do is to be able to see it ourselves, so that we can test whether we can make it go away successfully. You don't need to validate yourself. We all need to explore the argument. It's not you, it's it. Relax, we believe you.
There's one comment from the original poster (identified solely as "M Z") that "No, I have not managed to reproduce it in safe mode." This is potentially a killer bit of info. I'm assuming he means "Windows Safe Mode", an F8-key start which disables many system customizations. If the problem actually *never* occurs with system customizations turned off, then we know to look more closely at the system customizations. But unfortunately, the description is amibiguous... might mean that he rarely tests in OS "safe mode" just as well. Tantalizing, but still less-than-fully-useful.
Someone asks "What Firefox extensions do you have installed?" and then various lists are produced. It's more useful to know whether the problem still occurs with a stock Firefox installation. If you ever see the symptom on that system when not running any browser customizations, then we'll have more info than knowing which brands and versions of extensions you've customized the browser with. Key refactoring: "Have you ever seen the problem when all Firefox extensions have been turned off?" Even one such incident would exculpate all extensions.
Someone identifying themself only as "el3000@gmail.com" offers another potentially useful bit of detail: "I encounter it only after FF has been running for a while (>60 min)." The original-poster needs to be asked whether he has ever seen the problem immediately at system/browser startup, or whether it also needs a significant period of browser use before the problem has ever appeared. If so, I would also ask them to look at their Windows Task Manager, to see how much memory their copy of Firefox is currently using. In the past, media dropout has often been associated with low-memory situations. It wouldn't be too hard to quantify the current reports, to see whether the well-known Firefox memory consumption issues are in play when they lose audio/video.
Subsequent comments of "I have the same problem" do not help at all. No one doubts the original reporter. But these low-info confirmations just muddy the discussion, making a resolution more difficult to reach.
There are additional contributions such as "the problem is your adobe flash player version". That's it, no citation, no reason offered. This is a great example of why public bugbases should be scrubbed for buggy comments. The conversation may be open to this person's participation, but he is increasing readership costs for everyone else. A group needs a smart mix of inclusion and exclusion in order to function well.
Mike Beltzner, a Mozilla staffer, makes a little progress with this comment: "Can we at least call this Windows only? I haven't seen any reports of it happening in other OSes." He's trying to craft a recipe for reproduction of the problem. If we can be sure it's Windows-only, then we'd know an engineer shouldn't bother trying to reproduce it on a Mac. It's a start.
Let's switch back to Rafe's article. It's got the headline "Why can't they fix the Flash/Firefox bug?" This sets off warning lights for me, because of his use of the word "the"... implies that there is only a single problem, and that it's famous. In reality, it's not even yet well-defined. There are also semantic issues with the rhetorical "why", as well as the cognitive issue of knowing what the problem actually is before starting to think about whether it is possible to fix it. When I read a loaded phrase like that, I start wondering how well the writer has started thinking about what they will be writing about. Not a big flag, but a small warning flag of possible confusion ahead.
"Both Mozilla and Adobe have been aware of the issue since late May, but as yet no solution has been found." It would be fairer to see that no way to reproduce it on demand has yet been found. The current stopping-block is in the original descriptions, not in any lack of effort by people writing code.
"One workaround solution is to install the Flash 10 player, which is still in beta." I have no assurance that this changes the problem... in the Bugzilla talk we haven't seen that anyone who has had the symptom has been able to make it go away by using Astro, and make it return by going back to Player 9.
Matter of fact, after reading Rafe's article we don't know whether he has been able to see the problem himself. I sorta suspect he might have, which would explain his interest in this one not-yet-fully-formed Bugzilla entry, but there's zip info on his personal work at reproduction of the issue.
(Later: Yes! Down at the very bottom he says that he sees the problem too, but that he doesn't see it in Internet Explorer. Not much more detail, but it'd be useful if he contributed to the solution.)
There's a quote from Mike Beltzner that implies "ah, if only all Player code were published, then the problem would be easy to solve." Baloney. [expletives deleted] Mike should know, from Mozilla's experience with the Tamarin Project, the massive study curve that even brilliant new engineers need to do to get up to speed, to understand what is going on. And Tamarin is just one small part of the tiny engineering marvel which is Adobe Flash Player.
"He also took a minute to trumpet Mozilla's open-source philosophy. Since Firefox's code is open, Adobe can look at it to try to determine what is going on. But Mozilla's team can't look into Flash. Beltzner didn't blame Adobe for the bug itself, but he did say that Adobe's traditional closed software architecture is slowing down their investigation. 'We hit a wall when it's a closed-source solution,' he said."
The truth is that you simply need to distill the public complaint into an actionable item. The problem actually lies in Bugzilla's conversational style. Right now it's just "Oh I saw someone on a forum describe a similar thing." You need to show engineers how they can see it. Playing the "proprietary" card instead is just weak. I'm watching my language here, but....
Comments at Webware are interesting. Too bad they close it off by registration (yeah, like I'm going to open new accounts and track new passwords for each special little site), and too bad some commenters hide their identity when commenting on others. (Tip to indy Silverlight evangelists: Including a verifiable identity will reduce the taint of possible astroturfing.) The comments section is not very useful overall, but there's some realistic thought in there, which I appreciate, thanks.
I'm with Rafe completely on his penultimate paragraph: "Finger pointing is common in software troubleshooting, and I give both Mozilla and Adobe credit for only generally waving, not pointing, their fingers at each other. Unfortunately, neither team seems to have developers who can reproduce this issue, which just keeps the ping-pong game going." Making the problem occur on demand is the first necessary step in making sure the problem has really gone away.
But his final paragraph seems like rankest fantasy and fairytale to me: "What I find most interesting is the way the differing philosophies of Mozilla and Adobe are slowing down resolution of this issue. If both companies were open then any developer--at Mozilla, Adobe, or elsewhere--could get into things and start experimenting to find a fix. If both companies had closed philosophies then their engineers could swear each other to the secrecy, swap source code, and together fix the issue."
To solve the problem quickly, focus on what it is.
Summary: From the little I can see in the descriptions, I'd really want to check reporters' system memory consumption when the problem occurs... not a sure thing, but a quick and easy diagnostic that may zero-in on the cause of the problem. (To put it gently, Firefox is rather famous for its memory issues.)
Bugzilla needs (imho) to tighten down, get rid of the conversational bloat. Doing tech support is an acquired skill, and not everyone can think directly about a problem, but a good bugbase would instruct new contributors on how to help isolate the true problem, how to describe things so that others can usefully attempt to reproduce it. Readers should not have to read through stream-of-consciousness from strangers. Refactor it, make it functional.
And finally, that line "but it's proprietary" needs to go away. It's a replacement for branding issues. Even Apple, the most proprietary, closed, secretive company of them all, reflexively reaches for it when they don't know what else to say. You and I have near-zero chance to influence the W3C or Mozilla to do something -- they are not more "open" in process than Adobe, or even Microsoft. "Opensource" code tweakability means more for things which run on your own machines (Linux, Apache) rather than on everybody else's machines, when "predictability" becomes more valuable. I'm tired of conversations getting derailed when someone resorts to this weak "proprietary" tactic. Think. We need you to think. Just be honest and think. Quit the blaming and think.
And check your system memory if video stops. Not a guarantee, but it's a start.
]]>Hear me out before judging. I'm pretty surprised at having such a thought myself, so I'm still looking for ways to invalidate it. If you've got a good argument, I'd like to hear it. But it's a simple thought, and so seems strong.
We do know that "Flash subverting The Web" and such are bandied about. The rap is that you "shouldn't" rely upon the Adobe runtime because it's "not HTML, CSS and JavaScript". When asked why, the most common response is something along the lines of "Because Adobe might do something bad someday." (At this point I want to ask, "What, like they did with PostScript or PDF?" ;-)
According to the best stats I've seen -- Google worldwide queries Jan07-Jun08, over a billion browsers -- Microsoft Internet Explorer 6 is still used by almost 40% of the people out there. That's a lot. Beyond that, there's also about 40% of the world using Microsoft Internet Explorer 7. Another big audience. Beyond that, Firefox? One person out of six... 16%. A meaningful audience, but still, only one person out of every six. Safari has half the remainder, Opera is bigger on mobile, and 1.4% use even rarer browser brands.
Microsoft has overwhelming, crushing marketshare in rendering websites' HTML. 80% of the time your JavaScript will run in a Microsoft logic engine, against a Microsoft DOM, with Microsoft styling, and it's 50/50 whether you'll be running inside IE6 or 7. A TV network is ecstatic to get a 40% marketshare. A political party is completely satisfied with a 51% marketshare. Google dominates search with 60% marketshare.
For running Ajax, Microsoft has an 80% marketshare.
You can't choose. Your audience makes their own choice. And 80% of the time they choose a Microsoft runtime to render your HTML, CSS, and JS productions. Microsoft runs your code for you.
When you create an HTML page, 80% of people will view it in a Microsoft runtime. A pure "web standards" site from a CSS guru? Four out of every five people will see it rendered by a Microsoft runtime. A JavaScript application which can retrieve text from a server without refreshing the page? Your scripting will overwhelmingly be interpreted by a Microsoft runtime.
Microsoft Internet Explorer 7, getting close to 50%. Microsoft Internet Explorer 6, dropping down towards 30%. Mozilla Firefox, less than 20%. Safari, Opera, Konqueror, and more which must be supported.
But inevitably rendered 80% of the time in a Microsoft runtime.
(I know, I know, there is the promise that the standards process will someday Shame Microsoft Into Doing The Right Thing, and that Firefox must eventually rule the world, and "Better IE than SL!", but please bear with me, I was born a skeptical fella.... ;-)
If you're objecting to Adobe runtimes "because they're proprietary", then why would it be preferable to run nearly-all-the-time in Microsoft runtimes instead?
Such a simple question, seems like it should have a simple answer....
]]>This forum thread seems to have the most descriptions (possibly of multiple issues), but the screenshots and partial descriptions don't seem to mention any particular SWF at MSNBC.com. As in previous Flash warnings through this venue, it's hard to summarize the main evidence, drawn from various disconnected forum posts. Dan Goodin said Sandi mentioned Flash, but I didn't see where she did (other than with her weblog template about "flash malvertizements"). There's not yet a succinct case.
It's plausible that some webpage has some rogue SWF which acts obnoxiously with the clipboard. Might be a JavaScript thing too. But let's say that there's indeed some rogue browser element which just yak-yak-yaks into your clipboard.
Two questions:
1) How did you get to be executing some logic which acts so obnoxiously?
2) If you're using a browser to surf the web, should strangers have so much power?
(The answers are already here, but let's run it fresh again anyway.... ;-)
How'd some rogue interactivity get into your browser? Probably because of a trustworthy webpage with untrustworthy third-party content. Ad networks are big vectors for third-party resources. Web-based services are another way to introduce third-party scripting into a composite webpage. Even a third-party GIF can no longer be completely trusted. Sandi's page is pretty secure, but even this is executing scripts from three domains... the article at The Register is executing scripts from six different domains.
As Nat Torkington described, if you're republishing third-party JavaScript, even trustworthy sources may prove untrustworthy. If you're accepting interactivity through an ad network, then they don't seem to have formal processes to vet the people they forward to you for republishing.
If you use Firefox and AdBlock Plus, or have another way of inspecting third-party content on webpages, take a look at just how many domains are involved in creating the page you're viewing. Each HTTP request for a GIF or a JavaScript or an RSS or even a ping is registered on a server log at those unanticipated third-party sites, and for interactivity (.SWF, .JS, whatever), your browser will be accepting instructions from parties other than the site you're visiting. Modern sites like TechCrunch invoke dozens of scripts and ping even more domains whenever you visit.
Should webpages have so much power, as to be able to copy to the clipboard? Probably not, because you can't trust everyone else we allow on the network. Early email architects didn't imagine spam, but spam is what we got. If we want to safely click from link to hypertext link on the World Wide Web, the most stable solution is to give the browser experience few privileges.
(The alternative (which failed for Microsoft in the 1990s, and which Google is reviving in a different way with their search warnings) is the concept of giving some groups of publishers greater trust than others, which leads into an additional class of permission-raising exploits, spoofing, and so on, as well as all the subsequent social opposition from the less-privileged classes. In these days, when even your local domain-name server can't always be trusted, favoritism doesn't scale at all well.)
Web browsers need to be able to safely visit any hypertext link, safely execute any instructions they may contain. To gain greater privileges, it seems smarter to use a separate codebase with a more generous sandbox, than it is to set up permission schemes. This is the fundamental reason that I believe the various brands of WWW browsers won't be able to act very much like desktop apps... the needs of visiting any strange site safely conflict directly with the needs to be trusted and powerful parts of your daily environment. Theoretically possible; pragmatically fragile.
Anyway, on this story at The Register, I haven't yet been able to identify the exact situation from the descriptions. Clipboard-spamming does seem a possibility. And the trends of composite webpages with third-party content makes it increasingly difficult for in-browser apps to act like desktop apps.
Summary: This report needs further investigation.
]]>
Biggest takeaway: People like rich video experiences. The big sitback screen is still first choice... broadcast served far more traffic than Web. Pundits who argue "Web vs TV" are missing that it's "Web *and* TV". But when people can experience a "Video RIA" they like it. Good validation.
But when people are excluded, they don't like it. Microsoft was heard as saying "we're bringing Olympics to the world", and only later people realized this was a US-only deal. Linux users were cut out, as were Mac/PPC owners. Then 10% of US broadband folks were cut out atop that. Microsoft would have drawn less criticism were they a little more realistic in setting expectations.
What are the numbers for Silverlight? Hard to say... still seem contradictory. Nielsen Online says in an Aug 13 press release that the video section of NBCOlympics.com received 2,030,000 unique visitors on Mon Aug 11. Microsoft is saying they got eight million "downloads" one day. When you combine geo-restriction, platform-restriction, and failed installations, the NBC site may have prompted a million successful installations one day. Looks teeny.
Whatever the actual numbers turn out to be, it doesn't seem to mean much for making Silverlight deployment to the general public any more practical... a site would still have to eat those support costs. I risk turning RIAstats.com into a gaming target by mentioning it, but Saturday morning still shows less than 2% Silverlight 2 support. The DNC doesn't seem like it will change this either. The numbers are still fuzzy, but it seems pretty clear Silverlight's silver bullet shot blanks.
Still unclear to me is the mobile angle. Some US-oriented quotes seem to show this at 25% of the desktop browser video viewing. Considering there are probably device restrictions, atop the OS restrictions and geo-restrictions, this could be a big deal. Needs more detail.
Also unclear so far is the overall global picture, and how people worldwide actually used web video this Olympics. China has a bigger internet audience than the US, and much more interest in the games themselves... news services uniformly use Flash video these days... regional licensees seemed to mostly deliver in non-beta software their audiences could actually view... there was massive peer-to-peer delivery this time as well.
It will take awhile for the world to really understand this worldwide video event. Signs look good that it changed expectations in a positive and useful way. We humans do like smarter video. Good sign.
Two other bits this week, Microsoft-related, but not Olympics:
ECMAScript fell down and went boom. The best numbers I've seen show IE6 at 40% marketshare, IE7 at 40%, and Opera/Firefox/Safari/etc at 20%. That's the real world. For the specification process, ECMAScript has been working on its next version for almost a decade. It's been clear for a year Microsoft won't implement it, and so the world won't support it. End of story. HTML, CSS and JavaScript continue to evolve relatively slowly. Makes the whole VIDEO/RIA/Aurora predictions seem even more unrealistic. [nb: I rewrote this paragraph an hour after initial post.]
ISO fell down and went boom, too. Microsoft pushed through the OOXML proposal. Doesn't matter that no one can implement it, and perhaps no one might even want to implement it... Microsoft Office is no longer barred from governmental purchase because it's not a politically-mandated "open standard". Circus all around on that one.
Put those two items together and it gets really silly... Microsoft saying "ooh ES4 is too hard for us to implement" (despite it being already deployed to over 90% of consumer machines today!), then pushing through "an open standard" that even they can't implement. Just business, not personal.
Anyway, for in-the-browser delivery, it's still "Flash Just Works". I can understand that committed .NET developers might want to believe otherwise, and those heavily invested in cross-browser JavaScript 1.x frameworks might want to believe otherwise, but no amount of bloviation changes the basics. Adobe Flash Player provides universal publishing capability, and truly rapid evolution atop that. The Adobe Integrated Runtime is bringing this beyond-the-browser, to trusted Internet apps. Flash Just Works.
And people do indeed like live video communications. The trend's our friend.
]]>I micro-blogged this earlier today on Twitter, but want to call out some main topics in the weblog.
An intro to video delivery choices:
The video you see in BBC iPlayer today is encoded using the On2 VP6 codec, at a bitrate of 500Kbps. The On2 codec (a video compression technology from a company called On2) is pretty much the standard for video delivery over the internet today. It's optimised for moderately low data rates (300Kbps to 700Kbps, rather than the 2Mbps to 4Mbps needed for HD content), and low CPU usage, allowing it to work reasonably well on older computers. In short, On2 VP6 is the video workhorse of the internet.... Compared to On2 VP6, H.264 delivers sharper video quality at a lower data rate, but requires more CPU power to decode, particularly on older machines, and the user needs to have the latest version of Flash installed.
Back in December of last year, relatively few people had installed the Flash player needed to play H.264 content; now almost 80% of BBC iPlayer users have it. More machines now have graphics cards with H.264 hardware acceleration. Additionally, Level3, a content distribution network (CDN) is now able to stream H.264 content to ISPs in the UK, and the content encoding workflows that we use (Anystream and Telestream) are now able to support H.264.
... The good news for those looking for video quality improvements in BBC iPlayer is that, starting this week, we're going to be encoding our content in H.264 format at 800Kbps. Additionally, our media player now supports hardware acceleration in full-screen mode, giving a greatly improved image at lower CPU usage than before.
So they've got the clientside runtime technology already installed (Adobe Flash Player), and the production workflow almost migrated (changing to MainConcept encoders), and their content distribution network is about ready to go H.264 too.
Final element? User experience. You can't yank peoples' habits, expectations out from under them. That's why the release will be in stages. First stage is offering parallel VP6 and H264, with VP6 as default, and H264 available via a "Play high quality" button. Once this is realworld-tested, the next stage is to turn on automatic bitrate detection, meaning that H264 will become the default on good connections. The stage after that would be analyzing bandwidth changes and audience desire. They're getting their feedback a little at a time, not asking the viewing audience to change to too much, too quickly, without recourse.
Also see Erik Huggers, who gives the larger picture about the move.
In comments at Anthony Rose's technical discussion: "Is this new codec going to be compatable with the Nintendo Wii?" This is a tough question... but it's a valid question. iPhone and PlayStation owners ask the same thing. Nokia Internet Tablet, iRiver, and many other devices achieve standard capability via Adobe Flash Player. But it did take awhile before office printers standardized on Adobe PostScript... there will always devices which don't include standard capabilities, especially during the early days.
Innovative file-format types do tend to be commodified over time... bitmap formats work better across devices now, and text is easier than in the early years. Mozilla will be adding the On2 VP3 codec next year, as has Opera. But I imagine it would be expensive for realworld video production workflows to distribute an additional older format of compressed video for a minority audience... desirable, sure, but expensive. See how it goes.
You've got to get all four legs of the stool solid: the production workflow, the distribution process, the clientside capability, and then the user experience. The BBC is a good example of how a video production group actually goes about this testing. I'm glad the BBC is so open about how they're bringing about this work.
Lots of commentary the past few days focused on the details, but I think it's more the overall shape that's important. Wouldn't you want seamless synching among devices, and wall displays, and integrated telecommunications, and more satisfying interface customization, and easy data capture/transformation, and strong location-awareness? Those seem like good things. I'd like to see them happen.
Whether a particular comp's interface is "busy" or context-menu design isn't as important to me... practically, multiple implementations of interfaces would eventually handle these different audience needs. I'm looking at the overall direction, and I definitely like it. There's other stuff to accomplish too, true, but what I see in the video are good directions in which to strive.
You and I can see ways to accomplish lots of this lifestyle today... I had fun watching the video and thinking how it might have been produced. ;-) But it's not yet a widespread and easy way of using digital devices. If the Aurora videos can bring more people into believing that these are important goals, then that's to all our benefit.
(I'm not sure of the video's focus on "Web and Browsers" instead of the larger "Net and Clients". We need an ability to visit any published page in the world without fear. Doing that with the same codebase as extreme personalization seems trickier than the alternatives. I see future computing as more of an Internet thing than just a Web Browser thing. But that's a separate issue, as is the video compression.)
Check out the series of four videos, if you get the chance this week. There's some good stuff in there, and I think this campaign will be successful in getting more people anticipating these evolutions.
Blast from the past: Kevin Lynch, 2003, device cooperation.
]]>Update: Fixed two typos about Player 9 release dates... originally read "2006", should have been "2007".
]]> -- start republished comment --"Flash can get to 'ubiquitous' across the entire web with new capabilities in roughly 18 months and the Open Web faces a best case replacement time-frame of 5 years. Reducing that differential from 42 months to zero is now the defining challenge of the Open Web."
Hi, interesting essay. I don't have the answer, but I do have some datapoints which may be of use:
o Consumer adoption rate of Adobe Flash Player is now actually quite a bit faster than that... Player 9 (with Just-In-Time compilation etc) was released end of June 2006 2007 and was audited at 97% consumer support twelve months later. Its Update 3 (with H.264 video) was released in December 2006 2007 and reached 82% consumer support within six months.
http://justin.everett-church.com/index.php/2008/07/09/fp9-97-flash-player-9-update-3-at-82/
Neither of these used the auto-update mechanism, which is reserved for security releases. It was the range of content out there which drove the adoption rates.
To have over 80% overall consumer support, across browser brands, within six months is indeed a big deal.
o Download size has been an issue in the past. I'm not sure what effect it will have in the future, particularly across device types. In the early days Macromedia did studies adding null kilobytes to Player downloads and measuring the dropoff rate in completed installations. The more time people have to hit that "Cancel Download" button, the more will do so. And browsers are bigger than plugins....
o I haven't seen measurements of it, but one factor I've long suspected for slower browser adoption is that it risks change to each person's daily visual/tactile routine. Browsers have chrome, menu items, new preferences to investigate. Adobe Flash Player is just invisible. There are no habits to change, no risk of breaking daily concentration. Visible newness can slow adoption.
Rephrased, changing your browser chrome involves a conscious choice, the assumption of risk of habit change. But invisibly improving a background capability is an easier choice to make.
o Needless to say, changing browser brands imposes a much higher cost on endusers than just updating within the same brand. If all browser creators don't agree on providing a capability, then it will always be costly for sitemakers to employ that capability. This is intrinsic to the spec-first, implement-later model, and is one reason why cross-browser plugins are such a valuable complement.
o Firefox does have a healthy update rate. But it accomplishes this by daily phoning home to check for new updates. Adobe Flash Player defaults to checking for updates every 30 days, and such updates are published at a less frequent rate than for Firefox. I'm not sure of the optimum notification setting or criteria for the majority of the web, but suspect it's more at the Player end of the scale than the Firefox scale. Open question.
http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager05.html
o What's the fastest way to use new abilities? I suspect it's opening up "The Open Web" and not casting aside technologies just because of branding. Folks at Sitepen already have an open-minded attitude towards web technologies. But there's also some needless antagonism out there too.
By embracing cross-browser technologies, instead of retreating into a browser-brand niche, wider audiences will be able to use newer abilities more quickly.
My apologies for any poor phrasing on my part... typed quickly. These are some of the ideas I thought of while reading Alex's essay and subsequent comments. Thanks for the read!
jd/adobe
]]>Bottom line: Clicking on links in social media is like not washing your hands after being out in public -- you just can't know what you will pick up.
The part that worries me the most is the "says it's Adobe Flash" part. We've seen such impersonation before with files ("Naked Wife", eg). But to actually impersonate a very well-known runtime? I'm not sure how that will play out. Some people will fall for it, and I feel for them, but most would see through it. Still, some real people will be hurt.
David Lenoe, from Adobe's Security Team, had a blogpost up about it today. I don't think that the people who need that reminder would ever see it though. I'm still concerned.
Adobe is not directly involved, but the infection relies upon using the existing goodwill towards the overall Adobe Flash ecology... without all those sites which made Flash a standard, this social exploitation would not work. (And Ryan's article doesn't clearly state whether the link is to an .HTM, .EXE, or other file, so it's unclear to me yet whether URL-shortening services are currently enabling the exploit.)
A bigger bottom line: Someone out there in the world is going to get their bank accounts stolen because they saw a dialog that said "Adobe Flash" and they said "Okay". I don't feel right about that.
Do you have thoughts, advice, observations on this? I'm seeking different ways to look at this problem, different approaches we might take. Open to anything, thanks in advance.
]]>derStandard.at holds an interview with Novell's Miguel de Icaza, about their Mono and Moonlight emulations of Microsoft runtimes for Linux. Miguel also points out the convenient blindspots of those who argue against technology solely on the grounds of "It's not The Open Web":
I mean, how many people outside of the technology world really know about Linux at the moment? And even the Mozilla guys - the keynote we had here was done on a mac, every single Mozilla developer uses a Mac. And it's funny, they constantly attack Silverlight, they constantly attack Flash and then all of them use proprietary operating systems, they don't seem to have a problem doing it. And then they had the Guiness record thing for Firefox 3 and you went to the website and it had a flash map to show where people are downloading - so there definitely is a double standard here. And that's after all their claiming that you can do everything in AJAX - so they definitely don't 'walk the walk'."
If evangelists try to say that practical realworld web technologies can be tossed aside because of alleged philosophical impurity, then why aren't these proselytizers using some type of Linux box, instead of the super-secret tightly-controlled Apple hardware?
And it goes up a level too -- if you're really concerned about open use of the World Wide Web, and are against proprietary secrecy, then wouldn't you avoid accepting primary funding from Google, who has the biggest databases tracking consumer behavior on the Web, and who refuses to allow people to access the files Google holds on them? (If you're not up-to-speed in this area of cross-site tracking via third-party content, then try EFF, Wikipedia, or me.)
When your mortgage is ultimately paid by selling consumers' attention, it's a little disingenuous to throw rocks at others who just sell software.
We accept "proprietary hardware" and "proprietary OS", and run through "proprietary service providers" to bulk up "proprietary ad networks" and "proprietary social services", all to build "proprietary behavioral databases" for a sugardaddy, but dadgum we can't be using no "proprietary plugins", nosir (unless'n they're our "proprietary plugins" that is)!
It's like seeing a supermarket ad for "all natural ingredients"... nice enough at first listening, but just what does it mean? And if you met someone who insisted on eating only "all natural ingredients", but couldn't describe what they were, then that could get more than a little weird too.
I think it makes a lot more sense to just neutrally weigh the benefits and potential risks of various choices, and not to dismiss any choice out-of-hand for religious reasons. But if I were to argue that certain choices may not be tolerated, then I'd likely try to make for some reasonable consistency in that intolerant stance. Why feed Apple below and Google above, if you insist "Flash is subverting 'The Open Web'"...!?
The emphasis is on HTML development ("do not use tables", "do not use frames" etc), but lots of the recommendations are good for any runtime engine: strike a balance between similar experience across devices and using device-specific capabiloities... use emulators early but be sure to test on the varied devices themselves before release... minimize auto-refresh without audience disclosure and control... doublecheck contrast and color use under various viewing conditions... my favorite: "Use clear and simple language" (which implies acceptance of language-neutral imagery and appropriate animation).
There's a longer version available too, but it's good to keep the summary bookmarked, both for personal checking and as ammunition in internal workgroup discussions.
]]>The core driver beneath all this is the business need of website owners to attract sufficient qualified traffic. (The meaning of "qualified" would vary with the site and its purpose.) If a manager is charged with responsibility for the website, they need to be able to prove that it's worth the corporate investment. Site traffic is the easiest metric to use.
"How can I attract enough qualified visitors to my site?" That's the reality. This need of site-owners is what puts the whole Search Engine Optimization business in motion.
But much of the weblog conversation on SEO is about relative trivialities, such as whether every word in a database is "exposed to the spiders". Who cares? There would be too much competition for such incidental search terms anyway. If your personal Ajax or Flash apps can draw dynamic data from remote databases, then so can other Ajax or Flash apps. Who is going to get on that first page of Google results?
Attracting visitors is only partially solved by search. We websurfers do sometimes discover new sites through keyword-matching on a search engine. But we more often discover new sites through the recommendations of friends or trusted strangers. And if enough other websites link to a site with anchor text of "best insurance website" or whatever, then that site will naturally do better when people type that phrase into a search engine.
If emphasizing the search engines in the overall pursuit of traffic goals, then the best approach I've seen is to first consider how your potential audience might actually try searching for you. What terms will they likely enter in a search engine? What's the current competition for those terms? On which search terms can you realistically compete, to get that desired top listing on the first page of results?
Start by looking at the searching process itself... look at things from the visitor's point of view. Think of how they'll try to find that site. Then make it easier for the search engines to find it under those terms, with the classic bodytext, metadata, and sitemap info.
But don't forget that search is only one ingredient in attracting an audience... the site will still have to be useful enough for others to advertise with informative text.
So what do I know about search? Not much.
I do know that the SEO marketplace has been remarkably resistant to inconvenient questions, and suspect that much of the conversation isn't really about search at all.
And I'm not convinced that search engines are the best discoverability engine we should be considering anyway. Even for keyword-matching, they're already pretty much overwhelmed by noise.
I do know that trusted recommendations are still the key way to attract traffic directly, and authoritative inbound links incidentally have a beneficial effect on search results.
But I do know that there are enormous social drivers for the creation of all types of SEO beliefs... the rewards are great, the details few, the promises many. We'll likely see confusion for a good long time to come.
]]>I'm not putting down the pundits... they're entitled to view anything anyway they see fit, and it's likely that Adobe hasn't done the strongest job in insisting on understanding of its goals.
But this isn't a story like competing cable or satellite providers, and which company secures the rights to a given title in a given region. It's not one of those earlier zero-sum games about which movie theatre chains can show the fancy MGM films, and which chains shows the quicker RKO titles. It's more like designing the first cathode-ray tubes, or discovering the business models for the first TV stations. We know we have to achieve something, but still have to figure out its final form.
Off the top of my head, Adobe Media Player 1.0 delivered three significant things: a local Rich Internet Application for viewing video from diverse sources, replacing the page-refresh video experience where your viewing history is stored on some company's server and then data-mined... a subscription-based, "video comes to you" experience, laying the groundwork for future decentralized social viewing recommendations... and a policy-file system which lets content creators determine where they grant viewing rights, to whom, and when.
There's a whole lot more technology understructure yet to test and develop. We need better creation, integration, and analysis of video metadata, a coherent pipeline for including information along with the visuals. More work needs to be done on the overall production workflow, from planning to asset tracking to editing to compression to distribution to analytics. We need to analyze and expose video content (speech-to-text, object recognition) and social metadata (recommendations and tagging from friends), so that advertising (the main revenue generator) can be more tuned to the viewing audience's current needs. We need to make the video experience more customizable to the content producer's experiential design, and more responsive to the enduser's desires. AMP 1.x did accomplish a lot, but there's much more work yet to done.
Within Adobe I don't hear people talk of competing with particular video sites and distributors... such initiatives are uniformly seen as partners, or as potential partners, who have technology needs which are not yet met, perhaps not yet even recognized.
Everything I see points towards Adobe Media Player as being a technology platform, where new publishing capabilities can be explored and refined. "How will the viewing public want to experience video in 2010, 2015, 2020?" seems more the spirit than "What's the marketshare for the catalog this month?" That's the reality I see within Adobe, from the product team to the Dynamic Media organization to the top executive level. We need to bring about the next generation of internet video publishing.
Back when Adobe PostScript first provided a more predictable digital printing capability than the maze of competing printer drivers and application exporters, Adobe Systems did not open a publishing house or try to monopolize book distribution. Adobe achieved its financial goals by opening up the publishing process to universal access, earning money on sales of enabling technology.
To confirm this cultural DNA, see this recent interview with Charles Geschke, co-founder of Adobe. He was a math professor who found computers personally interesting, found great satisfaction in making the written word more accessible to more people than anyone since Gutenberg, and now stresses the importance of the new integrated runtime for networked application development. It's a longterm view, not about controlling content, but about profiting by helping others sustainably create and use content. This cultural orientation was one of the most striking things I learned about Adobe, coming in from the cowboy/interactivity/shrinkwrap culture at Macromedia.
Other companies have different business models, whether it's to sell a range of consumer electronic devices, or to develop an advertising network, or to increase the range of proprietary personalization databases. But Adobe makes its money selling neutral publishing technology. The more people who find video useful, the better. These core orientations determine the different paths each group will take.
The AMP marketing materials do emphasize significant partners, but there seem to be two main reasons for that: (a) we need a goodsized audience to provide reliable feedback on how people will really want things to work; and (b) creators are actively seeking ways to maintain a connection with their big-budget work, beyond just letting an .MPG run wild throughout the Web in hope that money will somehow flow in. Sony, CBS, Showtime, MTV and all the rest are validating that they find potential within AMP, and those big titles help draw useful audiences during development.
(There's an interesting angle on big-budget video... YouTube became famous during the Web 2.0 age for "User Generated Content" (UGC). That's great, I love it, it's valuable, we need it. But audiences tend to obsess on professional, big-budget entertainment... that's they stuff they hunt for. And to afford those professional budgets, creators need a real return-on-investment. Finding ways to support video-creation businesses is the real way to support video-viewing audiences.)
Anyway, when I see the daily commentary focus on Ghostbusters or The Love Boat, I can understand how someone fresh to it may just see what's personally relevant for them. But I see bigger goals within Adobe, focused far more on new technology than commercial properties.
The Adobe video pipeline is undergoing startling rapid evolution. I'm betting the Techmeme stories from Summer 2009 will likely be quite a bit different.... ;-)
]]>Om Malik observed: "The S3 outage points to a bigger (and a larger) issue: the cloud has many points of failure - routers crashing, cable getting accidentally cut, load balancers getting misconfigured, or simply bad code."
The 2002 definition of "Rich Internet Application" explicitly mentioned support for occasional connectivity. Most of us have assumed this means that the app works whether or not your pocket device can connect to the net. But it's just as valid whether a remote service is down. The app should just work, regardless of whether its connectivity requests can be fulfilled.
Support for occasionally-connected applications is available in the Adobe Integrated Runtime (AIR). But it isn't automatic. We still need well-accepted design patterns, interface conventions to handle varying freshness levels of remote data. We've got the basics down at the platform level, but there's a lot of work left to do at the application level.
The cloud concept isn't dead just because S3 went down. Arguing whether Amazon or Google or Microsoft or a startup has best connectivity is irrelevant -- all services are occasionally unavailable. Simple always-live apps are vulnerable to surprises. Every application that relies on the network really needs to figure out how to still work, when it cannot connect across the cloud.
]]>There were big debates last week about "blaming the W3C for a proprietary web" (Slashdot, Paul Ellis, Molly Holzschlag, Alex Russell, Shelley Powers, OSNews, John Carroll, Steven Clark, more). There was a subthread of "Don't blame the W3C; blame the browser vendors instead", but that still assumes that there is blame for something to be doled about.
My bottom line: When people ask "Should we blame the W3C for being so incredibly slow on RIA specifications (or video specifications or two-way communication specifications or whatever) that proprietary corporations end up doing things on their scurrilous own?" I hear a tower of assumptions which could end up damaging the consortium's ability to do the things it actually needs to do.
Here are some of the underlying, unquestioned assumptions I read in comments to the essays above:
To understand the question "Is the World Wide Web Consortium to blame for the rise of The Proprietary Unweb?", you'd have to first understand real life as being composed of the same duality in the same way, then to agree that they're pitted against each other, and then to think that action is required to save one by attacking the other.
When people toss around "The Open Web vs The Proprietary Unweb", it's an open assumption that each person understands life and technology's social effects in the same way. Such labeling tends to encourage arguments.
Asserting an assumption does not make it so. It does make the rest of us suspect that you believe it is so, but it's not really the basis for good communication.
There is no need for such a kill-or-be-killed, oppositional style of technology development. Assumptions to the contrary would first need to be substantiated.
We humans finally achieved personal electronics just a generation ago, and we've had only a decade for freely networking them together. We're still striving to move this network to the pocket, so that the computer goes with you instead of you going to the computer. I don't even have a pair of WiFi projective sunglasses yet, for goshsake. We don't know much yet. It's early.
The World Wide Web and its eventual consortium definitely weren't created to predict all new uses of the network. They might be able to help in many of these goals, but the World Wide Web is only one part of the larger Internet: "A key concept of the Internet is that it was not designed for just one application, but as a general infrastructure on which new applications could be conceived, as illustrated later by the emergence of the World Wide Web." The Net is bigger than the Web.
The work of the World Wide Web Consortium is not easy work. We've had a hard time getting newer specifications for HTML/XHTML/HTML5, CSS, agreement on things like JavaScript 2. What's worse, considering that it's much easier to standardize on such simpler, well-known things first, it's potentially destructive to attempt to standardize everything all at once, particularly in advance of any practical realworld knowledge. Asking too much of the W3C risks getting not much of anything at all.
We can see this already in just HTML itself. What was once "so simple that anyone could learn to publish in an afternoon" has become a hulking monster of complexity, where you are judged by how little you are out of compliance. HTML creation has become much less accessible to real people with each increase in the specification's complexity and scope. VRML and SVG are two other processes which folded under the weight of the increased expectations placed upon them. It's hard to be simple.
Assuming W3C primacy over all new Internet uses assumes too much of the group, its mandate, and its abilities. Assuming the consortium is "too slow to solve the video problem" or "too slow to solve the mobile problem" overburdens them, and distracts from the task of solving the hypertext problem.
This is more a general lifestyle assumption, but one which seems to be the basis of the two assumptions above. You hear a lot of the word "should" in these conversations.
Committees of experts are good at noticing what works, slowly grinding away differences, making a predictable recipe for future success. The top-down process is efficient at distillation, but the bottom-up process tends to work better for discovery. Corporate marketing didn't create a YouTube, a Flickr, a Twitter, a Techmeme. It's small groups which usually discover new niches, and large groups which later colonize. The Five Year Plan doesn't uncover novelty. Centralism doesn't do as well in unknown territory.
The liangyi is made up of both Yin and Yang, moon and sun, order and chaos, centralism and decentralism. One grows from the other, both interdependent. The standardization process works better for negotiation on the known than for discovery of the unknown.
I think we need both centralism and decentralism to succeed. The edges are nowhere without the center, and vice versa.
I don't see the need for setting up oppositions in internet technology... we should look at all options objectively, and not just characterize tech by who developed it. I also don't think that the World Wide Web Consortium can be realistically tasked with the expectations to solve all the new problems of The Internet.
I fear that asking more of the W3C than it is capable of accomplishing will make their actual work more difficult, endangering the basic browser technologies upon which we're slowly continuing to agree. Such unwarranted assumptions add risk to our future hyperlinking abilities, to our future networking abilities, to our future personal publishing abilities.
The question in this discussion is itself part of the problem. It assumes the W3C must change course to slay giants. It is not a neutral question, and asking it often enough makes it harder for the W3C to slowly accomplish what it must do.
Simple standards work best. If we agree on voluntary standards, we want everyone to be able to meet them. If the specifications are too complex to implement or follow, then these specifications won't attract as much voluntary compliance. The simpler the rules, the better.
Disclaimers:
Simple idea, but hard to talk about... Jacqui Cheng has another article at Ars Technica: "The Social Accessibility Project hopes to circumvent the entire problem of dealing with developers by allowing users with screen readers to automatically report problems with various web pages back to IBM. Volunteers can then sort through IBM's database of accessibility issues and create their own metadata for each element. When users with screen readers return to that site, or go to other sites visited by project participants, they will simply load the latest information from the database and be able to navigate the web with greater ease."
Neat idea, but I wonder what the social repercussions will be. Website owners have typically rebelled against third-party annotation networks, whether Third Voice or Smart Tags or any of various other efforts. One hot issue is when people see their work mashed-up without their explicit consent... another hot issue is the confirmation of metadata accuracy within such a voluntary network... I guess a third hot issue could be when trying to determine whether the HTML page you experience on one machine is the same as the same address on another machine. Lots of issues to iron out when the canonical page representation becomes mutable.
Still, this is intrinsic to the HTML model... when you can't predict the user-agent, you're never quite sure how others will experience the media you create. Greasemonkey is likely the posterboy example of not knowing how your HTML will be rendered. Third Voice was ultimately rejected by the webdev arbiters, but I think it will be harder to argue against this Social Accessibility Project.
No conclusion on my part... this collaboration on improving the webpages of others seems like a very delicate problem, and I can't predict how it will be received by website designers and website owners in general. Interesting.
]]>