|
Hello,
>> A couple of thoughts on CSD:
>>
>> I prefer file systems as a primary method of storing and retrieving files because they're well understood by all current users, flexible enough to allow a per-activity organisation (in spite of their rigidity when you'd rather have several ways to index
the same set of files/folders, to view a whole folder as a timeline, etc.), and they're rather raw structure, so that means users can appropriate themselves this structure in ways we hadn't anticipated. File systems also already sit in an existing ecology
of tools readily available to organisations, so that means GNOME is also a workplace option. Providing per-app content selection as a primary means of interaction may create extra "noise" for organisational contexts where CISOs can't afford to let users rely
on their apps to store and exchange data but would rather impose a contracted service provider.
>>
> I just want to make a few remarks here about this. Maybe this is a bit off-topic for a security thread, but I think it's worthwhile to talk about.
Indeed. I'll cut your anecdotes into personas of computer beginners/experts and then add mines to the list. Will put that on on a Wiki page asap.
> This is personal anecdotal evidence, but one of the big issues I've seen with less-computer-savvy folks (relatives, parents, friends) is that they don't grasp a full understanding the filesystem. It's difficult for them to visualize an infinitely nesting
set of folders, since that obviously can't happen in real life.
>
> So they tend to think of the system as flat, with a few folders, and if they can't see the proper in the immediate explorer window, they think the files that they had were lost forever.
>
> They think of the "desktop" not as just another folder, but as the working set, almost. This is rarer, but I've seen several people drag files out of folders and onto the desktop, then open it in Word, and then when they're done, they file it back away.
>
> They're always losing their files: "where did I put my files?"
>
> At this point, even on my computer, I don't care about properly categorizing and filing things, unless I'm doing a big project across 200 or so files where filing and categorization helps. For the most part, if I'm downloading a stray file (album I bought
off of Bandcamp, .exe file, other random media files), I just save it to the default location, which is most likely the Desktop, Downloads folder, or my user folder, and rely on search to help me find my stuff again.
>
> At some point later, if I need to categorize stuff better, I'll search for it and drag it to a new folder. So while the GNOME apps "Collections" designs aren't perfect for that use case, they do make it easy for me to go back to my random assortment
of files and start organizing them.
>
> I think this sort of behavior makes sense for our users, too. Users who grasp the organizational power of nested folders should be able to use them, but we shouldn't force other users to choose where to put their files. They should be able to have a
dumping ground and find things through search, and maybe categorize and clean up later if it gets too messy.
You're right here. For me the file system has two primary advantages: it's "raw" in that it allows a lot of different strategies/practices (some efficient, some painful to the user), whilst a system that comes more structured out of the shelf offers less
freedom for appropriation. The second advantage, even more important, is that it's always been here.
You can't compare the switch to per-app storage on the mobile to a switch to content selection on the desktop/laptop/tablet because mobiles didn't already have an ecology of tools that expect a file system, sharing and collaboration tools built on top
of file systems and a majority of current users who have had years of experience with file systems on that very platform. In fact all the "power user" Android ROMs come with a file manager -- which is incredibly more convenient than the default gallery for
deleting bulks of files I've already sync'd on my Dropbox... And I (speculatively) suspect Windows users who have such a need connect their phone to the PC and use the PC interface.
> Windows 7 tried to approach both problems with its idea of aggregate folders, "Libraries", which I thought was a clever solution, but I never used it that much.
Haven't used Windows for ages, so this is taken right from the Windows doc: "In Windows 7, you simply create a library, name it something (perhaps, "Family Photos"), and then tell Windows which far-flung folders your new library should include. Your photos
are still physically located in three different spots—but now they show up in a single window." This sounds to me like users are still expected to know and understand the underlying file system organisation and to know (at least at setup time) where to find
stuff. So that wouldn't solve the problem of users needing to put together related files (whether there's any chance for the system to be aware of the relationship or not) without being exposed to the file system's structure, let alone maintaining that view
of their system when using applications that don't already integrate with Libraries.
Before someone ventures there, I should say that finding which files are relevant to one another is a complex problem (relevant read: http://www.eecs.berkeley.edu/Pubs/TechRpts/2008/EECS-2008-163.pdf and if you like theory: http://www.ics.uci.edu/~jpd/ubicomp/Dourish-Context-PUC.pdf
and http://www.dcs.gla.ac.uk/~matthew/papers/jcscwContextOld.pdf). Finding which are relevant to one another securely (when you can't trust data coming from the user's applications, which may be compromised) is borderline impossible (see http://www.cs.berkeley.edu/~tygar/papers/Machine_Learning_Security/asiaccs06.pdf;
combined with CAAD, what you'd need to solve to have actual "zero-effort libraries" would be an adversarial version of CAAD).
I'll discuss a bit further the fact that any mapping applied to the file system needs to be systematically applicable (as drago01 pointed out).
> The other point I want to make is that the filesystem mixes up user data and system internals, to the point where it's common for people to hide their porn collection in folders C:\Windows\System32 like they would between a mattress boxspring, because
it's "internals".
Indeed, and let me ask you how exactly am I meant to hide my porn collections without a cryptic file system? :) I'll add a "porn hider" persona to my list in fact, because hiding files from relatives (ideally in a repudiable way) is definitely a feature
needed on shared computers (we could also take a second to reflect upon the fact that people still find it too inconvenient to separate accounts and share data across accounts / re-log to their own account when a session is open, etc. There's room for intervention
here!).
> It's dangerous for less-computer-savvy users to be able to see the system internals and poke around in there. We can try to partition user data away from the dangerous parts of the filesystem: C:\Windows and C:\Users, but it's not a true separation to
its core.
We should be able to do something about that... Nautilus could show some information bar to tell users not to mess with .config, etc., unless told to in a tutorial or unless they know what they're doing... It shouldn't be a prime cause of concern though
as there are plenty of use cases where even a non-savvy user might need to fiddle and retrieve some logs, apply some correction to a config file to circumvent a bug, etc.
> The filesystem is an *excellent* data structure for O(1) keyed hierarchical local data storage, and we shouldn't throw that away, because it makes sense to build a bunch of system internals on, but I don't think we should expose it directly to the user.
It shouldn't be completely inaccessible -- hackers and engineers like ourselves won't stop using it, but we should start thinking of new, more user-centric models.
I almost entirely agree with you, you're right to point out there might be better fits. Though, I believe a "User Documents" file system so to speak is still a good candidate for users to handle their data as it lets a variety of users deploy their own
strategies (however articulated they are).
> You touched upon this a bit as well, but with the advent of cloud storage services like Dropbox, Google Drive, ownCloud, iCloud, etc. the whole model of "O(1) keyed hierarchical local data storage" breaks down, since now you have networking in the middle.
Dropbox had a brilliant solution to the problem: they have a little program in the background that notices new files and old files and syncs your data automatically, so it integrates seamless with existing filesystem-based apps, and it's still O(1).
> The way I look at it, and the way Dropbox looks at it too, is that the program is only a backwards-compatibility thing for desktops. Dropbox's new technology is all about new content pickers you can add into your web or iOS or Android apps.
I'm also curious how existing efforts to integrate with file systems would get in the way of exposing apps/remote stores in a content selection fashion. That's why I think the FS should be fully supported and parallel views should be made available. Those
parallel views then don't degrade the UX of FS-capable users, and they don't need to be 100% complete anymore as users can occasionally go back to the old-yet-complete FS view.
Other views could include per-app views, per-location view, per-content-type views, timeline-based views. There's a lot of room to help users select what they prefer, especially if file search is well optimised with indexes.
> Plenty of user research is being done in this area at UX labs. I'd love to see more research and studies done on better data storage models for average users.
> Jasper
It's very hard to come up with a view, right now, of what's better. There's not only testing specific approaches to specific users in specific contexts (which necessarily would be different to what GNOME would deploy for its own users in its users' own
ecosystems), but also thinking about how users appropriate themselves the technology you give them. I'm aware that Paul Dourish (who is a very respectable researcher, already member of the CHI Academy for his work on embodied interaction and contextuality)
wrote an essay on appropriation illustrated with his own research on file system replacements; surely a relevant read! http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.20.4274&rep=rep1&type=pdf
As for writing APIs for sandboxed apps, I'm fairly confident the general approach I have in libsandboxutils would apply equally well to a Content Selection Dialog, so I'm not very concerned about what GNOME thinks fits their users best. As far as I'm concerned,
I'd probably prefer to deploy a FS-based dialog because I want to study whether the sandbox layer gets in the way of my study participants rather than the new approach to selecting their content.
Cheers,
--
Steve Dodier-Lazaro PhD student in Information Security University College London Dept. of Computer Science Malet Place Engineering, 6.07 Gower Street, London WC1E 6BT OpenPGP : 1B6B1670 |