| Thread Previous • Date Previous • Date Next • Thread Next |
On Wed, Jul 14, 2010 at 12:26 AM, Aditya Manthramurthy <aditya.mmy@xxxxxxxxx> wrote:On Wednesday 14 July 2010 12:15 AM, krishnan parthasarathi wrote:The browser based client is being described as a firefox addon in the blueprint. The browser based client needs to be able to decrypt/encrypt data given the key from the client local filesystem and transmit messages to server using the message protocol we design. I think this can be done using Java Script. OTOH, a firefox addon is written only if you want to extend the functionality of the browser to perform extra functions. for eg, playing mp3, displaying pdf files, etc. Do we want to abstract our browser based client app as an extension of firefox's functionality?No, we do not need to abstract it as a browser extension. If we use Javascript, it will have to be served by a webserver - there is the issue of trusting this code. The difference with using a browser extension is that all the source code is available to the user, and so can be trusted. We can have clients implemented in JS, as a separate server application perhaps even running on a different server machine, etc, and other people can implement them too - exposing a server API just illustrates that all this is possible. I would however suggest that if we write a browser based client, it should be an extension, so that a user can trust it. -- Aditya.
On Wednesday 14 July 2010 01:21 AM, suren wrote (in response to above):
IMHO, Actually its the firefox plugin that is untrusted more than JS. A plugin has access to all site cookies and browser variables as it is part of the 'browser'. But the javascript can't really access anything other the browser data for the same serving url.
But Suren, I mean it from a source code perspective. The user can see the code to decide for herself to decide its trustworthiness - we of course publish the plugin's code.
On Wednesday 14 July 2010 12:48 AM, krishnan parthasarathi wrote:
On Wed, Jul 14, 2010 at 12:26 AM, Aditya Manthramurthy <aditya.mmy@xxxxxxxxx <mailto:aditya.mmy@xxxxxxxxx>> wrote:No, we do not need to abstract it as a browser extension. If we use Javascript, it will have to be served by a webserver - there is the issue of trusting this code.JavaScript (JS) code can be viewed at client side. Being addon doesn't make the app any trust-worthy. The addon still needs to be separately 'signed' by us.
I was always saying from the perspective of us writing it.
The difference with using a browser extension is that all the
source code is available to the user, and so can be trusted.
Where is the addon's code (that is currently running) available to the
user?
The addon only runs code "that was added" when the plugin was installed on the browser. Of course, it is separately required for the addon's source to be open as well. But that is a given, if we write it. So source code is visible.
I would however suggest that if we write a browser based client, it should be an extension, so that a user can trust it.Writing browser based client to me means that we are using HTML to display data from the server at the client side. This can be done using JS. The JS code runs on the client side on the firefox's JS interpreter's process context. If we were to write an extension, it would mean that we are expanding firefox's capabilities to act as a client to our server app as well. This is not what we want to do. I hope I am clear.
I can see what you mean. We can still squabble over it and decide to write one for what we want ourselves, but more importantly, we should give it less importance, now right? I mean its just an alternate channel to access data. The main mode of access ought to be the native app.
-- Aditya.
| Thread Previous • Date Previous • Date Next • Thread Next |
