54

Floppy disks used to have a physical means of preventing writing to them. No software could bypass that, no matter what. It had to be flicked physically and manually by a human being.

Modern SD cards and SD card converters have a physical such switch, but it does not physically prevent anything and only "advises" the software to not write, which it can ignore at will, rendering it completely meaningless and downright deceptive.

Not a single one of all my many external USB hard disks, even including an older and bigger 3.5" one, have even any such "pretend-switch" on them. Nothing.

Why did they go from allowing physical write protection to not even having a silly "pretend-switch" for this? I've never heard anyone mention this, but to me it's absolutely mindblowing and keeps bothering me every single time I take out my backup media on both disks and memory cards and sticks.

Being able to do this is crucial when restoring important backups on potentially malware-infested computers, or when people prone to making honest mistakes are dealing with them and you only want them to be able to fetch/read data but not corrupt/delete it.

It would cost them maybe $0.001 extra per unit to add this. And I haven't even seen it on the really expensive products (except the fake ones on the memory cards mentioned above).

schroeder
  • 125,553
  • 55
  • 289
  • 326
Polnow
  • 549
  • 2
  • 4
  • 34
    That $0.001 claim is absurd. Imagine if a SD card reader costs only 10 cents ($0.10), if the addition of this component causes failure at only 1%, the cost of a unit failure due to this switch is already $0.001. There's no way that something like this that shows up on EVERY reader and EVERY card will cost this little, let alone the entire QA process for this component across the entire family of cards and readers. – Nelson Oct 18 '22 at 08:16
  • 4
    Exercising Cunningham's Law I see? – MonkeyZeus Oct 18 '22 at 15:23
  • 22
    "It had to be flicked physically and manually by a human being." How quaint. My first floppy disks came with a set of write protect stickers that could be applied to the cover the write enable notch. Of course, you could turn a single-sided disk into a double-sided disk by cutting your own notch on the other side of the case. – FreeMan Oct 18 '22 at 17:25
  • Cartridges with write protect switches are available for professional LTO tape drives. Though it looks like that just advises the drive. – user1937198 Oct 18 '22 at 18:29
  • 8
    I am not convinced you are correct about this. It may be true for some brand you found but what you want does appear to exist: https://security.stackexchange.com/questions/4248/how-reliable-is-a-write-protection-switch-on-a-usb-flash-drive (You can also buy WORM USB sticks. Once written, they can only be read from.) – JamieB Oct 18 '22 at 19:33
  • 7
    Kanguru still sells USB thumb drives with a hardware-enforeced write protect switch. I've used them for years: https://www.kanguru.com/pages/flash-drives – Nick S Oct 19 '22 at 08:24
  • 1
    This might be better asked on [retrocomputing.se] – CGCampbell Oct 19 '22 at 14:18
  • 1
    FWIW I don't see the usecases. If one suspects a computer is malware infected, one nukes from orbit and reprovisions. If one fears a user will overwrite key data, one keeps a copy the user doesn't have write access to. In neither case does a hardware switch fix the real problem: malware remains after the backup is restored unless the backup happens to overwrite it; and the user can easily flick the switch (or it could fail). Moreover no serious computing solution today backs up to removeable media: it's too small and slow. Backups go over networks to spinning magnets: no local hardware. – 2e0byo Oct 19 '22 at 15:02
  • @NickS "Kanguru still sells USB thumb " - I would bet good money that even this is a 'detect/advise' physical switch and not a hardware enforced one. The OP's original premise is based on incorrect information. – Neil Oct 19 '22 at 19:51
  • @Neil So it would just tell the host about it and let it decide what to do? Is there anything in the USB spec for it to be able to communicated that? – Nick S Oct 20 '22 at 14:54
  • 2
    The only way a physical switch would really truly be physical would be if it was connected to a R/W pin and pulled up or down (which ever was always R). Unfortunately, these days, there aren't such pins because everything is serial (SPI), and therefore handled by protocols, which are software controlled. USB is just a transport mechanism, and 'read-only' is a software protocol. – Neil Oct 20 '22 at 15:32
  • 2
    To me these protections were a nightmare. Not only they moved freely and I had to be careful when inserting a diskette, but it was the equivalent of today's USB-B insertion: I never had the correct position the first and second time. – WoJ Oct 20 '22 at 19:55
  • 1
    @FreeMan I remember discovering that secret to turn 3.5" 720k floppies into 1.44MB. I thought I had discovered the chicken that laid the golden egg until I started getting read errors... – Michael Oct 20 '22 at 22:06
  • Amazingly, @Michael, I made DSDD 5-1/4" floppies out of SSDD 5-1/4" floppies all the time and never (to my recollection) ran into any issues. Guess I was just a living right high school kid back then. Did have a few floppies fail (no recollection if they were "enhanced" or not). They made great Frisbees when removed from their protective sleeve, inserted in the drive, then the drive door flicked open while it was attempting to read the disk. Had one fly > 100', leading me and my buddy to hurriedly pack our stuff and escape the university library by a different door... :) – FreeMan Oct 21 '22 at 12:43

11 Answers11

47

Floppy disks used to have a physical means of preventing writing to them. No software could bypass that, no matter what. It had to be flicked physically and manually by a human being.

They didn't. It was ultimately controlled by the floppy drive. The plastic tab indicated whatever the floppy was write protected or not, but ultimately a drive could be made that ignored it.

That's no different from SD cards. What's changed is how much is exposed to the host computer: with floppies, the R/W signal could not be overriden by the host using the standard floppy disk interface. With SD card readers, it's simply a bit sent to the software driver for the card reader.

Why doesn't modern media generally provide this?

Well, if read only is a required feature, there's (as indicated by other answers) products that offers this. In the not so far past, there was also the extremely common optical media: CD-R and later DVD-R, which housed quite a lot and cost next to nothing, with a write after initial recording being impossible.

So in short: it's not a feature most customers are willing to pay for, so it's not delivered in most mass storage devices. If you need it, get a device with a switch, and pay the premium for it.

vidarlo
  • 14,890
  • 2
  • 43
  • 56
  • 35
    Still, if we consider the case of a malware on the main computer, or heck, user errors, there's a big difference between protection implemented in the reader device (even in firmware), and protection implemented fully in software. Though one could use a _reader_ that just rejected writes, if the card itself can't do that, but those would be a bit of a special device, while floppy drives that respected the write support switch were the usual thing. – ilkkachu Oct 18 '22 at 16:24
18

The old floppy disk write protect isn't really at the disk level, and doesn't physically prevent writing. It instructs the drive to prevent writing, as it's detected by the drive electronics (on early drives) or firmware (on more modern ones). Maybe you can trust the electronics even though a user could easily modify them* but you can't necessarily trust the firmware. For an example of floppy drives with modern electronics, I have a USB floppy drive at home.

Except on early drives that were highly analogue by modern standards, the biggest difference in the implementation of write protect on SD vs. floppies is where the code to check/obey the switch is running. And other flash storage formats don't implement whole-drive write protect at all. Essentially SD write protect is so a cautious user doesn't accidentally delete their photos - but when it was introduced, pro cameras all used CF cards or the miniature HDDs in CF format anyway.

Also, SD cards support slow read/write over the very simple SPI bus. Write protect detection for that would have to be done in the card itself, adding cost top every card. For high-speed writing it would have to be implemented in the reader.


*disk duplicators didn't check for the switch, because disks intended for mass distribution didn't always have one, instead having just a hole. Taping over the hole was a workaround if you wanted to reuse those disks.

Chris H
  • 4,375
  • 2
  • 16
  • 23
  • 1
    Why is it a problem that SD cards support accesses over SPI? Or why would the write-protect need to be implemented in the reader for high-speed writing? AFAIU the card itself necessarily contains some flash controller which, if nothing else, interprets the commands it gets on the bus, and which should be well-enough capable of reading one bit of data from an external pin and rejecting writes based on it. – ilkkachu Oct 18 '22 at 16:13
  • @ilkkachu it's a while since I studied the SD physical layer for a project that didn't happen, but I recalled SPI writing relying solely on the card's controller but faster modes hand off more to the host; checking just now, the controller in the card could still block the write – Chris H Oct 18 '22 at 19:28
  • @ChrisH: I would think that having a "write protect" pin on SD cards could be a useful feature for not only guarding against requested write operations, but also providing enhanced robustness against unexpected power-down events when used with a host device that deasserts write-enable while a certain amount of energy remains in a power-supply cap. – supercat Oct 18 '22 at 20:52
  • 3
    And an advanced user (or a software bug) could still write to those supposedly write-protected floppy. For an example detailed dive in into such a case can be found here: https://scarybeastsecurity.blogspot.com/2020/06/a-wild-bug-1970s-intel-8271-disc-chip.html – Matija Nalis Oct 18 '22 at 20:55
  • @supercat when SD was introduced it was just one of several formats meant mainly for cameras. None of the rival technologies implemented any sophisticated form of write protection either, even those, unlike SD, that were aimed at professional use. – Chris H Oct 18 '22 at 21:09
  • @MatijaNalis I knew there were things that could be done, but didn't play much with hardware in the days of 5¼ inch disks - it was expensive and not mine. By the time I was doing much hardware tinkering 3½ drives were the norm. And there were easier ways to defeat the write protect on a per disk basis – Chris H Oct 18 '22 at 21:12
  • @ChrisH: Many SD cards are prone to data corruption if power is lost while they are busy processing wear-leveling algorithms. Having a hardware mechanism that could guard against data corruption in case of power loss would seem like a useful feature. – supercat Oct 18 '22 at 23:08
  • 1
    @supercat protection from power loss is done in other ways. Sd cards are, by design, camera (etc.) storage from the 90s. Cameras' low battery logic leads to an orderly shutdown so a write wouldn't be commanded when the power rail couldn't be maintained. Wear levelling would have to go on for a long time after a write to be a problem, and SD wear levelling doesn't involve a lot of rewriting (simpler than in SSDs & they probably learnt from the older tech). From experience on Raspberry Pis, corruption is very unlikely on power loss. Protection nice for edge cases, adds cost to card & device. – Chris H Oct 19 '22 at 06:05
  • @ChrisH: A project I was involved with that used about a dozen Raspberry Pi devices had frequent problems with corruption until we configured the SD cards to never write anything during normal operation but simply use network storage for everything that was volatile. Although cameras would often run off enclosed batteries, many could also be supplied by mains power or an external battery pack, which could be disconnected without warning. – supercat Oct 19 '22 at 14:31
  • @supercat my RPi project only wrote (appended) about 50B once every 30s then closed the file, so it's not surprising I had better luck. But they did handle students rebooting by toggling the power. You've now got me wondering: did the first mass market digital cameras have the ability to run off mains? – Chris H Oct 19 '22 at 18:13
  • 1
    @ilkkachu it's indirectly a problem in that it means that functionality would need to be implemented twice instead of only once. – Dan Is Fiddling By Firelight Oct 19 '22 at 18:16
  • 1
    @ChrisH: I'm not sure about the first ones, but the third one I bought offered a mains adapter as a feature, and the first cameras were sufficient battery guzzlers that I would expect that many people who used them a lot would have welcomed the ability to connect a belt pack with four D cells. – supercat Oct 19 '22 at 18:18
  • That said, is SPI interface still a factor on modern SD cards? Years ago when working on a system that wrote to SD cards over SPI, we had to order unusually small capacity cards for it to work. I don't recall if that was a limitation in the SPI-flash interface itself though, or in some part of the file system driver we were using. – Dan Is Fiddling By Firelight Oct 19 '22 at 18:19
  • @DanIsFiddlingByFirelight it's still in the spec, so probably a driver (or file system - sneaky partitioning and formatting may provide a workaround) issue. I know of applications that are likely to use SPI (3D printers so reading, at least mainly) that don't work with SDHC – Chris H Oct 19 '22 at 18:23
  • @DanIsFiddlingByFirelight, twice? Or do you mean once inside the firmware, and once in the main OS? That doesn't sound _too_ complicated, since pretty much the only addition to the current situation would be for the controller to just check the bit and reject writes if it's enabled. Though I might be worried about sucky controllers having a buggy implementation of the write protection, or only protecting a subset of commands... (if there's multiple that could be consider "write-like") – ilkkachu Oct 19 '22 at 18:30
15

Ultimately because on USBs, it was a very niche feature that the vast, vast majority of people didn't care about. It adds complexity (and thus cost) to the drives, it's another component that can fail (especially as it's a physical switch on a device with no other moving parts), and it can also cause lots of problems (especially the switch gets accidentally turned on and then the device is "broken").

There are still companies who sell devices with hardware switches (like Kanguru - and I'm sure you can find others), but you can expect to pay a premium for them. You can also buy hardware write blockers, which are mostly used for forensics, although I've also seen people use them to guarantee that drives can't get infected when moving them between environments.

schroeder
  • 125,553
  • 55
  • 289
  • 326
Gh0stFish
  • 6,800
  • 1
  • 23
  • 23
  • 13
    @schroeder You've changed this answer from meaning that write protection on USBs in *particular* was a very niche feature. I'm not sure there ever was write protection on USBs (and indeed, that's the context in which this question was asked), which makes this answer confusing. This is very different from what the author originally wrote: That write protection on *any* storage device is a niche feature. – Rob Oct 19 '22 at 05:28
  • Write protection probably was quite a niche feature on USB (stick)s, at least I've never heard of one having write protection! I wonder if the meaning here was supposed to be that it was a niche feature on floppies already, though I have the impression it was common knowledge at the time. Which doesn't mean everyone would have used it. – ilkkachu Oct 19 '22 at 18:33
  • @AndrewRay "it" had no antecedent and it was causing confusion. And yes, the author confirmed the USB write controls were what was intended. – schroeder Oct 20 '22 at 10:37
13

It is many things...

  • Even if the cost were $0.001 per SD card, at current market, we're talking about a hundreds of thousands (and possibly millions) of dollars extra.

  • The cost is way more - mechanical parts are surprisingly expensive. Moving parts even more so. For example, you can get complete micro IoT computer like raspberry PI zero W for $5, and a set of a stupid 2x20-pin Strip Dual Male Header for it would cost you extra $0.95 (that 40 little brass pins in plastic) -- which cost 20% of the price of the whole singleboard computer with wifi, bluetooth, CPU, RAM etc. integrated! Moving parts, especially the ones that don't break after several uses, can easily cost more than that whole computer (as would a plastic case for it).

  • There is not only material cost, oh no. Not the fact the Bill-of-Materials much prefer multiple pieces of the same thing to the different things. Placement cost is absolutely huge. Your chips and components can be placed by pick'n'place machine for basically nothing compared to how much would adding physical switch cost.

  • then we come to the real cost. User support and logistics. There is a moving part. Meaning it will break. The cheaper you managed to make it, the more likely it is it will break. Meaning the more users will complain. Meaning you have to have bigger callcenter, more personnel, more overhead, more outrageous shipping costs on your expense etc. (even if you don't count the cost of the product itself)

  • there is also upgrade problem with hardware things. If there is a problem found, it is not a simple software fix followed by "put new firmware update and let automatic computer upgrade fetch it and apply it", it is a recall of defective product which has to be thrown to e-waste (and payed for that) but also a new batches to be delivered at your own cost.

And to compound all that, while putting the switch closer to the actual hardware might seemingly help, it quite often doesn't. It is just that people back then were not so frightened by security exploits (due to Internet not existing and stuff), that they were easier to convince that something is actually safe when it wasn't.

Case in point, even on old floppy drive protected by "physical" protection holes, an advanced user (or a software bug) could still write to those supposedly write-protected floppy. For an example, detailed dive in into such a case can be found here in nice retro reverse-engineering blog post: https://scarybeastsecurity.blogspot.com/2020/06/a-wild-bug-1970s-intel-8271-disc-chip.html

Matija Nalis
  • 2,265
  • 13
  • 19
  • In terms of user support, there's also the potential issue of accidentally making the drive read-only and being confused why it can't be modified. – Solomon Ucko Oct 20 '22 at 18:46
10

In ancient days when people were WOW'd by how many kilobytes your computer had, the write capability could be disabled via a single wire. Modern interfaces and techniques don't lend themselves to that simple of an interface.

There is an entire industry, marketing primarily to forensics use, that make what is commonly referred to as Hardware Blockers. The idea is this sits between the computer and the storage device to protect (block) any writes from occurring and affecting the evidence, in fact there is a never ending mini-battle as to whether Software Blocking is acceptable. (Bear with me, there is a point.) The reality of these expensive hardware blockers is that none of them are actually hardware blockers, they all work by recognizing and blocking commands known to cause a write. They are software functions in a separate box. In fact their firmware is updatable to account for new devices and protocols and sometimes they still get it wrong.

The net result is that modern implementations are too complex to lend themselves to a simple hardware switch. For example, a given device may require a low power signal to read and a high power signal to write, what's more timing is lkely different. It's all under software control, there is no dedicated wire to switch.

user10216038
  • 7,933
  • 2
  • 16
  • 20
  • 3
    Please explain to me why it's "too complicated" to have a physical separation of two small metal pieces which, if they are not connected, prevent writing entirely within the storage device? I just can't accept the "it's so complicated these days" explanation, because it doesn't seem to explain anything? Aren't you basically saying that they have been deliberately crippled at the specification stage to allow for an unnecessary industry which locks out anyone who isn't rich from having basic security? – Polnow Oct 18 '22 at 14:19
  • I added a simple example for you. – user10216038 Oct 18 '22 at 14:31
  • 7
    @Polnow Because all that the card sees is a stream of commands, some of them read commands, other write commands, all sent the same way over the same wires. It's not like all writes go through a separate bus you can just easily disconnect (putting something like that into the design would be impractical as it would nearly double the required pin count). So the only possible way to implement this in hardware is to insert a man-in-the-middle into the command path and have it interpret all commands as they come in and filter out the writes. That's exactly what the forensic write blockers do. – TooTea Oct 18 '22 at 15:53
  • 1
    @Polnow and you need to know *which commands* are writes and which are reads. Whilst that's perfectly doable with a copy of the relevant spec, the set of both is a fair bit larger than one. You decide whether the motivation for this spec was 'allowing an unnecessary industry which locks out anyone who isn't rich' or e.g. implementing efficient disk access for the filesystems targeted. – 2e0byo Oct 18 '22 at 19:23
  • 4
    The explanation in this answer seems to imply that "protocol is hard, we won't implement the checks for commands that might write". Well, why not reject writing transactions at the level of the storage device itself rather than the controller? – Ruslan Oct 18 '22 at 20:12
  • 4
    @TooTea: The "forensic write blockers" all of course rely on the cooperation of the storage device. If the host and device are in collusion, then they can easily hide writes from man in the middle. Think about how ineffective a web firewall "write blocker" would be, if it blocked HTTP(s) POST requests while allowing HTTP(s) GET requests. Clearly the client can manipulate the querystring on a "read" and still transfer arbitrary data to the server. Same is true for storage device, if host and device are in collusion. – Ben Voigt Oct 18 '22 at 20:38
  • @Ruslan how do you plan on doing that? What would such an implementation look like for spinning magnets, nand flash and FeRAM? Sure, in each case you *could* build a circuit to do that, but given that almost nobody wants it the R&D makes it pointless. – 2e0byo Oct 19 '22 at 14:57
4

Because it is an extra point of failure, and there are much easier-to-use versions at the file system level.

The read/write switch needs a detector on the drive, and due to its mechanical nature, can fail mechanically. It'll definitely cost more than $0.001 per unit.

If you need proper read/write access, you can easily do this at the file system level.

Nelson
  • 990
  • 7
  • 12
  • Also, if all the switch does is disconnect/connect a minimal metallic connection, I don't see the problem in complexity/cost. – Polnow Oct 18 '22 at 08:08
  • 5
    @Polnow Then prototype it until it is the $0.001 cost that you claim. Saying baking a cake is easy is very different than making baking easy. And my answer was created from reading the question fully, so looks like I misunderstood it, but I have no idea what I misunderstood because you didn't specify. – Nelson Oct 18 '22 at 08:11
  • 1
    @Polnow nobody forces you to directly attach the sd card to the malware infested computer. Attach it to one that you know is working correctly that shares it to the machine you want to restore with the proper permissions set up. Or just clone the sd card prior to restoring. – Haukinger Oct 18 '22 at 08:12
  • @Nelson: Well, in the reasonable case of Flash memory, it is pretty much that simple. Flash writing relies on one very specific bit of circuitry, the charge pump, to generate a high-enough voltage. Short that out, and it is physically impossible to generate the write voltage. – MSalters Oct 21 '22 at 13:59
2

It may just be my perception, but the "write-protect" mechanisms was more intended as a way to protect valuable (paid) content to be inadvertently erased/overwritten by other data rather than as a nice functionality for end user.

For example, think about your old cassette tapes. You just bought the last album of your preferred artist, they didn't want to sell it on a physical support which could be blown away so easily, so they didn't make it impossible to erase, they just "dumb-proofed" it a bit. It was only to avoid accidental erasure.

Similarly, a lot of valuable content was delivered on floppy disks. I remember the 12 floppy disks necessary to run my first version of Access DB, which I paid good money for. I was quite savvy in computers already, but if not it would be very easy for someone to accidentally erase or corrupt the content of one floppy disk. So once again, a bit of "dumb-proofing" was incorporated into the design (sorry if you find the term "dumb-proofing" offensive, just think of it as "accidental mistake proofing" if it sounds better).

Then the times changed. The new support to deliver valuable digital content was an optical disk, which was not overwritable, so it didn't need that extra layer of accidental erasure protection.

Nowadays, you rarely get CDs anymore (you have to request and pay for it), everything comes to you downloaded from another server. If you corrupt your downloaded files you can just download them again (provided you have the proper license or proof of purchase).

So the physical media we use nowadays to store digital data are mostly used as storage for end users data, they are not used to deliver valuable paid for content. The necessity for protection decreased and as other answers mentioned, the cost to implement something robust enough was not worth mass market adoption, so only a few companies actually implement these features, and obviously have to charge a premium for it.

Note: You could argue that the feature would still be interesting for the mass market as a way to write something "permanently" (write it once and never change it again). A sort of backup. Well, you could use burn-once CD or DVD, or indeed USB sticks which this feature, but the industry consensus on backups nowadays relies more on redundancy than on safeguarding a single physical support. After all, even CDs and USB sticks have a limited useful lifetime before data can get corrupted (without any human interaction). So once again, no need to implement a costly feature for a flawed solution.

The main domain where this feature is really needed is when computer security is involved. That is not a mass market but rather an industry niche. For these applications the feature exists, but it has a certain cost.

Sir Muffington
  • 1,536
  • 2
  • 11
  • 23
Hoki
  • 121
  • 3
1

Because mass storage write-protect robust enough for security purposes is prohibitively difficult/expensive to implement, and unsecure write-protect for avoiding boneheaded errors is too niche to be worth manufacturing. (After all, a sufficiently advanced bonehead will eventually just toggle the write-protect switch.)

Write (and read) protect is still very common for flash inside SoCs, but this is because the extreme expense of unpackaging an integrated circuit and tampering directly with the wafer excludes most users' threat models. Once you have multiple integrated circuits, the cost of tamper attacks goes down by several orders of magnitude, and you have to do a lot more legwork to protect against hardware MITM. E.g. you may need to have security regions inside each chip to store unique secrets programmed in the factory. Mass storage uses separate flash chips, so you need to upgrade to flash chips with security regions (they don't all have them).

Even if you're only considering software attacks in your threat model (i.e. using storage media in your exclusive custody to re-image a compromised system), circuits outside of security regions (and firmware, inside or outside security regions) receive significantly less R&D to prevent software from accessing parts of the hardware it shouldn't. E.g. a buffer overflow might be found which can be used to write to a section of memory scheduled for DMA transfer to the SPI transmit register as the controller prepares to send an authenticated command to a flash chip. Or a privilege escalation may be found on the controller which lets you load new code into the non-security flash, which can use keys in the security region to send arbitrary commands to flash chips. You'd be hard pressed to find vulnerabilities in the actual security region, but unless the data is literally inside the security region, it's an extremely difficult problem to prevent unauthorized reads and writes to that data. Storage media that can make that claim and back it up would fetch a pretty penny, but would it be worth the R&D? Manufacturers don't seem to think so right now.

John
  • 111
  • 3
1

For the record, SD cards do have a write protection mechanism, even if it's firmware only. Look up TMP_WRITE_PROTECT/PERM_WRITE_PROTECT bits in the CSD register. Obviously, this feature won't offer any protection against a malicious host, but it does help to prevent honest mistakes.

On the other hand, to access SD card write protection flag, you need a card reader which exposes the raw MMC block device (e.g. /dev/mmcblk0) and not just a mass storage device (e.g. /dev/sda) that is the case with most cheap USB card readers. Putting a write-protected SD card in such a card reader protects against malicious hosts as well.

Dmitry Grigoryev
  • 10,122
  • 1
  • 26
  • 56
-1

If it is crucial to you that nothing can write to a disk, there are tools (both hardware and software) that will help you achieve that. It's just that most people don't need this, so it's not worth adding to the regular hardware.

Just google for software write blockers, forensic disk controllers or hardware write-block devices.

Paul
  • 101
-1

I have a few "recent" (USB 3.0) 2.5" enclosure with write protect (not a physical switch though). I can't speak to how it's implemented and if it can be bypassed. Also a search for "usb with write protect switch" turns up results including a 16 GB USB 3.0 stick, so I guess "they didn't [all] stop".

On Linux, you can mount pretty much anything as read-only (yes, it's software enforced, but as somebody else pointed, floppy disks never had a hardware write protect, it was just part of the controller).

On Windows, there's no such option that I'm aware of. A while ago, I made a driver to allow that, it'd mount device with "read-only" option, and as an extra safety, it'd drop any write operation.

The fact is, ultimately, it is extremely unlikely someone would implement that as a hardware option. What I mean is, at best, your flash controller, or your whatever controller (like your USB UMS to SATA bridge) will have a firmware that will check if writing is authorised, and if not, will inform the OS and hopefully will fail any write request. It could likely be bypassed if the device would have a vulnerability (in the firmware, or a way to upgrade the firmware).

Now I cannot answer your question, you would have to ask every single entity separately to know "why they didn't do it". My bet is it has to do with cost and market demand. Plus the ever-going evolution that everything hardware gets moved to software (you don't have hardware tuners anymore, you have software defined radios, when you plug your microphone, it no longer physically disable your built-in microphone, it's turned off in software)... It is often cheaper to do software, it can also add convenience, and it adds software upgrade support.

user1532080
  • 571
  • 2
  • 8