3 ms·

To address your concerns: > isn't whoever controls your code the "timestamping party"? No (and sort of yes). The result of the timestamp is instantly verifiab

To address your concerns: > 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.

smt88 6y ago
> 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.
bccdee 6y ago
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.

smt88 6y ago

> 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.

bccdee 6y ago

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.