Bitcoin Forum
May 30, 2024, 06:43:08 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Finding better browser support for JavaScript wallets  (Read 459 times)
jcalfee1 (OP)
Newbie
*
Offline Offline

Activity: 1
Merit: 0


View Profile
February 14, 2014, 09:31:58 PM
 #1

Pure open-source JavaScript wallets can offer the user some benefits.  Aside from ease of install and upgrade, the user can be sure the program has limited access to there system and data.  With so many coin implementations this becomes more important.  Finally, any private keys can be stored locally keeping those off of the server.  In fact, when it comes down to it you really don't need a server at all just a place to securely host the files.

Due to the same origin policy, it is not practical for JavaScript code running in a browser to connect other servers (other than the server hosting the JavaScript). This makes writing pure JavaScript block-chain clients very difficult and no-doubt has an indirect effect on the price of my coins.   Cool  It is basically standard now to remove all central points of failure.  This means that a JavaScript wallet should be mirrored and ran anywhere and not have to use a dedicated servers to work.  

Getting 200+ coins to put code into there servers may not work very well.  Those servers are however designed to accept and welcome connections from clients that want to connect to them. I don't see any reason to limit the JavaScript or impose special server-changes for this.

Instead of by-passing or work around the same origin policy, what about a permission enabling plug-in?  Java Policy files are a good example of how a permission file may limit or grant permissions to system resources.  Should there be a policy file that a user can view and optionally accept and deny individual permissions?  This is better than some mobile platforms where it is a limited accept or deny all..

In other words, permission to make direct JavaScript sockets to other hosts could be granted.  This would by-passing the need to use json or iframe tricks or the need for Cross-origin resource sharing (CORS).

Is there anything like this available?  What do we need to do to get a project like this going?  Isn't this better than expecting the servers to support CORS?
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!