Unhosted and Privly

[Sean McGregor]

Hello,

My name is Sean McGregor, I am the lead developer of a web privacy
project named Privly [1]. It is exciting to see the progress Remote
Storage/Unhosted has made since I met Jan at a conference in June (I
have been lurking for a while).

Following Privly's acceptance into the Google Summer of Code [2], I am
hoping to explore potential summer projects at the intersection of
Privly and Unhosted.

Privly is an application stack built to view private content in the
context of untrusted web pages.

Let me give you a specific example, but please note that the approach
is not tied to any specific website. When you open the webmail
provider Hushmail and encounter a specially formatted "Privly link," a
Privly browser extension injects a locally-served web application into
the context of Hushmail, which requests the link's referenced content
for inline viewing. Within this application you can provide advanced
privacy/security functionality since the same origin policy protects
your content from Hushmail.

This brings me to unhosted. The applications that are injected into
the page could potentially be any application that does not run
remotely served code. These applications currently support cleartext
storage and JavaScript encrypted storage (ZeroBin) [3], but we are
extending the application abstraction into a sort of Greasemonkey for
full-applications. This could potentially be used as a distribution
mechanism for Unhosted apps.

Basically, we want to make it easy for developers (and eventually
users) to download and store applications in their browser extensions,
which could then be viewed in the context of untrusted websites, or in
the case of most Unhosted apps, as the top document in the browser.

My goal in emailing is twofold,

1) I would like to discuss the feasibility of incorporating Unhosted
apps on the Privly application stack, and potentially work towards
collaborating on a GSoC project

2) Promote to potential GSoC students on the Unhosted list who are
interested in developing at the intersection of the two projects

Thanks for reading my wall of text!

Best,
Sean McGregor

[1] https://priv.ly/
[2] http://www.google-melange.com/gsoc/org/google/gsoc2013/privly
[3] Local storage of applications is currently on the Google Chrome extension.

--
Sean McGregor

Oregon State University, Department of Computer Science
Twitter: seanmcgregor
irc.freenode.net: smcgregor

[Michiel B. de Jong]

On 2013-04-14 01:28, Sean McGregor wrote:
> Hello,
>
> My name is Sean McGregor, I am the lead developer of a web privacy
> project named Privly [1]. It is exciting to see the progress Remote
> Storage/Unhosted has made since I met Jan at a conference in June (I
> have been lurking for a while).

hi, thanks for writing! nice to (virtually) meet you. :)

> Following Privly's acceptance into the Google Summer of Code [2], I
> am
> hoping to explore potential summer projects at the intersection of
> Privly and Unhosted.

great! we didn't apply for GSOC ourselves this year, but i would be
happy to help with supervision

> The applications that are injected into
> the page could potentially be any application that does not run
> remotely served code.

hm, what do you win by that? how would the application arrive at the
client if not from a URL?

> These applications currently support cleartext
> storage and JavaScript encrypted storage (ZeroBin) [3], but we are
> extending the application abstraction into a sort of Greasemonkey for
> full-applications. This could potentially be used as a distribution
> mechanism for Unhosted apps.

hm, wouldn't that amount to reinventing the web? how would your
distribution mechanism be better than DNS+TLS+HTTP distribution of the
app's source code?

> Basically, we want to make it easy for developers (and eventually
> users) to download and store applications in their browser
> extensions,
> which could then be viewed in the context of untrusted websites, or
> in
> the case of most Unhosted apps, as the top document in the browser.

hm, sort of like a bookmarklet? what type of applications would you run
in the context of an untrusted website, other than the priv.ly
extension?

when you run it as the top document, i don't see what you win compared
to just using a URL for the app, combined with appcache.

>
> My goal in emailing is twofold,
>
> 1) I would like to discuss the feasibility of incorporating Unhosted
> apps on the Privly application stack, and potentially work towards
> collaborating on a GSoC project

great!

> 2) Promote to potential GSoC students on the Unhosted list who are
> interested in developing at the intersection of the two projects

cool! i hope someone picks it up. in any case, let's keep talking about
the intersection of our projects!

i think there would also be an interesting intersection between priv.ly
and remotestorage. I couldn't really work out from
https://github.com/privly/privly-organization/wiki/Burrowing what the
exact API of the content server is. Does the extension speak https to
the content server? How does the extension discover the server to use,
is that configurable?

I think it would be interesting to see if you can make it possible to
specify your own remote storage server in the extension, and use that as
the content server. It would have to go into the "public/" part of the
user's remote storage account, so that other people can have access to
it if they know the URL.

I see the tasks of the content server are:


> 1. Store and permission content
> 2. Provide a web application to view content without an extension
> 3. Provide data management tools for one’s own content

the first one is already handled by the remotestorage spec (using
OAuth). for 2. you could develop an unhosted web app that pulls in the
data and nicely displays it. how does that work now if the receiver
doesn't have the extension? are they prompted to install the extension?

for 3. we already have tools, for instance
https://remotestorage-browser-nilclass.5apps.com/, so you would benefit
from that if you were to switch your content server to the remotestorage
protocol.

See also http://remotestorage.io/provide/


Cheers!
Michiel

[Sean McGregor]

Michiel,

Sorry if the threading is difficult to read, I responded inline below.

-Sean

On Tue, Apr 16, 2013 at 5:46 AM, Michiel B. de Jong
<anyt...@michielbdejong.com> wrote:
> On 2013-04-14 01:28, Sean McGregor wrote:
>>
>> Hello,
>>
>> My name is Sean McGregor, I am the lead developer of a web privacy
>> project named Privly [1]. It is exciting to see the progress Remote
>> Storage/Unhosted has made since I met Jan at a conference in June (I
>> have been lurking for a while).
>
>
> hi, thanks for writing! nice to (virtually) meet you. :)

Indeed! I may make it to Germany this summer which would hopefully
<strikethrough>virtually</strikethrough>.

>
>
>> Following Privly's acceptance into the Google Summer of Code [2], I am
>> hoping to explore potential summer projects at the intersection of
>> Privly and Unhosted.
>
>
> great! we didn't apply for GSOC ourselves this year, but i would be happy to
> help with supervision

You can "apply" to be a mentor on our GSOC org here if you like:
http://www.google-melange.com/gsoc/homepage/google/gsoc2013

We don't have our student allotment from Google yet so getting more
mentors could potentially increase the number of allotments. We'll
know more in the next phase of GSoC's 2013 rollout, and I would be
happy to include you in the discussion on project selection.

>
>
>> The applications that are injected into
>> the page could potentially be any application that does not run
>> remotely served code.
>
>
> hm, what do you win by that? how would the application arrive at the client
> if not from a URL?

The applications are currently distributed with the Chrome extension.
Hosting the code remotely in the case of Privly has a number of
drawbacks. One particularly bad one is load time since remote code
would require an additional request for every Privly-type link on the
host page, ex:

1. Load host page
2. Load remotely served injectable application as an iframe in the host page
3. Fetch content associated with the application's URL

So a locally served application eliminates the http request for the
injected application.

There are also a number of side benefits to incorporating the
applications directly into the extension, in particular, it has
beneficial security properties for Privly.

>
>
>> These applications currently support cleartext
>> storage and JavaScript encrypted storage (ZeroBin) [3], but we are
>> extending the application abstraction into a sort of Greasemonkey for
>> full-applications. This could potentially be used as a distribution
>> mechanism for Unhosted apps.
>
>
> hm, wouldn't that amount to reinventing the web? how would your distribution
> mechanism be better than DNS+TLS+HTTP distribution of the app's source code?

(reinventing the web) perhaps adding capabilities, but not removing
any of the current capabilities.

(distribution mechanism) The distribution mechanism is less useful if
you have a server you trust to deliver the expected code reliably and
securely. However, most users do not have their own application
servers, and countries are increasingly using state controlled ISPs to
block access to certain domains and ISPs. Distributing the content
amongst an ever-shifting set of content servers, and controlling the
code locally makes it more difficult to censor information.

Also, by storing the code locally we can guarantee that it will have
certain design elements like a randomly generated glyph which
identifies extension code in the context of unsafe host pages.

>
>
>> Basically, we want to make it easy for developers (and eventually
>> users) to download and store applications in their browser extensions,
>> which could then be viewed in the context of untrusted websites, or in
>> the case of most Unhosted apps, as the top document in the browser.
>
>
> hm, sort of like a bookmarklet? what type of applications would you run in
> the context of an untrusted website, other than the priv.ly extension?

Many different applications could find use cases within the context of
untrusted web applications, some examples are:

* Numerous cryptographic protocols, like PGP, OTR, etc
* Host-site specific applications. For instance, if Twitter doesn't
want Privly to run with more than 140 characters, then they could
exclude all Privly apps except ones that support a 140 character
preview.

>
> when you run it as the top document, i don't see what you win compared to
> just using a URL for the app, combined with appcache.

Unsophisticated users are not particularly strong in understanding
when they have successfully fetched the proper code, so it is more
difficult to protect users from themselves.

Also, the addition of an extension brings the potential for
applications to use the (in development) public key crypto that
integrates with the extension. Without stricter integration of apps
and extension, it is not possible to expose public key crypto
functionality. Security becomes too much of a moving target.

>
>
>>
>> My goal in emailing is twofold,
>>
>> 1) I would like to discuss the feasibility of incorporating Unhosted
>> apps on the Privly application stack, and potentially work towards
>> collaborating on a GSoC project
>
>
> great!
>
>
>> 2) Promote to potential GSoC students on the Unhosted list who are
>> interested in developing at the intersection of the two projects
>
>
> cool! i hope someone picks it up. in any case, let's keep talking about the
> intersection of our projects!

:)

>
> i think there would also be an interesting intersection between priv.ly and
> remotestorage. I couldn't really work out from
> https://github.com/privly/privly-organization/wiki/Burrowing what the exact
> API of the content server is. Does the extension speak https to the content
> server? How does the extension discover the server to use, is that
> configurable?

Content server selection is highly configurable on the Chrome
extension, but the Firefox extension is lagging behind.

Our content server is a "reference implementation," meaning it is
being built according to the design principles Privly gives rise to,
but it will not be tightly integrated with the extensions. I can send
you a developer account on the Alpha server if you want to play around
with it.

>
> I think it would be interesting to see if you can make it possible to
> specify your own remote storage server in the extension, and use that as the
> content server. It would have to go into the "public/" part of the user's
> remote storage account, so that other people can have access to it if they
> know the URL.

Do you have a recommendation for a server I could try this out with? I
want to figure out the contours of privacy and security at the
intersection of the Privly and Remote Storage.

If it is not in the public folder, it may still be useful. For
instance, if you want to use Facebook's timeline functionality to
record a series of non-public posts containing journal entries or
photos, you can post the links on Facebook without giving Facebook (or
anyone else) access. To be clear, I don't think you should do this
since it is preferable to work in an environment with greater user
control, but the point here is that you can mashup content and service
in interesting ways.

>
> I see the tasks of the content server are:
>
>
>> 1. Store and permission content
>> 2. Provide a web application to view content without an extension
>> 3. Provide data management tools for one’s own content
>
>
> the first one is already handled by the remotestorage spec (using OAuth).

One of the critical pieces of functionality in the reference
implementation is the ability to authorize content according to any
identity implemented on the server. For instance, we want to make it
easy to publish the same content to Facebook, Google+, Diaspora,
Twitter, etc, and allow all individuals who are friends, circles,
aspects, followers, etc have access. One of the GSoC "ideas" is to
build out this functionality, but it hasn't been fully specified
(yet). The current identities on the server are pretty simplistic
(verified email/domain, and IP address).

> for 2. you could develop an unhosted web app that pulls in the data and
> nicely displays it. how does that work now if the receiver doesn't have the
> extension? are they prompted to install the extension?

Many people will not post content behind a Privly-type link unless
their readers are able to view the content without an extension.
However, since the usability of the system comes from the browser
extension, every piece of content currently shows an "install the
extension" advertisement unless the extension is installed.

The apps are currently fully hosted by the content server, but we
should work to make them all available unhosted.

>
> for 3. we already have tools, for instance
> https://remotestorage-browser-nilclass.5apps.com/, so you would benefit from
> that if you were to switch your content server to the remotestorage
> protocol.
>
> See also http://remotestorage.io/provide/

Time for me to experiment!

>
>
> Cheers!
> Michiel
>
> --
>
> --- You received this message because you are subscribed to the Google
> Groups "Unhosted Web Apps" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to unhosted+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.