Talk:Filesystem-level encryption
This article is rated Start-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||||||||||||||||
|
Link on filesystem infobox
editTemplate for filesystems redirect here in "transparent encryption", however transparent encryption is both a per-file encryption (like EFS) and a per-volume encryption (like DR-DOS or Cryptoloop), that transparently encrypts and decrypts file/volume contents without the user or the programs knowing about that process.
I think that this article should be enhanced and renamed.
—Claunia 12:37, 30 October 2006 (UTC)
- Or better yet, enhance this Common filesystem features article.
- —Claunia 12:49, 30 October 2006 (UTC)
- In the context of filesystems, it doesn't make any sense to talk about transparent block device-level encryption (disk encryption) - as any filesystem supports this method as long as the operating system has a means for disk encryption. I think the link caption in the filesystem infobox template should be changed instead to make it more clear. And I don't see a need for rename, either - there already are articles on full disk encryption and disk encryption which cover the disk-level encryption part. In my opinion, separating these is a good thing, as they are conceptually very different - although a generic article comparing the two would be nice to have, too. As for enhancing, name one article on Wikipedia that shouldn't be enhanced? ;) -- intgr 22:16, 30 October 2006 (UTC)
Naming
editWikipedia appears to have a de facto standard of spelling out "file system" as separate words instead of "filesystem"; however, I don't think the title of this article (or any links) should follow that, as the phrase "file system-level encryption" could be interpreted as "system-level file encryption" which is not quite right – file system is a precise technical term. Opinions? -- intgr 03:29, 16 December 2006 (UTC)
- Seems like a pragmatic solution. Open4D (talk) 07:10, 29 November 2013 (UTC)
Re: reverted edit by 69.140.68.72
edit"Given the coarsely stated differentiation between "filesystem-level encryption" and "cryptographic file systems," it should be clear to all but the novice that the former does not in any way implement automatic encryption, which—one imagines—is what the user would expect. Nor is a file kept encrypted automatically and updated, fully encrypted, in place: indeed, one must bodily decrypt, modify, and encrypt in order to make the least change. Anyone can use a third-party utility to encrypt this file or that folder on demand, so packaging that capability within the file browser and terming it "filesystem-level encryption" is, at best, deceptive. The differentiation indicated heretofore, that is, whether metadata is or is not encrypted, merely obfuscates the issue. Windows, in fact, does not provide any capability resembling automatic encryption: to this extent, at least, the oft-ballyhooed "filesystem-level encryption" is merely a minor convenience that frees the user from having to install a third-party encryption application."
- [User:Intgr] responded with "(revert POV/weasel blurb; no source cited for claiming that general-purpose FSes don't do in-place updates; Windows does provide 'automatic' encryption with folder attributes)."
- We may be splitting hairs here, but let's clarify: Windows implements what I'd call "conditional filesystem-level encryption". The encryption by EFS is entirely automated, not requiring any user intervention once it's initially configured, and it is transparent to all applications except those that explicitly implement the Backup APIs. That said, it's conditional in that the EFS component driver will encrypt files only if it detects that either (a) the folder has the Encrypted attribute enabled, or (b) the user application (e.g. Windows Explorer, CIPHER.EXE) has passed an explicit flag to request that the file be created encrypted. Once a file is encrypted, it is kept encrypted automatically and updated, fully encrypted, in place (unless the user explicitly requests that the file be decrypted).
- Question to the original poster (69.140.68.72): to what other mistakenly-labelled "filesystem-level encryption" application are you referring? —Preceding unsigned comment added by ParanoidMike (talk • contribs) 22:07, August 27, 2007 (UTC)
- Maybe the problem with "differentiation between filesystem-level encryption and cryptographic file systems" would be mitigated by my suggestions at Talk:Disk encryption/Archive 1#File & disk encryption article restructuring. Part of my suggestion is that this Filesystem-level encryption article would become just a redirect. Open4D (talk) 07:16, 29 November 2013 (UTC)