You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 30, 2020. It is now read-only.
To the best of my current understanding, the /v1/submit protocol allows a client to specify the resource to be certified by URL only.
This means that the system has no way to make sure the submitter and the recorder are observing the same content at the same URL at submission time, before the transparency log is recorded.
As a silly example, a web-server could do user-agent sniffing (or special-case IPs for your server) and serve different content to rget, compared to what the user expected to submit.
I think it would be nice to have some kind of local-feedback loop, so that the submitter can know that the recorder is certifying the same content that they submitted.
To that extent, it may be worth having client-provided digest hints that the server could double-check before certifying a resource (and notify the client on mismatches).
The text was updated successfully, but these errors were encountered:
However, the web server would have no incentive to lie to Merkle County API because an invalid digest would get registered and rget would fail later on downloading a file.
But, it wouldn't be difficult to do and adds an additional guarantee so I would happily take a patch (hint, hint) or will put it on the backlog.
To the best of my current understanding, the
/v1/submit
protocol allows a client to specify the resource to be certified by URL only.This means that the system has no way to make sure the submitter and the recorder are observing the same content at the same URL at submission time, before the transparency log is recorded.
As a silly example, a web-server could do user-agent sniffing (or special-case IPs for your server) and serve different content to
rget
, compared to what the user expected to submit.I think it would be nice to have some kind of local-feedback loop, so that the submitter can know that the recorder is certifying the same content that they submitted.
To that extent, it may be worth having client-provided digest hints that the server could double-check before certifying a resource (and notify the client on mismatches).
The text was updated successfully, but these errors were encountered: