Possible, but I see you are factually wrong.

No one in the whole thread is advising identifying files manually. Different people are proposing file names, extensions, content etc. all non-manually / automatically / programmatically / transparently to the end user.

And I never said putting this information in file name is a good strategy, so why you litter your post with such irrelevant content is beyond me. This is why I read but am not addressing more than half of this post of yours too.

I got it. You are among the proponents of evil bit. I agree information security is trivial once we get all the evil people to set this evil bit. Real life is not so simple - web servers areone of the least trustworthy elements in a typical user's computing life.

In RFC 3514 world, yes. In real life, this "metadata" will need to be edited, or distrusted. So we do need to identify a file. In the face of this imperfect world, there are certain difficulties. Whether it is a perl script or a jpeg image can best be figured out from looking at file content.

NOT from file name.
NOT from metadata set by untrustworthy people.

Yes, wherever some information is, it has to be read and processed. ANY information.

Many applications can be used to process jar files as well as zip files. In as much as they use the same container, they ARE the same type of files. In as much as the purpose is different, there should be another data to be read somewhere. Remember you could change the "separate" metadata from application/zip to application/jar - so ALL the confusion that results from decisions taken by examining file content are all possible in decisions taken by examining the separate metadata.

But in this separate metadata, not only the OS might attempt running a zip application on a jar file, it could also run photoshop on an excel sheet. Which is a much more varied possibility, testing against is many orders of magnitude more difficult than testing security of zip applications opening jar files, and hence much much more risky.

Yes, so rather than execute a regexp of "any complexity", just run a multi-megabyte application on it because that is not a risk.

Irrelevant.

Which is a good thing. A perl script IS different from an image, even though an image can be made to look like a perl script by relatively minimal change. Actual security scenario around the file has changed by that change in "in-data identifiers".

Which is again a good thing. A file triggering notepad by default being converted into a file triggering photoshop by default IS a modification to the file's most common behaviour. Why should it not require a write access?

I think either you don't know what you are talking about, or you haven't understood the thread subject at all. I repeat my example - "The context is that OS components need to distinguish between an image and a perl script."

Exactly the same is wrong with extension approach too. Double clicking on a .emacs file in windows comes with error "Windows can't open this file".

Both are issues of the database not being updated, not fundamental problems in the approaches. But looking at content to decide about the content at least makes half a sense. Looking at an independent variable - last few characters of the file name makes zero sense and is a fundamental problem in the approach.

The context is that OS components need to distinguish between an image and a perl script. The only difference between them that is significant in this context is in the content of the file. So it is a poor idea to examine anything else other than the file itself.

File name, extension, mimetypes, separate changeable attributes are all poor ideas when the file itself is available for examination.

Which 2 classes? "Data" and "executable"? There is no distinction as long as interpreters exist. Spread sheets are data, but if opened in MS Excel can perform actions that many executables find difficult. Many many applications change registry when just opening "data" files. It is easy to make a file which is both a csv and a perl script.

Then there are zero day, and decades old vulnerabilities in many applications where a "maliciously" crafted data file can get the application to run arbitrary code.

For a regular human being, there is no possible way of distinguishing data from applications.

As long as interpreters exist, there is no difference between 'load this file in its proper application' and 'run this application'. You have to go full iOS and disable "interpreters", loosely defined.

From my perspective, this is the worst. Command line showing one name, explorer showing another name of the SAME folder. There are even applications which show the "internal" name, and some show the so-called "user friendly" name.

There is only one utility of things having a name - and that is that it doesn't keep changing depending on circumstances. Otherwise there is no point in anything having any name.

That is assuming backup strategy for all pictures is the same, that for all music is the same etc. This is a VERY bad assumption - leaving with 2 options :

1. Analyze the 120 GB documents, pictures and music spending 3 hours. Still, worst case backup 120 GB.
2. Backup 120 GB across documents, pictures and music.

Only one of those folders makes sense - Downloads. This is because it is unlikely one would want to backup downloads. But other backup strategy has nothing to do with whether something is called a document, or a picture or "a music".

Google gives me 3 results :

1. One is your slashdot post
2. One about memes with a quote written on an obese lady saying "lowering minimum wage will increase the number of jobs". No explanation/description.
3. One heritage.org, saying somewhat orthogonally "Increased Minimum Wage Does Not Reduce Poverty"

First try answering this question which has proven hard enough for you.

And superior for making phone bodies. I am waiting for 24 carat gold screw drivers for such idiots - steel is cheap, it's why the vast majority of cheap crap is made from steel. Nice stuff is made from gold.

Decide whether metal is more "isn't easy", or plastic is more "quite hard". I know doing real work is difficult - whether plastic or metal but it makes no sense to call both more difficult than each other to publicly declare your idiocy, since it is already well established from your first paragraph.

I see humans walking around with shattered glass in their phones' front and backs everyday. And those with plastic as good as new for months, good condition for years.

Poke extremely hard and squish cruelly, for modern plastics. Like you do to the big iPhone to hilarious results, except the hilarity in metal is forever.

Plastic doesn't just have "other" advantages, modern plastics have every advantage. Nothing better than "idiots feel smug about their cluelessness" can be said about this, I guess.

Aside from SSL in transport it is not encrypted. Gmail really needs encryption. Aside from Obama, there is no president of the US. US really needs a president.

Of wait, one president is enough. And one encryption is enough, especially for those who are fine with some third parties reading their mail. Oops, you're wrong again.

You used glass and solid in the same sentence. Apart from the legends about glass being liquid, I haven't met any one else yet who calls glass "solid" in its figurative sense either.

So the "idiots feel smug about their cluelessness" as spake a mindless person upthread seems right.

I checked again, and I don't find gmail really violating any of your golden principles laid out in this post - http://slashdot.org/comments.p....

Google reads mail - check.
Others cannot read mail - check.
Forgot password support - check

Gmail does even more - it has 2 factor authentication too.

In fact I agree with your statement

Encryption is useful against whoever has access to data bits and should be unable to read the data underlying those bits. Whether they be third, fourth or nth party when n tends to infinity. There are no such people in the case of gmail.