Earlier quoted context omitted.
> Linux somewhat supports /dev/tcp/HOSTNAME/PORT (technically that's application level in bash so not everywhere), and im sure there's daemons you could run to automount things on the fly. Do note that this has been disabled in the major distributions at compile time for pretty much ever. The debian bug to build bash with that feature by default is ~20 years old (and was closed as wontdo).
On two different Debian 10 boxes bash seems to have it enabled: Terminal 1 $ echo hi > /dev/tcp/127.0.0.1/9999 Terminal 2 $ nc -vvvlp 9999 Listening on [0.0.0.0] (family 2, port 9999) Connection from 127.0.0.1 57540 received! hi $
Man who thought opening a TXT file is fine thought wrong
241–250 of 316 posts
Re: Man who thought opening a TXT file is fine thought wrong
#242File extensions are a kludge anyway. (And Windows 10 still hides them by default, because hey, backwards compatibility, and you wouldn't want to confuse Grandma who's seen the file be called "grandkids" since Windows 95..). Why should the filetype be dependent on the name? People even think renaming a .BMP to .JPG means now it's a compressed file! Old school Macs stored the filetype outside of a file, so you can rena…
Re: Man who thought opening a TXT file is fine thought wrong
#243The title should be: > Man who thought opening a TXT file in TextEdit is fine thought wrong There are many, many text editors out there that would not attempt to parse HTML upon opening a text file.
> Man who thought TextEdit could be trusted as a plain text editor is wrong
This is one more example of what I find so frustrating about macOS, which is all those hidden little features trying to be "smart" and "user friendly" just in case I the user do not really know what I'm doing.
Re: Man who thought opening a TXT file is fine thought wrong
#244Oh, man. The idea that TextEdit automatically parsed .txt files as HTML if they started with a certain file signature is problematic... ...but the fact that file:// schemes can access remote files by appending /net/ followed by a domain name is pretty shocking. I mean, the entire purpose of "file://" would seem to be to provide access to local/mounted files and only those. The fact that a Mac engineer thought it woul…
Re: Man who thought opening a TXT file is fine thought wrong
#245Oh, man. The idea that TextEdit automatically parsed .txt files as HTML if they started with a certain file signature is problematic... ...but the fact that file:// schemes can access remote files by appending /net/ followed by a domain name is pretty shocking. I mean, the entire purpose of "file://" would seem to be to provide access to local/mounted files and only those. The fact that a Mac engineer thought it woul…
The extension is meaningless outside of Windows...
Re: Man who thought opening a TXT file is fine thought wrong
#246Earlier quoted context omitted.
According to you. I appreciate that TextEdit is a rich editor. I can use vim or countless other apps for plain text. Few do what TextEdit does with its simplicity.
Aye. According to me. I have a preference for tools doing one thing, and one thing well. That attitude has served me very well. Your opinion is that you like TextEdit for what it is. Neither opinion/feeling is relevant.
You can make security bugs in simple tools - this security bug is not purely a function of the number of target use-cases.
Nor do you have any rational basis for asserting that the given app "should only do one [thing]".
Re: Man who thought opening a TXT file is fine thought wrong
#247Earlier quoted context omitted.
“Everything’s a file!”
perhaps this is the worst possible abstraction to be protected by a security framework.
I honestly don't understand how anyone with at least a basic understanding of how OSes are designed and operated could ever arrive at that conclusion. The layers of wrong assumptions required to support that assertion are in the level of "not even wrong" confusions.
Re: Man who thought opening a TXT file is fine thought wrong
#248Earlier quoted context omitted.
Rigidly interpreting documents depending on their file extension is worse than trying to figure out the type of a document before interpreting it. File extensions are a brittle and primitive system that does not fix any security issue.
File extensions are simple and, crucially, visible and understandable to the user. They're far better than any proposed alternative.
> visible and understandable
False. Something is neither visible nor understandable if it's misleading - which file extensions are. There are absolutely no guarantees that a file extension will match file contents, and that assumption can cause security risks - like in this article.
An actually good alternative is to encode file type as metadata, instead of inside the file contents or file-name, and then configure viewers to display it. That, while not "simple", is also visible and understandable to the user, while simultaneously being safe.
Re: Man who thought opening a TXT file is fine thought wrong
#249Oh, man. The idea that TextEdit automatically parsed .txt files as HTML if they started with a certain file signature is problematic... ...but the fact that file:// schemes can access remote files by appending /net/ followed by a domain name is pretty shocking. I mean, the entire purpose of "file://" would seem to be to provide access to local/mounted files and only those. The fact that a Mac engineer thought it woul…
“Everything’s a file!”
I fail to see how HTTP and REST's "everything is a resource" paradigm is significantly different than UNIX's "everything is a file" paradigm, and I'm yet to see anyone claim that the freedom and power to open any HTML document (OMG a file!) made available through the internet is a mistake or a bad design decision.
Re: Man who thought opening a TXT file is fine thought wrong
#250Oh, man. The idea that TextEdit automatically parsed .txt files as HTML if they started with a certain file signature is problematic... ...but the fact that file:// schemes can access remote files by appending /net/ followed by a domain name is pretty shocking. I mean, the entire purpose of "file://" would seem to be to provide access to local/mounted files and only those. The fact that a Mac engineer thought it woul…
This is the only story here. Everything else sounds like clueless hyperboles.