Can one set permissions for read access with SIA?
-
I was just thinking, I wonder if I can persist a file with SIA, and then set read access to all for people.
I realize including explicit user rules for read access etc, might create overhead on extra metadata in the BC, but perhaps a bit that functions as a flag for simply 'public' or 'private'.
In other words, user X uploads a file but doesn't mind if it's read by others. Possibly even for utility. Maybe a professor wants to upload a file for classes so the students can pull it down (might not be the best example), or an author wants to put up an essay for all to read.
I am guessing SIA is probably best private, or perhaps? is it possible to be able to give out a key to a data share ?
I'm thinking maybe this could be done, user X rents 1 GB of space via SIA, and then can give out the key ? so others can access it ?
Bottom line I was thinking about a permissions layer to SIA data stores... if they exist ? Might they exist ? should they exist ?
-
Currently, the .sia files themselves constitute "read access." If you give someone a .sia, they have the ability to download and decrypt the data. So you can control read access by controlling .sia access.
Of course, it's important to remember that if you give a .sia to an untrusted party, they can distribute it to anyone they want -- but there's not much you can do to avoid this without adding some form of DRM.
-
@nemo Might it be possible in theory to instruct hosts you're uploading a file to that they shouldn't serve your files except to renters with a given... well, currently, a given IP address, but in the future when dynamic IPs are better supported, a given key?
This way you could give A a .sia, then you could tell your hosts that A's address/key is allowed to access that content. If A gives the .sia to B, then B won't be able to access the data unless A additionally compromises itself by giving B its own full key (at this point, A and B would become the same peer to the network; but this generally has a cost to A, unless it trusts B fully).This can't - of course - stop A from just giving B the data through other means. But it could be important to hosts which may not love the idea of being used by multiple users, perhaps many users (anyone with the given .sia), to share files among each other without any limitation... I'm thinking also of the thread about (host) anonymity on the network.
-
Access control on the host side is probably futile, because the renter can simply serve as a proxy, making download requests on behalf of arbitrarily many users (although this would restrict downloads to a single connection, which may be desirable).
The situation reminds me of private torrent trackers. In general, they are powerless to stop people from leaking their .torrent files to non-members. At best, they can detect which user leaked, and punish them. But they can't prevent it from happening in the first place.As far as I can tell, the only way to prevent data leakage is to refrain from sharing it with people you don't trust completely.
-
@nemo but if a renter is acting as a proxy, then at least the host is not personally sending anything to anybody who's not the "authorized" renter... which may be a good enough assurance for the host's purposes.
It really depends on what the host is afraid of, I guess. As a host, I personally wouldn't love finding myself in the situation where I'm an unwitting provider of "inappropriate" data to a large number of renters (not just the ones I have contracts with, which may limit the damage in some ways), directly to them from my own IP.
I think for legal purposes, directly sending data to multiple third parties may be different from having a private contract with one party, and then letting that party serve data to others if it so decides.
-
Might it be possible in theory to instruct hosts you're uploading a file to that they shouldn't serve your files except to renters with a given... well, currently, a given IP address, but in the future when dynamic IPs are better supported, a given key?
You could definitely give the hosts a list of keys that are allowed to access the file. But you can't enforce that the host will respect that list. If the hosts need that list to be compliant with the laws in their jurisdiction, then maybe it's worth doing. But if the renter is hoping that the host will honor that list of keys, then it's not really a useful construction because there's nothing stopping the host from breaking those rules.
-
@Taek true, but since the file is normally going to be spread among several hosts, and not reconstructable from fewer-than-enough pieces, just one host "breaking the rules" and serving its data when it shouldn't does not necessarily result in spilling the beans.
Anyway, yes, I'm mostly thinking of hosts' legal liability myself.
-
just one host "breaking the rules" and serving its data when it shouldn't does not necessarily result in spilling the beans.
True, you would need at least M of N hosts to break the rules. But, there is no incentive for them to follow the rules. A rational host is going to break the rules every time, because they are probably getting paid for that download, and therefore find it profitable to break the rules. The only danger would be that the person requesting the download is actually auditing them to test their trustworthiness. Which is maybe something we could implement, but the host may be able to guess which download requests are audit requests and which ones are legitimate.
-
@Taek Wait, isn't the payment channel for downloads only opened with the original renter? Does that mean that the renter will be the one paying for any downloads?
-
@Taek Wait, isn't the payment channel for downloads only opened with the original renter? Does that mean that the renter will be the one paying for any downloads?
No, the protocol is actually constructed such that anyone with a file contract payment channel to the host can pay to download a file. When you download a file in the new protocol, you download by the file's hash instead of by the file contract. But... the fact remains that you need some way to pay the host.
