"Uber security breach may have affected up to 50,000 drivers"

http://www.latimes.com/business/technology/la-fi-tn-uber-data-breach-20150227-story.html

:D


On 27/02/15 18:54, Adam Gibson wrote:
> Thanks for all the info.
> Did it ever reach the stage of a github repo? I couldn't see one. Not
> that it's purely code of course, but still.
>
> I'd love to see some work on it. What spare time I have is going to
> joinmarket right now, and a bit of tlsnotary. Otherwise I'd love to
> help, or at least find out more about it.
>
> Agoristradio was great. A bit rough around the edges compared to what
> you do now Adam, but it was a definite fav :)
>
> Yeah there's not much to say about Roadie (and I'm pretty sure I've
> seen one or two other similar setups, although not sure how far
> along). Like Uber, it might be more immediately significant than a
> decentralised option, because the centralization makes it so much
> easier, but I can't see how it could be co-opted or leveraged, maybe I
> lack the imagination to see it..
>
> Building decentralized Uber has been sitting there waiting for someone
> to do it already for ages, but it's really hard because it gets right
> into the reputation/trust issue. It's notable to me that 15 years ago
> I remember using "decentralised Uber" in Russia (by which I mean -
> just wave your hand and get a ride from any stranger). Western
> "consumers" are so soft-edged that they will reject anything that
> doesn't have a perfect veneer of safety and comfort.
>
> Hmm maybe that's Cody's point. Uber as a trojan horse sort of thing.
> Uber has no "moat" to use business parlance. Ordinary people get
> behind it because it's the easy option, then Uber uses the consumer as
> leverage to break the monopolies, then the decentralised option steal
> all its business when the consumers realise they don't have to pay
> Uber a cut. Well, nice dream.
>
> Decentralised marketplace (OpenBazaar), uncensorable and untraceable
> payment (stealth addresses, coinjoin), decentralized delivery
> (bitdrop?). I think the only block is the reputation/identity issue.
>
>
> On 02/27/2015 05:10 PM, Adam B. Levine wrote:
> > There was a minimal amount of work done on Bitdrop, I found the
> > project after it had been dead for about six months and got
> > involved trying to put together a team which was going well until
> > nef disappeared.
>
> > Yes, onion routing was always part of the vision.
>
> > I don't think there's any problem with you posting Hiro's podast,
> > he hasn't been around for quite some time and was a very open
> > source guy.
>
> > Yes, I have seen Roadie - Roadie strikes me as egold, they have
> > founders they have servers they do matchmaking it's pretty
> > straightforward as a comparison. The only reason you get
> > something like Bitdrop is because its the best option in a sea of
> > bad options, otherwise it's not worth reinventing and boostrapping
> > such a network.
>
> > So my timeline for something like Bitdrop not only existing but
> > making sense is about 10 years from now after we've seen the rise
> > and subsequent fall of things like Roadie, Uber, etc. Really it's
> > all the same thing, just that bitdrop is for long distance stuff
> > (Whether a person or a human, you'll probably be going more than
> > just one leg of a journey) and a fully distributed uber would
> > usually have the same guy pick you up and drop you off at your
> > destination.
>
> > If it's in the same system, that's not actually a given - All
> > people/parcels wind up looking the same because even if its only a
> > dropoff to the next leg of a route to the person doing the
> > dropping off it looks exactly the same. They gave it to someone
> > else, whether its the destination or not.
>
> > One thing we spent a lot of time thinking about was verifiability
> > which is a damn hard problem, but to which there are definite
> > solutions. My favorite part is the local redistribution scenarios
> > which if you've ever worked in distribution or redistribution
> > makes ages more sense than the way we do things now shipping from
> > distant centralized locations.
>
> > On a related note, anybody want to do an episode of LTB about this
> > with me? I've been looking for an excuse for quite some time and
> > if there is interest we could at least do a nice think-out that
> > would get gears turning in listener heads. If there was desire to
> > actually push on the project this would be a good way to kickstart
> > that too. Hit me in a seperate email if you're interested
> > (adam@??? <mailto:adam@letstalkbitcoin.com>)
>
>
> > Here's something else from the archives. ---
>
> > (11:18:00 AM) hercules/: Hey Voodoo (11:18:31 AM) voodoo: hey!
> > (11:20:53 AM) hercules/: Was thinking I might have answered the
> > question wrong there for a sec, Nef just ran with it, didn't
> > actually come up with it (11:21:03 AM) voodoo: oh, really?
> > (11:21:17 AM) hercules/: You havn't read the original thread?
> > (11:21:33 AM) voodoo: where, on the bitcoin forums? (11:21:33 AM)
> > hercules/: There is a public record of the creation of the Bitdrop
> > concept, its pretty neat (11:21:35 AM) hercules/: yeah (11:21:50
> > AM) hercules/: it was in a thread on a robotic courier service
> > someone thought was a good idea (11:22:02 AM) voodoo: I have, but
> > it's been a while (11:22:12 AM) hercules/: anyhow, we were both
> > thinking nef hehe (11:22:16 AM) voodoo: I remembered nefario as
> > bing OP (11:22:18 AM) hercules/: So you had questions (11:23:38
> > AM) voodoo: yeah...I'm trying to separate *basic function* from
> > *security* from *biz model* while keeping all three in mind
> > (11:24:29 AM) voodoo: so, I'm just putting down desired behaviors
> > for each object referenced on that doc you sent me (11:24:36 AM)
> > hercules/: ok (11:25:28 AM) voodoo: so, it's a complicated problem
> > and I've attacked first as a 2d problem - getting a package from
> > one point to another (11:26:02 AM) voodoo: not too tough, but
> > really it's a 3d problem with really interesting temporal hurdles
> > (11:26:11 AM) hercules/: and bootstrapping issues (11:26:23 AM)
> > voodoo: oh yeah (11:26:27 AM) hercules/: like crazy (11:26:32 AM)
> > hercules/: that's what keeps me up (11:27:15 AM) voodoo: so, lets
> > start with easy stuff - I'm going to try to paste this (11:27:20
> > AM) hercules/: ok (11:27:26 AM) voodoo: Node: Can have holder role
> > With holder role: Has a location Can have runner role With runner
> > role: Has a maximum travel radius Has a maximum volume Has a
> > maximum weight Has a maximum single package volume Has a maximum
> > single package weight Can have router role With router role: Has a
> > schedule Has an origin Has an endpoint Has a maximum volume Has a
> > maximum weight Has a maximum single package volume Has a maximum
> > single package weight Has a minimum payout_expectation Has an
> > identifier identifier: Has a text description Expires Can have a
> > “job hunt” mode In “job hunt” mode: Reports its location to the
> > server every XXX seconds. Can have a “static” mode In “static” mode
> > Has a location (11:27:40 AM) hercules/: Did that paste properly? or
> > is it a table (11:28:01 AM) voodoo: It looks ok from here - it's an
> > outline (11:28:08 AM) hercules/: ok (11:28:35 AM) voodoo: so a node
> > can have a role and other attributes based on the role (11:28:49
> > AM) voodoo: and then mode (11:29:02 AM) hercules/: And you're
> > envisioning temporary text descriptors? (11:29:34 AM) voodoo: on
> > what? (11:29:46 AM) hercules/: Everyone has to have an identifier
> > in this layout, right? (11:30:03 AM) hercules/: The two fields you
> > have for that are text and expiration (11:30:21 AM) voodoo: yes, as
> > written, that's true, but really only runners and routers would
> > have that (11:30:27 AM) hercules/: Sorry, I'm focusing on details -
> > What's the bigger picture question? (11:30:36 AM) voodoo: first
> > note for myself :-) (11:31:30 AM) voodoo: so the doc you sent me
> > said a node in "job hunt" mode would be eligible for jobs within a
> > set radius of current_location (11:31:59 AM) voodoo: but, really
> > wouldn't they be eligible for jobs in a radius based on a fixed
> > point (11:32:07 AM) voodoo: centered on a fixed point? (11:32:10
> > AM) hercules/: it depends (11:32:34 AM) hercules/: The doc
> > envisions two types of terminals used for receiving missions
> > invites (11:32:55 AM) hercules/: A stationary one (home/base) and a
> > mobile one that floats based on your phones rough location
> > (11:33:31 AM) hercules/: some people will spend lots of time at a
> > central base, but I know lots of other people who spend their time
> > driving all over major cities (11:34:01 AM) hercules/: SUre they
> > could set the radius as the whole city, but really what they want
> > is to know about pickups that are near where they are right then
> > when they're looking (11:34:15 AM) voodoo: ok, but if my phone and
> > I are at the edge of my radius based on fixed point, then travel
> > could be up to 50% greater than I've specified (11:34:28 AM)
> > hercules/: you don't have to say yes (11:34:59 AM) hercules/: I
> > was thinking the mobile one would have a much smaller radius than
> > the standard fixed (11:35:25 AM) hercules/: someone in a car might
> > be willing to go 5 miles out of their way when they're on the
> > road, while someone operating from a home base might have a range
> > of 20 miles in any direction (11:35:41 AM) hercules/: that of
> > course assumes a town, not a city, as cities will be much easier
> > with the higher density (11:35:58 AM) voodoo: OK (11:36:14 AM)
> > voodoo: that may be a moot point, though depending on some other
> > things (11:36:18 AM) hercules/: I agree (11:36:41 AM) voodoo: the
> > doc said the runner shouldn't be able to select the location for
> > handoff (11:36:45 AM) voodoo: however... (11:36:53 AM) hercules/:
> > well, we've gone back and forth on that (11:37:10 AM) voodoo:
> > bootstrapping is already a problem, and I think I may have a neat
> > solution to that (11:37:41 AM) hercules/: That falls under
> > security - The more "the system" handles by itself, the more secure
> > we are and the fewer interceptions we'll have (11:37:55 AM)
> > hercules/: regarding runner location selection (11:38:39 AM)
> > voodoo: right. So how about we allow a runner to designate multiple
> > points where he/she feels comfortable doing handoffs, and
> > distance/direction they are willing to travel from there (11:39:04
> > AM) voodoo: and then the system can use those multiple points in
> > the route calculation to a) help it create routes (11:39:20 AM)
> > voodoo: and b) randomize the handoff locations (11:39:26 AM)
> > hercules/: My concern is always with interceptions when we talk
> > about pre-set rendezvous that local carriers can monopolize
> > (11:39:46 AM) voodoo: where the receiving node is
> > psuedo-determining location (11:39:48 AM) hercules/: We as humans
> > like set patterns, but it screams "ambush me" (11:40:16 AM)
> > hercules/: right, but that's just as difficult as sending a couple
> > packages from different places in a city to figure out the popular
> > rendezvous (11:40:23 AM) hercules/: I think it can be a hybrid
> > solution (11:41:04 AM) hercules/: In dense areas, online mapping
> > and social media have done a good job of mapping out most
> > restaurants, recreational shit, etc. (11:41:34 AM) hercules/: in
> > those situations, the system should just pick meetup locations that
> > overlap delivery areas, no selection from users (11:42:19 AM)
> > hercules/: But in more sparse areas, where we'd be using GPS
> > coords, or just in general we have a harder time with routing then
> > I can see a multiple user selected option (11:42:43 AM) hercules/:
> > Where we have density, the system needs to just make the right
> > choices and not give any options (11:43:19 AM) voodoo: just to be
> > clear, I'm not suggesting the users select, just that we use their
> > localized knowledge to generate a db of handoff locations (11:43:43
> > AM) hercules/: I'm not fundamentally opposed, it just blinks red at
> > me (11:44:06 AM) hercules/: AFK about 45 minutes (11:44:21 AM)
> > hercules/: feel free to ask further stuff, I'll address when I get
> > back (11:44:27 AM) hercules/: we're going to get together as a
> > group soon (11:44:53 AM) hercules/: AFK (11:48:40 AM) voodoo: ...
> > (11:48:41 AM) voodoo: ... (11:48:47 AM) voodoo: <hr> (11:50:06 AM)
> > voodoo: so, based on all that, we run smack into the temporal
> > problem - a node in "job hunt" mode can only be assigned to one
> > (maybe, MAYBE two)-leg routes (11:50:53 AM) voodoo: IOW, the pickup
> > and final_desitnation points are both within the radius of that
> > node (11:51:22 AM) voodoo:
> >
> .....................................................................................................................
>
>
>
> (11:52:51 AM) voodoo: next: Package, no problem:
> > (11:52:53 AM) voodoo: Package: Has a type # letter, box, crate
> > With types box and crate Has a height Has a length Has a width Has
> > a weight Has a QR code Has a tracking ID (11:53:09 AM) voodoo:
> >
> ................................................................................................................................
>
>
>
> (11:53:29 AM) voodoo: Job:
> > Has at least one Package Has a final_destination Has an
> > intermediate_destination Newly created: Has a location Triggers
> > Route.seek(job.location) In-transit: Has a current_node (11:55:05
> > AM) voodoo: ............ again, not much controversial in the Job,
> > yet (the accounting and interfaces are going to be the biggest
> > chunk of Job) (11:55:19 AM) voodoo:
> >
> ......................................................................................................................................
>
>
>
> (11:55:31 AM) voodoo: now, the fun part, Route
> > (11:56:17 AM) voodoo: this is where all the temporal problems
> > become mountains (11:56:20 AM) voodoo: Route: Has at least one Leg
> > Seeking: First Leg: Finds Nodes where job.location is within
> > node.radius(node.current_location) && node.mode == “job hunt” Low
> > Price: For each node in first_leg: Calculates all possible routes
> > to job.final_destination where !first_leg.include?(Node) # kata
> > harry potter Assigns lowest-cost route to low_possible_route[node]
> > Low Four: Selects the four lowest-cost, unique low_possible_routes
> > Messages all nodes in low_four Fastest: Calculates all possible
> > routes to job.final_destination where !first_leg.include?(Node) #
> > kata harry potter Assigns most efficient route to
> > efficient_possible_route[node] Efficient Four: Selects the four
> > most-efficient, unique efficient_possible_routes Messages all
> > nodes in efficient_four Bid: Returns lowest-cost low_four where all
> > nodes accepted Returns lowest-cost efficient_four where all nodes
> > accepted Returns most-efficient efficient_four where all nodes
> > accepted Shipper Acceptance: For each node in accepted bid:
> > Creates a leg (11:57:45 AM) voodoo: ..................and, just
> > for reference,
> > Leg...................................................................
>
>
>
> (11:57:59 AM) voodoo: Leg:
> > Has a start_point Has a start_point_time Has an end_point Has an
> > end_point_time Has a node (11:58:06 AM) voodoo:
> >
> .......................................................................................
>
>
>
> (12:00:19 PM) voodoo: "efficient" is some measure based on directness of
> > route and working schedule of the nodes (12:02:04 PM) voodoo:
> > which, is the first temporal problem - any Node is going to have
> > to pre-determine a schedule for anything other than one-hop routes
> > to work (12:03:12 PM) voodoo: IOW, the system is going to need to
> > know which Nodes will be available for work at the approx. time
> > the package(s) would arrive at any given point (12:04:53 PM)
> > voodoo: and, it's going to have to be able to dynamically re-route
> > Jobs when the inevitable no-show occurs (12:07:43 PM) voodoo: and,
> > it's going to have to be sufficiently flexible to allow a Node to
> > accept multiple legs while being sufficiently strict as to prevent
> > a Node from accepting conflicting legs (12:16:09 PM) voodoo: all
> > while making it so that the current_node knows only where he's
> > going and what time to be there (12:16:24 PM) voodoo: and what the
> > pickup node will look like
>
> > Adam B. Levine Editor-in-Chief Let's Talk Bitcoin!
> > <http://www.letstalkbitcoin.com/>
>
> > On Thu, Feb 26, 2015 at 4:16 PM, Washington Sanchez
> > <washington.sanchez@???
> > <mailto:washington.sanchez@gmail.com>> wrote:
>
> > Well I'll take the opportunity to think crazy here:
>
> > Categorize the size of the package you want to deliver and match it
> > with the best transportation medium and range.
>
> > For example, small lightweight packages could probably be delivered
> > by drone-hopping.. the number of hops would determine the delivery
> > range. The flight-hop path alogrithm could access an API to a
> > prediction market (yet to be built on OpenBazaar, but doesn't have
> > to be OB) betting on the risk-of-interception within certain
> > regions of a locality... if the price of a certain region gets too
> > hot, the 'swarm' could alter it's flight-hop path to less risky
> > route(s).
>
> > On Fri, Feb 27, 2015 at 7:14 AM, Adam Gibson <ekaggata@???
> > <mailto:ekaggata@gmail.com>> wrote:
>
> > https://tlsnotary.org/cypherpunkd-EP043.mp3 - starts at about 35
> > minutes
>
> > Btw if someone wants me to take these down, I will of course.
>
> > Cheers, Adam
>
>
> > On 02/26/2015 11:01 PM, Adam Gibson wrote:
> >> Hmm just realise it's discussed in ep 43 also, I'll upload that.
>
> >> On 02/26/2015 10:55 PM, Adam Gibson wrote:
>
>
>
> >>>> Adam, do you have a link to that Agorist radio interview? I
> >>>> couldn't find it. Also, do you know if BitDrop is being
> >>>> developed or saw any development? I only saw an old
> >>>> BitcoinTalk thread, looked abandoned. Solid ideas on this
> >>>> topic are floating around, sounds like it's only a matter of
> >>>> time...
>
>
> >>> Sam, I'm guessing you meant the other Adam ;), but here you go:
> >>> https://tlsnotary.org/cypherpunkd-EP019.mp3
>
> >>> I think the onion routing idea was already there, I am not
> >>> original :)
>
> >>> It's near the end of the interview.
>
>
>
> > _______________________________________________ unSYSTEM mailing
> > list: http://unsystem.net
> > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>
>
>
>
> > -- ------------------------------------------- *Dr Washington Y.
> > Sanchez* Post-doctoral research officer Therapeutics Research
> > Centre University of Queensland Princess Alexandra Hospital
> > Woollongabba, 4102 Queensland, Australia
>
> > _______________________________________________ unSYSTEM mailing
> > list: http://unsystem.net
> > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>
>
>
>
> > _______________________________________________ unSYSTEM mailing
> > list: http://unsystem.net
> > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>
> _______________________________________________
> unSYSTEM mailing list: http://unsystem.net
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem