Spotten skrev:Hej.
Jeg har lige "Spottet" en fejl som jeg VED har virket før.
Jeg kan ikke længere smide et . foran et mappenavn og dermed gøre det IKKE er synligt for enhver på mit skrivebord, jeg ved det har virket før.
Nogle der kan sige mig hvad man gør for at få det tilbage som det engang var?
Hader når der bliver lavet om i ens ting til det værre, det er ikke fremskridt, men tilbagegang!
På forhånd tak.
lath skrev:Spotten skrev:Hej.
Jeg har lige "Spottet" en fejl som jeg VED har virket før.
Jeg kan ikke længere smide et . foran et mappenavn og dermed gøre det IKKE er synligt for enhver på mit skrivebord, jeg ved det har virket før.
Nogle der kan sige mig hvad man gør for at få det tilbage som det engang var?
Hader når der bliver lavet om i ens ting til det værre, det er ikke fremskridt, men tilbagegang!
På forhånd tak.
Jeg har lige testet det hos mig og i Nautilus (Filhåndtering) bliver en . (dot) mappe skjult men det sker ikke på desktoppen.
Så det er ikke kun hos dig at desktoppen opfører sig sådan. Måske fordi det ikke rigtig giver mening at skjule noget der.
Til det har du hjemmemappen.
/Lars
AJenbo skrev:Virker fint for mig, jeg skal bare trykke f5 for at genopfiske skrivebordet efter jeg omdøber filen.
Spotten skrev:AJenbo skrev:Virker fint for mig, jeg skal bare trykke f5 for at genopfiske skrivebordet efter jeg omdøber filen.
F5 og højre klik "Opstil efter navn" er ikke det samme? Synes der mangler denne "Opdater" i højrekliks menuen (Ved godt det ikke er Windows)
Men tak, så ved jeg da F5 er den "gyldne" knap jeg skal bruge!
Det kan jo være man roder lidt rundt som jeg gør, og måske lige kort har noget midlertidigt liggende på sit skrivebord som man gerne vil gemme så andre ikke "bare" lige kan se det men skal hente funktionen der viser skjulte filer, og de fleste ville nok ikke lige tænke over der lå skjulte filer dér, de ville sikkert først kigge i hjemmemappen, det ville jeg i hvert fald selv gøre.
Feature:Security Through Obscurity
NewsPosted by CmdrTaco on Monday July 20, @03:19AM
from the its-a-bad-idea dept.
Bruce Perens has sent us another writeup, and this one hopefully won't cause a flamewar that brings the server to its knees! This one is on Security Through Obscurity, and why it just doesn't work. Specifically, Bruce talks about cryptography and why open source is necessary to produce truly secure internet applications.
The following is a feature written by Slashdot Reader Bruce Perens
Why Security-Through-Obscurity Won't Work
Bruce Perens
bruce@opensource.org
With all of the threats of new cryptography export laws, and the copyright bill in congress that would illegalize the circumvention of a copyright-protection system, it's time for us to go over the concept of security through obscurity, and why it's a bad idea. I try to explain the concepts as simply as possible in this article, so that non-programmers can understand them.
The encryption feature of a popular commercial spreadsheet program was broken several years ago, when a programmer realized that the spreadsheet always stored the same character sequences at fixed locations in its encrypted file. Because he knew what those characters were when decoded, and because the spreadsheet used a rather unsophisticated code, he could look at the encoded file and work out the code key. That programmer wrote an application that would automatically work out the code key and decode the entire spreadsheet. At that point, the programmer notified the spreadsheet manufacturer that their encryption function had a security bug, and should not be used. He expected the manufacturer to pass this information on to their customers and issue a revision of the program with a less-easily-broken encryption feature.
The spreadsheet manufacturer tried to solve this problem by security through obscurity. They threatened the programmer with a lawsuit or criminal action if he revealed the method of breaking the code. Because another programmer might figure out the method given only the clue that the code had been broken, the spreadsheet manufacturer also threatened lawsuit or criminal action if the programmer even told anyone else that their encryption function was breakable.
Security through obscurity is always a bad idea. In this case, the manufacturer assumed that nobody as smart as that particular programmer would come along for a while, and thus their customers would be secure if this one programmer could be dealt with. However, they did not consider that someone else might have already broken the spreadsheet code without telling the manufacturer, and might already be using the technique to eavesdrop on some rich corporation's secrets.
Many software manufacturers hide bugs that impair the security of programs, or even entire operating systems, without knowing whether some outsider has already found and exploited these bugs. The only proper course for a software manufacturer is to issue a software update as soon as possible after a problem is found, and to inform all customers that the update must be installed to correct an existing security problem. Until more manufacturers understand that security through obscurity is a fallacy, you should consider that popular computer operating systems, applications, and cryptography programs are presently compromised. Do not rely on the security features of these systems.
One exception to the above are Open Source operating systems such as Linux and FreeBSD, and cryptography programs such as GNU Privacy Guard. Because the developers of these systems publish all of their source code for others to read, they can't rely on security through obscurity. The publication of source code actually improves security because the program or operating system can be peer-reviewed by anyone who cares to read it. Many security bugs that are overlooked in other operating systems have been caught and repaired in Linux, because of its extensive peer-review process.
National governments attempt to use security through obscurity. For example, the United States Government forbids the export of strong encryption software, seemingly under the assumption that people in other nations aren't smart enough to write similar software! A copyright law now in the U.S. congress attempts to legislate security through obscurity by banning code-breaking tools, and placing a half-Million-dollar penalty on the act of code-breaking. This would tremendously cripple computer security, because the only way to tell a good code from a bad one is to attempt to break it.
Here's the test that should be applied to all of your cryptography software, the applications you use for privileged data, and the operating systems on which you run those programs. This test is already used by knowledgeable cryptography manufacturers like RSA Data Security. First, publish the source code to your program, or, in the case of a cryptography program, publish complete details of the encryption algorithm so that a programmer can understand exactly how the code works. Encourage programmers to study your system and to attempt to break it. Only when a program has been publicly reviewed this way, and when people have tried to break it and have failed, can you be assured that it's useful for concealing your secrets.
Scientists who review codes will rarely call them unbreakable. There are only a few special circumstances in which an unbreakable code is even theoretically possible. Instead, they will tell you that a good code can't be broken in less than decades using the most powerful computers available today, and that is what makes it practical for you to use. Faster computers are constantly being developed, and we are learning more about computer security every day. To assure the continued integrity of your system, you must continue to encourage people to break it as the process becomes "easier". Eventually, computers become powerful enough to break a particular code, and that code must be retired to make way for a more difficult one.
Some time ago, programmers hit upon the fact that they could couple thousands of momentarily-idle workstations together over the Internet and make them all work on the same problem simultaneously. By doing this, they could create "virtual" supercomputers, at low or no cost, more powerful than the Billion-dollar supercomputers in government code-breaking agencies like the U.S. National Security Agency. These networks, run by thousands of amateurs guided by a few cryptography scientists, are now able to make short work of breaking codes like the old 56-bit DES, once recommended for business use by the U.S. Government. As the news of these codes being broken is made public, their retirement is forced in favor of more difficult-to-break versions. This is exactly the work that the circumvention law would ban, and the result would be that people would continue to use obsolete codes long after they became breakable.
lath skrev:Spotten skrev:AJenbo skrev:Virker fint for mig, jeg skal bare trykke f5 for at genopfiske skrivebordet efter jeg omdøber filen.
F5 og højre klik "Opstil efter navn" er ikke det samme? Synes der mangler denne "Opdater" i højrekliks menuen (Ved godt det ikke er Windows)
Men tak, så ved jeg da F5 er den "gyldne" knap jeg skal bruge!
Det kan jo være man roder lidt rundt som jeg gør, og måske lige kort har noget midlertidigt liggende på sit skrivebord som man gerne vil gemme så andre ikke "bare" lige kan se det men skal hente funktionen der viser skjulte filer, og de fleste ville nok ikke lige tænke over der lå skjulte filer dér, de ville sikkert først kigge i hjemmemappen, det ville jeg i hvert fald selv gøre.
Security through obscurity er ikke sikkerhed!
Fra Slashdot.org: http://slashdot.org/features/980720/0819202.shtml:Feature:Security Through Obscurity
NewsPosted by CmdrTaco on Monday July 20, @03:19AM
from the its-a-bad-idea dept.
Bruce Perens has sent us another writeup, and this one hopefully won't cause a flamewar that brings the server to its knees! This one is on Security Through Obscurity, and why it just doesn't work. Specifically, Bruce talks about cryptography and why open source is necessary to produce truly secure internet applications.
The following is a feature written by Slashdot Reader Bruce Perens
Why Security-Through-Obscurity Won't Work
Bruce Perens
bruce@opensource.org
With all of the threats of new cryptography export laws, and the copyright bill in congress that would illegalize the circumvention of a copyright-protection system, it's time for us to go over the concept of security through obscurity, and why it's a bad idea. I try to explain the concepts as simply as possible in this article, so that non-programmers can understand them.
The encryption feature of a popular commercial spreadsheet program was broken several years ago, when a programmer realized that the spreadsheet always stored the same character sequences at fixed locations in its encrypted file. Because he knew what those characters were when decoded, and because the spreadsheet used a rather unsophisticated code, he could look at the encoded file and work out the code key. That programmer wrote an application that would automatically work out the code key and decode the entire spreadsheet. At that point, the programmer notified the spreadsheet manufacturer that their encryption function had a security bug, and should not be used. He expected the manufacturer to pass this information on to their customers and issue a revision of the program with a less-easily-broken encryption feature.
The spreadsheet manufacturer tried to solve this problem by security through obscurity. They threatened the programmer with a lawsuit or criminal action if he revealed the method of breaking the code. Because another programmer might figure out the method given only the clue that the code had been broken, the spreadsheet manufacturer also threatened lawsuit or criminal action if the programmer even told anyone else that their encryption function was breakable.
Security through obscurity is always a bad idea. In this case, the manufacturer assumed that nobody as smart as that particular programmer would come along for a while, and thus their customers would be secure if this one programmer could be dealt with. However, they did not consider that someone else might have already broken the spreadsheet code without telling the manufacturer, and might already be using the technique to eavesdrop on some rich corporation's secrets.
Many software manufacturers hide bugs that impair the security of programs, or even entire operating systems, without knowing whether some outsider has already found and exploited these bugs. The only proper course for a software manufacturer is to issue a software update as soon as possible after a problem is found, and to inform all customers that the update must be installed to correct an existing security problem. Until more manufacturers understand that security through obscurity is a fallacy, you should consider that popular computer operating systems, applications, and cryptography programs are presently compromised. Do not rely on the security features of these systems.
One exception to the above are Open Source operating systems such as Linux and FreeBSD, and cryptography programs such as GNU Privacy Guard. Because the developers of these systems publish all of their source code for others to read, they can't rely on security through obscurity. The publication of source code actually improves security because the program or operating system can be peer-reviewed by anyone who cares to read it. Many security bugs that are overlooked in other operating systems have been caught and repaired in Linux, because of its extensive peer-review process.
National governments attempt to use security through obscurity. For example, the United States Government forbids the export of strong encryption software, seemingly under the assumption that people in other nations aren't smart enough to write similar software! A copyright law now in the U.S. congress attempts to legislate security through obscurity by banning code-breaking tools, and placing a half-Million-dollar penalty on the act of code-breaking. This would tremendously cripple computer security, because the only way to tell a good code from a bad one is to attempt to break it.
Here's the test that should be applied to all of your cryptography software, the applications you use for privileged data, and the operating systems on which you run those programs. This test is already used by knowledgeable cryptography manufacturers like RSA Data Security. First, publish the source code to your program, or, in the case of a cryptography program, publish complete details of the encryption algorithm so that a programmer can understand exactly how the code works. Encourage programmers to study your system and to attempt to break it. Only when a program has been publicly reviewed this way, and when people have tried to break it and have failed, can you be assured that it's useful for concealing your secrets.
Scientists who review codes will rarely call them unbreakable. There are only a few special circumstances in which an unbreakable code is even theoretically possible. Instead, they will tell you that a good code can't be broken in less than decades using the most powerful computers available today, and that is what makes it practical for you to use. Faster computers are constantly being developed, and we are learning more about computer security every day. To assure the continued integrity of your system, you must continue to encourage people to break it as the process becomes "easier". Eventually, computers become powerful enough to break a particular code, and that code must be retired to make way for a more difficult one.
Some time ago, programmers hit upon the fact that they could couple thousands of momentarily-idle workstations together over the Internet and make them all work on the same problem simultaneously. By doing this, they could create "virtual" supercomputers, at low or no cost, more powerful than the Billion-dollar supercomputers in government code-breaking agencies like the U.S. National Security Agency. These networks, run by thousands of amateurs guided by a few cryptography scientists, are now able to make short work of breaking codes like the old 56-bit DES, once recommended for business use by the U.S. Government. As the news of these codes being broken is made public, their retirement is forced in favor of more difficult-to-break versions. This is exactly the work that the circumvention law would ban, and the result would be that people would continue to use obsolete codes long after they became breakable.
Du kan læse mere på engelsk wikipedia: http://en.wikipedia.org/wiki/Security_through_obscurity
/Lars
Spotten skrev:
God læsning, men forstår ikke helt sammenhængen med denne tråd og denne tekst? Har endda læst alt nøje!
lath skrev:Spotten skrev:
God læsning, men forstår ikke helt sammenhængen med denne tråd og denne tekst? Har endda læst alt nøje!
At sikkerhed, som er baseret på at du gemmer noget væk, ikke virker.
/Lars