Man who thought opening a TXT file is fine thought wrong | Hacker News Reader

Man who thought opening a TXT file is fine thought wrong

paulosyibelo.com

986 pointshyperpape304 comments

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 would be a great "feature" to allow file:// to access the entire internet is... kinda terrifying. Did that get patched, or was it only TextEdit?

I think it carries over from NeXTstep, iirc.

It feels like a choice when "net" meant "my campus network", not "the internet."

Because why would you be connected to the internet all the time? And how could you even afford those long distance calls?

That one East German guy in Cliff Stoll's The Cuckoo's Egg found a creative answer for both of those.

Looking in /etc/auto_master, which is the configuration for Autofs, the /net mount point is commented out by default. I do not know when (or if) it was ever turned on by default.

Whether or not a default configuration is vulnerable is a pretty typical component of accessing a vulnerability’s severity.

Unfortunate that the author didn’t mention this.

Obviously this doesn’t excuse the bug, but it’s important to contextualize if we hope to compare relative impact and have frank discussions.

The default configuration was, in fact, vulnerable at the time. Having it be commented out by default is new.

The vulnerability: https://www.fcvl.net/vulnerabilities/macosx-gatekeeper-bypas...

I'm stilling running Mojave (10.14.x) and it is uncommented. The file dates to 2014 so I suspect it was set up with the original OS that came with this machine.

/net is really meant for things like nfs.

“Everything’s a file!”

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.

In the article, the remote file's contents were not malicious, but merely trying to access it was. That would require a very different security posture to "assume all files are malicious".

> the remote file's contents were not malicious

until ... one day ... they are!

The remote file is only one of two files in the story.

And what about malicious metadata?

I can see a way this would be useful to use the same abstraction to limit app/user web access to a single domain.

For instance the dropbox binary can only access "/home/dropbox" and "/net/dropbox.com" if this was more well-known/used.

This can be done with a proper capability system.

How is that? Per-process namespaces in Plan 9 seem like a good idea for isolation. "Everything is a file," but what is and isn't accessible can be managed on a per-process level.

In POSIX we only generally get a user/group level of granularity which seems to practically mean that only daemons are completely isolated.

Per process won’t be good enough in a different app that does legitimately need `/net`, just not when displaying file:/// links inside HTML pages.

I disagree. Use a second process that has a limited namespace where you've mounted only the local files you want an HTML document to be able to refer to and an IPC socket marked for exclusive use. The first process resolves file links and reads file contents via IPC to the second process.

On the contrary, it's very good design.

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

I don't think "everything is a file" is necessarily bad. What's worse is "every application I run has access to every resource that the OS gives my user access to".

Would be nice if the operating system could set up a fresh, temporary "user" for each application installed, and instead run the application as that user, who starts out with no access to computing resources. Maybe some existing systems already sandbox apps into their own unprivileged users, I don't know, but it would probably be very secure.

Modern operating systems can; there is quite granular control.

But often when such sandboxes are attempted, it turns out that it often became more complex than originally thought, and applications need many resources which were not originally considered, so they are given those resources, and very often those resources can be used again to construct more resources or otherwise to some measure escape the sandbox.

I believe this is how Qubes OS is supposed to operate.

> In Unix everything is a file. Files are files, folders are files, disks are files, your keyboard is a file, your mouth is a file, the air is a file, you can't breathe, your file lungs fill with files and you try to scream but only files come out oh god Dennis how could you do this

-- https://twitter.com/TartanLlama/status/1375045731644538882

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

Several ways. In Unix files are streams of bytes. In HTTP resources are complex entities with MIME types, multiple representations, encodings, etc. HTTP URL structure supports parameters and there is a method for providing data and obtaining a result back, a sort of RPC.

On the other side Unix has users and permissions, HTTP does not and you have to build your own.

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

Actually if I am not mistaken it is after they want to fight the browser war they break the barrier between the file system and internet system. It is not in the early version of windows or IE. the integration is one of the major mistakes Microsoft made. And surprise apple fall for it as well.

Can’t trust these two or ,,, who can we trust for network security.

> 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
  $

For anyone wondering, it is enabled by default on Ubuntu too. I wonder what made someone think that this was a good idea?

If you follow the everything is a file philosophy it seems quite natural does it not?

Except permissions aren't granular enough / are too confusing, it's a giant footgun with the current Linux architecture, which doesn't have all the nice things Plan9 does

I mean, unless you're host is extremely locked down you'll probably also have telnet,netcat, etc installed, so no great difference.

I'm no specialist but I'm inclined to disagree, for me it's the difference between the ability to run an arbitrary binary and the ability to read/write an arbitrary filepath

They are imaginary paths in the bash executable. They aren't usable outside it. Thus the netcat analogy.

Anything you can do in telnet or netcat can also be done in python, perl, ruby. One of those is likely installed, most probably python.

And if you think about if all applications where using files for communication blocking one program from the internet would be as simple as a chmod.

I didn't say that the everything is a file philosophy is necessarily correct and well implemented on Linux. Merely that if you where to continue along this direction it would seem like a logical next step. I don't think I would use this for anything but for shell scripts at best. However especially if you are a plan 9 fanatic then it would seem like quite a good idea which is what the original question was.

Although it was disabled in Debian bash 2.04-5 on 2000-06-05, it was re-enabled in bash 4.0-5 on 2009-09-13 and is currently enabled. See https://metadata.ftp-master.debian.org/changelogs/main/b/bas...

SMB is more understandable though, since you have more trust for things on your local network, and an attacker usually won't have control over those resources. And it's a fairly common and reasonable expectation in a business environment that network drives appear as part of the filesystem.

Whereas a domain name over the open internet is an entirely different story.

Its been a while since i've done windows stuff, but i thought you could use IP addresses in addition to netbios names for smb - \\1.2.3.4\share\file

You can use \\domain.name\share\ as well.

The extension is meaningless outside of Windows...

It doesn't sound like that from the article:

>the default text reader on OSX, TextEdit is used to open files with TXT extension by default.

>Gatekeeper doesn’t quarantine TXT files

File extensions are routinely used by all sorts of software, at least as hints if nothing else. For example, gcc will handle files named .c differently from files named .cpp, and will not even work with static libraries unless they are named .a.

Far from it. Even Mac OS stopped using type and creator codes in favour of file extensions, 11 years ago (with snow leopard).

It's not specific to the file:// URI scheme; /net is an actual filesystem path that works with anything that accesses paths. Or used to work, anyway; it was recently changed to be disabled by default.

holy batman

Most likely nobody decided to have file:// access the network. Most likely, someone decided to make file:// the scheme for accessing files, and someone else decided to mount the network as a file.

My memory is hazy, but I think this was a “feature” of Plan9

> I mean, the entire purpose of "file://" would seem to be to provide access to local/mounted files and only those.

This is the only story here. Everything else sounds like clueless hyperboles.

A file can be accessed locally, on a private network, or over the internet. The fact that /net/ exists is redundant to http file download... so there's an argument there, but to access a local network file through http requires a webserver which may not be desired. So, having file /net/ solves that problem but of course could work the same way on an internet network so... we're kind of screwed really.

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

Agreed. This problem exists because someone wrote a tool that should only do one (really well) and but instead made it do five different things.

That sound in the background is emacs laughing.

You can press ctrl-super-meta-¥ to make it stop.

Underrated.

I don't think it will accept the command if it knows you learned it as anything other than C-S-M-¥.

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.

Neither is the opinion that "This problem exists because someone wrote a tool that should only do one (really well) and but instead made it do five different things."

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

So, keeping the GP rationale, do you see any gain from TextEdit opening txt files?

shoulda used 'cat

Using cat with arbitrary input exposes you to many terminal-side security issues. It is insufficiently complex.

Such as?

Any vulnerability in the escape sequence handling of the terminal emulator, and conceivably, depending on what sequences your terminal supports, access to facilities like local file generation or clipboard contents. There have been a number of issues with escape sequences injected into things people might copy and paste from a web page, or in git commit histories, that have done nefarious things.

Cat has long been known to expose you to code execution, among other things.

https://security.stackexchange.com/questions/56307/can-cat-i...

Alternatively use "cat -v" and any terminal escape characters will be escaped.

It can do some sketchy things and rewrite your terminal in weird confusing ways, but afaik most of the out-and-out malicious escape sequences have been patched out at least a decade ago.

that wouldn't work nicely with the mouse :)

That's what the on-screen keyboard is for. Even works with the touchscreen, no mouse required! Eminently usable.

If you don't want text editors to do non text-editing stuff, then people need to stop saying we should build development environments around text editors. "An IDE is just a text editor with bells and whistles", people say. Well if that's the case, it's not surprising if people "only ship the one text editor".

I don't know anyone who says that an IDE is just a text editor with bells and whistles. Visual Studio Code is a text editor with more bells and/or whistles than a choo-choo train, but that doesn't make it any more of an IDE than nano and termux.

VS code is an IDE by any reasonable measure. Nano is not.

It compiles and debugs, that seems like an IDE to me.

VS Code is cool and all, but it definitely is a lot more manual and laborious than VS. the tooling and automation in VS is missed if you’re used to it.

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.

> But opening.txt and treating it as html, that seems strange.

I’d go as far as to call it negligent, not merely 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 days tools like ls will colour filenames based on the extension.)

This is only a Unix vs Windows thing in terms of the application launcher and how it is implemented. File extensions are semantically meaningful for many unix tools, most notably gcc.

Also meaningless for vastly more UNIX tools. Also, Gnu’s not UNIX.

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.

Edit.app is the original NeXTSTEP text editor from the 1989. It supported plain text and rich text files. Famously, the first web browser was based on the rich text capabilities built into NeXSTEP.

TextEdit.app is the OpenStep rewrite of Edit.app and dates to the mid 1990s. It was likely one of the first OpenStep apps. It supported the same rich text files as the original Edit.app.

Apple bought NeXT, OpenStep became Cocoa, TextEdit was ported to Java, and then back to garbage collected Objective-C, then ARC Objective-C, (then Swift, probably).

Along the way it picked up features for reading/writing/editing HTML and Microsoft Word documents.

Apple used to publish the source code for TextEdit as part of their Xcode sample code, but they stopped a few years ago.

Yeah, I think TextEdit.app is supposed to be a showcase for the Cocoa text system, really.

> TextEdit was ported to Java

Wait, what? Wow, that’s nuts!

Java was supposed to be the primary programming language for OS X. That's why they renamed OpenStep to Cocoa (Java and Cocoa go great together).

But AppKit was still pure Objective-C, and bridging between AppKit's Obj-C APIs and the Java language presented problems. 3rd-party developers (eventually) preferred the write directly in Objective-C and Apple dropped the Java bridge some years later.

> Apple used to publish the source code for TextEdit as part of their Xcode sample code, but they stopped a few years ago.

The URL still works if you want it, but, yeah, it's obviously not up-to-date:

https://developer.apple.com/library/archive/samplecode/TextE...

> (then Swift, probably).

Not yet at least; there's no Swift symbols in the binary on Big Sur.

An example of "unsafe defaults:"

NeXT used Display PostScript for the display manager. If you opened an email that had PostScript commands, the mail agent would happily, automatically, execute them.

A favorite payload sent around the computer lab would smear all pixels downward to "melt" whatever was rendered on your display.

Note that there weren't that many interesting things to exfiltrate back then, so this wasn't a terrible default: there wasn't (any!) online commerce, online banking was rare, and even passwords were never echoed to the terminal.

You don't need a password to be echoed to exfiltrate it. You just need the key codes. Not sure about NeXTStep, but regular old X let you sniff keys really easily.

Some systems (specifically, earlier versions of SGI IRIX) shipped with X authorization disabled by default. This is the equivalent of "xhost +". You could sniff a box as soon as it was plugged into the network, including capturing login session credentials, all terminal commands, and anything else. When they su'd to root, yes, you'd capture the root password.

In those days (mid 90's) almost nobody was running firewalls. At least, nobody in these parts. Putting your "office on the Internet" meant raw, unfiltered IP.

These days too, IPv6 tends to be firewall-free. In theory there are protections though, like regularly changing suffixes.

Do MacOS and Ubuntu ship with firewalls?

Most consumer routers should at least be doing basic inbound connection filtering for IPv6. Are they not?

MacOS and Ubuntu ship with firewalls, though not sure if they're enabled by default.

I checked one big ISP, boasting 99% IPv6 coverage, and the IPv6 firewall is opt-in, and considering how many people change their settings...

(For those that might not be aware of it : with IPv6, there's no NAT, since there's no need for it.)

This was fixed in 2020 so no need for any excuses in 2021.

Text ≠ Plain Text. TextEdit defaults to rtf. It supports html as an alternative to rtf, which is to say it can do basic formatting and nothing else.

It's perfectly reasonable to expect a text editor to support more than literal unicode, and to work with a variety of commonly-used formats.

It seems people are hunk TextEdit is the macOS equivalent of Notepad.exe while instead it’s more like WordPad

But is it reasonable to treat a .txt as anything other than plain text?

No, it’s definitely not, that’s a separate problem!

You should read the article before commenting.

The blog post states that the contents of said "text file" were quite literally <!DOCTYPE HTML><html><head></head><body>

This is not a mere text file. At all. This is a HTML document that might be deemed valid by a very permissive validator.

Just because HTML might be stored in a text file that does not mean that a noncompliant HTML file ceases to be a HTML file.

I read the article. I understand that. But what takes precedence, the first line or the extension.

If the file extension is .txt, I always expect it to be opened as plain text. The file extension is, rightly or wrongly[0], the metadata declaring the file type — nobody would consider it reasonable for an .exe to remain executable if the extension is changed to .txt, after all.

One might, possibly, still argue about the text encoding of a .txt file (I’m old enough to remember Unicode being a new fancy alternative to ASCII), but that’s about it.

[0] Sometimes I reminisce about the good old days of classic Mac OS, with resource forks and separate file type metadata: https://en.wikipedia.org/wiki/Resource_fork

> If the file extension is .txt, I always expect it to be opened as plain text. The file extension is, rightly or wrongly[0], the metadata declaring the file type — nobody would consider it reasonable for an .exe to remain executable if the extension is changed to .txt, after all.

That statement is quite wrong and shows a good dose of ignorance. To start off in UNIX systems the extension means nothing regarding whether a file is an executable or not. All it takes is a +x flag and a file format (header, magic number) that can be executed.

Also, file extensions mean nothing. In fact, a popular and very basic trick to fool clueless users to run malware (and one which any anti-malware tool checks) is to sneak executables with a different extension, because it only means something to clueless users.

And a file with a txt file extensions means nothing at all. The only thing that matters is the file content and it's file permissions.

It's a rich text editor by default. Rich text is still text.

Opening HTML files and converting them to rich text certainly does belong as a valid feature for a rich text editor. It'll open and convert Word files too, which is super useful.

The content-type autodetection, however, I agree was a bad idea. Still, this vulnerability presumably existed with an .html file opened in TextEdit.

I assume the content-type autodetection exists because of how downloading files occasionally appends a .txt extension (I think this is when the content type is text/plain). Postel’s law gets applied with the result of macOS attempting to make up for misconfigured servers.

>Still, this vulnerability presumably existed with an .html file opened in TextEdit.

It wouldn't have been as bad though. From the article:

>Gatekeeper doesn’t quarantine TXT files

I think this captures my sentiment on the matter as well. Applications today want to be a swiss army knife and do just about every job.. and do it poorly. I do expect that level of complexity from RStudio, but probably not from Notepad. I would probably kinda accept it in Notepad++.

So real question. Is TextEdit a default text editor in a mac?

TextEdit is closer to WordPad than Notepad in terms of functionality. It supports rich text edition, and is more than a plain text editor.

It seems like the only real issue here is that a file:// URL can make a network request. Who could ever think that that would be a good idea?

People who were building next-generation networked computers in the late 1980s and 1990s?

> a file:// URL can make a network request. Who could ever think that that would be a good idea?

Anyone with networked filesystems, I should imagine?

>>Anyone with networked filesystems, I should imagine?

You're either missing the point made by GP or being disingenuous. Please keep in mind that you need to explicitly mount a NFS before you're able to open it, and mounting a NFS not only requires explicit authorization but also only provides access to a specific file system mounted in a specific point following specific permissions.

Accessing the whole internet through file:// without being prompted for permissions or consent or even awareness is an entirely different thing. For starters, the access is not explicit nor subjected to conditions.

No, the fact that .TXT files got interpreted as HTML is worse.

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.

Optimizing for "simple" for the sake of robustness is exactly backward.

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

> There are absolutely no guarantees that a file extension will match file contents, and that assumption can cause security risks

Only in software that ignores the extension.

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

Metadata can be just as wrong as a file extension, and is generally far less visible.

> Only in software that ignores the extension

No, only in software that blindly follows file extensions.

The problem is that the text editor ignored the extension of the txt file. That's what lead to unsafe behaviour - the user thought the file was fine to open because the extension was txt, and improving users is not practical.

The exact same thing would happen with metadata - indeed file extensions are just a form of metadata - if the metadata says this is a text file but the application ignores it, we would have the exact same issue.

They are also trivial to get wrong, can be mangled when the files are moved around, and are easy to use as an attack vector.

They are not far better than the alternatives, it's just that no alternative reached a critical mass due to them not being how Windows works.

> They are also trivial to get wrong, can be mangled when the files are moved around, and are easy to use as an attack vector.

On the contrary, they're the only kind of metadata that doesn't get mangled when files are moved around, and they're far less of an attack vector than other approaches. Of course you can set the wrong file type, but no approach avoids that problem.

I disagree, especially in the context of email attachments or web uploads. It isn't rocket science.

The problems occur when a file, that is said to be of a certain filetype, is erronously treated as something else.

Here's an interesting quirk in Windows: There are two APIs to execute external programs, CreateProcess and ShellExecute. CreateProcess is the older of the two and only runs executables. ShellExecute opens the target with whatever app is associated with the extension.

When they shoehorned the ShellExecute behavior into cmd.exe, they basically just said "if (!CreateProcess(foo)) {ShellExecute (foo)}"

As a result, if you take "foo.exe" and rename it "foo.txt" then try to run it like "C:\>foo.txt" from the command line, it will run as an executable instead of opening in Notepad like you would expect. Do the same with a real text file (that doesn't start with "MZ") and it opens in Notepad.

This is a frustrating behavior on Windows, not because it's possible, but because it's default. I vastly prefer the way KDE performs. Whatever the default program to open that file type is attempts to open it. You can easily change what the default is.

It's frustrating when I instinctively change a file extension on Windows so I can do some other operation with it (say changing a configuration file to .txt to edit it) and Windows still doesn't know what to do with it.

I'm not averse to the behavior, I just wish I could control when it happens.

Being pedantic, CreateProcess is more fundamental but ShellExecute, dating back to 16-bit Windows, is older.

Yesterday grep didn't work because it 'autodetected' that the target file was a binary.. So I 1) cursed whoever made this non backward compatible change 2) used man to find the '-a' option..

Hah, looks like I’ve been needlessly typing quite a few extra keystrokes, as I’ve always done —binary-files=text. I should have looked at the man page more closely..

File 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 rename the file "grandkids.mp4" and double-clicking it would still open it in the image viewer.

Not really outside. The metadata was stored in a so-called "resource fork", with the file contents proper in a "data fork", both of which belonged to the file per se. Part of the resource fork was the "creator code", four bytes identifying the application which had created or could open the file, and the "type code", four more bytes defining which, among the potentially many kinds of files a given application could open, this file actually was. Binaries were stored in the same format, with IIRC an extra bit somewhere flagging them as executable.

Classic Palm OS used an identical scheme, and for both platforms there was a freeware "ResEdit" application you could find to let you edit resource forks without paying for a real developer toolkit.

Yes, and it sounded great on paper but was horrible for interoperability because a file was not self contained from the POV of filesystems that didn't support the resource fork. Every file you wanted to distribute cross platform needed 2 versions. One with all that metadata bundled up for Mac, one without it for everything else. It was a nightmare

OS-X dropped it for good reason.

Yeah, it was painfully overcomplicated for sure - Palm OS did it much more seamlessly for cross-filesystem interop, but it was only when SD cards and /Palm/Launcher came along and you didn't really need Hotsync any more that it really got comfortable. It was very much of its time and I don't regret that it's gone, but it was certainly a clever and interesting design.

>but was horrible for interoperability

This makes me sad - it was dropped because of problems with other operating systems, not because it was necessarily a bad architecture.

I understand why they would do it, but it makes you wonder how much better our systems could be if it weren't for concerns about legacy.

> This makes me sad - it was dropped because of problems with other operating systems, not because it was necessarily a bad architecture.

No, it was dropped because it was designed without enough forethought given to how that metadata would be transmitted over the wire or when multiple files were bundled consistently. Even if every OS used this scheme a better solution to these problems would have to have been devised.

Are extensions perfect? No, they suck. But yet solve this metadata transfer problem "good enough" and therefore won the war.

PS - There was also a lack of user management tools/feedback on a lot of systems, for example changing the "file type" was often impossible out of the box, and the file types often unclear unless you went into details/properties on purpose (a potential security headache, up there with hidden extensions ala Windows).

Microsoft removed the file type manager in Vista(?), so it's no longer as simple to change what software opens arbitrary file extensions. You now need to have a file with the extension you want to change the default for, use 'open with', and check the 'use by default' button. If you want to change a bunch of file types by copy/ pasting exe path, sorry, you can't do that without editing the registry. And the new method of changing programs that open groups of file types (ie documents or html), the program you're running needs to be registered as something that can do so, or it won't appear in the list. Want to change all image formats except gif (jpg, png, tiff, bmp, wmf, emf, and so on) to a different image viewer? Your options are to change them all then change gif back, or to change them individually.

I think there's a location in the new settings for listing all file type associations, but it still doesn't allow copy/pasting paths for multiple fast modifications. If you want to change the name of a file type as it appears in the file type column in explorer, or want to change the icon used for a type of file to something other than that of the application used to open it, that's no longer possible without editing the registry.

>I understand why they would do it, but it makes you wonder how much better our systems could be if it weren't for concerns about legacy.

Concern for legacy is the only thing keeping the field of computing sane these days. If every operating system worked with radically different standards for basic things like filesystems, a significant amount of bespoke work would need to go into each build of every piece of software, and we could very quickly encounter a monopoly scenario where only the rich could afford to develop apps for everyone. All of this is not to say that there aren't already systems doing this: Haiku and Plan-9 are about as esoteric and non-conformant as they get, and their reward for that is a minuscule but dedicated userbase. If Apple wants to make the computer a better experience for the end user, then they're going to have to play ball.

They still kind of do : WSL is kind of useless because of incompatible file systems between Windows and Linux...

I’ve not had any issues opening a file from WSL in my IDE, which is running from Windows.

Oh, right, IIRC WSL 2.0 uses a complete different method?

yeah, I think it creates a file share that you can access.

I was in my tweens/early teens when I learned about ResEdit. I thought it was some kind of hacker tool, and I was amused at the various things I could change.

I used to add menu items (that didn’t do anything), I was able to change picture/icon resources inside apps, all kinds of fun stuff. Change command mapping, etc

Changing app icons was the big thing for me. I learned about that as a tiny child at computer camp, and I thought the high school kid who introduced me to it must be just about the coolest guy in the world.

The file type and creator type are stored in the Finder Info meta data which is in the file record (along with the creation date, file size, etc).

Type and creator codes were stored in the desktop file IIRC, not in the resource fork.

i always found that a bit funny to see the 'typing' hygiene vary between OSes just like between programming languages. Windows let you cast anything, MacOS.W had the application being the sole type constructor in a way. Very functional.

On the contrary, it's a simple and explicit (when not stupidly hidden...) way of denoting the file type, which is great for interoperability and information interchange.

Proprietary, opaque mechanisms like resource forks only serve to keep users uninformed (and thus unlearning) and impede the free interchange of information between different applications.

But it's not a file type, it's a file extension that sometimes can be matched to a content type.

Same thing, really. If you have the type information stored somewhere else, it can also be wrong.

I do remember resource forks, but I thought content-detection was also a generally accepted pattern on 90s-era Macs because of the lack of file extensions?

(If you had a safe content-detection code-path -- admittedly a harder thing to guarantee these days -- that could certainly be safer than relying on users to not "open grandkids.bmp.exe" or "rename a downloaded.txt to autoexec.bat".)

I don't actually think file extensions are such a bad system.

Filenames exist to provide context for the data inside. "Draft 2020 Quarterly Report.txt" and "Draft 2020 Quarterly Report.csv" could contain the exact same data, but the file extension indicates how the file is intended to be used, just as "2020" indicates the relevant year and "Draft" indicates completeness.

The cool thing about the Classic MacOS file type/creator system is that you what app opened a file was not dependent solely on the file type, but also on the app that created it.

So if you downloaded a GIF file of a cute cat, it would open in your image viewer, but if you were working on drawing your own GIF image, it would open up in your image editor.

But we have file timestamps, permissions and other attributes. There could easily be a "file type" field too, that seems more natural than shoving this metadata into the title.

As I see it, a timestamp is "non-negotiable". The file was last modified on April 22, 2001. There's no difference of opinion, the time is what it is.

But the file extension partially reflects a user's intentions. A stylesheet named "style.css" is intended to be used by a browser directly, whereas one named "style.scss" is expected to go through a preprocessor, but the two might have the exact same contents, and I might decide to just change one to the other, and that's okay.

I take your point about permissions, which are expected to be set by the user. Of course, I actually run into problems caused by incorrect permissions all the time. Maybe it would be better to encode those in the file name! (Although I don't know how you'd do it without creating a mess, and potentially security issues.)

But you could just name one of the files `Draft 2020 Quarterly Report CSV`. That's a terrible reason to use file extensions.

It would be kind of neat if changing the extension of a file caused it to be converted automatically. It would save a bunch of typing and browsing around. Just rename a directory to foo.tar.gz and it gets compressed and tarred. I'm not saying that the kernel should be doing that, but it feels like a nice abstraction for some UI.

But why tar it in the first place? If you want to share a directory, the system can tar it for you behind the scenes. Also, the system can zip anything behind the scenes, without the user knowing.

I guess it would make sense if you want to archive it and save some disk space. It also not always clear to the system that you are sharing a directory, if you drop it on a network drive, for instance. But yes, I think zipping a directory is not the most compelling use case.

Amazing idea !

This is one of those ideas that seems nice in theory but in practice would just lead to so many subtle problems especially if it happened automatically.

Lots of programs create temporary files by changing the extension temporarily but if the kernel were attempting to intercept and change the internal data you could never guarantee the state of your file data. Not to mention potentially renaming an extension to an automatically handled extension and having that data irrevocably altered without you even realizing it.

Then of course there's the fact that there are usually lots of options associated with converting a file. Jpg needs visual compression levels, mp3 needs bitrates, etc.

In the age of the internet, file extensions are a good idea, they should be visible by default, and people need to learn to recognize them. There's a lot of malware that gets people to run it by being an executable with an icon of an innocent file type, like an image. If you don't see extensions, you have no idea it's an .exe instead of a .jpg.

They’re also dangerous too! I remember seeing malware as an attachment to an email with the file name “somefile.exe.bmp”, which looks safe, but when saved on Windows, it saved it to disk as “somefile.bmp.exe” because there was some Hebrew character that flipped the last two extensions around!

Meta comment: The custom scroll behaviour on that site is awful. I hate sites that try to "improve" the behaviour of scrolling by making it faster/slower than normal.

Amen...

Yeah, it's ironic in a way. TXT files should open as TXTs and scroll should scroll naturally and not be tampered with.

Love this comment

I've been racking my brain trying to figure out just what "benefit" is had by this type of scroll-jacking but to no avail. It does seem to help in any way and all it does is frustrate the user.

Luckily the spacebar behaviour remains untouched, but you shouldn't have to experiment with each and every snowflake webpage just to have the default actions act as you would expect.

It's not the author's fault necessarily. Well, they _did_ choose the template and decided to keep it. But the template comes from a company who targets WP templates towards Female Entrepreneurs, most likely in a bid to win some slice of Google's keyword share with "Feminine Blogger Templates". Not sure what my point is, except that maybe they are incredibly out of touch with a lot of things these days. And I'll it there. This is turning into an unintended stream-of-though rant. Sorry!

Imagine if a site made the user downpress on a link for a longer time before the click would register?

It's actually insane.

The spreading plague of JavaScript has resulted on plenty of situations of middle click on a link not correctly opening it in a new tab.

Yeah. I had to disable JS to make it bearable.

It gets even worse if you try to "pinch and zoom" on a mac.

Totally agree. Appears to be using a script called "SmoothScroll".

Ublock origin blocks it evidently.

> I will not leave a PoC for this chapter but I promise you, it will not be that difficult to figure out after reading the above two parts

I find this kind of annoying. Either write about the vulnerability or don't.

So... First vulnerability is that you can force someone to hit

2nd vulnerability is that you can print a password file (or other file) inside the text editor

A dangling markup attack is an attack that sends you information as part of the url request up to the next quote

So you could do this and someone has sent you the contents of the password file when trying to get css

Which is very interesting in and of itself as that's not how dangaling markup attacks usually work (normally it would send the unparsed html, not the result of parsing the html). Not to mention wtf the non-standard <iframedoc> tag is and how it differs from an iframe.

But my broader point was less the how, and more that the style of writing was obnoxious.

The link provided in the article to HTTPLeaks required some sort of login for me. Here is the direct link:

* https://github.com/cure53/HTTPLeaks

There are a lot of ways HTML can leak information. HTTPLeaks is an attempt to create a test for all such leaks. Unfortunately, people keep inventing new ways for HTML interpretation to leak data. The article describes a particularly clever approach accidentally implemented by Apple.

I don't know what people expect - don't run code you don't trust. There is also lots of ways for python to leak data if you execute a malicious python script.

It's not about running code, it's about opening a TXT file with the operating system default handler for TXT files.

So you what you are saying is basically 'do not open any files or websites you don't trust' - which is usually not what people expect as that would basically mean 'don't use your computer'

More specificly im saying, the web is designed around making network requests. If your threat model is not to make network requests, you shouldn't try and sanitize html vis blacklists because you'll be in for a bad tine (responding to the grandparent's list of html leaks not the article. I agree that its unreasonable that the txt file does anything. The mistake is in the apple devs trying to sanitize html which is doomed to failure)

The bug is fixed now, as the articles notes at the end. I cannot reproduce this at all now. When I put HTML in an actual .txt file, TextEdit opened it showing the markup, not the rendered content. This is regardless of whether in Preferences, I check or uncheck "Display HTML files as HTML code instead of formatted text" checkbox.

He says it was patched in 2020.

But the log viewer shows March 31 2021?

ran on an unpatched machine

Virtual Machine?

It would only leak your real IP if you were using a proxy through your browser, right? If you were using a VPN it would give the VPN server's IP address?

edit: comment hidden, probably due to new account. Leaving it up just for reference

Why is TextEdit accessing the Internet without permission? Does Big Sur's Access Control block stuff like this?

From the OP it sounds like there is a very weird feature/component in MacOS called "AutoMount" and/or "AutoFS" that lets HTTP GET network requests be made via reading file system locations... and it may somehow escape other access controls?

I too am curious for more details about this. Where did this feature come from, how has it been used, has it actually been used?

Is AutoMount/AutoFS still there after this CVE patch? Does it indeed circumvent Access Control or other such things? Is it a likely path for other security problems?

I don't think this is doing any HTTP. Autofs is generally used to mount remote file systems like NFS shares.

It's pretty common on Unix-like systems (especially in multi-user environments) and not at all specific to macOS.

References:

https://wiki.archlinux.org/index.php/autofs

https://www.freebsd.org/cgi/man.cgi?query=autofs&sektion=5

https://access.redhat.com/documentation/en-us/red_hat_enterp...

The only thing I know about this is what I learned from the OP reporting the vulnerability. Maybe I was mistaken the request was HTTP? Anyway, rest applies, assuming the article is correct in describing the nature of the vulnerability.

Anyway, if this is how TextEdit got around macos access controls related to network activity, I wonder if this is a route for other apps, including malicious ones, to get around it too?

> After digging into OSX internals, I came across the AutoMount feature that lets file:/// urls make remote requests. AutoFS is a program on OSX that uses the kernel to make a mounting request to a drive. Automount can also make remote requests to an external drive. Doing 'ls /net/EXAMPLE.com' forces OSX send a remote request to EXAMPLE.com

> While they did a good job blocking TextEdit from making external requests, this was the one thing they forgot when they allowed file:/// scheme, on OSX file:///net/11.22.33.44/a.css connects to 11.22.33.44.

It’s not that weird, but probably less widely used now; it’s wrapped up with NFS - SunOS had this starting back in the eighties and it’s really handy. You can also do much the same including HTTP access with UNC on Windows.

Both will follow normal network file access controls in their respective environments.

As for the why? It’s a really easy way of sharing resources between computers, and also way more efficient and easier to manage than static mounts.

Well, /net is entirely disabled by default as of recently, so this entire method is no longer applicable.

However, since you asked, here is some useless information:

With /net or remote filesystems in general (NFS and SMB), the network accesses are performed by the kernel directly, rather than by the application using networking syscalls. Therefore, sandboxing network access from specific applications won't affect it.

Big Sur doesn't actually have a permission dialog for network access. But TextEdit does use the (long-existing) App Sandbox system, which is based on applications statically declaring permissions they need. Since TextEdit doesn't request a networking entitlement, it's prohibited from accessing the network directly; as I said, that doesn't include remote filesystems.

This is why I use vallum.

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

Or even something like this:

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

MacOS, too? That's a classic Microsoft kind of bug. At one point in the Windows XP era, Windows would execute anything that came anywhere near a desktop machine - USB sticks, CDs, web sites with install files... "Ease of use", right? They gradually tightened up.

> On the interface of TextEdit, it looked like you can do basic customization to your text (you can turn text bold, italic, change color etc...),

I hate this about TextEdit. Is there a way to turn auto-formatting off? If I paste text, I want it to be stripped of any imported formatting.

Edit > Paste And Match Style

when you open textedit you can change the mode to plain text with menu>format>make plain text.

Small typo - it is Tavis Ormandy, not Ormary

> we have previously seen memory corruption bugs leading to RCE by Tavis Ormary in Microsoft Notepad

> reading files with infinite data streams like /dev/urandom, /dev/zero. a 2kb text file can crash your mac.

Wouldn't this just beach ball TextEdit, which you could force quit and carry on?

Fascinating, I've always been annoyed when Textedit would open a .txt file and treat it as rtf/html. In retrospect that's a pretty obvious attack vector :/

For attachment handling there's really a need for a service that takes the file in light of the uploaded suffix and mime type, and normalizes or rejects it (in a sandbox) based on how safe for consumption it is for common apps that handle that kind of file. For normalization eg GhostScript can convert PDFs to PDF/A that contain no scripts, images can be recoded, etc. Open source project idea? Or is there something this lie this already?

The scroll event processing on the blog is super annoying. With all the js-errors I'm pretty sure we are all guinea pigs for op's hacking efforts lol

> I found another browser trick that lets force-downloaded TXT files to be opened without user interaction or warning

I wish there was more elaboration on this. Opening a downloaded file without user interaction sounds pretty bad.

That is Safari's default behaviour for ZIP files. Only to extract them, though.

Still a terrible idea, though.

So whenever the program used for extracting ZIPs has a vulnerability any website could force-download a malicious ZIP and it would automatically be extracted and trigger the vulnerability...

Why is "force-download" even a thing? IMO the browser should always ask before downloading any file. Though this is not a unique Mac thing, I believe Chrome does that everywhere.

What happens with 42.zip and other zip bombs? https://www.bamsoftware.com/hacks/zipbomb/

> It seems TextEdit for some reason thought it should parse the HTML even while the file format was TXT. So we can inject a bunch of limited HTML into a text file, now what?

Well, what's a file type unless you know it from context, for example a special file system attribute that set to "text/html"? Heuristics. At the very least I think it's better to ignore file "extensions" completely when dealing with the data inside than to make it the deciding factor.

libmagic, which powers a lot of file(1)'s work, is called libmagic for several reasons.

Has Apple paid the author yet? Or is this yet another free bug bounty?

I think most of the outside contributions to Apple and their ecosystem are unpaid so wouldn't surprise me if this is the same.

> This vulnerability was reported to Apple in Dec 2019, and it got patched somewhere in 2020. I don’t know why a CVE-2019 ID is given.

FYI: The year part of a CVE ID is either when the ID was assigned or when the issue was publicised: https://cve.mitre.org/about/faqs.html#year_portion_of_cve_id

Not (as I had assumed) when the vulnerable software was first published.

Heh, the observation from the "zones of thought" universe comes to mind: If you want to be safe, don't even try to sneak a peek!

Just post the POC for a 2019 bug...

Hmm, I can't replicate this on my Mac running 10.9.

    printf '<!DOCTYPE HTML><html><head></head><body>' > test.txt

Opening test.txt shows the exact code I printed. Am I missing something?

He said it was patched in 2020

And 10.9 was last updated in 2016. :)

the preferences allow you to set wether html is parsed or displayed as is. Perhaps it's due to that ?

Yep, was was it. I forgot I set that.

Some odd things are going on here though. The file is listed as “locked” when I open it, and if as TextEdit to unlock it, it fixes the file extension.

It reminds me of thinking that invoking the cat command is benign: https://seclists.org/bugtraq/1999/Sep/432

There's nothing sacred about .txt files. It's a DOS/Windows thing.

To this day osx still doesn't ship with a true plaintext gui editor.

applescript editor?

Not true, TextEdit is exactly this, it’s just not the default. One checkbox in preferences activates plaintext mode for all new files.

haha, after using OS X since the beginning, i have never even looked for this. after the first time of realizing it was rich text like WordPad and not a text editor Notepad, I never even attempted to use it for anything text related. better app options were available for pure text anyways. BBEdit was my gold standard in the way back days.

Probably a quirk of english that I don't see as a native speaker, but I'd phrase this as a gui plaintext editor.

Also, people not served by textedit are pretty niche.

I think both sound equally valid. One sort of expands to "a GUI editor for plain text" in my mind and the other is more like "a plain text editor with a GUI."

"plaintext gui editor" sounds like you are editing GUIs... in plaintext? Maybe a plaintext markup language for GUI's... I guess that's what HTML is!

It also doesn't ship with a paint program. OSx has a lot of ground to cover before it can function as a decent desktop OS.

oh come on, how much more do you need than a crayon based color picker? ever set the date of your system to waaay into the future and then look at the crayon color picker? after providing that, what else could you possibly need?

What does that do?

just like a box of crayons. when they are new, all of the lables are crisp and clean, and the edges of the crayons are square/flat. after using the crayons, the tips become rounded, and you have to peel the labels back as the crayon wears down.

so does the crayon color picker. at least it did in older versions of the OS. haven't looked at it in a reallly long time, as it was def a gimmick more than function

preview's basic annotation functions cover most of what paint can do, or am i missing something?

Preview annotations don't begin to scratch the surface of what paint can do. Look what some people can do in MS paint: https://www.techeblog.com/amazing-spider-man-ms-paint-drawin...

Most of us can't, but paint has all the tools, which is very helpful in many situations.

It's IMHO either too simple or too complicated. On Windows I prefer either ShareX or Paint.Net

It can sort of hackily fill some extremely extremely basic functions (I know cause I do it too), but even that is pretty hacky, like how do you create a new blank document 800px by 600px to start painting on?

You can’t really start with a blank canvas and fill it in. You can only edit an existing image. (Yes, if you can create an all white JPEG you’ve more or less reinvented paint.)

I too have been annoyed to not have a simple bundled paint program (I remmeber MacPaint!), but bundled application software is not really what determines whether an OS is a decent desktop OS.

It's not the only factor, but definitely one of the most important ones.

I actually strongly disagree. Bundled applications which I don’t use and/or will replace with more powerful third party options just add clutter. There’s a balance to be sure, but I generally think OS’s bundle too many apps!

Why would the quality of an OS be determined by what apps come bundled with it? An OS is a different thing than applications, it's what the applications run on. I think you have an unusual viewpoint.

Because people generally want their computer to be usable when they buy it. Imagine if OSes did not include a text editor, browser, file explorer, settings app, wifi connection tool, etc. MS paint is similarly a very basic part of the standard toolset.

I know it's not the same AT ALL, but there are drawing controls in Notes.app

One of the big reasons I switched in 2007 was the absence of absolute dreck like Paint.exe on a Mac. Instead, Apple focused on providing other types of apps for free, and now macOS comes with a full office suite and a prosumer sound editing program as things Windows doesn't have on first launch. Out of the box, macOS offers so much stuff today it's kind of incredible.

You want to draw? Use Notes, which has very little but enough to draw a quick idea you just had.

> absolute dreck like Paint.exe

mspaint.exe is as close to a perfect software as I have ever seen. I'm curious to know which program you think is better, because I'm sure very few exist.

Oh, what do you know, Apple is using the same shitty playbook that Microsoft used and outgrew off from 90's. Remember when opening and interpreting everything by default was the source of all kind of malware because Microsoft thought usability/convenience must trump security? I remember. Nowadays they toned that down: - no more macros enabled by default, no more default autoplay, no more automatically opening mail attachments in Outlook, and definitely Notepad doesn't interpret HTML tags within anything you threw at, including .html files.

https://cve.report/CVE-2019-8761

Well written. Thank you.

To the author: This website seems to use something called SmoothScroll (edit: a javascript library) which makes my scrolling really really jumpy/janky. I'm using chrome on a MacBook with the touchpad. Made it basically impossible to scroll around the page which in turn made it very difficult for me to read the article.

Was about to post the same. This might be the most frustrating scrolling I've ever encountered.

Messing with native scrolling as a web antipattern is right up there with interfering with copy and paste. I will never understand why people do these things.

I don't really understand why browsers allow it!

the browsers cannot control a dev that uses AJAX to continually redraw the page without causing the browser to update the history/location. typically a sign of a) a dev new to AJAX or b) a solo dev that created a PoC that got turned into a product with very little thought about things like history/state/etc. I myself am an option B person.

Thanks; I definitely don’t and can’t claim to understand the “front end” at this point. Your comment was enlightening.

Breaking the back button is the ultimate sin in my book. This comes close.

My first web development job was for a Rails consultancy, where the owner of which explicitly stated that our apps were not designed to support using the back button. On another occasion, this same person responded to user reports of page zooming breaking the site with a counter of "then don't zoom the page".

These moments were two of the first wherein I strongly reconsidered whether I had made the right career choices.

Looks fine to me... maybe because I block javascript

Well, yes, of course.

so you know what to do now...

No, I (and most people) have no interest in disabling JS. Not a practical solution.

Huh, I didn’t experience this problem. The problem appears to be unique to Chrome. It doesn't show up in Firefox or Safari.

That's really rare! Someone take a photo!

It's not really rare. Chrome tends to be a bit more "adventurous" and experimental, while Safari and Firefox are a bit more conservative. So it's not uncommon to see a few weird issues show up in Chrome.

I'm using Chrome and Windows10 but also got unpleasant behavior. I can't quite tell whats going on for multiple pushes of the scroll wheel but one 'tick' would push the page a set amount, and then a moment later the movement was repeated (but without the prompting input). Adds up to kind of a 'gross' overall feeling when scrolling. EDIT: when scrolling with the arrow keys it looks like theres an attempt at 'smoothing' but it really feels more like inertia and damping and is pretty unpleasant.

That this behavior is called "SmoothScroll" is what pushes it over the boundary for me firmly into self-satire (and so I am in stitches playing from laughing so hard at your great description and then experiencing the actual behavior); who writes these scripts, and why? :(

Not seeing this on Firefox + Linux

Firefox under Linux works fine for me too. I was able to reproduce in Chrome and Edge (Preview).

windows 10 chrome. Gets real jank whenever I stop scrolling. Not pleasant.

Also to the author: This is most likely costing you readers.

Just weighing the pros and cons here:

Pro: People who don't have smooth scrolling mouses will suddenly enjoy smooth scrolling on this website. Even this is a questionable "pro". Most people have scrolling setup how they want it and don't need it fixed on a per-website basis.

Con: Degradating a core function of the computer (scrolling) for people who already have smooth scrolling.

So to summarize: The plugin is not helping anyone read the blog, but it is preventing/annoying many people from reading it.

It says something when the top comment isn't about the content of the article but about how bad someone broke people's browsing experience.

Yeah, it says you're on the Orange Site.

Something on the site triggered mcafee on my laptop.

your bigger problem is likely that you're using mcafee

No choice, corporate laptop.

I consider messing with scroll to be one of the cardinal sins of web development.

Basically every single big site screws this up when lazy loading content - Twitter, YouTube, etc. If I drag down the scrollbar to position content where I want it on the page, invariably content gets loaded and pushed to the page. Because I am fixing the scrollbar by holding down the mouse button, the page jumps to a new position.

It is infuriating because this is solveable in many ways, the simplest being not to push during a mouseDown event.

But my new most hated thing is Google lazy showing details when I mouse over a result. Which means if I quickly go to click on the second link I mouse past the first link and it expands to the space where the second link was, so I either click the wrong link or have to reorient and then click the second link. I can't imagine how or why that feature exists.

Seems like the JS library needs to be rebranded, as the name clearly does not describe the result of using it

Works fine on Firefox for me. On the other hand, the text is in a small and thin font, light gray on a white background making it unreadable on my screen. Reader mode to the rescue, once again.

"Please don't complain about website formatting, back-button breakage, and similar annoyances. They're too common to be interesting. Exception: when the author is present. Then friendly feedback might be helpful."

https://news.ycombinator.com/newsguidelines.html

(Note: I'm not saying such things aren't annoying—it's the opposite—which is why we need a site guideline to prevent discussions from being dominated by them.)

I wonder if there is an Apple's backdoor to read users' text files when they open it and send saucier things to them. We will probably never know as this could be collated with other stuff and sent with metrics.

How i am not surprised? And people still insist on lax field/input/request validation, without ever knowing where this input will ultimately end up.

Sure, you know this is a simple txt file, so anything can come into it, right? There is no such thing as malicious txt file.

How to immediately stop me from reading your article? Embed code that harassess me to "Pin it."

Small thing I do first when a new Windows has been installed: make the file association of .VBS and .JS files open with Notepad instead of wscript.exe[0]

Mitigates `iloveyou`[1] virus type attacks on my system

[0] https://en.wikipedia.org/wiki/Windows_Script_Host

[1] https://en.wikipedia.org/wiki/ILOVEYOU

That headline is needlessly dramatic. It’s like the tag line for a movie poster for some cyber thriller.

I disagree. Many of Apple's user-base believes that the platform is immune from viruses and malware. It's important to get the message out that it's no better (and may be worse) than other popular platforms. Especially since Apple claims their platform is "secure by design."

I don't think it can be worse than Windows. Not immune, but definitely not worse.

Depends on how you want to set the goalposts.

By version, MacOSX is faring worse.

By total history despite a good chunk of old Windows malware not being net capable or able to run in current modes... perhaps.

https://www.vox.com/recode/2020/2/12/21134681/mac-pc-virus-m...

Safety by virtue of running MacOSX isn't enough anymore. Not that I'd argue it ever was totally safe/enough in the first place.

Bad habits are what subject one to attacks more than anything else... and that's basically what Apple cultivated in their users through ignorance of threat mechanisms.

>Bad habits are what subject one to attacks more than anything else... and that's basically what Apple cultivated in their users through ignorance of threat mechanisms.

This. 100 times this. The end user is the weakest link in your security chain, and the way Apple implements abstraction in MacOS makes it really difficult for the end user to understand what exactly they're doing, and what effect it has on their overall security.

Most of the safety has always been in being a minority platform, and consequently I don't think the threat level has really changed all that much over the past ten years. Apple are really hitting the gas right now with their SIP work and the immutable OS volume and such.

Windows has a good handful of security vulnerabilities, but you'd be surprised by how few people actually "target" Windows devices. Windows still has accountability to their enterprise users, which means they spend most of their time mitigating the more serious stuff rather than some infected exe you'll find floating around the internet. MacOS and it's Unix heritage make it a pretty interesting case study for hackers, and while it may not have the perceived "hackability" of a Windows box, the severity of a MacOS exploit can vary greatly. Not to mention, Apple's reluctance to work with security researchers and opaque development cycle only make it harder for the end user to ascertain what impact MacOS has on their personal security.

I use neither of these operating systems on a daily basis, but I think you'd be surprised by how secure Windows is these days. It's by no means perfect, but it does a pretty good job of staying secure, even as the #1 desktop operating system in the world. Now if only Microsoft could make a secure desktop that was any good... wishful thinking.

>you'd be surprised by how few people actually "target" Windows devices

What do you mean by this? As a percentage of malware it's not even close, Windows is far and away the most targeted platform: https://www.pcmag.com/news/windows-computers-account-for-83-...

It's also far and away the most used platform, so it should surprise nobody that it's the most targeted.

I'm not surprised, I'm just curious what you meant by saying I'd be surprised at how few people target it.

Android is way more common. https://en.wikipedia.org/wiki/Usage_share_of_operating_syste...

Wow. I would have expected Android to be so much higher. For all the poorest people in the world who never owned a computer and have Internet access through an Android device, this is a great statistic.

Phones are much more secure than desktops.

Windows has a very good built-in antivirus now that protects you from pretty much all but 0-day vulnerabilities.

Really I don't think you can draw any big comparisons here anymore nowadays - Apple's security on mac OS is sandboxing and signing, the latter of which power users will have turned off and the prior being inapplicable in this case.

The response, for the longest time, from a lot of MacOS users was that "Macs can't get viruses." No thanks, in large part, due to Apple's own advertising.

This led to decades of bad online practices on the part of Mac users, thinking that by virtue of using an Apple computer, they were immune to such attacks they deemed exclusive to 'viruses.' Malware was for someone else, they'd argue. Because they don't get viruses, they were fine.

As a result, one of the largest botnets for a time was a MacOS one. Flashback.

https://en.wikipedia.org/wiki/Flashback_(Trojan)

The headline isn't needlessly dramatic. It's dramatic enough to prove a point. Bad habits and lack of safe file handling is the most guaranteed way one opens themselves up to attack vectors such as the one demonstrated in the article.

How does something like this wind up on the front page? As of this comment, it was posted 48 minutes ago with 12 points , one other comment, and sits at number 5. It's a self-professed clickbait title, though the content is interesting.

The ranking algorithm put it here.

Why not? You yourself just said "though the content is interesting." and the title might be a little clickbaity, but its not that bad. I've seen much worse reach the frontpage.

The post are sorted approximately by

  points / (time_in_hours+1)^1.5 * lot_of_penalties

where 1.5 is a number that may change from time to time without warning, perhaps now it's 1.6 or something like that.

The number of comments does not matter, unless the post has too much more comment than points, and the site adds a penalty.

There are a lot of automatic and manual penalties added by the mods, and also added by the flags of the users. Most of the details are part of the secret sauce and change from time to time without warning.

Reply on news.ycombinator.com