| | 1 | = [wiki:Summit 2nd Summit] Day 2 = |
| | 2 | |
| | 3 | 09-Nov-2011, Mozilla SF. |
| | 4 | |
| | 5 | == Attendees == |
| | 6 | * Zack Weinberg |
| | 7 | * Zooko |
| | 8 | * David-Sarah |
| | 9 | * Brian |
| | 10 | * Shawn |
| | 11 | * Mark Seaborn |
| | 12 | |
| | 13 | == Ideas == |
| | 14 | - Shawn: would be nice to have a more traditional username/password web frontend |
| | 15 | - I (warner)'m imagining an IService, listening for HTTP on a different port |
| | 16 | than the main WEBAPI port, with a public URL. You submit |
| | 17 | username+password, get a cookie, present a filename. The gateway |
| | 18 | translates that into a filecap. |
| | 19 | - maybe store one rootcap per username. use bcrypt/scrypt to defer |
| | 20 | exposure until user submits password. |
| | 21 | - adding ACLs: either put a table in the frontend (username->file |
| | 22 | list), or put ACL data in dirnode edge metadata and have frontend |
| | 23 | compare it against a username |
| | 24 | - sharing to public: tell frontend a filename/dirname and ask to make |
| | 25 | it public, it returns a tinyurl. Just like a tinyurl except it's a |
| | 26 | proxy instead of a redirect. |
| | 27 | - sharing to an individual: maybe have an encryption pubkey for each |
| | 28 | account, Alice tells frontend "share my ~/foo with user=Bob", |
| | 29 | frontend encrypts a note to itself with Kbob, later when Bob logs in, |
| | 30 | his password bcrypt-unlocks the decryption key Kbobpriv, decrypts the |
| | 31 | note, gets the dircap, adds to a table for Bob, lets him enumerate a |
| | 32 | list of inbound shared directories |
| | 33 | - zwol describing a Tor project, making Tor traffic look like other |
| | 34 | traffic: WoW, other web browsing. "Stegatorus"? |
| | 35 | - zwol thinking about censorship-resistance, content-centric networking |
| | 36 | |
| | 37 | == Control Panel == |
| | 38 | - Brian explained requirements for a tahoe web-control-panel: |
| | 39 | - examine/control Agent things like periodic backup jobs (local dir, |
| | 40 | dircap, schedule, status, progress), lease-renewal/repair jobs |
| | 41 | (dircap, schedule, status, progress) |
| | 42 | - not using browser ambient authority, accessed through NODEDIR (iff |
| | 43 | you can read/write to NODEDIR/private, you should be able to get to |
| | 44 | the Web Control Panel), |
| | 45 | - not scoped to a particular filecap/dircap |
| | 46 | - yes scoped to "client authority" (i.e. an "Account", q.v. Accounting, |
| | 47 | for general uploads and maybe repair), or local-disk-authority |
| | 48 | (backup jobs), or server admin (for the server side of Accounting) |
| | 49 | - ok to have no-JS and yes-JS options, ok if the no-JS option is less |
| | 50 | pleasant |
| | 51 | - David-Sarah, Zack, Shawn designed a scheme |
| | 52 | - writes a "control.html" into NODEDIR/private/ |
| | 53 | - "tahoe control" launches browser with {{{file://.../control.html}}} |
| | 54 | - yes-JS version: |
| | 55 | - it contains one big {{{<iframe src="http://WUI/control#SECRET">}}} |
| | 56 | - that page contains JS which pulls the secret out of the fragment, |
| | 57 | then does lots of XHR with the secret to present the control panel |
| | 58 | - no-JS version: |
| | 59 | - it contains a form with a big "Start" button and a secret in a |
| | 60 | hidden form-post argument |
| | 61 | - that returns a page with lots of forms, secrets in hidden |
| | 62 | post-args. All links are POSTs. "back" won't be pleasant (requires |
| | 63 | a 're-submit form?' confirmation each time). |
| | 64 | - benefits: keep secret out of address bar, out of Referrer header |
| | 65 | - other useful techniques: |
| | 66 | - to limit the lifetime of a powerful secret, 'tahoe control' can write |
| | 67 | a new secret into NODEDIR just before launching the browser, and the |
| | 68 | node can erase or change the secret just after accepting the |
| | 69 | resulting browser hit. |
| | 70 | - splitting the webapi into multiple origins is becoming more |
| | 71 | important: probably starting with one port for (control-panel, |
| | 72 | welcome, node-status, WUI-dirnodes, download-only WAPI), and a second |
| | 73 | one for (WUI-documents) that could be executable. |
| | 74 | |
| | 75 | == Accounting Review == |
| | 76 | - Brian presented his Accounting branch |
| | 77 | (https://github.com/warner/tahoe-lafs/tree/accounting) , only looking |
| | 78 | at the delta between the '466-ed25519' branch and the 'accounting' |
| | 79 | branch (it builds upon the #466 work) |
| | 80 | - deferred discussion of leasedb crawler and race conditions, that |
| | 81 | requires more serious design work. David-Sarah and Brian will huddle on |
| | 82 | it, probably online later |
| | 83 | - approach seemed good, code is still incomplete |
| | 84 | - needs: more tests, usable control panel, refinement of "account |
| | 85 | message" concept |
| | 86 | - need to carefully plan the merge with LAE's s3-backend: they overlap a |
| | 87 | lot. Removing leases from shares helps a bunch. s3-backend introduces |
| | 88 | async share-crawlers, accounting removes one big crawler but adds a new |
| | 89 | small one, which might need to be async-ified if that still seems like |
| | 90 | a good idea. |
| | 91 | - consensus was that #466 should definitely land first. But then whether |
| | 92 | accounting should land before s3-backend, or other way around, was |
| | 93 | unclear. accounting needs more development work before it's ready for |
| | 94 | landing, s3-backend might be closer. But some co-evolution and |
| | 95 | anticipatory refactoring should make things easier for everybody. |
| | 96 | - brief discussion about branches in Git vs Darcs, specifically for |
| | 97 | working on projects like this. Brian anticipates pain and suffering |
| | 98 | trying to test merges of s3-backend (managed in a darcs branch) with |
| | 99 | his accounting work (managed in git branches). David-Sarah suggested |
| | 100 | applying the git/darcs bridge on a branch too, brian skeptical. |
