[tor-dev] GSoC: BridgeDB Twitter Distributor report

[Kostas Jakeliunas <kostas@xxxxxxxxxxxxxx>]

Hey all,

in the past weeks I've been working on understanding what can be done
using Twitter APIs and its media support in its CDN (for a later
captcha implementation), as well as on improving my existing Twitter
bridge distributor bot PoC. I've written some broken code, but it's
alright. More details below.


Distributor bot improvements included working on adding a churn rate
control mechanism which securely stores Twitter user IDs (with code
and design ideas from BridgeDB's HMAC approach to remembering e.g.
email addresses in the EmailDistributor), and implementing a (mostly)
bogus text-based challenge-response system (this is mostly so that we
have a generic design for doing challenge-responses in this
distributor - we'll be able to later on replace it with a decent
CAPTCHA, for example. It's just nice to have a generic system and a
thing for testing out the bot, etc.)

I've also looked into using isis' new and shiny BridgeRequest objects
to process user (well) 'bridge requests' in a non-hacky way; this
should also eventually result in a bridge request syntax compatible
with (a subset of) GetTor commands. But I still need to figure out the
best way to use BridgeRequests, so nothing interesting to show yet.

TODO

 * (still yet to) summarize a nice meeting i've had with sysrqb and
isis. No definite conclusions were made, but there were (iirc) some
nice ideas about a generic BridgeDB API that could be used by third
party components, etc. (i.e. it might be worth pursuing it even if the
Social Distributor is to be implemented at some later point.)

 * clean up my mess, test new code not to fail, and push new things
onto https://github.com/wfn/twidibot/ (current (old) code there does
work, if anyone's curious to run it)

 * figure out BridgeRequests, the new IRequestBridges (ha!) interface,
and use these in the twitter bot

 * be able to 'serve' the bot fake bridge data so it could process it
in a way that may be compatible with a future BridgeDB API (i.e.,
hopefully this bot will be able to run as a third-party-thing,
separate from core bridgedb. This is hopefully how future distributors
will/should work.) This way the bot will be more/actually 'realistic'
in the way it serves current bogus bridge lines to users. (I thought
I'd have this by now, but I don't. Hrm.)

 * continue looking into captcha systems modulo what can be used in
the twitter context

 * look into bridgedb buckets and what I can help re: them, so the
bridgedb API could happen sooner than later. (Old todo list item, did
not yet touch it.)

All in all, need to write more non-broken code, fewer words, and just
continue with the current bot.

Have a nice day/night/thing!

--

Kostas.

0x0e5dce45 @ pgp.mit.edu
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev