Open str4d opened 7 years ago
Trac update at 20150130T13:03:37: killyourtv changed type from "defect" to "enhancement"
Trac update at 20150205T04:53:00:
Great ideas, but too many in one ticket, and a duplicate. I have moved your Part B comment to #25, and created #40 for your third idea.
In future, please open separate tickets for separate ideas. If you have an idea that has several sub-ideas, please create a parent ticket and then make subtickets for each sub-idea.
( 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
3) 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)
to:
( 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
Trac update at 20150805T06:43:18:
6ffbe5b58daf9f95ccd51f61740b27289ac63da1
earlier this year implemented per-identity settings (as part of implementing #24), and as part of that implemented most of the backend required for this ticket. Identities now support individual config of all the above settings (except new mail frequency, see #24).Still to be done:
- UI for configuring per-identity
- UI and backend for configuring per-message
Trac update at 20150805T06:51:22:
( 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.
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:
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
Migrated from https://trac.i2p2.de/ticket/1450