[Noisebridge-discuss] M.A.I.D. was: Freespace / slackspace file system

aestetix aestetix aestetix at gmail.com
Fri Sep 25 09:45:06 UTC 2009


On Thu, Sep 24, 2009 at 11:12 PM, Mountain Sky <mountainoceansky at hotmail.com
> wrote:

>  > > My version is much less stable - one can't depend that files that are
> > > saved will stay there, and one might need to move 'em around a lot -
>
> Coming at this with the tech know-how of a star-nosed mole... how would you
> propose that the overall organizational scheme ensure that whatever sekrit
> data you are trying to stuff into the slack-space isn't losing big chunks of
> itself with the user's files constantly switching bits around? You've
> addressed this happening, but what would you do about it?:
>
> 1) Have the data frequently monitored to see which redundant segments are
> on short supply?
> A) and how would you then hide the monitor lizard?
> B) or keep it in a cage outside the system?
>
> 2) Have the whole shebang frequently re-install itself equi-informationally
> into the fragged niches, overwriting any chinks it used to occupy and
> rooting out the fresh bits?
> A) and wouldn't this draw detectably on the user's CPU performance?
> B) and could the program that executes this, itself be tucked away in
> fragments and still be able to run?
>
> 3) Profit? :P
>
>
This is a bit more complex than that. It really depends on the kind of file
system you want to use. If you like at file systems in past years, often
they have depended on many files looking up to a master allocation table to
keep them in order.

However, many years ago, there was a file system renaissance, where files
began experimenting with different systems, and made great advances in both
understanding of themselves and how they relate to other files. Naturally,
this destroyed their notion of "divine right" of the allocation table, and
they had to reassess how files are categorized.

Lately, we've seen a lot of movement towards equal rights for all files, but
have found that this is more difficult than it seems. Some files are useless
without a program to run them. Others work in a lot of different programs.
Some files can be deleted or changed, but others are necessary in order to
maintain the full order of the file system.

Thankfully, some of the file systems can talk to each other, and I think in
the future we'll see a bit of homogenizing, at least to the extent that
files can kind of understand each other even if they don't speak the same
language. There will definitely be paradigm shifts in terms of hegemonious
allocation tables, but at least we're on the right track.


>
> > > Very neat idea, though. I like it, and it'd potentially work well
> > > together with mine.
>
> It's fascinating! Hey Sai, <s>if</s> when you make this, would you consider
> naming it something to do with dandelions? They're my favourite flower, and
> i can't help but imagine them jutting up innocuously between slabs of data,
> spanning out their lives, and then casting a thousand self-replicating seeds
> to the wind. They're native to the most daunting of climates (Tibet) and
> thrive for great justice!
>

This is a fantastic idea! Despite the negative attitudes towards artists
held by early file system developers (such as Plato and Socrates), without
beauty or truth, we wouldn't have all ye need to know. Further,
self-replication will enable propagation of excellence to everyone.


>
>
> > I don't see how your idea is workable. I don't understand your threat
> > model nor how your system is actually secure against someone who
> > understands how it works. Can you explain the threat model and a general
> > overview of the specification?
>
> In my dandy mental model of this idea, anyone who's qualified and able to
> look through your files for crypto clues is doing it because your data stash
> is already suspicious/ under investigation, and a competent seeker will be
> able to see the nesting bits like fluffy bright yellow spots in your lawn.
> But if nobody's looking with the right tools, of course it won't be
> noticeable. Though, your idea would help initially present your data as
> innocent [merely a pr0n collection :P]. But i imagine, if you're caught
> wearing the red hat, your investigators will think to do more than poke your
> data with a sniffy-stick and give it the ol' spread-and-pat, and then you're
> in trouble.
>

"A file system unorganized is not worth encrypting." --A dead white guy


>
> > (Hrm. So I generally don't care for the terms "blackhat" or "whitehat"
> > as they're largely meaningless. What's a whitehat who gets a speeding
> > ticket in a car with fly by wire controls? What's a blackhat that helps
> > overthrow a theocracy by leaking sensitive information gained by illicit
> > means?)
>
> It's all just Spy vs. Spy anyway.
>
>
> ------------------------------
> Hotmail® has ever-growing storage! Don’t worry about storage limits. Check
> it out.<http://windowslive.com/Tutorial/Hotmail/Storage?ocid=TXT_TAGLM_WL_HM_Tutorial_Storage_062009>
>
> _______________________________________________
> Noisebridge-discuss mailing list
> Noisebridge-discuss at lists.noisebridge.net
> https://www.noisebridge.net/mailman/listinfo/noisebridge-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.noisebridge.net/pipermail/noisebridge-discuss/attachments/20090925/79770d7e/attachment-0003.html>


More information about the Noisebridge-discuss mailing list