[whatwg] Potential Danger with Canvas API in html5 #html5 #canvas
Peter Beverloo
peter at lvp-media.com
Wed Jun 9 11:50:17 PDT 2010
On Wed, Jun 9, 2010 at 20:29, narendra sisodiya
<narendra at narendrasisodiya.com> wrote:
>
> Canvas API is just great and I love it, You will also love it , if not, just see Canvas demos - http://www.canvasdemos.com
>
> But we have potential danger to misuse it also for the sake of non-standards.
>
> <prediction>
> Case 1 - Abode can make its flash-player inside canvas API. I know, it will not be 100% compatible. They can create a CanvasAPI based flash player. Their are already 2 client side run time engine in JavaScript - Smokescreen and Gordon - http://twitter.com/jdowdell/statuses/14985295733 , Biggest advantage with JS and client side is that you can see sourcecode. In order to hide the source code , Adobe can use server side. Some processing will be on server side and output will be streamed (in form of image) to client side and renders into CANVAS area with pixel. You can grab event from canvas area and send bacl to server. This way Developer may come up with a Server Side HTML5 toolkit which will reuse BAD standards like flash with Hiding Source code of a Web Application . Adobe or other companies can modify their products and generate server side HTML5 code which will render the application CANVAS API.
> A huge number of dummy developer use such non-standards tools and with this, they will be able to reuse skills by this and will not adopt a true spirit of HTML5.
> So, This I do not like,,,--> ''designer/developers will be using non-standard server side code, generated from non-standards ToolKits, and pretend that we also use HTML5"
>
> We urgently need HTML5 authoring tool. we urgently needs SVG authoring tools.
>
>
> </prediction>
>
> I guess, with the advance of html5, Adobe has been working hard to run flash on canvas from server inorder to save its presence.
>
>
> .
> --
> ┌─────────────────────────┐
> │ Narendra Sisodiya
> │ http://narendrasisodiya.com
> └─────────────────────────┘
> Yet another HTML5 Developer.
Hello Narandra,
Do you have any links or sources backing up that Adobe is working on
the server-side? While your scenario certainly is possible, even with
today's possibilities, I see a number of problems with it:
1) The number of simultaneous users in any web application will be
severely limited by the available processing power of the server.
Thinking of the current uses of Flash, a really large part of which
are video players and games, it does not seem realistic. Extend this
to Flash applications such as FarmVille on Facebook and server-side
processing and rendering will be pretty close to impossible.
2) How exactly is this different from normal webpages? A lot of
websites use scripting languages as their back end, such as PHP,
delivering a certain flexibility which is not directly visible to the
user. The same thing can be applied to achieve creating personalized
Application Cache Manifests.
On top of that, there are various Javascript obfuscators around which
convert code to nearly unreadable pieces of text. While code
formatting can be normalized using a range of tools, variables like
"_" and "___" will be continue to be confusing nonetheless. Such
obfuscation is enough to stop 99% of the people from getting/copying
the code, going through the trouble of continuous connections and
server-side processing for that last percent seems unlikely.
If any application is that critical, the author should consider
limiting access to the application altogether.
Regards,
Peter
More information about the whatwg
mailing list