10 ms·

How about requiring devices to accept alternate, Free Software firmware, from the upstream provider? At the very least, it should be possible after some time p

• the4anoni 3y ago
  As far as I remember FCC about 8 years ago didn't liked OpenWRT, and even enforced on TP Link to lock it.
  • SoftTalker 3y ago
    IIRC the main objection was that it could be used to do something with the radio (boost power?) that caused the device to exceed FCC limits for a consumer radio? Something along those lines?
    • PhilipRoman 3y ago
      For those out of the loop these documents have a good introduction to how free software interacts with radio regulations https://wireless.wiki.kernel.org/en/developers/regulatory/statement https://wireless.wiki.kernel.org/en/developers/regulatory/st... https://wireless.wiki.kernel.org/en/developers/regulatory https://wireless.wiki.kernel.org/en/developers/regulatory TLDR manufacturers and "serious" companies won't touch anything that could potentially be configured to emit signals that your local government doesn't like. So Linux has to pretend it doesn't allow to do that (even though anyone with 2 braincells can patch it)
      • dtaht 3y ago
        As these regulations change frequently, I am glad that linux makes it possible to update this database and the devices in the field. For example a portion of the 5.9ghz spectrum became available. https://www.computerworld.com/article/2993112/vint-cerf-and-260-experts-give-fcc-a-plan-to-secure-wi-fi-routers.html https://www.computerworld.com/article/2993112/vint-cerf-and-...
      • codedokode 3y ago
        So Linux takes government's side, not user's?
        • chupasaurus 3y ago
          I'd call it "safe defaults".
    • RF_Savage 3y ago
      It was about the radio and being able to modify the radio firmware. As many modifications would void the FCC certifications of the device, due to changed parameters (more power, disabled anti-interface mitigations, out-of-band channels, etc.). This was avoided by making the radio firmware separate blobs, but there was a real danger of the whole device having to have signed firmware.
    • pgeorgi 3y ago
      The main issue these days is the 5GHz band that might interfere with radar. That's mostly an issue outside near an airport, that is, it affects practically nobody, so the solution is to snoop the problematic bands and disable them when detecting radar signals, and use them otherwise for a bandwidth boost. These days this seems to be mostly done in wifi chip firmware (that is then signed and under lock and wrap to make it tamper proof), but back in the day it was too easy to circumvent the mechanism.
  • tzs 3y ago
    There was no requirement that firmware be locked down. The requirement was that consumer radio transmitters could be too easily made to use frequencies and power levels that violate FCC regulations. If a device had a transmitter where firmware could control those things, and the firmware for the device was one blob that contained everything so letting the user replace firmware meant letting the user control those restricted parameters, then the manufacturer might have to lock the firmware. There were other possible approaches. One would be to split the firmware into two parts. One part for the radio hardware and the other for everything else. Make it so the firmware update process only allows the manufacturer to supply the first part.
    • Y_Y 3y ago
      Isn't that a bit overreaching? I can make you a device the spews garbage on any wavelength you fancy, so they're really only preventing accidental radio pollution. Even in that case it's pretty unusual to prevent a consumer device (other than a radio) from being used in an unlawful way, Part 15 notwithstanding.
      • zamadatix 3y ago
        I believe the regulation applies to such a device you make as well, not specifically consumer Wi-Fi products. I.e. if you make a transmitting SDR it's not supposed to allow certain things. The prevention all comes down to enforcement though, the law doesn't physically stop you from making a device it just means you could get in trouble for intentionally ignoring it and selling a lot of those devices.
        • Y_Y 3y ago
          You're totally right. I'm trying to make a moral argument, I think if it were unfeasible for an individual to make something (e.g. modern CPU) then you could make an argument for producers limiting them on the basis that it would effectively prevent anyone from doing the banned thing. The fact that it's roughly as easy to reflash an IoT device with custom firmware as it is to make an antenna that produces noise in a forbidden frequency means that you are adding a technical measure to prevent just some of that illegal action and not stopping a determined hacker. I'm not claiming it wouldn't be an overall social good, but other areas of law and regulation don't seem to function like this (with notable exceptions like photocopying banknotes).
  • dtaht 3y ago
    Vint Cerf and I shot that proposed anti-dd-wrt regulation down thoroughly: filing here: http://www.taht.net/~d/fcc_saner_software_practices.pdf http://www.taht.net/~d/fcc_saner_software_practices.pdf Substitute IoT for router in everything we wrote there on page 12-13 and that seems to be a starting point everyone around here has come to think is necessary. I would prefer not to summarize such a large filing here. Also Dan Geer wrote extensively on these topics at the time. Of late I have been strongly suggesting that software be at least "built in america": https://blog.cerowrt.org/post/an_upgrade_in_place/ https://blog.cerowrt.org/post/an_upgrade_in_place/ I care most deeply first - that the front doors to our houses, the home gateways, are properly secured, kept up to date, and have ipv6 and bufferbloat fixes on them. IoT devices belong on their own vlan...
• hannob 3y ago
  I am all for alternative free software firmware. But I don't think it adresses IoT security in any meaningful way.
  • CameronNemo 3y ago
    Why? The person you are replying to outlined one major example where IoT security was improved: wireless routers. Not allowing users to update the software on the hardware they own is just a botnet waiting to happen.
    • dboreham 3y ago
      99% of users don't know their iot devices have firmware nor that it can be updated.
      • computerfriend 3y ago
        Maybe that figure would change if the firmware could indeed be updated.
        • NegativeK 3y ago
          It would change, but again -- it wouldn't be appreciable. Security policy is needed that accounts for the behaviors of the vast majority of users.
          • Larrikin 3y ago
            Users update their phones, there's no reason they can't be educated to update their other devices
            • NegativeK 3y ago
              Most non-technical users that I know don't actively update their phones and push back when I tell them that they need to do so faster than the automatic process because of an actively exploited vulnerability.
• deleted 3y ago
  [deleted]
• Finnucane 3y ago
  This is kind of adjunct to the right-to-repair question. "Smart" features are being added to things that a person would expect to have a long usable lifetime--like cars, kitchen appliances, and so on. If the manufacturer is saying, we'll only support the "smart" features for five years, one would be inclined to opt out on that unless there is a way to ensure the appliance remains useful.
• entropyie 3y ago
  This is also a key point to fighting ewaste and making devices last longer. I have appliances from the 70s including a rotary telephone, that I still use regularly. If you combined mandatory OSS support with repair cafes, you would have a model for sustainable reuse and better security. You may even start a commercial aftermarket in reflashing older devices!
  • phero_cnstrcts 3y ago
    At rotary phones still compatible with todays standards? If that’s the case I might get one too.
    • dpifke 3y ago
      It's been years since I've seen a landline, but as of a ~decade ago you could still dial "rotary" by tapping the receiver hook with the correct spacing. (1 click to dial a "1," 2 clicks to dial a "2," etc. with a pause between digits.)
    • entropyie 3y ago
      In my case I use a small gadget to convert the pulses to DTMF tones, which feed into a voip connection. The point is that the device itself still works, unlike much iot crap which can't be made to work once the server goes down.
  • treyd 3y ago
    Yeah if companies that make IoT hardware complain about the costs to keep old devices updated then they should be required to make them more user-modifiable and release source code / signing keys when they're abandoned by their manufacturer so that they can be picked up by the communities and development can be continued (also requires some policing to determine when hardware is functionally abandoned, as releasing a minor update once a year that doesn't fix real bugs should still be considered abandoned). Repair cafes would be fantastic for helping support small businesses keeping people's old hardware running. Of course, manufacturers don't want that either because they make money off of planned obsolescence and consumers keeping old hardware running makes them less likely to buy old hardware.
• Ajedi32 3y ago
  I'm a big supporter of the idea of applying right to repair principles to software, but I don't think it should (or legally can) be implemented by fiat of unelected bureaucrats at the FCC. Labeling requirements like what the OP is proposing seem much more palatable to me.
• ChrisCinelli 3y ago
  Openwrt is not the best example. Community sucks, some routers are full of bugs and the security is not great either. In general even if I like open devices and having the option to use my own software, this is not a solution for most of the consumers. It is not a solution even for the enthusiast that know how to flash their own firmware. Because even if they may do it a few times initially, eventually they stop doing it. You need a system that can update automatically even when you are busy in another project.
  • abwizz 3y ago
    openwrt is surely lacking in many aspects, but all the points you brought forward also apply to the manufacturer firmware but those are even less user friendly and cannot be modified. there are a lot of open and closed firmware projects building upon openwrt
    • ChrisCinelli 3y ago
      I am not clear how "all the points you brought forward also apply to the manufacturer firmware"
    • adventured 3y ago
      > but all the points you brought forward also apply to the manufacturer firmware but those are even less user friendly and cannot be modified. That's more than a reach of a claim. All manufacturer firmware are buggy with poor security? That's very obviously false. With closed manufacturers the history is that it's a mixed bag, not a blanket. Some are excellent, some are very poor. Openwrt has been mediocre and all the negatives about it do not equally apply to all closed manufacturer firmware.
      • abwizz 3y ago
        > All manufacturer firmware are buggy with poor security? That's very obviously false. guess we have a difference of opinion then
  • petsfed 3y ago
• MarcoPerazaFCC 3y ago
  Maybe the presence or absence of this capability could be something disclosed on the label? It's an idea worth thinking about. I encourage you to file a comment with your thoughts on the matter. You probably want to focus on how this information could help a security-concerned consumer/business make a better purchasing decision. Or if you're arguing that this be a hard-requirement for the label, why a device should not be considered secure without this capability.
• basch 3y ago
  Also, one of the single most important parts of security is human manageability. Having to go into a proprietary app for each manufacturer. There's this level of management at the google/amazom/apple level, and in some cases google even lets me push firmware updates (sennheiser ambeo is an example), BUT there should be a requirement that security settings in firmware be exposed in a way that they can be manipulated in a rolled up dashboard. I shouldn't have to depend on a first party app to stay maintained to get to the settings for a device.
• ics 3y ago
  Possibly weird idea: federal firmware escrow. The OEM gets to put a stamp on their product after submitting firmware source/keys to the FCC. When the OEM either declares the product not supported or provides no updates for X length of time, the files are automatically published to a public repository. Perhaps there is an appropriate license which says essentially that it is almost public domain, with an exception (or fee?) to use it for any purpose other than supporting the lifetime of an existing product. As others have stated, free software is one way of giving the public ability to keep things up to date but that's almost like the government saying people are allowed to clean up pollution. It doesn't put any pressure on companies to behave better. Another issue is build-ability of open source code. If an OEM submits firmware source and keys to a third party, even regularly, who really knows whether it is actually functional and complete. Automated tests or sample hardware are possible ideas but have their own failure modes and could be difficult for to implement solely for this purpose. Another weird idea for the above. If one requirement was deterministic builds, then in addition to source/keys, a suitable toolchain to build could also be required such that the repository stewards would only need to run exactly what the OEM provides, and if the checksums don't match then it means they are not in compliance.
  • unintendedcons 3y ago
    I like this idea! A code&keys escrow org, yes please
  • bick_nyers 3y ago
    This is an amazing idea and I would only buy a product that has this stamp on them. I would put some additional triggers into the publication of source code as well, notably if the company goes out of business. I would also put some kind of timer and renewal process on it, like a company needs to recertify every 1-5 years (pros and cons to different time lengths) and that they have indeed been providing actual updates (and not just fake ones) and actual support.
    • ics 3y ago
      The OEM could be allowed to choose their recertification period, perhaps with slight differences in requirements. Perhaps even different options offered by company size. For example 1-5 employee companies might get a "no recertification, provided as-is" option which releases automatically 3 years after filing. Vendors who re-certify every 6 months could get an extra mark on their stamp or whatever. There are tons of possibilities honestly, and though I've been thinking about it for a long time writing it is much easier to come up with more.
• caust1c 3y ago
  I like this angle. Require device manufacturers to actually comply with OSS licenses and extend it to require providing the means for consumers to build upon the software as you mention. Furthermore, if the concern is national security, then I think some of the onus should be on the corporate consumers of such devices. Holding them responsible for doing due diligence on their vendors seems easier to regulate and enforce than trying to regulate supply side. Of course, this leaves the general population without a clear solution to updates if the process of updating using alternate channels has any amount of friction whatsoever. I'm clueless as to what to do about that. Regulating it entrenches established companies. Not regulating it maintains the status quo. Anecdotally, it feels like software has gotten far more secure in the past decade without regulation but security theater and concerns around national security have grown considerably faster. This isn't easy to measure of course, but that's how I see it.
• carride 3y ago
  The best alternative firmware example for true IOT devices is Tasmota [1]. Erase manufacturer firmware for every ESP devices the day after purchase to avoid those careless manufacturer firmwares. [1] https://tasmota.github.io/docs/ https://tasmota.github.io/docs/