biolizard89 wrote:
So, looking at the difference between our respective proposals -- using the file/ namespace would use more blockchain space (proportional to files rather than domains), but using file/ would work for any filetype while using an HTML element would only work for HTML files and would require modifying even static sites. Since Javascript is probably a more attractive target than HTML, I'm of the opinion that a system for this would need to be agnostic of file type, hence I think using the file/ namespace would be preferable despite increased blockchain usage. What do you think?
As an aside, I noticed a specific detail that would need to be kept in mind... if the file/ name is just based on filename (rather than full URL to the file), then multiple websites which use the same Javascript library or image would have a collision... so I would recommend that the full URL of the file be used in the file/ name, rather than just the filename.
OK. You have right. I considered only static html but this concept can be extended very easily. With Javascript you also have right.
I am not sure if I understood your proposal correctly.
Why should your proposal use more the blockchain ? Because the dd/ entry ?(the additional usage is not semnificative)
Or do you want to store the file signatures in the blockchain ?
If yes, using the blockchain for every file update I think it would be extremely inconvenient. I wouldn't use so.
Having the reference for the signatures of the html content and loaded embedded content(loaded from the site or externally - doesn't matter) in header tags .
for ex. helloworld.html
<html>
<head>
<title>This is a title</title>
<localsignature>YES</localsignature>
<externsignature>YES</externsignature>
</head>
<body>
<p>Hello world</p>
<img src="helloworld.png" alt="helloworld">
<img src="anotherdomain.com/subdirectory/helloworld2.png" alt="helloworld2">
</body>
</html>
would have a corresponding helloworld.sig.
If the <localsignature> tag is on YES then all locally embedded files also need signature.
helloworld.png - helloworld.png.sig
If the <externsignature> tag is on YES then all externally embedded files also need signature.(if dynamic content is embedded externally then this should be put on NO) The signature could be locally in the above example in the file anotherdomain.com.subdirectory.helloworld2.png.sig.(I am not sure if it is so safe this solution for external embedded content)
Here all can be included what can be displayed on the page but not content which is linked for download.
Having more validators as you proposed above is not a problem and their public keys could be referred to the dd/ entry as proposed or saved directly in the d/ entry.
domob wrote:This will surely improve security - however, at the moment I see its usability more for "few special" files (like binary / source downloads for which the proposal was originally intended). I'm not sure whether it will really help to sign every file on a webpage; as you suggest, for a lot of content of a modern web application (which is dynamic), this won't work at all. Thus the remaining cases I can think of are things like bitaddress.org, but in that case, since one is encouraged to download the file anyway, a "manual" signature check can be done.
But I'm not opposed to having this feature if it seems worthwhile to implement and you think website owners will sign their files. However, as mentioned I see the utility more in enabling this check for a special "download." subdomain, and not in enabling it for the main website and only disabling for some "special" subdomain.
Dynamic files would be safe as before with TLS security on the server side. (here is no content author validation possible because the server generates the content)
With downloadable content I am also on the meaning that should be better solved outside of the browser like Biolizard already expressed above. But it would be also possible to create a <downloadsignature>YES</downloadsignature> tag in the html header which enables downloaded content to be checked to be valid against a local signature file. This would be only possible after downloading the content eventually with a special button in the browser. But here more changes would be necessary and it would create eventually confusion when the content is embedded but can be downloaded also.
