Talk:Data erasure
This is the talk page for discussing improvements to the Data erasure article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
This article has not yet been rated on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | |||||||||||
|
Merge to data remanence
editBackground/full disclosure: See Talk:Data remanence/Archive 1#Proposed merge and Talk:Data remanence/Archive 1#Overhaul and merge
I propose merging Data erasure into Data remanence, for the same reasons I and others have merged similar articles before: They're all dealing with the same thing. Data remanence is the problem. Data erasure is a countermeasure. They are two sides of the same coin. As such, it is more useful to the reader to treat them in one article, rather than asking the reader to jump around. Causes, ramifications, and countermeasures are all part of the same whole. In particular, without a merge, both articles have to spend a lot of words on the same introductory and background material. That wastes the reader's time. Comments? Objections? —DragonHawk (talk|hist) 00:24, 10 November 2008 (UTC)
I dispute the proposal to merge the topic of data erasure with data remanence on several grounds. First, data remanence is simply the residual representation of data after removal attempts of various kinds, which may or may not involve data erasure -- a specific type of overwriting. Also, the term data remanence is a more obscure search term that would make it difficult to locate a discussion on removing data. Mlscarabiner (talk) 19:29, 16 December 2008 (UTC)
- Easy one first: Data erasure can be made into a redirect to data remanence (or vice versa), so searching isn't an issue. · Regarding content: This article seems to deal with quite a bit more than just a specific type of overwriting. Parts of the intro section, as well as the entire "Importance" section, are in fact mostly dealing with topics that the data remanence article addresses. We could merge just those sections and leave the remainder in isolation, but I think that would do the reader a disservice. I think it's far more useful to treat erasure in the large context of remanence, since that also covers why we care about erasure, and lets us compare and contrast different mechanisms. Do you disagree? —DragonHawk (talk|hist) 23:24, 16 December 2008 (UTC)
I disagree that it is more useful to treat data erasure in the larger context of data remanence. Data remanence occurs when data remains on an asset due to subpar data erasure methods, which is where the comparison and contrast of different mechanisms should be discussed. The term data remanence should be referenced as the resulting complication of failed data erasure.—Mlscarabiner
I am removing the merge suggestion. This is mostly because it has limited support here on the talk page. I'm also removing it because that support seems to be based on assumptions about why the reader is looking at these pages. The best way to help the reader is by assuming as little as possible about why the reader is here. If data remanence is a problem for the reader then permanent data erasure is the solution for the reader. If Wikipedia were a problem-solving manual, it would make perfect sense to discuss both topics in one article. However, we can't assume such a motive for the reader of a general-purpose encyclopedia. Related topics are not "all dealing with the same thing." Just because an editor has a problem-solution orientation, that does not mean that the reader will. Some readers will want to know how data is erased without caring about why it's done that way. Those readers will be poorly served by a redirect from "Data erasure" to "Data remanence." Other readers will only want to know about remanence. Presenting similar or even identical introductory and background content in articles about related topics is something that print encyclopedias do often. Flying Jazz (talk) 23:53, 15 September 2009 (UTC)
Citation work
editI unified the format of citations. Expanded raw URLs to aid future dead link recovery. Recovered four dead links (except for that difficult German one - the title would have helped here.) Converted the list of notable breaches from inline links to expanded inline citations, again to aid future dead link recovery - it had explanatory titles (which is fine), which didn't match the article title when linked, which made dead link recovery harder. --Lexein (talk) 11:12, 20 July 2010 (UTC)
- Lovely work. That's sort of things that I love doing so maybe we'd better be a team! :) Fleet Command (talk) 13:27, 21 July 2010 (UTC)
German BSI TL-03423 standard?
editPer Shredding Methods (Protectstar.com),
- "8 Cycles: German BSI / VS-ITR Standard (TL-03423) In March 2010 the German Federal office for IT Security (BSI) published a new technical BSI Guideline for "Requirements to overwrite memory media TL-03423) (Download / PDF). The method is similar to VSITR standard for magnetic storage media. In total the new algorithm has 8 cycles, which has to be worked through in chronological order. Includes one cycle of verification."
Unfortunately TL-03423 does not seem to be available from https://www.bsi.bund.de, so its contents cannot be verified, though its existence "BSI TL-03423 Anforderungen zum Überschreiben von Datenträgern" ("Requirement to overwrite memory media") is noted in BSI Forum 2010#1 (PDF) and Newsletter - Ausgabe 04/2009, 17. Dezember 2009. Oh well. --Lexein (talk) 22:10, 20 July 2010 (UTC)
Sources
editAcademic paper:
- Paula Thomas and Theodore Tryfonas (2007) Hard drive disposal and identity fraud Springer Boston. ISBN: 978-0387723662. New Approaches for Security, Privacy and Trust in Complex Environments p. 461-466 DOI: 10.1007/978-0-387-72367-9_41 —Preceding unsigned comment added by Lexein (talk • contribs) 15:07, 21 July 2010 (UTC)
widespread dangerous misconception about format and delpart
editWe need info such as here and here in this article and disk formatting that these commands do not do not mean "erase", despite the widespread dangerous misconception.--Espoo (talk) 00:50, 3 November 2010 (UTC)
no reliable info about utilities allowed?
editWhy was this reverted? Many similar Wikipedia pages have links to reliable sources of information on relevant utilities. --Espoo (talk) 00:59, 3 November 2010 (UTC)
- Probably because Wikipedia is not meant to be useful but verifiable and not a list of links? And no, I'm not trolling. That's a legitimate policy (that I have some reasons to disagree with being so strict), but sadly makes people like me waste time going through pages and pages of Bing/Google/etc. results. 71.196.246.113 (talk) 03:23, 26 July 2012 (UTC)
Misleading claim about recovering overwritten data
editThe data on Bradley Manning's PC was certainly not overwritten in the sense that it would defeat even software recovery tools. That very article linked to says this. Even if you somehow were able to recover some statistical data or sectors marked bad ('reallocated') from the overwritten cylinders, it would not likely be entire files. Even if you were a company willing to spend millions for recovery, the data recovery services would tell you that it's just lost if you somehow did several full formats and OS reinstallations over the needed data.71.196.246.113 (talk) 03:30, 26 July 2012 (UTC)
POOR ENGLISH — ABSURD USE OF 'INDUCE'
editI would have changed this myself but there is no edit tab in the first section. Consider the following phrase:
"Theft of an SED will induce physical asset loss (...)"
This is daft — 'theft' will not 'induce' loss of a 'physical asset' (why not put 'object'?), it will result in loss. If someone steals your car, you lose it (most likely, for good). Now, having had your car stolen might induce you to be more careful where you park a vehicle in future, not to leave keys in the ignition and so on but that is quite another matter.
In other words, using fancy words such as 'induce' without having the foggiest idea of their meaning is a bad idea. Why not phrase the whole thing more simply? My suggestion is: "Such data security will ensure that if your computer is stolen, thieves will not be able to read the information stored on it". — Preceding unsigned comment added by 79.157.233.205 (talk) 09:31, 14 March 2014 (UTC)
- Yeah, that wasn't too pretty. Went ahead and improved the language in lead section, please check it out. — Dsimic (talk | contribs) 21:05, 15 March 2014 (UTC)
Long time
editCan you give an example of data erasure that takes many hours, days, weeks, months, years, decades, centuries, or millennia to complete? GeoffreyT2000 (talk) 02:00, 24 March 2015 (UTC)
External links modified
editHello fellow Wikipedians,
I have just added archive links to one external link on Data erasure. Please take a moment to review my edit. If necessary, add {{cbignore}}
after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}}
to keep me off the page altogether. I made the following changes:
- Added archive https://web.archive.org/20080626203927/http://www.bsi.de:80/english/gshb/manual/s/s02167.htm to http://www.bsi.de/english/gshb/manual/s/s02167.htm
When you have finished reviewing my changes, please set the checked parameter below to true to let others know.
This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}}
(last update: 5 June 2024).
- If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
- If you found an error with any archives or the URLs themselves, you can fix them with this tool.
Cheers.—cyberbot IITalk to my owner:Online 05:25, 24 January 2016 (UTC)
Coatrack of data security topics?
editNot sure if this qualifies as a WP:Coatrack, but much of the article is devoted to off-topic data security subjects from data breaches (that did not clearly relate to erasure) to HIPAA (which has only passing relevance to erasure). Not suggesting that the content isn't reasonably due and sourced, but it's off-topic. — soupvector (talk) 00:57, 20 May 2019 (UTC)
- Had a very quick glance. Some thoughts. Please be clear if this applies to the whole article or specifically to the "Importance" section. There may be a case for spliting "data breaches (from failure to remove data from disposed media)" as a separate article (I recall an early recorded case in UK a 2nd hand (ex mil.?) omputer bought in a shop in Oxford and I remember passing a comment to someone about it in the 1990s and they said "We built that ...! (was amazed still worked)". Quite possibly however the authors of this article have a different bent on the subject than may be implied by the title.Djm-leighpark (talk) 01:26, 20 May 2019 (UTC)
delete or rewrite the paragraph about SED
editThe paragraph : "Presently, dedicated hardware/firmware encryption solutions can perform a 256-bit full AES encryption faster than the drive electronics can write the data. Drives with this capability are known as self-encrypting drives (SEDs); they are present on most modern enterprise-level laptops and are increasingly used in the enterprise to protect the data. Changing the encryption key renders inaccessible all data stored on a SED, which is an easy and very fast method for achieving a 100% data erasure. Theft of an SED results in a physical asset loss, but the stored data is inaccessible without the decryption key that is not stored on a SED, assuming there are no effective attacks against AES or its implementation in the drive hardware."
is confusing, it seems that encryption for data erasure works only with SED, while it can be done by software, circumventing potential compromised SED firmware. cf. https://wiki.archlinux.org/title/Self-encrypting_drives#Disadvantages