acmeattic-devel team mailing list archive

[Karthik Swaminathan Nagaraj <nkarthiks@xxxxxxxxx>]

I think that these assumptions and policies are okay for the design. If we
are able to think of a better model, we could incorporate it in the future.
I was thinking that if the web server itself is crafted as a separate
application from the server, it could be run by the user at a more trusted
local location.
Eg: I can run my own web server on my machine for accessing my files. I
still do not need to provide space but I still maintain all my security
guarantees if only "my" server handles my key.
If its small and portable, maybe we could even ship it with a small web
server - like the python web server!
The web application is there to anyway provide simple access to the files.

And the storage server would also be running a copy of the webserver for
those who want to use that functionality after understanding the risks.

On Mon, Jul 5, 2010 at 4:54 AM, Krishnan Parthasarathi <
mine.or.tea.re.pot@xxxxxxxxx> wrote:

> For this discussion, we assume AA server to be a web app listening on https
> port. Also there is no application running on the client to aid in
> maintaining
> local revisions. For alpha release 1, it will serve sync and download
> requests
> from the user accessing it via the appropriate urls in the browser.
>
> In a download request if user expects AA server to send the actual file
> contents (decrypted data) when he/she clicks on a file url, then we would
> need
> to entrust the server with the file's AES key and the contents for a small
> window of time. This is a cause of concern given that we assume the server
> software can be 'patched'.
>
> In a sync request, the user needs to send the newer version of the
> file(unencrypted) to the server along with its AES key. Here the assumption
> is
> that the user might not be able to encrypt data on his own. This is another
> scenario where the server has the key for a short period of time.
>
> These are the shortcomings Adi and me came up while discussing. From
> SpiderOak's technical articles<https://spideroak.com/engineering_matters#instant_access>we know that even they don't recommend people to
> use the web interface. So, we think we should go ahead and implement it and
> keep the user's warned about what happens when he uses the web interface.
>
>
> --
> Cheers,
> Krishnan Parthasarathi
>



-- 
Karthik