here<\/a> for web IRC access).<\/p>\nBootstrapping Accountability in the Internet We Have<\/strong><\/p>\n(9:01:51 AM) <\/span><\/span>smowton: Ang Li, Xin Liu and Xiaowei Yang
\n(9:02:04 AM) <\/span><\/span>malte: \"the internet was designed in the old time\"
\n(9:02:47 AM) <\/span><\/span>smowton: They're worried about \"traffic hijacking,\" defined as advertising prefixes you don't own
\n(9:02:48 AM) <\/span><\/span>malte: example: Pakistan YouTube incident
\n(9:02:59 AM) <\/span><\/span>smowton: and also plain old DDOS
\n(9:03:48 AM) <\/span><\/span>smowton: morning Theo
\n(9:03:52 AM) <\/span><\/span>twh25: afternoon!
\n(9:04:04 AM) <\/span><\/span>smowton: motivating example: Wikileaks supression
\n(9:04:12 AM) <\/span><\/span>malte: Attacks are bad: disruptive, politically motivated, costly
\n(9:05:26 AM) <\/span><\/span>malte: Largest DDoS attack observed in practice has exceeded 100 Gbps
\n(9:06:17 AM) <\/span><\/span>malte: Question: Can we make the intertubes secure?
\n(9:06:20 AM) <\/span><\/span>smowton: Challenge: secure the internet in a way that's incrementally deployable *and* helps early adopters
\n(9:07:13 AM) <\/span><\/span>smowton: previous work: secure BGP (BGP + signing)
\n(9:07:27 AM) <\/span><\/span>malte: There are various existing approaches: Secure BGP, packet source authentication
\n(9:07:41 AM) <\/span><\/span>malte: reference for the latter: \"Packet passport\" in NSDI 2008
\n(9:07:49 AM) <\/span><\/span>smowton: Other previous work: source-signing, in which packets contain unforgable source information to prevent spoofing
\n(9:08:11 AM) <\/span><\/span>smowton: Natural application to preventing DoS as you know who's actually doing it
\n(9:08:24 AM) <\/span><\/span>malte: What's missing? Why is the internet so vulnerable?
\n(9:09:24 AM) <\/span><\/span>malte: two types of \"natural identifiers\" in the internet: (1) IP addresses, (2) IP prefixes
\n(9:09:51 AM) <\/span><\/span>malte: but they cannot be used for accountability (\"identify bad guys\") because they can be spoofed, like all network-layer identifiers
\n(9:10:05 AM) <\/span><\/span>smowton1: they introduce \"IPA\", IP-made-accountable, which tries to produce non-spoofable network identifiers
\n(9:11:24 AM) <\/span><\/span>smowton1: Criticism of existing approaches:
\n(9:11:32 AM) <\/span><\/span>smowton1: PKIs require heavyweight deployment
\n(9:11:36 AM) <\/span><\/span>smowton1: web-of-trust isn't reliable
\n(9:11:44 AM) <\/span><\/span>smowton1: and self-signing has obvious problems
\n(9:13:05 AM) <\/span><\/span>smowton1: proposal: use DNSSEC and BGP to serve the role of a PKI
\n(9:14:16 AM) <\/span><\/span>smowton: In the case of DNSSEC, this means using a reverse-resolution record as proof of ownership of some IP range
\n(9:14:55 AM) <\/span><\/span>smowton: or rather, attesting to your owning a keypair that you will use to sign source addresses
\n(9:15:23 AM) <\/span><\/span>mas90: that's pretty cool. I bet the IETF would love that
\n(9:16:18 AM) <\/span><\/span>smowton: Apparently there's a break in the chain of trust between in-addr.arpa and root allocators like ARIN; just an administrative thing though
\n(9:16:55 AM) <\/span><\/span>smowton: the top-level guys would just assert ownership of some key, but presumably SSH-style has-the-key-changed will suffice for something so commonly encountered
\n(9:16:59 AM) <\/span><\/span>malte: (and supposedly to be resolved shortly: \"by end of March\")
\n(9:16:59 AM) <\/span><\/span>mas90: ha
\n(9:16:59 AM) <\/span><\/span>mas90: better be quick :)
\n(9:17:56 AM) <\/span><\/span>malte: certificate distribution is supposed to be \"in-band\", by piggy-backing on BGP announcements
\n(9:18:07 AM) <\/span><\/span>smowton: BGP messages enclose certificates in the obvious way, a la HTTPS supplying the complete cert chain
\n(9:18:19 AM) <\/span><\/span>malte: the data would go into \"optional\" and \"transitive\" path attributes
\n(9:18:34 AM) <\/span><\/span>smowton: the chain should mirror netblock delegation
\n(9:19:20 AM) <\/span><\/span>malte: Each certificate is ~650 bytes
\n(9:19:31 AM) <\/span><\/span>smowton: They're concerned about overhead, and solve it by sending only unsent certificates
\n(9:19:45 AM) <\/span><\/span>smowton: but really, how significant is the complete throughput of BGP relative to actual dataplane traffic?
\n(9:19:47 AM) <\/span><\/span>malte: in order to avoid sending those big-ish certs all over the place all the time, the certs relating to neighbours are cached
\n(9:20:07 AM) <\/span><\/span>malte: smowton: agreed
\n(9:20:41 AM) <\/span><\/span>smowton: cert revocation is done in the ordinary existing fashion: revocation lists (eagerly flooded to your delegatees) and expiry dates
\n(9:22:41 AM) <\/span><\/span>malte: eval in terms of three dimensions: performance, security and adoptability
\n(9:23:52 AM) <\/span><\/span>malte: for time's sake, they only present the overhead on normal BGP and some adoptability analysis in the talk
\n(9:24:35 AM) <\/span><\/span>malte: their BGP trace contains a total of 118M updates, with ~44 occuring per second
\n(9:25:08 AM) <\/span><\/span>smowton: they measure in terms of bytes\/second for a BGP speaker taking part in their protocol but otherwise exchanging the same updates as a real-world speaker
\n(9:25:36 AM) <\/span><\/span>smowton: they find some examples of updates that would take 60 seconds to process
\n(9:25:43 AM) <\/span><\/span>smowton: but 99.4% would be <= 30s
\n(9:26:06 AM) <\/span><\/span>smowton: presumably this would get better as routers are already expensive; could include some specialist crypto h\/w
\n(9:26:42 AM) <\/span><\/span>smowton: adpotability problem: there's a Cisco router that explodes when they set their cert attribugte
\n(9:26:53 AM) <\/span><\/span>smowton: mundane bug
\n(9:27:25 AM) <\/span><\/span>smowton: this is their incremental adpoptability: BGP speakers will preserve their new attributes even if they don't understand them themselves
\n(9:28:33 AM) <\/span><\/span>smowton: and that's that<\/p>\n <\/p>\n
Privad: Practical Privacy in Online Advertising<\/strong><\/p>\n09:35 < malte> Next talk: Serving ads from localhost for Performance, Privacy and Profit
\n09:35 < malte> Saikat Guha, Microsoft Research India; Bin Cheng and Paul Francis, MPI-SWS
\n09:35 < avsm> woah cool, usenix is serving ipv6 dhcp!
\n09:36 < malte> experimental talk: he's going to keep the talk short and leave lots of time for questions
\n09:36 < malte> Today's web ads suck: quality sucks, so flood users with lots of them
\n09:36 < malte> loading ads from third-party servers slows down page rending
\n09:37 < malte> the way it works today is that a \"broker\" of some sort (e.g. Google) marries advertisers' ads to publisher websites
\n09:38 < malte> money flows from advertisers to brokers to publisers
\n09:38 < malte> users don't get a cent
\n09:38 < mas90> users are the saleable product :-)
\n09:39 < smowton> users get content :)
\n09:39 < malte> cookies leak information to ad broker -- Google knows every page we visit
\n09:39 < smowton> problem: persistent cookies as the broker domain is the same even if the site is different
\n09:40 < smowton> they're worried that an evil employee will sell the Google Ads database
\n09:40 < smowton> Goal: work in the current world
\n09:40 < malte> including \"the current click-fraud model\" :-)
\n09:41 < malte> they define privacy as \"unlinkability\"
\n09:41 < smowton> \"private enough\"
\n09:41 < smowton> keep the tracking-for-targeted-ads thing without letting anyone know who you are
\n09:42 < smowton> basically because otherwise only the altruistic advertisers will adopt
\n09:42 < malte> at the same time, they don't want to trade off privacy for poorer advert quality
\n09:42 < smowton> and there are obvious problems with that sentence :)
\n09:42 < smowton> \"Scalable: yada yada yada\"
\n09:43 < malte> fundamental decision: the most trusted entity in the advertising ecosystem is the client's own computer
\n09:44 < malte> they are wondering what data *needs* to leave the local system
\n09:44 < malte> they could achieve privacy by either having an anonymization network in between the user and the broker (e.g. Tor)
\n09:45 < malte> but the problem with that is that it doesn't allow detection of click fraud
\n09:45 < smowton> problem: most anonymisation protocols would make the ad-broker vulnerable to click fraud
\n09:45 < malte> so they introduce another party called the \"dealer\"
\n09:45 < malte> they assume that the dealer and the broker don't ever collude
\n09:46 < smowton> the dealer anonymises and filters for fraud
\n09:46 < smowton> the broker plays his old role but with anonymised input
\n09:46 < malte> the local agent monitors user behaviour and builds a local user profile
\n09:46 < smowton> why would anyone be a dealer?
\n09:47 < malte> broker sends a bunch of ads to the dealer, who then sub-selects the ones to present to the user
\n09:47 < malte> the agent has got a local cache of ads that is populated by the dealer
\n09:47 < malte> (question: how does the broker know that the ads have actually been viewed?)
\n09:48 < malte> (their solution is that the client reports ad event to the dealer, who reports to the broker... but that assumes that both agent and dealer are honest)
\n09:48 < smowton> the dealer seems like a vague creature; this basically moves the risk from the broker to the dealer
\n09:49 < smowton> ah, the ad reports are encrypted; the dealer can't peek
\n09:49 < malte> actually, they use PKI to sign the reports so that the dealer can't modify them
\n09:49 < smowton> assuming again he doesn't collaborate with the broker
\n09:49 < malte> it only strips the private information
\n09:49 < malte> *he
\n09:49 < smowton> which here == IP
\n09:50 < malte> now he's asking people what they want to know more about
\n09:52 < malte> Q: is the user profile information actually safe on the user's own machine?
\n09:52 < malte> A: probably more so than anywhere else...
\n09:53 < malte> Q: is this really compatible with the current ad model? Does it support CPI and CPC models?
\n09:54 < malte> A: Yes, all of view\/click\/other events can be reported through their ad event reporting system
\n09:55 < smowton> A: yup
\n09:55 < smowton> Q: why would a broker trust dealers to stay functional?
\n09:56 -!- googie [80e80ef5@gateway\/web\/freenode\/ip.128.232.14.245] has joined #nsdi11
\n09:57 < smowton> A: They can use the privacy benefits as a selling point
\n09:58 < smowton> but ad-vendors don't really sell to users
\n09:58 < smowton> I could see tinfoil-hat websites that desperately need ad revenue selling it to their user
\n09:58 < smowton> but pretty much only them
\n09:58 < smowton> Aside: they don't care about AdBlock: it works either way, and only 12% of people use them
\n09:59 < smowton> I'm actually surprised how high that figure is
\n09:59 < malte> indeed
\n09:59 < malte> looks like people in Saudi Arabi haven't been educated about spyware toolbars yet ;-) (40% install third-party tool bars)
\n10:00 < smowton> Q: why-t-f would you be a dealer? how will you make money?
\n10:00 < smowton> A: they won't; they'll be run as a public service by the EFF or someone like that
\n10:00 < smowton> Alternatively, MS could be both -- with appropriate legal oversight
\n10:01 < smowton> seems to me like the same deal as laws requiring them not to be evil in using their ad data
\n10:01 < smowton> I suppose so long as no one angry employee has the keys to the dealer's logs and the broker's logs also...
\n10:02 < malte> Q: How do you prove to me that the local agent tool (supplied by YOU) is not going to act as spyware and leak my data?
\n10:02 < smowton> ooooh, answered a question by \"removing the weasel words\"
\n10:02 < smowton> take that, wikipedia
\n10:03 < smowton> it's 10:03; the Usenix heavies are descending
\n10:05 < malte> opinion: nice talk as it was controversial and incited discussion, and the presenter is actually keen on this stuff
\n10:05 < malte> but I don't really buy the architecture
\n10:05 < smowton> yup same
\n10:05 < smowton> like most things, no incentive to improve without direct pressure from the users
\n10:06 < smowton> and most people don't know or care about the problem
\n10:06 < smowton> alright
\n10:06 < smowton> next talk<\/p>\n
Bazaar: Strengthening User Reputations in Online Marketplaces<\/strong><\/p>\n(10:06:47 AM) <\/span><\/span>smowton: Ansley Post,\u00c2\u00a0MPI-SWS and Rice University;\u00c2\u00a0Vijit Shah and Alan Mislove,\u00c2\u00a0Northeastern University<\/span>
\n(10:07:21 AM) <\/span><\/span>smowton: Marketplaces are what you might suppose: eBay et al
\n(10:07:32 AM) <\/span><\/span>smowton: point being, untrusted people trading with others
\n(10:08:54 AM) <\/span><\/span>smowton: economists observe that your eBay reputation does matter
\n(10:09:00 AM) <\/span><\/span>smowton: you'll get more money for the same item
\n(10:09:06 AM) <\/span><\/span>smowton: but: accounts can be created for free
\n(10:09:30 AM) <\/span><\/span>smowton: so can start anew
\n(10:09:33 AM) <\/span><\/span>smowton: or, can collude
\n(10:10:38 AM) <\/span><\/span>smowton: apparently there are often very cheap listings that have \"positive feedback guaranteed\"
\n(10:11:13 AM) <\/span><\/span>smowton: Potential solutions:
\n(10:11:24 AM) <\/span><\/span>smowton: 1. Make it hard to join to begin with, e.g. must present some ID
\n(10:11:34 AM) <\/span><\/span>smowton: sucks because it's a barrier to honest people too
\n(10:11:44 AM) <\/span><\/span>smowton: 2. Use escrow, but only appropriate for expensive things
\n(10:12:24 AM) <\/span><\/span>smowton: 3. Transactions happen in person; the website just pairs you up. Problem: transfers online fraud to plain old mundane mugging
\n(10:12:36 AM) <\/span><\/span>smowton: 4. Insurance: spreads the cost
\n(10:14:09 AM) <\/span><\/span>smowton: Their solution keeps existing feedback systems but tries to bound fraud
\n(10:15:37 AM) <\/span><\/span>smowton: They build a \"risk graph\": accounts that have traded are joined by an edge weighted by dollar amount
\n(10:16:09 AM) <\/span><\/span>smowton: Turst = max-flow between buyer and seller
\n(10:16:29 AM) <\/span><\/span>smowton: presmably the hope is that fraudulent people will be walled off from honest ones by negative-feedback edges
\n(10:16:59 AM) <\/span><\/span>malte: I don't quite see how this solves the sybil attack problem
\n(10:17:09 AM) <\/span><\/span>smowton: trading with your own sockpuppets doesn't help as they're a clique
\n(10:17:15 AM) <\/span><\/span>smowton: they might as well be the same person
\n(10:17:19 AM) <\/span><\/span>malte: ah, I see
\n(10:17:23 AM) <\/span><\/span>malte: yeah
\n(10:17:37 AM) <\/span><\/span>avsm: cunning
\n(10:18:05 AM) <\/span><\/span>mrry: nice aspect of this is that, at least on eBay, you have to pay a %age fee, so there is cost to building up these edges (if you're only pretending to sell things)
\n(10:18:05 AM) <\/span><\/span>malte: unless of course you make your sockpuppets do a bunch of genuine transactions in order to link them into the honest network
\n(10:18:35 AM) <\/span><\/span>smowton: sure, so you're required to be at least X% honest
\n(10:18:41 AM) <\/span><\/span>smowton: I think this is the strong bound on fraud
\n(10:18:42 AM) <\/span><\/span>mrry: @malte, you'd still have to make large transactions with your sockpuppets, which would be expensive
\n(10:19:17 AM) <\/span><\/span>malte: mrry: yeah, point taken - you can't trade a bunch of 50c items and then defraud someone for $5000 as you don't have enough flow
\n(10:19:34 AM) <\/span><\/span>smowton: your best bet would be to genuinely be an honest trader for a few months
\n(10:19:47 AM) <\/span><\/span>smowton: then quickly make off with everyone's wallet whilst they're still in the dark
\n(10:21:42 AM) <\/span><\/span>smowton: aha, this is challenge #1
\n(10:21:58 AM) <\/span><\/span>smowton: the ability to steal a lot of cash before the users realise
\n(10:22:12 AM) <\/span><\/span>smowton: solution: your edge is suspended whilst there's an outstanding transaction
\n(10:22:22 AM) <\/span><\/span>smowton: limits the volume of trade you can perform if your reputation is low
\n(10:22:29 AM) <\/span><\/span>smowton: seems reasonable with or without bazaar
\n(10:23:46 AM) <\/span><\/span>malte: same principle as the London tube Oyster charging system :-)
\n(10:24:04 AM) <\/span><\/span>twh25: ?
\n(10:24:30 AM) <\/span><\/span>smowton: challenge #2: how to induct new users? Friends can vouch, lending their credability, or can do link-escrow (buy your initial credability, I think)
\n(10:24:41 AM) <\/span><\/span>malte: (Oyster deducts the maximum fare while you're en-route, then credits you when you touch out)
\n(10:25:32 AM) <\/span><\/span>smowton: problem: max-flow over a large graph is expensive.
\n(10:26:06 AM) <\/span><\/span>smowton: They assert real-world graphs are usually of a shape that makes this okay
\n(10:26:30 AM) <\/span><\/span>smowton: and also note we only need a vague is-it-greater-than-X answer, not the true result
\n(10:27:38 AM) <\/span><\/span>smowton: cunning technique for cheap maxflow: construct log(n) [where n is the highest weight link] graphs where graph i is restricted to edges with weight >= 2^i
\n(10:28:04 AM) <\/span><\/span>smowton: for big sellers you'll find that the sparse top-level graph says yes right away
\n(10:28:27 AM) <\/span><\/span>malte: in fact, if you assume that the majority of your sellers is honest, your performance is okay
\n(10:28:29 AM) <\/span><\/span>smowton: only need to check the lowest-level full graph if your maxflow would be very small
\n(10:28:49 AM) <\/span><\/span>smowton: Eval:
\n(10:29:18 AM) <\/span><\/span>smowton: crawled a 90-day trace of ebay (8m auctions)
\n(10:29:46 AM) <\/span><\/span>smowton: used 80% to form a risk network using observed feedback
\n(10:30:12 AM) <\/span><\/span>smowton: remaining 20% used to test
\n(10:30:36 AM) <\/span><\/span>smowton: found that total amount users could steal is always <= their previous successful transactions
\n(10:30:44 AM) <\/span><\/span>smowton: sounds like something that could be proved rather than experimented :)
\n(10:30:57 AM) <\/span><\/span>malte: yeah, surely that's a fundamental property of their system?
\n(10:31:20 AM) <\/span><\/span>smowton: <5% false positive rate
\n(10:31:36 AM) <\/span><\/span>smowton: where that means it flags an auction that actually led to positive feedback
\n(10:31:48 AM) <\/span><\/span>smowton: they blame their lack of knowledge before 90 days ago<\/p>\nDewdrop: An Energy-Aware Runtime for Computational RFID<\/strong><\/p>\n(11:03:11 AM) <\/span><\/span>smowton: defn: \"computational RFID\" = computer that works solely using RF energy
\n(11:04:00 AM) <\/span><\/span>smowton: scenario: pervasive monitoring for the elderly
\n(11:04:30 AM) <\/span><\/span>malte: (or, alternatively, government surveillance and spying :-P)
\n(11:04:32 AM) <\/span><\/span>smowton: they don't like cameras for this purpose, due to privacy concerns
\n(11:04:47 AM) <\/span><\/span>smowton: motes are neat but battery powered
\n(11:06:19 AM) <\/span><\/span>smowton: so, let's use computational RFIDs, in which the reader powers the thing but it can do some on-board computation (and storage?)