date:20090514

Matthew Toseland skrev:
> Related idea: We should maybe tell the user in the installer that they should 
> use a separate browser for Freenet, rather than in the wizard? And then let 
> them choose one, and then use it when they click on the icon to browse 
> Freenet? (#3104)

Most major browsers either have or are about to include "privacy mode" 
which we ought to use instead. Maintaining 2 browser installations is a 
hell for non-geeks as well.

- Zero3

[freenet-dev] Usability test results

2009-05-14 Thread Thomas Sachau

Matthew Toseland schrieb:
> My observation: Can we get rid of the "I will configure it manually" choice? 
> And maybe the welcome page? (#3094)

You want to force everyone to use the Wizard?

> Because we were both on the same LAN, it did not connect, until I told him to 
> set it to allow local addresses on that peer. There should be a checkbox when 
> adding a noderef, defaulting to on, "Friend may be on the same local network 
> as me" or something. (#3098)

This is imho not usual, so i would set this to very low priority and only for 
advanced mode enabled.

> Related idea: We should maybe tell the user in the installer that they should 
> use a separate browser for Freenet, rather than in the wizard? And then let 
> them choose one, and then use it when they click on the icon to browse 
> Freenet? (#3104)

This would produce additional work for people packaging freenet, since they 
would have to warn the
user themselves, while users tend to ignore the output of the package manager.
So this would lower the chance of people noticing the request for a different 
freenet
browser/profile and therefor i am against it. I suggest the current way: 
Warning during first call
of the webinterface like it is currently done.

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 315 bytes
Desc: OpenPGP digital signature
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20090514/ac5793a1/attachment.pgp>

[freenet-dev] Wininstaller deployed

Matthew Toseland skrev:
  > We now include wget.exe and sha1test.jar. Also, I have put the 
update.cmd in
> update-new.cmd on emu and updated it to fetch itself, and made it use icacls 
> on win 5.2 (XP64, win2k3 server etc). And fixed some problems with its use of 
> the start/stop scripts, and a bug that was causing it not to switch between 
> builds that had already been downloaded (which still exists in the other 
> version of update.cmd iirc). So it works now, despite java not being on the 
> path (causing the verification not to run; why doesn't it just fail?).

Regarding these comments in update.cmd:

":Assume that it was running, no way to easily tell - FIXME what to grep 
for in the service list when multiple installs?"

and

"::  FIXME   do we need a new error handling section for the new .exe? 
Will it handle errors itself?"

The service name is "freenet", where  is 
the contents of installid.dat in the install dir (empty on first 
install, "_2" on second install, "_3" on third install and so on).

Run "start.exe /?" and "stop.exe /?" to see command line options and 
return codes (or look in the source: src_freenethelpers/FreenetStart.ahk 
and src_freenethelpers/FreenetStop.ahk).

- Zero3

[freenet-dev] Usability test results

Another usability test, with somebody who has used Freenet before once or
twice but remains essentially a newbie.

My observation: Can we get rid of the "I will configure it manually" choice?
And maybe the welcome page? (#3094)

The browser warning: User installed Chrome, and copied the URL across (without
prompting), thus restarting the wizard.

Since he knows me he chose maximum security.

The warning shown when setting friends security to HIGH is missing, it shows
the name of the string, not the explanation. (#3095)

Several messages refer to "network security level". What does this mean? We
use "protection against strangers attacking you over the internet" etc... we
should put "network security level" in brackets or something. (#3096)

You have no peers message: should tell him to add peers via the Connections to
Friends page, with a link. User had no idea. It should also link to (or even
have a button for?) the security levels page. (#3097)

Friends page: what is a noderef? We need to have some dismissable explanation
text here to explain that you need to exchange noderefs both ways to get
connected. (#3035)

We exchange noderefs over skype. Skype appears to put linebreaks in, but this
worked anyway.

Because we were both on the same LAN, it did not connect, until I told him to
set it to allow local addresses on that peer. There should be a checkbox when
adding a noderef, defaulting to on, "Friend may be on the same local network
as me" or something. (#3098)

The node took some time to connect, even then. My side showed it as connected
quickly, but his side said DISCONNECTED, with nothing in the logs. I sent his
node a node to node text message, which was received; when a reply was sent,
it finally showed up as connected. (#3099)

My observation: Also, it would have helped if the friends page had refreshed
itself via javascript; sashee will be working on this over summer. (#3100)

Once connected to my node, it repeatedly RNFed on the top block of TUFI.
Performance with one peer is expected to be poor, but it is worse than IMHO
it could be. Some sort of fair sharing scheme ought to allow a darknet peer
that isn't doing much to have a few requests accepted while we are rejecting
tons of requests from other darknet peers and opennet peers. (#3101)

Then he switched the network seclevel to NORMAL.

My observation: maybe we should give some sort of progress indication for
bootstrapping on the homepage? Or even on the loading-a-page progress pages?
Maybe when we have fewer alerts (by consolidating them) we could show them on
the loading-a-page page? (#3102)

The search box is broken, we need to release 1210 to fix it.

My observation: The search page should have a meaningful title, and not take
up a big chunk of space with its name and version. (#3103)

Related idea: We should maybe tell the user in the installer that they should
use a separate browser for Freenet, rather than in the wizard? And then let
them choose one, and then use it when they click on the icon to browse
Freenet? (#3104)
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20090514/3edf5e09/attachment.pgp>

[freenet-dev] Question about an important design decision of the WoT plugin

2009-05-14 Thread Arne Babenhauserheide

On Wednesday, 13. May 2009 16:33:29 Arne Babenhauserheide wrote:
> Voting not on users but on messages (objects):

Short additional info: You never rate users directly but only check how much 
their votes correspond with yours. 

If they correspond positively (they vote up what you vote up) you use their 
votes for judging messages. If they correspond negatively (they voted up 
spam), you use their votes inversed. 

The developers showed that, if you can keep people from creating new accounts 
to quickly, this system makes it impossible to promote more than a few spam 
messages as good, and if multiple spammers try to promote different spam, they 
cancel out, since they have to vote honestly on so many good messages that 
their spam disappears. 

Best wishes, 
Arne

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 
   - singing a part of the history of free software -
  http://infinite-hands.draketo.de
-- 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: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20090514/1af9098e/attachment.pgp>

[freenet-dev] Question about an important design decision of the WoT plugin

n node can get. ?The only issue
> >> I see is that you would want to limit the churn rate -- it does no
> >> good to have limited the spammer to 5 child identities if he can send
> >> a few messages, unmark those identities, and mark some new ones.
> >
> > This is logical.
> >>
> >> Having a way for me to easily realize that an identity I have trusted
> >> is trusting spammers is important. ?However, I think part of avoiding
> >> censorship is making this be a manually verified process, and *not* an
> >> automated, recursive part of the normal computation algorithm.
> >
> > Yes, we should ask the user, but the converse is if a user doesn't visit 
his
> > node for a while, everyone will have blacklisted him because he didn't
> > blacklist the spammers he trusted.
> 
> Isn't the same true with other metrics?  If someone trusts spammers in
> WoT, I'll mark them down?  You tackle this problem with rules that
> attempt to ignore trust lists from people who aren't active, or by
> deciding that out of date trust lists shouldn't be trusted, and
> therefore the blacklisting is appropriate.  For example, if I mark
> someone as a spammer, WoT could then know to start ignoring trust
> lists from people who trust him and haven't been active in the last
> [time period].  Obviously you want to keep using trust lists that are
> still accurate and belong to people who are merely lurking, so the
> problem has some subtlety to it, but I don't think it's a hard one.
> 
> >> >> In the context of the routing and data store algorithms, Freenet has a
> >> >> strong prejudice against alchemy and in favor of algorithms with
> >> >> properties that are both useful and provable from reasonable
> >> >> assumptions, even though they are not provably perfect. ?Like routing,
> >> >> the generalized trust problem is non-trivial. ?Advogato has such
> >> >> properties; the current WoT and FMS algorithms do not: they are
> >> >> alchemical. ?In addition, the Advogato metric has a strong anecdotal
> >> >> success story in the form of the Advogato site (I've not been active
> >> >> on FMS/Freetalk recently enough to speak to them). ?Why is alchemy
> >> >> acceptable here, but not in routing?
> >> >
> >> > Because the provable metrics don't work for our scenario. At least they
> > don't
> >> > work given the current assumptions and formulations.
> >>
> >> Could you be more specific? ?This thread is covering several closely
> >> related but distinct subjects, so I'm not really sure exactly which
> >> assumptions you're referring to. ?Also, do you mean that they don't
> >> work in the sense that the proof is no longer applicable or
> >> mathematically valid, or in the sense that the results of the proof
> >> aren't useful?
> >
> > The latter. Pure positive only works if every user can be trusted to
> > continually evaluate his peers' messages to all contexts, and their
> > relationships to other users, and can therefore be blocked if they 
propagate
> > messages of spammers.
> 
> OK.
> 
> I think you really mean "Pure positive only works *perfectly* if every
> user..."  

Hmm, maybe.

> We don't need a perfect system that stops all spam and 
> nothing else.  Any system will have some failings.  Minimizing those
> failings should be a design goal, but knowing where we expect those
> failings to be, and placing them where we want them, is also an
> important goal.
> 
> Or, looked at another way:  We have ample evidence that people will
> abuse the new identity creation process to post spam.  That is a
> problem worth expending significant effort to solve.  Do we have
> evidence that spammers will actually exert per-identity manual effort
> in order to send problematic amounts of spam?  

I don't see why it would be per-identity.

> Personally, I'm not 
> worried about there being a little bit of spam; I'm worried about it
> overwhelming the discussions and making the system unusable.  My
> intuition tells me that we need defenses against such attacks, but
> that they can be fairly minimal -- provided the defenses against
> new-identity labor-free spam are strong.

So you consider the problem to be contained if a spammer can only trust 20 
identities, everyone reads his messages, everyone reads his sub-identities' 
spams, and then individually blacklist them? Those targeted by the spam would 
then not trust the spammer's main identity in order to not see his 
sub-identities' spam, but those who talk to him would as they don't see them. 
Maybe you're right, if we have some severe constraints on changes to trust 
lists?
> 
> However, I've seen enough flames flying over the issue of mob
> censorship that I believe that problem to be real and worth worrying
> about.  In the absence of a system that simultaneously solves both
> problems (something which I suspect is, at a fairly fundamental level,
> not doable), I am inclined to place the strengths of the system in
> avoiding new-identity spam and avoiding mob censorship, and decide
> that having the inevitable weaknesses be against attacks by
> established, trusted identities is acceptable.
> 
> Evan Daniel
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20090514/61e556dd/attachment.pgp>

[freenet-dev] Wininstaller deployed

On Thursday 14 May 2009 01:17:10 Juiceman wrote:
> On Wed, May 13, 2009 at 5:22 PM, Zero3  wrote:
> > Matthew Toseland skrev:
> >> I have deployed the new wininstaller, for Vista/win7 users and anyone who
> >> clicks on "Windows instructions". Win2K/XP users with working JWS will 
still
> >> see the old installer for now.
> >
> > Cool! :)
> 
> I just did a test install on a clean virtual machine.  It is missing
> wget.exe in the \bin folder of the installer!  This will break the
> update.cmd script please pull the new installer until this is fixed!

We now include wget.exe and sha1test.jar. Also, I have put the update.cmd in 
update-new.cmd on emu and updated it to fetch itself, and made it use icacls 
on win 5.2 (XP64, win2k3 server etc). And fixed some problems with its use of 
the start/stop scripts, and a bug that was causing it not to switch between 
builds that had already been downloaded (which still exists in the other 
version of update.cmd iirc). So it works now, despite java not being on the 
path (causing the verification not to run; why doesn't it just fail?).
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20090514/0f43ed54/attachment.pgp>

[freenet-dev] Usability test results

2009-05-14 Thread Robert Hailey

On May 14, 2009, at 12:17 PM, Matthew Toseland wrote:

> Because we were both on the same LAN, it did not connect, until I  
> told him to
> set it to allow local addresses on that peer. There should be a  
> checkbox when
> adding a noderef, defaulting to on, "Friend may be on the same local  
> network
> as me" or something. (#3098)

I think that it should be possible to automatically detect this.  
Specifically, if we detect that our peer has the same "external  
address" as us, try and connect locally. Is that a reliable indicator?

> Once connected to my node, it repeatedly RNFed on the top block of  
> TUFI.
> Performance with one peer is expected to be poor, but it is worse  
> than IMHO
> it could be. Some sort of fair sharing scheme ought to allow a  
> darknet peer
> that isn't doing much to have a few requests accepted while we are  
> rejecting
> tons of requests from other darknet peers and opennet peers. (#3101)

I second that, but I'm not sure as to the best implementation.

On the surface this appears to be the same issue as balancing local/ 
remote requests. i.e. if your node is busy doing everyone else's work,  
your requests should take clear advantage when you finally get around  
to clicking a link.

I think this conflicts with the current throttling mechanism; piling  
on requests till one or both nodes say 'enough', and if we reserve  
some space we will not hit our bandwidth goal. Or that requests are  
actually "competing" like collisions on a busy ethernet channel rather  
than having an order.

One thing that I was playing around with earlier was re-factoring  
PacketThrottle to be viewed from the queue-side. Rather than  
"sendThrottledPacket" blocking till "a good time" to enqueue a message  
based on the throttle, that all the packets would be serially  
available interleaved (e.g. PacketThrottle.getBulkPackets(n); returns  
the next 'n' packets).

--
Robert Hailey

-- next part --
An HTML attachment was scrubbed...
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20090514/e97a652f/attachment.html>

[freenet-dev] Question about an important design decision of the WoT plugin

On Thu, May 14, 2009 at 11:32 AM, Matthew Toseland
 wrote:
>> IMHO these are not solutions to the contexts problem -- it merely
>> shifts the balance between allowing spam and allowing censorship. ?In
>> one case, the attacker can build trust in one context and use it to
>> spam a different context. ?In the other case, he can build trust in
>> one context and use it to censor in another.
>>
>> Right now, the only good answer I see to contexts is to make them
>> fully independent. ?Perhaps I missed it, but I don't recall a
>> discussion of how any other option would work in any detail -- the
>> alternative under consideration appears to be to treat everything as
>> one unified context. ?I'm not necessarily against that, but the
>> logical conclusion is that you're responsible for paying attention to
>> everything someone you've trusted does in all contexts in which you
>> trust them -- which, for a unified context, means everywhere.
>
> Having to bootstrap on each forum would be _bad_. Totally impractical.
>
> What about ultimatums? "these" above refers to WoT with negative trust, right?
> Ultimatums: I mark somebody as a spammer, I demand that my peers mark him as
> a spammer, they evaluate the situation, if they don't mark the spammer as
> spammer then I mark them as spammer.

Right.  So all the forums go in a single context.  I don't see how you
can usefully define two different contexts such that trust is common
to them but responsibility is not.  I think the right solution (at
least for now) is one context per application.  So you have to
boostrap into the forums app, and into the filesharing app, and into
the mail app, but not per-forum.  Otherwise I have to be able to
evaluate possible spam in an application I may not have installed.

Ultimatums sound like a reasonable approach.  Though if Alice sends
Bob an ultimatum about Bob's trust for Sam, and Bob does not act, I'm
inclined to think that Alice's client should continue downloading
Bob's messages, but cease publishing a trust rating for Bob.  After
all, Bob might just be lazy, in which case his trust list is worthless
but his messages aren't.

>> >> Also, I don't see how this attack is specific to the Advogato metric.
>> >> It works equally well in WoT / FMS. ?The only thing stopping it there
>> >> is users manually examining each other's trust lists to look for such
>> >> things. ?If you assume equally vigilant users with Advogato the attack
>> >> is irrelevant.
>> >
>> > It is solvable with positive trust, because the spammer will gain trust
> from
>> > posting messages, and lose it by spamming. The second party will likely be
>> > the stronger in most cases, hence we get a zero or worse outcome.
>>
>> Which second party?
>
> The group of users affected by the spam. The first party is the group of users
> who are not affected by the spam but appreciate the spammer's messages to a
> forum and therefore give him trust.

Ah.  You meant "solvable with *negative* trust" then?

>> OK.
>>
>> I think you really mean "Pure positive only works *perfectly* if every
>> user..."
>
> Hmm, maybe.
>
>> We don't need a perfect system that stops all spam and
>> nothing else. ?Any system will have some failings. ?Minimizing those
>> failings should be a design goal, but knowing where we expect those
>> failings to be, and placing them where we want them, is also an
>> important goal.
>>
>> Or, looked at another way: ?We have ample evidence that people will
>> abuse the new identity creation process to post spam. ?That is a
>> problem worth expending significant effort to solve. ?Do we have
>> evidence that spammers will actually exert per-identity manual effort
>> in order to send problematic amounts of spam?
>
> I don't see why it would be per-identity.

Per fake identity that will be sending spam.  If they can spend manual
effort to create a trusted id, and then create unlimited fake ids
bootstrapped from that one to spam with, that's a problem.  If the
amount of effort they have to spend is linear with the number of ids
sending spam, that's not a problem, regardless of whether the effort
is spent on the many spamming ids or the single bootstrap id.

>
>> Personally, I'm not
>> worried about there being a little bit of spam; I'm worried about it
>> overwhelming the discussions and making the system unusable. ?My
>> intuition tells me that we need defenses against such attacks, but
>> that they can be fairly minimal -- provided the defenses against
>> new-identity labor-free spam are strong.
>
> So you consider the problem to be contained if a spammer can only trust 20
> identities, everyone reads his messages, everyone reads his sub-identities'
> spams, and then individually blacklist them? Those targeted by the spam would
> then not trust the spammer's main identity in order to not see his
> sub-identities' spam, but those who talk to him would as they don't see them.
> Maybe you're right, if we have some severe constraints on changes to trust
> lists?

Yes, I

[freenet-dev] a social problem with Wot (was: Hashcash introduction, was: Question about WoT )

On Thu, May 14, 2009 at 4:22 AM, xor  wrote:
> On Wednesday 13 May 2009 22:48:53 Evan Daniel wrote:
>> On Wed, May 13, 2009 at 4:28 PM, xor  wrote:
>> > On Wednesday 13 May 2009 10:01:31 Luke771 wrote:
>> >> Thomas Sachau wrote:
>> >> > Luke771 schrieb:
>> >> >> I can't comment on the technical part because I wouldnt know what im
>> >> >> talking about.
>> >> >> However, I do like the 'social' part (being able to see an identity
>> >> >> even if the censors mark it down it right away as it's created)
>> >> >
>> >> > "The censors"? There is no central authority to censor people.
>> >> > "Censors" can only censor the web-of-trust for those people that trust
>> >> > them and which want to see a censored net. You cant and should not
>> >> > prevent them from this, if they want it.
>> >>
>> >> This have been discussed ?a lot.
>> >> the fact that censoship isnt done by a central authority but by a mob
>> >> rule is irrelevant.
>> >> Censorship in this contest is "blocking users based on the content of
>> >> their messages"
>> >>
>> >> ?The whole point ?is basically this: "A tool created to block flood
>> >> attacks ?is being used to discriminate against a group of users.
>> >>
>> >> Now, it is true that they can't really censor anything because users can
>> >> decide what trust lists to use, but it is also true that this abuse of
>> >> the wot does creates problems. They are social problems and not
>> >> technical ones, but still 'freenet problems'.
>> >>
>> >> If we see the experience with FMS as a test for the Web of Trust, the
>> >> result of that test is in my opinion something in between a miserable
>> >> failure and a catastrophe.
>> >>
>> >> The WoT never got to prove itself against a real flood attack, we have
>> >> no idea what would happen if someone decided to attack FMS, not even if
>> >> the WoT would stop the attempted attack at all, leave alone finding out
>> >> how fast and/or how well it would do it.
>> >>
>> >> In other words, for what we know, the WoT may very well be completely
>> >> ineffective against a DoS attack.
>> >> All we know about it is that the WoT can be used to discriminate against
>> >> people, we know that it WILL be used in that way, and we know that
>> >> because of a proven fact: it's being used to discriminate against people
>> >> right now, on FMS
>> >>
>> >> That's all we know.
>> >> We know that some people will abuse WoT, but we dont really know if it
>> >> would be effective at stopping DoS attacks.
>> >> Yes, it "should" work, but we don't 'know'.
>> >>
>> >> The WoT has never been tested t actually do the job it's designed to do,
>> >> yet the Freenet 'decision makers' are acting as if the WoT had proven
>> >> its validity beyond any reasonable doubt, and at the same time they
>> >> decide to ignore the only one proven fact that we have.
>> >>
>> >> This whole situation is ridiculous, ?I don't know if it's more funny or
>> >> sad... ?it's grotesque. It reminds me of our beloved politicians, always
>> >> knowing what's the right thing to do, except that it never works as
>> >> expected.
>> >
>> > No, it is not ridiculous, you are just having a point of view which is
>> > not abstract enough:
>> >
>> > If there is a shared medium (= Freenet, Freetalk, etc.) which is writable
>> > by EVERYONE, it is absolutely IMPOSSIBLE to *automatically* (as in "by
>> > writing an intelligent software") distinguish spam from useful uploads,
>> > because "EVERYONE" can be evil.
>> >
>> > EITHER you manually view every single piece of information which is
>> > uploaded and decide yourself whether you consider it as spam or not OR
>> > you adopt the ratings of other people so each person only has to rate a
>> > small subset of the uploaded data. There are no other options.
>> >
>> > And what the web of trust does is exactly the second option: it "load
>> > balances" the content rating equally between all users.
>>
>> While your statement is trivially true (assuming we ignore some fairly
>> potent techniques like bayesian classifiers that rely on neither
>> additional work by the user or reliance on the opinions of others...),
>
> Bayesian filters DO need input: You need to give them "old" spam and non-spam
> messages so that they can decide about new input.
>
> But they cannot help Freetalk because they cannot prevent "identity spam",
> i.e. the creation of very large amounts of identities.

They do not require input from *other people*.

>
>> it misses the real point: the fact that WoT spreads the work around
>> does not mean it does so efficiently or effectively, or that the
>> choices it makes wrt various design tradeoffs are actually the choices
>> that we, as its users, would make if we considered those choices
>> carefully.
>>
>> A web of trust is a complex system, the entire purpose of which is to
>> create useful emergent behaviors. ?Too much focus on the micro-level
>> behavior of the parts of such a system, instead of the emergent
>> properties of the system as a whole, means

[freenet-dev] a social problem with Wot (was: Hashcash introduction, was: Question about WoT )

2009-05-14 Thread xor

arge amounts of identities.

> it misses the real point: the fact that WoT spreads the work around
> does not mean it does so efficiently or effectively, or that the
> choices it makes wrt various design tradeoffs are actually the choices
> that we, as its users, would make if we considered those choices
> carefully.
>
> A web of trust is a complex system, the entire purpose of which is to
> create useful emergent behaviors.  Too much focus on the micro-level
> behavior of the parts of such a system, instead of the emergent
> properties of the system as a whole, means that you won't get the
> emergent properties you wanted.
>

Yes, the current web of trust implementation might not be perfect. But it is 
one of the only solutions to the spam problem, if not the only. 

So the question is not whether to use a WoT but rather how to program the WoT 
to fit our purposes.

Well anyway, if someone has an alternative to WoT, please tell us, but you 
cannot say "do not use it" if you have none.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20090514/1b3913bb/attachment.pgp>

[freenet-dev] Wininstaller deployed

Matthew Toseland skrev:
> I have deployed the new wininstaller, for Vista/win7 users and anyone who 
> clicks on "Windows instructions". Win2K/XP users with working JWS will still 
> see the old installer for now.

Cool! :)

- Zero3

Re: [freenet-dev] a social problem with Wot (was: Hashcash introduction, was: Question about WoT )

2009-05-14 Thread xor

On Wednesday 13 May 2009 22:48:53 Evan Daniel wrote:
 On Wed, May 13, 2009 at 4:28 PM, xor x...@gmx.li wrote:
  On Wednesday 13 May 2009 10:01:31 Luke771 wrote:
  Thomas Sachau wrote:
   Luke771 schrieb:
   I can't comment on the technical part because I wouldnt know what im
   talking about.
   However, I do like the 'social' part (being able to see an identity
   even if the censors mark it down it right away as it's created)
  
   The censors? There is no central authority to censor people.
   Censors can only censor the web-of-trust for those people that trust
   them and which want to see a censored net. You cant and should not
   prevent them from this, if they want it.
 
  This have been discussed  a lot.
  the fact that censoship isnt done by a central authority but by a mob
  rule is irrelevant.
  Censorship in this contest is blocking users based on the content of
  their messages
 
   The whole point  is basically this: A tool created to block flood
  attacks  is being used to discriminate against a group of users.
 
  Now, it is true that they can't really censor anything because users can
  decide what trust lists to use, but it is also true that this abuse of
  the wot does creates problems. They are social problems and not
  technical ones, but still 'freenet problems'.
 
  If we see the experience with FMS as a test for the Web of Trust, the
  result of that test is in my opinion something in between a miserable
  failure and a catastrophe.
 
  The WoT never got to prove itself against a real flood attack, we have
  no idea what would happen if someone decided to attack FMS, not even if
  the WoT would stop the attempted attack at all, leave alone finding out
  how fast and/or how well it would do it.
 
  In other words, for what we know, the WoT may very well be completely
  ineffective against a DoS attack.
  All we know about it is that the WoT can be used to discriminate against
  people, we know that it WILL be used in that way, and we know that
  because of a proven fact: it's being used to discriminate against people
  right now, on FMS
 
  That's all we know.
  We know that some people will abuse WoT, but we dont really know if it
  would be effective at stopping DoS attacks.
  Yes, it should work, but we don't 'know'.
 
  The WoT has never been tested t actually do the job it's designed to do,
  yet the Freenet 'decision makers' are acting as if the WoT had proven
  its validity beyond any reasonable doubt, and at the same time they
  decide to ignore the only one proven fact that we have.
 
  This whole situation is ridiculous,  I don't know if it's more funny or
  sad...  it's grotesque. It reminds me of our beloved politicians, always
  knowing what's the right thing to do, except that it never works as
  expected.
 
  No, it is not ridiculous, you are just having a point of view which is
  not abstract enough:
 
  If there is a shared medium (= Freenet, Freetalk, etc.) which is writable
  by EVERYONE, it is absolutely IMPOSSIBLE to *automatically* (as in by
  writing an intelligent software) distinguish spam from useful uploads,
  because EVERYONE can be evil.
 
  EITHER you manually view every single piece of information which is
  uploaded and decide yourself whether you consider it as spam or not OR
  you adopt the ratings of other people so each person only has to rate a
  small subset of the uploaded data. There are no other options.
 
  And what the web of trust does is exactly the second option: it load
  balances the content rating equally between all users.

 While your statement is trivially true (assuming we ignore some fairly
 potent techniques like bayesian classifiers that rely on neither
 additional work by the user or reliance on the opinions of others...),

Bayesian filters DO need input: You need to give them old spam and non-spam 
messages so that they can decide about new input.

But they cannot help Freetalk because they cannot prevent identity spam, 
i.e. the creation of very large amounts of identities.

 it misses the real point: the fact that WoT spreads the work around
 does not mean it does so efficiently or effectively, or that the
 choices it makes wrt various design tradeoffs are actually the choices
 that we, as its users, would make if we considered those choices
 carefully.

 A web of trust is a complex system, the entire purpose of which is to
 create useful emergent behaviors.  Too much focus on the micro-level
 behavior of the parts of such a system, instead of the emergent
 properties of the system as a whole, means that you won't get the
 emergent properties you wanted.


Yes, the current web of trust implementation might not be perfect. But it is 
one of the only solutions to the spam problem, if not the only. 

So the question is not whether to use a WoT but rather how to program the WoT 
to fit our purposes.

Well anyway, if someone has an alternative to WoT, please tell us, but you 
cannot say do not use it if you have none.

Re: [freenet-dev] Wininstaller deployed

On Thursday 14 May 2009 01:17:10 Juiceman wrote:
 On Wed, May 13, 2009 at 5:22 PM, Zero3 ze...@zerosplayground.dk wrote:
  Matthew Toseland skrev:
  I have deployed the new wininstaller, for Vista/win7 users and anyone who
  clicks on Windows instructions. Win2K/XP users with working JWS will 
still
  see the old installer for now.
 
  Cool! :)
 
 I just did a test install on a clean virtual machine.  It is missing
 wget.exe in the \bin folder of the installer!  This will break the
 update.cmd script please pull the new installer until this is fixed!

We now include wget.exe and sha1test.jar. Also, I have put the update.cmd in 
update-new.cmd on emu and updated it to fetch itself, and made it use icacls 
on win 5.2 (XP64, win2k3 server etc). And fixed some problems with its use of 
the start/stop scripts, and a bug that was causing it not to switch between 
builds that had already been downloaded (which still exists in the other 
version of update.cmd iirc). So it works now, despite java not being on the 
path (causing the verification not to run; why doesn't it just fail?).


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

Re: [freenet-dev] a social problem with Wot (was: Hashcash introduction, was: Question about WoT )

On Thu, May 14, 2009 at 4:22 AM, xor x...@gmx.li wrote:
 On Wednesday 13 May 2009 22:48:53 Evan Daniel wrote:
 On Wed, May 13, 2009 at 4:28 PM, xor x...@gmx.li wrote:
  On Wednesday 13 May 2009 10:01:31 Luke771 wrote:
  Thomas Sachau wrote:
   Luke771 schrieb:
   I can't comment on the technical part because I wouldnt know what im
   talking about.
   However, I do like the 'social' part (being able to see an identity
   even if the censors mark it down it right away as it's created)
  
   The censors? There is no central authority to censor people.
   Censors can only censor the web-of-trust for those people that trust
   them and which want to see a censored net. You cant and should not
   prevent them from this, if they want it.
 
  This have been discussed  a lot.
  the fact that censoship isnt done by a central authority but by a mob
  rule is irrelevant.
  Censorship in this contest is blocking users based on the content of
  their messages
 
   The whole point  is basically this: A tool created to block flood
  attacks  is being used to discriminate against a group of users.
 
  Now, it is true that they can't really censor anything because users can
  decide what trust lists to use, but it is also true that this abuse of
  the wot does creates problems. They are social problems and not
  technical ones, but still 'freenet problems'.
 
  If we see the experience with FMS as a test for the Web of Trust, the
  result of that test is in my opinion something in between a miserable
  failure and a catastrophe.
 
  The WoT never got to prove itself against a real flood attack, we have
  no idea what would happen if someone decided to attack FMS, not even if
  the WoT would stop the attempted attack at all, leave alone finding out
  how fast and/or how well it would do it.
 
  In other words, for what we know, the WoT may very well be completely
  ineffective against a DoS attack.
  All we know about it is that the WoT can be used to discriminate against
  people, we know that it WILL be used in that way, and we know that
  because of a proven fact: it's being used to discriminate against people
  right now, on FMS
 
  That's all we know.
  We know that some people will abuse WoT, but we dont really know if it
  would be effective at stopping DoS attacks.
  Yes, it should work, but we don't 'know'.
 
  The WoT has never been tested t actually do the job it's designed to do,
  yet the Freenet 'decision makers' are acting as if the WoT had proven
  its validity beyond any reasonable doubt, and at the same time they
  decide to ignore the only one proven fact that we have.
 
  This whole situation is ridiculous,  I don't know if it's more funny or
  sad...  it's grotesque. It reminds me of our beloved politicians, always
  knowing what's the right thing to do, except that it never works as
  expected.
 
  No, it is not ridiculous, you are just having a point of view which is
  not abstract enough:
 
  If there is a shared medium (= Freenet, Freetalk, etc.) which is writable
  by EVERYONE, it is absolutely IMPOSSIBLE to *automatically* (as in by
  writing an intelligent software) distinguish spam from useful uploads,
  because EVERYONE can be evil.
 
  EITHER you manually view every single piece of information which is
  uploaded and decide yourself whether you consider it as spam or not OR
  you adopt the ratings of other people so each person only has to rate a
  small subset of the uploaded data. There are no other options.
 
  And what the web of trust does is exactly the second option: it load
  balances the content rating equally between all users.

 While your statement is trivially true (assuming we ignore some fairly
 potent techniques like bayesian classifiers that rely on neither
 additional work by the user or reliance on the opinions of others...),

 Bayesian filters DO need input: You need to give them old spam and non-spam
 messages so that they can decide about new input.

 But they cannot help Freetalk because they cannot prevent identity spam,
 i.e. the creation of very large amounts of identities.

They do not require input from *other people*.


 it misses the real point: the fact that WoT spreads the work around
 does not mean it does so efficiently or effectively, or that the
 choices it makes wrt various design tradeoffs are actually the choices
 that we, as its users, would make if we considered those choices
 carefully.

 A web of trust is a complex system, the entire purpose of which is to
 create useful emergent behaviors.  Too much focus on the micro-level
 behavior of the parts of such a system, instead of the emergent
 properties of the system as a whole, means that you won't get the
 emergent properties you wanted.


 Yes, the current web of trust implementation might not be perfect. But it is
 one of the only solutions to the spam problem, if not the only.

 So the question is not whether to use a WoT but rather how to program the WoT
 to fit our purposes.

 Well anyway, if

Re: [freenet-dev] Question about an important design decision of the WoT plugin

On Wednesday 13 May 2009 19:32:45 Evan Daniel wrote:
 On Wed, May 13, 2009 at 12:58 PM, Matthew Toseland
 t...@amphibian.dyndns.org wrote:
  On Wednesday 13 May 2009 15:47:24 Evan Daniel wrote:
  On Wed, May 13, 2009 at 9:03 AM, Matthew Toseland
  t...@amphibian.dyndns.org wrote:
   On Friday 08 May 2009 02:12:21 Evan Daniel wrote:
   On Thu, May 7, 2009 at 6:33 PM, Matthew Toseland
   t...@amphibian.dyndns.org wrote:
On Thursday 07 May 2009 21:32:42 Evan Daniel wrote:
On Thu, May 7, 2009 at 2:02 PM, Thomas Sachau m...@tommyserver.de
   wrote:
 Evan Daniel schrieb:
 I don't have any specific ideas for how to choose whether to 
ignore
 identities, but I think you're making the problem much harder 
than
  it
 needs to be.  The problem is that you need to prevent spam, but 
at
  the
 same time prevent malicious non-spammers from censoring 
identities
  who
 aren't spammers.  Fortunately, there is a well documented 
algorithm
 for doing this: the Advogato trust metric.

 The WoT documentation claims it is based upon the Advogato trust
 metric.  (Brief discussion:
  http://www.advogato.org/trust-metric.html
 Full paper: http://www.levien.com/thesis/compact.pdf )  I think
  this
 is wonderful, as I think there is much to recommend the Advogato
 metric (and I pushed for it early on in the WoT discussions).
 However, my understanding of the paper and what is actually
 implemented is that the WoT code does not actually implement it.
 Before I go into detail, I should point out that I haven't read 
the
 WoT code and am not fully up to date on the documentation and
 discussions; if I'm way off base here, I apologize.

 I think, you are:

 The advogato idea may be nice (i did not read it myself), if you
  have
exactly 1 trustlist for
 everything. But xor wants to implement 1 trustlist for every app 
as
   people
may act differently e.g.
 on firesharing than on forums or while publishing freesites. You
   basicly
dont want to censor someone
 just because he tries to disturb filesharing while he may be 
tries
  to
bring in good arguments at
 forum discussions about it.
 And i dont think that advogato will help here, right?
   
There are two questions here.  The first question is given a set of
identities and their trust lists, how do you compute the trust for 
an
identity the user has not rated?  The second question is, how do 
you
determine what trust lists to use in which contexts?  The two
questions are basically orthogonal.
   
I'm not certain about the contexts issue; Toad raised some good
points, and while I don't fully agree with him, it's more 
complicated
than I first thought.  I may have more to say on that subject 
later.
   
Within a context, however, the computation algorithm matters.  The
Advogato idea is very nice, and imho much better than the current 
WoT
or FMS answers.  You should really read their simple explanation 
page.
 It's really not that complicated; the only reasons I'm not fully
explaining it here is that it's hard to do without diagrams, and 
they
already do a good job of it.
   
It's nice, but it doesn't work. Because the only realistic way for
   positive
trust to be assigned is on the basis of posted messages, in a purely
   casual
way, and without the sort of permanent, universal commitment that 
any
pure-positive-trust scheme requires: If he spams on any board, if I
  ever
   gave
him trust and haven't changed that, then *I AM GUILTY* and *I LOSE
  TRUST*
   as
the only way to block the spam.
  
   How is that different than the current situation?  Either the fact
   that he spams and you trust him means you lose trust because you're
   allowing the spam through, or somehow the spam gets stopped despite
   your trust -- which implies either that a lot of people have to update
   their trust lists before anything happens, and therefore the spam
   takes forever to stop, or it doesn't take that many people to censor
   an objectionable but non-spamming poster.
  
   I agree, this is a bad thing.  I'm just not seeing that the WoT system
   is *that* much better.  It may be somewhat better, but the improvement
   comes at a cost of trading spam resistance vs censorship ability,
   which I think is fundamentally unavoidable.
  
   So how do you solve the contexts problem? The only plausible way to add
  trust
   is to do it on the basis of valid messages posted to the forum that the
  user
   reads. If he posts nonsense to other forums, or even introduces 
identities
   that spam other forums, the user adding trust probably does not know 
about
   this, so it is problematic to hold him responsible for that. In a 
positive
   trust only system this is unsolvable afaics?
  
   Perhaps some form of feedback/ultimatum system? Users who are affected 
by
  spam
   from an identity can

Re: [freenet-dev] Question about an important design decision of the WoT plugin

2009-05-14 Thread Arne Babenhauserheide

On Wednesday, 13. May 2009 16:33:29 Arne Babenhauserheide wrote:
 Voting not on users but on messages (objects):

Short additional info: You never rate users directly but only check how much 
their votes correspond with yours. 

If they correspond positively (they vote up what you vote up) you use their 
votes for judging messages. If they correspond negatively (they voted up 
spam), you use their votes inversed. 

The developers showed that, if you can keep people from creating new accounts 
to quickly, this system makes it impossible to promote more than a few spam 
messages as good, and if multiple spammers try to promote different spam, they 
cancel out, since they have to vote honestly on so many good messages that 
their spam disappears. 

Best wishes, 
Arne

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 
   - singing a part of the history of free software -
  http://infinite-hands.draketo.de


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

Re: [freenet-dev] Question about an important design decision of the WoT plugin

On Thu, May 14, 2009 at 11:32 AM, Matthew Toseland
t...@amphibian.dyndns.org wrote:
 IMHO these are not solutions to the contexts problem -- it merely
 shifts the balance between allowing spam and allowing censorship.  In
 one case, the attacker can build trust in one context and use it to
 spam a different context.  In the other case, he can build trust in
 one context and use it to censor in another.

 Right now, the only good answer I see to contexts is to make them
 fully independent.  Perhaps I missed it, but I don't recall a
 discussion of how any other option would work in any detail -- the
 alternative under consideration appears to be to treat everything as
 one unified context.  I'm not necessarily against that, but the
 logical conclusion is that you're responsible for paying attention to
 everything someone you've trusted does in all contexts in which you
 trust them -- which, for a unified context, means everywhere.

 Having to bootstrap on each forum would be _bad_. Totally impractical.

 What about ultimatums? these above refers to WoT with negative trust, right?
 Ultimatums: I mark somebody as a spammer, I demand that my peers mark him as
 a spammer, they evaluate the situation, if they don't mark the spammer as
 spammer then I mark them as spammer.

Right.  So all the forums go in a single context.  I don't see how you
can usefully define two different contexts such that trust is common
to them but responsibility is not.  I think the right solution (at
least for now) is one context per application.  So you have to
boostrap into the forums app, and into the filesharing app, and into
the mail app, but not per-forum.  Otherwise I have to be able to
evaluate possible spam in an application I may not have installed.

Ultimatums sound like a reasonable approach.  Though if Alice sends
Bob an ultimatum about Bob's trust for Sam, and Bob does not act, I'm
inclined to think that Alice's client should continue downloading
Bob's messages, but cease publishing a trust rating for Bob.  After
all, Bob might just be lazy, in which case his trust list is worthless
but his messages aren't.

  Also, I don't see how this attack is specific to the Advogato metric.
  It works equally well in WoT / FMS.  The only thing stopping it there
  is users manually examining each other's trust lists to look for such
  things.  If you assume equally vigilant users with Advogato the attack
  is irrelevant.
 
  It is solvable with positive trust, because the spammer will gain trust
 from
  posting messages, and lose it by spamming. The second party will likely be
  the stronger in most cases, hence we get a zero or worse outcome.

 Which second party?

 The group of users affected by the spam. The first party is the group of users
 who are not affected by the spam but appreciate the spammer's messages to a
 forum and therefore give him trust.

Ah.  You meant solvable with *negative* trust then?

 OK.

 I think you really mean Pure positive only works *perfectly* if every
 user...

 Hmm, maybe.

 We don't need a perfect system that stops all spam and
 nothing else.  Any system will have some failings.  Minimizing those
 failings should be a design goal, but knowing where we expect those
 failings to be, and placing them where we want them, is also an
 important goal.

 Or, looked at another way:  We have ample evidence that people will
 abuse the new identity creation process to post spam.  That is a
 problem worth expending significant effort to solve.  Do we have
 evidence that spammers will actually exert per-identity manual effort
 in order to send problematic amounts of spam?

 I don't see why it would be per-identity.

Per fake identity that will be sending spam.  If they can spend manual
effort to create a trusted id, and then create unlimited fake ids
bootstrapped from that one to spam with, that's a problem.  If the
amount of effort they have to spend is linear with the number of ids
sending spam, that's not a problem, regardless of whether the effort
is spent on the many spamming ids or the single bootstrap id.


 Personally, I'm not
 worried about there being a little bit of spam; I'm worried about it
 overwhelming the discussions and making the system unusable.  My
 intuition tells me that we need defenses against such attacks, but
 that they can be fairly minimal -- provided the defenses against
 new-identity labor-free spam are strong.

 So you consider the problem to be contained if a spammer can only trust 20
 identities, everyone reads his messages, everyone reads his sub-identities'
 spams, and then individually blacklist them? Those targeted by the spam would
 then not trust the spammer's main identity in order to not see his
 sub-identities' spam, but those who talk to him would as they don't see them.
 Maybe you're right, if we have some severe constraints on changes to trust
 lists?

Yes, I consider that a solution, for two reasons.  First, that's a
manageable amount of spam.  Annoyingly high, but

[freenet-dev] Usability test results

Another usability test, with somebody who has used Freenet before once or 
twice but remains essentially a newbie.

My observation: Can we get rid of the I will configure it manually choice? 
And maybe the welcome page? (#3094)

The browser warning: User installed Chrome, and copied the URL across (without 
prompting), thus restarting the wizard.

Since he knows me he chose maximum security.

The warning shown when setting friends security to HIGH is missing, it shows 
the name of the string, not the explanation. (#3095)

Several messages refer to network security level. What does this mean? We 
use protection against strangers attacking you over the internet etc... we 
should put network security level in brackets or something. (#3096)

You have no peers message: should tell him to add peers via the Connections to 
Friends page, with a link. User had no idea. It should also link to (or even 
have a button for?) the security levels page. (#3097)

Friends page: what is a noderef? We need to have some dismissable explanation 
text here to explain that you need to exchange noderefs both ways to get 
connected. (#3035)

We exchange noderefs over skype. Skype appears to put linebreaks in, but this 
worked anyway.

Because we were both on the same LAN, it did not connect, until I told him to 
set it to allow local addresses on that peer. There should be a checkbox when 
adding a noderef, defaulting to on, Friend may be on the same local network 
as me or something. (#3098)

The node took some time to connect, even then. My side showed it as connected 
quickly, but his side said DISCONNECTED, with nothing in the logs. I sent his 
node a node to node text message, which was received; when a reply was sent, 
it finally showed up as connected. (#3099)

My observation: Also, it would have helped if the friends page had refreshed 
itself via javascript; sashee will be working on this over summer. (#3100)

Once connected to my node, it repeatedly RNFed on the top block of TUFI. 
Performance with one peer is expected to be poor, but it is worse than IMHO 
it could be. Some sort of fair sharing scheme ought to allow a darknet peer 
that isn't doing much to have a few requests accepted while we are rejecting 
tons of requests from other darknet peers and opennet peers. (#3101)

Then he switched the network seclevel to NORMAL.

My observation: maybe we should give some sort of progress indication for 
bootstrapping on the homepage? Or even on the loading-a-page progress pages? 
Maybe when we have fewer alerts (by consolidating them) we could show them on 
the loading-a-page page? (#3102)

The search box is broken, we need to release 1210 to fix it.

My observation: The search page should have a meaningful title, and not take 
up a big chunk of space with its name and version. (#3103)

Related idea: We should maybe tell the user in the installer that they should 
use a separate browser for Freenet, rather than in the wizard? And then let 
them choose one, and then use it when they click on the icon to browse 
Freenet? (#3104)


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

Re: [freenet-dev] Wininstaller deployed

Matthew Toseland skrev:
   We now include wget.exe and sha1test.jar. Also, I have put the 
update.cmd in
 update-new.cmd on emu and updated it to fetch itself, and made it use icacls 
 on win 5.2 (XP64, win2k3 server etc). And fixed some problems with its use of 
 the start/stop scripts, and a bug that was causing it not to switch between 
 builds that had already been downloaded (which still exists in the other 
 version of update.cmd iirc). So it works now, despite java not being on the 
 path (causing the verification not to run; why doesn't it just fail?).

Regarding these comments in update.cmd:

:Assume that it was running, no way to easily tell - FIXME what to grep 
for in the service list when multiple installs?

and

::  FIXME   do we need a new error handling section for the new .exe? 
Will it handle errors itself?

The service name is freenetinstallsuffix, where installsuffix is 
the contents of installid.dat in the install dir (empty on first 
install, _2 on second install, _3 on third install and so on).

Run start.exe /? and stop.exe /? to see command line options and 
return codes (or look in the source: src_freenethelpers/FreenetStart.ahk 
and src_freenethelpers/FreenetStop.ahk).

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

Re: [freenet-dev] Usability test results

2009-05-14 Thread Thomas Sachau

Matthew Toseland schrieb:
 My observation: Can we get rid of the I will configure it manually choice? 
 And maybe the welcome page? (#3094)

You want to force everyone to use the Wizard?

 Because we were both on the same LAN, it did not connect, until I told him to 
 set it to allow local addresses on that peer. There should be a checkbox when 
 adding a noderef, defaulting to on, Friend may be on the same local network 
 as me or something. (#3098)

This is imho not usual, so i would set this to very low priority and only for 
advanced mode enabled.

 Related idea: We should maybe tell the user in the installer that they should 
 use a separate browser for Freenet, rather than in the wizard? And then let 
 them choose one, and then use it when they click on the icon to browse 
 Freenet? (#3104)

This would produce additional work for people packaging freenet, since they 
would have to warn the
user themselves, while users tend to ignore the output of the package manager.
So this would lower the chance of people noticing the request for a different 
freenet
browser/profile and therefor i am against it. I suggest the current way: 
Warning during first call
of the webinterface like it is currently done.



signature.asc
Description: OpenPGP digital signature
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Separate browser or not

Matthew Toseland skrev:
 Related idea: We should maybe tell the user in the installer that they should 
 use a separate browser for Freenet, rather than in the wizard? And then let 
 them choose one, and then use it when they click on the icon to browse 
 Freenet? (#3104)

Most major browsers either have or are about to include privacy mode 
which we ought to use instead. Maintaining 2 browser installations is a 
hell for non-geeks as well.

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

Re: [freenet-dev] Usability test results

2009-05-14 Thread Robert Hailey



On May 14, 2009, at 12:17 PM, Matthew Toseland wrote:

Because we were both on the same LAN, it did not connect, until I  
told him to
set it to allow local addresses on that peer. There should be a  
checkbox when
adding a noderef, defaulting to on, Friend may be on the same local  
network

as me or something. (#3098)


I think that it should be possible to automatically detect this.  
Specifically, if we detect that our peer has the same external  
address as us, try and connect locally. Is that a reliable indicator?


Once connected to my node, it repeatedly RNFed on the top block of  
TUFI.
Performance with one peer is expected to be poor, but it is worse  
than IMHO
it could be. Some sort of fair sharing scheme ought to allow a  
darknet peer
that isn't doing much to have a few requests accepted while we are  
rejecting

tons of requests from other darknet peers and opennet peers. (#3101)


I second that, but I'm not sure as to the best implementation.

On the surface this appears to be the same issue as balancing local/ 
remote requests. i.e. if your node is busy doing everyone else's work,  
your requests should take clear advantage when you finally get around  
to clicking a link.


I think this conflicts with the current throttling mechanism; piling  
on requests till one or both nodes say 'enough', and if we reserve  
some space we will not hit our bandwidth goal. Or that requests are  
actually competing like collisions on a busy ethernet channel rather  
than having an order.


One thing that I was playing around with earlier was re-factoring  
PacketThrottle to be viewed from the queue-side. Rather than  
sendThrottledPacket blocking till a good time to enqueue a message  
based on the throttle, that all the packets would be serially  
available interleaved (e.g. PacketThrottle.getBulkPackets(n); returns  
the next 'n' packets).


--
Robert Hailey

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

Re: [freenet-dev] Usability test results

On Thursday 14 May 2009 18:35:07 Thomas Sachau wrote:
 Matthew Toseland schrieb:
  My observation: Can we get rid of the I will configure it manually 
choice? 
  And maybe the welcome page? (#3094)
 
 You want to force everyone to use the Wizard?

Why would that be bad?
 
  Because we were both on the same LAN, it did not connect, until I told him 
to 
  set it to allow local addresses on that peer. There should be a checkbox 
when 
  adding a noderef, defaulting to on, Friend may be on the same local 
network 
  as me or something. (#3098)
 
 This is imho not usual, so i would set this to very low priority and only 
for advanced mode enabled.

Hmmm, maybe.
 
  Related idea: We should maybe tell the user in the installer that they 
should 
  use a separate browser for Freenet, rather than in the wizard? And then 
let 
  them choose one, and then use it when they click on the icon to browse 
  Freenet? (#3104)
 
 This would produce additional work for people packaging freenet, since they 
would have to warn the
 user themselves, while users tend to ignore the output of the package 
manager.
 So this would lower the chance of people noticing the request for a 
different freenet
 browser/profile and therefor i am against it. I suggest the current way: 
Warning during first call
 of the webinterface like it is currently done.

Well, maybe on linux, with the packages that we don't have yet...


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

Re: [freenet-dev] Separate browser or not

On Thursday 14 May 2009 18:40:31 Zero3 wrote:
 Matthew Toseland skrev:
  Related idea: We should maybe tell the user in the installer that they 
should 
  use a separate browser for Freenet, rather than in the wizard? And then 
let 
  them choose one, and then use it when they click on the icon to browse 
  Freenet? (#3104)
 
 Most major browsers either have or are about to include privacy mode 
 which we ought to use instead. Maintaining 2 browser installations is a 
 hell for non-geeks as well.

We would have to reliably detect it. Possible?


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

Re: [freenet-dev] Usability test results

On Thursday 14 May 2009 20:36:31 Robert Hailey wrote:
 
 On May 14, 2009, at 12:17 PM, Matthew Toseland wrote:
 
  Because we were both on the same LAN, it did not connect, until I  
  told him to
  set it to allow local addresses on that peer. There should be a  
  checkbox when
  adding a noderef, defaulting to on, Friend may be on the same local  
  network
  as me or something. (#3098)
 
 I think that it should be possible to automatically detect this.  
 Specifically, if we detect that our peer has the same external  
 address as us, try and connect locally. Is that a reliable indicator?

Not very (what if it changes?) ... we don't want darknet peers to cause us to 
connect to addresses on our LAN ... otherwise the solution is simply to try 
the local addresses included ...
 
  Once connected to my node, it repeatedly RNFed on the top block of  
  TUFI.
  Performance with one peer is expected to be poor, but it is worse  
  than IMHO
  it could be. Some sort of fair sharing scheme ought to allow a  
  darknet peer
  that isn't doing much to have a few requests accepted while we are  
  rejecting
  tons of requests from other darknet peers and opennet peers. (#3101)
 
 I second that, but I'm not sure as to the best implementation.
 
 On the surface this appears to be the same issue as balancing local/ 
 remote requests. i.e. if your node is busy doing everyone else's work,  
 your requests should take clear advantage when you finally get around  
 to clicking a link.

Possibly. It is indeed a load balancing problem. Queueing will help, or maybe 
simulated queueing.
 
 I think this conflicts with the current throttling mechanism; piling  
 on requests till one or both nodes say 'enough', 

Is this how it works now?

 and if we reserve   
 some space we will not hit our bandwidth goal. Or that requests are  
 actually competing like collisions on a busy ethernet channel rather  
 than having an order.

Yes, it is very much like that.
 
 One thing that I was playing around with earlier was re-factoring  
 PacketThrottle to be viewed from the queue-side. Rather than  
 sendThrottledPacket blocking till a good time to enqueue a message  
 based on the throttle, that all the packets would be serially  
 available interleaved (e.g. PacketThrottle.getBulkPackets(n); returns  
 the next 'n' packets).

Good idea... I thought it was somewhat like that already? It is important in 
some cases for it to block...


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

Re: [freenet-dev] Question about an important design decision of the WoT plugin

On Thursday 14 May 2009 17:33:29 Evan Daniel wrote:
 On Thu, May 14, 2009 at 11:32 AM, Matthew Toseland
 t...@amphibian.dyndns.org wrote:
  IMHO these are not solutions to the contexts problem -- it merely
  shifts the balance between allowing spam and allowing censorship.  In
  one case, the attacker can build trust in one context and use it to
  spam a different context.  In the other case, he can build trust in
  one context and use it to censor in another.
 
  Right now, the only good answer I see to contexts is to make them
  fully independent.  Perhaps I missed it, but I don't recall a
  discussion of how any other option would work in any detail -- the
  alternative under consideration appears to be to treat everything as
  one unified context.  I'm not necessarily against that, but the
  logical conclusion is that you're responsible for paying attention to
  everything someone you've trusted does in all contexts in which you
  trust them -- which, for a unified context, means everywhere.
 
  Having to bootstrap on each forum would be _bad_. Totally impractical.
 
  What about ultimatums? these above refers to WoT with negative trust, 
right?
  Ultimatums: I mark somebody as a spammer, I demand that my peers mark him 
as
  a spammer, they evaluate the situation, if they don't mark the spammer as
  spammer then I mark them as spammer.
 
 Right.  So all the forums go in a single context.  I don't see how you
 can usefully define two different contexts such that trust is common
 to them but responsibility is not.  I think the right solution (at
 least for now) is one context per application.  So you have to
 boostrap into the forums app, and into the filesharing app, and into
 the mail app, but not per-forum.  Otherwise I have to be able to
 evaluate possible spam in an application I may not have installed.
 
 Ultimatums sound like a reasonable approach.  Though if Alice sends
 Bob an ultimatum about Bob's trust for Sam, and Bob does not act, I'm
 inclined to think that Alice's client should continue downloading
 Bob's messages, but cease publishing a trust rating for Bob.  After
 all, Bob might just be lazy, in which case his trust list is worthless
 but his messages aren't.

Agreed, I have no problem with not reducing message trust in this case.
 
   Also, I don't see how this attack is specific to the Advogato metric.
   It works equally well in WoT / FMS.  The only thing stopping it there
   is users manually examining each other's trust lists to look for such
   things.  If you assume equally vigilant users with Advogato the attack
   is irrelevant.
  
   It is solvable with positive trust, because the spammer will gain trust
  from
   posting messages, and lose it by spamming. The second party will likely 
be
   the stronger in most cases, hence we get a zero or worse outcome.
 
  Which second party?
 
  The group of users affected by the spam. The first party is the group of 
users
  who are not affected by the spam but appreciate the spammer's messages to 
a
  forum and therefore give him trust.
 
 Ah.  You meant solvable with *negative* trust then?

Yes, sorry.
 
  OK.
 
  I think you really mean Pure positive only works *perfectly* if every
  user...
 
  Hmm, maybe.
 
  We don't need a perfect system that stops all spam and
  nothing else.  Any system will have some failings.  Minimizing those
  failings should be a design goal, but knowing where we expect those
  failings to be, and placing them where we want them, is also an
  important goal.
 
  Or, looked at another way:  We have ample evidence that people will
  abuse the new identity creation process to post spam.  That is a
  problem worth expending significant effort to solve.  Do we have
  evidence that spammers will actually exert per-identity manual effort
  in order to send problematic amounts of spam?
 
  I don't see why it would be per-identity.
 
 Per fake identity that will be sending spam.  If they can spend manual
 effort to create a trusted id, and then create unlimited fake ids
 bootstrapped from that one to spam with, that's a problem.  If the
 amount of effort they have to spend is linear with the number of ids
 sending spam, that's not a problem, regardless of whether the effort
 is spent on the many spamming ids or the single bootstrap id.

Because there is a limit on churn, and one spamming identity can be blocked 
trivially. Does this eliminate the need for reducing trust in an identity 
that trusts spammers (hence ultimatums)?
 
  Personally, I'm not
  worried about there being a little bit of spam; I'm worried about it
  overwhelming the discussions and making the system unusable.  My
  intuition tells me that we need defenses against such attacks, but
  that they can be fairly minimal -- provided the defenses against
  new-identity labor-free spam are strong.
 
  So you consider the problem to be contained if a spammer can only trust 20
  identities, everyone reads his messages, everyone reads his

Re: [freenet-dev] Separate browser or not

2009-05-14 Thread Colin Davis

The most reliable way to detect incognito mode is to use the CSS detect 
trick.
If we can detect their CSS links followed, they are not in privacy mode.
http://crypto.stanford.edu/~collinj/research/incognito/
-CPD

Matthew Toseland wrote:
 On Thursday 14 May 2009 18:40:31 Zero3 wrote:
   
 Matthew Toseland skrev:
 
 Related idea: We should maybe tell the user in the installer that they 
   
 should 
   
 use a separate browser for Freenet, rather than in the wizard? And then 
   
 let 
   
 them choose one, and then use it when they click on the icon to browse 
 Freenet? (#3104)
   
 Most major browsers either have or are about to include privacy mode 
 which we ought to use instead. Maintaining 2 browser installations is a 
 hell for non-geeks as well.
 

 We would have to reliably detect it. Possible?
   
 

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

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

Re: [freenet-dev] Please help us test the new wininstaller (Vista users especially welcome)

2009-05-14 Thread ghoul

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, 12 May 2009 13:45:49 -0600 Zero3 ze...@zerosplayground.dk
wrote:

2nd Install, with java pre-installed (32/64 bit)

1. Freenet installer as Administrator
2. Java detected, taking default install options

Did the installer correctly detect your 64-bit Java installation?
I thought it didn't do that last time?

No, it detected the 32 bit only.

6. Up and running. One small oddity, I accessed the same index
page
as above, but this time I had to go to it three times to get the
latest, most current version. Will this cause confusion with new
users that they sometimes can get old content from the main
page?
Was it a very old version, or the second latest? Your node
probably
found the second latest version first, and transparently replaced
it with the latest one once it stumbled upon it. This is quite
normal. It shouldn't happen for long though, as all nodes should
update their copies as soon as they hear about the new one.

What I thought odd was that it actually updated to a newer version
twice. So rather than jump from an old edition to the latest, it
hit an intermediate one on the way.

7. Not installer related, but upon uninstalling w/ option to
do
survey, the survey errored out with: Something bad happened.
Don't
worry, though. The Spreadsheets Team has been notified and we'll
get right on it. This was from IE as it is still set as the
default browser. (but not for long)

Sounds like an error from Google (who hosts the survey
spreadsheet).
Should fix itself once they figure out what's wrong.

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

One other thing, When the uninstaller runs, it does not remove the
freenet user it created. I had multiple users named freenet,
freenet.001, freenet.002 etc.

-BEGIN PGP SIGNATURE-
Charset: UTF8
Note: This signature can be verified at https://www.hushtools.com/verify
Version: Hush 3.0

wkYEARECAAYFAkoMwGIACgkQDAg0OvA3V4CVvQCeJzWiJgktGIbzYkPYHvnlOnTgIgkA
oLam3uDUEk5kOVLbUaXcCbUlHFd1
=uaFh
-END PGP SIGNATURE-

--
Click now to find great remedies for hangovers!

http://tagline.hushmail.com/fc/BLSrjkqgbosfv6exDo267TAOeZk0jO08ZuqcrGR1xUsPmLVOqjezTaJ1bTS/

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

Re: [freenet-dev] Question about an important design decision of the WoT plugin