A per browser salt is a wonderful idea. It's basically impossible to fake even small key poems or whatever if you cannot guess their salt. Just some thoughts : - The salt should be a text field users can interact with easily. It could be displayed prominently in the extensions config, or even with the key poem or whatever. - Initially (no pre-existing salt) the salt should be set to contain a few dictionary words, maybe using a call to key poem routines. Using dictionary words makes it easier for users to copy the salt between machines. - Ideally, the initial salt should be set using machine specific information, like CPU ids or default mac address or whatever, instead of a temporary random number, so a clean reinstall of the operating system should produce the same salt. - Upgrades should attempt to preserve the salt. Tails should attempt to persist the salt too, but ideally TBB should produce the same salt when run on under Tails on the same machine without persistent storage. If machine identifiers cannot be used, then maybe Tails could set the salt when the boot image is created. - Documentation should recommend that users who fear targeted attacks set a stronger salt and advice that all users share the same salt across all their machines. There could be buttons to create a random strong salt and reset the salt to the machine's default. - Ideally, the documentation should explain that if you want to compare representations with another person then you should use a temporary salt, so as not to reveal your usual salt. On Thu, 2015-08-20 at 15:47 +0000, Yawning Angel wrote: > It was a hypothetical example. If we're willing to go with the visual > equivalent of key poems (which is what my suggestion roughly > corresponds to) with a per-client secret to prevent brute forcing, then > there's no reason why we couldn't let the user choose a visual > representation they're most comfortable with. Yeah, if there are multiple representations then users could simply select the ones they like. If someone wants to do a research project on visually recognizing key material then they can add an option to the extension. I'd expect card hands, mahjong tiles, etc. suck for most users, btw. I wonder if memes like lolcats might make an good compromise for the different memorability constraints. It could be as simple as an image database with associated keywords, a dictionary, and word transition probabilities. If we've a per browser salt, then one could simply select a unix fortune cookie or something similarly entertaining but low entropy. > > Perhaps a notification "You've never visited this site before" that > > pushes down from the top like some other notifications might go a long > > way? > > People would likely complain about storing "did access foo.onion in the > past" type information to disk. I could argue for/against "well, use a > per-client keyed bloom filter, false positive rate!!!!", but depending > on the adversary model, people will probably (rightfully) be uneasy at > the thought of persisting even that. > > The moment people are willing to store "I accessed this onion in the > past", I'm inclined to think "this is functionally equivalent to the > user bookmarking said onion". Yes exactly. In fact, if you've added the bookmark star to FireFox's toolbar then it changes color when you visit a bookmarked page, so you could already do this by bookmarking the site's root and briefly returning to it to check. Another idea : If the users has added the bookmark star to FireFox's toolbar, and bookmarked anyplace on the site but not the exact page, then the bookmark star changes to another color to indicate the site has been visited before, and lets users quickly find all the bookmarks on that site. Jeff
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev