Illicit market for location proofs, have you considered this attack vector?


#1

What stops a market for proofs of location from popping up ? Im in Time Square, you’re not, but you can be, for the right price (i.e. I will sell you the private key owning the location proof).

I am playing a game, or driving a truck, or going on a sales call, or … and I need a proof that I am or have been at some location(s) … so I go to an online marketplace for location proofs and just buy one.

What mitigates this attack vector in FOAM ?


#2

I fail to see how this a legitimate attack vector. The only way that you can claim that /you/ have been somewhere is with your private key. So certainly, you can give someone your private key with all the risks that doing so entails and pay them to “be somewhere” on your behalf, and then you’re at risk of that person just cleaning out your wallet while they’re at it. In fact, it makes the most sense for me to just take any assets you have associated with that private key and the fee you paid for the presence claim than actually going out to make the claim as that would cost me nearly nothing.

Realistically, any application would want several presence claims (e.g., the truck should have several presence claims along its route, the sales call should show your last x minutes of travel to the destination) within a certain time range (i.e., it shouldn’t accept presence claims from a week ago when the delivery/sales call is tomorrow) which are difficult to create a priori. On the other hand, if you play a ludicrously inefficient game of just collecting presence claims and spending large quantities of FOAM on presence claims that you might never be able to sell, why don’t you just accept the bounty of the truck delivery or sales call for yourself instead (if that’s even acceptable, as a sensibly coded contract working against such presence claims would restrict only the driver/salesperson to claiming it).

To summarize, any consumer of such a market is putting themselves at risks of catastrophic loss so no sensible consumer would /want/ to pay for this, and the supply side of said market can be easily mitigated by adhering to sensible practices in applications that consume presence claims.


#3

I am buying a private key with an associated location proof attached to it, I have no asset at risk controlled by this key.

“any application would want several presence claims” … the illicit location proof market will just satisfy this requirement, the more requirements the higher the price of proof.

“if you play a ludicrously inefficient game of just collecting presence claims” … the proof merchants will just have little bots scattered in profitable high-demand locations to generate proofs on demand.


#4

The hardware would be secure, so extracting the key would be prohibitive.


#5

I am buying a private key with an associated location proof attached to it, I have no asset at risk controlled by this key.

The asset that you’re buying the key with is at risk. What’s stopping me from just taking the asset you’re paying for this private key and giving you garbage data? If you do this exchange on a blockchain via commit-reveal or something, then any frontrunners can easily claim ownership of the PK and do something with the claim you paid for. One way or the other, you’re either exposed to risk from the private key leaking or just being straight up scammed.

If you plan to use these once-off keypairs to claim some asset tied to location, then again, why would I give you the keypair when I can just take your money and claim the location-locked bounty for myself?

“if you play a ludicrously inefficient game of just collecting presence claims” … the proof merchants will just have little bots scattered in profitable high-demand locations to generate proofs on demand.

Any such demand can be mitigated with the axiom that a legitimate user wouldn’t want to ever reveal their private key for obvious reasons. Adequately coded applications built on top of the protocol that consume presence claims can restrict exactly which private keys/addresses can do something with a given set of presence claims.

If I’m paying you to make a sales visit or deliver a package, I can simply require that you give me your address before the bounty is even created (akin to entering into a traditional contract, it’s between the contract creator and a second party, not the contract creator and anybody). Then my contract will only disburse payment for presence claims that belong to the address of second party entered into contract with. To create presence claims with the second party’s address, they would would have to give up their private key to a supplier in this proof market. The supplier can then just claim the bounty for themselves as well as whatever you’re paying them to perform the service.

In the case of a game or something with less value at stake, then sure, such behaviors could make the game gameable. There are still additional logics on the application that can be imposed (e.g., time-restricting the transferability of assets earned in the game to reduce the threat of sybil behaviors) or simply inspecting what a user is doing with their accounts (are they flying around the world collecting presence claims faster than anything or anybody can physically travel? then they probably gave their private keys out to someone to rapidly collect rewards in this game and are cheating). Reputation systems can further mitigate this by limiting the viability of disposable accounts, e.g., you need to have performed some amount of interactions with the FOAM protocol before you can play a certain game, so if I have an address with a long history of legitimate-seeming behavior, I surely wouldn’t want to compromise its private key to play my favorite blockchain game.


#6

Any transaction consuming or attesting a presence claim can be expected to maintain a marginal balance in the public address controlled by the Private key, just as we have a minimum for POIs. Since a Presence claim is signed with a private key, they would also control additional assets, it would not be rationale game theory to divulge that Private Key.

Zone Anchors’ mediate presence claims based on Timing Bounds that will only correspond to geographical nearness. At the latencies the FOAM Protocol will operate at there will be no chance to relay a transaction or collude with other parties. Just as your phone waits longer and longer to let you retry a password. Zone Anchors’ may punish attempts to perform denial of service or malicious activity such as unwarranted delay would require. While it is possible that a Good Actor, could be delayed seconds in processing a claim in such a system due to a loss of signal or connection, appropriate metrics will be recorded to allow the correct amount of time of average connection attempts.

Better coverage by multiple Zone Anchors’ will also minimize transaction times. As a thought exercise this has been a good question.


#7

@Ryan_foam

The hardware would be secure, so extracting the key would be prohibitive.

I am buying the key and its proof(s), not stealing it.

@iostat :

What’s stopping me from just taking the asset you’re paying for this private key and giving you garbage data?

There marketplace will have a reputation score / reviews of the proof sellers.

If you do this exchange on a blockchain

No blockchain necessary, it can be done on a centralized marketplace server.

why would I give you the keypair when I can just take your money

The marketplace will reimburse me and ban you (the reimbursement could come from money that you you have to stake a seller, amount staked > value of proofs you’re selling).

my contract will only disburse payment for presence claims that belong to the address of second party entered into contract

The marketplace can satisfy this as well, sellers will offer fresh addresses that have not been seen in FOAM yet.

are they flying around the world collecting presence claims faster than anything or anybody can physically travel.

The gamer/buyer in Tokyo would game that by waiting X number of hours, X = travel time to NYC, before buying the NYC location proof.

Reputation systems can further mitigate this by limiting the viability of disposable accounts

True there can me measures taken at the app level, I’m just wondering if measures can be taken at the FOAM protocol layer.

@yinzeus

Any transaction consuming or attesting a presence claim can be expected to maintain a marginal balance in the public address controlled by the Private key

The seller adds the value of that marginal balance to the price of private key she’s selling.


#8

@Chomsky12
OK, let’s assume this centralized marketplace is trustworthy. The job of the protocol is to provide proofs that the controller of a particular private key was at a given place at a given time. If that is accomplished, then the protocol has done its job as intended. If some application utilizing the protocol has decided the only criteria necessary is a single (or set of) presence claim(s) to trigger some behavior, then that is for the application’s creator to decide. In a sense, what I think you’re suggesting here is a variant of a Sybil attack, and it’s not the protocol’s job to make applications on top of it Sybil-proof. This is not attacking the protocol, this is attacking an application. To reiterate, applications can protect themselves from this by introducing additional constraints besides “is there a presence claim” to trigger behavior. The FOAM protocol has worked as intended if the possessor of private key had physically been in a zone, paid that zone for a presence claim and received a valid, verifiable record of them being within the zone when they had done so. If the possessor of the private key then transfers their key to someone else, the protocol is not going to prevent that. A prudent developer building an application on FOAM would ideally be aware of this scenario, as this is, again, essentially a Sybil attack and very well known in the general space of cryptoeconomic systems.


#9

The use of Presence Claims in the FOAM Protocol approaches the speed of light. Stale Presence Claims, would not be useful, just as there is not much use for a Movie Theater Ticket stub after you have entered the theater. Proving you were in a place would be a matter of Historical record, although applications that would be written to use such a proof for any other period than NOW is doubtful.

The only one I can think of is Loyalty points related to visitors to a store, and since the Store would account for the interaction with additional data points besides Presence Claims, well then stores should seek to establish a customer relationship. A repeat customer is your best customer. Simply walking into a store does not establish that relationship. Walking into a store a hundred times, less so. (although an interesting exercise in data analytics would be to determine why a customer returned to a store 99 times without buying anything…)

The scenarios you describe require too much latency for a Zone Anchor to approve of. Applications that used historical Presence Claims would most likely not be commanding a volume of users. (and those low volume edge cases could require additional measures) Games are about immediacy and response. Selling a Presence Claim for last week would not be applicable to any casual or high volume application I can think of.

What you describe seems to treat Presence Claims as low-cost to create, yet having a high value thus a secondary market. When in reality FOAM users that interact with FOAM overtime will have a higher trust and stake in the Protocol. Selling that stake’s Private key is not rationale. The architecture will not reward or even recognize lag on interactions with a Zone Anchor that have any latency outside of their geography.

The closest I can get to what I think you are proposing is a system wherein AGENTS with FOAM interacted in specific locales with the FOAM Protocol via a Zone Anchor for a third party, those AGENTS could be contracted to perform that action, under contract or employment. That would be a valid interaction with FOAM. It is a messy scenario, and could show there is an opportunity for new types of work or jobs in the FOAM economy.

I agree that this is largely dependent on the Application written to use FOAM. A badly designed application could be susceptible to the pitfalls you raised, only if they put any credence in Historical Presence Claims. Any application processing Presence Claims NOW would not be susceptible to a market in used Presence Claims.

You obviously are very concerned about this scenario, perhaps a more exhaustive analysis could be made to cover all areas you have raised?


#10

I’m in Time Square, you’re not, but you can be, for the right price (i.e. I will sell you the private key owning the location proof).

My takeaway from the discussion above is this:
the protocol itself does not / cannot thwart such markets, because it cannot forbid transfer of private keys used to obtain the PoL. Applications should be aware of this possibility and should implement appropriate checks to protect against it: detect “teleportation” anomalies, demand that user sticks to single “verified” account for presenting location proofs. The nature and thoroughness of checks will be application-dependent and balanced against other concerns, like privacy.


#11

Ah ha! This is why this is not practical; an ad-hoc market for Location Proofs, would not be able to determine the Locations that would be relevant ahead of time, thus the exponential options of FOAM accounts PLUS, any actual locations would be enormous.

FOAM is an U2F in Transactions

It would be impossible to generate disposable FOAM accounts in any number to address this without consuming a large amount of FOAM resources. For high-value Presence Claims, the applications would require that they would be attached to a further requirement of liquidity or stake. The Presence Claim acts as a locale based U2F, it is ONLY a factor, it is not the only requirement. We are leveraging FOAM to verify a geospatial coordinate, and the application would not be only dependent on that component.

Next Steps for Automation

With that being said, I still think that Authorized AGENTS could interact with FOAM in manners that would enhance security, and perform work that could be desired.

Surrogates for Human Tasks

Now think of a courier robot service, and a document, or agreement that must be signed in person. Could we in that case create a mechanism that allowed delegation to that Zone for the Agent?

A Robot Brinks Trunk?

Or transport and handling of valuable or dangerous components that require observation, control, and securing of their transit. Would FOAM in that case be able to provide a framework within which delegation of Human supervision could be automated for most or all of the transit?

How many Brinks trucks drive around empty? Is this a mechanism to reduce the chance that they are robbed? Certainly regular arrivals and departures minimize the total amount in transit at a time. Now think about how that human component adds to the overhead of the company.