Open sonatagreen opened 7 years ago
mishfit
commented
7 years ago I believe the files are "mutable" if the "zite" owner updates them and signs them.
If the site owner doesn't update, sign and publish the new content, then static files will not change (most importantly by seeders of the site).
Perhaps I'm missing something, but that seems to fit your use case.
sonatagreen
commented
7 years ago As I understand it, it's currently possible to create a site that doesn't update, by refraining from making use of the update feature; but it's not currently possible to create a site that can't update.
A site that can update, even if it doesn't, provides no verifiable guarantee that it won't.
Sites can contain Javascript; therefore, sites are computer programs. Zeronet's sandboxing security model limits the damage that malicious sites can do, but users who choose to run a particular program benefit from being able to rely on it doing what they expect.
Security requires code review.
For any site that even in principle could possibly ever update, each user must either:
Only option 2 is compatible with reasonable security practices. Even then, it's not possible to write a hyperlink to a particular version of a site, so even if there's widespread consensus that site X is not evil as of date Y, I can't readily download the date-Y version of X.
Zeronet is based on Bittorrent.
Imagine a version of Bittorrent where, even after you finished downloading a file, by default the original uploader could push a different version so that the copy on your machine was automatically replaced without notifying you.
Imagine if, even if you turned off automatic updates for a particular file, there was no way for a tracker website to publish a .torrent file referring to a specific version, so that no matter how well-vetted a particular .torrent file was, it would always be possible for the original uploader to decide unilaterally that any newcomers downloading the file for the first time should get an altered version of the file instead of the well-vetted original.
Would you want to use such a thing?
There are many cases where it's good for updating a site to be possible. There are also cases where it's very bad for it to be possible to update a site even if that possibility is never exercised.
The site owner being able to refrain from updating the site is very different from ordinary users being able to be sure that the site can never be changed.
ROBERT-MCDOWELL
commented
7 years ago On 3/14/2017 12:34 PM, Sonata Green wrote:
As I understand it, it's currently possible to create a site that /doesn't/ update, by refraining from making use of the update feature; but it's not currently possible to create a site that /can't/ update.
A site that /can/ update, even if it /doesn't/, provides no verifiable guarantee that it /won't/.
Sites can contain Javascript; therefore, sites are computer programs. Zeronet's sandboxing security model limits the damage that malicious sites can do, but users who choose to run a particular program benefit from being able to rely on it doing what they expect.
Security requires code review.
For any site that even in principle could possibly ever update, each user must either:
- review the code every time she visits; or
- pause the site so as to block future updates; or
- accept on faith that the site owner will not push a malicious (or careless) update.
Only option 2 is compatible with reasonable security practices. Even then, it's not possible to write a hyperlink to a particular version of a site, so even if there's widespread consensus that site X is not evil as of date Y, I can't readily download the date-Y version of X.
Zeronet is based on Bittorrent.
Imagine a version of Bittorrent where, even after you finished downloading a file, by default the original uploader could /push a different version/ so that /the copy on your machine was automatically replaced without notifying you/.
Imagine if, even if you turned off automatic updates for a particular file, there was no way for a tracker website to publish a .torrent file referring to a specific version, so that no matter how well-vetted a particular .torrent file was, it would always be possible for the original uploader to decide unilaterally that any newcomers downloading the file for the first time should get an altered version of the file instead of the well-vetted original.
Would you want to use such a thing?
There are many cases where it's good for updating a site to be possible. There are also cases where it's /very bad/ for it to be possible to update a site /even if that possibility is never exercised/.
The site owner being able to refrain from updating the site is /very different/ from ordinary users being able to be sure that the site can never be changed.
Do you mean that use zeronet is more risky that to use the conventional client -> server website? what about if zeronet has a config to deactivate completely any client side code like javascript as an option?
mishfit
commented
7 years ago You might have a misconception about IPFS. You can have static javascript files in IPFS just fine.
What features of the ZeroNet API would you want if the files themselves are meant to be "immutable"?
sonatagreen
commented
7 years ago Do you mean that use zeronet is more risky that to use the conventional client -> server website?
No, Zeronet is superior to the traditional model even without the feature I'm requesting. But it could still be better.
what about if zeronet has a config to deactivate completely any client side code like javascript as an option?
I don't think that is necessary or particularly helpful. Between the existing sandboxing and the option to simply not use a given site, I don't think that would provide anything we don't already have.
What I want is to be able to use a site, including its scripting, but to specify a particular version of it.
You might have a misconception about IPFS. You can have static javascript files in IPFS just fine.
I don't see how static javascript is relevant to
A static zite would differ from e.g. an IPFS site in that it could access the ZeroFrame API, and therefore act as a client for a networked protocol, whereas an IPFS site is purely read-only. Through the API, static zites could have mutable state; only the code would be immutable, not the data.
.
What features of the ZeroNet API would you want if the files themselves are meant to be "immutable"?
I'm not sure what you mean by the "ZeroNet API", but I'd want everything in the ZeroFrame API, even sitePublish, siteSign, and siteUpdate.
On further reading about how those are used, I realize that my original idea of how this would work was based on a misunderstanding of Zeronet implements stuff.
What I want is a site that verifiably-to-the-end-user rejects only those updates that require the signoff of the site's original publisher, while accepting the type of updates that do not require that sort of special privilege.
Possibly I'm still misunderstanding how stuff works. Possibly merger sites do what I want. Probably I need to grok better in order to figure out how what I have in my head would work. Possibly Zeronet can't do what I want.
What I want is a type of site that works - roughly - like an Ethereum contract: non-updateable code, and mutable state that can only be changed in accordance with the non-updateable code.
mishfit
commented
7 years ago I don't see how static javascript is relevant to
A static zite would differ from e.g. an IPFS site in that it could access the ZeroFrame API, and therefore act as a client for a networked protocol, whereas an IPFS site is purely read-only. Through the API, static zites could have mutable state; only the code would be immutable, not the data.
Yeah, "non-updatable" is confusing as a requirement. "Versioned" site makes a lot more sense to me.
What features of the ZeroNet API would you want if the files themselves are meant to be "immutable"?
I'm not sure what you mean by the "ZeroNet API", but I'd want everything in the ZeroFrame API, even sitePublish, siteSign, and siteUpdate.
I mean the "ZeroFrame" API.
Perhaps you should change the title to "Versioned Sites" as a feature request.
sonatagreen
commented
7 years ago On further reflection, merger sites provide most of the security benefits, but I still want to be able to create a static link to a specific version of a site. I'll change the title to reflect that.
Thanks for your help getting my head sorted out on this.
sergei-bondarenko
commented
7 years ago Maybe more general approach will be better: https://github.com/HelloZeroNet/ZeroNet/issues/452 I propose to track a history of each site as in Wikipedia articles. Also there will be possible to have a direct links to particular time in the history.
sonatagreen
commented
7 years ago That's a good idea. In order to fulfill this request, though, it'd be necessary to not only store previously-seen versions of the site, but to download the entire change history of the site even from before one joined. Otherwise,
it's not possible to write a hyperlink to a particular version of a site, so even if there's widespread consensus that site X is not evil as of date Y, I can't readily download the date-Y version of X.
sergei-bondarenko
commented
7 years ago @sonatagreen You are completely right. Also the history of the site can't be stored by the site owner, because he can rewrite it. It seems impossible to implement such feature without blockchain :(
[ Edit: This was not initially well thought out. To keep the record of the conversation intact, I have kept the rest of this post as I first posted it; for those just joining us, the actual feature request is further downthread. ]
It would be nice to be able to have static (immutable, non-updatable) zites. There are many cases where immutability is a positive feature from a security perspective, especially from the perspective of auditability.
A static zite would differ from e.g. an IPFS site in that it could access the ZeroFrame API, and therefore act as a client for a networked protocol, whereas an IPFS site is purely read-only. Through the API, static zites could have mutable state; only the code would be immutable, not the data.