Difference between revisions of "Talk:INTERNETARCHIVE.BAK"
Jump to navigation
Jump to search
Line 3: | Line 3: | ||
I feel it is really critical that the drives or directories sitting in the end-user's location be absolutely readable, as a file directory, containing the files. Even if that directory is inside a .tar or .zip or .gz file. Making it into a encrypted item should not happen, unless we make a VERY SPECIFIC, and redundant channel of such a thing. --[[User:Jscott|Jscott]] 00:01, 2 March 2015 (EST) | I feel it is really critical that the drives or directories sitting in the end-user's location be absolutely readable, as a file directory, containing the files. Even if that directory is inside a .tar or .zip or .gz file. Making it into a encrypted item should not happen, unless we make a VERY SPECIFIC, and redundant channel of such a thing. --[[User:Jscott|Jscott]] 00:01, 2 March 2015 (EST) | ||
== | ==Potential solutions to the storage problem== | ||
* [https://tahoe-lafs.org/trac/tahoe-lafs Tahoe-LAFS] - decentralized (mostly), client-side encrypted file storage grid | * [https://tahoe-lafs.org/trac/tahoe-lafs Tahoe-LAFS] - decentralized (mostly), client-side encrypted file storage grid | ||
** Requires central introducer and possibly gateway nodes | ** Requires central introducer and possibly gateway nodes | ||
** Any storage node could perform a Sybil attack until a feature for client-side storage node choice is added to Tahoe. | ** Any storage node could perform a Sybil attack until a feature for client-side storage node choice is added to Tahoe. | ||
* [http://git-annex.branchable.com/ git-annex] - allows tracking copies of files in git without them being stored in a repository | * [http://git-annex.branchable.com/ git-annex] - allows tracking copies of files in git without them being stored in a repository | ||
==Other anticipated problems== | |||
* Users tampering with data - how do we know data a user stored has not been modified since it was pulled from IA? | |||
** Proposed solution: have multiple people make their own collection of checksums of IA files. --[[User:Mhazinsk|Mhazinsk]] 00:10, 2 March 2015 (EST) | |||
* "Dark" items (e.g. the "Internet Records" collection) |
Revision as of 05:10, 2 March 2015
A note on the end-user drives
I feel it is really critical that the drives or directories sitting in the end-user's location be absolutely readable, as a file directory, containing the files. Even if that directory is inside a .tar or .zip or .gz file. Making it into a encrypted item should not happen, unless we make a VERY SPECIFIC, and redundant channel of such a thing. --Jscott 00:01, 2 March 2015 (EST)
Potential solutions to the storage problem
- Tahoe-LAFS - decentralized (mostly), client-side encrypted file storage grid
- Requires central introducer and possibly gateway nodes
- Any storage node could perform a Sybil attack until a feature for client-side storage node choice is added to Tahoe.
- git-annex - allows tracking copies of files in git without them being stored in a repository
Other anticipated problems
- Users tampering with data - how do we know data a user stored has not been modified since it was pulled from IA?
- Proposed solution: have multiple people make their own collection of checksums of IA files. --Mhazinsk 00:10, 2 March 2015 (EST)
- "Dark" items (e.g. the "Internet Records" collection)