Oh, 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...
Man who thought opening a TXT file is fine thought wrong
191–200 of 316 posts
Re: Man who thought opening a TXT file is fine thought wrong
#192Two words: excessive complexity. It's always seemed strange that an application called TextEdit is actually more than a text editor. I strongly believe that content-type autodetection, much less HTML rendering(!), most certainly does not belong in a text editor.
TextEdit dates back to NeXTStep, so it was originally written in the late 1980s probably. Guessing it didn't render HTML originally, but it always had RTF capability. Not that it's an excuse in 2021, but very few applications from that era woudl be considered "safe" today.
Re: Man who thought opening a TXT file is fine thought wrong
#193Re: Man who thought opening a TXT file is fine thought wrong
#194Earlier quoted context omitted.
But not with file extensions of .txt. They should only do bells and whistles if the extension warrants some bells. .md, sure syntax highlight me. But opening .txt and treating it as html, that seems strange.
Well, on Unix file extensions are a convention and don't have any strict semantic meaning. Maybe this doesn't make sense in a world where most people do think in terms of file extensions (thanks to the popularity of Windows) but it shouldn't be surprising that non-Windows programs might not special-case file extensions. (Though in fairness, text editors do usually have special casing for file extensions and these day…
Re: Man who thought opening a TXT file is fine thought wrong
#195Earlier quoted context omitted.
“Everything’s a file!”
perhaps this is the worst possible abstraction to be protected by a security framework.
Except we have some grandfathered file types that are implicitly trusted.
Re: Man who thought opening a TXT file is fine thought wrong
#196Earlier quoted context omitted.
perhaps this is the worst possible abstraction to be protected by a security framework.
IMO not so much. Just assume all files are malicious unless accompanied by metadata saying otherwise. That is pretty much the status quo already. Except we have some grandfathered file types that are implicitly trusted.
Re: Man who thought opening a TXT file is fine thought wrong
#197Earlier quoted context omitted.
perhaps this is the worst possible abstraction to be protected by a security framework.
IMO not so much. Just assume all files are malicious unless accompanied by metadata saying otherwise. That is pretty much the status quo already. Except we have some grandfathered file types that are implicitly trusted.
Re: Man who thought opening a TXT file is fine thought wrong
#198Re: Man who thought opening a TXT file is fine thought wrong
#199Oh, 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…
> ...but the fact that file:// schemes can access remote files by appending /net/ followed by a domain name is pretty shocking. Not that shocking. Windows has had that with SMB networking for ages file://SMBSERVERNAME/path/file . 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.
Can’t trust these two or ,,, who can we trust for network security.