ASVGuy::SWFBlog

Accessibility: Is a CC button deaf-friendly?

You learn something each day, sometimes it has a big impact.

Suppose you are designing a FLV video player. Unless the player is to be extremely simple, you will want to support displaying closed-captions/subtitles, either because you are truly accessibility conscious and care about it, or, because you find the idea of displaying subtitles for a foreign language movie cool. Surely, you will want to cover all bases.

Lets start adding captions support to the design:

1. You will need to have a button, labeled 'CC', that toggles display of captions.
2. Not all FLVs will have associated captions, so a feature can be to hide the CC button (rather than displaying it in disabled state) when there are no captions available. This will also provide more space for other controls, a slider may benefit from the extra space. [1]
3. Some people will want to start with captions-on, so you will provide the programmatic interface to start with the CC button already clicked once.

Can you think of any other option? (Other than supporting multiple language tracks) Anything missing?

Until some minutes ago, I wouldn't know the missing option, and the CC button would be the symbol of my accessibility support.

Missing option is having captions on all the time without the CC button to turn them off.

What good is that for? Obviously you could have thought about this, but why would you want it?

Because, at a site for the deaf (which is what accessibility is really all about in this case), a CC button is not considered deaf-friendly. Captions must be present and displayed at all times [2].

Just like the way you (and I) think, 'let's not display the CC button because there won't be captions for some FLVs', you should also think, 'let's not display the CC button because there are times there will be captions all the time and they will never be turned off'.

A FLV player with a CC button, sure, is accessible. But if you really care about accessibility, you should have the option for not displaying that button.

That's what I learned today, from one of our Captionate [3] customers, who is creating web sites targeting deaf consumers, and who himself is also deaf. He is passionate about this. For him, it's not an option to have the CC button displayed, it's inappropriate, it's not deaf-friendly, end of story.

Could I ever, by myself, have thought about supporting captions without a CC button? Maybe... Could I ever have shared the passion about this? I don't think so.

Nothing is as simple as it looks, accessibility included.

[1] Obviously, if you have designed a player that works with different skins, you will want to have skins without a CC button (no captions support) and skins with a CC button that support captions. For the sake of this discussion, this is irrelevant.

[2] 'They can embed captions onto video in that case' will be too shallow thinking,

[3] We do not provide a player for deploying captioned FLVs with Captionate. We do not have a FLV player product.

ASV is 9 today...

So I haven't been posting lately.

I was obviously busy, but main reason was (as I have written before) I didn't want to sound like trying to sell more copies of ASV using my blog, and I didn't want to post off-topic, but any on topic useful bits of info I could share was un-shareable. What was left was Adobe press release like news, like the recent Flash CS4 10.0.0.2 update, but I decided I didn't want that long ago.

Of course, I can always post about hot topics of the day, like recent Flex Builder name change to Flash Builder. Well, I hate it and I think it's wrong. Adobe is exploiting the 'Flash' name and I think it will not help the 'Flash' brand or the platform. A totally, absolutely wrong move - will cause lots of confusion in the long run* (so I totally disagree with KP on this one). OK I said it, it won't change anything (other than maybe some people with strong feelings about this will start not having good thoughts about me).

A few months ago I even did an off-topic test blog to see if I can really post at least daily. I saw that I could.

Anyway...

Today is ASV's 9th anniversary. I had to post, because I realized if I didn't, some people might get wrong ideas about us, ASV, ASV's future etc. We are on pre-release for quite some time now, for various reasons, but we are working and alive just as we always have been (We released last pre-release ASV just 16 days ago with improved SWF 10 and AS3 support). Second of all, I call myself 'ASV Guy', so this makes this post appropriate. And 9 years is quite a long time for any product.

I don't know how often I will post here, hopefully my next post will not be exactly this day next year...

* Unless Adobe is getting ready to 'phase out' Flash IDE, the authoring tool, which would be a worse (or probably the worst) move and Lee Brimelow says this is not the case.

On Version Numbers...

We will be changing version numbering of our products. Admitted, if we didn't feel we have to do this, most probably we wouldn't have cared at all.

For ASV, we started with version 1.0, in 2000. And major versions went like 2, 3, 4... We reserved .5 minor update for a somewhat very significant update and normally minor updates went like .01, .02, .03... Internal releases made us skip minor version numbers released and sometimes we increased the minor version to avoid confusion (People do confuse 5.1 and 5.01).

We synchronized ASV major versions with major Flash versions. ASV 1 supported Flash 4, ASV 2 supported Flash 5, ASV 3 supported Flash 6 (MX)... I personally liked this because it was straight forward and  it made things simple. But this was mostly because Flash major versions were synchronized with major Flash player versions (and so SWF versions). After all, you created Flash (SWF files) with Flash (the authoring tool). Why should there be a major player release if there's no tool to support the new features? Then there was Flex... (Flash was not the only authoring tool that can support a new player anymore).

Frankly, I think we still would be reluctant to change the versioning, if ASV didn't lag behind. We currently have ASV 6 'pre-release' version. Again, the most important reason it's called a pre-release is probably because we don't have the documentation/help yet. Otherwise any release version is also bound to have bugs/issues or some missing features. Current ASV pre-release can even open SWF 10 content (found on the web), displays a warning about the version because it's not supposed to support SWF version 10. And of course new Flash release is near and skipping version 6 of ASV, because it's released as pre-release versions, doesn't sound good.

I never liked other naming/versioning schemes... Windows 95, Office 98, MX, CS3, Flash MX 2004 (version 7 which was released in 2003 BTW)...

One thing was sure, we would never use arbitrary letters or acronyms as the major version designator. Using year or date was surely better and then the date actually meant something. If the software is clearly dated, you don't need any other version numbers. The developer assigns the numbers anyway and there's no standard (We did skip ASR versions 3 and 4 to align it with ASV version. Some developers use odd/even minor version numbers for unstable/stable builds, we never did that because we never have unstable builds. Some skip versions 4 and 13 because of superstitious reasons. There's no standard really).

So, it's ASV 2008... We ourselves hated the way it sounded first. But make no mistake, it won't be deceptive like dates on magazines. I never got used to reading a mag dated into the future... So, let months be another number of the version, and the day another. If you have ASV 2008/10 that will mean it's released in October 2008. In the about box, you will see a verbose version string like 2008/10.14, where 14 will mean the date of release.

We are losing the arbitrary version numbers, version number will be the time stamp. That's our solution and we believe it's superior to arbitrary numbering, cuts the confusion and has many other advantages to both the developer and the users.

We always made updates free, and charged for some upgrades. Since our version numbers depended on new release of Flash (and then we needed some time for supporting the new Flash), you never new exactly when there will be a new major version. And because it was not feasible for us to work on many versions, usually what happened was that we stopped working on a previous version and started working on the new version. Bug fixes and improvements even for earlier versions of SWF went into the new version, old version just stayed as it is... We did have a grace period but someone who purchased ASV when a new version released did get longer free upgrades than someone purchased just before the grace period (and received the next version as per our 'next version upgrade free' policy). In short, using dates lets us offer things like: ASV with 1 year of free updates, or ASV with 2 years of free updates. There will be no 'upgrade' in the normal sense, major version number will change from 2008 to 2009, when 2009 comes...

Is this new? Not really. And most software do need major version numbers to indicate milestone releases. Ours didn't, we have realized. Our version number (which will be the date) will mean that the software is what we had at that date, nothing more, nothing less.

Do you want to purchase a copy of ASV and see this in action? :) You'll have to wait till mid-October...

All the above is quite condensed, I can write a small chapter about this change. Let me finish by saying that we will never inconvenience our current customers, they will get what we have promised at the time of their purchase and maybe some more because we would be cautious (rather than err) about this.

ASV 6 Alpha 1

We have just made ASV 6 Alpha1 available to all licensed ASV 5 users. It's really an alpha release, very incomplete.

Still, we think it will not be totally useless. And with the future alpha and beta versions, we hope our users will help us finding issues (With this alpha1 release, there are so many known issues, we are not really looking for reports from our users).

For example, the AS3 decompile engine integration to ASV is not complete at all (and neither the decompile engine), so you'll see timeline scripts as classes, where each frame script is a method. Most probably you won't be able to see those classes in later builds and each frame script will show on its own frame...

Exactly 7 years has passed since ASV 1.0.

I do post about ASV anniversaries - don't do that for our other software.

I was able to convince remaining 3 members of our team to release an update on this very day. The result is ASV 5.27 with only a couple of cosmetic bugs fixed, still, I feel good about this (but I wouldn't urge you to download it if you already have ASV 5.25)...

So it's been 7 years. Last year it was 6. And I hope, next year, I'll post an '8 years' post. Thanks again to everyone who helped to make this possible...

ASV, UAE, ASR 5.25 updates released!

These updates mainly enhance the decompile engine and fix some bugs. (No CS3/AS3 support yet, it will come with 6th versions and ASV 6 is expected to be available by July 16th, 2007).

I will keep this post short. ASV license owners: if you are also using SWF Encrypt 4, please test your protected SWFs with the updated version (and let us know if you find a bug). Thanks.

(We think most probably these will be last 5.x updates for ASV, UAE and ASR. Not that we won't release updates if a serious bug is found. May 16th is ASV's 7th anniversary, and I tend to think it would be a nice coincidence to have the final 5.x version released on that day...).

Adobe Ships Creative Suite 3 and other news

Flash CS3 Professional is available for purchase now along with other CS3 applications and CS3 suite versions, though I don't see a trial download available yet. Rumors were that the big day would be April 20th, it turns out it was today. (UPDATE: Trial downloads became available on May 9th 2007).

If you have missed it, Flash Player 9,0,45,0 was released on 12th. This is the CS3 update and Flash CS3 ships with that version.

Another press release is about Adobe Media Player (Philo),which is being developed using Apollo and will be available before the end of this year. Me thinks it was time Adobe had an Adobe Media Player and it will probably help Apollo runtime distribution at first and then benefit from it later.

Todays 'renaming' news was a name change from MS. The 'Flash killer' WPF/E or WFP/E or something - god I never learned the name- got a very creative new name: Silverlight (There was nothing new released). MS didn't stop there and while at it, renamed the acronym RIA as 'Rich Interactive Application'! I didn't realize this and read it (even the full phrase) as 'Rich Internet Application' until I saw JD's post.

News from us: As we have previously announced, new version of ASV which supports Flash CS3/AS3 will be available in 3 months from today (All ASV 5 purchases since the start of March is considered as ASV 6 purchases for upgrade purposes). We may also have a beta earlier open to customers only. Our other applications, UAE and ASR, will also be available, hopefully in a very short time, after ASV release. Captionate version 3 will be available as a free upgrade in June.

SWF Encrypt, SWC Encrypt, Do you need them both?

Update: Please see the update at the end of the post.

Generally I don't post about specific Flash/SWF obfuscators. I believe there's a need for both obfuscators and decompilers. We bypass popular obfuscations with our tools with updates every 3 to 6 months, which I believe is fair.

There are many obfuscators. SWF Encrypt by Amayeta is a well known one. SWF Encrypt 'works', as many other obfuscators do -until they are bypassed, though Amayeta usually have funny claims like their software provides 'up to 1000 times stronger' protection. (It took us just minutes to bypass their initial v3, with such claims).

I haven't tried their new version 4 yet, we bypass obfuscations as we receive requests from our customers, we do not actively check them out. But, as ASV 5.21 bypassed many current obfuscations at the time of its release (January 5, 2007), we expected obfuscator vendors releasing  updates. (Actually, I thought they would be much quicker. An obfuscators whole job is to hide your script. A professional decompiler like our ASV provides many other benefits so it's not vital for us to bypass SWF obfuscations very quickly. In fact, we deliberately not do that).

SWF Encrypt is an expensive tool from where I look. We sell ASV for US$60, their tool sells for US$125. Writing a decompiler is far more difficult as I see it, so I consider it expensive.

Now, they have another tool, SWC Encrypt, for $125 and they sell the bundle for 'just' $250 (they don't believe in bundle discounts I guess).

SWC files are in ZIP format, you can rename a SWC as .ZIP and open/extract it with any ZIP tool. ASV does that when you open a SWC file, searches the ZIP and opens the SWF if there's only one, or displays a SWF list. We never thought of releasing a SWC decompiler, because it would only mean the added support for opening ZIP files, for which there are free libraries.

I don't know if this SWC Encrypt actually does something special for the SWCs, but I've previously seen one other 'SWC obfuscator' that didn't. I wasn't able to find any info about this on their site, if this SWC Encrypt is just SWF Encrypt with ZIP support, selling for another US$125, that is just sad.

You may choose SWF Encrypt for your SWF obfuscation needs, it's a bit expensive and a bit too popular (both are not really good), but it works as much as any other in its class, considering ASV (I must say that I don't know exactly how much other decompilers bypass every obfuscation out there). (I also must say that I usually recommend another class of obfuscation, identifier renaming, as Genable ASO lite does. The process is harder to automate and may not suit your needs, but it's irreversible. Even if you'll be using another obfuscator later, it may be worth obfuscating identifier names first for maximum protection).

For your SWC obfuscation needs, I'd suggest simply extracting the SWF(s) from the SWC (by renaming it as a ZIP first) and obfuscating using your current solution. Then you can zip them back and rename the file as .SWC. (and this can easily be automated).

If you paid US$125 for SWF Encrypt, if I were you, I'd ask them for SWC support, which is trivial and I can't see why they shouldn't have it (unless it will make their SWC Encrypt obsolete).

If you have a Flash obfuscator, it's easy to obfuscate SWF files in SWC files using your current obfuscator. You don't really need to purchase a separate SWC obfuscator.

And if you have a SWC obfuscator, chances are that you can use it for obfuscating your SWFs. Simply ZIP your SWF, rename the ZIP as .SWC, obfuscate it and extract your 'obfuscated' SWF back...

(5 hours later) Update:
OK, one of my good friends emailed me and said that the above (obfuscating SWFs and re-zipping the SWC) didn't work with SWF Encrypt. I was surprised. I hadn't tested anything but I didn't see why it wouldn't work.

The only reason I can think of is the method SWF Encrypt uses. It moves the bodies of the scripts to undefined SWF tags, jumps to those tags from action tags. It exploits the fact that Flash Player will jump and execute code anywhere in the SWF file. This may have caused the SWC incompatibility.

Current conclusion:
If you have SWF Encrypt, you may need an additional SWC obfuscator, as it seems their obfuscation is not that compatible. (Other obfuscators should work well, maybe you should think twice before investing in SWF Encrypt).

If you have a SWC obfuscator -and that should include SWC Encrypt- , you can obfuscate your SWFs using it by simply putting them in ZIP files and renaming ZIPs as SWCs.

(One day later) Update:

Final thoughts:

My initial motivation for this post was my surprise to see a SWC obfuscator, which is normally quite redundant if you have a SWF obfuscator. It turns out, Amayeta needed one because of the obfuscation method they used with SWF Encrypt. So, in fact we have two different obfuscation methods here. (You can use SWC Encrypt for SWF obfuscation but you cannot use SWF Encrypt for SWC obfuscation). I've received an email suggesting that SWF Encrypt is stronger than SWC Encrypt. This may well be the case, but they both sell for US$125...

ASV, UAE, ASR updates released... (2)

Another day, another update... How embarrassing! Nevertheless, this has happened before and we had to do what we had to do. We released updates, within 24 hours of the 5.20 updates, which fixes a single bug. Current versions of ASV, UAE and ASR are now 5.21...

This made me think why we don't release updates more frequently... Obviously the reason is testing and quality assurance. This one bug was about having a one-too-many semicolon somewhere as a string constant - so it was an easy fix and required not much testing...

Speaking of updates, Ted Patrick's post on Adobe Flex 2.01 update was quite enthusiastic...

ASV, UAE, ASR updates released...

As scheduled, we have released 5.20 versions of ASV, UAE and ASR. Only the decompile engine has been enhanced and fixed (apart from very minor changes to other parts), still changes are significant. (As usual license owners can download the updated versions at their assigned download URLs).

New versions bypass some new obfuscations older versions couldn't (provided that correct AS import options are selected) but I know from experience that it won't take obfuscator apps too long to get updated.

My recommendation to anyone who wants to protect his code is to use an obfuscator that renames identifiers, before any other type. Even if the code gets decompiled - and that happens sooner or later-, it would be extremely difficult to understand for others.