Tom Lee wrote:
In the original Microsoft list of workarounds for the Eolas patch, one of
the possible workarounds was to base64 encode your swf and embed the data
inline in your object tag. The original page has since been removed, and
the only evidence I can now find of this is at
http://www.mustardlab.com/developer/flash/standards/, a page being kept
around for archival reasons (see the "official fixes" section). Though I
don't need this technique as an Eolas workaround, I'm still really curious
about it. Is it possible to base64 encode a swf file and include that raw
data in your web page instead of hosting a separate swf file on your server?
Anyone have experience with the Data: URI Scheme? I find it odd that
Microsoft would include it in their list of workarounds if their browser
didn't support it, but then again, maybe that's why the page was removed.
I'd like to at least get this working in Mozilla browsers.
Tom,
Hey, it's Mustard Lab--that's us. I actually work with Sean Christmann,
the author of the page that you referred to, and would refer you to him,
but he's out until Monday so I'll take a stab at elaborating on this.
The very short answer to your question is that that the data: URI scheme
(RFC 2397) is not supported by Internet Explorer. It does, however,
work with most other browsers on the market, including Firefox, Opera
and Safari. As such, it is not helpful in terms of working around the
recent change in IE to bring it into compliance with the Eolas patent.
To answer your second question, yes it is possible to use this technique
to encode a SWF file within a containing HTML page. A while back, I
actually managed to write out a second SWF to a HTML page from another
SWF with a bit of Javascript. You can see a working example with source
code here: http://dev.psalterego.com/datauri/.
Originally, I was experimenting with using the data URI scheme as a
possible means to obfuscate SWFs encoded within an outer wrapper SWF to
make it slightly more difficult for relatively unskilled "script
kiddies" to quickly recover and decompile the bytecodes for the inner
SWF via a simple attack with a decompiler. However, as such a scheme
would result in the inner "protected" SWF being completely inaccessible
to Internet Explorer users, I never pursued this idea further.
Keep in mind that this technique is not particularly efficient in terms
of file size, particularly if the base 64 encoded data is stored in
HTML. There are also limitations on the maximum possible length of a
URL supported by each browser that effectively limit the size of the
data that you can include via a data URI scheme.
Jim
_______________________________________________
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com
