https://wiki.gnome.org/Steve%20Dodier-Lazaro/FileSystemPersonas
I'll develop later, it'd be good to have others had their stories / stories of their relatives or coworkers. And of course their interpretations of each story because I'm subjective and amateurish in all that stuff :) -- 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 ________________________________ From: desktop-devel-list <[email protected]> on behalf of Dodier-Lazaro, Steve <[email protected]> Sent: 25 May 2014 12:27 To: Jasper St. Pierre Cc: [email protected]; [email protected] Subject: RE: Are file systems outdated for accessing user content (in a world of sandboxed apps)? (was: RFC - file chooser dialog API for sandboxed apps) 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
_______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
