[freenet-dev] Unhosted web apps over Freenet: Restricted API for WoT-based Javascript was Re: [unhosted] Unhosted and Freenet Project

[Arne Babenhauserheide]

On Thursday 10 March 2011 19:06:46 Michiel de Jong wrote:
> Still, since you're already distributing the web app, i don't see so much
> added advantage in separating the app from the data (which is what unhosted
> is all about). it makes sense to put javascript into freenet extension, but
> not so much putting it into unhosted web apps, i think?

I think it makes sense, if you define a common (safe) API for retrieving the 
data. It would make it possible to integrate freenet-backed (censorship-
resistant) services in other websites which people can easily migrate from 
site to site. 

What would be even better: An API for the web-app, but also an API for 
retrieving and synchronizing the raw data for alternate hosting solutions. 
Then if a site goes down, the forst step would be to integrate the web-app on 
another site using freenet as backend, and the second step would be to grab 
the full dataset from freenet and setup a new backend server. 

Freenet would then be the censorship resistant fallback.

Best wishes, 
Arne
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 316 bytes
Desc: This is a digitally signed message part.
URL: 

Re: [freenet-dev] Unhosted web apps over Freenet: Restricted API for WoT-based Javascript was Re: [unhosted] Unhosted and Freenet Project

[Arne Babenhauserheide]

On Thursday 10 March 2011 19:06:46 Michiel de Jong wrote:
 Still, since you're already distributing the web app, i don't see so much
 added advantage in separating the app from the data (which is what unhosted
 is all about). it makes sense to put javascript into freenet extension, but
 not so much putting it into unhosted web apps, i think?

I think it makes sense, if you define a common (safe) API for retrieving the 
data. It would make it possible to integrate freenet-backed (censorship-
resistant) services in other websites which people can easily migrate from 
site to site. 

What would be even better: An API for the web-app, but also an API for 
retrieving and synchronizing the raw data for alternate hosting solutions. 
Then if a site goes down, the forst step would be to integrate the web-app on 
another site using freenet as backend, and the second step would be to grab 
the full dataset from freenet and setup a new backend server. 

Freenet would then be the censorship resistant fallback.

Best wishes, 
Arne

signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Unhosted web apps over Freenet: Restricted API for WoT-based Javascript was Re: [unhosted] Unhosted and Freenet Project

[Michiel de Jong]

On Sat, Mar 5, 2011 at 4:49 PM, Arne Babenhauserheide wrote:

> On Monday 14 February 2011 09:08:28 Michiel de Jong wrote:
> > I may remember this incorrectly, but I think when I tried out freenet,
> it's
> > a desktop application, and not a localhost http service, right?
>
> Freenet is a localhost http-service. I already used it remotely quite often
> by
> just tunnelling the port via SSH to another computer.
>
> It uses public keys for identifying pseudonyms, and it automatically
> loadbalances popular data (which is much faster than seldomly requested
> data).
>
> Also there already is an example of a Javascript-based App on Freenet with
> a
> freenet extension as data provider (Sone, still experimental but already a
> cool twitter/identi.ca replacement).
>
> ? http://127.0.0.1:/USK at nwa8lHa271k2QvJ8aa0Ov7IHAV-
>
> DFOCFgmDt3X6BpCI,DuQSUZiI~agF8c-6tjsFFGuZ8eICrzWCILB60nT8KKo,AQACAAE/sone/28/
>
> So it might be possible to create an unhosted freenet extension which
> allows
> using freenet as data server which the unhosted Javascript applications on
> websites could use.
>

Still, since you're already distributing the web app, i don't see so much
added advantage in separating the app from the data (which is what unhosted
is all about). it makes sense to put javascript into freenet extension, but
not so much putting it into unhosted web apps, i think?


>
> Best wishes,
> Arne
-- next part --
An HTML attachment was scrubbed...
URL: 

Re: [freenet-dev] Unhosted web apps over Freenet: Restricted API for WoT-based Javascript was Re: [unhosted] Unhosted and Freenet Project

[Michiel de Jong]

On Sat, Mar 5, 2011 at 4:49 PM, Arne Babenhauserheide arne_...@web.dewrote:

 On Monday 14 February 2011 09:08:28 Michiel de Jong wrote:
  I may remember this incorrectly, but I think when I tried out freenet,
 it's
  a desktop application, and not a localhost http service, right?

 Freenet is a localhost http-service. I already used it remotely quite often
 by
 just tunnelling the port via SSH to another computer.

 It uses public keys for identifying pseudonyms, and it automatically
 loadbalances popular data (which is much faster than seldomly requested
 data).

 Also there already is an example of a Javascript-based App on Freenet with
 a
 freenet extension as data provider (Sone, still experimental but already a
 cool twitter/identi.ca replacement).

 → http://127.0.0.1:/USK@nwa8lHa271k2QvJ8aa0Ov7IHAV-

 DFOCFgmDt3X6BpCI,DuQSUZiI~agF8c-6tjsFFGuZ8eICrzWCILB60nT8KKo,AQACAAE/sone/28/

 So it might be possible to create an unhosted freenet extension which
 allows
 using freenet as data server which the unhosted Javascript applications on
 websites could use.


Still, since you're already distributing the web app, i don't see so much
added advantage in separating the app from the data (which is what unhosted
is all about). it makes sense to put javascript into freenet extension, but
not so much putting it into unhosted web apps, i think?



 Best wishes,
 Arne
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Unhosted web apps over Freenet: Restricted API for WoT-based Javascript was Re: [unhosted] Unhosted and Freenet Project

[Arne Babenhauserheide]

On Monday 14 February 2011 09:08:28 Michiel de Jong wrote:
> I may remember this incorrectly, but I think when I tried out freenet, it's
> a desktop application, and not a localhost http service, right? 

Freenet is a localhost http-service. I already used it remotely quite often by 
just tunnelling the port via SSH to another computer. 

It uses public keys for identifying pseudonyms, and it automatically 
loadbalances popular data (which is much faster than seldomly requested data). 

Also there already is an example of a Javascript-based App on Freenet with a 
freenet extension as data provider (Sone, still experimental but already a 
cool twitter/identi.ca replacement). 

? http://127.0.0.1:/USK at nwa8lHa271k2QvJ8aa0Ov7IHAV-
DFOCFgmDt3X6BpCI,DuQSUZiI~agF8c-6tjsFFGuZ8eICrzWCILB60nT8KKo,AQACAAE/sone/28/

So it might be possible to create an unhosted freenet extension which allows 
using freenet as data server which the unhosted Javascript applications on 
websites could use. 

Best wishes, 
Arne
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 316 bytes
Desc: This is a digitally signed message part.
URL: 

Re: [freenet-dev] Unhosted web apps over Freenet: Restricted API for WoT-based Javascript was Re: [unhosted] Unhosted and Freenet Project

[Arne Babenhauserheide]

On Monday 14 February 2011 09:08:28 Michiel de Jong wrote:
 I may remember this incorrectly, but I think when I tried out freenet, it's
 a desktop application, and not a localhost http service, right?

Freenet is a localhost http-service. I already used it remotely quite often by
just tunnelling the port via SSH to another computer.

It uses public keys for identifying pseudonyms, and it automatically
loadbalances popular data (which is much faster than seldomly requested data).

Also there already is an example of a Javascript-based App on Freenet with a
freenet extension as data provider (Sone, still experimental but already a
cool twitter/identi.ca replacement).

→ http://127.0.0.1:/USK@nwa8lHa271k2QvJ8aa0Ov7IHAV-
DFOCFgmDt3X6BpCI,DuQSUZiI~agF8c-6tjsFFGuZ8eICrzWCILB60nT8KKo,AQACAAE/sone/28/

So it might be possible to create an unhosted freenet extension which allows
using freenet as data server which the unhosted Javascript applications on
websites could use.

Best wishes,
Arne

signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Unhosted web apps over Freenet: Restricted API for WoT-based Javascript was Re: [unhosted] Unhosted and Freenet Project

[Matthew Toseland]

On Tuesday 01 Mar 2011 17:44:33 Michiel de Jong wrote:
> Hi Matthew,
> 
> Sorry to take so long to reply, it's been a bit hectic for me these days.
> 
> On Thu, Feb 24, 2011 at 5:06 PM, Matthew Toseland  amphibian.dyndns.org
> > wrote:
> 
> > Okay, we've clearly gone off in different directions.
> >
> not necessarily, i think i just didn't fully understand what you were
> proposing, which made we talk about irrelevant things.
> 
> > To address your question first:
> >
> > A purely in-browser implementation of Freenet is probably possible, with
> > the cross domain authorisation stuff. On opennet it might work acceptably
> > while the number of fixed nodes remains much higher than the number of
> > browser nodes, but adding a lot of very low uptime nodes would definitely be
> > a problem - and even more so if they have little storage (how much storage
> > can you access from such an application?) On darknet it would be even worse:
> > Freenet in darknet mode only routes through your friends, and possibly
> > friends of friends. This means they have to be online at the same time as
> > you are.
> >
> > Also IP address detection might be a pain, depending on security settings.
> >
> > I take it there is no way to circumvent the uptime requirement? Freenet in
> > a browser would only run for as long as a browser window was open with
> > Freenet on it. And it certainly wouldn't run when the browser wasn't
> > running.
> >
> > If opennet has a long-term future it might be worth thinking about, but
> > even then the uptime would be a problem. If as I believe currently opennet
> > has no future it is pointless.
> >
> ok, i think we can agree we don't want to run freenet nodes inside browsers.
> my thought of offering freenet as an unhosted service is also pointless,
> because if you have, say, a freedombox, or a commodity host, running freenet
> for you, then you might as well point your browser straight at it instead of
> pointinf your browser at some intermediate unhosted web app, which then
> connects to it through cross-origin ajax. So let's skip to the other chain
> of thought.
> 
> > To answer my own chain of thought:
> >
> > Currently Freenet cannot allow any Javascript whatsoever. The hardest to
> > deal with reason for this is that if a browser app can fetch Freenet keys
> > and time them, and then upload what it finds out, it can compromise the
> > user. For instance, it could try to work out where on the keyspace the user
> > is by trying fetches of different keys, and it could try to identify what
> > chat boards the user uses, what users they trust, and possibly even their
> > own identity, by downloading messages from them. Likewise with freesites
> > (freenet-hosted websites). Put all this data together and you have a
> > detailed profile of a user which is very dangerous.
> >
> > I had thought maybe we could avoid this by only allowing javascript apps to
> > fetch data from per-user and possibly per-app stores, and possibly requiring
> > that the user explicitly authorise each contact.
> >
> > However, on further analysis, any Javascript app will be able to open pages
> > in new windows, frames, images etc, and will be able to time these fetches.
> > If it can't that's not going to be very useful! We could limit it to some
> > small amount of resources from its own site but it would limit functionality
> > and cause other problems, and wouldn't entirely solve the problem ...
> 
> yes, if you start allowing javascript, there is no telling what people could
> put in there in terms of identity phishing so to speak.

Right. Unless there is a way to provided a restricted API that is useful and 
yet doesn't allow most of the dirty tricks. Which might be possible, and would 
likely be based on identities.
> 
> also, keep in mind that unhosted is nothing more than a browser trick. it's
> a trick to do something with your browser that would normally require you to
> install a desktop app or at least a browser plugin.
> 
> in freenet, you might not need to use this trick, since you have a 'proxy'
> between the user's browser and the content. whatever decentralization and
> encryption tricks unhosted could do inside the browser, can be done much
> more effectively in the freenet node.

Hmmm, true...
> 
> also, i guess freenet already solve the issues that unhosted could solve
> (freedom from monopolies).
> 
> does that make any sense?

Yeah. Thanks.
> 
> Cheers
> Michiel
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

Re: [freenet-dev] Unhosted web apps over Freenet: Restricted API for WoT-based Javascript was Re: [unhosted] Unhosted and Freenet Project

[Matthew Toseland]

On Tuesday 01 Mar 2011 17:44:33 Michiel de Jong wrote:
 Hi Matthew,
 
 Sorry to take so long to reply, it's been a bit hectic for me these days.
 
 On Thu, Feb 24, 2011 at 5:06 PM, Matthew Toseland t...@amphibian.dyndns.org
  wrote:
 
  Okay, we've clearly gone off in different directions.
 
 not necessarily, i think i just didn't fully understand what you were
 proposing, which made we talk about irrelevant things.
 
  To address your question first:
 
  A purely in-browser implementation of Freenet is probably possible, with
  the cross domain authorisation stuff. On opennet it might work acceptably
  while the number of fixed nodes remains much higher than the number of
  browser nodes, but adding a lot of very low uptime nodes would definitely be
  a problem - and even more so if they have little storage (how much storage
  can you access from such an application?) On darknet it would be even worse:
  Freenet in darknet mode only routes through your friends, and possibly
  friends of friends. This means they have to be online at the same time as
  you are.
 
  Also IP address detection might be a pain, depending on security settings.
 
  I take it there is no way to circumvent the uptime requirement? Freenet in
  a browser would only run for as long as a browser window was open with
  Freenet on it. And it certainly wouldn't run when the browser wasn't
  running.
 
  If opennet has a long-term future it might be worth thinking about, but
  even then the uptime would be a problem. If as I believe currently opennet
  has no future it is pointless.
 
 ok, i think we can agree we don't want to run freenet nodes inside browsers.
 my thought of offering freenet as an unhosted service is also pointless,
 because if you have, say, a freedombox, or a commodity host, running freenet
 for you, then you might as well point your browser straight at it instead of
 pointinf your browser at some intermediate unhosted web app, which then
 connects to it through cross-origin ajax. So let's skip to the other chain
 of thought.
 
  To answer my own chain of thought:
 
  Currently Freenet cannot allow any Javascript whatsoever. The hardest to
  deal with reason for this is that if a browser app can fetch Freenet keys
  and time them, and then upload what it finds out, it can compromise the
  user. For instance, it could try to work out where on the keyspace the user
  is by trying fetches of different keys, and it could try to identify what
  chat boards the user uses, what users they trust, and possibly even their
  own identity, by downloading messages from them. Likewise with freesites
  (freenet-hosted websites). Put all this data together and you have a
  detailed profile of a user which is very dangerous.
 
  I had thought maybe we could avoid this by only allowing javascript apps to
  fetch data from per-user and possibly per-app stores, and possibly requiring
  that the user explicitly authorise each contact.
 
  However, on further analysis, any Javascript app will be able to open pages
  in new windows, frames, images etc, and will be able to time these fetches.
  If it can't that's not going to be very useful! We could limit it to some
  small amount of resources from its own site but it would limit functionality
  and cause other problems, and wouldn't entirely solve the problem ...
 
 yes, if you start allowing javascript, there is no telling what people could
 put in there in terms of identity phishing so to speak.

Right. Unless there is a way to provided a restricted API that is useful and 
yet doesn't allow most of the dirty tricks. Which might be possible, and would 
likely be based on identities.
 
 also, keep in mind that unhosted is nothing more than a browser trick. it's
 a trick to do something with your browser that would normally require you to
 install a desktop app or at least a browser plugin.
 
 in freenet, you might not need to use this trick, since you have a 'proxy'
 between the user's browser and the content. whatever decentralization and
 encryption tricks unhosted could do inside the browser, can be done much
 more effectively in the freenet node.

Hmmm, true...
 
 also, i guess freenet already solve the issues that unhosted could solve
 (freedom from monopolies).
 
 does that make any sense?

Yeah. Thanks.
 
 Cheers
 Michiel


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Unhosted web apps over Freenet: Restricted API for WoT-based Javascript was Re: [unhosted] Unhosted and Freenet Project

[Michiel de Jong]

Hi Matthew,

Sorry to take so long to reply, it's been a bit hectic for me these days.

On Thu, Feb 24, 2011 at 5:06 PM, Matthew Toseland  wrote:

> Okay, we've clearly gone off in different directions.
>
>
not necessarily, i think i just didn't fully understand what you were
proposing, which made we talk about irrelevant things.


>
> To address your question first:
>
> A purely in-browser implementation of Freenet is probably possible, with
> the cross domain authorisation stuff. On opennet it might work acceptably
> while the number of fixed nodes remains much higher than the number of
> browser nodes, but adding a lot of very low uptime nodes would definitely be
> a problem - and even more so if they have little storage (how much storage
> can you access from such an application?) On darknet it would be even worse:
> Freenet in darknet mode only routes through your friends, and possibly
> friends of friends. This means they have to be online at the same time as
> you are.
>
> Also IP address detection might be a pain, depending on security settings.
>
> I take it there is no way to circumvent the uptime requirement? Freenet in
> a browser would only run for as long as a browser window was open with
> Freenet on it. And it certainly wouldn't run when the browser wasn't
> running.
>
> If opennet has a long-term future it might be worth thinking about, but
> even then the uptime would be a problem. If as I believe currently opennet
> has no future it is pointless.
>
>
ok, i think we can agree we don't want to run freenet nodes inside browsers.
my thought of offering freenet as an unhosted service is also pointless,
because if you have, say, a freedombox, or a commodity host, running freenet
for you, then you might as well point your browser straight at it instead of
pointinf your browser at some intermediate unhosted web app, which then
connects to it through cross-origin ajax. So let's skip to the other chain
of thought.


>
> To answer my own chain of thought:
>
> Currently Freenet cannot allow any Javascript whatsoever. The hardest to
> deal with reason for this is that if a browser app can fetch Freenet keys
> and time them, and then upload what it finds out, it can compromise the
> user. For instance, it could try to work out where on the keyspace the user
> is by trying fetches of different keys, and it could try to identify what
> chat boards the user uses, what users they trust, and possibly even their
> own identity, by downloading messages from them. Likewise with freesites
> (freenet-hosted websites). Put all this data together and you have a
> detailed profile of a user which is very dangerous.
>
> I had thought maybe we could avoid this by only allowing javascript apps to
> fetch data from per-user and possibly per-app stores, and possibly requiring
> that the user explicitly authorise each contact.
>
> However, on further analysis, any Javascript app will be able to open pages
> in new windows, frames, images etc, and will be able to time these fetches.
> If it can't that's not going to be very useful! We could limit it to some
> small amount of resources from its own site but it would limit functionality
> and cause other problems, and wouldn't entirely solve the problem ...
>

yes, if you start allowing javascript, there is no telling what people could
put in there in terms of identity phishing so to speak.

also, keep in mind that unhosted is nothing more than a browser trick. it's
a trick to do something with your browser that would normally require you to
install a desktop app or at least a browser plugin.

in freenet, you might not need to use this trick, since you have a 'proxy'
between the user's browser and the content. whatever decentralization and
encryption tricks unhosted could do inside the browser, can be done much
more effectively in the freenet node.

also, i guess freenet already solve the issues that unhosted could solve
(freedom from monopolies).

does that make any sense?


Cheers
Michiel
-- next part --
An HTML attachment was scrubbed...
URL: 

Re: [freenet-dev] Unhosted web apps over Freenet: Restricted API for WoT-based Javascript was Re: [unhosted] Unhosted and Freenet Project

[Michiel de Jong]

Hi Matthew,

Sorry to take so long to reply, it's been a bit hectic for me these days.

On Thu, Feb 24, 2011 at 5:06 PM, Matthew Toseland t...@amphibian.dyndns.org
 wrote:

 Okay, we've clearly gone off in different directions.


not necessarily, i think i just didn't fully understand what you were
proposing, which made we talk about irrelevant things.



 To address your question first:

 A purely in-browser implementation of Freenet is probably possible, with
 the cross domain authorisation stuff. On opennet it might work acceptably
 while the number of fixed nodes remains much higher than the number of
 browser nodes, but adding a lot of very low uptime nodes would definitely be
 a problem - and even more so if they have little storage (how much storage
 can you access from such an application?) On darknet it would be even worse:
 Freenet in darknet mode only routes through your friends, and possibly
 friends of friends. This means they have to be online at the same time as
 you are.

 Also IP address detection might be a pain, depending on security settings.

 I take it there is no way to circumvent the uptime requirement? Freenet in
 a browser would only run for as long as a browser window was open with
 Freenet on it. And it certainly wouldn't run when the browser wasn't
 running.

 If opennet has a long-term future it might be worth thinking about, but
 even then the uptime would be a problem. If as I believe currently opennet
 has no future it is pointless.


ok, i think we can agree we don't want to run freenet nodes inside browsers.
my thought of offering freenet as an unhosted service is also pointless,
because if you have, say, a freedombox, or a commodity host, running freenet
for you, then you might as well point your browser straight at it instead of
pointinf your browser at some intermediate unhosted web app, which then
connects to it through cross-origin ajax. So let's skip to the other chain
of thought.



 To answer my own chain of thought:

 Currently Freenet cannot allow any Javascript whatsoever. The hardest to
 deal with reason for this is that if a browser app can fetch Freenet keys
 and time them, and then upload what it finds out, it can compromise the
 user. For instance, it could try to work out where on the keyspace the user
 is by trying fetches of different keys, and it could try to identify what
 chat boards the user uses, what users they trust, and possibly even their
 own identity, by downloading messages from them. Likewise with freesites
 (freenet-hosted websites). Put all this data together and you have a
 detailed profile of a user which is very dangerous.

 I had thought maybe we could avoid this by only allowing javascript apps to
 fetch data from per-user and possibly per-app stores, and possibly requiring
 that the user explicitly authorise each contact.

 However, on further analysis, any Javascript app will be able to open pages
 in new windows, frames, images etc, and will be able to time these fetches.
 If it can't that's not going to be very useful! We could limit it to some
 small amount of resources from its own site but it would limit functionality
 and cause other problems, and wouldn't entirely solve the problem ...


yes, if you start allowing javascript, there is no telling what people could
put in there in terms of identity phishing so to speak.

also, keep in mind that unhosted is nothing more than a browser trick. it's
a trick to do something with your browser that would normally require you to
install a desktop app or at least a browser plugin.

in freenet, you might not need to use this trick, since you have a 'proxy'
between the user's browser and the content. whatever decentralization and
encryption tricks unhosted could do inside the browser, can be done much
more effectively in the freenet node.

also, i guess freenet already solve the issues that unhosted could solve
(freedom from monopolies).

does that make any sense?


Cheers
Michiel
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Unhosted web apps over Freenet: Restricted API for WoT-based Javascript was Re: [unhosted] Unhosted and Freenet Project

[Matthew Toseland]

On Monday 14 Feb 2011 08:08:28 Michiel de Jong wrote:
> I thought about this some more, and I think it doesn't make sense to
> distribute applications over freenet. Rather I think the JavaScript
> application should be like a viewer application, and the unhosted storage
> node could do freenet-node/server task of keeping data alive and anonymizing
> requests. So basically, move your freenet node to your plugserver (which is
> always-on), and access it through http rather than as a desktop application.
> 
> But since you then already have a http interface on the freenet node, and
> also you don't want to connect to other identifiable freenet-nodes from your
> browser, without routing through somewhere else, you might as well use that
> directly as the application you browse to, instead of using an unhosted web
> app somewhere to access your freenet node, or even accessing your own one
> and those of your friends.
> 
> I may remember this incorrectly, but I think when I tried out freenet, it's
> a desktop application, and not a localhost http service, right? Is there
> also a mode to run the node as a server and use a standard browser as a
> client to it? If you have that, then it would be easy to move the node to a
> plugserver, where it is always-on, and in your home. Is that already
> possible right now with freenet?

Freenet is a localhost HTTP service. We provide some native stuff for 
convenience' sake to open a browser in privacy mode.

And yes we could serve javascript applications from Freenet's web interface. 
The catch is I don't see any way to sandbox them properly. It looks like we 
could provide (something like?) the Unhosted API and enable Javascript 
applications as well as our Java-level plugins, on the basis that the user 
trusts the coder?
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

[freenet-dev] Unhosted web apps over Freenet: Restricted API for WoT-based Javascript was Re: [unhosted] Unhosted and Freenet Project

[Matthew Toseland]

On Sunday 13 Feb 2011 21:30:13 Michiel de Jong wrote:
> On Sat, Feb 12, 2011 at 8:32 PM, Matthew Toseland  amphibian.dyndns.org
> > wrote:
> 
> > I wonder if we could build a usable sandbox based on Unhosted principles,
> > i.e. an app can download and upload data specific to its user, and can talk
> > to other users. We could even provide a confirmation mechanism per-user for
> > more paranoid users, which could smoothly integrate into the app's UI if we
> > are really good, including CAPTCHA-based introductions ... h, there
> > could be something in this ... might need API changes though, how do you
> > deal with introductions now?
> 
> Unhosted only defines that you use 'some' discovery mechanism to find 'some'
> user-specific web service. The two user-specific web services we have
> defined so far, are a per-user key-value store, in which anyone who the
> key-name is able to read its value, and per-user message queues, in which
> anyone is able to send a message to anyone.
> 
> Each application can then decide to implement its own concept of friendship
> and introductions, and not display any messages from strangers.

The app will need to decide which users' web services to fetch from.
> 
> > Such principles may be valuable to Freenet even if we have to break
> > compatibility with Unhosted... Thoughts?
> 
> Right now, we only have one resource discovery mechanism, and that is based
> on email addresses. So one big difference between unhosted and freenet right
> there is that all data is per-user. There has been talk about
> content-addressable resources, for instance for supporting the DHT of
> Seeks-project, but it is as yet hard to oversee freeloading problems that
> this could bring.
> 
> I think we should be very aware of what we're trying to achieve when we
> consider combining unhosted and freenet. I think that would be doing freenet
> in the browser, right? I heard of the Veiled project which tried to do
> (something like) this two years ago, but it seems that HP have taken down
> the link?
> http://www.cio.com/article/498566/HP_Researchers_Say_Browser_Based_Veiled_Make_Darknets_a_Snap
> 
> Does anyone know what happened there? What issues did they encounter? We
> might learn a lot from them there. We could find out, and see if we can
> resume or redo that project, maybe.

Okay, we've clearly gone off in different directions.


To address your question first:

A purely in-browser implementation of Freenet is probably possible, with the 
cross domain authorisation stuff. On opennet it might work acceptably while the 
number of fixed nodes remains much higher than the number of browser nodes, but 
adding a lot of very low uptime nodes would definitely be a problem - and even 
more so if they have little storage (how much storage can you access from such 
an application?) On darknet it would be even worse: Freenet in darknet mode 
only routes through your friends, and possibly friends of friends. This means 
they have to be online at the same time as you are.

Also IP address detection might be a pain, depending on security settings.

I take it there is no way to circumvent the uptime requirement? Freenet in a 
browser would only run for as long as a browser window was open with Freenet on 
it. And it certainly wouldn't run when the browser wasn't running.

If opennet has a long-term future it might be worth thinking about, but even 
then the uptime would be a problem. If as I believe currently opennet has no 
future it is pointless.


To answer my own chain of thought:

Currently Freenet cannot allow any Javascript whatsoever. The hardest to deal 
with reason for this is that if a browser app can fetch Freenet keys and time 
them, and then upload what it finds out, it can compromise the user. For 
instance, it could try to work out where on the keyspace the user is by trying 
fetches of different keys, and it could try to identify what chat boards the 
user uses, what users they trust, and possibly even their own identity, by 
downloading messages from them. Likewise with freesites (freenet-hosted 
websites). Put all this data together and you have a detailed profile of a user 
which is very dangerous.

I had thought maybe we could avoid this by only allowing javascript apps to 
fetch data from per-user and possibly per-app stores, and possibly requiring 
that the user explicitly authorise each contact.

However, on further analysis, any Javascript app will be able to open pages in 
new windows, frames, images etc, and will be able to time these fetches. If it 
can't that's not going to be very useful! We could limit it to some small 
amount of resources from its own site but it would limit functionality and 
cause other problems, and wouldn't entirely solve the problem ...
> 
> 
> Cheers!
> Michiel.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.

Re: [freenet-dev] Unhosted web apps over Freenet: Restricted API for WoT-based Javascript was Re: [unhosted] Unhosted and Freenet Project

[Matthew Toseland]

On Sunday 13 Feb 2011 21:30:13 Michiel de Jong wrote:
 On Sat, Feb 12, 2011 at 8:32 PM, Matthew Toseland t...@amphibian.dyndns.org
  wrote:
 
  I wonder if we could build a usable sandbox based on Unhosted principles,
  i.e. an app can download and upload data specific to its user, and can talk
  to other users. We could even provide a confirmation mechanism per-user for
  more paranoid users, which could smoothly integrate into the app's UI if we
  are really good, including CAPTCHA-based introductions ... h, there
  could be something in this ... might need API changes though, how do you
  deal with introductions now?
 
 Unhosted only defines that you use 'some' discovery mechanism to find 'some'
 user-specific web service. The two user-specific web services we have
 defined so far, are a per-user key-value store, in which anyone who the
 key-name is able to read its value, and per-user message queues, in which
 anyone is able to send a message to anyone.
 
 Each application can then decide to implement its own concept of friendship
 and introductions, and not display any messages from strangers.

The app will need to decide which users' web services to fetch from.
 
  Such principles may be valuable to Freenet even if we have to break
  compatibility with Unhosted... Thoughts?
 
 Right now, we only have one resource discovery mechanism, and that is based
 on email addresses. So one big difference between unhosted and freenet right
 there is that all data is per-user. There has been talk about
 content-addressable resources, for instance for supporting the DHT of
 Seeks-project, but it is as yet hard to oversee freeloading problems that
 this could bring.
 
 I think we should be very aware of what we're trying to achieve when we
 consider combining unhosted and freenet. I think that would be doing freenet
 in the browser, right? I heard of the Veiled project which tried to do
 (something like) this two years ago, but it seems that HP have taken down
 the link?
 http://www.cio.com/article/498566/HP_Researchers_Say_Browser_Based_Veiled_Make_Darknets_a_Snap
 
 Does anyone know what happened there? What issues did they encounter? We
 might learn a lot from them there. We could find out, and see if we can
 resume or redo that project, maybe.

Okay, we've clearly gone off in different directions.


To address your question first:

A purely in-browser implementation of Freenet is probably possible, with the 
cross domain authorisation stuff. On opennet it might work acceptably while the 
number of fixed nodes remains much higher than the number of browser nodes, but 
adding a lot of very low uptime nodes would definitely be a problem - and even 
more so if they have little storage (how much storage can you access from such 
an application?) On darknet it would be even worse: Freenet in darknet mode 
only routes through your friends, and possibly friends of friends. This means 
they have to be online at the same time as you are.

Also IP address detection might be a pain, depending on security settings.

I take it there is no way to circumvent the uptime requirement? Freenet in a 
browser would only run for as long as a browser window was open with Freenet on 
it. And it certainly wouldn't run when the browser wasn't running.

If opennet has a long-term future it might be worth thinking about, but even 
then the uptime would be a problem. If as I believe currently opennet has no 
future it is pointless.


To answer my own chain of thought:

Currently Freenet cannot allow any Javascript whatsoever. The hardest to deal 
with reason for this is that if a browser app can fetch Freenet keys and time 
them, and then upload what it finds out, it can compromise the user. For 
instance, it could try to work out where on the keyspace the user is by trying 
fetches of different keys, and it could try to identify what chat boards the 
user uses, what users they trust, and possibly even their own identity, by 
downloading messages from them. Likewise with freesites (freenet-hosted 
websites). Put all this data together and you have a detailed profile of a user 
which is very dangerous.

I had thought maybe we could avoid this by only allowing javascript apps to 
fetch data from per-user and possibly per-app stores, and possibly requiring 
that the user explicitly authorise each contact.

However, on further analysis, any Javascript app will be able to open pages in 
new windows, frames, images etc, and will be able to time these fetches. If it 
can't that's not going to be very useful! We could limit it to some small 
amount of resources from its own site but it would limit functionality and 
cause other problems, and wouldn't entirely solve the problem ...
 
 
 Cheers!
 Michiel.


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Unhosted web apps over Freenet: Restricted API for WoT-based Javascript was Re: [unhosted] Unhosted and Freenet Project

[Matthew Toseland]

On Monday 14 Feb 2011 08:08:28 Michiel de Jong wrote:
 I thought about this some more, and I think it doesn't make sense to
 distribute applications over freenet. Rather I think the JavaScript
 application should be like a viewer application, and the unhosted storage
 node could do freenet-node/server task of keeping data alive and anonymizing
 requests. So basically, move your freenet node to your plugserver (which is
 always-on), and access it through http rather than as a desktop application.
 
 But since you then already have a http interface on the freenet node, and
 also you don't want to connect to other identifiable freenet-nodes from your
 browser, without routing through somewhere else, you might as well use that
 directly as the application you browse to, instead of using an unhosted web
 app somewhere to access your freenet node, or even accessing your own one
 and those of your friends.
 
 I may remember this incorrectly, but I think when I tried out freenet, it's
 a desktop application, and not a localhost http service, right? Is there
 also a mode to run the node as a server and use a standard browser as a
 client to it? If you have that, then it would be easy to move the node to a
 plugserver, where it is always-on, and in your home. Is that already
 possible right now with freenet?

Freenet is a localhost HTTP service. We provide some native stuff for 
convenience' sake to open a browser in privacy mode.

And yes we could serve javascript applications from Freenet's web interface. 
The catch is I don't see any way to sandbox them properly. It looks like we 
could provide (something like?) the Unhosted API and enable Javascript 
applications as well as our Java-level plugins, on the basis that the user 
trusts the coder?


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Unhosted web apps over Freenet: Restricted API for WoT-based Javascript was Re: [unhosted] Unhosted and Freenet Project

[Michiel de Jong]

I thought about this some more, and I think it doesn't make sense to
distribute applications over freenet. Rather I think the JavaScript
application should be like a viewer application, and the unhosted storage
node could do freenet-node/server task of keeping data alive and anonymizing
requests. So basically, move your freenet node to your plugserver (which is
always-on), and access it through http rather than as a desktop application.

But since you then already have a http interface on the freenet node, and
also you don't want to connect to other identifiable freenet-nodes from your
browser, without routing through somewhere else, you might as well use that
directly as the application you browse to, instead of using an unhosted web
app somewhere to access your freenet node, or even accessing your own one
and those of your friends.

I may remember this incorrectly, but I think when I tried out freenet, it's
a desktop application, and not a localhost http service, right? Is there
also a mode to run the node as a server and use a standard browser as a
client to it? If you have that, then it would be easy to move the node to a
plugserver, where it is always-on, and in your home. Is that already
possible right now with freenet?


Cheers,
Michiel
-- next part --
An HTML attachment was scrubbed...
URL: 

Re: [freenet-dev] Unhosted web apps over Freenet: Restricted API for WoT-based Javascript was Re: [unhosted] Unhosted and Freenet Project

[Michiel de Jong]

I thought about this some more, and I think it doesn't make sense to
distribute applications over freenet. Rather I think the JavaScript
application should be like a viewer application, and the unhosted storage
node could do freenet-node/server task of keeping data alive and anonymizing
requests. So basically, move your freenet node to your plugserver (which is
always-on), and access it through http rather than as a desktop application.

But since you then already have a http interface on the freenet node, and
also you don't want to connect to other identifiable freenet-nodes from your
browser, without routing through somewhere else, you might as well use that
directly as the application you browse to, instead of using an unhosted web
app somewhere to access your freenet node, or even accessing your own one
and those of your friends.

I may remember this incorrectly, but I think when I tried out freenet, it's
a desktop application, and not a localhost http service, right? Is there
also a mode to run the node as a server and use a standard browser as a
client to it? If you have that, then it would be easy to move the node to a
plugserver, where it is always-on, and in your home. Is that already
possible right now with freenet?


Cheers,
Michiel
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Unhosted web apps over Freenet: Restricted API for WoT-based Javascript was Re: [unhosted] Unhosted and Freenet Project

[Michiel de Jong]

On Sat, Feb 12, 2011 at 8:32 PM, Matthew Toseland  wrote:

> I wonder if we could build a usable sandbox based on Unhosted principles,
> i.e. an app can download and upload data specific to its user, and can talk
> to other users. We could even provide a confirmation mechanism per-user for
> more paranoid users, which could smoothly integrate into the app's UI if we
> are really good, including CAPTCHA-based introductions ... h, there
> could be something in this ... might need API changes though, how do you
> deal with introductions now?


Unhosted only defines that you use 'some' discovery mechanism to find 'some'
user-specific web service. The two user-specific web services we have
defined so far, are a per-user key-value store, in which anyone who the
key-name is able to read its value, and per-user message queues, in which
anyone is able to send a message to anyone.

Each application can then decide to implement its own concept of friendship
and introductions, and not display any messages from strangers.


> Such principles may be valuable to Freenet even if we have to break
> compatibility with Unhosted... Thoughts?
>

Right now, we only have one resource discovery mechanism, and that is based
on email addresses. So one big difference between unhosted and freenet right
there is that all data is per-user. There has been talk about
content-addressable resources, for instance for supporting the DHT of
Seeks-project, but it is as yet hard to oversee freeloading problems that
this could bring.

I think we should be very aware of what we're trying to achieve when we
consider combining unhosted and freenet. I think that would be doing freenet
in the browser, right? I heard of the Veiled project which tried to do
(something like) this two years ago, but it seems that HP have taken down
the link?
http://www.cio.com/article/498566/HP_Researchers_Say_Browser_Based_Veiled_Make_Darknets_a_Snap

Does anyone know what happened there? What issues did they encounter? We
might learn a lot from them there. We could find out, and see if we can
resume or redo that project, maybe.


Cheers!
Michiel.
-- next part --
An HTML attachment was scrubbed...
URL: 

Re: [freenet-dev] Unhosted web apps over Freenet: Restricted API for WoT-based Javascript was Re: [unhosted] Unhosted and Freenet Project

[Michiel de Jong]

On Sat, Feb 12, 2011 at 8:32 PM, Matthew Toseland t...@amphibian.dyndns.org
 wrote:

 I wonder if we could build a usable sandbox based on Unhosted principles,
 i.e. an app can download and upload data specific to its user, and can talk
 to other users. We could even provide a confirmation mechanism per-user for
 more paranoid users, which could smoothly integrate into the app's UI if we
 are really good, including CAPTCHA-based introductions ... h, there
 could be something in this ... might need API changes though, how do you
 deal with introductions now?


Unhosted only defines that you use 'some' discovery mechanism to find 'some'
user-specific web service. The two user-specific web services we have
defined so far, are a per-user key-value store, in which anyone who the
key-name is able to read its value, and per-user message queues, in which
anyone is able to send a message to anyone.

Each application can then decide to implement its own concept of friendship
and introductions, and not display any messages from strangers.


 Such principles may be valuable to Freenet even if we have to break
 compatibility with Unhosted... Thoughts?


Right now, we only have one resource discovery mechanism, and that is based
on email addresses. So one big difference between unhosted and freenet right
there is that all data is per-user. There has been talk about
content-addressable resources, for instance for supporting the DHT of
Seeks-project, but it is as yet hard to oversee freeloading problems that
this could bring.

I think we should be very aware of what we're trying to achieve when we
consider combining unhosted and freenet. I think that would be doing freenet
in the browser, right? I heard of the Veiled project which tried to do
(something like) this two years ago, but it seems that HP have taken down
the link?
http://www.cio.com/article/498566/HP_Researchers_Say_Browser_Based_Veiled_Make_Darknets_a_Snap

Does anyone know what happened there? What issues did they encounter? We
might learn a lot from them there. We could find out, and see if we can
resume or redo that project, maybe.


Cheers!
Michiel.
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Unhosted web apps over Freenet: Restricted API for WoT-based Javascript was Re: [unhosted] Unhosted and Freenet Project

[Matthew Toseland]

I apologise for replying before I at least had a proper look at the website! 
This is in fact fascinating and there may well be things we can do together or 
at least inspiration we can draw from one another.

Lets get detailed, technical, and concise, about what would be involved in 
Freenet working with Unhosted, as one of many options for transport etc. Sorry 
for the general waffle last time, it's worth reading though.

The basic principle of Unhosted from a freenet-ish angle is:
- Websites are static and therefore can be hosted absolutely anywhere.
- The website is a (large?) javascript applet. The client trusts the author of 
the website, within reason.
- Data is encrypted by the client.
- Data is stored on a separate storage server.
- CORS allows this (this requires relevant request headers)
- The PKI sounds very strange! On Freenet we always pass the hashes of the 
pubkeys... :|

Now, compare to Freenet:
- Freenet is reasonably good at hosting static content.
- It strips out javascript in order to preserve security. This happens at the 
fproxy level; if the app is trusted it could be whitelisted or something.
- Data is stored by clients for themselves, which is easy on Freenet, or it is 
routed between clients via queues, which is somewhat harder: Because of spam 
problems, we need to announce identities and establish a web of trust between 
them, or at least that's how current stuff works; we could use CAPTCHAs or some 
similar scarcity mechanism directly on a per message basis, but once a 
relationship is established it is unnecessary, and there are serious worries 
about the long term viability of CAPTCHAs.
- Your PKI sounds rather strange... We could probably provide a WoT-based 
lookup service and be API-compatible though...

There are some interesting sandboxing options. The big difficulty preventing 
Freenet from allowing Javascript is not the difficulty of writing a javascript 
filter (although that is a hard problem it is a solvable problem); it is the 
difficulty of defining a safe API for it to call. Freenet only provides request 
and insert - fetch and put - but with that alone, a malicious app author can do 
a lot of mischief. I wonder if we could build a usable sandbox based on 
Unhosted principles, i.e. an app can download and upload data specific to its 
user, and can talk to other users. We could even provide a confirmation 
mechanism per-user for more paranoid users, which could smoothly integrate into 
the app's UI if we are really good, including CAPTCHA-based introductions ... 
h, there could be something in this ... might need API changes though, how 
do you deal with introductions now? Such principles may be valuable to Freenet 
even if we have to break compatibility with Unhosted... Thoughts?
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

[freenet-dev] Unhosted web apps over Freenet: Restricted API for WoT-based Javascript was Re: [unhosted] Unhosted and Freenet Project

[Matthew Toseland]

I apologise for replying before I at least had a proper look at the website! 
This is in fact fascinating and there may well be things we can do together or 
at least inspiration we can draw from one another.

Lets get detailed, technical, and concise, about what would be involved in 
Freenet working with Unhosted, as one of many options for transport etc. Sorry 
for the general waffle last time, it's worth reading though.

The basic principle of Unhosted from a freenet-ish angle is:
- Websites are static and therefore can be hosted absolutely anywhere.
- The website is a (large?) javascript applet. The client trusts the author of 
the website, within reason.
- Data is encrypted by the client.
- Data is stored on a separate storage server.
- CORS allows this (this requires relevant request headers)
- The PKI sounds very strange! On Freenet we always pass the hashes of the 
pubkeys... :|

Now, compare to Freenet:
- Freenet is reasonably good at hosting static content.
- It strips out javascript in order to preserve security. This happens at the 
fproxy level; if the app is trusted it could be whitelisted or something.
- Data is stored by clients for themselves, which is easy on Freenet, or it is 
routed between clients via queues, which is somewhat harder: Because of spam 
problems, we need to announce identities and establish a web of trust between 
them, or at least that's how current stuff works; we could use CAPTCHAs or some 
similar scarcity mechanism directly on a per message basis, but once a 
relationship is established it is unnecessary, and there are serious worries 
about the long term viability of CAPTCHAs.
- Your PKI sounds rather strange... We could probably provide a WoT-based 
lookup service and be API-compatible though...

There are some interesting sandboxing options. The big difficulty preventing 
Freenet from allowing Javascript is not the difficulty of writing a javascript 
filter (although that is a hard problem it is a solvable problem); it is the 
difficulty of defining a safe API for it to call. Freenet only provides request 
and insert - fetch and put - but with that alone, a malicious app author can do 
a lot of mischief. I wonder if we could build a usable sandbox based on 
Unhosted principles, i.e. an app can download and upload data specific to its 
user, and can talk to other users. We could even provide a confirmation 
mechanism per-user for more paranoid users, which could smoothly integrate into 
the app's UI if we are really good, including CAPTCHA-based introductions ... 
h, there could be something in this ... might need API changes though, how 
do you deal with introductions now? Such principles may be valuable to Freenet 
even if we have to break compatibility with Unhosted... Thoughts?


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl