Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

×

Comment: Re:file magic - use the content to determine type (Score 1) 560

by bingoUV (#49180953) Attached to: Why We Should Stop Hiding File-Name Extensions

We're talking at cross-purposes.

Possible, but I see you are factually wrong.

My view is that we shouldn't be identifying files manually AT ALL.

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.

They should be part of the meta-data, as already is whenever you download a file. Just because it ends in .docx doesn't mean it's sent to you as application/microsoftworddocument (or whatever it is) by your browser. In fact, you can break stuff easily that way if you don't populate your webserver with proper mimetypes

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.

In fact, you can break stuff easily that way if you don't populate your webserver with proper mimetypes.

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.

But from that point on, we don't NEED to ever identify a file again

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.

Comment: Re:file magic - use the content to determine type (Score 1) 560

by bingoUV (#49180335) Attached to: Why We Should Stop Hiding File-Name Extensions

And encoding the filetype into the file means that you have to examine (and potentially interpret) the file to work out what to open it in.

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

That's fine for certain things (e.g. executables all start with MZ) but not for others (e.g. JAR files are indistinguishable from ZIP until you interpret the ZIP file contents and act upon that interpretation).

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.

As soon as the contents could be malicious, and you're running even a regexp of any complexity on it, it's a risk.

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

Encoding it into the filename itself is shoving metadata into other metadata. There's even a metadata separator involved here, the period in between! As such, they should be two separate and independently changeable pieces of information. Parsing the filename to work how to interpret the data inside is a nonsense, when you could just store "filename" (without the extension) and "filetype" separately. This also allows .jpg and .jpeg to be seen as the same thing (which they are!) and not require two separate and confusing entries!

Irrelevant.

Adding any in-data identifiers to existing files also means modifying the file, potentially modifying hashes and security on them.

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".

Changing the way they are interpreted on one machine will affect every machine they are visible on and require write-access to the file.

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."

Comment: Re:file magic - use the content to determine type (Score 1) 560

by bingoUV (#49179253) Attached to: Why We Should Stop Hiding File-Name Extensions

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.

Comment: Re:file magic - use the content to determine type (Score 1) 560

by bingoUV (#49179179) Attached to: Why We Should Stop Hiding File-Name Extensions

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.

Comment: Re:Better idea (Score 1) 560

by bingoUV (#49179003) Attached to: Why We Should Stop Hiding File-Name Extensions

The actual problem is simple and only needs to deliver a simple binary distinction between two specific classes of file.

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.

Could you possibly explain to a regular human being why that was the best possible way of distinguishing data from applications?

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

Comment: Re:Yes, I agree (Score 1) 560

by bingoUV (#49178683) Attached to: Why We Should Stop Hiding File-Name Extensions

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.

Comment: Re:Yes, I agree (Score 1) 560

by bingoUV (#49178679) Attached to: Why We Should Stop Hiding File-Name Extensions

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".

Comment: Re:Default Government Stance (Score 2) 194

by bingoUV (#49170083) Attached to: Feds Admit Stingray Can Disrupt Bystanders' Communications

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.

Comment: Re:Nope (Score 1) 231

by bingoUV (#49169489) Attached to: Samsung Officially Unpacks Galaxy S6 and Galaxy S6 Edge At MWC

And that's the thing. Plastic is cheap

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.

metal, which isn't as easy to work with

Building a good device out of plastic is quite hard - you need to

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.

Comment: Re:Nope (Score 1) 231

by bingoUV (#49164755) Attached to: Samsung Officially Unpacks Galaxy S6 and Galaxy S6 Edge At MWC

When you poke/squish the plastic, it moves and deforms. When you do the same to glass it stays rigid (like a solid).

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.

People like something that feels well built and solid even if the plastic being able to deform has other advantages.

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.

Comment: Re:Another bad omen for privacy and security (Score 1) 308

by bingoUV (#49164581) Attached to: Moxie Marlinspike: GPG Has Run Its Course

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.

Comment: Re:Nope (Score 1) 231

by bingoUV (#49164117) Attached to: Samsung Officially Unpacks Galaxy S6 and Galaxy S6 Edge At MWC

the solid feel of a phone with glass on both sides.

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.

Comment: Re:Another bad omen for privacy and security (Score 1) 308

by bingoUV (#49163987) Attached to: Moxie Marlinspike: GPG Has Run Its Course

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

It is not necessary that no third parties can decrypt your data or messages in order to have encryption be useful

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.

"Kill the Wabbit, Kill the Wabbit, Kill the Wabbit!" -- Looney Tunes, "What's Opera Doc?" (1957, Chuck Jones)

Working...