Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

i2pbote delay: per ID and pre message [0.02 BTC] (Trac #1451) #39

Closed
str4d opened this issue Apr 16, 2017 · 1 comment
Closed

i2pbote delay: per ID and pre message [0.02 BTC] (Trac #1451) #39

str4d opened this issue Apr 16, 2017 · 1 comment

Comments

@str4d
Copy link
Member

str4d commented Apr 16, 2017

( I offer small tip of 0.01 Bitcoin - so a beer at current prices - for who ever implements this, e.g. from
https://blockchain.info/address/152fnfBqRjVMDvRa5LQ2upx9tJAeHnyqHC )

To not repeat security mistakes of Freemail, FMS we need better random-delay settings.

No setting should be global, as it lowers security somewhat by correlating all your IDs if you use nonstandard settings.

  • number of hops to use
  • random delay at each hop min..max time
  • frequency of checking for new mail

This should be configured for each identity (on creation of identity, with default value taken from the current global settings)

Also, when composing a new message, it should again ask for settings related to sending:

  • hops
  • delay at each hop

To not require user to have javascript, I propose adding following options:

From [ ..... ] (the same as it exists now)
Security: number of hops: [x] use default for selected sender,
... or deselect above checkbox and select value here: [...]
Security: delay at each hop: [x] use default for selected sender,
... or deselect above checkbox and select value here: min [...] max [...] minutes


PART B, additional 0.01 BTC:

ALSO, few details about delay of "cronjobs" - especially the "check email" action:
For each account, where T is the configured time of action, e.g. 10 minutes for "check email each 10 minutes":
and L option:
Sometimes pretend to be offline for up to .... hours to make others confused about when your computer is online.

  1. At start, job should delay random(T0 to T2)
  2. After running the check, job should schedule next run, to be randomly between time from now
    sleeptime = random(T0.5 to T1.5)
    if random(0..100) is < 30 then sleeptime += randomGauss(0 to L/5)
    if random(0..100) is < 10 then sleeptime += randomGauss(0 to L)

choose the scheduled time: ID.nextrun = now() + sleeptime

OTHER IDEA (for future)

Add options
[ ] fake random timezone (can delay actions like message check or send for up to 1 day)

on ID creation set ID.timezone
choose a random timezone, based on amount of darknet users in given timezone, including at least:
all USA time zones separately, USA Eastern, USA Pacific, .... , Timezones for Europea, Timezones for Russia
at least 10 timezones, with weighted probability correlating to say number of tor users or something.

Now look at ID.nextrun scheduled in previous points.
Convert it to a day, in the ID.timezone.

If (ID.behaviour == type1) then
start = hour 8:00 of that day // wake up
end = hour 23:00 of that day // go to sleep

If ID.nextrun < start, then ID.nextrun = start; // wait until user "wakes up"
if ID.nextrun > end, then change to next day, and run algorightm again // user sleeps already

if time was changed as above, then add random(0,T*0.1) + randomGauss(0.5,1.5)

(Future idea: take into account: other pattern (only in morning and evening, not "in work"),
and randomly based on ID.skipwork chance (e.g. 1%) use other behaviour)

Make above scheduling be used for checking messages, but also to sending messages (otherwise they are placed in a queue, with a checkbox to bypass fake timezone on message composing)

Migrated from https://trac.i2p2.de/ticket/1451

{
    "status": "closed", 
    "changetime": "2015-01-30T13:03:06", 
    "description": "( I offer small tip of 0.01 Bitcoin - so a beer at current prices - for who ever implements this, e.g. from\nhttps://blockchain.info/address/152fnfBqRjVMDvRa5LQ2upx9tJAeHnyqHC )\n\nTo not repeat security mistakes of Freemail, FMS we need better random-delay settings.\n\nNo setting should be global, as it lowers security somewhat by correlating all your IDs if you use nonstandard settings.\n\n- number of hops to use\n- random delay at each hop min..max time\n- frequency of checking for new mail\n\nThis should be configured for each identity (on creation of identity, with default value taken from the current global settings)\n\nAlso, when composing a new message, it should again ask for settings related to sending:\n- hops\n- delay at each hop\n\nTo not require user to have javascript, I propose adding following options:\n\nFrom [ ..... ]  (the same as it exists now)\nSecurity: number of hops: [x] use default for selected sender,\n... or deselect above checkbox and select value here: [...]\nSecurity: delay at each hop: [x] use default for selected sender,\n... or deselect above checkbox and select value here: min [...] max [...] minutes\n\n--------------------------------------------------------------------------------------\n\nPART B, additional 0.01 BTC:\n\n\nALSO, few details about delay of \"cronjobs\" - especially the \"check email\" action:\nFor each account, where T is the configured time of action, e.g. 10 minutes for \"check email each 10 minutes\":\nand L option:\nSometimes pretend to be offline for up to .... hours to make others confused about when your computer is online.\n\n1) At start, job should delay random(T*0 to T*2)\n2) After running the check, job should schedule next run, to be randomly between time from now \n  sleeptime = random(T*0.5 to T*1.5) \n  if random(0..100) is < 30 then sleeptime += randomGauss(0 to L/5)\n  if random(0..100) is < 10 then sleeptime += randomGauss(0 to L)\n\nchoose the scheduled time: ID.nextrun = now() + sleeptime\n\n\n\n\n3)\nOTHER IDEA (for future)\n\nAdd options \n[ ] fake random timezone (can delay actions like message check or send for up to 1 day)\n\non ID creation set ID.timezone \nchoose a random timezone, based on amount of darknet users in given timezone, including at least:\nall USA time zones separately, USA Eastern, USA Pacific, .... , Timezones for Europea, Timezones for Russia \nat least 10 timezones, with weighted probability correlating to say number of tor users or something.\n\nNow look at ID.nextrun scheduled in previous points.\nConvert it to a day, in the ID.timezone.\n\nIf (ID.behaviour == type1) then\nstart = hour 8:00 of that day // wake up\nend = hour 23:00 of that day // go to sleep\n\nIf ID.nextrun < start, then ID.nextrun = start; // wait until user \"wakes up\"\nif ID.nextrun > end, then change to next day, and run algorightm again // user sleeps already\n\nif time was changed as above, then add random(0,T*0.1) + randomGauss(0.5,1.5)\n\n(Future idea: take into account: other pattern (only in morning and evening, not \"in work\"),\nand randomly based on ID.skipwork chance (e.g. 1%) use other behaviour)\n\nMake above scheduling be used for checking messages, but also to sending messages (otherwise they are placed in a queue, with a checkbox to bypass fake timezone on message composing)\n\n\n\n\n\n\n\n", 
    "reporter": "rfree", 
    "cc": "", 
    "resolution": "duplicate", 
    "_ts": "1422622986247309", 
    "component": "apps/plugins", 
    "summary": "i2pbote delay: per ID and pre message [0.02 BTC]", 
    "priority": "obsolete", 
    "keywords": "I2P-Bote", 
    "version": "0.9.17", 
    "parents": "", 
    "time": "2015-01-30T12:19:23", 
    "milestone": "undecided", 
    "owner": "", 
    "type": "enhancement"
}
@str4d
Copy link
Member Author

str4d commented Apr 17, 2017

Trac update at 20150130T13:03:06:

  • killyourtv changed priority from "minor" to "obsolete"
  • killyourtv changed resolution from "" to "duplicate"
  • killyourtv changed status from "new" to "closed"
  • killyourtv changed type from "defect" to "enhancement"

@str4d str4d closed this as completed Apr 17, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant