I2P dev meeting, October 4, 2013 @ 20:00 UTC

Quick recap

  • Present: dg, equinox, hottuna, Mathiasdm, orion, psi, str4d topiltzin, zzz

Registo Completo do IRC

20:09:33  <str4d> Meeting time. Who is here?
20:09:53  * psi is here
20:10:04  * dg here
20:11:34  * topiltzin .
20:11:51  <str4d> hottuna, zzz, welterde, kytv: ping
20:12:17  * orion is here
20:13:01  * str4d loads meeting agenda
20:14:01  <str4d> I can't reach zzz.i2p. Can anyone else get to http://zzz.i2p/topics/1480 ?
20:14:35  <str4d> Got it.
20:14:43  <str4d> 1) Threat model
20:14:44  <str4d> 1a) Discuss merits of DREAD classification scheme (and choose another if necessary).
20:14:44  <str4d> 1b) Discuss threat model (and update if needed).
20:14:44  <str4d> 1c) Apply DREAD (or other scheme) to attack vectors in threat model.
20:14:44  <str4d> 2) Website revamp - check over in preparation for launch.
20:14:53  <str4d> 3) Roadmapping.
20:15:22  <str4d> 4) Docs discussion.
20:15:41  <str4d> We already coverered 0)  Say hi ;-P
20:15:42  <str4d> 1) Threat model
20:15:53  <str4d> 1a) Discuss merits of DREAD classification scheme (and choose another if necessary).
20:17:07  <str4d> As I said in the forum post, I think that one of the things we can do to improve how other perceive I2P is to improve and clarify the threat model.
20:17:29  <str4d> Right now, it is a wall of text, and difficult for users (and non-motivated devs) to find the main concerns.
20:17:45  <dg> It's hard to rank it also.
20:17:47  <dg> Understand urgency, etc.
20:18:03  <str4d> And without any proper risk modelling, we really have no idea if we are focusing on the right aspects.
20:18:13  <psi> It would be great to get a short version of the threat model first and build off that
20:18:23  <str4d> dg: exactly.
20:18:59  <str4d> I did some research, and https://www.owasp.org/index.php/Threat_Risk_Modeling has a good threat risk modeling "layout", which is used by e.g. Cryptocat for their threat model.
20:19:04  <iRelay> Title: Threat Risk Modeling - OWASP (at www.owasp.org)
20:19:53  <str4d> The DREAD scheme that they describe is not completely effective at identifying risk correctly, according to feedback mentioned in a subsequent post by the designer of the model - https://blogs.msdn.com/b/david_leblanc/archive/2007/08/13/dreadful.aspx
20:20:49  <str4d> I propose that we use the modified DREAD model that he gives in the above post, to model the severity and priority of our attack vectors.
20:20:50  <str4d> Discuss!
20:21:13  <dg> Give me some time to review the models? :)
20:21:40  <str4d> dg: you were supposed to have done that already, I linked to it in the forum post...
20:21:44  <str4d> :P
20:21:50  <dg> sorry
20:22:24  <str4d> (but I didn't actually ask people to do so, my bad)
20:23:08  <str4d> DREAD tl;dr - they rank a threat on five 1-10 scales, add the results and divide by 5.
20:23:12  <str4d> Damage Potential
20:23:29  <str4d> Reproducibility
20:23:29  <str4d> Exploitability
20:23:29  <str4d> Affected Users
20:23:30  <str4d> Discoverability
20:24:12  <str4d> modified DREAD tl;dr - same five parameters, but a 1-3 (low, med, high) scale and a "weighted" calculation.
20:25:09  <dg> I'm giving it a brief read; I obviously don't know all the details but any structured system is better.
20:25:18  <str4d> The modified DREAD model makes better sense to me than the original.
20:26:06  <dg> I have a lot of respect for OWASP too. :P
20:26:10  <str4d> "If we look at the five components, we see that none of these are highly correlated - one of them does not imply the other. This means we have independent factors, which is one of the strongest criteria for a solid model. Thus our task is to figure out how to properly weight the inputs. In WSC, we told you to rate them from 1-10, add them up, and divide by 5. If we apply some obvious tests, we find that a damage of 1, and all other factors 10 (a well known nuisance
20:26:10  <str4d> , e.g., pop-ups) gets weighted the same as a discoverability of 1 and everything else 10 (hard to sort out, but causes the heat death of the universe). This is an obvious malfunction."
20:27:10  <str4d> dg: so do I. They have many other potentially-useful models and docs there.
20:27:31  <str4d> Anyone else have comments?
20:29:50  <str4d> If no-one else has comments yet, then we will move on to the next topic while you think.
20:30:05  <psi> no comments
20:31:03  <str4d> 1b) Discuss threat model (and update if needed).
20:31:17  <str4d> http://vekw35szhzysfq7cwsly37coegsnb4rrsggy5k4wtasa6c34gy5a.b32.i2p/en/docs/how/threat-model
20:31:18  * psi starts skimming threat model
20:31:39  <iRelay> Title: I2P's Threat Model - I2P (at vekw35szhzysfq7cwsly37coegsnb4rrsggy5k4wtasa6c34gy5a.b32.i2p)
20:31:47  <dg> I notice a rating?
20:31:50  <dg> Is this new?
20:32:04  <str4d> dg: I added the modified DREAD system.
20:32:12  <str4d> (in anticipation of no one having objections)
20:32:31  <str4d> (but not in anticipation of no comments at all :-P )
20:32:53  <str4d> The ratings are invalid.
20:33:03  <dg> It doesn't seem to match-
20:33:05  <dg> yeah
20:33:09  <str4d> (this is what I want to change in this meeting)
20:33:25  <str4d> While we are discussing the threat model itself, please think about possible ratings (for the next topic)
20:33:28  <dg> The design looks good so with actual values, I'd like it. We should order in value of severity too.
20:34:48  <str4d> Our threat model page does not follow the "standard" threat model layout (e.g. OWASP page)
20:35:04  <str4d>      Identify Security Objectives
20:35:05  <str4d>     Survey the Application
20:35:05  <str4d>     Decompose it
20:35:05  <str4d>     Identify Threats
20:35:05  <str4d>     Identify Vulnerabilities
20:35:08  <psi> we're going to duscuss the values of these rating now... or later?
20:35:50  <str4d> psi: next topic. Right now we are discussing the threat model itself - we can't rate threats if they are out-of-date.
20:35:58  <psi> right
20:36:17  <str4d> (And FYI meeting will end at 10PM UTC)
20:36:29  <str4d> (At least, I will be leaving then)
20:37:18  <str4d> The threat model page does not clearly identify our security objectives.
20:37:21  <dg> Where is everyone?
20:37:29  <dg> We can't operate with 3 people.
20:37:54  <str4d> topiltzin, hottuna, zzz, welterde, kytv: ping
20:37:55  <zzz> there is more to "formalizing" the model than just rating each element
20:37:56  <equinox> I think it is worth considering the methods outlined in todays guardian articles. The NSA tried to target the dev process
20:38:16  <str4d> zzz: I know, but we have to start somewhere.
20:38:18  <zzz> in particular, the major objection to our model is that we don't clearly specify what is in and what is out
20:38:40  <dg> What affects us and what doesn't?
20:38:43  <zzz> which is a step that would need to happen before rating, should we care to address the critics
20:39:23  <str4d> zzz: that is what we are doing now.
20:39:23  <str4d> <str4d> The threat model page does not clearly identify our security objectives.
20:39:29  <zzz> the major point of a threat model is to specify what's NOT in it, e.g. the NSA. Projects use that to wave their hands and say "not our problem, not in our threat model"
20:39:44  <zzz> we haven't done that.
20:40:07  <idog98@freenode> .
20:40:10  <str4d> Right. So let's do that.
20:40:29  <zzz> If we make a formal model and omit the NSA, we can then stop working on protocol obfuscation, and perhaps even stronger crypto.
20:40:42  <zzz> or, we could call that a copout.
20:41:18  <dg> From the start, it's clear that Tor can't save you from a GPA. Do we make this and other caveats clear?
20:41:26  <dg> and do we protect against NSA?
20:41:59  <str4d> Global adversaries (that can monitor the entire internet) are out by nature of the onion routing design.
20:42:18  <str4d> NSA, as big as it is, is not a global adversary.
20:42:37  <psi> the NSA as it is does have an extensive reach
20:42:38  <zzz> Most of the current model is aspirational, as we are too small to realistically counter may of the items atm
20:42:50  <dg> Would we protect against GPA with some of the things in our roadmap? ;)
20:42:52  <equinox> str4d: perhaps but they do work with others
20:43:01  <zzz> the traditional terminology is "state-level" adversary, e.g. NSA
20:43:03  <orion> GPA?
20:43:11  <str4d> equinox: likely.
20:43:13  <str4d> zzz: thanks.
20:43:18  <dg> Global Passive Adversary
20:43:56  <zzz> so if you want to make a strict model and exclude state-level, and use it to guide dev, then that would e.g. tell us not to work on obfuscation
20:44:47  <orion> It's a difficult enough task to maintain anonymity, let alone do obfuscation.
20:45:43  <zzz> critics love formal threat models... does having one only enable the trolls, or would it actually help us promote and dev?
20:45:53  <str4d> We have always stated that I2P does not do obfuscation (but not explicitly in the threat model)
20:46:19  <str4d> That is a fair point.
20:46:28  <Mathiasdm> a threat model is good for focus
20:46:34  <dg> The trolls have enough if they want to troll. Fuck that.
20:46:41  <Mathiasdm> trolls are always around, I wouldn't take those into account
20:46:43  <Mathiasdm> (sorry to jump in)
20:46:51  <str4d> My goal with this meeting was not to have a strict threat model that we must absolutely follow to the letter.
20:47:02  <str4d> Even if we wanted to have that, it would not be possible in a single meeting.
20:47:25  <dg> No problem. Nice to see you, Mathiasdm.
20:47:28  <dg> A formal threat model helps us to define what we're trying to protect against either
20:47:37  <dg> I've been around for almost a year and I'm still not sure exactly what.
20:47:40  <str4d> The website page we call the "threat model" is a giant WoT and difficult to grep. That is really what I want to fix.
20:48:20  <str4d> I want users to be able to look at it and quickly understand what we are trying to do.
20:48:50  <equinox> We know the state agencies and actors on behalf of the state will only increase their scope as time goes on (if they are left unchecked). I think it is best to plan for that eventuallity rather than reacting to it.
20:49:16  <str4d> Because misinformation and misunderstanding have been a problem with I2P for a long time.
20:50:28  <zzz> I think the page is pretty good. Although perhaps it needs another page that's a summary.
20:51:12  <str4d> The threat risk modelling (with DREAD) is something that is easy to do, and easy to remove if we decide that it doesn't give us valid information.
20:51:57  <str4d> zzz: it is good for someone who is prepared to take the time to read it. It is not good for skimmers.
20:52:36  <str4d> As the post I linked above says: "Warning! Do NOT apply this system, or any other system, without THINKING about it. This system may or may not help you arrive at the right conclusion, and if it does not, consider worth what you paid to get it, which is zero."
20:53:26  <zzz> imho you have 3 orthogonal goals for the single page: 1) simplifying for the masses, 2) formalizing, and 3) risk modelling
20:54:38  <str4d> 1) and 3) are linked - having the ratings enables the masses to skim, find the "important" ones to them, and read.
20:54:49  <str4d> But I agree that 2) is orthogonal (and also linked to 3) )
20:56:04  <str4d> If having a formal threat model becomes a blocker to other things, then we will need to pursue it. But when I originally said "formalize", I should have said "clarify".
20:57:43  <str4d> Quick poll: does anyone here think that going through and applying DREAD to the attack vectors on our "threat model" page is useful or a good idea?
20:58:28  <str4d> If yes, let's move to next topic and do so, then we can discuss the result. If no, let's forget about it and move on.
20:58:44  <topiltzin> yes-as-long-as-its-someone-else-doing-it
20:58:46  <dg> What's the alternative?
20:59:09  <dg> hahaha
20:59:21  <topiltzin> being honest :)
20:59:37  <dg> or depressing. :)
21:02:00  <hottuna> It isn't a bad idea but, I'm not sure that is the be-all-end-all solution for the threat model.
21:02:06  <psi> hmm
<str4d> hottuna: I don't intend it as such, but I think it is a useful step. And no one else was suggesting or doing anything :-P
<psi> it depends if there are more people helping
<psi> if it's just 1 person no way
<psi> if there are collaborators, possibly
<str4d> psi: I wanted to do it in-meeting right now, while we had more than one person.
<zzz> "formalizing" is important to some - OpenITP, critics, reviewers, auditors, funders, others in our field, etc.
<hottuna> would it really be enough and structured well enough to just do it now in this meeting?
<hottuna> im not very familiar with the whole DREAD process though.
<str4d> hottuna: we go through each attack vector, and rate the five categories as low, medium or high. That's all. 
<psi> i am not familiar with DREAD as well
<str4d> I chose that one because it was very simple to apply.
<psi> ah
<str4d> (The five categories I outlined just above the index on the threat model page)
<psi> let's try an example one
<hottuna> each known attack vector?
<hottuna> psi, sure
<str4d> I intentionally did everything beforehand to make it simple because I knew that getting anyone here to agree to do this would be hard :P
<str4d> Okay, "timing attacks"
<hottuna> sure.
<str4d> Damage Potential: If a threat exploit occurs, how much damage will be caused?
<str4d> If it is used to identify a user, then that user is deanonymized -> high?
<hottuna> statistical exploits based on timing and packet sizes have been employed against tor to successfully find out which site was being visited
<hottuna> with very high success ratios (~90% if I remember correctly)
<str4d> (use e.g. https://www.owasp.org/index.php/Threat_Risk_Modeling#DREAD to get an idea of scales - it already has three levels described)
<str4d> Reliability: How reliable is the attack? - low? med? It is generally network-load-dependent.
21:12:28  <psi> to be able to time what exactly?
21:13:26  <hottuna> anything in general?
21:14:11  <psi> okay
21:14:27  <hottuna> I don't know.
21:14:47  <hottuna> But the descriptions seems messgae oriented.
21:14:52  <str4d> (use e.g. https://www.owasp.org/index.php/Threat_Risk_Modeling#DREAD to get an idea of scales - it already has three levels described)
21:14:54  <iRelay> Title: Threat Risk Modeling - OWASP (at www.owasp.org)
21:14:56  <str4d> Reliability: How reliable is the attack? - low? med? It is generally network-load-dependent.
21:15:33  <str4d> psi: that's a good point - the "Timing attacks" section should probably be split into message-delivery attacks and message-content attacks
21:15:36  <hottuna> damage potential: 5?
21:15:51  <str4d> Assume message-delivery for now.
21:15:55  <psi> " Complete system or data destruction " means the box explodes i assume?
21:16:08  <hottuna> as far as reliability goes, statistical models have been proven reliable in the case of tor..
21:18:00  <str4d> hottuna: we are using a 1-3 scale
21:19:08  <str4d> the 1-10 scale described in the OWASP is harder to justify.
21:19:08  <str4d> "What's the difference between discoverability of 6 and 7? Who the heck knows?"
21:19:08  <str4d> Use the OWASP scale as an indicator of how to assign low/med/high
21:19:11  <str4d> psi: In our case, I would say that "high" is complete correlation between a particular user and their activity.
21:19:13  <psi> timing i'd say 5 or 6
21:19:13  <psi> (for dammage)
21:19:14  <str4d> (for Damage)
21:19:17  <str4d> https://blogs.msdn.com/b/david_leblanc/archive/2007/08/13/dreadful.aspx explains the categories possibly better.
21:20:00  <psi> i see
21:20:16  <hottuna> but the damage would be revealing some sort of information, which may be bad.. theoretically it could reveal that I'm running a certain application or talking to a certain destination
21:20:20  <hottuna> is that a 5-6?
21:20:34  <str4d> Exploitability: What is needed to exploit this threat? - med? The attacker needs to monitor several locations along the possible path.
21:20:36  <str4d> low?
21:20:49  <psi> it depends on the attacker
21:20:55  <psi> and it also depends on the network size
21:21:34  <str4d> Exploitability is requirements before launching the attack. Reliability is how well it works once triggered.
21:21:48  <psi> ah
21:21:49  <str4d> psi: yes, so these ratings will change over time.
21:22:05  <str4d> (And this is an example of a limitation of the model, and a big flaw in the original DREAD)
21:22:06  <psi> exploitability would be med
21:22:18  <str4d> Exploitability is only used to calculate priority, not severity.
21:22:25  <psi> just running a stock i2p router would be not enough
21:22:54  <str4d> psi: right, so not high.
21:23:15  <str4d> But not low because it doesn't need advanced computing power etc.
21:23:20  <str4d> Affected Users: How many users will be affected?
21:23:27  <hottuna> You would have to be a part of a tunnel, and then just have a look at the message profile. If you're the ibgw for a service, you might be able to separate out a few users from the rest. Or at least cluster them inte different user groups
21:23:40  <hottuna> into*
21:24:23  <psi> mid may be a hit much for exploitability
21:24:29  <psi> bit*
21:24:36  <psi> mid-low
21:24:40  <hottuna> in the ibg case, I'd say it's pretty easy, but you wouldnt get a ton of information
21:24:45  <hottuna> ibgw*
21:25:06  <str4d> psi: mid or low. It will only affect the priority score.
21:25:48  <hottuna> As far as eploitability goes, I think it's very doable. Especially in comparison to other exploits.
21:25:55  <str4d> Discoverability: How easy is it to discover this threat? - mid? It requires at least some knowledge of how I2P works.
21:25:59  <psi> hottuna: agreeed
21:26:10  <str4d> "Something that's highly discoverable is publicly known, or very similar to something that is publicly known. Low discoverability is that it takes intimate knowledge of the internal workings of your app to sort out."
21:26:22  <psi> mid
21:26:51  <hottuna> We would never know about the attack since it's passive
21:26:55  <str4d> hottuna: exactly. The classification partly depends on what is chosen for other attacks. It's all relative.
21:27:26  <hottuna> str4d, are you noting some sort of value based on what's being said?
21:27:44  <str4d> hottuna: yes.
21:29:02  <hottuna> good.
21:29:02  <hottuna> D: low
21:29:19  <psi> hmm
21:29:29  <hottuna> Affected users: High (all who actually do something)
21:29:37  <str4d> Here's what I think we agreed on, and what it calculates:
21:29:37  <str4d>     Damage Potential: medium
21:29:37  <str4d>     Reliability: medium
21:29:37  <str4d>     Exploitability: medium
21:29:51  <str4d>     Affected Users: high
21:29:52  <str4d>     Discoverability: medium
21:29:53  <str4d>     Severity: 4/5
21:29:54  <str4d>     Priority: 5/9
21:30:23  <psi> timing attacks are pretty bad but they don't seem practical
21:30:29  <psi> at least, at the moment
21:30:41  <str4d> Does that seem like a sensible result? Are the levels I set what we actually decided on?
21:30:58  <hottuna> I dont agree with discoverability.
21:31:01  <str4d> And we should do at least one other attack vector, to get a sense of how this will compare them.
21:31:09  <hottuna> A passively logging node would never be discovered.
21:31:17  <str4d> hottuna: you think it should be high?
21:31:17  <hottuna> Sure.
21:31:29  <str4d> hottuna: wrong "discoverability".
21:31:47  <hottuna> whatever undiscoverable translates into
21:31:53  <str4d> This is a defensive model. This is discoverability of the vulnerability by the attacker.
21:32:00  <psi> the resources used to launch an attack would be rather obvious unless they pwnd all the boxes
21:32:12  <hottuna> oh. I see.
21:32:18  <dg> Timing attacks are specific and maybe not as applicable to us anyway..
21:32:25  <hottuna> Oh, in that case I agree.
21:33:28  <psi> to do a timing attack would require either a birds eye view or ownership of many nodes (how many? idk)
21:33:38  <str4d> Severity is how bad we think the attack is, Priority is the order it thinks we should focus on.
21:33:55  <dg> Oh.
21:33:55  <psi> not sure if a bird's eye view would be enough too
21:33:57  <dg> Yeah, 4/5.
21:34:10  <str4d> Let's leave that classification for now, and do another one for comparison.
21:34:30  <psi> reflecting on 4/5 IF they can do timing attacks then pretty much everything low latency is affect
21:34:33  <psi> affected*
21:34:54  <psi> priority... not sure 5/9 is appropriate
21:35:15  <str4d> "Tagging attacks" should be easy to classify.
21:35:32  <str4d> psi: we won't know what priority means until we have more classified. Classification is an iterative process.
21:35:38  <psi> okay
21:35:48  <str4d> So, tagging attacks.
21:36:15  <psi> tagging messages? tagging routers?
21:36:48  <str4d> Messages
21:36:59  <str4d> (kinda)
21:37:07  <str4d> Determining what path a message follows.
21:37:17  <str4d> Damage potential: mid?
21:37:30  <psi> mid agreed
21:37:38  <psi> low in a sense
21:37:43  <hottuna> Damage potential: lo
21:37:47  <hottuna> low-mid
21:37:58  <str4d> Tagging (if possible) is only going to reveal info within a particular. tunnel
21:37:58  <psi> it depends on the situation
21:38:01  <str4d> Reliability: low.
21:38:01  <psi> yea
21:38:08  <str4d> Or...
21:38:10  <str4d> Hmm.
21:38:41  <psi> on what scope would the tagging be measured at?
21:38:58  <hottuna> if they were used in a situation where they could identify tunnel participants, they woulkd work every time, right?
21:39:00  <str4d> Exploitability and discoverability are low - it should be impossible to tag messages themselves, and collusion requires exact placement of routers.
21:39:20  <hottuna> E:low
21:39:21  <str4d> psi: a message going between two endpoints (a client or server).
21:39:23  <hottuna> D: low
21:39:39  <psi> i agree LOW
21:39:45  <psi> E and D
21:39:50  <str4d> hottuna: exactly. If a tagging attack was discovered, it would work every time.
21:40:13  <hottuna> so, R: high?
21:40:21  <str4d> But such discovery should be impossible because everything is signed.
21:40:51  <str4d> But it depends on the tagging attack.
21:40:56  <str4d> Message tagging: high.
21:40:57  <psi> if they have your keys then they can sign too
21:41:06  <str4d> Collusion tagging: mid.
21:41:07  <hottuna> str4d, sure, but discoverability is another metric
21:41:13  * str4d says high for now.
21:41:28  * hottuna is sattisfied
21:41:44  <str4d> Affected users: only users with malicious nodes in their tunnels are affected.
21:42:02  <psi> low
21:42:16  <hottuna> A: most likely low
21:42:26  <str4d> Okay:
21:42:26  <str4d>     Damage Potential: low
21:42:27  <str4d>     Reliability: high
21:42:27  <str4d>     Exploitability: low
21:42:27  <str4d>     Affected Users: low
21:42:27  <str4d>     Discoverability: low
21:42:28  <str4d>     Severity: 2/5
21:42:29  <str4d>     Priority: 2/9
21:42:52  <hottuna> looks good
21:42:59  <psi> sounds good
21:43:22  <str4d> feels good
21:43:57  <hottuna> onto an actual threat?
21:44:28  <str4d> Shall we quickly go through the remaining meeting topics, and then come back to this?
21:44:37  <hottuna> ok
21:44:56  * str4d culls 4) Docs discussion, it will take too long.
21:45:12  <str4d> 2) Website revamp - check over in preparation for launch.
21:45:35  <psi> the site revamp is applying better CSS or is there more?
21:45:48  <str4d> Apart from this classification process (or removing the classifications), what else needs doing before welterde "launches" the site revamp?
21:46:12  <hottuna> I dont know.
21:46:21  <str4d> psi: "better" CSS, but a lot of structural and layout changes.
21:46:32  <str4d> I think structurally, everything is ready.
21:46:50  <hottuna> How automatic is the translation update process?
21:46:50  <str4d> Completely.
21:47:06  <hottuna> How frequent is it?
21:47:28  <str4d> Whenever I update it.
21:47:45  <hottuna> Ok.
21:47:48  <str4d> So far, whenever I have seen string changes I run the scripts to extract and update the translation strings.
21:47:50  <psi> i need to jet ill bbl in 30 minutes
21:47:56  <hottuna> I suppose that is good enough.
21:48:01  * str4d will be gone by then.
21:48:30  <str4d> psi: you're welcome to continue the DREAD discussion then :)
21:48:44  <hottuna> oh, str4d: the giant download button on the front page doesnt seem to auto update to the latest version
21:48:45  <str4d> There are known CSS problems in IE 7 and 8 IIRC
21:49:00  <str4d> hottuna: that is another bug that I need to talk with welterde about.
21:49:09  <hottuna> ok. good.
21:49:25  <str4d> Whenever a .py file changes, a script is meant to restart the server (and whenever translations change, it recompiles them)
21:49:49  <str4d> But for some reason, changes to .py files are not being detected on welterde's server...
21:49:49  <str4d> (They were before)
21:50:24  <str4d> Okay, if there is nothing else, then I
21:50:43  <str4d> 'm happy with the revamp and once the .py bug is fixed, it can go live.
21:50:52  <hottuna> Alright!
21:51:11  <str4d> (IE 7/8 CSS will be mitigated when I get a chance, but I don't consider it a blocker)
21:51:23  <hottuna> Sounds reasonable.
21:51:42  <str4d> "live" == welterde will make it live at https://geti2p.net (the URL we decided on several meetings ago), but leave www.i2p2.de as-is.
21:51:52  <iRelay> Title: I2P Anonymous Network - I2P (at geti2p.net)
21:52:00  <hottuna> Why will i2p2.de be left as it is?
21:52:03  <str4d> Then I will run tests, check Google etc. are happy with it.
21:52:30  <str4d> hottuna: in case something catastrophic happens and we need to revert.
21:52:42  <hottuna> ok, so it's just temporary
21:52:51  <str4d> Only when everything is absolutely checked and ready, will we 301 redirect i2p2.de to geti2p.net
21:53:15  <hottuna> that makes sense
21:53:23  <str4d> Because 301 is a permanent move, and will cause search engines to update their links.
21:54:08  <str4d> The legacy redirection code uses 302 redirects for now, but will be changed to 301 once everything is set (so that we don't lose pagerank from old links)
21:54:28  <str4d> Okay, moving on:
21:54:28  <str4d> 3) Roadmapping.
21:54:42  <str4d> hottuna: your turn.
21:55:44  <str4d> You have about ten minutes of my time (maybe more for anyone else who is still here)
21:55:45  <hottuna> roadmap? All I know is that I've been having a little more time as of late, and I've been getting back into looking at the DHT code. Especially the reply handling code.
21:56:08  <hottuna> I don't really have anything else to add.
21:56:48  <str4d> The current roadmap for 0.9:
21:56:48  <str4d>     Include some seed data in the distribution so a central reseed location isn't required?
21:56:48  <str4d>     Reachability Mapping / handle peers partially reachable / enhanced restricted routes
21:56:49  <str4d>     Improve help pages and website
21:56:49  <str4d>     More translations
21:56:56  <str4d>     SSU disconnect message
21:56:57  <str4d>     Iterative floodfill lookups
21:57:13  <str4d> I have no idea where we are on some of that, or when it was last updated.
21:57:54  <hottuna> The floodfill lookups are iterative as far as I understand them.
21:57:59  <str4d> 1.0 - 3.0 were last updated in 2008.
21:58:14  <str4d> 0.9 was added in 2010.
21:58:14  <dg> restricted routes is unlikely
21:58:37  <hottuna> I'll have to go in a minute or two
21:58:42  <str4d> I think proper evaluation of the roadmap needs another meeting, with more attendance.
21:59:01  <hottuna> Agreed.
21:59:14  <str4d> hottuna: good to hear you are getting back into the DHT code.
21:59:29  <str4d> Deferring until later.
21:59:33  <hottuna> And the actual threat model should be looked after.
21:59:43  <str4d> Okay.
21:59:47  <hottuna> Could we have a long meeting next time for that?
22:00:35  <str4d> hottuna: I had hoped 2 hours would be enough, but we spent at least an hour debating whether it was even worth doing >_<
22:00:36  <hottuna> I've gotta leave, but thanks for the meeting str4d. You're a natural!
22:01:19  <str4d> We don't have time to return to 1c), so:
22:01:23  <str4d> str4d *baf*s the meeting closed