> where the timestamping party cannot be trusted to act honestly because of conflicting interests
But in this case, isn't whoever controls your code the "timestamping party"?
Looking at two examples:
A: With blockchain
The timestamp that the photo was taken is immutably, publicly logged.
B: Without blockchain
The timestamp the photo was taken is logged by you, the software provider.
What is a scenario where (B) is less secure than (A)? In both scenarios, you have no proof of when the photo was taken. It could've been two hours or ten minutes ago. There is no way to digitally verify it.
So it sounds like all you're doing it creating a public, verifiable record of something that you have no incentive to alter and something that doesn't actually verify the state of the vehicle at any point in time.
From personal experience, the most common types of fraud in this space are (1) just posting an old photo as though it were taken right now, and (2) posting a photo of a different vehicle. I don't see how either of these are prevented.
What am I missing?
(Full disclosure: I built software that does something similar for different types of clients, so I've worked on the problem of "verifying vehicle state" for ~10 years.)
The picture of the car is not protected by hard crypto until it's inserted into the blockchain. Until it is inserted the trust chain breaks at the questions of:
When was it taken?
Who was taking the picture?
What is the picture of? The car to be protected? Or someone else's car.
Blockchain works for currencies, since currencies are just numbers in a ledger. And numbers can be easily secured with strong crypto.
"Secured by hard crypto" is item fifteen on someone's priority list after usability, cost, reliability, speed and the font used on the marketing page. Note that none of the questions you raise are answered by protecting a jpeg with hard crypto... (If that was the point, my apologies for re-explaining it).
See my response to the grandparent comment for more details.
> When was it taken?
We currently verify this by including the last Bitcoin block hash in the photo, giving us a ~10 minute time window in which the photo was taken. Also, the whole handoff period is under 20 minutes, so the transporter only has access to the cars for 20 minutes (with many others around), before a timestamp is required.
> Who was taking the picture?
We've never run into this as a problem, but we can require a continuous video including a selfie of the transporter.
> What is the picture of? The car to be protected? Or someone else's car.
This we verify by checking the VIN in the frame (frame number check).
Your company sounds pretty awful to work for, where suggestions like, "Watch the employees at all times" are apparently taken seriously.
Had an interview for a company like that once, where they required that no work-related communication happen outside of their chat client. And they had cameras to check for that. The turnaround rate was through the roof.
I genuinely hope that you'll try and solve these problems using other methods. Building these systems just makes your employee's lives hell.
We don't do any of what you describe. When I said "continuous video", I was referring to the transporter taking a video of the state of the car — two minutes max. No livestream or tracking or anything.
I don't watch or control my employees or the transporters (they are just a client of a client). I don't even see the pictures they take before transport, usually just our customer.
It feels like you're wilfully misunderstanding something.
> isn't whoever controls your code the "timestamping party"?
No (and sort of yes). The result of the timestamp is instantly verifiable against the timestamped data, meaning the results of the timestamp can be viewed on a public blockchain explorer or using an API that interfaces with the blockchain, without trusting our code. If another party doesn't trust our frontend code, they can build their own frontend logic that interfaces with the blockchain in the backend to independently verify results. If someone is using our app, they implicitly trust our code, yes, but they don't have to trust our database. That's the difference.
> In both scenarios, you have no proof of when the photo was taken. It could've been two hours or ten minutes ago. There is no way to digitally verify it.
This is a solvable-ish problem. What our app does is require the photos to be taken in-browser, and adds a small stamp to the photo before hashing it with the most recent Bitcoin block hash. This way, we have a window of ~10 minutes within which we know the photo was taken.
Can this be abused? Yes. But the transporter is exceedingly unlikely to know how, and they also don't have access to the cars before handoff, so the concern is really negligible. Faking the photos is now at least a few order of magnitudes harder than before. We can improve on this in the future.
> posting a photo of a different vehicle
We ask the transporters to take a photo of the VIN in the frame, along with other photos (body, odometer, etc.). This is a pretty foolproof solution.
> No (and sort of yes). The result of the timestamp is instantly verifiable against the timestamped data, meaning the results of the timestamp can be viewed on a public blockchain explorer or using an API that interfaces with the blockchain, without trusting our code. If another party doesn't trust our frontend code, they can build their own frontend logic that interfaces with the blockchain in the backend to independently verify results. If someone is using our app, they implicitly trust our code, yes, but they don't have to trust our database. That's the difference.
I think you misinterpreted the attack I was describing.
Let's say you rewrite your front-end code to change the timestamp. Sure, someone could read it, but reading source code every time it's updated is not a sustainable security practice. It's also especially easy to hide malicious code in JavaScript.
How does blockchain prevent that attack? Your blockchain is memorializing data that you have interfered with. Someone can definitely verify that whatever photo is on the blockchain was really added to it at whatever timestamp. But how does that give them any proof that the photo was actually taken at that timestamp?
All the blockchain does is say, "At [timestamp], this photo was added to the blockchain." It doesn't offer proof of who took it, where it was taken, what the subject was, or (crucically) when it was actually taken.
And that basic guarantee (that the photo was taken at a certain timestamp) is just as easy to accomplish with an append-only database.
Regardless, this is all about mitigating an extremely unlikely attack: your own company. Why do your own clients need to verify that you are trustworthy?
> What our app does is require the photos to be taken in-browser
> We ask the transporters to take a photo of the VIN in the frame, along with other photos (body, odometer, etc.).
I agree that these measures likely stop close to 100% of attempts to defraud you, especially because there is a chain of custody that makes fraud more difficult.
But I still don't see any reason this couldn't/shouldn't have just been built on a vanilla RDBMS. Hell, if you want to verify the timestamp, you could just instantly email the photo to someone via Gmail, since you can't fudge Gmail's SMTP timestamps.
As I said before, using blockchain here decentralizing trust in a situation where the source of truth is... you. And it still doesn't make you trustworthy, since you can alter the photos before ever hashing them.
What if I write a browser extension that lets me upload a file from my computer with an arbitrary timestamp when I'm prompted to take a photograph? That seems like the obvious attack.
But in this case, isn't whoever controls your code the "timestamping party"?
Looking at two examples:
A: With blockchain
The timestamp that the photo was taken is immutably, publicly logged.
B: Without blockchain
The timestamp the photo was taken is logged by you, the software provider.
What is a scenario where (B) is less secure than (A)? In both scenarios, you have no proof of when the photo was taken. It could've been two hours or ten minutes ago. There is no way to digitally verify it.
So it sounds like all you're doing it creating a public, verifiable record of something that you have no incentive to alter and something that doesn't actually verify the state of the vehicle at any point in time.
From personal experience, the most common types of fraud in this space are (1) just posting an old photo as though it were taken right now, and (2) posting a photo of a different vehicle. I don't see how either of these are prevented.
What am I missing?
(Full disclosure: I built software that does something similar for different types of clients, so I've worked on the problem of "verifying vehicle state" for ~10 years.)