On Sat, Oct 26, 2019 at 09:42:44AM +1100, Zenaan Harkness wrote:
Original copyrighted, now discarded blocks: A D
Block store: B (pure random data), C and E ('encodings' of A and D)
Who owns the copyrights on the various blocks?:
Block A is regenerated using B XOR C.
Block D is regenerated using E XOR C, where C was chosen completely randomly.
Block C is an encoding of A.
Block E is an encoding of C, so E is also, quite evidently, an encoding of A, and in fact E { XOR C XOR B } gives A, so copyright
The above function is incorrect on second reading, so let's correct it: E XOR C = D, and of course E XOR D = C (remember D was discarded from our block store) so: E XOR D XOR B = A or to use only blocks available in our block store: E XOR (E XOR C) XOR B = A Hopefully this is now correct :) And note, without any other information (namely the block list for XORing to recreate A or D), and because of the nature of block B, we know that block E, by itself, is statistically completely random - indistinguishable from pure random data (likewise, so is block C); it is only someone who knows that C XOR B will produce block A, who can even say "ahah! block C is therefore, obviously and mathematically, an encoding of copyrighted block A". But, this very same mathematics of encoding, as we see above, demonstrates mathematically and with absolute certainty, that block E is likewise an encoding of block A. One can postulate that this above insight from circa 2000, is why statute law at least since then equates "copyright infringement" with downloading and not with storage of the copyrighted material - although I think storage is also covered, at least in Australian jurisdiction. Notwithstanding this legislative shift to "downloading", one can readily use the same above maths to get around this same problem by, for example, using a shared base public domain block set, say 1GiB, 10GiB and 100GiB (depending on the size of files you wish to torrent) and then only ever distributing encodings of the base file set, which, for those in the know, just happen to also match Disney's latest Princess Snowflake syndrome programming material. As long as you have the base file set, which gets reused and is the only block set that gets reused (for torrents up to that size), then it is only the base file/block set that you cannot delete from your block store, making individual libraries (as opposed to large shared community libraries) viable (end users with private libraries, here and there will need to purge older content). "So lads, I happen to have this one little secret high quality encoding of the Wikipedia base media collection y'all might be interested in - I needed a totally random new name for it since there are already so many encodings of it getting around (I know, I know, we're utter sluts for Wikipedia yo!), so for a name, I just happened to chose "Wikimedia 100GiB encoding, Game of Thrones Supre Mega HQ DVD Bluray WebRip, so sad 2019 miscegenation edition" Get it while it's hot! - Oh, and by the way, I had an encoding problem, so only the first 27.12 GiBs has been encoded, sorry about that =)" Question is, is there a bush lawyer or actual lawyer who can say whether this would actually be useful if defending a MAFIAA court case?
holder of A can quite legitimately, within the assumption that he has copyright over all encodings of A, claim copyright over block E.
But this would probably not be considered satisfactory to the copyright holder of block D, who can also with mathematical certainty, demonstrate that block E is an encoding of block D.
---------------------------
In the "free speech" version (HTML paper courtesy grarpamp), this principle was used with a distributed "random data" 128KiB block store - sort of P2P, although it wasn't automated and this was 2000, so the link protocol was FTP, with the intention being the ability to distribute messages over the internet, exposing those messages "at some time in the future" via "just happened to notice these blocks ABC XOR to produce message XYZ".
---------------------------
Utility appears to be confounding copyright holders.
Utility for "free speech"? Not so much, since:
- "speech", such as chatting and email demand various "reasonable maximum" latencies - for email, a few minutes max latency is desirable, often much longer can be tolerated, but still only up to "hours" - for chat/text/forum, a typed message needs to appear within seconds, ideally milliseconds
What about storage requirements? Although some folks and systems are designed to record all history for a chat room, and email lists tend to work this way by default, there are many use cases for throwaway chat rooms and flippant discussions about the weather which most folks would never bother or want long term storage for.
XOR/RAID-type block stores, where new blocks are created and added to the store based on randomly chosen prior blocks, have the apparent (on first look at least) requirement that all older blocks are kept and never deleted - there may be some other blocks in your store, or in the block store of some peer, depending on your old block.
Secondly, except that compression is applied before storage, there is no compression of compressible data (this is solvable in end user software of course - just compress all new blocks before storing, and remember to notate the compression algorithm used).
Thirdly, deduplication is not part of the above systems, and would not appear to add much utility anyway... most material is new material and some git style content mapping/ addressing solution is what's really wanted in an upper layer anyway.
So we have a significant unavoidable problem built in to this type of system:
- an ever expanding block store, where older blocks can never be deleted since they may be XOR encodings of newer blocks, in yours or other's' (in the case of a distributed store) block stores
---------------------------
Storing interesting content?:
Some content is illegal in one jurisdiction, whilst being legal in another jurisdiction. So what about the case where you happen to be in a jurisdiction where such content is illegal in your jurisdiction?:
Someone with access to your block store, can run permutation XORs up to large counts, with enough computing power.
This can be described also as "pot luck" - do you want to entrust your defence against local laws to pot luck?
Of course, blocks can be hidden with encryption, but then we've already got veracrypt, so what does the extra XOR/RAID layer add? Nothing AFAICT.
And if you're storing copyrighted content in your block store to which you simply don't have lawful right to access/view/share, then your block XOR maps must be stored somewhere anyway, with an application that can read and present you with your illicit copyright infringing library of content, for local viewing. That app could put a password on that, but now we're back to password management, crypto password salting, key blocks for multiple keys and etc - i.e., we're back to veracrypt/luks, and again, why bother with OFFsystem?
---------------------------
Conclusion:
XOR/ RAID stripe type block mixing appears potentially great for confounding copyright holders in an actual court case.
This could be a good way for a library to store their digital media - "no Judge, if we remove those copyrighted blocks, we are removing the encodings of many other digital works we store; can't do, won't do".
"Potentially contentious" media would be consistently followed by a bunch of other media, all intermingled (this is another time factor problem - in OFFsystem, earlier blocks get more dependencies on them, to later blocks).