<story><title>Store the proof of a webpage saved with SingleFile in Bitcoin</title><url>https://blog.woleet.io/woleet-singlefile-extension-bitcoin-proof/</url></story><parent_chain><item><author>kwantam</author><text>Since there&amp;#x27;s little technical detail it&amp;#x27;s hard to be certain, but I doubt this is useful as a proof in the way one might wish (that is, proving that a web server delivered content X at date Y). The reason is, it does not appear that anything prevents the user from modifying the web page and then generating a &amp;quot;proof&amp;quot; about the modified version.&lt;p&gt;TLSNotary (tlsnotary.org) is an example of a project that attempts to use a (modified) TLS connection for non-repudiation (which is roughly the property that we would want here), but it requires a trusted third party to act as the notary.&lt;p&gt;It&amp;#x27;s possible this project is taking a similar approach (which would be fine, for those who trust the trusted third party). But given the lack of technical detail, and reading between the lines, I don&amp;#x27;t see a reason to believe this is the case.&lt;p&gt;(Happy to be wrong, though! Maybe a more detailed description would help us understand what&amp;#x27;s going on.)</text></item></parent_chain><comment><author>jmeyer2k</author><text>&amp;gt; I doubt this is useful as a proof in the way one might wish (that is, proving that a web server delivered content X at date Y). The reason is, it does not appear that anything prevents the user from modifying the web page and then generating a &amp;quot;proof&amp;quot; about the modified version.&lt;p&gt;The point of this service is to prove data &lt;i&gt;&lt;/i&gt;existed&lt;i&gt;&lt;/i&gt; at a certain time. It can&amp;#x27;t prove the authenticity of the data.</text></comment>
<story><title>Store the proof of a webpage saved with SingleFile in Bitcoin</title><url>https://blog.woleet.io/woleet-singlefile-extension-bitcoin-proof/</url></story><parent_chain><item><author>kwantam</author><text>Since there&amp;#x27;s little technical detail it&amp;#x27;s hard to be certain, but I doubt this is useful as a proof in the way one might wish (that is, proving that a web server delivered content X at date Y). The reason is, it does not appear that anything prevents the user from modifying the web page and then generating a &amp;quot;proof&amp;quot; about the modified version.&lt;p&gt;TLSNotary (tlsnotary.org) is an example of a project that attempts to use a (modified) TLS connection for non-repudiation (which is roughly the property that we would want here), but it requires a trusted third party to act as the notary.&lt;p&gt;It&amp;#x27;s possible this project is taking a similar approach (which would be fine, for those who trust the trusted third party). But given the lack of technical detail, and reading between the lines, I don&amp;#x27;t see a reason to believe this is the case.&lt;p&gt;(Happy to be wrong, though! Maybe a more detailed description would help us understand what&amp;#x27;s going on.)</text></item></parent_chain><comment><author>gregable</author><text>Another possible solution to what you want to solve is to use a signed exchange signature: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;wicg.github.io&amp;#x2F;webpackage&amp;#x2F;draft-yasskin-http-origin-signed-responses.html&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;wicg.github.io&amp;#x2F;webpackage&amp;#x2F;draft-yasskin-http-origin-...&lt;/a&gt;&lt;p&gt;The publisher server must support it, but this results in the document being signed with the publisher&amp;#x27;s certificate. This won&amp;#x27;t &amp;quot;date&amp;quot; the signature, but combined with a blockchain solution like this could prove that a web server delivered content X at date Y.</text></comment>