[whatwg] Potential Danger with Canvas API in html5 #html5 #canvas

On Thu, Jun 10, 2010 at 12:20 AM, Peter Beverloo <peter at lvp-media.com>wrote:

> 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:
>
>
No, i  do not have any info. I am independent developer who enjoy making
predictions -
http://blog.narendrasisodiya.com/2010/06/how-and-why-browser-share-ratio-will-be.html


> 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.
>


Yes, you are correct at this points,



> 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.
>
>
PHP script generate HTML code along with JavaScript. It make our task easy.


But, Lets imagine
if we have a very good Tookkit which have everything for webdesign like
buttions, menus, dropdown and final code renders everything in CANVAS.
ToolKits may use altogether different higher level sytax to generate canvas
based applications. further this toolkit has JavaScript unzip library. then
you will be able to create a application in zipped format.
Let me explain this more

   - Designer/Developer will use drag and drop based Toolkit which has
   altogether different higher level sytax which generate CANVAS based
   application.
   - Toolkit Or some JavaScript code will generate JavaScript code with all
   resource like image, htmlcode, source code and everything in application
   directory.
   - Toolkit will zip the whole application and finally designer/developer
   will get a *myfirstgame.wapp *

Now developer/designer need to write this much code

<script src="./js/wapp-engine.js"></script>
<div class='wapp-application' data-src='./myfirstgame.wapp' width='600'
height='800' />

This wapp-engine.js will be a wapp player which load
*myfirstgame.wapp*using Ajax and unzip files. Create a dynamic canvas,
and render the game in
canvas area.

So we are using HTML5 canvas but what are we doing

   - Fast and GUI based development tools with a non-standards/proprietary
   ToolKit for generating a .wapp files which can be distributed and developed
   easily
   - .wapp will be played in browser will be JS wapp player which render it
   inside CANVAS API with hiding images, text and everything under pixels which
   is the prime requirement of many website
   - Desktop based wapp player inorder to play downloded .wapp files.
   - Web will become a binary world.

So, it is quite possible to introduce a new non-standard technology under
the CANVAS API with Javascript unzip library.





> 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.


Wow, I have not having this idea in my mind. thanks for the trick.


> 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
>



-- 
???????????????????????????
?    Narendra Sisodiya
?    http://narendrasisodiya.com
???????????????????????????
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100610/632b8a0f/attachment-0001.htm>

Received on Wednesday, 9 June 2010 13:05:35 UTC