[HN Gopher] Ask HN: I'm an FCC Commissioner proposing regulation...
___________________________________________________________________
Ask HN: I'm an FCC Commissioner proposing regulation of IoT
security updates
Hi everyone, I'm FCC Commissioner Nathan Simington, and I'm here to
discuss security updates for IoT devices and how you can make a
difference by filing comments with the FCC. As you know, serious
vulnerabilities are common in IoT, and it often takes too long for
these to be patched on end-user devices--if the manufacturer even
bothers to release an update, and if the device was even designed
to receive them. Companies may stop supporting a device well before
consumers have stopped using it. The support period is often not
communicated at the time of sale. And sometimes the end of support
is not even announced, leaving even informed users unsure whether
their devices are still safe. I've advocated for the FCC to
require device manufacturers to support their devices with security
updates for a reasonable amount of time [1]. I can't bring such a
proposal to a vote since I'm not the chairman of the agency. But I
was able to convince my colleagues to tentatively support something
a little more moderate addressing this problem. The FCC recently
issued a Notice of Proposed Rulemaking [2] for a cybersecurity
labeling program for connected devices. If they meet certain
criteria for the security of their product, manufacturers can put
an FCC cybersecurity label on it. I fought hard for one of these
criteria to be the disclosure of how long the product will receive
security updates. I hope that, besides arming consumers with better
information, the commitments on this label (including the support
period) will be legally enforceable in contract and tort lawsuits
and under other laws. You can see my full statement here [3]. But
it's too early to declare victory. Many manufacturers oppose making
any commitments about security updates, even voluntary ones. These
manufacturers are heavily engaged at the FCC and represented by
sophisticated regulatory lawyers. The FCC and White House are not
likely to take a strong stand if they only hear the device
manufacturer's side of the story. In short, they need to hear from
you. You have experienced insecure protocols, exposed private keys,
and other atrocious security. You have seen these problems persist
despite ample warning. People ask, 'why aren't there rules about
these things?' This is your chance to get on the record and tell us
what you think the rules should be. If infosec doesn't make this an
issue, the general public will continue falsely assuming that
everything is fine. But if you get on the record and the government
fails to act, the evidence of this failure will be all over the
Internet forever. If you want to influence the process, you have
until September 25th, 2023 (midnight ET) to file comments in the
rulemaking proceeding.[4] Filing is easy: go to
https://www.fcc.gov/ecfs/search/docket-detail/23-239 and click to
file either an 'express' comment (type into a textbox) or a
'standard' comment (upload a PDF). Either way, the FCC is required
to consider your arguments. All options are on the table, so don't
hold back, but do make your arguments as clear as possible, so even
lawyers can understand them. If you have a qualification (line of
work, special degree, years of experience, etc.) that would bolster
the credibility of your official comment, be sure to mention that,
but the only necessary qualification is being an interested member
of the public. I'm here to listen and learn. AMA. Feel free to ask
any questions about this or related issues, and I'll answer as many
as I can. I just ask that we try to stay on the topic of security.
My legal advisor, Marco Peraza, a security-focused software
engineer turned cybersecurity lawyer, will be answering questions
too. I'm open to incorporating your ideas (and even being convinced
I'm wrong), and I hope that my colleagues at the FCC are as well.
Thank you! [1] https://www.fcc.gov/document/simington-calls-
mandatory-secur... [2] https://www.fcc.gov/document/fcc-proposes-
cybersecurity-labe... [3] https://www.fcc.gov/document/fcc-
proposes-cybersecurity-labe... [4] If your comments are purely in
response to arguments made in other comments, you have an extra 15
days, until October 10, 2023.
Author : SimingtonFCC
Score : 2029 points
Date : 2023-09-05 15:07 UTC (7 hours ago)
| arkitectual wrote:
| I really appreciate you directly going to the community for
| feedback.
|
| As someone who writes software for IoT devices and has worked in
| the past on security in the IoT space this is sorely needed. By
| far the biggest issue in my view is that manufacturers are not
| motivated to take device security seriously since they are
| largely isolated from any fallout. Device manufacturers already
| have to pass certification for RF emissions and safety among
| other things and should have to pass certification for at least a
| basic security audit on the device and the services the device
| connects to. Even self-certification would improve the current
| situation.
|
| For many device types there exists some form of open source OTA
| update software or a commercial offering. In the last few years
| there has been significant maturing of the tooling in this space
| but the security aspect is often left as optional even though the
| tooling often makes it fairly easy to add. At this point I think
| the industry just needs a little push to make secure OTA updates
| the standard.
| outwit wrote:
| A regulation that would force companies to release source code in
| case they go out of business. A form of escrow maybe? I have
| several paperweights that used to be "smart". And several others
| that still work but will never get another update.
| iandanforth wrote:
| I think the most valuable security feature for IoT devices is
| being able to work without contact with a central service.
|
| If the value of a device is tied to opening a connection to and
| occasionally retrieving code from a third party it is _inherently
| insecure_. All I have to do is buy the company that owns the
| central server (or compromise it in some other less visible way)
| and I now have the ability to introduce malicious code to all
| devices that are receiving 'security updates.' You won't be able
| to make a rule to prevent asset transfer (correct me if I'm
| wrong) so you won't be able to close this hole. And this assumes
| the manufacturer isn't malicious in the first place.
|
| For people to be able to protect themselves and to protect the
| value of the property they have purchased (e.g. the company tanks
| and the central service is lost) a rule should exist mandating
| minimum useful functionality in a disconnected and/or self-
| managed environment.
| nickff wrote:
| > _" All I have to do is buy the company that owns the central
| server (or compromise it in some other less visible way) and I
| now have the ability to introduce malicious code to all devices
| that are receiving 'security updates.' You won't be able to
| make a rule to prevent asset transfer (correct me if I'm wrong)
| so you won't be able to close this hole."_
|
| Has this actually been a problem in the past? I do not know of
| any examples of this, do you?
|
| I hate having to create and maintain accounts and subscriptions
| for so many devices, but I'm not sure it's a huge security
| problem.
| iandanforth wrote:
| Google's acquisitions of Nest and Dropcam are the two which
| impacted me personally. Data ended up in the hands of people
| I didn't want, features were removed that I found essential.
| Perhaps others can volunteer their stories, I've largely
| opted out of IoT because of these experiences and concerns.
| SonOfLilit wrote:
| There are malicious actors in the business of buying popular
| App Store apps and introducing malware into updates.
| downrightmike wrote:
| Hopefully automatic updates by default gets in there, because no
| one is going to manually update nay of this
| wolverine876 wrote:
| I see the strong encouragement to post to the FCC's public
| comments, and you say it is highly influential - more influential
| than what you can do as a Commissioner.
|
| I'm a well-informed, active citizen, and I didn't realize that.
| It might help to explain how that works - how do public comments
| influence things? My concern would have been that it depends on
| the FCC, and that comments could be included or ignored as
| desired, and probably the latter. (I want to emphasize: That
| _would have been_ my concern had I not read this thread - I trust
| they are influential).
|
| Thank you!
| SimingtonFCC wrote:
| _It might help to explain how that works - how do public
| comments influence things?_
|
| The FCC conducts notice-and-comment rulemaking and is
| accountable to a public interest standard. Obviously the public
| interest can be hard to define, but at minimum, if reasonable
| comments on the record raise issues that we are clearly
| ignoring, this is likely to emerge in item debate, dissenting
| statements, and the press. In fact, the courts can go as far as
| overturning a rule if the FCC failed to adequately address
| arguments made on the record during the rulemaking process. A
| lot of our rulemaking is technical and not of general interest,
| but the public has the right to comment on all of it.
|
| In this particular case, I think the much of the relevant
| experience and expertise resides with the public more than the
| federal government. A lot of tech workers are very upset with
| the current state of IoT security and with the US Government's
| actions or lack thereof, so if we get a lot of comments on the
| records about specifics, those will be hard to brush off.
|
| Link for general reference: https://www.fcc.gov/about-
| fcc/rulemaking-process
| projectazorian wrote:
| Although I don't have much to add on the specific topic here, I
| wanted to applaud you for coming to this community for
| consultation. If we want to see better regulation of our
| industry, this is exactly the sort of thing we need to see more
| of. (As opposed to dusty formal public comment processes easily
| gamed by rent-seekers.)
| mike_hearn wrote:
| As someone with a libertarian bent, meaningful labels appeal to
| me as a decent way to address problems without overriding the
| judgement of the market. An informed market avoids lemons. So
| this proposal sounds OK in principle but here are some questions.
| Please be aware that I'm not a US citizen so my views don't
| really matter here, I'm just looking over the garden fence and
| asking questions.
|
| 1. Your argument for why it's under the FCC's jurisdiction
| doesn't seem all that strong. In your linked speech, you argue
| it's important because the FCC has the ability to regulate
| signals interference, and insecure devices could be turned into
| jammers. Has this ever actually happened? If not, is this not
| rather a large stretch of the FCC's mandate? Perhaps this sort of
| effort belongs in a different part of the government, or in an
| international standards agreement (possibly non-governmental).
|
| 2. What's the definition of security you're using? Security
| problems always exist in the context of a threat model, so having
| a label would imply standardizing a threat model. For example,
| smartphone security systems were originally designed to block
| malware, but over time have been stretched to try and solve often
| vaguely specified privacy goals towards non-malicious software
| too. If someone commits to supporting security updates for five
| or ten years at risk of government censure, then the definition
| of security is going to become a battlefield because whoever wins
| gets to control all the software that's got this label.
|
| 3. Modern security is layered via defense-in-depth strategies. If
| there's a bug in an inner layer but it's not exploitable due to
| mitigations or sandboxes (software firewalls) in outer layers, is
| that a mandatory security update or not? It could be argued
| either way because the device is not technically hackable still,
| simply the armor became weaker. Today this is left to the best
| judgement of engineers, who must balance efforts to patch
| theoretical vulns in old devices with work to e.g. build new
| defenses for newer devices. If it becomes mandatory, then
| paradoxically, new devices may become less secure than they
| otherwise could have been because all the effort is going into
| patching old devices.
|
| 4. Imagine a company commits to security updates for all devices
| for 10 years, but after 5 gets into financial difficulties. Maybe
| due to competitors who didn't make that expensive commitment. One
| quick way to dig themselves out of this hole is to push a
| 'security update' that drastically restricts the device's
| functionality e.g. prevents it from installing new apps released
| after a certain date. This can be indeed argued to make the
| device more secure, and you can argue that there's no expectation
| that the device will always be able to install new apps anyway,
| so no end-user expectations or promises have been violated. How
| would you stop this kind of perverse incentive?
| wolverine876 wrote:
| > An informed market avoids lemons.
|
| Has that been true in practice? I can think of plenty of
| horrible products, in IT, on the market. In terms of security
| (including privacy), the market has done nothing for IT
| consumers. And what about the people who already bought the
| lemons, before the market learned of it? Also, what if the
| lemon doesn't affect me but affects others (such as through
| DDoS)?
|
| I prefer to keep it as simple as possible, but no simpler.
| mike_hearn wrote:
| Nothing? Hasn't Apple built a part of their brand upon
| security and privacy?
| hsbauauvhabzb wrote:
| I'll preface this with the fact that I am a security engineer
| ('penetration tester') but I probably don't live in your country.
|
| I care more about my privacy than I do about the security of my
| device, but an architecture that supports the second almost
| always supports the first (my neighbours hacking my zigbee isn't
| a threat model almost anyone should be concerned about, unless
| there's a pattern of hacking en masse).
|
| I found out my smart lights literally have a microphone in them
| the other day, under the guise of 'plays light to your music' or
| something.
|
| I architect my IOT by implementing a network without internet,
| fronted by home assistant - that way my devices can't 'phone
| home' which who knows what privacy infringing crap.
|
| I know that botnets driven by iot is a real and ongoing problem,
| but it's a problem that is probably not going to get much vendor
| buyin without regulation, but what I'm pointing out is that it's
| not the only threat facing these devices.
|
| I want:
|
| - clear guides on what data is collected, I don't trust they'd
| only use it the way they say they will so I wouldn't bother
| reading that part, if it existed
|
| - the ability to opt out of any data collection aside from
| anything required to do technical updates. I want any data
| transfer to occur in a clear and auditable way (e.g the ability
| to inject a root CA and perform a mitm if I wish)
|
| - enough protocol spec that at least basic functions can work
| offline via a system like home assistant
|
| These won't directly solve the ddos vectors, but they will solve
| the problems that come shortly after on the timeline.
| fdschoeneman wrote:
| I appreciate you for coming to this form and soliciting input.
| There are a lot of smart people here and they're likely to have
| good opinions.
|
| My own opinion, though, is that regulations like this should only
| be written when no reasonable alternative to them exists and as a
| last resort. And I think there is still plenty of room and time
| for industry to come up with its own certification programs, kind
| of like organic certifications in food. What actions have you
| taken or do you plan to take to encourage industry to take care
| of this without being forced to at the point of a gun?
| khiqxj wrote:
| Here's what needs to happen:
|
| The tech industry is not ready for pervasive internet enabled
| devices that have microphones, cameras, or control heavy
| machinery. It all needs to be taken out. Aside from the threat to
| human life (due to malfunctioning vehicle software), we're
| heading straight for a dystopia where you can get arrested for
| walking down the street and committing a thought crime because
| every house will have cameras facing the street hooked into some
| company like Amazon that will simply be commandeered by the
| government to "fight crime because if you aren't giving us access
| to your camera you aren't against crime".
|
| I don't know what legal movements this needs, it has to be
| something that doesn't backfire. The obvious thing to do is just
| ban Amazon from selling products like Ring, and remove software
| and radio communication from home appliances and vehicles.
| Software in a television shouldn't be legal. It has environmental
| consequences too not just privacy (which right now is a problem
| since every TV just scans what your watching and reports back to
| the company.
| prognu wrote:
| Simple. Give the manufacturers the choice: either they must
| provide full (FLOSS) source code and documentation (full
| schematics) to the user to enable them to maintain, patch and
| thus secure their devices (see also: right to repair), OR they
| are liable for all damages (direct, indirect) for a 30 year
| expected lifetime that arise from security issues with the device
| AND must have insurance to cover those damages (so that they
| cannot get out of that liability by bankruptcy). Most will opt
| for FLOSS, and none will have the excuse that it would be more
| secure to make it proprietary. And then users will at least be
| able to fix issues -- and the security community will be way more
| effective at finding issues as it wouldn't have to do the slow
| reverse engineering.
| wiremine wrote:
| > either they must provide full (FLOSS) source code and
| documentation
|
| I like the spirit of this, but one problem with this is that
| the software stack is likely not FLOSS, and the manufacturers
| don't own all the software.
|
| A second problem is that lot of the software for production
| IoT-devices doesn't live in the device.
|
| Third, there are safety concerns with a lot of devices that
| you'd need legal productions for.
|
| Finally, the best IoT devices use a zero-trust architecture.
| You'd need to support a variation of this pattern to allow
| users to modify the devices.
| ndriscoll wrote:
| If parts of the supply chain aren't FLOSS, then manufacturers
| would have to lean on those suppliers to change their
| licensing or find different suppliers. Same with other
| regulations around things like lead in consumer products.
| Anyone wanting to be part of consumer product software supply
| chains would have to start offering it as FLOSS if they want
| any customers, so the supply chain would adjust to the new
| reality.
|
| We do need to establish common sense liability if it's not
| already there. If you modify your circular saw to remove the
| guard and injure yourself, that's your fault. If you modify
| some software to run outside of safe design parameters and it
| malfunctions/injures you, that's your fault.
|
| I don't see why zero-trust is incompatible with user-modified
| devices. In fact it's in line with the spirit of zero-trust:
| don't assume just because something is able to talk to one of
| your servers (e.g. because it's on your VPN/LAN) that it's
| friendly. People should already always be assuming customer-
| owned hardware will potentially be completely controlled by a
| malicious actor and acting accordingly.
| joezydeco wrote:
| I'm working on an IoT device for industrial use, and we're
| wrestling with this very problem.
|
| The answer we're probably going to go with is that the device
| is 'leased' to the customer. It's part of their subscription.
|
| This solves a _ton_ of problems about FLOSS and support of
| the same. It 's now a closed device, and you have no rights
| to the code inside. If we go out of business, you have a
| brick that you don't have to pay for anymore.
| Kim_Bruning wrote:
| I think it's always better for the customer to have access
| to the code inside. I'll actively recommend FLOSS solutions
| to customers _even if_ they 're not quite as good as the
| competition on paper right away. Simply because a large
| part of the cost of industrial hardware is actually
| supporting it for a long time. And support is SO MUCH
| EASIER if you have all the source code and schematics. Of
| course big customers get to demand this kind of arrangement
| (floss, escrow, or even just "give us all the paper") while
| small industrial operations end up paying a premium for
| inferior service.
| rolph wrote:
| >> The answer we're probably going to go with is that the
| device is 'leased' to the customer. It's part of their
| subscription. <<
|
| 1000% wrong answer, unless you straight up front sell a
| service with an installer making a site visit to deploy
| chattels of service.
|
| such as satellite television, or DSL internet.
|
| when you swap handfulls over the counter before any
| contractual agreements i.e. clickthrough TOS , you are
| selling a hardware, that means user ownership.
| joezydeco wrote:
| No, we're straight up selling with a dealer/installer in
| the pipeline. We're not that stupid to try and sell
| direct to the customer these days.
| rolph wrote:
| i find that revealing, it seems direct enduser engagement
| has really stung you, is there something other than
| people being people, or are there onerous requirements
| that are not worth it?
| mcdonje wrote:
| ^^^ This right here ^^^
|
| Additionally, this cannot be an excuse to charge subscriptions
| or force lease agreements into the fine print for items
| consumers buy outright.
| rndmize wrote:
| I favor something like this, if less strong. It should be
| required that a product that reaches end-of-life as defined by
| the manufacturer should have all documentation and source code
| released and open sourced; prior to end-of-life (and perhaps
| for one year after), they're required to provide security
| updates. The manufacturer is then free to decide the point at
| which closed source is no longer worth the maintenance cost.
|
| A few additional thoughts:
|
| - Perhaps hardware design/specs should be released as well?
|
| - A government body should probably host this information after
| EOL.
| bestouff wrote:
| I love this.
| eru wrote:
| You as a customer can already give the manufacturer that
| choice, and simple refuse to buy from any manufacturer that
| doesn't comply.
| beardedmoose wrote:
| So what we need is giant warning stickers on products of
| which their parent companies don't follow good practices.
| Kind of like tobacco products.
|
| "Leaks your personal data to unknown servers" Or
| "Manufacturer typically does not support their products
| beyond 2 years after which critical features and functions
| may stop working"
| digging wrote:
| I've been not-buying IOT trash as hard as I can for decades.
| But nothing's changing... please tell me how to do this
| correctly!
| eru wrote:
| Well, lots of people have been not-buying liquorice their
| whole life, but nothing's changing. The market for
| liquorice candy is alive and well.
|
| Less snarky: if other people still want to buy certain
| products, manufacturers will provide. But that's not a bad
| thing. Different folks have different preferences.
| digging wrote:
| Why did you suggest not-buying as a better action than
| regulation if you acknowledge that it doesn't work? Are
| you a manufacturer of low-quality IoT devices? People
| don't _prefer_ insecure devices, they just want
| convenience and manufacturers are not being upfront about
| how dangerous these "convenient" devices are. Ergo,
| regulation.
| emiliobumachar wrote:
| Insecure IOT has the huge externality of providing muscle
| to criminal botnets, though.
| Bilal_io wrote:
| A relatively small group of people won't have an effect,
| that's why regulation plays an important role.
| eru wrote:
| Perhaps we should respect the wishes of the large rest of
| the people who are outside that relatively small group?
| Bilal_io wrote:
| Ignorance is not a wish. We're talking about users that
| don't know any better when buying products
| SkyMarshal wrote:
| Are there any that currently do comply?
| chromoblob wrote:
| Consumer's power is not the same as FCC's
| eru wrote:
| Indeed. And that's good.
| chromoblob wrote:
| It's good that consumers have much less power in context
| of forcing manufacturers to the described choice?
| guzik wrote:
| Ah, the utopian dream of a world where every manufacturer gives
| away their intellectual secrets just so users can play tech
| guru. You're suggesting that companies offer up decades of R&D
| and risk their competitive edge, or else face 30 years of
| liability? With the speed at which technology evolves, we're
| lucky if a device is even relevant after 30 months. And let's
| not forget the minor detail of skyrocketing costs. Want a
| device built under these fantasy rules? Hope you're ready to
| pay through the nose--think 10 times the current price. Because
| nothing says 'accessible technology' like pricing out the
| average consumer.
| parentheses wrote:
| 30 years of expected support is pretty unreasonable. Stating a
| requirement like this makes the discussion about competing
| dogmas. Rather, it's about the right way to keep devices
| operational as long as possible while also allowing companies
| to remain possible.
|
| 30 years of support expectations immediately makes the cost of
| any device go up to hedge against the risk of fines during the
| entire 30 years. It also makes it harder to disrupt an industry
| with hardware at its core.
|
| I don't have a single computing device that has lasted longer
| than 10 years. Reasonably speaking, either performance or
| features start to make the device largely obsolete and
| unusable.
|
| I think a better way to propose this would be the expectation
| that when a product is EOL, it should be supportable by the
| buyer for a certain period. This requires figuring out the
| right period of support. I'd propose something that scales
| period based on cost or device class. A $1200 phone should be
| usable for 10 years while a $10 disposable glucose sensor with
| a battery should not.
| Animats wrote:
| > 30 years of expected support is pretty unreasonable.
|
| I happen to know, having been with a Ford unit at the time,
| that the Ford EEC-IV engine control unit in 1980s Ford cars
| and trucks was designed for a 30 year lifetime. Many are
| still working.
|
| The _average_ age of light vehicles in the US is 12.2 years.
|
| This is more in NHTSA's wheelhouse, though.
| prognu wrote:
| Sorry, but some people will run routers (and other IoT
| devices) for > 10 years, and long past some random 2 year EOL
| a manufacturer may set. We need less e-waste, and if
| manufacturers have to warrant security for 30 years, they may
| also invest enough to make the hardware itself last longer.
| More expensive is totally fine if the product is useful for
| longer! Oh, and please double-check if you really have no 1st
| generation Raspberry PI anywhere, or maybe some ancient
| Arduino? What about your washer? Modern washers are IoT
| devices. My (admittedly not yet IoT washer) is > 10 years
| old. Or take your car. Sure, you may buy a new one every 10
| years, but there are plenty of cars > 10 years on the road.
| Do you want all of them to be vulnerable and out of warranty
| in the future?
| omniglottal wrote:
| Fundamentally, IoT security will increase in proportion to
| repairability and our. ability to modify/reflash IoT devices. No
| other change will have as great of an effect. If we (the people)
| cannot audit a thing, its obscurity will harbor vast troves of
| insecurities.
| Ericson2314 wrote:
| Aim to converge with the state-level right-to-repair down the
| road.
|
| If the manufacture _stops_ releasing updates, they need to make
| it clear how you can update the device yourself without
| compromising security.
| ilamont wrote:
| _commitments on this label (including the support period) will be
| legally enforceable in contract and tort lawsuits and under other
| laws._
|
| When it comes to U.S. laws that touch technology, enforceability
| is a mess. Spyware, spam, fraud, misleading labels, etc. are
| already governed by various state and federal laws, yet
| enforcement efforts are whack-a-mole at best.
|
| For IoT devices, having the proposed requirements sounds good in
| theory but I fear it is practically unenforceable, particularly
| for consumer-grade devices manufactured overseas.
|
| However, if powerful IoT platforms are also tied into the new
| regs - with Google, Amazon, Apple, Microsoft, PTC, HPE, etc.
| required to audit supposedly qualified devices and ban those that
| don't meet the standards, with escalating penalties for failing
| to do so - that might shift the needle.
|
| My 2 cents.
| AnimalMuppet wrote:
| Hmm, yeah. Just as fraud telemarketers set up a new shell run
| by the same principals when the legal bills come due for their
| old one, so we're likely to see new labels for a new shell
| company slapped on the same old insecure IoT box.
|
| So I'm not sure "escalating penalties" is going to cut it. It's
| still whack-a-mole. You need a way to kill the mole, not just
| drive it to pop up a new hole.
|
| You need a way to get to the principals. They're the mole.
|
| You need to either make them _personally_ liable financially,
| or you need to jail them. Nothing else is going to stop serial
| fraud-behind-a-shell-company.
|
| I'm not sure I have an answer. But whatever answer there is
| needs to be applied not only to fraud telemarketers ( _please_
| ), but _also_ to fraud IoT manufacturers /resellers.
| staticautomatic wrote:
| If there's a private right of action you can bet the class
| action lawyers will do the enforcing.
| dredmorbius wrote:
| Fair enough, but against whom?
|
| Fly-by-night foreign manufacturers or exporters would be
| difficult to prosecute. Unless the domestic importer,
| reseller, or transportation provider can be held liable, even
| class action lacks teeth.
| Gormo wrote:
| They're proposing an opt-in labeling program that essentially
| amounts for to the FCC underwriting certain attestations that
| vendors are choosing to make about their products.
|
| This means that someone applying the label without meeting the
| standards the label indicates would be guilty of exactly the
| sort of fraudulent advertising you're describing, and contract
| and tort law _are_ the relevant mechanisms of enforcement for
| this.
|
| I'm not sure what you mean by enforcement efforts being "whack-
| a-mole at best", but if you're expecting some sort of
| preemptive regulatory barrier to be enforced by a bureaucratic
| agency in advance, that's just not the way this sort of thing
| works or is intended to work, and the FCC certainly wouldn't
| have the legal authority to implement such a regime.
|
| Legal actions for fraud, false advertising, trademark
| infringement (in the case of trademarked standards
| certification badges, e.g. UL) are frequently used mechanisms
| for this sort of thing, and seem to work well enough to ensure
| that vendors are deterred from fraudulently applying
| certification labels to their products.
| SimingtonFCC wrote:
| Your point about buyers at scale is really important. The
| current effort is focused on sellers, but we think that if
| sellers have to define their security commitments, buyers will
| pay attention and their risk management people will insist on
| high standards.
|
| _I fear it is practically unenforceable, particularly for
| consumer-grade devices manufactured overseas_
|
| Also a good point. The way we handle this for RF interference
| is to look at distributors and importers, not just
| manufacturers, but there will probably always be an
| untrustworthy product tier out there.
| encyclic wrote:
| Planned or unplanned obsolescence is good for business. You are
| proposing regulations counter to that, so should expect counter-
| pressure, even for IoT makers that want to do the right thing.
|
| By volume and impact, what devices have IoT vulnerabilities? If
| from large mfrs, you might expect some measure of support as that
| would be somewhat in their best interest, if only to preserve
| their brand image. My concern would be low quality, usually
| cheaper, whack-a-mole mfrs that come and go on Amazon, eBay, etc.
| Even if they release a product that would fall under these
| guidelines, how are you going to go after a ghost?
|
| Also, what happens when an IoT mfr is acquired, does the acquirer
| assume all the IoT risks as well?
| SimingtonFCC wrote:
| _Planned or unplanned obsolescence is good for business. You
| are proposing regulations counter to that, so should expect
| counter-pressure, even for IoT makers that want to do the right
| thing._
|
| Great points. From one perspective, we can't afford to do this
| stuff; from another, we can't afford not to. If connectivity
| makes your life a little easier for little risk, that's one
| thing; if your dishwasher steals your identity and sells it
| online, that's another.
|
| _My concern would be low quality, usually cheaper, whack-a-
| mole mfrs that come and go on Amazon, eBay, etc. Even if they
| release a product that would fall under these guidelines, how
| are you going to go after a ghost?_
|
| Another great point, but that's a snapshot of the market as it
| is now. We expect certain standards from some things but not
| others, depending on how much you depend on them, how much is
| at risk, and what the costs would be. Right now, under the
| proposal, a company is 100% free to say "I will support this
| for 0 days and you expect it to ship broken from the factory"
| -- it's just that they actually have to say that out loud.
|
| _Also, what happens when an IoT mfr is acquired, does the
| acquirer assume all the IoT risks as well?_
|
| I expect this to be a hot topic on the record. We'll see what
| technologists, manufacturers, consumer advocates, etc. say and
| try to come up with a proposal addressing stated concerns.
| ncallaway wrote:
| > Also, what happens when an IoT mfr is acquired, does the
| acquirer assume all the IoT risks as well?
|
| Most other liabilities are inherited during an acquisition. I
| don't see a good reason for this to be an exception.
|
| It would encourage acquirer's to do much more strict due
| diligence in this regard, which will have a natural pressure
| to clean up the behavior of manufacturer's that plan to seek
| a future exit.
|
| Any exception to liability here seems like a get out of jail
| free card, for all new manufacturers seeking an exit to
| behave extremely badly. It also opens the door to corporate
| shell games, where as soon as a liability is discovered it
| gets acquired by a thin parent entity to dissolve that
| liability. I'll leave a comment to that effect as well, but
| it absolutely seems like this liability should survive an
| acquisition.
| zamalek wrote:
| I added a comment voicing support. I also added concerns about
| only being able to update devices through specific ecosystems. I
| use Home Assistant at home, and many devices will only update
| through the likes of Google Nest or Alexa - rendering them
| unsupported on day 1. I was lucky enough to know not to purchase
| devices that have this issue, but many home owners could find
| this out the hard way. Firmware should be available from a
| publicly accessible location.
| jcampbell1 wrote:
| I honestly don't think we need a government solution to this
| issue. Consumers who want this security can buy from
| manufacturers with a reputation at stake such as Amazon or Apple.
| I don't want your "help". Let the market sort it out.
| wolverine876 wrote:
| Consumers have no idea about security, the risks, the
| technology, how to evaluate it, or who to buy from. That is not
| a realistic solution.
|
| Consider food or automobile security: Should consumers somehow
| evaluate them? Check the wiring? Find out, at every restaurant
| and grocery, how long the food has been stored and where?
|
| IoT security has another issue: It can affect others more than
| the end user. If my IoT is DDoSing you, what will the market do
| about it?
| whats_a_quasar wrote:
| A required support period of some number of years is problematic
| for products developed by startups, because startups cannot
| guarantee that they will still exist to provide support in
| several years. They can have the best of intentions and excellent
| engineering, but still fail in the market and be unable to keep
| maintaining a device. So requiring security support for several
| years wouldn't have any effect on these devices, because the
| company will be gone and there won't be anyone to take an
| enforcement action against.
|
| For a labelling program for this type of company, you could
| require additional disclosure to consumers at the time of sale,
| along the lines of "We can't guarantee that we'll provide
| security updates." Or you could require open-sourcing of firmware
| if a company goes defunct. Or perhaps device manufacturers could
| be required to hand the technology of to some third party
| maintainer if they go under.
|
| Any regulation at end-of-support-life has the "company
| disappears" problem, so probably disclosure at time of sale is
| the only thing that could be reliably enforced.
| nikanj wrote:
| Any guarantees and warranties have the same caveat: if the
| company goes under, you got nobody left to sue. And there's no
| squeezing water from a rock anyway, a defunct company can't pay
| for the updates nor the damages
| smingo wrote:
| Totally valid point. Escrow then open sourced, or perhaps even
| some insurance policy so that the future patching and
| vulnerability remediation is guaranteed.
|
| There's a bunch of stuff consequential to EO 14028 which could
| allow for some automation of library vulnerability.
| whats_a_quasar wrote:
| I was trying to think of ways to finance it, and "future
| patch insurance" is clever! There are other sorts of business
| insurance where the insurer is liable even if the business no
| longer exists, so it would be doable. Though a policy would
| require a level of technical competency that other insurance
| policies don't, since their providing a guarantee of service
| rather than a guarantee to pay out a certain amount in
| damages.
| fidotron wrote:
| While the IoT security situation is out of control I doubt that
| regulating security updates will have any other result than
| radically reducing competition and innovation in the space by
| making it impossible to operate as a small company. It will
| simply push more hardware innovation out to China.
|
| Having worked in the space I came to the conclusion the only
| viable secure future is to adopt star topology local networks
| where local traffic for all devices goes into a single secure
| regularly updated broker device that then decides what to do with
| it. Any access out to the Internet or between devices needs to be
| mediated. The part that will annoy a lot of people is that broker
| device probably needs to be able to read all of it. Therefore
| rather than just regulation I would talk to the WiFi alliance in
| particular about possibly expanding the scope of what it means to
| be a WiFi router.
|
| The problem is actors like Google really want such a thing to be
| just in the cloud "for convenience", by which they mean
| monitoring everything that ever happens.
|
| The only corporate actors I encountered that understood this were
| the Taiwanese OEMs, who are remarkably on point and blunt behind
| closed doors, but they are basically powerless to do anything
| about it.
|
| Edit to add: if there is one thing the FCC could do immediately
| it would be to ban the covert deployment of cellular modems in
| other devices and to force giant warning labels for such things
| and require they be user removable.
| jaclaz wrote:
| >Having worked in the space I came to the conclusion the only
| viable secure future is to adopt star topology local networks
| where local traffic for all devices goes into a single secure
| regularly updated broker device that then decides what to do
| with it. Any access out to the Internet or between devices
| needs to be mediated.
|
| Yes, yours is (IMHO) the only possible way out, still there are
| things that simply should be not allowed or be only optional,
| as I see it the "mistake" is confounding the "Internet" in IoT
| with the "Cloud".
| eru wrote:
| > The only corporate actors I encountered that understood this
| were the Taiwanese OEMs, who are remarkably on point and blunt
| behind closed doors, but they are basically powerless to do
| anything about it.
|
| Fascinating! Could you elaborate?
| fidotron wrote:
| Firstly you have to appreciate the web isn't a thing. When
| they want to talk protocols and crypto they mean things like
| sockets, mqtt and talk about where on the production line the
| fuses for the keys will be blown and who will have access to
| that area. It is a different universe.
|
| The absolutely huge thing is they want to live in a world of
| standard interchangeable pieces. They despise custom
| solutions to problems unless totally necessary or they are
| enormously better than the alternatives.
|
| They will flat out tell you that they are essentially waiting
| for an industry standard solution to problem X to appear, and
| until it does these ad hoc solutions suck.
|
| If you want IoT security you don't need to regulate it, you
| "just" need to create a no-brainer to adopt industry standard
| model for device operation that these people can drop in
| place. (I hate MQTT, but think something in that ballpark
| with the right security model* would be a good starting
| point). This is a hard enough ask as is, but is made harder
| by the big software giants all trying to come up with schemes
| that put them in the middle all the time.
|
| As an aside I also encountered a non Taiwanese executive
| espousing the view (with respect to slurping up network
| topologies via multicast) that he hates it, but as long as it
| isn't illegal they have to do it. I don't believe the law
| would help as you will always have bad actors and people
| using aliexpress - it needs to be technically impossible,
| hence the star networks.
|
| Edit to add: * and provisioning process. Were it up to me I'd
| have something like NFC based key exchange between broker and
| device during setup as part of the standard.
| koliber wrote:
| The issue seems to be wider than just abandoning support on IoT.
| IoT device abandonment is a real problem, but you can aim higher.
| Software written for hardware is generally of poor quality.
|
| There is an insightful HackNews thread from three days ago about
| the subject. I hope it will add some more insight into the scope
| of the issue: https://news.ycombinator.com/item?id=37352970
|
| My 2 cents would be: treat software defects like hardware
| defects. Pass legislation to force manufacturers to provide a
| warranty for at least 2 years. Pass rules which favor the
| consumer ruthlessly. Button was not constrasty enough - refund.
| Text label caused the user to misinterpret the action - refund.
|
| Perhaps the additional accountability during the early days of a
| device will have a positive impact on the longer-term longevity.
| If prices are forced to go up a bit in order to provide better
| support, there will be more money for higher-quality software.
|
| Don't limit this to IoT devices. Manufacturers will find ways to
| skirt whatever way "IoT" gets defined. Make whatever rules you
| create apply very broadly to all devices with embedded software.
| b20000 wrote:
| How is a small business going to be able to pay for this? This
| will be something that big tech can do but not startups that are
| bootstrapped.
| guzik wrote:
| Valid point. Customers would then need to prepare for a new
| reality where their options are limited and potentially more
| expensive.
| b20000 wrote:
| right, and the small guy might offer you transparency and
| guarantee privacy while big tech won't.
| MarcoPerazaFCC wrote:
| This is being proposed as a completely voluntary program. No
| need to participate in it if you don't want an FCC
| cybersecurity label on your product.
| b20000 wrote:
| right, so then people will not buy your product because you
| don't have the label and you cannot afford to pay 10K-20K to
| some testing lab while vc backed startups or big tech can...
| so it takes away any chance for you as a small guy to compete
| in the market. no thanks.
| eternityforest wrote:
| My big concern is with devices being obsolete due to the cloud
| servers going down.
|
| I am all for high security IoT, but only if the requirements
| don't make it harder to use local-first APIs, and don't add too
| much cost to these devices, or stop small companies from making
| open source devices.
|
| In fact, I think I would even prefer that requirements do not
| apply at all unless the device communicates directly over the
| public internet, or over proprietary wireless networking, or
| where the device's failure could cause a safety hazard.
|
| I would not want to see anything get in the way of, say, making a
| cheap motion sensor that connects to WiFi and allows open access
| via the already-private WiFi network, or a BLE sensor tag that
| broadcasts open data.
|
| Not all devices need updates, or encrypted protocols.
| dang wrote:
| All: To read the entire thread, you'll need to click More at the
| bottom of the page, or like this:
|
| https://news.ycombinator.com/item?id=37392676&p=2
|
| https://news.ycombinator.com/item?id=37392676&p=3
| scrollaway wrote:
| What's your approach wrt. open source, and generally preventing
| security through obscurity?
| IAmPym wrote:
| I can't see this changing much if they water it down to a point
| where liability isn't an issue. If a company is weighing whether
| to put resources into a security update vs. roll the dice on
| whether they are used as an attack vector, where they will be
| sued and just declare bankruptcy, I don't think it would be
| effective.
|
| Doubly so if their products are still in use after the company
| goes under. Now who is liable? What protections can one create
| for this scenario?
|
| Most consumers will never file a lawsuit against such behavior
| because it is an incredibly uphill battle.
|
| I get the sense that regulation like this will just create a new
| goalpost that won't ultimately help consumers, we've seen it
| happen time and time again, but I don't have a better idea. I
| suspect if you tried to enact real change you'd get too much
| opposition.
|
| Tricky situation.
| MayeulC wrote:
| EU citizen here, but FCC regulations also apply to me indirectly
| :) Not sure if I am allowed to comment there.
|
| I echo the many voices here that do not connect their devices to
| the Internet. Of course, I am in the minority that attaches a
| great deal of importance to these questions, so my devices either
| run free software (Tasmota and Esphome are two main ones), or
| have no Internet access (currently with ZigBee, though I have
| also used Vlans and separate Wi-Fi access points). The only
| service accessible from the outside (not firewalled) is
| HomeAssistant.
|
| I can see manufacturers doing the same, with a direct line to
| their servers for controlling smart devices, but that's only as
| good as the manufacturer's cyber security practices, what if they
| are hacked?
|
| Reducing internet exposure to "gateways" (HomeAssistant) in my
| case distributes a bit the problem, but also reduces the number
| of devices that have to be maintained up-to-date, so this may be
| an interesting avenue, especially if manufacturers are pushed to
| include a dedicated "IoT VLAN" and SSID in every (Wi-Fi) router
| that makes it easy for every consumer to adopt a separate
| network.
|
| To summarize, here are the main elements that could help, in my
| opinion:
|
| * Ensure that every IoT device (often sensors and actuators) has
| basic functionality available even when completely offline
| (including during initial setup).
|
| * Ideally these bits of interaction should take place over a
| standardized interface (the Matter standard seems to fit this
| perfectly).
|
| * Maybe consider strongly incentivizing gateways instead of
| directly connecting IoT devices to the Internet, and hold these
| to higher security standards?
| vkaku wrote:
| I've dealt with this multiple times, so let me give my
| perspective.
|
| - It is hard for manufacturers to do this with small teams.
| Mostly because they do not always have good CI/CD or platforms
| available to keep being on top of vulnerabilities and so on and
| so forth.
|
| - Not all manufacturers write their own software and often
| contract it out to other experts in the field. This includes
| firmware and app developers.
|
| - If a manufacturer goes out of business or their website is
| hacked or whatever, the devices are going to send information to
| someone else, this is a big risk.
|
| - A lot of blast damage can be contained if home devices use
| local / MDNS based service discovery as opposed to Internet based
| services. Many services could then either choose to reply locally
| or sometimes relay to the Internet if users policies allow.
| Unless people want other people unlocking their doors through the
| Internet, and they explicitly say it, Internet connection can not
| be mandated.
|
| - If a producer goes out of business they should be forced to
| give out a signed firmware that disables the key checking, then
| they must put up their source code for any users who wish to
| build and flash it themselves.
|
| - Some of these will not be practical to get manufacturers to
| agree on. IP issues will arise. Following decent open protocols
| for firmware upgrade and sharing platform specific specs can
| alleviate this. One should be able to re implement open firmware
| for their bulbs if everything else shuts down.
| MarcoPerazaFCC wrote:
| These are all great points and maybe a good reason why a
| voluntary program like this is the way to start, so a higher-
| tier of secure products can begin to emerge. We would also love
| to see the emergence of platforms that allow small teams to
| build on top of a secure, update-ready base. Some interesting
| discussion here https://news.ycombinator.com/item?id=37394546
| tremon wrote:
| > It is hard for manufacturers to do this with small teams.
| Mostly because they do not always have good CI/CD or platforms
| available to keep being on top of vulnerabilities and so on and
| so forth.
|
| "It is hard for hospitals to keep their ORs clean with small
| teams. Mostly because they do not always have good cleaning
| products or procedures available to keep being on top of
| contaminations and so forth". I do not believe this is a valid
| argument to protect small firms.
|
| > Not all manufacturers write their own software and often
| contract it out
|
| Two words: liability chain. This is standard practice in almost
| every other industry.
|
| I agree with the rest of your points, but I do not think that
| IP protections should trump regulatory requirements: if a
| company cannot comply with certain requirements due to
| contracts with their suppliers, the device should not be
| allowed on the market.
| Robotbeat wrote:
| Liability chain in many industries is a fantastic way to
| build a large legal moat to prevent competition from small
| players.
|
| The goal of any regulatory agency must be to ensure as much
| safety as can be done while preserving the ability of small
| players to enter the field and compete & while keeping the
| costs low for consumers. Otherwise, safety becomes a
| rationale that larger corporations are excellent at spinning
| to justify more regulatory moats.
| Etheryte wrote:
| If your team is not large enough to meet the required standards
| then you need to get a bigger team, not ask everyone else to
| forget the standards. You could make the same point about
| taxes, radio frequency use, etc. This is a non-argument.
| bewaretheirs wrote:
| > If a producer goes out of business they should be forced to
| give out a signed firmware that disables the key checking, then
| they must put up their source code for any users who wish to
| build and flash it themselves.
|
| Requiring an organization to do even a small amount of
| engineering as it is going under is simply not going to work in
| practice.
|
| IMHO the only possible way for something like this to work is
| to require vendors to upload buildable firmware source into a
| third-party escrow system before you can ship devices to
| customers.
| AnthonyMouse wrote:
| Escrow doesn't really work either. You have the original
| code, but do you have the signing key? Is it still the
| correct signing key, or has an update rotated it without
| putting the new one in escrow? Are there different versions
| of the hardware that need different firmware?
|
| The only way to know that it works is to let people install
| custom firmware from day one, so they can discover if they
| can't and raise their objections before the company is
| defunct.
| MetaWhirledPeas wrote:
| > - A lot of blast damage can be contained if home devices use
| local / MDNS based service discovery as opposed to Internet
| based services. Many services could then either choose to reply
| locally or sometimes relay to the Internet if users policies
| allow. Unless people want other people unlocking their doors
| through the Internet, and they explicitly say it, Internet
| connection can not be mandated.
|
| Networking ignoramus here. Are you suggesting the device could
| be prohibited from accessing the internet directly, and would
| be required to relay through a separate device (presumably with
| better security assurances)? Because that sounds like a good
| idea.
|
| Are there off-the-shelf firewall (or whatever) products that do
| this already? Quarantine the IoT devices and limit them to
| whitelisted, curated endpoints?
| trelane wrote:
| 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 period
| of no updates or insecurity, but a blanket requirement is less
| susceptible to games.
|
| Probably the best thing to happen to wireless routers is OpenWRT
| and the other descendents of the WRT firmware.
| caust1c wrote:
| 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.
| ics wrote:
| 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.
| fidotron wrote:
| The problem here is the government can't be trusted with the
| signing keys. They will simply use them to deploy their
| botnets.
| dredmorbius wrote:
| A challenge to this sort of suggestion is that the device OEM
| rarely controls _all_ the software which goes into a device.
| There are third-party modules, hardware drivers, and more,
| which are also components. Then there are patents.
|
| Either the escrow would have to apply to _all_ software on
| the device, regardless of whether owned by the OEM or third
| parties, or OEMs would be required to vouch for all the
| included software.
|
| I'd prefer the former myself: multiple software and patent
| assets can be combined, but on support EOL, all those become
| public domain.
|
| Build / release / update toolchains must _also_ be included.
| bick_nyers wrote:
| 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.
| punnerud wrote:
| Classic tech to think of technical solutions to a
| regulatory problem, but I like it.
|
| Could have the code run in a sandbox where people can apply
| "external" network traffic trying to hack it (or apply
| vulnerabilities), inspired by how you can run ML models on
| kaggle.org on Kaggle servers to validate models.
|
| Have end-points as honney-pots, so if you can access these
| endpoint you prove you have compromised the code.
|
| If there is no new code with patches the keys are released.
|
| This way FCC/gov don't need to maintain a technical system.
| Just build this once.
| ics wrote:
| 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.
| [deleted]
| agloe_dreams wrote:
| So this feels like an amazing idea...but do we really want to
| give the federal government the keys to update your equipment
| remotely and to be able to pinpoint weaknesses of the source?
| This feels like Edward Snowden's grimmest nightmare.
| Xelynega wrote:
| As I understand that's not what's being proposed. The
| "keys" in this case would decrypt the encrypted source code
| that's available in a public repository, and there's some
| logical mechanism(and actual use for smart contracts) that
| would key the key in escrow until certain conditions are
| met(company doesn't renew, goes out of business, etc.)
| After which it will be publicly released so anyone can
| decrypt the already available encrypted source code
| kristianbrigman wrote:
| And what happens if the server holding the keys gets
| compromised? I guess most manufacturers won't care, but
| the more reputable ones would have things in their source
| they consider proprietary and would definitely not want
| to have to submit it.
|
| Verification that it is, in fact, the actual shipped
| source might not be trivial either.
| ics wrote:
| Framed like that, it sounds terrible. However, consider
| this:
|
| [1] This discussion is about a federal agency providing
| certification of products essentially in the form of a
| _stamp_ (on a device, website, etc.). Nothing is stopping a
| vendor from committing to and offering the same thing but
| without government involvement. This could easily be a
| selling point for the paranoid. Something something
| blockchain and smart contracts...
|
| [2] Even though we're discussing IoT devices, it's not
| necessary that they be capable of updating over the air
| 24/7. Creative engineers could probably devise a method to
| prevent complete remote takeover by anyone holding the
| keys- physical switches, additional authentication required
| during the support period, etc.
|
| [3] Personally, I think the federal government getting
| access to keys for any IoT device made/sold in the US is
| the only part of this idea that could already be happening.
| They can knock on doors or mail subpoenas, plant moles,
| etc. I would be much more comfortable with a technical
| solution on the physical device than any presumption of
| privacy in the current state.
| unintendedcons wrote:
| I like this idea! A code&keys escrow org, yes please
| MayeulC wrote:
| I have been thinking that something along these lines should
| apply to most embedded systems, from mobile phones to game
| consoles to IoT devices. And more, for cases when companies
| go under: industrial control automation, etc.
|
| However, it's very hard to police: what if the company only
| provides a header file or so? Or the basic OS but not the UI?
|
| Moreover, what counts as "support"? There have been cases
| where companies refuse to consider remote code execution a
| "security issue". What's to prevent token updates that let
| the company claim a product is supported while it's riddled
| with holes?
|
| I could also see companies fighting teeth and nails against
| this if their devices share a common software base. But hey,
| you have your support incentive right there!
| ChrisCinelli wrote:
| 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.
| petsfed wrote:
| There is absolutely no scenario where I want the firmware of
| any of my infrastructure devices updating without my say so.
| Even if there are dire security consequences of _not_
| updating.
|
| If a firmware update on my smart watch bricks it, who cares?
| But if my entire house/office is without internet connection
| because of a bug in the router update, then I don't want to
| waste time determining if its my ISP, my physical connection,
| my local hardware, or the firmware update that just occurred
| silently. I want to send the "update" command, note that
| network response did not resume within 5 minutes, and revert
| from there.
|
| A lot of folks tend to think of firmware updates as identical
| in complexity and risk to any other software update. I submit
| that if it can't go wrong in such a way that it requires an
| in-system-programmer to fix, its a software update, not a
| firmware update.
|
| In that sense, I think true firmware updates (e.g. BIOS
| updates and the like) require a different set of regulations
| than your standard IoT security updates.
| abwizz wrote:
| 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
| adventured wrote:
| > 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.
| ChrisCinelli wrote:
| I am not clear how "all the points you brought forward also
| apply to the manufacturer firmware"
| the4anoni wrote:
| As far as I remember FCC about 8 years ago didn't liked
| OpenWRT, and even enforced on TP Link to lock it.
| SoftTalker wrote:
| 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 wrote:
| 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/s
| t...
| 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 wrote:
| 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-...
| codedokode wrote:
| So Linux takes government's side, not user's?
| pgeorgi wrote:
| 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.
| RF_Savage wrote:
| 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.
| dtaht wrote:
| 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
|
| 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/
|
| 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...
| tzs wrote:
| 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 wrote:
| 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.
| tzs wrote:
| People were asking online for help dealing with WiFi
| interference, and were getting answers telling them how
| to install open source firmware on their WiFi routers,
| and giving them exact commands and configuration changes
| that would set the power higher than was legally allowed
| or stop them from avoiding channels that were being used
| by active weather radar (5 GHz WiFi shares channels with
| weather radar and is supposed to monitor and only use
| those channels when the radar is not in use).
|
| I suppose you could call that accidental radio pollution,
| because most of the people doing it probably didn't
| realize that they were causing interference, but
| regardless it was becoming a problem.
|
| Hence regulations to address it.
|
| That's the world we're in now. You have a problem, you do
| a search online for help, and among the answers you often
| will find some that really should only be used by people
| with more experience or expertise than you but do not
| make that clear.
| zamadatix wrote:
| 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 wrote:
| 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).
| hannob wrote:
| I am all for alternative free software firmware. But I don't
| think it adresses IoT security in any meaningful way.
| nextnewaccount wrote:
| [flagged]
| weberer wrote:
| It allows users to replace insecure software with secure
| software. And it allows updates long after the company drops
| official support of the device.
| hannob wrote:
| That's great for the 0,1% of users who will do that. As
| said: I'm all for it. But the problem is the other 99,9%.
| fallingknife wrote:
| Seriously. I'm a SWE and I would throw out a TV and get a
| new one before spending hours minimum figuring out how to
| switch the firmware to a open source version.
| weberer wrote:
| Because right now we have to actually perform some
| exploit to run custom firmware most of the time. What if
| there were just a toggle in the settings menu for which
| repo to look at?
| CameronNemo wrote:
| 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 wrote:
| 99% of users don't know their iot devices have firmware nor
| that it can be updated.
| computerfriend wrote:
| Maybe that figure would change if the firmware could
| indeed be updated.
| NegativeK wrote:
| 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 wrote:
| Users update their phones, there's no reason they can't
| be educated to update their other devices
| NegativeK wrote:
| 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.
| CameronNemo wrote:
| They may have trusted family members, friends, or
| neighbors who they feel comfortable allowing the
| management of their internet connected devices.
| charcircuit wrote:
| No. As long as their iot device is still working
| consumers could care less about security updates.
| CameronNemo wrote:
| What do you mean by "no"? Are you denying the existence
| of my grandparents who trust me to manage their devices?
| charcircuit wrote:
| I am saying that people like you are not enough to help
| the 99% of people who have an iot product.
| CameronNemo wrote:
| Apart from Smart TVs, most people don't have an IoT
| device to begin with.
| i_am_jl wrote:
| Smart speakers, printers, thermostats, light bulbs,
| security cameras, door bells, locks, smartwatches, TV
| sticks...
| navigate8310 wrote:
| This approach may function effectively with your close
| family members. However, it can sometimes fail when your
| cousins won't let you near their IoT devices because they
| view you as the hacker or tech enthusiast who might
| tamper with their gadgets.
| CameronNemo wrote:
| So what? Just because there are some atypical people
| doesn't make it a "no".
| michaelt wrote:
| Free software firmware would be great for free software
| lovers and tech experts, no doubt. But sophisticated users
| who'll take advantage of things like that are only 1% of
| the market.
|
| But if the aim is to stop DDOSes from botnets of poorly
| secured IOT devices, we need something to help the other
| 99% of the market.
| trelane wrote:
| > But sophisticated users who'll take advantage of things
| like that are only 1% of the market.
|
| Most folks can't or won't do lots of things in their
| lives (e.g. plumbing, electrical, construction, lawn
| services, Automotive).
|
| The main thing blocking routers and IoT devices is the
| control every vendor wants to hold over their customers'
| devices _after sale._
| i_am_jl wrote:
| Even if you give control to the users, it's up to them to
| use it.
|
| I'd argue that the main blocker to IoT security is the
| lack of culpability on the part of device manufacturers.
| I don't want to go so far as to suggest that companies
| should be wholly liable for software bugs, but
| vulnerabilities that are brought to the attention of the
| company privately or disclosed publicly absolutely should
| be their responsibility to address.
|
| For you or me (or most of the folks here I suspect) we
| feel better if we had the ability to decide what software
| our fridge runs, but for 99% of people they're better off
| if their fridge's manufacturer provides them with regular
| security updates for the life of their product.
|
| That being said, these aren't mutually exclusive. In a
| perfect world we'd have laws compelling fridge companies
| to allow 3rd party software if they don't keep their
| firmware up to date.
| i_am_jl wrote:
| I'm sure the number of routers running OpenWRT is _dwarfed_
| by the number of OpenWRT-compatible routers running
| vulnerable, stock firmware.
|
| Allowing people to install software on their hardware isn't
| a cure for vulnerabilities. It's a step in the right
| direction for sure, but it's a very small one from the
| perspective of something as huge as "IoT security".
| dtaht wrote:
| We have worked very hard in the OpenWrt and Linux
| projects to make it easy to update them in the field.
| Linux distros, android, apple, openwrt, etc have this
| facility built in now. IoT should also.
| i_am_jl wrote:
| Devices should have the ability to run whatever software
| the user chooses. My point is that simply allowing this
| isn't enough to ensure those devices are secure.
| sroussey wrote:
| The solution without free firmware (and I don't like this)
| is that the device bricks itself at the end of its
| scheduled lifetime.
|
| Which is to say, you are buying a multi-year lease up
| front. And the manufacturer should send you a recycling
| return box.
|
| This is a more _honest_ way to sell these devices.
|
| Consumers that would not care about length of security
| updates will suddenly very much care how long their "lease"
| is... and manufacturers would compete on the length of that
| lease (which is where the FCC could require security
| updates for the length of the lease period).
| yjftsjthsd-h wrote:
| That just forces e-waste. Aftermarket firmware lets a
| device stay useful indefinitely.
| dtaht wrote:
| Agreed. I fully expect to see the routers we used in the
| cerowrt project from 2008 still operational for 10-20
| more years. Theres one out there with 4+ years of
| _uptime_ that I know of.
|
| https://blog.cerowrt.org/post/an_upgrade_in_place/
| notatoad wrote:
| replacing the firmware _can_ allow knowledgeable users who
| want to secure their devices to improve the security. it
| can also allow malicious actors to replace the firmware (or
| trick users into replacing the firmware) with something
| less secure. allowing users to replace the software on the
| hardware they own is _also_ a botnet waiting to happen.
| MarcoPerazaFCC wrote:
| 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.
| [deleted]
| basch wrote:
| 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.
| entropyie wrote:
| 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 wrote:
| At rotary phones still compatible with todays standards? If
| that's the case I might get one too.
| dpifke wrote:
| 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.)
| treyd wrote:
| 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.
| 1000100_1000101 wrote:
| Releasing Signing keys seems a potentially dangerous one.
| Someone could produce malicious firmware, sign it, and
| convince your device to auto-update with it.
|
| I think (and I'm a security know-nothing, so could very
| well be off in the weeds), the firmware should accept
| updates signed with two keys. The manufacturer key, which
| can allow automatic updates, and a post-service key that
| cannot be automatic. Either a user has to initiate the
| firmware update manually, or consent via some other means.
|
| This post-service firmware may very well enable a third key
| for automatic updates of its own, so there's just a manual
| step on the transition from manufacturer to some community
| project you support, not each revision afterwards.
| treyd wrote:
| Presumably they'd remove the auto-update functionality
| before releasing signing keys and require that it be
| physically loaded by a user at that point.
| Ajedi32 wrote:
| 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.
| Finnucane wrote:
| 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.
| alexfromapex wrote:
| This is a great idea. The Philips Hue hub situation is a great
| case study that many are probably familiar with where the support
| ended for the first version of the IoT hub much sooner than many
| consumers were expecting. It's like a more acute and malicious
| form of planned obsolescence.
| delfinom wrote:
| Here's a thought. Your proposal is really to create an FCC
| Cybersecurity label, but why does it matter?
|
| For a long time in the US since the 1960s, we had the private
| industry UL and their trademarked seal they enforced. The
| standards were quite rigorous and in response to many residential
| and commercial accidents, fires, and more. The problem is over
| time, the industry created ETL/Intertek to compete because of
| cost. They claim to be another standards testing body like UL but
| their actual standards are quite loose and verification looser.
| Now in 2023? Nobody cares anymore.
|
| You have Amazon selling literal fire hazards for electrical
| equipment that no brick and mortar retailer in their right mind
| will sell without UL or ETL certification. The CPSC barely is
| able to make Amazon take down products, and the flood is immense.
|
| I just don't see how a voluntary label will solve anything.
| jcpham2 wrote:
| Unfortunately ever since Ajit Pai dropped that net neutrality
| Harlem Shake video the same day him and his cronies snuck that
| legislation through - well let's just say it's difficult to trust
| or believe a person who speaks on behalf of the FCC, a three
| letter agency that was bought and paid for long ago.
|
| It's like trusting the SEC to do well, anything.
|
| I have a suspicion that you're more beholden to your lobbying
| constituents than you are to random HN commentators. I can only
| hope I'm wrong.
| coldpie wrote:
| He's one of the Republican FCC Commissioners, so yes, you can
| safely assume he's using the role primarily to work against
| most Americans' interests in favor of corporate executives,
| just as Pai did. However, I don't see that obviously being the
| case in this particular discussion, so I think it's OK to stay
| on topic.
| cannedbeets wrote:
| The single biggest problem with IoT devices is the black box,
| vendor-specific cloud platform nature. This causes privacy issues
| galore as well as requiring every manufacturer to reinvent the
| wheel to secure their devices, while also making huge quantities
| of ewaste when Random Manufacturer #484 goes out of business,
| taking their cloud with them.
|
| How about instead, mandating that all IoT devices need to comply
| with an open standard? Customers would be free to connect their
| device to Siri or Alexa if they wanted, but by default the device
| just works with an open standard that you can control fully,
| hosted at home if desired.
|
| It would also remove the cloud security onus from the
| manufacturer--they would fund the standards org, which would be
| responsible for the security of the interface.
|
| We already have this concept for electricity, phones, networking.
| You don't buy a "MA Bell" phone anymore or an "Edison-compatible"
| fan.
| Sparkyte wrote:
| I will need to read more about this over time. How does this
| effect Fedramp based stuff?
|
| I think FCC needs to step in on other things too. For one I think
| digital scalping has gotten out of hand. Something needs to be
| done to protect users and consumers. I think we need regulation
| on this matter. People use bots to buy up tickets or products and
| resell. The difficult part is how to enforce and prevent
| scalping.
| myself248 wrote:
| Speaking as someone who has several cheap cameras gathering dust
| in a box because I no longer trust them with network access...
|
| ...manufacturers are simply never going to be incentivized to
| take security seriously. The best you can hope for with a
| regulatory approach is to incentivize them to pay more lip-
| service to the idea, while hiding their backdoors better. Their
| incentive to spy on users is simply too profitable.
|
| (And, the legal environment is such that users can simply click-
| wrap away literally anything. If the terms say you agree to let
| the manufacturer monitor your conversations, guess what, it's no
| longer spying. Perhaps any such language, in the built-in
| firmware OR IN ASSOCIATED APPS, should immediately make a device
| ineligible for a favorable label.)
|
| Only users ourselves, actually have users' interests at heart.
| The only meaningful improvements in security that I've ever seen
| in the wild, have been with open-source firmware that completely
| replaces the device's own. Not a shim on top that adds
| functionality while preserving the OEM's backdoors, but a
| complete ground-up replacement.
|
| Therefore, the most meaningful step would be to require support
| for open-source firmware. Providing all the data such that open-
| source drivers can be written, providing a working build-
| environment, and making it easy to install user-provided
| firmware, would go a long way.
|
| Then once the device is fully supported in the mainline distro of
| a mainstream FOSS project, its label could indicate that support
| may extend beyond the manufacturer's whims or even existence. And
| since the label wants to be affixed at time of sale, the
| incentive is on the manufacturer to get this support work done
| before they even ship.
|
| Also, require a meaningful cybersecurity response. That is, they
| have a disclosure contact, they work with researchers to fix
| vulnerabilities under standard timelines, they pay bounties that
| make it worth researchers' time rather than incentivizing them to
| sell their vulns, and they check related products for similar
| vulns rather than playing perpetual whack-a-mole.
| ncallaway wrote:
| > The best you can hope for with a regulatory approach is to
| incentivize them to pay more lip-service to the idea
|
| While I think this is true, there's also some benefit to
| getting the manufacturer's to pay lip-service to the idea.
|
| In that, it becomes part of the marketing and the sales of the
| device. Later, consumers can _attempt_ to hold manufacturer's
| feet to the fire with false advertising and other fraud class
| action lawsuits.
|
| It's really really not a good system, but even forcing a bit of
| lip-service is a marginal improvement over what we have now.
|
| > Therefore, the most meaningful step would be to require
| support for open-source firmware.
|
| I agree that it would absolutely be better, but it sounds like
| even this voluntary labeling program is the compromise that
| might be tolerated by the other members of the FCC. I'm
| guessing such a strong and effective program would be a non-
| starter with those members.
|
| Which, honestly, tells me a lot about the other members of the
| FCC, and whose interests they are seeking to serve.
| kevincox wrote:
| > Later, consumers can _attempt_ to hold manufacturer's feet
| to the fire with false advertising and other fraud class
| action lawsuits.
|
| I would hope that this becomes relatively simple at some
| point.
|
| 1. I have this box that says I get updates until 2025-01-01.
|
| 2. It is 2023-09-05.
|
| 3. I have applied all available security updates.
|
| 4. Vulnerability X is still exploitable and has been made
| public to the manufacturer for 4 months.
|
| 5. Get full refund for defective product.
|
| Obviously we are a long way from this. Especially 4 being
| hard to make a concrete rule for.
| MarcoPerazaFCC wrote:
| I think if the box says updates until the beginning of
| 2025, and they've stopped providing updates before then,
| you have a pretty good contract lawsuit against them. You'd
| have to show that their failure to issue a patch for four
| months constitutes a breach, but that is exactly the kind
| of thing that gets hashed out in lawsuits. You could even
| have a class action of all the owners suing the
| manufacturer. We think one of the great opportunities of
| this labeling program is to begin developing a caselaw of
| what it means to hold a manufacturer to the commitments on
| the label.
| ncallaway wrote:
| Yep, the labeling would enable exactly the kind of class-
| action false advertising/fraud lawsuits against companies
| that simply lie on the packaging.
|
| So companies would be forced to disclose their _actual_
| level of support, and risk consumers not wanting the
| product, lie on their disclosure and risk a significant
| class-action lawsuit, or improve their level of support.
|
| I would hope the market would tip us towards the latter
| scenario, but...we won't know unless we actually force
| disclosure of these things.
| SimingtonFCC wrote:
| _manufacturers are simply never going to be incentivized to
| take security seriously_
|
| I worry about this too, and it's one thing when it's a camera
| but another when it's a car, or electrical grid equipment, or
| chemical process controls, etc. You make a great point re
| clickwrap, and clearly clickwrapping your rights away should be
| something that we don't readily allow for a manufacturer
| receiving the federal benefit of a marketing label.
|
| It could be that even a top-tier label will turn out to be
| meaningless. That would mean that we'd need to have "harder"
| regulation or that people would start demanding dumb devices. I
| hope that industry will respond productively to this voluntary
| effort so that the public doesn't get harmed and we are able to
| benefit from the real advantages of connectivity that's also
| secure.
| ilc wrote:
| Maybe we need to approach it differently?
|
| There will always be an "End of Life" date. And there will always
| be a user using the product beyond it.
|
| So my question is: How do we make it safe?
|
| My first thought is a "deadman's switch". If a device doesn't get
| or see some form of a signal, it just stops updating and disables
| IOT features. If the user wishes it to come alive again, there's
| a button they can press to have it "Check for updates" if there
| are none, it tells the user it is at "End of Software Updates"
| and "Certain services will be disabled." etc.
|
| We can't stop the issue. We can decide what to do once a vendor
| decides to stop updating... and make sure that final revision is
| as safe as it can be. Preferably non-networked (including
| bluetooth etc).
| kxrm wrote:
| I am not a fan of this idea as it would only contribute to
| eWaste, but I think one aspect I can get onboard with is a
| clearly defined expiration for updates.
|
| I think we would be getting too far into the weeds to specify
| what "security updates" means as there will always be ways to
| work around the language, but the fact that a manufacturer will
| guarantee a certain expiration of updates would be better than
| where we are now. If a vulnerability is discovered before
| expiration, presumably it would give the market and consumers
| leverage to hold the manufacturer's feet to the fire.
|
| I think no nonsense update expiration dates is a very easy win.
|
| Bricking the device after expiration or if it can't communicate
| is just a non-starter for me. Many devices can find a second
| life if manufactures were incentivized to open their hardware
| vs close it. Under a brick after expiration scenario I worry
| manufactures will be incentivized to lock down or prevent
| tampering to avoid exposure to torts that this rule might open
| up.
| smif wrote:
| How would opening up the hardware solve the issue for the
| average consumer? Let's say the official update channel goes
| dead on your smart fridge, the company has gone out of
| business. What would happen in that scenario for the average
| consumer (not someone who posesses the skills or will to
| tinker around with the firmware and such)?
| kxrm wrote:
| My comment is more about not incentivizing locking down
| hardware vs incentivizing opening it up so I can't speak a
| lot to your questions.
|
| > How would opening up the hardware solve the issue for the
| average consumer?
|
| At the risk of going off-topic, what I will ask you is, why
| do you feel that opening hardware requires a consumer have
| special skills? I'd argue that open hardware wouldn't
| _have_ to limit adoption to those who possess the skills. I
| think requiring special skills is a bug because currently
| manufacturers don 't even consider the idea of a second
| life for products.
| smif wrote:
| I'm not saying that hardware shouldn't be open in some
| form or another (at least in a way that doesn't stifle
| innovation, maybe also taking another look at how the
| patent system works and such).
|
| I guess I'm just having trouble visualizing how this
| problem gets solved for the average joe consumer in a
| world where hypothetically the hardware is open. Who
| pushes the security patches out to the devices? All of
| that has a cost in terms of bandwidth, maintenance, etc.
| If it's a community effort, what happens when the device
| gets old enough where no one is really working on it
| anymore, no more community updates, people have moved on,
| etc. How does liability work in a world with community-
| driven updates? What happens if a buggy community update
| is pushed and the smart fridge malfunctions and causes a
| flood / damages? What about supply-chain attacks and
| such?
|
| I guess for the code-literate subset of consumers, they
| can just go to the github repo and see exactly what is
| changing and where, but for the non-code-literate
| consumers, how do they know what kind of updates they are
| getting from the community?
|
| What about a middle-ground option? Where towards the end-
| of-life for the product, you are asked a question if you
| want to switch to a different update channel than the
| manufacturer default, and if there is no response
| recorded after X amount of days or whatever, the device
| just bricks itself?
| ilc wrote:
| I don't want my TV to "expire". I want to be able to use it
| with a gumstick if I still like it!
|
| I think of IOT devices as a continuum:
|
| One one end, Alexa and friends, which is a brick without
| Amazon. Good luck fixing that in a real way.
|
| On the other, a washing machine. It'll wash clothes for 10-15
| years, just fine. It may only get security updates for 5...
| but who cares. So it can't tell me by app when my clothes are
| done, it is still very useful.
|
| TVs, Cars, etc... all fit on this line in a way.
|
| And remember: People will use these devices past their
| expiry. They will get rooted, and turned into botnets and
| other crap. We have to choose our evils. I merely want a safe
| device at the end. Regardless of how long or short it lives.
| kxrm wrote:
| > On the other, a washing machine. It'll wash clothes for
| 10-15 years, just fine. It may only get security updates
| for 5... but who cares. So it can't tell me by app when my
| clothes are done, it is still very useful.
|
| > TVs, Cars, etc... all fit on this line in a way.
|
| Sure but you are missing an entire category of devices that
| revolve around home automation. Think light switches,
| dimmers, faders, plugs and door bells. These types of
| devices have an interface but also need IoT to be useful
| but not necessarily the cloud. If I install something like
| this in a light panel, it seems a little odd to me to "kill
| the IoT" of the device. It loses tremendous value. Again
| think of the incentives. Should we be incentivizing
| manufacturers to create devices that can so easily be
| created that lose value that I may have invested in as a
| part of a renovation?
|
| Can we create/incentivize an ecosystem of IoT devices that
| can live without the manufacturer tying these devices to a
| cloud service or the Internet in general?
|
| Let's find ways to incentivize second lives vs another
| renovation 5 years from now when my light switches and
| outlets no longer get updates.
| ilc wrote:
| It is a continuum. Your light switches are close to the
| Alexa side of it alas.
|
| Yes, we should. But alas, the incentives run the exact
| reverse today. Today they get to monitor your usage of
| the lights, resell the data, etc.
|
| You are part of the product.
|
| OTOH: If I look at this as a vendor, where else where the
| light switch go for updates?
|
| I'd be VERY hesitant to direct wire any IOT device into
| my house, if I wasn't comfortable ripping it out in 6mo,
| when the company decides to desupport it and kill the
| app.
|
| For me this is a the exact opposite problem: I won't
| adopt until I know that these issues are ironed out, or I
| accept that the device is 100% disposable.
|
| There's cases where I can't avoid it, TVs, Cars, etc. It
| is pushed on me, like it or not. For those, I truly do
| want safe mode, so I can pick how it networks.
|
| To me this generation is lost. I accept that. It is sad.
| I want to win the NEXT one, or the one after. And only by
| making the life cycle EXPLICIT will we do that.
|
| When a customer goes into Home Depot and says "My
| lightswitch stopped working in 2 years, you got something
| that will live longer this time?" The problem is self
| solving.
| kevincox wrote:
| IMHO the biggest problem is that there is no end-of-life date
| made clear to the user. I think if the purchaser could clearly
| see the support lifetime on the box then they can make an
| informed decision. Maybe this model that costs 50% more but is
| supported for 10y rather than 2 is a better deal after all.
|
| I don't think we need to kill the device. Ideally it would
| somehow be made clear to the user when it drops out of support.
| But I would rather have the consumer informed and capable of
| making a decision than taking away their control to keep using
| the device.
| ilc wrote:
| I never said to kill it. I said to kill it's IOT
| functionality. There is a very big difference.
|
| Think of a washing machine. It'll still wash clothes... it
| may not ping the internet portal anymore, it isn't "safe".
| worthless443 wrote:
| Such a transparent and clear post, therefore first, Thank you!
| Based on my experience with propitiatory IoT devices and
| protocols, vendors seem to be kind of unwary when it comes to
| potential security vulnerabilities and exploits in their protocol
| or firmware of the devices. As I understand, it's now all on us
| consumers to deliberately report insights to regulatory
| authorities and respective lawyers and hope everything comes
| together.
| b20000 wrote:
| I don't understand how cybersecurity falls within the
| responsibility of the FCC. I thought the FCC dealt with
| protecting the radio frequency spectrum.
| 2OEH8eoCRo0 wrote:
| If a known vulnerability in an IoT device is exploited for harm
| then the device manufacturer should be liable.
|
| Right now there is no penalty for firing and forgetting half-
| baked IoT products onto the market.
| superkuh wrote:
| I guess the one thing I can hope you consider is that not
| everyone or everything is a for-profit company and you should
| leave open source and individual human developers out of these
| coercing regulations and only apply them to incorporated entities
| that exchange products for money.
|
| The idea of a random human being forced to keep writing software
| via the threat of being sued is incompatible with human freedom
| and in that context would be far worse than the problem it
| "fixes".
| ChrisCinelli wrote:
| Regulation seldom proves to be the ultimate remedy.
|
| The true catalyst for change lies in cultivating informed
| consumers who wield their purchasing power to support
| manufacturers committed to security.
|
| If a law has to be put in place, ensure that every marketing
| advertisement and article concerning a device explicitly states
| the duration for which it will receive regular updates.
| SimingtonFCC wrote:
| Thank you so much everyone for the interesting, high-quality
| discussion so far. My team and I are looking forward to
| continuing to engage with you for at least a few more hours.
|
| Just a reminder: As fun as discussing this in here with you is,
| the best way to influence what the FCC ends up doing is to file
| an official comment by September 25th at
| https://www.fcc.gov/ecfs/search/docket-detail/23-239 . Click to
| file either an 'express' comment (type into a textbox) or a
| 'standard' comment (upload a PDF). The FCC is required to address
| your arguments when it issues its final rules. All options are on
| the table, so don't hold back, but do make your arguments as
| clear as possible so even lawyers can understand them. If you
| have a qualification (line of work, special degree, years of
| experience, etc.) that would bolster the credibility of your
| official comment, be sure to mention that, but the only necessary
| qualification is being an interested member of the public.
|
| Finally, I'd like to extend a special thanks to dang and the rest
| of the HN team for their help putting this together. They have
| been a pleasure to work with.
| natch wrote:
| I went to an EFF event where there was a guy from Sling Media
| (Slingbox, remember them?) who said the one point that overrides
| all others in importance, which he learned from EFF, is that
| updates should never be force pushed.
|
| Designing a device to accept force pushed updates opens non-
| addressable security holes by giving a mechanism that will allow
| political players, acquiring companies, or pretty much anyone
| with an angle, to use the legal system to exert any control and
| conduct any abuse they can get away with.
| blondie9x wrote:
| What about requiring proactive exploit identification to be paid
| out and then patched by manufacturers for reasonable life of
| equipment?
|
| The reasonable life of the equipment should be based on equipment
| type. It should also be clearly described and communicated to
| consumers how much support the manufacturer will provide the
| product over the life of the product and into future.
|
| Manufactures should have to estimate how long a product can last
| and will receive updates based on their testing and in reasonable
| conditions of use. And what environment it was tested in.
|
| Also, based on the Samsung recent leaks where many accounts were
| related to IOT devices we know the security risk is not just at
| the device level but in a broader sense the company itself.
|
| How a company manages and deletes / archives data safely is a
| paramount issue that also flows into securing IOT devices better
| as well.
| realo wrote:
| What about industrial IoT?
|
| Even if a manufacturer publishes updates, the clients would
| likely not want to change anything, often.
|
| If you have a plant with 1,000 units of gizmo-A and update them
| during a week-end and now 200 of them do not do the thing they
| used to do anymore... you have a big problem.
|
| There is a genuine fear to update anything in many industries and
| I am not sure how this can be overcome.
| Kim_Bruning wrote:
| I'm not sure it should be overcome.
|
| Updating software is not a panacea and not always the best
| thing to do. In industrial hardware it's often better to have a
| known quantity.
|
| Especially with equipment that can cause damage or even kill
| people.
|
| Even if it isn't quite that high stakes, dealing with constant
| random updates is a cost factor with no clear commercial gain.
|
| This doesn't mean there can't be updates, but they need to be
| done on the factory's schedule, not on the schedule of some
| random supplier.
| numpad0 wrote:
| Yeah, I don't operate software controlled heavy machineries,
| but it's not comforting when I update a physically moving
| machine and it makes different sounds than before due to
| altered algorithms and parameters.
|
| Also, it's not considered a huge issue in smartphones and
| laptop computers, but updating firmware on Flash ROM degrades
| its performance such as data retention periods. Firmware
| updates are not always a rocket surgery, but like a surgery,
| not without risks. I think advocating frequent updates to all
| types of electronics is slightly irresponsible.
|
| (Edited to add! I'm writing in good intentions but I'm not a
| US person, in case that matters)
| SimingtonFCC wrote:
| Flash ROM comment noted. It would be bad if getting a label
| required a manufacturer to do something objectively anti-
| user.
| SimingtonFCC wrote:
| Comments against push updates and highlighting industrial
| applications would be a very important part of record
| development. I would expect industrial buyers to have very
| different needs from commodity consumer hardware buyers and it
| would be great if they (and their vendors) were represented on
| the record!
| slt2021 wrote:
| Data collection is another point - customers need to know if
| their personal data, video streams are being collected and stores
| somewhere?
|
| like video camera streams, voice audio, images, etc - are they
| being used to train AI models for some object recognition of some
| sort?
| mschuster91 wrote:
| I can't file because I'm not based in the US, but I'd love to see
| smartphones, tablets and similar devices to be covered as part of
| IoT in general, as they share the most important of the
| characteristics - the manufacturer sells a device connected to
| the Internet.
|
| There are multiple issues that I think need urgent regulatory
| attention, and the issue classes are valid for both "classic" IoT
| devices and phones:
|
| 1. Manufacturers often do not state anything about support:
| availability of spare parts, feature updates, security updates.
| Even those that do, like Google's Pixel lineup, have ridiculously
| short times, and "enterprise" devices like my Samsung Galaxy Tab
| Active 3 that's 2.5 years old don't have spare screens available
| any more. I bought an "enterprise" device in the hope that it
| would have a better supply chain than consumer devices, but I was
| mistaken.
|
| 2. Many devices with batteries are sold without the ability to
| easily replace them or without officially sanctioned spare parts,
| which causes a risk of people running devices with swollen or
| otherwise damaged batteries, or devices living way shorter than
| they could be because batteries can and do simply lose capacity.
|
| 3. Many devices are completely locked down. This is particularly
| relevant for SSL root certificates whose expiry leads to devices
| being bricked, or for people who simply would like to enjoy the
| freedoms of the GPL and other FOSS licenses but can't because
| custom firmware can't be installed at all (due to Secure Boot) or
| permanently bricks features out of DRM concerns (e.g. Samsung
| Knox, Netflix, banking and many other apps that refuse to run on
| rooted or otherwise modified devices).
|
| 4. Many devices' BSPs (board support packages) are littered with
| ridiculously old forks of stuff like bootloaders, the Linux
| kernel or other userland software, and the chip/BSP vendors and
| manufacturers don't give a fuck about upstreaming their changes
| or code quality is so bad it cannot be reasonably upstreamed.
| SimingtonFCC wrote:
| Re your point 4 in particular, I feel your pain -- I said
| "exposed public keys, expired certs" in the OP for a reason.
| The current item doesn't contemplate a requirement to tie these
| off as such, but I'd be interested to see if commenters ask for
| this as part of getting a stronger label.
| mschuster91 wrote:
| Thanks for your response!
|
| To add on the "label" point: I don't think labels are enough,
| not in a world where consumers (private, commercial and
| governments) primarily look at the price in purchase
| decisions. At least a base set of legally binding
| requirements must be established.
|
| ETA: I'd also love to see an exception for small scale /
| startups. Like < 1000 units sold per model and year. That
| allows quick iterations while the large offenders still have
| to comply.
| SimingtonFCC wrote:
| Thanks for yours!
|
| It depends how much the labels shape behavior. I'm
| envisioning a "high-tier" label that says that risks X, Y
| and Z have been addressed by M means and that, e.g.,
| addressing risk Z meant sweeping stated databases for known
| security holes, committing to security-only patches for N
| years, and hiring J compan(ies) to sweep your firmware
| within specified parameters -- or whatever other things
| from the wish list of infosec pros that people like posters
| in this thread choose to advocate for. Hopefully that would
| be better than what we have now, which is mainly
| price/churn-driven minimum viable product.
|
| Re your exception: I don't think mandatory labels are on
| the horizon in the USA, but this could indeed be a problem
| under other regulatory regimes.
| lacker wrote:
| Regulation to require a certain period of security updates
| doesn't seem useful to me. It's very easy to send out a "security
| update" that doesn't actually improve security. You can send out
| an ad to all your users saying "You should upgrade now to our
| newest product!" and call it a security update. Requiring
| security updates may end up just requiring companies to spam
| their users with a certain amount of marketing material.
|
| A bigger issue than the available of updates is whether security
| updates are automatic and mandatory, or optional for the user. If
| a security update requires some action on the user's part, most
| users won't want it.
|
| The overall problem is that the main IoT security problem is
| botnets, not insecure devices per se. A botnet does not affect
| the owner of a device very much. Thus, the owner of a device
| usually _prefers_ an insecure device, rather than taking some
| risk of the security update breaking the device.
|
| I'm not sure what the FCC should do here. It seems reasonable to
| hold the manufacturers of devices responsible in some way when
| those devices are used in a botnet, but I'm not sure if that's
| within the FCC's scope.
| MarcoPerazaFCC wrote:
| I think you're right that it would be difficult for the FCC to
| precisely define exactly when security updates are required.
| This is a problem in law generally, one that is usually
| resolved by imposing a reasonableness standard. Maybe here, a
| vulnerability needs to be patched if it might reasonably be
| expected to allow an attacker to take control of a device, or
| to do so when combined with other known or unknown
| vulnerabilities. Or maybe a different standard. Then when
| enforcement/lawsuits come around, the judge/jury/regulator has
| to evaluate the reasonableness of the manufacturer's actions in
| light of that standard. We'd love to see commentary on the
| record as to what the right legal standard might be.
| rlpb wrote:
| > This is a general problem for law generally, one that is
| usually resolved by imposing a reasonableness standard.
|
| Exactly this. Here in the UK we have "merchantable quality"
| as the standard for the required quality of any goods sold.
| How "merchantable" is defined is a matter for the courts to
| decide on a case-by-case basis. In practice, the courts take
| into account generally market expectations as well as the
| marketed price to determine the expected quality standard and
| it seems to work just fine. If my chair falls apart after a
| few years after ordinary use by ordinary people, then it
| wasn't of merchantable quality and the seller is in breach of
| the law.
|
| In the case of security vulnerabilities, I think a similar
| approach would work well. The key thing is to ensure that
| sellers of IoT products cannot disclaim responsibility for
| security vulnerabilities _altogether_ , which is exactly the
| problem today. If an IoT product can be subverted by an
| adversary after a few years of ordinary use by ordinary
| people, then the seller _should be_ in breach of the law.
| keepamovin wrote:
| A cyber vuln is a defect in a product expected to function
| well. In other domains (cars, apartments, pharmaceuticals),
| if there is a defect, the manufacturer is responsible to
| ensure it is fixed.
|
| It seems pretty simple. The standard should be the same as
| used in other industries where vendors need to recall,
| repair, or refund products in case of defects.
| wolverine876 wrote:
| As a very broad starting point, we should be sure to address
| the fundamentals of security:
|
| CIA: Confidentiality, Integrity, Availability.
| sophacles wrote:
| This sounds like a reasonable approach (sorry for the pun).
| One question - reasonable to whom? (who? - english is my
| first language sorry).
|
| I ask because when I was doing security research, we'd often
| present issues and get responses like "but who is going to
| think of that?" or "No one could find that", only for someone
| to think of or find it later and take over a system. I still
| occasionally hear this from software developers (even though
| the industry as a whole has gotten much better over the
| years), but quite often from people who work in
| "cyberphysical" systems (e.g IOT).
|
| Part of the tension seems to come from the fact that some
| infosec people can be equally unreasonable, declaring
| something utterly useless if there's a remote theoretical
| chance of a problem.
|
| Unrelated to the above:
|
| > Maybe here, a vulnerability needs to be patched if it might
| reasonably be expected to allow an attacker to take control
| of a device...
|
| I suspect you know this and short-cutted for conversation, or
| maybe these are all the same legally, but "take control of a
| device" isn't the only win condition - DOS, info leaks, and
| so on also exist. I note this because I'm kind of curious if
| the law considers those the same or vastly different
| scenarios, and if any sort of FCC regulations would include
| them.
| duped wrote:
| One way to mitigate this is to require introspection into
| _what_ the update is. This has two implicit requirements
| which are that the firmware is source-available and has
| reproducible builds. With those two requirements you would be
| able to see _what_ is being updated, and prove that the
| update your device receives is actually the update the
| manufacturer said they created.
|
| The second requirement is something that is really overlooked
| in the software supply chain, partly because of the
| difficulty in achieving it. But it's a goal that the proper
| push from regulators could help us reach.
|
| A knock on benefit is this helps secure the update channel,
| which if you are requiring firmware updates you must also
| require a way to make sure those updates are secure (since it
| inherently creates more attack surface area)
| nneonneo wrote:
| The irony is that botnets often function as an automatic
| update: they break in through a vulnerability, often include a
| patch for said vulnerability, and then stay somewhat updated
| via their C&C server. Of course, this is all to prevent _other_
| botnets from coming in and stealing their devices away.
|
| We had a WiFi camera get compromised. We put it on the internet
| - so it could get an update - and it got pwned before the
| update even finished downloading. The malware blocked the admin
| interface, but kept the camera feed running, presumably to
| minimize suspicion. As far as we can tell, the actual vuln was
| patched (some sort of dumb command injection in one of the many
| exposed endpoints), so there was also no way for us to get back
| in.
| asynchronous wrote:
| You could regulate they have to patch any outstanding CVEs for
| their device/firmware but enforceability might be difficult.
| charcircuit wrote:
| Not all CVE are real vulnerabilities.
| tkfu wrote:
| This would be an absolutely terrible standard. CVEs really,
| really suck. See, for example, this CVE for curl[1] that was
| assigned a 9.8. Or read sqlite's page on CVEs[2]. The sqlite
| issues alone would make this a non-starter, because you're
| not gonna convince everyone in every piece of software you
| use to update their version of sqlite.
|
| [1] https://daniel.haxx.se/blog/2023/08/26/cve-2020-19909-is-
| eve... [2] https://www.sqlite.org/cves.html
| 2OEH8eoCRo0 wrote:
| Liability. Make the manufacturer liable if a known
| vulnerability is exploited.
| intrasight wrote:
| I would think that tort law already achieves this - unless
| some law was passed that shields manufacturers from lawsuits.
| If that's the case, then the easy fix is removal of such
| shields instead of trying to create new regulations. Same
| applies to nearly all aspects of product liability.
| RecycledEle wrote:
| I would expect some sort of license "agreement" that
| shields the manufacturer and resellers from all liability.
| intrasight wrote:
| Not too many industries have such a shield. The nuclear
| industry comes to mind as an example of one that does.
| MarcoPerazaFCC wrote:
| The general rule in tort is that you need physical injury
| or physical destruction of property to sustain a lawsuit.
| There's exceptions at the edges of that, but you basically
| can't sue a device manufacturer for crummy security that
| caused you to lose money or other non-physical damages like
| reputational harm. The same limitation does not apply to
| contract law. We think that a cybersecurity label could be
| enforceable under contract law, as well as help bolster
| claims that a duty was breached in tort (when there _is_
| physical injury /damage). It would also be subject to FCC
| enforcement, for failing to live up to the commitments made
| to get the label.
| b20000 wrote:
| Are you familiar with the saying that if you make something
| secure nature will create a better fool?
| earthboundkid wrote:
| This is a great idea! Just last week my wife had to connect our
| oven to the wifi to use an app to control it, and I was thinking
| about how there's basically no guarantee the oven won't just
| become a botnet on our internal network eventually. It would be
| great to get some legal requirements on this stuff.
| yellow_lead wrote:
| How can we define a security vulnerability meeting this "serious"
| requirement? There are a wide variety of vulnerabilities, so it
| seems difficult to define this strictly.
| MarcoPerazaFCC wrote:
| I think you're right that it would be difficult for the FCC to
| precisely define exactly when security updates are required.
| This is a problem in law generally, one that is usually
| resolved by imposing a reasonableness standard. Maybe here, a
| vulnerability needs to be patched if it might reasonably be
| expected to allow an attacker to take control of a device, or
| to do so when combined with other known or unknown
| vulnerabilities. Or maybe a different standard. Then when
| enforcement/lawsuits come around, the judge/jury/regulator has
| to evaluate the reasonableness of the manufacturer's actions in
| light of that standard. We'd love to see commentary on the
| record as to what the right legal standard might be.
| (originally posted at
| https://news.ycombinator.com/item?id=37394188)
| avsteele wrote:
| I think this is a bad idea which will lead to fewer and more
| expensive devices. I do not want the FCC regulating this.
|
| It is much more reasonable to have the market impose some
| discipline on manufacturers and their level of support. Plenty of
| consumers would favor less costly, less-supported devices.
| thfuran wrote:
| Are you in favor of seat belt and airbag requirements? What
| about the bans on asbestos and lead paint?
| avsteele wrote:
| Are you in favor of seat belt and airbag requirements?
|
| No. The presence of these features is easy to document, and
| the harms are limited to the person making the $/risk
| tradeoff. What about the bans on asbestos and
| lead paint?
|
| This is more justifiable. The harm is very far removed from
| the manufacture (time, place) and it is hard to evaluate
| whether a given space has these features when e.g renting.
| thfuran wrote:
| and the harms are limited to the person making the $/risk
| tradeoff
|
| That's not really true. Certainly the harm is concentrated
| there, but it leaks onto their passengers, whoever has to
| face vehicular manslaughter charges that should've been
| more minor, etc. and it is hard to evaluate
| whether a given space has these features when e.g renting.
|
| But it's hard to evaluate every aspect of any product, let
| alone all of them. Do you research the manufacturer of the
| capacitors in your phone chargers to prepare for the next
| capacitor plague? Do you perform supply chain analysis on
| the local sandwich shop to make sure their current veggie
| supplier isn't one associated with unusually high rates of
| salmonella? Or do you, at some point, assume that the
| things around you are generally safe?
| eru wrote:
| Hurrah, more red tape!
|
| Please let customers opt out of your proposed protection, if they
| want to.
|
| (And it sounds like that's already the status quo. So perhaps you
| could use your time to figure out where you can cut obsolete and
| cumbersome regulations instead of adding more mandatory
| bureaucracy that customers evidently don't want enough to pay for
| voluntarily?)
|
| There might be an argument to be made about negative
| externalities. The economic standard answer is either let the
| Coase Theorem sort it out, or to tax the externalities. Not to
| ban what you don't like.
|
| https://en.wikipedia.org/wiki/Coase_theorem
| janalsncm wrote:
| The free market hasn't figured it out, as evidenced by the
| decade of half-working devices consumers are left with. There
| is no way for people to know if products will still work in 2-5
| years if it depends on some server staying up.
| eru wrote:
| > There is no way for people to know if products will still
| work in 2-5 years if it depends on some server staying up.
|
| If customers want it, there is a way: use contract law to
| commit the manufacturer.
|
| That's already the norm for enterprise grade equipment.
| Companies often pay more for their hardware to get guaranteed
| long term support.
|
| So the market is willing and able to provide this kind of
| service, when people vote with their wallets.
|
| > The free market hasn't figured it out, as evidenced by the
| decade of half-working devices consumers are left with.
|
| The free market hasn't provided me with a flying car either.
| But that doesn't mean the market has failed. And I don't
| think using bureaucracy to ban any company that doesn't want
| to sell me a flying car would be an improvement on the status
| quo.
|
| (To be more explicit: many people, including me, think a
| flying car would be fun. But we don't want it badly enough to
| be willing to pay what it would take. And that's why
| suppliers only offer normal cars, not the flying kind.)
| lukeschlather wrote:
| Contract law actually is pretty universally used the other
| way around, to prevent you from updating. I have several
| old Android phones with locked bootloaders that I couldn't
| legally update even if the manufacturer hadn't locked the
| bootloader. I don't have access to the source code or the
| signing keys. I'm not sure the signing keys even exist
| anymore.
|
| And I can't buy a phone with the contract terms I want,
| they simply don't exist and can't exist unless the
| government forces companies to offer such terms. (They
| exist if you're buying thousands, maybe, but I just want
| one for personal use.)
| wolverine876 wrote:
| Have you ever used contract law in that manner? Did you
| call up Apple and negotiate a contract for your new iPhone,
| imposing requirements on them?
|
| Give it a try and report back.
| anigbrowl wrote:
| What's stopping hobby/micro-developers from saying 'Not FCC
| approved, use at own risk'? I hack on ESP32 devices, I
| certainly have different expectations as a hobbyist and as a
| consumer or consultant.
| eru wrote:
| > What's stopping hobby/micro-developers from saying 'Not FCC
| approved, use at own risk'?
|
| OP is. Or rather, he wants to make it impossible to opt out.
| At least that's how I interpret these two paragraphs:
|
| > The FCC recently issued a Notice of Proposed Rulemaking [2]
| for a cybersecurity labeling program for connected devices.
| If they meet certain criteria for the security of their
| product, manufacturers can put an FCC cybersecurity label on
| it. I fought hard for one of these criteria to be the
| disclosure of how long the product will receive security
| updates. I hope that, besides arming consumers with better
| information, the commitments on this label (including the
| support period) will be legally enforceable in contract and
| tort lawsuits and under other laws. You can see my full
| statement here [3].
|
| > But it's too early to declare victory. Many manufacturers
| oppose making any commitments about security updates, even
| voluntary ones. These manufacturers are heavily engaged at
| the FCC and represented by sophisticated regulatory lawyers.
| The FCC and White House are not likely to take a strong stand
| if they only hear the device manufacturer's side of the
| story.
| SimingtonFCC wrote:
| Sorry for any confusion. The relevant language:
|
| _If they meet certain criteria for the security of their
| product, manufacturers can put an FCC cybersecurity label
| on it._
|
| So if they don't, they can't put the label. That's all.
| eru wrote:
| Well, making a voluntary sticker to opt-in to certain
| legal obligations is fine.
|
| But you are saying already that manufacturers don't
| really want to commit to anything? What makes you think
| the sticker would change that?
|
| (In principle, I'm all for manufacturers offering more
| warranties. But when it comes to spending money,
| privately I almost never opt for the enterprise grad
| hardware that does come with warranties like long term
| guaranteed support.
|
| Instead I rely on reputation, eg that Google will keep
| providing security updates for their Pixel phones for a
| few years as they have done in the past, even if there's
| no legal obligation for them.
|
| And I wouldn't want any regulation to take that choice
| away from me. I'm glad to have escaped the EU where
| appliances are more expensive, partially because
| manufacturers are forced to include a two year warranty
| with each device.)
| whats_a_quasar wrote:
| The labeling program provides a signal to consumers that
| the device meets a certain standard. The incentive to the
| manufacturer is that it allows them to borrow the FCC's
| reputation and advertise a security that is well defined.
| The consumer can see that the device has that
| certification, and know that product has legal
| obligations, and
|
| It's a pretty reasonable first step. No manufacturer is
| being punished, there's no warranty requirement, and the
| gov isn't taking away choice. Instead the FCC gives
| manufacturers a way to reliably signal to consumers that
| their product meets a security standard. Google can do
| that because they're Google and have a reputation - this
| approach would let joe-schmo IOT device manufacturer do
| the same.
| jedberg wrote:
| What is the appetite for requiring the firmware/software source
| to go into escrow, such that if the company goes out of business
| or stops supporting the hardware, the software becomes open
| source and public domain?
|
| This would incentivize companies to provide updates but also
| allow the community to take over if the company folds.
| unintendedcons wrote:
| The most important thing is what happens after vendors fail and
| disappear - the code and keys and reproducible build system must
| be released so people can fix their things.
|
| A standard and an org for keeping those things in escrow, please!
| 1-6 wrote:
| The answer is: Standards. Linux core with LTS (Long-term
| support). Offer that option and don't get involved for the rest.
| Let the consumer decide.
| heisenbit wrote:
| Way back it was not so uncommon that companies buying software
| had access to the sources. When they did not have access to the
| sources and the machine code was supplied by a small vendor there
| were escrow agreements for the source just in case the vendor
| went out of business or died. No matter what rules are put in
| place companies will find a way around them or will not be able
| to follow them at all.
|
| Abandoned IoT devices if there are few of them are an issue for
| the consumer and they should be enabled to at least help
| themselves or hire help.
|
| Abandoned IoT devices if they are in larger numbers can pose a
| threat to the network and one may consider what could be done
| about those.
|
| Abandoned IoT devices also are an economic burden as they cause a
| premature loss of value of investments of consumers and
| investors. Worse are way too many horror stories out there of
| critical infrastructure running on outdated platforms. These
| devices were bought at a time where computers were rare. If we
| extrapolate 15 years from now based on the experience we have
| today - we will not see accumulated economic loss but disasters
| too.
| baby_wipe wrote:
| [Update: I did not read the original proposal carefully. I
| mistakenly believed this was a mandated regulation and not a
| voluntary one, so some of the points in my post do not apply.
|
| However, I still oppose it for mostly the same reason: if
| consumers wanted this type of label on their products, then we we
| would likely already see it.
|
| I am also skeptical that this is being initially proposed as a
| voluntary program, but is actually laying the foundation for a
| regulation that is mandatory.]
|
| Please do not propose this regulation. If consumers actually
| cared about their IoT devices receiving security updates,
| companies would be doing it. The fact that companies are not
| already doing this is evidence it's not important to consumers.
| People may express frustration, but their purchasing behavior
| speaks louder than their words.
|
| This regulation would force companies to work on things that
| customers don't actually value. It will hinder innovation.
| Companies could work on features consumers value instead of
| working on security updates that consumers do not value.
|
| If this regulation passes, companies will be less likely to offer
| new IoT devices knowing they will have to provide security
| updates beyond what consumers are demanding.
|
| This regulation will also increase costs for IoT devices. As a
| consumer, I do not want the FCC mandating what features will be
| included in my IoT devices.
|
| From the perspective of an individual engineer, tech regulation
| like this often leads to engineers doing soul-sucking work that
| nobody cares about. I know your focus is on consumer protection,
| not producers, so that point may be irrelevant.
|
| Please do not be the individual that causes a negative impact on
| the world, despite whatever good intentions you may have.
|
| I'm guessing if the FCC enacts this regulation, it will help you
| in your political career. However, if you were to take the
| opposite stance and oppose the legislation for the reasons stated
| above, I'm sure you'd lose your job very quickly. Therefore, I am
| confident I will be ignored.
| wolverine876 wrote:
| Consumer don't have time, knowledge, or resources to demand all
| these things they use. When I buy a car, I want it to be safe.
| I spend zero time evaluating its technology and demanding
| labels. I already have a job.
| a123b456c wrote:
| "The fact that companies are not already doing this is evidence
| it's not important to consumers. People may express
| frustration, but their purchasing behavior speaks louder than
| their words."
|
| I would like to see evidence before anyone accepts this premise
| as true. That's like saying smokers don't care about lung
| cancer, or parents don't care about lead in baby toys, as shown
| by their purchase behavior.
|
| Security updates are affected by asymmetric information,
| widespread consumer ignorance and negative externalities. We
| need solid regulation.
| harg wrote:
| I don't think customers not caring is a valid reason to not do
| this. Compromised IoT devices don't only cause harm to their
| owners, but also external networks and the internet as a whole.
|
| A compromised doorbell, or lightbulb etc can be used as part of
| a botnet to perform DDoS attacks or other nasty activities.
|
| An analogy is like saying we shouldn't work on reducing the
| pollution emmitted by motor vehicles because the users of these
| vehicles don't care about how much pollution they cause and
| would buy them regardless. It's the negative externalities that
| we need to consider.
| Twisol wrote:
| > If consumers actually cared about their IoT devices receiving
| security updates, companies would be doing it.
|
| I don't think this is true. Security issues don't matter _until
| they do_ , and consumers -- by which I mean "people" -- are
| notoriously bad at estimating risk for sufficiently rare
| outcomes.
|
| To take a common example, insecure internet-connected baby
| monitors can literally give strangers video access to your home
| (not to mention your child, although we don't need to resort to
| "think of the children"). I think most consumers make purchases
| with the reasonable expectation that the product isn't going to
| violate their personal security without them knowing.
|
| As a concrete example to the contrary, even many laypeople I
| know consider home assistants like Alexa to be too risky --
| they don't like the idea of being overheard and monitored by
| some unknown "other". And that's almost literally part of the
| product description! When consumers are aware of these issues,
| they _do_ care. The idea that they currently purchase as though
| they don 't is confounded by a lack of awareness on the one
| hand, and a reasonable expectation to the contrary on the other
| hand.
| zzzeek wrote:
| And here's the political angle. Letting a bunch of insecure iot
| devices into your home actually harms _other_ people by
| allowing your devices to enable subsequent exploits of your
| neighbors, both on the next block over as well as the next
| country over.
|
| Therefore iot devices most certainly should be regulated as
| this is a critical issue for the public good as well as
| national security.
| jwuphysics wrote:
| > Please do not propose this regulation. If consumers actually
| cared about their IoT devices receiving security updates,
| companies would be doing it. The fact that companies are not
| already doing this is evidence it's not important to consumers.
| People may express frustration, but their purchasing behavior
| speaks louder than their words.
|
| Or, maybe, companies are exploiting consumer ignorance and
| we're not dealing with an efficient market.
| faitswulff wrote:
| If you ask an average consumer about their IoT devices'
| security updates their eyes will glaze over. I imagine the
| average car buyer in the 1950s would react the same way to talk
| of "crumple zones." Consumers absolutely need to be protected
| from corporate negligence here.
| zamadatix wrote:
| The proposal in question is a voluntary labeling program. If a
| company did not want to participate they would not have to.
| ncallaway wrote:
| > If consumers actually cared about their IoT devices receiving
| security updates, companies would be doing it.
|
| This seems like a crazy response to me.
|
| The _entire_ program is _voluntary_. If a manufacture doesn't
| want to jump through any hoops the only downside is that they
| don't get an "FCC cybersecurity" label on it. So if the
| customers _actually_ don't care, then don't do the program and
| don't get the sticker on the box.
|
| The _only_ reason for anyone to complain about this program is
| that customers _DO_ fucking care, and _want_ to be informed.
| Customers _want_ to purchase more secure products but do not
| have the option, and do not have the information required to do
| so.
|
| It's not even a mandate that they have X years of security
| updates. They just have to _disclose_ how many years of
| security updates they are providing. They could disclose that
| they provide 3 months of security updates if they want to. If
| that hurts sales, it's only because PEOPLE ACTUALLY CARE about
| this.
|
| If your theory is accurate, then this proposed rulemaking would
| have 0 effect on industry at all.
|
| > As a consumer, I do not want the FCC mandating what features
| will be included in my IoT devices.
|
| That's not the proposal. The proposal is the FCC mandates what
| features are included in your IoT devices that have an "FCC
| cybersecurity" label on it.
|
| > If they meet certain criteria for the security of their
| product, manufacturers can put an FCC cybersecurity label on
| it. I fought hard for one of these criteria to be the
| disclosure of how long the product will receive security
| updates
| i_am_jl wrote:
| >Please do not propose this regulation. If consumers actually
| cared about their IoT devices receiving security updates,
| companies would be doing it. The fact that companies are not
| already doing this is evidence it's not important to consumers.
| People may express frustration, but their purchasing behavior
| speaks louder than their words.
|
| In 1980 11% of American adults used automobile seat belts.
| scottcodie wrote:
| Is there a definition of a "security update"? Software has an
| infinite number of bugs and it is cost infeasible to fix them
| all. If it's years down the road, the engineers that wrote the
| code may be long gone.
| MarcoPerazaFCC wrote:
| I think you're right that it would be difficult for the FCC to
| precisely define exactly when security updates are required.
| This is a problem in law generally, one that is usually
| resolved by imposing a reasonableness standard. Maybe here, a
| vulnerability needs to be patched if it might reasonably be
| expected to allow an attacker to take control of a device, or
| to do so when combined with other known or unknown
| vulnerabilities. Or maybe a different standard. Then when
| enforcement/lawsuits come around, the judge/jury/regulator has
| to evaluate the reasonableness of the manufacturer's actions in
| light of that standard. We'd love to see commentary on the
| record as to what the right legal standard might be.
|
| (originally posted at
| https://news.ycombinator.com/item?id=37394188)
| yacine_ wrote:
| YOU ARE ON THE WRONG WEBSITE!!!
| user3939382 wrote:
| We've seen manufacturers abuse ongoing access to devices to turn
| off features the device came with at the time of purchase or
| convert one-time-fee features into subscriptions. One of my
| concerns is that security updates are strictly defined in a way
| that prevents this type of regulation from being used as cover
| for these shenanigans.
| atomicfiredoll wrote:
| I just want to reaffirm the importance of this point. I've used
| an open source solution named Home Assistant[0] to manage my
| own network of IoT devices that I don't expose to the internet.
| I want to stay local because of the risks involved with the
| internet and with trusting companies to protect such private
| data.
|
| As such, I look to purchase relativity open devices. But,
| companies want to keep trying to inject themselves as a
| middleman, sometimes after the fact. In that case I'm let with
| a device that becomes e-waste. I don't know what other actions
| are being taken in regards to subscriptions, but it's a problem
| here.
|
| [0] https://www.home-assistant.io/
| hliyan wrote:
| I'm not a US citizen, but I too would cosign the idea of not
| using security updates as a vector for pushing monetization
| "features".
| eru wrote:
| > One of my concerns is that security updates are strictly
| defined in a way that prevents this type of regulation from
| being used as cover for these shenanigans.
|
| And then as a manufacturer you need to pay someone to certify
| that, or otherwise risk a class action lawsuit?
|
| What about hardware that uses third party software? (Either
| because it's a genuine third party, eg when you put open source
| on your router, or because the manufacturer split into two
| companies to exploit a legal loophole?) Can open source
| software only make releases that update automatically after
| getting certified, or risk getting sued otherwise?
| nanolith wrote:
| To add to previous similar comments, I think that one of the best
| ways to ensure that security updates are provided is to ensure
| that manufacturers either commit to continuous security updates,
| or after a minimum sunset period during which they provide
| security updates (e.g. 5 years), they agree to provide source
| code as well as build and deployment instructions, so that the
| community can take over. It must be possible to build the source
| code using a freely available toolchain. Furthermore, they must
| agree to provide links to these communities through their support
| pages for these products, so that users can be made aware of new
| third party firmware.
|
| A durable IoT device could last decades, but few companies
| building these products will survive as long as the devices, let
| alone support a device they are no longer profiting from. As long
| as they are supporting the device with security updates, it's
| fine for the firmware to be proprietary. But, when they decide to
| cut support for the device, they should be willing to ensure that
| consumers who have purchased this hardware and are still using it
| won't become victims, and that the overall Internet community
| won't end up harboring botnets made of living dead ewaste.
| XorNot wrote:
| Yeah I can't see an alternative to this. I'd go further to say
| that to guarantee this is done, company's should be required to
| provide this data upfront in some encrypted form, so that it's
| out and public in advance and can be unlocked by a simple
| encryption key (an FCC escrow service would be a good idea).
|
| And that's on the "if I really thought business should get a
| handout" approach.
|
| Practically, I see no reason the full source code for any of
| the network-interactive software components IoT devices
| shouldn't be required to be open and user-flashable upfront. I
| can buy pre-flashed ESPHome devices which will do wireless
| updates and come with the full source code and a map of how to
| talk to their pins (which implements the functionality) - I see
| no reason why this sort of access shouldn't be the default.
| __sy__ wrote:
| Nathan -- thanks for your work on this issue. I'm the ceo/co-
| founder at Seam (YC S20). We're building an API for IoT devices.
| I have many, many thoughts for you.
|
| For Seam, we purchase, set up, and test many individual devices
| and systems in our lab in San Francisco. During the course of
| this work, we discover quite a few interesting things. When
| possible, we work directly with manufacturers on addressing the
| more concerning problems we find. We maintain an internal device
| database (partially available here https://www.seam.co/supported-
| devices-and-systems) where we keep track of our findings on
| devices we test & integrate. One area that I haven't seen
| addressed here is data-storage jurisdiction. imho, that might be
| one of the more concerning aspect.
|
| happy to have a chat; my seam email is in my hn profile.
| AtNightWeCode wrote:
| Maybe it is the price model. It should state what type of
| security updates are included and for how long these are for free
| and what the expected cost after that is. I think a problem is
| that you buy a thing and not a thing and a service.
| pylua wrote:
| IOT security is funny. Secure ways of deploying things exists
| today, but retrofitting existing systems would be impossible if
| the devices don't support it ? Also, updating a running system...
| seems like a very costly and time consuming exercise.
| xoa wrote:
| Thank so much for posting this here first of all! I agree with
| other comments that rather than, or in addition to, some direct
| required period for security updates I'd really like to see a
| dynamic setup along the lines of "Power Means Responsibility":
| manufacturers can stop supporting devices when they wish, but
| must at that time release all keys and IP licensing needed for
| hardware owners to take over. If a company wants to keep
| supporting something, and in turn keep their power over deciding
| how it works, for 10 years that's fine. If they want to drop it
| after 6 months and make the firmware fully source available and
| allow owners to add their own root keys to devices that'd be fine
| too. Or someone could offer something fully open source with no
| strings attached but also no responsibility attached. The market
| can fill with a range of decent options.
|
| But manufacturers shouldn't be allowed to have it both ways, with
| control post-sale over their customers' hardware _AND_ no
| responsibility to support it. It should be directly linked by
| law.
| hannob wrote:
| > The FCC recently issued a Notice of Proposed Rulemaking [2] for
| a cybersecurity labeling program for connected devices.
|
| That appears to me to be the wrong way to go about this, and it
| has specifically to do with how IoT security is a problem.
|
| The most severe case of IoT security problems we have seen were
| things like mass botnets, where plenty of devices of the same
| type were hacked and then used for things like DoS attacks.
| Notable cases include the DoS attacks against Brian Krebs for
| some of his reporting.
|
| The important thing to understand here is that the device owner
| is _not_ the primary victim. That 's a third party.
|
| This is not about consumer choice, because consumers by and large
| do not care, because they are not the people being affected by
| this. An optional security label tries to adress it as a consumer
| choice problem, which it isn't.
| planb wrote:
| I think you are underestimating how a well known ,,secure"
| label (or lack thereof) could influence customer behavior. It's
| not that they don't care - they (understandably) lack deeper
| knowledge and therefore don't base their purchasing decisions
| on how long they will get updates. ,,If sticker X is not on the
| package I will get hacked" is much easier to grasp.
| doctorpangloss wrote:
| > ,,If sticker X is not on the package I will get hacked" is
| much easier to grasp.
|
| Hmm. In the grocery store, where this idea comes from and has
| the most persuasive history in govt. regulation, where
| manufacturers own the front of the package and regulators own
| the back, what is the healthiest food?
|
| The produce and meat. Which has no nutritional label.
|
| There's no such thing as a secure IoT device. There's
| _absolutely_ no such thing as a secure connected device that
| is also cheap.
|
| If you build your computer from commodity parts, it tends to
| be the longest lasting and most secure. It is usually the
| most expensive.
|
| Anyway, what would the label for a PlayStation 5 and an
| iPhone 15 look like? Miles long.
|
| Then, for the consumer buying the cheapest smart plugs off
| Amazon? Like one paragraph the vendor copied and pasted from
| the Internet, along with all the other legal shit they deal
| with.
|
| Whom should be regulated? I guess Amazon and Walmart, the
| retailers, they are the real gatekeepers. That's what the EU
| does! Which doesn't fly here. The Waltons live here, not in
| the EU.
| jtbayly wrote:
| That's only _one_ aspect of the problem.
|
| Lots of people have been bitten by suddenly unsupported
| devices.
|
| I think it could do some good.
| sanderjd wrote:
| Sure, but the question here seemed to be about security,
| specifically. What you're talking about is definitely a
| problem, but it seems like a different one.
| cosmojg wrote:
| Exactly. I don't see the situation improving until either the
| owner or, preferably, the manufacturer of a device that
| participates in a DoS attack is held partially accountable for
| said attack.
| marcosdumay wrote:
| Well, you can't hold somebody accountable if there isn't even
| a label or information somewhere saying that what they are
| doing is dangerous.
| otterley wrote:
| Sure you can. For example, we have vehicle codes that hold
| people accountable for dangerous driving.
| marcosdumay wrote:
| We don't hold people accountable for buying the wrong
| model of car and using it.
| eru wrote:
| Sounds like you are making an argument based on externalities.
|
| That's fine. But economic theory also gives you standard
| answers for externalities:
|
| Don't ban the behaviour you dislike. Either let people sort it
| out themselves (like the Coase Theorem
| https://en.wikipedia.org/wiki/Coase_theorem describes), or at
| most tax the offending behaviour.
| sanderjd wrote:
| I don't get what you're saying here. What "offending
| behavior" are you referring to in this case that might be
| taxed to disincentivize it?
| eru wrote:
| Suppliers can already make binding promises about their
| hardware. If you open your wallet wide enough, you can
| already buy enterprise grade hardware that comes with
| guaranteed long term support.
|
| OP says, amongst other things:
|
| > I've advocated for the FCC to require device
| manufacturers to support their devices with security
| updates for a reasonable amount of time [1].
|
| So the offending behaviour in this case would be for a
| manufacturer not to provide security updates.
| MarcoPerazaFCC wrote:
| Thanks for this great observation. I encourage you to share it
| in an official comment. In a final rulemaking, perhaps we could
| make it clear that the purpose of the label is not only to
| protect the purchaser of the product but also anyone who might
| be injured by way of a compromised device. In an FCC
| enforcement proceeding, we have broad discretion in assessing
| damages. In contract, the third-party beneficiary doctrine
| could allow victims of such attacks to enforce label
| commitments. And in tort, statutory duties apply to anyone who
| is within the class of people that the law seeks to protect. So
| the law is flexible here, but it depends on what exactly our
| final rules say.
| tkinz27 wrote:
| A big issue with botnets running on device owner equipment is
| the amount of bandwidth they "steal" from the device owner.
| Especially for device owners who are on constrained networks
| (such as a mobile/satellite network) this can be a really
| expensive issue for the device owner.
|
| So while the device owner may not be the primary victim, they
| can definitely still be heavily affected.
| otterley wrote:
| In order to make it a consumer problem, we'd have to make it a
| criminal violation to participate in a botnet. We could make it
| a punishable infraction I suppose, much like a speeding ticket
| for automobiles, but somehow I just don't see this happening in
| a coordinated fashion across the world.
| hutzlibu wrote:
| I think it is already illegal to participate in DDOS. Even
| though enforcement is .. pretty much nonexistent? And how
| could you enforce it? It would create an outcry if done
| consequently. (But maybe a neccessary one)
|
| But it also will be a consumer problem, if they cannot access
| important services anymore, because their IP has been
| blacklisted, because their toaster participated in too many
| DDOS or spam attacks.
| f33d5173 wrote:
| Even if consumers don't necessarily care about security,
| required labelling gives brands an opportunity to stand out
| from one another. If I'm looking at two products on the shelf,
| where one claims to have greater security, and the other makes
| no such claim, I'm likely to buy the more secure one, even if I
| don't necessarily care much about security. If getting the
| secure label is relatively cheap (which it should be, since
| most of the issues we see are the product of laziness rather
| than being especially hard to fix), than we could see the
| market dominated by products promoting high security, even
| without customers ever caring that much about insecure devices.
| dylan604 wrote:
| oh man, you sound like the type of person that would fall for
| the intentionally misleading labels that makes it sound like
| one thing but is in fact absolutely not that thing. just
| yesterday, there was a link to an article about the lies on
| food packaging.
|
| so, labeling requirements are one thing, but requiring that
| the information is straight forward and leaves no options for
| misleading would be great. I just don't think there's ever
| going to be a way from preventing someone from finding
| loopholes.
| SimingtonFCC wrote:
| There are a couple of NIST papers on specifics for labels:
|
| https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.02042022-2
| .... https://www.nist.gov/itl/executive-
| order-14028-improving-nat...
|
| They're in FN 20 of the linked proposal for rulemaking
| (which is 48 dense pages and which I don't expect anyone
| here to have had a chance to read yet.)
|
| If you find yourself skeptical about the NIST proposals,
| please feel free to comment on the record!
| hot_gril wrote:
| "This milk contains no <insert illegal additive>!"
| ChrisCinelli wrote:
| Making "x years of security updates" mandatory is likely to end
| up in a warning disclaimer every time you turn on the TV after
| x years: "This device does not receive any more security
| updates. You may be at risk."
|
| That will either make a large part of consumers paranoid or
| annoyed. So they will replace a TV that is in perfectly working
| conditions with a new TV.
|
| Samsung, LG and the consumerist economy would love that!
| mattkrick wrote:
| Voluntary certification, please. Law is slower than technology.
| This is a good thing! EnergyStar is a great example of a
| voluntary program doing more good than DoE or FTC mandates. HIPAA
| is a good example of what happens when mandates can't keep up
| with technology. When it comes to security, we can't afford
| another HIPAA.
| SimingtonFCC wrote:
| 100% agree! This is a totally voluntary program that is
| explicitly based on EnergyStar.
|
| I also worry that check-the-box compliance is one possible
| outcome. I'd love to see professionals comment on the record
| about where a checklist would and wouldn't be helpful. I'd also
| love commentary on if and where liability for failure to meet
| stated commitments would be helpful.
| throwaway689236 wrote:
| > Voluntary certification, please. Second this, otherwise it'll
| just put smaller companies without enough resources at
| disadvantage.
| Dowwie wrote:
| This economy seems to consist largely of cheaply made products
| with high profit margins. You're attacking profit margins, so
| good luck with that. Sorry for the pessimism but this country
| just derailed the FTC attempt to abolish non-competes because it
| would cost law firms business.
| smokel wrote:
| Interesting turn of events to ask Hacker News for their opinion
| :)
|
| Someone I know wrote an interesting opinion piece on this [1],
| which might be relevant to this discussion.
|
| [1] https://bits-chips.nl/artikel/iot-we-need-to-get-a-grip-
| on-t...
| mensetmanusman wrote:
| I'm concerned about smart lights that need to connect to Chinese
| servers to work being peddled on Amazon.
| TrueDuality wrote:
| I strongly suspect that regulation at the IoT product level will
| have a very small practical impact because I think its largely
| targeting the wrong issue. The vast majority of the
| vulnerabilities aren't coming from the manufacturer, many of them
| are making relatively small changes to a reference design
| provided by a company like Broadcom (which is notorious for
| exactly the behavior I'm about to describe).
|
| The reference design problem is an issue where a manufacturer
| like Broadcom creates a specialized chip. To use this chip they
| create a "reference driver" for it, package it in a custom
| firmware, then will never update that reference software. I've
| worked building internet routers for homes and small business and
| there are pieces of software we couldn't touch because they had
| been modified and only the fully compiled version is provided.
|
| Broadcom passes the buck by calling it a reference design and
| washing their hands of it. Some upstreams do provide the source,
| but it's the complete source, not just the changes they made and
| usually without any specific reference to what the specific
| version they based their changes on was. Trying to tease specific
| changes from the Linux kernel's raw source code is quite the
| needle in the haystack problem.
|
| I'm not sure how a lot of device manufacturers _could_ handle
| this. They tend to have very small development teams that are
| more electrical engineers than software engineers and usually
| their only directive is to make it work under an extraordinarily
| tight deadlines. Maybe part of the answer is they need to hire
| more to be more responsible... But even with experienced
| developers _every single hardware manufacturer_ is going to have
| to repeat the security fixes that companies like Broadcom refuse
| to fix.
|
| I don't even know where to begin proposing a legal foundation for
| reference design software. I do think if the penalties and pain
| were strict enough at this level it would lead to a different
| shortcut that would be much more beneficial to the world... If
| Broadcom and other companies doing this kind of malicious apathy
| were forced to keep their reference designs up to date, my money
| would be that they stop doing it entirely and instead get those
| driver merged into the Linux kernel proper where it can be
| properly maintained and updated by the legion of developers that
| care.
|
| The act of getting that code into the kernel would force them to
| improve the code and not take the shortcuts that cause so many
| headaches because the kernel developers gate the quality of code
| they produce.
| sa1 wrote:
| I wonder how companies will simultaneously deal with these FCC
| regulations in the US, and the proposed regulation to not update
| anything without intelligence approval in the UK.
| anticensor wrote:
| Separate hardware variants?
| ruffrey wrote:
| Many of these devices are made in China, even if designed and
| sold by American companies. Nearly all contain Chinese made
| parts. These are network devices with sensors and various
| behaviors. Given the tension between USA and China, especially in
| the cybersecurity realm - what about making the case based on US
| national security (in addition to consumer protection)?
| eru wrote:
| Sounds like a case of protectionism?
| hot_gril wrote:
| Just requiring security updates doesn't guarantee much; they have
| to actually stop the threats. I'd like some opt-in qualification
| guaranteeing support similar to what autos have. There are
| recalls for safety issues, refunds for negligence, etc for a
| reasonable amount of time. Behind the scenes, this requires some
| kind of fund or insurance to back up the liability. It's fine if
| not all products meet this bar, but it'd be good for highly-
| committed IoT companies to be able to distinguish themselves from
| the cheapos.
| doitLP wrote:
| There's some great recommendations in this thread but I just want
| to thank you for engaging with this community to solicit opinions
| from the trenches.
|
| This is really meaningful to most of us who see the regulations
| in our lives as something far away that we can't influence.
|
| Another reminder for everyone that while you likely can't
| influence something like a presidential election on your own, you
| can influence many other spheres with your knowledge and time
| that are closer to home and probably affect you more immediately.
| wolverine876 wrote:
| Agreed. Thank you Commissioner Simington for reaching out to
| us. It makes all the difference in the world.
|
| > while you likely can't influence something like a
| presidential election on your own
|
| In fact, there is almost nothing of significance you can
| accomplish (or influence) on your own. We always do and always
| have needed to work together - and the results are astonishing:
| almost everything that's ever been accomplished.
| [deleted]
| COGlory wrote:
| Going to echo my thanks here as well.
| SimingtonFCC wrote:
| Thanks! I am thrilled that so many people are participating.
| The FCC is going to need a lot of this community's input over
| the next few years as more and more devices go online.
| snarf21 wrote:
| The biggest problem isn't even new regulations. The liability
| for violation always tends to be a rounding error to profits.
| Then, even if there are teeth, there is no money for
| enforcement which makes it all pointless.
|
| Look at how the FTC and SEC have completely failed us in the
| 21st century. Better regulations would matter if we ever
| bothered to enforce the ones we already have.
| landemva wrote:
| This sums up the situation that government regulations
| don't work. These regulations put us on the path of
| trusting religious-like in government. We could be working
| toward push-button simple network segmentation with some
| kind of default filtering for install by the average home
| user.
| Finnucane wrote:
| Which the manufacturers of IoT devices will give us
| willingly out of the goodness of their hearts?
| landemva wrote:
| Yet government is made of people so it does not have God-
| like powers, even though it is often worshipped.
|
| I would prefer to plug in a box that does this
| segment/filter. I will pay if it can be rebuilt from
| available source code. Make it easy to install and setup.
| If nobody purchases then nobody cares and why would
| government get involved? Seems like FCC scope creep.
|
| Forcing every IoT vendor to do it overlooks the problem
| of each vendor having and maintaining the skillsets.
|
| How about something like UL to create a slim standard and
| test against that standard. The aforementioned box idea
| could apply to be tested against the standard.
|
| https://www.ul.com
| andybak wrote:
| > Yet government is made of people so it does not have
| God-like powers, even though it is often worshipped.
|
| A slightly bizarre aside.
| autoexec wrote:
| > These regulations put us on the path of trusting
| religious-like in government.
|
| We don't need to have religious-like faith in government
| because we can vote for people who will do what we want
| them to and we can vote out the people who refuse to do
| their job. It doesn't happen without the people getting
| involved and holding their government accountable though.
| You don't have to pray when you can vote.
|
| Without regulation you could only ever have religious-
| like faith in private corporations because they have zero
| incentive to act benevolently and you have zero power to
| replace a CEO who is acting against the interests of the
| public. You have no vote, so prayer is all you have left.
| landemva wrote:
| How well did that work for bank oversight in 2008, and
| again in 2023 with SVB? The accountability of "my one
| vote will remove government's failed regulators" fails on
| the scale of $billions.
| klausa wrote:
| Is there an argument that the government failed in
| oversight with SVB?
|
| I think this is a textbook slam-dunk by the government?
| They stepped in when the situation was _bad_, but not
| _catastrophic_ yet (mmmmaybe arguable), took over, and no
| depositors got hurt.
|
| Is there an argument that this could've gone better,
| apart from "no banks ever fail"?
| autoexec wrote:
| Your examples are situations were deregulation/lack of
| regulation caused problems. Without regulations, prayer
| didn't work out so well. We all know IoT security is a
| problem, but after decades of that problem existing
| prayer hasn't worked there either. No one person's vote
| can fix government but collectively we have the option to
| enact change. I'll take having the ability to make
| changes over being powerless to make changes every time.
| rjbwork wrote:
| >How well did that work for bank oversight in 2008, and
| again in 2023 with SVB
|
| Hilarious own goal on this one.
| fallingknife wrote:
| Maybe I could have some faith if regulatory bureaucrats
| were fired when there are major regulatory failures e.g.
| 737 max. Maybe I could have some faith if police state
| agency employees were jailed for FISA abuse.
|
| Voting isn't enough because even elected officials aren't
| allowed to fire these people.
| klausa wrote:
| HN when governments agencies have little leverage to
| enforce rules: The violations are a rounding error to
| profits! We need to make the laws more stringent.
|
| HN when EU passes laws that have significant teeth in them
| and let them actually enforce them: This is ridiculous
| overreach! It will kill innovation and make it impossible
| to do business there!
|
| Love it, never change <3
| avarun wrote:
| Almost like it's different people :)
|
| The bigger issue is that simplistic takes expressed
| strongly with no room for disagreement tend to get the
| most upvotes from other people. The people who agree will
| upvote, the people who disagree will just move on, and
| the people who don't have an opinion will think the
| person sounds like they know what they're talking about
| and will upvote anyway. That's how you end up with back
| to back threads where completely opposite takes are
| highly upvoted, and both of them happen to be awful
| takes.
| whats_a_quasar wrote:
| IDK man this is a pretty defeatist attitude and doesn't
| lead to any steps to improve the situation. There's an FTC
| commissioner here in the comments today who's interested in
| the community's input. If you don't think it will have any
| effect that's your prerogative, but members of the public
| providing good technical opinions can only be a good thing.
|
| I don't agree with the vibe that past failures mean that
| regulations are pointless. Nothing is perfect at preventing
| abuses, but regulations do shape the actions of
| corporations and the terms of the discussion. Plus, the FTC
| is not one person - the commissioner making the post
| entered office in 2020, and so it seems broad to pin him
| with vague statements about the FTC completely failing us.
| autoexec wrote:
| It's better to get the policies in place now and then
| complain about the lack of funding/enforcement. The mere
| threat of enforcement will cause some companies to design
| their products better and when a major security incident
| happens because of a bunch of insecure IoT devices and
| people are outraged it'll be a lot easier to motivate
| action if we can say "We already have rules that would have
| prevented this entirely, but the FCC wasn't provided the
| resources to enforce them."
|
| That's a clear call to specific action as opposed to "We
| don't have rules that would have prevented this, and also
| many of the rules we do have across several agencies don't
| have enough funding to enforce rules designed to solve
| other problems."
| echelon wrote:
| Thank you so much for asking HN! I can't think of a more
| informed, higher signal community to interface with and get
| open and honest feedback from. Really brilliant idea.
|
| I don't have much input on this issue, but I wanted to ask
| that if you know folks in the US Copyright Office, that you
| recommend the same approach to them with regards to their
| upcoming regulatory stance on AI.
|
| The copyright office is going to hear one-sided input from
| artists and the largest tech companies (seeking to build
| moats), but they need to broaden their inquiry to include
| technologists, researchers, and startups. HN is an excellent
| place to increase their understanding.
|
| _If you can, I would_ greatly _appreciate it if you tip the
| copyright office off about HN!_
| eganist wrote:
| Indeed, this is awesome.
|
| Not sure if you're able to comment on this, but is there
| anything in place to mitigate the risk of automated
| astroturfed commentary e.g via LLMs in this and other cases?
|
| Edit: on the fcc docket specifically, not on HN
| echelon wrote:
| > Not sure if you're able to comment on this, but is there
| anything in place to mitigate the risk of automated
| astroturfed commentary e.g via LLMs in this and other
| cases?
|
| Look at HN account age, karma, and comment histories.
| yreg wrote:
| What about new users?
| steamer25 wrote:
| This may be beyond the FCC's purview, but given some of the
| comments (e.g.,
| https://news.ycombinator.com/item?id=37393644) perhaps an
| entirely different strategy is warranted.
|
| Instead of trying to compel manufacturers, who may no longer
| even exist, to support their old products; perhaps the
| government should focus on protecting consumers and
| aftermarket vendors who update / modify / reverse-engineer
| older revisions--especially after they're no longer
| meaningfully supported by the manufacturer.
| unstatusthequo wrote:
| Fully agree. If some company vanishes, consumers are left
| holding the shit end of a broken stick. It would sure help
| if there were protections for those that effectively
| volunteer their time and effort to keep things running for
| others.
| oger wrote:
| There is an overlap with the right to repair topic. It does
| not make sense to have the DMCA hanging over your head when
| you are reverse engineering a product that is abandoned by
| the manufacturer - be it end of life or bankruptcy to name
| two reasons among many.
| Buttons840 wrote:
| Also, security researchers should have strong legal
| protections; they should be given the benefit of the
| doubt at every turn.
|
| Currently, researchers are sometimes threatened with
| decades in prison for testing the security of websites or
| devices. If they act in good faith as researchers, this
| should never happen.
|
| This is literally a national security issue. We currently
| stifle security research on essential IoT devices
| primarily so companies can avoid being embarrassed by
| their own poor security.
| EricMausler wrote:
| This might be an unpopular opinion but I respectfully do
| not see it that way. I agree with promoting security for
| IoT devices, but there needs to be consent from the
| company being probed for vulnerabilities or else I find
| it hard to consider it legitimate research, regardless of
| intent.
|
| I dont think anyone would like it very much if someone
| came to their house and documented all the ways to rob it
| they could find, even if it's for research purposes.
| There is an inherent risk of your vulnerabilities being
| broadcasted somewhere either on purpose or accidentally
| once that information is collected and organized by the
| researcher.
|
| It isn't harmless and innocent to probe anything for
| weaknesses unsolicited. It is reasonable to respond to
| that as a threat. It is genuinely threatening behavior.
|
| Now I do understand it gets complicated when it's a
| business being trusted with sensitive information /
| access to devices in your home. I am just saying as part
| of the solution we need to keep possibly threatening
| behavior in mind and try to avoid the promotion of it as
| part of the solution unless there is really no other way
| (imo)
| Two4 wrote:
| Why does everyone compare things to houses? If you want
| to be more consistent with your building analogy, IoT
| sold to the public or enterprises are more like bars,
| except that each user has their own privately owned bar
| that may or may not be stocked by a central liquor
| company. If a user wants to check it's not possible for
| someone to break into his bar, or slip poison into his
| booze shipments, or redirect the shipments altogether,
| that's legitimate in my mind. Even if someone buys a bar
| intending to hijack booze shipments, the liability is
| still partially on the liquor company if they have not
| taken reasonable precautions against known risks. Imagine
| buying a bar and the liquor company who you're forced to
| use says "if you rattle any of the doorknobs or test the
| alarm works, we'll sue your pants off and throw you in
| jail" - does that seem fair?
| EricMausler wrote:
| I was speaking towards probing the business not the
| things you own.
|
| Using housing as a metaphor is common because it's an
| incredibly common thing people can relate to with
| personal experience, and is something people typically
| have relatively detailed intuitions built around what
| they are okay with and not okay with regarding it.
|
| It got the point I was making across, but I do think
| there was a misunderstanding about what I was applying it
| to. I was referring to people who probe businesses
| security vulnerabilities on the internet side of IoT, not
| people who check for vulnerabilities in things they own
| on the T side of IoT.
|
| As for the bar analogy, I agree that there is a lot of
| room for reasonable due diligence to test the security if
| there is potential for you to be at risk of its failings.
| This is more in line of my last paragraph, and I do still
| assert that solutions that avoid the need for people to
| verify security themselves should be preferable to one's
| that do.
|
| If you've got 2 legally independent entities messing with
| the same device, and then abuse of the device does happen
| and it leads to damages - can you understand how much
| more difficult this becomes to sort out than if the
| company was solely responsible for the device?
| [deleted]
| dotancohen wrote:
| > I dont think anyone would like it very much if someone
| came to their > house and documented all the ways
| to rob it they could find, even if > it's for
| research purposes.
|
| The correct analogy would be if someone documented all
| the ways to rob a house that is currently mass-produced
| and sold on the market. And yes, as a consumer I most
| certainly would approve of such activity, especially if
| I've yet to make a purchasing decision. Or especially if
| I'm already living in such a house, I need to know that
| it is not safe.
| EricMausler wrote:
| In that scenario I would MUCH rather the company be aware
| someone is putting that lust together, notfiy me in
| advance of the research being concluded, provide updates,
| organize and manage the contents of that list, offer
| solutions, patch the fixes in new models, and generally
| work with the people who already purchased the house.
|
| I would not prefer someone to do it all in secret and
| then at the last second decide they want to inform the
| company.
|
| Once such a thing gets broadcasted, there is inherent
| risk created for a lot of those existing owners that did
| not exist. Opportunistic criminals are way more common
| than premeditated ones.
|
| Also if we gain the ability to monitor everyone who is
| currently probing houses for security issues, then if we
| are able to have a whitelist of people who pre-notified
| with their intent then we can more reliably examine
| people who might be looking to abuse the system.
|
| I guess part of my underlying assumptions here is that we
| are moving towards a surveillance state and there are no
| signs of stopping that
| saurik wrote:
| The problem here is that the thing I am probing is
| something I own: the device in my house that I ostensibly
| purchased and am allowed to smash with a hammer or put in
| a blender for all anyone should care; the context is that
| the DMCA is often used by companies to claim that DRM on
| the device is there to protect copyrights--whether music
| the device had access to, _even if it isn 't the reason
| many or even most people buy the device_ (such as a smart
| fridge with a speaker in it and the option to log in to
| Spotify), or the firmware software itself--and that it is
| thereby _illegal_ for me to distribute tools to help
| people access to repair (which is the key thing here:
| there actually are already some legal protections for the
| act of "probing", but you kind of have to do it alone
| which is insane) a device _I own_ and where finding
| vulnerabilities should be about me and my trade-offs, not
| the wishes of a manufacturer.
| EricMausler wrote:
| I hate it too, but the heart of this is that ownership is
| under question.
|
| People should not have agreed to buy things where there
| are parts of it they don't own that they don't even need,
| but they did. They did it a lot because it didn't matter
| to them and now those devices are prevalent everywhere
| and it's a PITA to try to buy the type of item you
| actually want - where you own it entirely.
|
| Ownership has never actually been absolute. When you buy
| land you cannot tear it up and make it totally unusable.
| If you buy a home under an HOA you may have to keep it in
| a certain type of order.
|
| Maybe what we need is a law that manufacturers always
| need to provide a "dumb" model of their products which
| can be completely owned by the consumer.
|
| However, I was speaking from a stance of acceptance that
| the companies are maintaining ownership of some
| functionality of the devices. I was primarily thinking
| about the way it accesses company owned infrastructure
| (servers and the information on them) but it extends into
| a grey area on the devices themselves.
|
| You should be allowed to reasonably tamper with the
| device, but you should also be attempting to communicate
| with the company about it. They shouldn't be allowed to
| retaliate against you for requesting to tamper, they
| should need to reply reasonably quickly, and the reasons
| for which they are allowed to deny you should be
| regulated so they cannot just deny for no reason.
|
| I am saying we need to lean in to the situation we are in
| if we want actual results, and I think there is a lot of
| room to develop a reasonable legal framework on this
| subject that incorporates partial ownership.
|
| It shouldn't be as restrictive as it is today, but it
| also shouldn't be a complete free for all. We should at
| least attempt to make an effort to control security
| vulnerability information so criminal behavior and
| innocent behavior actually looks different.
| AnthonyMouse wrote:
| > There is an inherent risk of your vulnerabilities being
| broadcasted somewhere either on purpose or accidentally
| once that information is collected and organized by the
| researcher.
|
| A legitimate researcher is going to promptly notify you
| of any vulnerabilities they discover and you as a large
| organization are going to promptly remediate them.
|
| But the trouble isn't that the law might impose a $100
| fine on a smug professor or curious adolescent to
| demonstrate that some audacious but mostly harmless
| behavior was over the line, it's that the existing rules
| are so broad and with such severe penalties that they
| deter people from saying anything when they see something
| that looks wrong.
| EricMausler wrote:
| I agree the laws are too broad. I think we need add
| layers of granularity to them. Create more of a framework
| for settling the rules on what is and isn't allowed.
| Maybe we settle on everything goes, but the company
| should be involved.
|
| A legitimate researcher should be notifying the company
| that they are going to be looking for vulnerabilities in
| the first place. That is part of the distinction in
| behavior that I am encouraging. This way if someone is
| caught poking around for things to abuse unsolicited, at
| least there's a little more merit to holding them
| accountable. We are able to treat it more like the threat
| it is.
|
| A good faith company can give researchers pointers on
| where to look. Maybe the company has a really good reason
| to prevent looking at certain things, and they are able
| to convince the researcher of that. I dk. Point is the
| framework for settling all that should be promoted rather
| than promoting people to act identical to criminals right
| up until they decide whether to sell / abuse the
| information illegally or notify the company and try to
| get a reward. Does that make more sense?
| Buttons840 wrote:
| I once found a vulnerability. I pressed F12 and saw
| unintended information in the source of a webpage. I just
| closed the tab, I didn't report it.
|
| Our laws made it risky to do the right thing, so I didn't
| do the right thing.
| tremon wrote:
| _there needs to be consent from the company being probed
| for vulnerabilities_
|
| What is the type of scenario that you have in mind here?
| Do you mean probing a web service for vulnerabilities,
| performing security assessments as part of pre-sale
| publications (think Consumer Reports, Anandtech reviews
| etc), or performing pen-testing on a device I bought and
| is now running on my home network? Because you appear to
| be arguing that I shouldn't be allowed to examine a
| device I own without explicit manufacturer consent.
| EricMausler wrote:
| I was speaking towards internet side of things where you
| do not own the infrastructure.
|
| As a related note, I do firmly believe in right to
| repair, and if you own something you can do whatever you
| want with it.
|
| Partial ownership seems to be a thing now. So I think
| there is a lot of missing framework around managing that
| properly.
|
| Long story short - I think there is room for manufacturer
| consent / acknowledgement / notice to be part of the
| solution and if it can be part of the solution then it
| should be. We may need regulation around that, it likely
| cannot be left solely to the companies discretion and may
| even need an aggressive "receipt but no reply by X days
| is considered consent" clause - but I would like to
| promote solutions that come with communication between
| the effected parties
| AJ007 wrote:
| This is what is referred to as "security through
| obscurity." If companies are going to publish/sell closed
| source software to the general public, and make any
| claims regarding it's security, that should provide more
| than enough consent to probe it.
| EricMausler wrote:
| I think the difference is in what's yours and what's
| theirs. If it's yours, I agree. If it's theirs, I
| disagree.
|
| The idea of absolute ownership is being eroded. You
| purchase a device but that device may use information you
| do not own. If you are manipulating the device to allow
| it to give you information you did not purchase and the
| contract you agreed to with the purchase was that you
| would not do this, then that is threatening. If what you
| learn by probing it allows you to breach the security of
| other people using the same service, then that is
| threatening.
|
| If you are concerned about the device, I don't understand
| why we can't live in a world where you are able to
| vocalize that and give the device provider a chance for
| feedback before probing it for weaknesses.
|
| If there is a security concern that you want to shine a
| light on, why is it that we need to address that concern
| in the dark? It is giving too much unnecessary overlap
| with people looking to exploit those security issues when
| we might not need to
| Buttons840 wrote:
| Do you believe that your proposal increases the
| cybersecurity of society as a whole?
|
| You focus a lot on the rights and conveniences of a
| company, but the rights of a company are not more
| important that the security of society as a whole.
|
| There are good guys and bad guys out there looking for
| vulnerabilities. What you propose reduces the number of
| good guys more than it reduces the number of bad guys
| (since bad guys are less likely to follow the law). What
| you propose shifts the balance towards the bad guys and
| makes it more likely that vulnerabilities will be
| discovered first by the bad guys. You also propose
| security through ignorance; security via hoping that
| nobody notices.
|
| Again, I would really like to hear you assert that your
| proposal would increase the cybersecurity of society as a
| whole. I did not clearly see such an assertion in your
| comment. I want to see an argument focused on the
| security of society as a whole.
|
| I assert that we currently reduce our national security
| for the convenience of companies.
| EricMausler wrote:
| I proposed a preference for systemic solutions over
| building a soft dependence on white hat hackers.
|
| This benefits society as a whole because it clearly
| delineates actions with intent. If doing X is always not
| allowed, then all you need to do is find people doing X
| and you can hold them accountable.
|
| If you allow or disallow the same activity based on merit
| of intent, then you increase the level of plausible
| deniability to everyone who gets caught.
|
| I am not proposing security through ignorance. I am
| proposing security through consent. Nowhere did I say
| anything about not allowing research, I only said that if
| you do it unsolicited then it should be considered a
| threat.
|
| So, we could systemically allow for a right to research
| that involves notice to the company and their consent for
| you to test. It would not hinder white hat at all. If
| businesses resist for selfish reasons we can expand the
| law to prevent them from denying requests without a
| legitimate reason. For example, maybe it is okay for them
| to deny a request from an ex-employee with a grudge who
| has sent the company aggressive emails. Idk, maybe there
| are no valid reasons to deny. The point is we can create
| a framework that promotes security development above the
| table with all parties involved. And my proposition is
| that if that is possible then it should be preffered.
| sumtechguy wrote:
| I would like to add most of the IoT problem is no patches at
| all. The firmware they get is usually bog standard with some
| very minor tweaks out of china somewhere.
|
| It is a problem of vendor locked in products where you have
| to buy a hub to do an update. If there even is an update. If
| you want to get a good picture of how sideways updating can
| even be watch the linus tech tips on where he wanted (and has
| the tech ability) to patch his light switches. But could not
| even get them to give him the correct firmware or even say if
| he could. Also many devices there is literally no way to even
| do the update. They flash it on the line and that is the last
| update it ever gets.
|
| Also Supported and actually maintained in the hardware world
| can mean different things. So you will need to get your
| definitions up front correct. Supported could mean to a HW
| manufacture if the thing burns out ship a new one. The
| firmware is a secondary consideration.
|
| Another aspect you will run into is licensing. I can sell a
| device but may not have access to the code. Example: The
| vendor who makes that code went EoL on their code 5 years
| ago. They will not even sell me the code as they may or may
| not even have anyone who works for them to give it away if
| they could. They may or may not want to sell me that software
| anymore as they have a new shiny they want to sell me. So I
| am stuck even though I want to update I can not do it. I had
| one vendor flat out refuse to give me the older docs because
| the item was EoL and they had a replacement product that cost
| like 5x. That was just to communicate with the thing. Not
| even to update it to a later revision.
| MarcoPerazaFCC wrote:
| Re: the licensing issue, companies wanting to put a label
| on their product would probably want to extract similar
| guarantees up their supply chain. Especially with a
| voluntary program like the one the FCC is proposing, good
| practices won't become the norm across the market
| overnight. But maybe, at the very least, the segment of
| product and component makers that take security seriously
| will begin to grow. I encourage you to share your thoughts
| in an official comment.
| slavik81 wrote:
| > If you want to get a good picture of how sideways
| updating can even be watch the linus tech tips on where he
| wanted (and has the tech ability) to patch his light
| switches. But could not even get them to give him the
| correct firmware or even say if he could.
|
| It was a mess, but it may not be a good example because
| part of the confusion was that there was no newer firmware.
| Their firmware version was being reported in hexadecimal,
| but the latest firmware version was listed in decimal.
| sumtechguy wrote:
| He had a mix of random ones. They were telling him to buy
| a hub and hope for the best or go thru one of their
| vendors (more cost). Even if it that was slightly wrong
| that exact example could very easily happen. You have a
| group of devices in random levels of firmware states with
| no real nice way to tell what is what.
| com2kid wrote:
| > I would like to add most of the IoT problem is no patches
| at all. The firmware they get is usually bog standard with
| some very minor tweaks out of china somewhere.
|
| I was on a team that worked with a firmware vendor, from
| the US, for a bluetooth chip.
|
| We would send in bug reports, they'd send us firmware with
| fixes. Except it was obvious they _did not use source
| control_ because they would sometimes base patches off of
| old firmware versions that had the bugs they had fixed in
| newer versions. It was absolutely insane having to send
| emails like "hi, your latest patch is based on firmware
| from a year ago, can you please instead fix the firmware
| you sent us last month?"
| mannyv wrote:
| Sounds like broadcom to me.
| com2kid wrote:
| Hilariously, not that time.
|
| I do understand why you might think that though. :-D
| sumtechguy wrote:
| Those sorts of places are fun to interview at. 'So what
| sort of source control do you use'. You would think
| everyone does that by this point. An easy slam dunk
| question to ask and for them to answer. I had one say
| 'well sometimes we check it into sourcesafe but usually
| just copy it around the 5 of us on a fileshare' (this was
| like 4-5 years ago).
| ChrisMarshallNY wrote:
| Awesome!
|
| Thanks for engaging, where the rubber meets the road!
|
| Hopefully, you are also looking into other venues, as well.
|
| HN has a great group of folks that represent some of the most
| cutting-edge tech, but IT runs on Java 8[0].
|
| [0] https://news.ycombinator.com/item?id=19877916
| kaycebasques wrote:
| Pretty cool (or at least interesting) to see a government
| agency engage on HN like this. Never seen that before.
| toomuchtodo wrote:
| They're definitely making efforts to engage where
| practitioners and subject matter experts are. Substantial
| Federal gov showing at defcon this year for example.
|
| https://www.dhs.gov/news/2023/08/11/secretary-mayorkas-
| deliv...
|
| https://www.politico.com/news/2023/08/11/def-con-hackers-
| spa...
|
| https://arstechnica.com/information-
| technology/2023/05/white...
| SimingtonFCC wrote:
| Thanks for participating! After this thread winds down, I and
| my team are going to comb through it for suggestions and take
| as many as we can. We're also looking into other venues to
| engage directly with cybersecurity professionals. But please
| feel free to comment on the record as well -- a robust and
| detailed record is worth a lot more than whatever I can do
| individually.
| ChrisMarshallNY wrote:
| I think that you'll get a lot of feedback.
|
| I would suggest to my peers, that the links you gave are
| "official channels," and are probably what you _really_ want,
| as opposed to a rather rambling thread of comments.
|
| But for me, you just get a rambling comment.
|
| I made my career on devices. In particular digital scanners
| and cameras.
|
| I worked for a company that was about as tinfoil as you could
| get, and they supported devices long past their sell-by date.
|
| But I also know that my company was an outlier. They sold
| premium equipment, at a premium price. They were an "old-
| fashioned" Japanese corporation, and had a basic mindset of
| keeping the customer's workflow in the center of the screen.
|
| I think IoT security is a huge issue, and I think that the
| solution could be that there are standard, open-source, open-
| license, free-to-use packages; maybe written in languages
| like C, that could be offered to the industry. These could
| enforce low-level compliance with security standards.
|
| Oh, and keep the TLAs out of it. They would _really_ like to
| put a bit of "extra spice" in something like that.
|
| That said, I know that it will never happen. There's a
| gazillion issues.
| SimingtonFCC wrote:
| _I would suggest to my peers, that the links you gave are
| "official channels," and are probably what you really want,
| as opposed to a rather rambling thread of comments._
|
| I sort of want both. Official commentary moves the needle,
| but selfishly, I love the thread comments. People tell you
| what they really think, and sometimes go into a lot of
| detail as to why. It's an education for me.
|
| _I think IoT security is a huge issue, and I think that
| the solution could be that there are standard, open-source,
| open-license, free-to-use packages; maybe written in
| languages like C, that could be offered to the industry.
| These could enforce low-level compliance with security
| standards._
|
| "Universal basic security" would probably be a major field
| of policy approach if we found ourselves with some huge
| disaster requiring a regulatory response. It's at least
| worth thinking about now, even if it goes beyond the scope
| of what the immediate regs can do.
| reducesuffering wrote:
| An even better venue for informed cybersec professionals is
| the info-sec community on Twitter and Mastodon,
| https://infosec.exchange/about .
|
| People like Michal Zalewski, https://twitter.com/lcamtuf,
| could point you to the best of that.
| toasted-subs wrote:
| Would there be a portal where people can report potentially
| hacked IoT devices?
| slicktux wrote:
| What does this mean for DIY hardware? For one I like my ESP32 and
| Arduino hardware because I can do whatever the heck I want with
| it. Will I be limited in choices if a bill/regulation is passed
| so as to make it restrictive on buying IoT hardware that's not
| compliant with "security features "?
| MarcoPerazaFCC wrote:
| This will be a completely optional program. And the proposal is
| that even for participants of the program, they just have to
| disclose the update period, whatever it may be (could be zero-
| length).
| solardev wrote:
| How will the regulations keep up with evolving security best
| practices?
| MarcoPerazaFCC wrote:
| It's a voluntary label, so it's open to competition from other
| standard-setting organizations. When it comes to mandatory
| regulations generally, our office thinks that broad standards
| that are used to hold people accountable for negligent conduct
| are better than detailed checkbox-compliance exercises that
| quickly become out-of-date red tape.
| burkaman wrote:
| > Accordingly, incorporating our modifications, we propose, for
| purposes of the IoT labeling program, to define an IoT device as:
| (1) an Internet-connected device capable of intentionally
| emitting RF energy that has at least one transducer (sensor or
| actuator) for interacting directly with the physical world,
| coupled with (2) at least one network interface (e.g., Wi-Fi,
| Bluetooth) for interfacing with the digital world. We seek
| comment on our proposed definition.
|
| I think this definition would apply to stuff like phones and
| cars, right? If so that's great.
| AnimalMuppet wrote:
| I don't like the quoted wording. I would like it to be clearer
| that the RF part isn't part of the transducer, but part of the
| network interface.
| burkaman wrote:
| I don't think it has to be part of the network interface. You
| could have an ethernet-connected device that emits RF for
| some non-networking purpose and I think it would still
| qualify.
| AnimalMuppet wrote:
| But if I have an ethernet-connected device that _doesn 't_
| emit RF for some non-networking purpose, it should _still_
| qualify. It should just need the transducer and a network
| connection.
| burkaman wrote:
| I don't think it would for this specific proposal. The
| FCC's justification for this rule is that insecure IoT
| devices "could be manipulated to generate and emit RF
| energy to cause harmful interference". That's why they
| have jurisdiction here, because they regulate radio
| frequency use.
| AnimalMuppet wrote:
| Ah, I see.
|
| Well, I stand by my position that the other is _also_ a
| problem, but maybe this rulemaking isn 't an approach
| that can cover that.
|
| Don't get me wrong, this is still worth doing...
| ncallaway wrote:
| This makes sense to me. The definition _is_ slightly
| awkward, but awkward in a way that preserves the FCC 's
| ability to regulate the issue at all. If you clean up the
| definition, you can get to a more coherent definition of
| IoT device, but without the FCC's ability to regulate the
| devices.
|
| I think the broader definition would probably just fall
| back to the FTC, and as far as consumer protection goes I
| think they've been asleep at the switch for decades.
| dtaht wrote:
| This is a wonderful thread, and I am so glad to see so many
| sharing my nightmares and some of my conclusions. I encourage
| folk to work together on actually filing proposals with the FCC
| in their format. I would gladly join on such an effort, but am
| too busy to lead such an effort.
| jjguy wrote:
| For those of you unfamiliar with the specific challenges IoT
| patching brings, here is a blog post from just last week on one
| aspect of the topic:
| http://tomalrichblog.blogspot.com/2023/08/british-cuisine-de...
|
| FTA:
|
| > I assumed that device manufacturers update the software in
| their device about every month...he said they do it annually.
|
| Those devices are at least _getting_ updates - there is a long
| tail of devices whose operational lifecycle [far] exceeds the
| vendor's support timeframe - in other words, they don't get
| patches at all N months after release.
|
| The solution to these problems is straightforward - we've been
| managing it in software for a long time. EOL OSes, Long Term
| Support (LTS) OS releases, etc - but the device manufacturers are
| not as mature, and have not been making natural progress to do
| so.
|
| And since this is HN - there is a startup hidden in the midst of
| all of this: an enterprise-grade IoT OS that "does security
| right." Sell to the device manufacturers, allow them to market it
| as "enterprise-ready" or some such. If the FCC guidelines here
| are approved, there will be a suddenly increased demand!
| MarcoPerazaFCC wrote:
| > _And since this is HN - there is a startup hidden in the
| midst of all of this: an enterprise-grade IoT OS that "does
| security right." Sell to the device manufacturers, allow them
| to market it as "enterprise-ready" or some such. If the FCC
| guidelines here are approved, there will be a suddenly
| increased demand!_
|
| Agreed. Building an automatic firmware update system from
| scratch would be burdensome for many IoT makers, but as it
| becomes necessary or encouraged, we would expect the market to
| provide a packaged solution/framework that manufacturers could
| fold into their products. It would be really helpful have to
| discussion of this on the record. How generalizable do you
| think such a solution could be? We are aware of the Uptane
| project, an OTA firmware update framework being jointly worked
| on by several car manufacturers, but would love to hear more
| about the feasibility of a solution for IoT devices generally,
| or particular classes of IoT devices.
| bfung wrote:
| > there is a startup hidden in the midst of all of this
|
| There are already some companies that do this, but obviously
| adds to the cost to making these iot devices.
|
| Ex: balena.io, and even AWS iot management does this.
|
| Maybe there's someway to get the AWS iot gorilla in the room
| the weigh in?
| nonrandomstring wrote:
| Forgive my redundancy as I am surely saying what has already been
| said in other comments I've not yet read.
|
| I have one cast-iron, non-negotiable relation with IoT objects:
|
| No IoT device should ever hide what it is doing from me.
|
| If it lives in my house, car or environment it is not acceptable
| for me to install something which then tries to hide its
| operations.
|
| I don't care who it's made by or how much they think they are
| "helping me".
|
| Whether by encrypted tunnelling, side channels, secure enclaves
| or whatever devious shitfuckery, if I can't put Wireshark on my
| network and put a name and purpose to every operation then I'll
| track down the origin and eliminate it.
|
| Further, I am simply not interested in any "arguments" claiming
| this is "necessary". It is not. Profit, spying and control are
| always the ulterior motive, and they are unacceptable. Do not
| allow anyone to pretend they are "security" and hide behind that
| word. Security for whom, from whom and to what end....
|
| Also there should be no "embedded function" which I cannot turn
| off with confidence, perhaps by a physical jumper or switch. No
| IoT device should ever reset itself to insecure defaults.
|
| Thanks for enquiring and good luck in your difficult work.
| BearhatBeer wrote:
| How will you define the difference between IoT, embedded, and
| devices which just happen to be tucked away?
| btilly wrote:
| What is the policy on manufacturer installed backdoors on
| commodity hardware?
|
| See https://arstechnica.com/information-
| technology/2016/11/chine... for an example.
|
| Attempting to rule on this might involve conflict with the NSA,
| which has a decades long history of getting backdoors into
| commercial tech. https://www.reuters.com/article/us-usa-security-
| congress-ins... says a bit about this. But a lot of our tech is
| built in China. They're almost certainly doing the same thing,
| and history shows that those backdoors get discovered then become
| a source of security holes for the rest of us.
| pledess wrote:
| I'd prefer a different solution in which the ecosystem of off-
| the-shelf consumer-grade routers and behind-the-router IoT
| devices cooperates to block Internet access, for a single IoT
| device, if that device is in a suitably exploitable state.
|
| This isn't a perfect solution but your "support their devices
| with security updates for a reasonable amount of time" is a non-
| starter. For example, suppose I'm designing a doll for the
| Christmas 2024 season. The doll uses the Internet because it's an
| AI product that converses with young children about the latest
| STEM news. I don't know how long it'll be used: maybe my eight
| year old daughter will just find it boring, or maybe she'll
| physically destroy the doll because she disagrees with its
| opinion on the Riemann hypothesis.
|
| I can't afford to maintain firmware beyond January 2025. If I
| have to commit, I'll just never release the product, and children
| will potentially have worse learning outcomes forever. But I am
| willing to have my 1.0 firmware send beacon frames to cooperating
| routers, announcing that my combination of product ID and patch
| level is a8217a61-09de-4b1e-8a99-b6fbc180cdce, and please
| blackhole me if this is a dangerous version. This requires more
| engineering to work effectively, but please don't stifle
| innovation by small IoT vendors who cannot commit firmware-
| maintenance resources to a product with an unknown revenue
| stream.
| lrvick wrote:
| I have personally found several IoT vulns in everything from Zoom
| devices to Japanese robot hotels, and I run a security consulting
| firm. Swooping in with my 2c.
|
| Most of the time the engineers making these things -think- they
| are reasonably secure, but they tend to have little to no infosec
| experience and are moving too fast with no accountability.
|
| Worse, even when there is some accountability such as code
| review, the release engineer creates the security problems at
| release time either as a supply chain attack or stupidity.
|
| If I were making the rules, I would ramp up common sense supply
| chain accountability which would cause some of the most prevalent
| problems to be spotted early.
|
| My wish list:
|
| 1. Require all source code be signed (git signatures or similar)
|
| 2. Require all source code reviews by peers be signed (minimum 1)
|
| 3. Require source code to compile deterministically
|
| 4. Require at least two individuals or entities verify code
| signatures, compile code, and compare identical hashes
|
| 5. Require proprietary firmware products have an external
| security firm on retainer incrementally reviewing code (including
| dependencies!), as well as reproducing, and co-signing releases.
|
| 6. Require proprietary products use a source code escrow service
| that will make their code public the day support and security
| updates stop so the consumer community can patch for themselves
|
| 7. Require open source firmware products have a bug bounty
| program (potentially with government funding like the EU does)
|
| Happy to chat about this sort of thing with anyone interested.
| Contact info in my bio.
| [deleted]
| notinthegovt wrote:
| great idea. is my name and address submitted on the form, Express
| or Standard, make public in anyway? Potential political
| implications down the road...
| transpute wrote:
| For visibility into Linux IoT firmware contents, you can upload
| the public firmware binary for any IoT device to the Microsoft
| binary analysis service. This free service is based on their
| acquisition of ReFirm Labs Binwalk Enterprise.
|
| https://techcommunity.microsoft.com/t5/microsoft-defender-fo...
|
| _> Firmware analysis takes a binary firmware image that runs on
| an IoT device and conducts an automated analysis to identify
| potential security vulnerabilities and weaknesses. This analysis
| provides insights into the software inventory, weaknesses, and
| certificates of IoT devices without requiring an endpoint agent
| to be deployed._
| blinkysc wrote:
| I think we also need to have mandatory access to devices for our
| own monitoring solutions
| PaulWaldman wrote:
| There is a high degree of ignorance pertaining to cybersecurity
| among the general public. Stand next to the Geek Squad counter at
| Best Buy and you'll hear login credentials being freely exchanged
| all day.
|
| Since this is "opt-in" on the part of the vendors, how will
| consumers be educated to care about the FCC cybersecurity label
| to make it worthwhile?
|
| This also seems analogous to the USDA's Organic label.
| winstonprivacy wrote:
| Sorry, but this is a terrible idea that is going to stifle
| innovation and make it much harder for startups and small
| companies to compete. The government simply doesn't need to get
| involved in this. There is already an incredibly robust ecosystem
| already in place which shames manufacturers who drop the ball
| when it comes to security.
|
| More government is rarely the answer and especially so in this
| case.
| nneonneo wrote:
| If I understand correctly, the labeling will be voluntary. So, I
| would guess that one of the challenges here is balancing the
| strictness of the requirements vs. the burden to manufacturers,
| i.e., it can't be too hard to implement the commitments or nobody
| will label their products. What are other balancing
| considerations that you are having to consider? This could help
| figure out where we can "tip the scales" in comments.
| atomicfiredoll wrote:
| Has much consideration been given to labeling when a third party
| cloud or paid service is required to use the device? As somebody
| who uses IoT devices "locally" on my private network, I want to
| know my data will stay local and protected. The recent issues
| with Eufy doorbells claiming to be under local control [and
| encrypting data], but actually sending data to the cloud stands
| out to me as an example where labeling and enforcement could
| help.
|
| [0] https://arstechnica.com/gadgets/2022/11/eufys-no-clouds-
| came...
| SimingtonFCC wrote:
| Right now, the actual requirements for a label are totally up
| for grabs. This would make for a good public comment, in my
| opinion.
| atomicfiredoll wrote:
| Thank you for your response, I'll consider submitting it.
|
| For context, I've thought about commenting on issues in the
| past, but especially on the heels of the fake comments
| regarding net neutrality, for lack of a better way to put it
| I'm left feeling outgunned against such sophisticated lawyers
| and companies. This may be a little paranoid, but from a risk
| perspective I also worry about having my name attached to
| comments that go against the interests of large companies
| which dominate the marketplace. I also have hesitation about
| identity theft and uncertainty about the process.
|
| Again, thank you for bring the conversation home, so to
| speak. I'll look at the process again.
| mey wrote:
| This may have some overlap/coordination with the CPSC and FTC
| laws regarding truth in advertising.
|
| An ideal world would be that products marketed towards consumers
| would have labeling on the box, up front, of an supported until
| date. With a government definition of what that "support" means.
| Something like Google's Chromebook's Auto Update Policy (except
| properly displayed/communicated on the box/device) would be a
| good start. Nothing preventing the manufacturing from extending
| that date later, but it puts a line in the sand for the consumer
| to make a choice up front.
| consumer451 wrote:
| This is likely outside of the scope of this proposal, but my red
| team brain sees IoT devices from China as a distributed Trojan
| Horse.
|
| In a time of conflict with China, firmware updates will be sent
| which will create the largest DDOS botnet in history.
|
| Our cheap IoT lightbulbs will take down major internet
| infrastructure.
|
| I don't know the solution to that problem, but it's a problem.
| Isn't it?
| MarcoPerazaFCC wrote:
| This is something that has us worried too. The FCC took some
| action on this issue last year by outright banning equipment
| from certain companies (e.g. Huawei), but we haven't even
| scratched the surface of this pervasive problem. I really
| encourage you to share your concerns through an official
| comment. Maybe the label can include commitments about the
| provenance (and, e.g., control of signing keys) of the on-
| device software and associated cloud services?
| 0xDEF wrote:
| Look into the ESP32 chip. It's by a Chinese company and is
| used in almost all cheap IoT products.
| 0xDEF wrote:
| Not just on the firmware level. Many cheap IoT products are
| based on the Chinese ESP32 SoC.
| asynchronous wrote:
| Really thrilled to see someone in a position of influence turn to
| the HN community for comments on public policy. We could use more
| stuff like this.
| ghastmaster wrote:
| This is what civil courts are for. Otherwise let the market
| determine which manufacturers or products are reliable. This is
| nonsesne.
| pyuser583 wrote:
| This seems like a strange regulation. Companies would simply
| comply by doing pro forms updates for the sake of updating.
|
| Additionally, the update process itself introduces security
| vulnerabilities.
|
| An IoT device might have a lifespan of 20 years. Let's say a
| company is required to update for a 10 years. For the subsequent
| 10, that process is nothing more than a vector for malware
| injection.
|
| The most serious type of vulnerability is an unauthorized,
| unbounded, write operation.
|
| One of the most secure architectures is "stateless." That's where
| the software is hardcoded into the software. This proposal would
| outlaw that approach. It's not for all situations, but it should
| be seriously considered.
|
| The real solution is to hold companies accountable for
| vulnerabilities.
|
| I suspect this is better done by the FTC.
|
| Perhaps your time would be better spent fighting DRM on broadcast
| television, or ensuring cell towers aren't tracking people, or
| that phone calls have crypto enabled by default.
| userbinator wrote:
| I agree with the others about requiring the ability to modify the
| software on devices one owns, but the other major threat that you
| should take into account is the increasing use of "security" to
| justify corporate authoritarianism. In any effort to add
| regulation, let's not forget the very important principle on
| which the country was founded: freedom.
| woke_neolib wrote:
| What makes IoT devices special, and warrants carve outs for
| security / vulnerabilities?
|
| I guess I am not surprised there are security issues with these
| devices, because I think of most of them as coming from small
| companies, and wonder what the impact would be on the IoT space
| if only large players can work through more regulation.
|
| That said, I can't decide if I am more concerned about my Wyze
| camera sending data where I don't want it to, than my water
| heater leaking it's current temperature (implicating whether I am
| home or not).
| SimingtonFCC wrote:
| From the Cyber Trust Mark perspective, there's no inherent
| difference between a connected disposable gizmo and your
| example of the water heater. Personally, I would love to see a
| minimum cybersecurity commitment made by anyone who makes or
| sells anything with connectivity.
| blinkysc wrote:
| I think it should be mandatory that we have access to these
| devices with SSH or something to be able and retrieve logs or
| possibly create fixes ourselves
| starik36 wrote:
| These rules sound like reasonable steps, upon first reading. Not
| sure what the downstream effects might be.
|
| Is there any thought given to cloud based devices becoming
| paperweight when companies behind them just stop supporting it or
| turn off the API? I'd like some "assurances" in place that if the
| company either goes out of business or decides to sunset the
| service, it would be required to open source (or at least make
| available for download). If memory services, that happened to
| some Nest models a while back.
| [deleted]
| distract8901 wrote:
| I think that IOT device manufacturers should be required to
| support their device for some minimum period of time AND be
| obligated to release the full source code for the device once
| they decide to end support. This also requires releasing the keys
| to any firmware signing mechanism or publishing a firmware update
| that removes such checks.
|
| The core problem is that without control of the firmware,
| consumers don't really own these devices. The company can
| unilaterally decide one day to brick your device and force you to
| buy a new one. It should be obvious that this behavior is
| egregiously anti-consumer and anti-competitive.
| gsuuon wrote:
| This is great for hackers but doesn't it make IoT devices
| incredibly insecure for normal users who wouldn't even know
| their device has reached end of support?
| fallingknife wrote:
| This is not really a solvable problem. Whether or not your
| iot devices are out of support is just not something anybody
| has time to think about. It's right up there with those "our
| terms of service have changed" emails from your bank in terms
| of priority.
| rfoo wrote:
| > doesn't it make IoT devices incredibly insecure for normal
| users
|
| How secure or insecure a device is is unrelated to whether
| its source code is public.
|
| Disclosure: I might be biased on this, as I'm a reverse
| engineer.
| gsuuon wrote:
| Releasing source code could lower the barrier a bit but the
| main thing I was calling out is releasing the keys - maybe
| they could be transferred to a trusted custodian instead.
| hot_gril wrote:
| If it were really unrelated, nobody would pay you to
| reverse engineer.
| whats_a_quasar wrote:
| I think the parent comment is implying that if the source
| code is released at the end of the device's supported life,
| it will be much easier for hackers to find vulnerabilities.
| Then users who aren't paying attention will continue
| running that last version, and hackers will attack them
| using those now-public vulnerabilities.
|
| So you'd still need some mechanism to force-update devices
| in response to vulnerabilities found in open-source end-of-
| support firmware.
| kijin wrote:
| There's also the problem that electronic devices last a long
| time -- often much longer than any manufacturer wants to admit.
|
| Vehicles, PCs, printers, and routers can easily last 10 years.
| Refrigerators and HVAC units can last 20 years or more. And now
| we're putting "smart" stuff into electric circuits that should
| last the lifetime of the house. The manufacturer will probably
| go out of business long before those devices go out of service,
| and there's no guarantee that there will be anyone to push one
| final firmware update or release the source code in the hectic
| last few days of an imploding business.
| creole_wither wrote:
| Some sort of escrow with a dead man switch could solve this.
| They can reset the switch by releasing an update or affirming
| that they are still providing service. If no communication is
| received after a certain period of time, then it gets
| released publicly.
| motohagiography wrote:
| Seconding this thread. There is no reason why a device
| shouldn't be servicable in 30 years regardless of whether the
| vendor is still in business.
|
| There might be a way to integrate these IoT regulations with
| e-waste regulations, where the liability for disposal,
| recycling, and cleanup is related to servicability.
| Joel_Mckay wrote:
| People need to admit one can't protect systems from the unknown.
| Thus, detection and incident handling is arguably more important.
|
| If CISCO/Google/Amazon/Microsoft can't keep their systems clean,
| than you can be certain adversaries who feign ignorance will be
| much worse regardless of the paperwork.
|
| A certification program similar to EMC testing in labs would
| however be favorable, as it does not consolidate the attack
| surfaces. Additionally, it allows the test to evolve with
| emerging threat vectors.
|
| If you think companies will let people poke around their security
| policies for paperwork stamps, than you are fooling yourselves.
|
| Good luck, =)
| adolph wrote:
| The best regulation is written as if it would be implemented
| and/or interpreted in the worst possible way. As if it would be
| used by your worn enemies against you.
|
| Would manufacturers be required to brick devices that cannot be
| fixed in software? For example, if an MCU didn't have a hardware
| implementation of a particular crypto function.
|
| Could a device be sold even if the end user had to take action in
| order to update the firmware? For example, would a manufacturer
| be encouraged to have every device "phone home" for "updates"
| without a method of operating in a network where outside Internet
| is unavailable?
| herf wrote:
| 1. The platform doesn't exist to do basic things like
| authentication or push notifications, so people hack together
| expensive cloud services or do insecure things instead. There is
| no rulemaking that will help this, we just need a better and
| universal platform.
|
| 2. "Keeping things patched" works in a world with Apple-like
| margins and it simply does not in a low-volume, startup-oriented,
| competitive market. No rules pay for a company to spend $500k a
| year on a dev team when a product didn't make enough profit -
| developers cost a ton and make the prices much higher, so these
| products are not the ones that win in the market.
|
| 3. If open standards cannot satisfy #1, then we have to look for
| other corporate structures, like a "Microsoft + Intel" marriage
| where hardware can be sold for cheap but the software remains
| supported by third parties. We see some of this with cloud
| companies like Alexa, Apple, and Google Home, but it's not really
| healthy yet, because there are no incentives to do things on the
| LAN in a secure way, so we are just hiding the costs of servers
| in other ways.
| tkfu wrote:
| One thing that regulators need to be very careful about is how
| "security updates" are defined, and exactly what manufacturer
| obligations for issuing security updates should be. CVEs are a
| notoriously terrible representation of actual security risks, so
| a measure like "manufacturer must issue new releases that include
| any released patches for CVEs with a severity rating greater than
| 9" would be a clear non-starter.
|
| There are also often practical issues related to security
| patching embedded devices: for example, a downstream supplier's
| driver can make it impossible to upgrade a kernel unless/until
| the supplier provides a fix. Of course, strong regulation here
| could help to drive bad practices like that out of the industry,
| but I'm not going to hold my breath on that one. The effect of
| regulation like this would make it harder for manufacturers who
| don't have the market power to lean on their suppliers to provide
| security patches.
|
| Finally, it's important that any regulation that mandates or
| strongly encourages software updates also mandates that the
| update system itself be implemented in a secure way. This is my
| specific area of expertise, and I can tell you that it's very
| often done very badly. A bad update system is a gigantic,
| flashing red target for attack. So something like mandating
| signatures (and sig validation) on software update images would
| be a good start. Mandating the use of TUF-compliant repositories
| would be even better.
| MattPalmer1086 wrote:
| While I acknowledge that CVE scoring of risk can be
| inconsistent and sometimes wildly wrong, what would you suggest
| in its place?
| slt2021 wrote:
| just go by past incidents. Quite often it is not software
| vuln that enables hacker's attack - it is insecure default
| config that user never changes and manufacturer supplies same
| default user/pw with each device.
|
| also insecure backdoors left by developers for debug purposes
| (or is it really debug or maybe espionage?)
| Animats wrote:
| > also insecure backdoors left by developers for debug
| purposes (or is it really debug or maybe espionage?)
|
| It should be made clear that any "backdoor" is a criminal
| offense under the "unauthorized access" provision of the
| Computer Fraud and Abuse act, unless the device is covered
| by an explicit remote maintenance agreement which imposes
| duties upon the maintainer.
| tkfu wrote:
| That's the problem, there isn't a good objective measure.
| Some type of "reasonableness" standard is usually invoked in
| situations like this, but that kinda just takes us back to
| square one: what's currently considered reasonable in the
| industry is pretty terrible.
| MattPalmer1086 wrote:
| I'm not sure we will ever have a universally accepted
| objective measure of risk. Risk is, by its nature, somewhat
| subjective.
|
| Most organisations will use CVEs and the CVSS system as a
| starting point, but will triage them and produce their own
| assessment of the actual risk to them and their products
| given how the software is used.
| whats_a_quasar wrote:
| I don't think a legal reasonableness standard would be the
| same as "common industry behavior." Regulation would hold
| companies to a real reasonableness standard, as determined
| in the text of the regulation or by a court.
| SimingtonFCC wrote:
| My two cents is that this would be an excellent comment on the
| record -- I'd love a discussion at the level of defining
| security risks to be part of the official federal commentary,
| because this is going to be a thorny implementation problem.
| holmesworcester wrote:
| It would be great for people to post an update like "comment
| submitted" on threads like this one to make sure it was
| entered as a comment into the official record.
|
| I'm sure these comments in themselves are helpful to
| @SimingtonFCC individually, but having them be part of the
| official record gives the FCC _legal grounds_ to consider
| them and incorporate them into rules.
| SimingtonFCC wrote:
| Completely agree! The public record in this case is going
| to be what agencies and industry looks to, far more than
| whatever I might happen to personally believe. I'm going to
| get as much information from this discussion as I can, but
| every participant should feel free to comment on the
| record, or to get their employers, companies, trade
| associations, ad-hoc working groups, concerned citizens
| congregating on Discord to complain, etc. to do so as well.
| rollcat wrote:
| > There are also often practical issues related to security
| patching embedded devices: for example, a downstream supplier's
| driver can make it impossible to upgrade a kernel unless/until
| the supplier provides a fix. Of course, strong regulation here
| could help to drive bad practices like that out of the
| industry, but I'm not going to hold my breath on that one. The
| effect of regulation like this would make it harder for
| manufacturers who don't have the market power to lean on their
| suppliers to provide security patches.
|
| This. We were building an IoT product that was effectively
| stuck on a derivative of Ubuntu 18.04; we couldn't upgrade
| because vendor wouldn't rebase on a new LTS for a very long
| time. As our project was being developed in Python, we were
| stuck on 3.6, and as it reached EOL, many third-party libraries
| dropped support and wouldn't even release security fixes; we
| needed to stay on that particular OS because of hardware
| support; and moving off the distribution-provided Python
| packages would increase maintenance burden beyond what we were
| able to handle.
|
| Even if the vendor would continue to provide security updates
| to the base OS and its packages, any real-world software
| solution will rely on third party packages, which may choose to
| drop support.
|
| I would love it if the lawmakers considered this scenario.
| vkou wrote:
| > I would love it if the lawmakers considered this scenario.
|
| You're building on quicksand, and you're asking for us to
| give you leeway when the building collapses.
|
| Either do the work of making all of those security fixes
| yourself, or pick a better platform to build on top of.
| rollcat wrote:
| > pick a better platform
|
| Unfortunately there isn't all that much competition in this
| space. The choice was try building on quicksand, or let the
| idea die. I'm glad we tried it.
| vkou wrote:
| Until there are consequences for building on quicksand,
| the vendors have no reason to improve their offerings.
| cstejerean wrote:
| > stuck on a derivative of Ubuntu 18.04 [...] as our project
| was being developed in Python, we were stuck on 3.6
|
| I might be missing something but why do you need to rely on
| the OS provided Python version? Newer versions that 3.6
| should run on older Ubuntu versions. You could have installed
| newer versions using the deadsnake PPA for example onto 18.04
| up until earlier this year (since LTS only has a 5 year
| support window, and deadsnakes only supports active LTS
| versions).
| rollcat wrote:
| If we had the resources to disentangle the entire Python
| situation, trust me we would. Unfortunately the web of
| dependencies for that project was quite intricate, and at
| one point you just need to swallow the vendor's proprietary
| libraries that they've built against what they've shipped
| in the base OS. (L)GPL is good on paper, but the effort to
| actually make use of the freedom it grants is
| disproportionate.
|
| (Which is why I'm a firm believer in the suckless
| philosophy: if the software is too complex to fully
| understand, source access or even copyleft aren't worth
| much.)
| Trombone12 wrote:
| As the support schedule for python is known ahead of time,
| this scenario seems pretty well covered by "disclosure of how
| long the product will receive security updates": just choose
| the EOL for the relevant python version in the date-picker.
| oezi wrote:
| Then fire your shitty vendor or refund your customers.
|
| Nothing will change unless everybody changes.
| jnwatson wrote:
| You can't fire your SoC vendor especially once the product
| ships. And their are all PITA about security updates.
| oezi wrote:
| If you buy from a supplier with a contract that
| stipulates security updates then you certainly would
| define the damages which failure to fix will cause you,
| wouldn't you?
| AnthonyMouse wrote:
| One of the issues is that the upstream vendor goes out of
| business. What you really need is to have the source code
| for the firmware, ideally in the public mainline kernel
| tree so that new kernel versions continue to work on the
| hardware.
| oezi wrote:
| Certainly true. Source code escrow should be part of any
| kind of company selling internet connected devices.
| cycomanic wrote:
| This is an honest question to these arguments, but as a
| consumer (and as an extension the FCC protecting them) why
| should I care? Would you accept the same arguments from your
| car manufacturer, "sorry we can't fix your broken brakes, our
| supplier uses a process that isn't supported by new brake
| standards so just don't brake"?
|
| I suspect not, so why not because the car is more expensive?
|
| I would argue that the purpose of regulation is exactly to
| root out this sort of practice. If it was cheap and
| effortless to do this we likely wouldn't need regulation.
| svnt wrote:
| The same thing happened to my car -- they discontinued
| support for the cellular module it shipped with. I had to
| bring it in (and I believe pay something) to have the
| module updated. I did not and now it no longer has the
| online functionality.
|
| Brakes are not internet-connected, but where the line is
| between features or functions that might be lost and those
| that represent the core of the product is an interesting
| question.
| rollcat wrote:
| Brakes are fundamentally both a safety-critical system,
| and one that is both relatively well isolated from other
| systems, and dead simple in principle (a bike has simple
| mechanical brakes and a 3yro could explain why they
| work).
|
| The issue with software OTOH, is that a security hole in
| one trivial component (e.g. resize images to make
| thumbnails) can often lead to a full system compromise.
| Even if you don't get full root, you can still use a
| compromised system to your advantage: steal personal
| data, use it in a botnet, serve malware, mine proof of
| waste, etc.
|
| On top of that, adding a dependency is often made very
| easy by modern package managers, and as the number goes
| up it gets rather difficult even to vet your direct
| dependencies, let alone transitive. Installing brakes in
| a vehicle doesn't automatically pull in a kitchen sink,
| but in the software world it's widely accepted, almost
| inevitable. You can spend your time removing the 90% of
| that library that you don't need, and rewriting the
| remaining 10%, or you do the "reasonable" thing and just
| ship.
| TeMPOraL wrote:
| That's the thing though: most IoT devices _shouldn 't_ be
| Internet-connected, and most definitely _should not_
| depend on a vendor _cloud_ (or increasingly, a cloud of a
| different vendor that sold white-label IoT solution to
| the "vendor" you you bought the device from). It's an
| unnecessary limitation, a combination of laziness (going
| over cloud is easier than figuring out local-first and
| standardizing on some VPN solution) and abusive business
| (the cloud on the other side of the world is holding your
| Internet-connected air conditioner hostage, better play
| nice).
|
| If brakes are not Internet-connected, that's mostly
| because they were established before Internet - and given
| the trends in car manufacturing in general, it's only a
| matter of time.
|
| (In some sense, we're already there - if you have cloud-
| connected self-driving, and that self-driving can
| override your command to apply brakes, then your brakes
| are de-facto Internet-connected, even if connectivity
| isn't a hard dependency in all cases just yet.)
| AnthonyMouse wrote:
| The issue is that it's currently _not_ a regulatory
| requirement. So when you go to the chip maker and demand
| that their chip have drivers in the Linux kernel tree so it
| will continue to support newer kernel versions, they turn
| you down. Most of their customers don 't care about this
| and they would have to pay a developer to produce drivers
| of the quality that would be accepted by the Linux kernel
| maintainers. Then you're stuck using what you can get.
|
| If you had a rule saying that device makers have to produce
| security updates, now the device makers will all demand
| this because they need it to satisfy the regulatory
| requirement, and not be willing to take no for an answer.
| cycomanic wrote:
| I don't understand your argument, are you agreeing with
| me that regulation will cause this to happen? So why is
| that an argument against regulation?
| AnthonyMouse wrote:
| It's an argument for getting the regulation right.
|
| For example, one of the obvious ways around these
| requirements is you set up Sell To Retailers, LLC which
| nominally does the final assembly, is responsible for the
| update requirement and then files for bankruptcy whenever
| anyone tries to enforce it against them.
|
| The bad way to get around that is to try to hang the
| requirement on some kind of larger entity, like the
| retailer. Then every retailer bans every kind of smaller
| device maker who might not be around to make updates in
| ten years and you have a rule that unintentionally causes
| catastrophic market concentration.
|
| The good way is to require that the customer can flash
| custom firmware to the device and the hardware has
| sufficient published documentation for a third party to
| make drivers for it (the easiest way to satisfy which
| would be to publish open source drivers and firmware).
|
| That way if the manufacturer goes bust, as some of them
| will even independent of trying to get out of the
| requirement, someone else can still patch the device. And
| that someone will be more likely to exist, because
| communities like DD-WRT will have already produced custom
| firmware for the device and be there to patch serious
| vulnerabilities even if the manufacturer is gone.
| dmurray wrote:
| Under sensible regulation you wouldn't get to blame a third
| party here. You would have signed a contract with your vendor
| to give you updates in line with what the regulation demands,
| and your insurance company would cover your liability if the
| vendor goes out of business and you have to pay through the
| nose to replace them or settle a class action lawsuit. Your
| expenses would go up and those would be passed on to the
| consumer, but everyone cheering for this regulation is OK
| with that. Hopefully the marginal cost of insurance and
| better vendors would be only slightly above the cost of
| providing this kind of long term support.
| xp84 wrote:
| > regulation like this would make it harder for manufacturers
| who don't have the market power to lean on their suppliers to
| provide security patches.
|
| Thought question (I'm asking, I don't know the "answer"):
|
| Today, many of these devices are marketed and sold by a company
| that has little to no involvement in the creation of the
| firmware or software, besides maybe sending over an image of
| their logo to be rolled into some turnkey "app." Would we
| actually be better off if companies couldn't really afford to
| basically dropship some sketchy white-label Chinese product,
| and instead could only sell a product here if they were
| confident they (acting alone) would be fully capable of
| supporting and updating it for a reasonable lifetime? Yes, it
| would raise the barrier to entry above basically the floor
| where it is today, but I don't imagine there is a way to have
| it both ways.
| btown wrote:
| I'm curious about your thoughts on balancing the damage of
| another Mirai with the damage of another SolarWinds. A
| regulation where every IoT device must accept a signed OTA
| update would make update servers an extremely valuable target
| for supply chain compromises.
|
| On the one hand, without updates, a world of IoT devices will
| inevitably get infected slowly and permanently (as long as
| they're physically active).
|
| But on the other hand, with mandatory updates, a world of IoT
| devices can get infected all at once (in the case of a supply
| chain attack) and possibly just as permanently (if the
| attacker's payload can disable or re-route the update system)?
|
| Do you think that prevailing security standards for IoT
| manufacturers are good enough that this balance falls in favor
| of a mandatory-update regulation?
| SimingtonFCC wrote:
| I don't know about a mandatory update regulation -- one way
| or the other, that isn't on the table right now. I would love
| extensive discussion on the record, however, of the costs and
| benefits of requiring updates to get the label.
| MarcoPerazaFCC wrote:
| Thank you for these thoughtful points. Some relevant responses
| from other threads:
|
| From https://news.ycombinator.com/item?id=37394188 :
|
| I think you're right that it would be difficult for the FCC to
| precisely define exactly when security updates are required.
| This is a problem in law generally, one that is usually
| resolved by imposing a reasonableness standard. Maybe here, a
| vulnerability needs to be patched if it might reasonably be
| expected to allow an attacker to take control of a device, or
| to do so when combined with other known or unknown
| vulnerabilities. Or maybe a different standard. Then when
| enforcement/lawsuits come around, the judge/jury/regulator has
| to evaluate the reasonableness of the manufacturer's actions in
| light of that standard. We'd love to see commentary on the
| record as to what the right legal standard might be.
|
| From https://news.ycombinator.com/item?id=37394793 :
|
| Agreed. Building an automatic firmware update system from
| scratch would be burdensome for many IoT makers, but as it
| becomes necessary or encouraged, we would expect the market to
| provide a packaged solution/framework that manufacturers could
| fold into their products. It would be really helpful have to
| discussion of this on the record. How generalizable do you
| think such a solution could be? We are aware of the Uptane
| project, an OTA firmware update framework being jointly worked
| on by several car manufacturers, but would love to hear more
| about the feasibility of a solution for IoT devices generally,
| or particular classes of IoT devices.
|
| From https://news.ycombinator.com/item?id=37393926 :
|
| [...] companies wanting to put a label on their product would
| probably want to extract similar guarantees up their supply
| chain. Especially with a voluntary program like the one the FCC
| is proposing, good practices won't become the norm across the
| market overnight. But maybe, at the very least, the segment of
| product and component makers that take security seriously will
| begin to grow. I encourage you to share your thoughts in an
| official comment.
| baby_souffle wrote:
| > How generalizable do you think such a solution could be? We
| are aware of the Uptane project, an OTA firmware update
| framework being jointly worked on by several car
| manufacturers, but would love to hear more about the
| feasibility of a solution for IoT devices generally, or
| particular classes of IoT devices.
|
| One thing to be aware of: a decent number of connected
| devices are white label devices or "lightly" tweaked forks of
| a reference design. The consumer-facing company may have no
| power to actually update anything. If the originating company
| only provides proprietary versions of some critical component
| and can't/won't ship updates, the consumer-facing company can
| only patch issues with _their_ portion of the final software
| running on the device.
|
| A _requirement_ that the consumer-facing company be able to
| update any/all portions of the software stack for
| $someTimeFrameAfterSale might start to change this but expect
| a fight from every link in the software-supply-chain on this
| front.
| perihelions wrote:
| You're the lawyer guy? What statutory authority are you
| drawing on that you believe allows you, the FCC, to regulate
| this stuff?
|
| Thanks!
| MarcoPerazaFCC wrote:
| Good question. The Notice of Proposed Rulemaking has a
| Legal Authority section that discusses this issue
| https://www.fcc.gov/document/fcc-proposes-cybersecurity-
| labe.... I also touch on it here
| https://news.ycombinator.com/item?id=37393316
| perihelions wrote:
| Thanks, but, that FCC document clearly says it's about a
| "voluntary labeling program", and, the title of this HN
| post has the word "regulation" and the text has language
| like "require" [0]. And the phrase "oppose[...] even
| voluntary ones", which clearly sounds like someone's
| proposing non-voluntary stuff.
|
| I read your linked HN comment too, but: "legitimate
| interest in" [1] a thing and actual "authority" to do a
| thing are not the same thing.
|
| I feel like I'm being bamboozled here. The fcc.gov
| "Notice", and this HN post, seem like they're talking
| about substantially different proposals.
|
| [0] _" I've advocated for the FCC to require device
| manufacturers to support their devices with security
| updates for a reasonable amount of time"_
|
| [1] _"...we think that the FCC has a legitimate interest
| in just about any vulnerability on a wireless device "_
| pierat wrote:
| Maybe, reach out to the FTC over the fraud that's being
| perpetuated with this cloud-locked (other peoples'
| servers) *rental* being sold as a *sale* ?
|
| If these companies are selling defective goods and
| preventing individuals to fix it themselves (in other
| words, the selling company holds material control of the
| device), that's a *rental* .
|
| Properly reclassifying consumer garbage with company-
| locked electronics as a rental would be the big kick-in-
| the-pants that nearly every company is playing now. And
| that includes the cellphone-on-wheels (Tesla), the stunts
| being played by most other car manufacturers ($$$ for
| heated seats, etc), Apple holding control over what
| approved software a general purpose computer can process,
| and loads more.
|
| I don't think the FCC can require firmware updates other
| than in radio based units, to require regulatory
| requirements for specific frequencies (2.4GHz no channel
| 12/13 in USA, 10 minute wait on a part of 5.8GHz for
| ground radar). But the FTC could force it by clarifying
| cloud-crap is a rental, and not a sale.
| whats_a_quasar wrote:
| Nathan's post and the proposed rulemaking are both quite
| explicit that the proposal under comment is a voluntary
| labeling scheme. Perhaps the intro could be better
| written to be clearer, but I don't really understand your
| complaint. There's no bamboozle.
|
| From above:
|
| "I've advocated for the FCC to require device
| manufacturers to support their devices with security
| updates for a reasonable amount of time [1]. I can't
| bring such a proposal to a vote since I'm not the
| chairman of the agency. But I was able to convince my
| colleagues to tentatively support something a little more
| moderate addressing this problem.
|
| The FCC recently issued a Notice of Proposed Rulemaking
| [2] for a cybersecurity labeling program for connected
| devices. If they meet certain criteria for the security
| of their product, manufacturers can put an FCC
| cybersecurity label on it. I fought hard for one of these
| criteria to be the disclosure of how long the product
| will receive security updates. I hope that, besides
| arming consumers with better information, the commitments
| on this label (including the support period) will be
| legally enforceable in contract and tort lawsuits and
| under other laws. You can see my full statement here
| [3]."
| SimingtonFCC wrote:
| Thanks! Sorry for any lack of clarity. My initial draft
| was way over the character limit and I had to cut a lot
| prior to posting. Thanks for highlighting the relevant
| language and clearing things up.
| whats_a_quasar wrote:
| To expand on this, since it's not explicit in Marco's
| comment: The statutory authority is section 302(a) of the
| Communications Act, which authorizes the FCC to regulate
| devices that can interfere with radio communication.
| Their reasoning is that IOT devices fit this category, so
| regulations on security updates are within scope.
|
| Full quote from the notice of proposed rulemaking: "In
| particular, section 302(a) of the Communications Act
| authorizes the FCC "consistent with the public interest,
| convenience, and necessity, [to] make reasonable
| regulations (1) governing the interference potential of
| devices which in their operation are capable of emitting
| radio frequency energy by radiation, conduction, or other
| means in sufficient degree to cause harmful interference
| to radio communications; . . ." While this program would
| be voluntary, entities that elect to participate would
| need to do so in accordance with the regulations the
| Commission adopts in this proceeding, including but not
| limited to the IoT security standards, compliance
| requirements, and the labeling program's operating
| framework. We tentatively conclude that the standards the
| Commission proposes to apply when administering the
| proposed labeling program fall within the scope of
| "reasonable regulations... governing the interference
| potential of devices...." We seek comment on this
| reasoning."
| heroprotagonist wrote:
| Can we actually trust the FCC comment process now? It's been
| astroturfed by interest groups for well over a decade now and
| that's only getting worse with AI generated content.
| elicash wrote:
| Unilaterally disarming seems bad. But yes, I'd agree a rethink
| of the process could take into consideration it doesn't
| represent public sentiment, though I have no alternative
| solution in mind.
| throw1234651234 wrote:
| Could you summarize what these "security updates" would entail?
| There are 1000s of attack vectors, so it would be difficult to
| practically define.
|
| It's awfully vague to the point of just being more regulation
| that allows selective enforcement, which reduces competition and
| leads to boilerplate allowing FCC department growth, without
| improving the situation.
|
| It will serve as a barrier to entry to new entrants. What's
| worse, is that this will create the _illusion_ that IoT is in any
| way secure. Some IoT _is_ secure, but that standard is
| unrealistic to apply to consumer devices.
| at_a_remove wrote:
| Someone smarter than I and more versed in the legal matters
| should shape this concept: if you go bankrupt, your source code
| gets released. I can already see some small problems with this
| but the general thrust is, I think, not unreasonable.
| wjat wrote:
| How about requiring devices to implement key security-relevant
| features in an immutable way, such as via FPGA, so that attackers
| have no way of circumventing those features even post EoS.
| eru wrote:
| Good luck patching security problems then?
| w10-1 wrote:
| Neither regulation nor market mechanisms can really address the
| problem of device security:
|
| There's virtually no overlap between the transactions of (1)
| purchasing the device for use, and (2) maintaining the device for
| security.
|
| All the transaction features differ: different parties, different
| interests, different type of transactions, different risks.
| That's a recipe for exporting costs that no market mechanism or
| regulatory scheme can fix.
|
| The best way to handle these is to have official succession
| plans: the manufacturer needs to delegate to a support
| organization for every product, and every product in use needs a
| way to indicate if it is up-to-date with support. The FCC
| maintains the database of support organizations for every FCC-
| certified device.
|
| Everything can flow from that, from current to future legal and
| market contexts.
|
| - Support organizations can take on devices. (Using open-source
| would be a particularly effective approach.)
|
| - Ordinary negligence can attach to users without support or
| support organizations who fail to address a risk they know of.
|
| - Support can be separately regulated
|
| - Because support organization (like insurance companies) are
| taking on the risk, they will discipline manufacturers, raising
| the cost of producing unsupportable devices.
|
| - Effective manufacturers might elect to internalize support
| (leveraging confidential information) or focus on manufacturing
| per design.
|
| - Support organizations may start contracting manufacturers by
| design, to reduce overall costs considering the entire lifecycle.
|
| Politically, I believe manufacturers seeking to avoid regulation
| would accept regulation if they have the alternative of
| offloading it to support organizations. Those organizations would
| welcome regulation as part of their moat. Large device users
| would welcome support organizations who can supply the service
| they need, and support can extend their expertise into consumer
| markets. Cost/price and the payer would track the value and cover
| the entire lifecycle.
| askIoT wrote:
| Been in the IoT space for over 10 years and this is much needed.
| In my experience, Cellular based IoT devices are inherently more
| secure than non cellular devices due to the network security and
| the certifications they go through. Of course, there are
| exceptions to this rule. Would be interested to learn more about
| the proposed regulations while not impacting the pace of
| innovation.
| cuttothechase wrote:
| All Internet supported devices should explicitly provide
| documentation about their functional behavior when there is no
| internet.
|
| A few examples-
|
| - internet enabled lights should say if they light up if no
| internet is available.
|
| - internet enabled exercise equipment should say what is
| operational and what is not when there is no internet.
|
| - automobiles should provide thorough documentation about what
| does not work and what does work when there is no internet
| dtaht wrote:
| This is not really relevant to the proposed rulemaking but it is
| something that bugs me deeply, and would like to get off my
| chest. I would like to see a mandate that red LED be wired inband
| to _every_ camera and microphone, on every device, so if it is
| powered up, the LED is also. This is what John Gilmore proposed
| in 2004, and we adopted in the OLPC project, as the first step
| towards not being ubiquitously surveilled. It is low cost, low
| power, and easy to implement.
| MarcoPerazaFCC wrote:
| I encourage you to file a comment suggesting this. It's
| actually not irrelevant. The FCC is free to decide that the
| label (which can include a QR code linking to more information)
| must include information about cameras and microphones and
| whether there is a software-tamper-proof way to tell whether
| they are on. Or the existence of a hardwired LED could even be
| a requirement to qualify for a label. Your experience with the
| OLPC project would really bolster the credibility of your
| comment as well, so don't forget to mention that.
| takinola wrote:
| It seems to me that a law based on technical specifications is
| going to be hard to define and harder still to enforce. Perhaps,
| it may be easier to employ market forces to incentivize the
| manufacturers to secure (and continue to secure) their devices.
|
| For instance, can there be a remediation fund that manufacturers
| pay into to compensate/support users for privacy or security
| breaches involving their devices. The amount they pay would be
| based on the number of the devices involved and the severity of
| the issue (PII, loss of amenity, network nuisance, etc). The rate
| paid could also be reviewed periodically to ensure the amount is
| not too low or too high. This way, companies can put a literal
| price on security and factor it into their product strategy and
| planning.
|
| The advantage of this approach is two-fold. It internalizes the
| cost of security so it is no longer an externality that is be
| foisted on consumers. It also allows companies to apply their
| innovation towards addressing the issue without hamstringing them
| into a regulation prescribed approach that may become outdated
| over time.
| geuis wrote:
| Your solution is a sticker? Seriously?
|
| It does absolutely nothing. It will simply be ignored. At most it
| will be an excuse for manufacturers to increase the price of a
| product simply because it has some "FCC APPROVED" sticker, while
| not costing any more to manufacture.
| tschellenbach wrote:
| I think the regulation should classify products differently.
| Something that records audio and video should require a high
| level of security and support. Something that wirelessly controls
| my sprinklers maybe not as much.
| tsegratis wrote:
| One suggestion for medical devices -- and in general any
| situation where the consumer cannot asses what they're buying,
| but is important is mandated ratings, such as for tyres
| https://www.goodyear.eu/en_gb/consumer/learn/eu-tire-label-e...
|
| Since security (medical safety etc etc) are hard to measure and
| therefore hard to enforce, the labels help everybody, because
| they encourage and measure best practice, rather than the
| unmeasurable, allowing sellers to advertise and demonstrate on
| that basis -- so helping everyone
| coldpie wrote:
| FWIW, seeing a security compliance label on an IoT product
| wouldn't mean anything to me as a consumer. There is no such
| thing as computer security in 2023, and there are no hints that
| security will exist at any point on the horizon. Even the biggest
| names in the field cannot put out secure products. Products from
| well-meaning manufacturers are going to be absolutely riddled
| with security problems, and putting a sticker on the box won't
| change that. It is literally impossible to put out a software
| product with anything resembling security today. It'd be like
| putting a "secure against bricks" sticker on a window. Our
| industry is a joke. Building secure software products can't be
| done without completely rearchitecting how our industry operates,
| which isn't going to happen.
| callalex wrote:
| This take is simply not based in reality. Compare what it took
| to gain root access to a computer 20 years ago to a modern
| iPhone and tell me again that there is absolutely no point in
| caring about security.
| soylentcola wrote:
| Amusingly enough, being able (or not being able) to gain root
| access to my _own_ devices is one of the main reasons I can
| 't address or verify their security - especially as official
| support is dropped over time.
|
| Modern phones and other appliances have (or are) computers to
| which it is nigh impossible to operate as root. You might say
| you have to pwn them even if you supposedly own them ;)
| SimingtonFCC wrote:
| I understand your skepticism. That's why I want to see the
| label functioning as something like an enforceable
| representation to consumers. If someone wants to sell brick-
| proof glass, and get a sticker from the US Government saying
| so, it better be brick-proof.
| coldpie wrote:
| Well, my comment is predicated on the, apparently erroneous
| :), assumption that no glass is brick-proof. It is impossible
| to build a secure software product with our current tooling &
| development practices. The number of security flaws in every
| software product is so high as to make the label meaningless.
| I don't think there's a meaningful distinction to end
| consumers between "this product has 1,000 holes, 100 of which
| are publicly disclosed" (i.e. no label) and "this product has
| 900 holes" (i.e. with label).
| daveevad wrote:
| > the, apparently erroneous :), assumption that no glass is
| brick-proof
|
| That reminds me of:
|
| > With sufficient thrust, pigs fly just fine.
|
| https://www.rfc-editor.org/rfc/rfc1925
| MattPalmer1086 wrote:
| I completely agree that it is meaningless to assert that
| something is "secure". Even very well secured things have been
| hacked, and the smallest of mistakes can have huge impact.
|
| What would be meaningful is an assertion that some basic set of
| secure practices have been or are followed. For example, that
| there are no default passwords on a device, that security
| updates will be provided on some defined schedule, that network
| protocols meet some reasonable standard of security, etc.
| eru wrote:
| > It'd be like putting a "secure against bricks" sticker on a
| window.
|
| I lived in a house that had such secure windows. I even
| witnessed someone trying and failing to smash a window with a
| brick.
| dylan604 wrote:
| we installed a storm door not for protection against storms,
| but an intruder armed with a brick and/or hammer because our
| front door was 85% single pane of glass.
|
| it seems like a bad analogy on the GP's part
| Maximus9000 wrote:
| Does the IoT company called "Eve" give hope to the industry?
| From what I understand, they take a security first approach to
| their IoT products. I haven't tried them out yet though.
| kristianbrigman wrote:
| I think this might be useful if we kind of wargame prospective
| regulations to follow all the ways people might abuse it, then
| you might get something that works. Maybe lawmakers already do
| that? This thread feels in that spirit too...
| NegativeK wrote:
| > There is no such thing as computer security in 2023
|
| This is absurd.
|
| Even the passive basics like relying on your free email
| provider's filtering and running Windows Defender is going to
| stop a huge number of attacks.
|
| If you're expecting perfect security, you'll be disappointed --
| but we can't declare complete bankruptcy.
| coldpie wrote:
| Scroll down: https://arstechnica.com/author/dan-goodin/ This
| is just a teeny tiny sampling of the security vulnerabilities
| disclosed every day. Our industry is just not built with
| security as a goal, and even if we started caring about it
| today, we have 50 years of not caring to patch up. Caring
| about security in a meaningful way (i.e. formal verification,
| engineer licensing & liability) is really, _really_
| expensive. No one is going to carry that burden when their
| competitors don 't have to. The end result is the situation
| we find ourselves in: there is no such thing as computer
| security, and any networked computer should be considered
| compromised by default.
| NegativeK wrote:
| I'm sorry, I can't really debate with a reductionist claim
| that everything is 100% fucked when it's readily apparent
| that some threat actors are still being stopped.
|
| For what it's worth, I'm not disagreeing with your points
| about needing drastic, systemic improvements in how we
| handle security.
| meltyness wrote:
| When are you going to rip out the Lazy Susan that manufacturers
| use to EoL equipment on an unbelievably aggressive timeline and
| force governments, agencies, and state universities to throw away
| perfectly good equipment that is no longer "supported"?
| johndhi wrote:
| I'm generally skeptical of the efficacy of regulation to solve a
| problem. Can you please cite some examples of where FCC
| regulation has been successful in solving other problems, and
| explain why you believe iot security regulation is likely to
| help?
| arrosenberg wrote:
| Your skepticism seems ideological, rather than practical. The
| FCC manages frequency bands, without which most technologies
| that rely on long-band EM spectrum would become a mess of
| conflicting signals.
| ncallaway wrote:
| Since your skepticism of regulation seems broad, it seems
| unfair to cabin examples to just the FCC.
|
| Why not look at the food quality changes between 1905 and
| today? Those have largely been won on the back of serious
| regulation through the FDA (and it's predecessor), as well as
| labeling requirements. Both of those regulations have had
| significant improvements in the lives of consumers.
|
| Honestly, I have a very hard time seeing a downside to
| regulation that solely mandates a more transparent marketplace.
| The free market only actually works when an effective
| marketplace is possible, and that _requires_ transparency.
| Without transparency, "free markets" are less likely to
| produce efficient outcomes.
| johndhi wrote:
| Hmm I don't know the food quality area super well but I am
| sure it's hard to confirm improvements were caused by
| regulations and not technology, right?
|
| The idea of transparency is interesting to me. I used to
| agree with you that more is better but I no longer feel that
| way. Prop 65 in California is one example where there are
| stickers saying 'this might give you cancer' basically
| everywhere and we all ignore them so often that we start
| worrying about cancer less. It's not a good thing.
|
| Imo existing laws regarding misleading marketing and accuracy
| are probably all that we need (perhaps increased enforcement)
| for something like iot security updates.
| ncallaway wrote:
| > but I am sure it's hard to confirm improvements were
| caused by regulations and not technology, right?
|
| For a good summary of the history of food safety I'd
| recommend: https://www.ncbi.nlm.nih.gov/books/NBK221553/
|
| Often the regulation _drives_ the technology. There is no
| inherent business need to create new technologies that
| improve the food safety, outside of demand from consumers
| or regulators.
|
| > In 1909 the American Public Health Association appointed
| a committee to develop a "standard" bacteriological
| technique for screening oysters and other shellfish, which
| recommended use of a tube dilution method for the presence
| of Escherichia coli. In an effort to gain data on levels of
| contamination, USDA's Bureau of Chemistry conducted an
| extensive bacteriological study along the Atlantic and Gulf
| coasts between 1908 and 1910.
|
| Again, though, consumers can only register there
| preferences with the _existing_ market. So if they want
| _safer_ foods than are available on the market, there is no
| real way for them to register that desire.
|
| > In the absence of government standards, companies willing
| to spend funds to assure protection of the public health
| are disadvantaged by the need to compete with companies
| unwilling to do so, because the latter could sell their
| products at a lower price. Some consumers might be willing
| to spend more on a "better" or "safer" product; poorer
| consumers, of course, would be unable to do so and would
| bear greater food safety risks than more affluent
| consumers. Price differentials for safer products would not
| be possible in many parts of the food marketplace, however,
| as most foodstuffs are sold as unbranded commodities at the
| beginning of the food chain, and often (as with most meat,
| poultry, and produce) at the retail level. Thus, even if
| society were willing to rely upon the market to encourage
| food safety, it is unlikely to be an effective producer of
| safety because of the commodity nature of most food
| transactions, as well as the difficulty of connecting
| foodborne illness with particular eating occasions or
| individual foods. For the same reasons, personal injury
| litigation provides only a weak incentive for food
| companies to improve their food safety efforts, because
| there is a low probability that they will be sued for
| foodborne illness, the damages they would pay are likely to
| be small, and there is a low probability that such
| litigation would have negative public relations
| consequences (Buzby and Frenzen, 1999).
|
| > Imo existing laws regarding misleading marketing and
| accuracy are probably all that we need
|
| Many of the food safety laws that exist are exactly to
| prevent this exact kind of misleading marketing and
| accuracy. Or, in other cases, to force them to make
| _specific_ claims that can be later enforced rather than
| generic claims that can never be enforced.
|
| In my mind, an analog to "put on the box how long security
| updates will be provided" are "nutrition facts", in that
| these don't just say: "everything on the box must be true",
| but also: "you must disclose some specific things about the
| product".
|
| The introduction of nutrition labeling changed both
| consumer behavior, and the products being offered to
| consumers:
| https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6340779/
|
| > In pooled analyses (Table 2), food labeling reduced
| intakes of energy by 6.6% (95% CI= -8.8%, -4.4%. n=31
| estimates; Appendix Figures 1 and 2), total fat by 10.6%
| (95% CI= -17.7%, -3.5%, n=13; Appendix Figures 3 and 4),
| and other unhealthy options by 13.0% (95% CI= -25.7%,
| -0.2%, n=16). Food labeling increased vegetable consumption
| by 13.5% (95% CI=2.4%, 24.6%, n=5; Appendix Figures 13 and
| 14).
|
| > ...
|
| > Reformulation outcomes were evaluated by six studies
| (Appendix Table 13, Appendix Figures 20-24). Food labeling
| significantly reduced the contents of trans fat (-64.3%,
| 95% CI= -91.1%, -37.5%, n=3) and sodium (-8.9%, 95% CI=
| -17.3%, -0.6%, n=4). Significant effects were not
| identified on product contents of total energy, saturated
| fat, dietary fiber, or other healthy (protein and
| unsaturated fat) or unhealthy (total fat, sugar, and
| dietary cholesterol) dietary components.
|
| Bringing it back to this topic that would mean forcing them
| to make a statement like: "we will provide security updates
| for 3 months" in small print somewhere on the packaging,
| rather than _only_ having the phrase "WORLD-BEATING
| SECURITY" in 45pt font on the front. And, again, all of
| this is _voluntary_ , and only required if they want to
| display a specific logo.
|
| I honestly can't see _any_ argument for how this would be
| objectionable. I don't think existing laws are sufficient,
| because they don't require a company to make any specific
| claims. As such, _no_ companies make any specific claims
| about security, which means as a consumer I have *no*
| ability to express a preference in the market for products
| that make stronger claims about security.
| Bjartr wrote:
| As far as effective regulation from the FCC goes, one example
| would be how well 911 works (and that it actually works on cell
| phones in addition to landlines). It's because the FCC mandated
| telecoms include 911 capability, and that it always work,
| regardless of the subscription status for that line.
|
| Another success would be regulation that closed captioning be
| included in broadcast media, and support for displaying them by
| consumer devices.
| johndhi wrote:
| Good examples! I'm more familiar with 911 but I know it also
| contains nightmare pains in the butt (e-911 software
| requirements).
| phkahler wrote:
| >> If they meet certain criteria for the security of their
| product, manufacturers can put an FCC cybersecurity label on it.
| I fought hard for one of these criteria to be the disclosure of
| how long the product will receive security updates.
|
| I think labeling may be a good idea. Requiring updates is
| probably not a great idea. For most of my things I prefer they
| not auto-update, as that invites another whole world of problems.
| Jiro wrote:
| What's to prevent companies from saying "our profit is more
| important" and not putting on the label?
| _whiteCaps_ wrote:
| This is off-topic but while you're here, the amateur radio
| regulations regarding baud / symbol rate really need to be
| removed and replaced with a 2.8kHz bandwidth limit.
|
| See Section 97.307(f).
| SimingtonFCC wrote:
| Thanks for raising this. I support the law addressing this
| issue and would also support Commission action on this.
| af3d wrote:
| One solution not being discussed much: formal verification. Any
| given "critical" IoT software component ideally should be subject
| to rigorous mathematical inspection in order to verify its
| logical integrity. Upon passing, it could then be signed with an
| FCC-issued key (along with the understanding that no unsigned
| software be installed during updates). While there are indeed
| plenty of theorem provers to be found in the wild, most are
| likely too domain-specific to solve the problem right out of the
| box. So the solution is hardly trivial, but it would nonetheless
| be a worthy (if daunting) undertaking.
| justinzollars wrote:
| I think our system has become Byzantine. The term comes from the
| Byzantine Empire, whose code of laws grew with time. Over
| hundreds of years the society was mired in complexity.
|
| There are too many rules and regulations. The best thing you
| could do within your role is to advocate for rolling back and
| eliminating existing regulations to simplify business.
| codedokode wrote:
| I am not an US citizen, so I cannot have a say here, but I have
| another idea.
|
| What's the problem if an IoT device is vulnerable? In the worst
| case the user will have to buy a new one (or pay someone for
| fixing it). Is it a serious problem? I think, no. Eventually
| users will understand which manufacturers are reliable and which
| are not.
|
| You probably want to argue, that infected devices can be used in
| DDoS attacks. But in this case, why don't you take measures
| against DDoS attacks directly and leave IoT devices alone?
|
| Why, despite Internet existing for 50 years, there is no
| protocol, using which any host can demand all upstream providers
| to block traffic from specific IP addresses? This would make low-
| level (transport-level and below) DDoS attacks impossible.
|
| Make such standard and make it required for all top-level ISPs.
| In this case the malicious traffic can be stopped at source
| network or at least at Tier-1 level. Middlemen like Cloudflare
| would become unnecessary, and you would be able to withstand a
| multigigabit DDoS attack even having just $5 VPS.
| SkyMarshal wrote:
| There's a concept in the Linux ecosystem called Long Term Support
| (LTS) in which a Linux distro will label a new release as LTS
| which means they will support it with security updates for
| several years. IoT should probably have something similar.
| SoftTalker wrote:
| Consumers consistently vote with their wallets on this, and based
| on their behavior, they don't care.
|
| They will buy the cheapest devices they can find on Amazon, made
| somewhere in the far East, and as likely to set their house on
| fire as punch a gaping hole in their home computer network, when
| there are much better made, well-supported alternatives but they
| cost more.
|
| If you want to make a difference, an FCC sticker won't do it.
| Consumers will go for the cheaper one without the sticker. You'll
| have to mandate whatever minimal level of support you want these
| companies to provide.
| ncallaway wrote:
| I just don't agree with this at all. I specifically avoid all
| smart plugs that don't have a UL mark (or European equivalent
| mark).
|
| It's impossible to say that consumers don't care about a
| specific certification before it exists based on their existing
| behavior. Consumers _do not have any ability_ to distinguish on
| this axis at the moment. So, we can't say: "based on their
| behavior they don't care". They very well might, and just don't
| have the information necessary to tell.
| saurik wrote:
| FWIW, I want to claim that I personally care deeply about a
| lot of this stuff; but, if I go to Home Depot and buy a piece
| of dumb equipment (such as a run of the mill light bulb or an
| outlet), it never occurred to me that I might have to check
| that there is a UL mark on it... I somehow assumed that Home
| Depot wasn't allowed to sell something that wasn't certified
| for at least basic electricity safety in the US.
| ncallaway wrote:
| I haven't checked everything at Home Depot, but many
| reputable retailers won't sell things in their store unless
| they have such a mark.
|
| It's "online marketplaces" like Amazon (or AliExpress)
| where you're actually purchasing from a random third party
| seller, and the marketplaces attempts to disclaim as much
| liability as possible that I'm more wary.
|
| I actually don't know the specific laws or regulations on
| this. It's very possible that it's illegal for Home Depot
| to sell a non-UL or other nationally recognized laboratory
| mark. It's probably that it's illegal for third-party
| sellers on other sites to do it as well, but my faith in
| Amazon and other "online marketplaces" for policing their
| third party sellers on this kind of stuff is...not high.
|
| I'm just trying to be a lot more careful about the stuff
| that goes into real circuitry, because I'm more used to
| playing with low-voltage DC stuff where I'm just not too
| fussed about it, so I feel OK ordering anything cheap that
| probably works.
|
| ---
|
| Finally, I think it's actually a regulatory and consumer
| information _success_ that you feel safe buying something
| from Home Depot and wiring/plugging it into your house
| without thinking about the product safety risks. The reason
| for that is _those risks have largely been eliminated_.
| There was a time when you _did_ have to be super careful as
| a consumer of electrical products. Over the years, we've
| drastically improved the safety of these kinds of products
| to the point where we for the most part don't have to think
| about it anymore, because it's not a problem anymore.
| That's effective government regulation at work.
| eru wrote:
| > If you want to make a difference, an FCC sticker won't do it.
| Consumers will go for the cheaper one without the sticker.
| You'll have to mandate whatever minimal level of support you
| want these companies to provide.
|
| Or you could respect the customers' revealed preference?
| SoftTalker wrote:
| For many products, I'd agree. For things that can affect
| public safety or shared, publicly owned or essential
| resources like network connections, use of radio spectrum,
| etc. we've long accepted that regulations are necessary so
| that the services can be available to everyone and provided
| safely.
| MarcoPerazaFCC wrote:
| If you think stronger action is needed, please share it through
| an official comment. Even if we don't do what you suggest,
| thoughtful comments really do influence the rulemaking process.
|
| As an aside, it's worth considering that there are also very
| sophisticated purchasers in this space, such as government and
| large businesses, and that a standardized, legally binding,
| label might help them insist on purchasing higher quality
| products.
| maerF0x0 wrote:
| > based on their behavior, they don't care.
|
| Personally I see it as "based on their behavior, they don't
| _understand_ "
|
| We also need far more computer/tech literacy in the education
| system and populace.
| chromoblob wrote:
| In a healthy person, caring should pretty surely imply
| efforts to research the topic and eventual understanding.
| janalsncm wrote:
| Yes, but not caring could mean either not understanding or
| understanding but still not caring.
| 6510 wrote:
| I've always thought that when a product is abandoned it should be
| left in a usable state. Keys or firmware to open up the device
| could be stored with the proper authority.
| sezycei wrote:
| It is extremely disheartening to see one of our many bureaucrats
| come to an anoymous international forum for input on an American
| domestic policy issue. A domestic policy issue that should be
| exclusively taken care of by the elected legislature rather than
| an unelected bureaucracy.
|
| I hope that all of the comments in this thread are fully
| discarded by all who hold actual power at the FCC; the opinions
| of the international community are not relevant.
| freedude wrote:
| Updates and the updating process are fraught with problems.
| Adding a requirement for updates to occur can compound those
| problems.
|
| Some updates deprecate code. If that code is needed for critical
| functionality the update renders the device useless for that
| application.
|
| Updates require some level of connectivity. It is becoming
| increasingly more common to insulate an IoT device from the
| Internet. Either through a VPN, an internal firewalled network,
| or completely disconnected. This is at odds with an IoT
| "requirement" to update equipment.
|
| Updates require downtime. When do updates occur? How often? Can
| they be scheduled? If I have several IoT devices from the same
| manufacturer can I aggregate updates with an intermediate
| software package which then controls deployment?
|
| How are updates tested? Are the original requirements from the
| initial manufacturing process kept or does this change over time
| and result in a broken IoT device.
| simne wrote:
| Greetings from Ukraine, European country with real Great war just
| now.
|
| I must say, we see extreme grow of cyber-crime as part of modern
| war. I think, in nearest future, cold war will guaranteed have
| huge cyber-crime part.
|
| And, hacking of IoT devices has very significant share of cyber-
| crime now. For real war it is question of life and death, because
| hacked devices with radio emission, are used by hostile
| intelligence, to find targets for attacks of heavy weapon, but
| also, we seen cyber attacks on electric-energy infrastructure,
| indented to make blackout (fortunately for us, unsuccessful).
|
| Chinese IoT devices are very special part of question, in many
| cases are connected to Chinese clouds, and this is also extremely
| dangerous, not only because potential unfriendly Chinese moves,
| but also because their security is not good enough, so in many
| cases, cyber-crime could intercept communications and interfere
| operation of device or even hijack control.
|
| For example, exists smart door locks with camera and I hear
| hackers hacked them and used them to observe work of air defense,
| so enemy could tune their air attacks to make more harm.
|
| In civilian life without war, videos from hacked door locks (or
| other IoT cameras) could be used for illegal surveillance, to
| coordinate riots, etc.
| SimingtonFCC wrote:
| Hi and thanks for commenting. My concern with this topic is
| motivated in part by the AcidRain family of energy
| infrastructure attacks and the larger questions they raise
| about infrastructure security. Teardowns on Chinese-sourced
| equipment have been somewhat worrying as well -- one report
| I've read highlighted about two dozen versions of SSH in a
| single base station. Best wishes and good luck.
| fnordpiglet wrote:
| Hi thanks for the work here. I read through (some) of the linked
| materials including the statements. The proposal itself is
| enormous, and all of it is extremely well researched. (Reading
| the comments here it reads like few folks read your links as most
| of the comments are addressed in some way).
|
| That that end, and I realize part of these exercises is
| exhaustiveness, due to the legal and regulatory nature, it would
| be really useful if there were a TLDR version that included the
| request for comments boiled down to a sentence and laid out
| concisely. The document is enormous and unless it were literally
| my job (aka a paid lawyer or lobbyist) I couldn't justify going
| through it all and composing responses point by point.
|
| The points however are great and we should respond - for
| instance, the question of should the label be at a product level
| or a device level (I.e., subsystem of a product) is great. IMO it
| should be at a product level. Currently device level labeling
| ends up just being a blob of perfunctory tiny text. Products are
| what we interface with, and if any updates would be applied, they
| would be applied at a product level anyway.
|
| Further, to the points made on energy star labeling in the
| statement made by your peer, I think the labeling should be
| simple - like a small discrete set of classes for compliance that
| can be extended over time with further rules. So 20 years
| security updates is "platinum" 10 years is "gold" 5 is "silver"
| or something. Then the classes of label can accrete meaning over
| time as you enhance your proposals.
|
| I also wonder if the formal comment system is the right interface
| for this community... a few might convert all the way to a
| comment, but it's not a trivial undertaking to read all the
| material and provide detailed commentary. I know it's what you've
| got and what you have to work with, but in some ways a way to
| work best is right here in the HN comments and then lifting
| material up into your direct work via the proposal and statement.
| To that end maybe reaching out earlier in the process to get
| feedback would work?
|
| Regardless I am glad to see our government proactively reaching
| out to adhoc communities of experts to solicit our feedback.
| Thank you, you are obviously one of the good eggs. I'll bookmark
| your links and try to spend some time drafting a comment.
| SimingtonFCC wrote:
| Really appreciate your kind words and the effort required in
| getting your arms around so much material so quickly.
|
| _it would be really useful if there were a TLDR version_
|
| I agree; I'm hoping that the tech press takes up this topic,
| but an "official" one would make engagement much faster.
|
| _I think the labeling should be simple - like a small discrete
| set of classes for compliance that can be extended over time
| with further rules. So 20 years security updates is "platinum"
| 10 years is "gold" 5 is "silver" or something. Then the classes
| of label can accrete meaning over time as you enhance your
| proposals._
|
| This is how I'm thinking about it too -- not just for support
| term, but for all kinds of things, FOSS firmware in escrow,
| bankruptcy transition plan, responsibility to publish and
| implement fixes from public databases -- there's so much that
| might go into each tier, and while I have my own ideas, it
| would be great to see the tech community take up these
| questions.
|
| _in some ways a way to work best is right here in the HN
| comments and then lifting material up into your direct work via
| the proposal and statement_
|
| Also true, and my team will be doing a detailed after-action on
| this thread once it winds down.
|
| _To that end maybe reaching out earlier in the process to get
| feedback would work_
|
| That's one to grow on for next time. The good news is that the
| final rule (I'd expect end of Q2 2024) will also be subject to
| notice-and-comment.
|
| Seriously, a huge thank you for your close engagement. I'm
| really excited about what the tech world can bring to this
| high-level proposal.
| blubbity wrote:
| Whatever the regulation, please please please may it only apply
| to companies above a certain revenue (or some other metric).
| Regulation of this form has a dampening effect on innovation, and
| this would be a straw on the camels back for startups.
| janalsncm wrote:
| There are too many IoT devices that want my email/phone just to
| perform what normal devices have been able to do for decades. No,
| I don't want to download an app just so I can use my apartment
| stationary bike. I get enough spam already, and I don't want to
| agree to a long terms and conditions just for that. In that case
| I couldn't even use the bike at all without creating an account.
|
| I think a lot of places got duped into thinking their internet
| connected stuff was an upgrade but in my opinion it's a major
| downgrade. A device should do what other non-IoT devices do
| without being online, and internet capabilities should only be a
| value-add. A toaster should make toast without being online.
| hermannj314 wrote:
| This is a great point. What are your thoughts on requiring a
| switch on all IoT devices so the consumer can flip a switch and
| their "smart Widget" just becomes a "widget"? This would be a
| nice for both security perspective and a consumer perspective.
|
| An insecure e-stationary bike should just become a stationary
| bike rather than a 100-pound pile of trash.
| janalsncm wrote:
| My opinion is that a stationary e-bike should be a stationary
| bike whether or not the wifi is connected, and then I can
| choose whether I want to connect it online. I don't think a
| switch is necessary, just don't connect the thing.
| ryankrage77 wrote:
| The Bob dishwasher from DaanTech gets this right, it has
| Wi-Fi capabilities and a DRM scheme for its propietry
| dishwasher fluid modules, but those are extra features, and
| it works fine as a dishwasher without them. If the company
| drops support or goes out of business, I won't even notice
| in terms of impact on washing my dishes.
| dtaht wrote:
| Thank you for engaging with the community in this way. Many years
| ago, in a fight to preserve individuals ability to flash their
| own routers, Vint Cerf, and I, and a coalition of many others,
| filed this report:
|
| http://www.taht.net/~d/fcc_saner_software_practices.pdf
|
| (retaining the ability to reflash our own routers, allowed my
| research project to continue, and the resulting algorithm,
| fq_codel (rfc8290), now runs on a few billion devices) The Linux
| and OpenWrt development process continues innovating and is very
| responsive to bugs and CVEs. It is a constant irritation that
| many products exist downstream from that that are 5 or more years
| out of date, and not maintained!
|
| Key bullets from that fcc filing are on page 12-13.
| SimingtonFCC wrote:
| High-quality comment. Thanks very much! I'll read your filing
| and think about it. But also, it's a great example of impactful
| public FCC commentary. I hope your work inspires others to make
| their mark in the record.
| dtaht wrote:
| Thank you very much for reading. It was the first, and last
| time, I ever took place in the public process and political
| action.
|
| https://www.computerworld.com/article/2993112/vint-cerf-
| and-...
|
| We were within months of delivering a massive RFC8290-based
| fix for wifi performance and we'd been bricking routers left
| and right... and then got in a whole bunch that we could not
| modify... due to that proposed regulation... I lost my
| temper, organized 260+ to sign, made that filing, won, and
| went back to work. I should perhaps have pressed harder, as
| the binary blob issue has got ever more terrifying, deeply
| embedded into too many baseband processors.
|
| If I hold your attention a little bit? It would be rather
| nice if modern fq + aqm algorithms went into the internet
| nationwide. "Bufferbloat" is at epidemic proportions. Most
| the fixes arrived for it in Linux in 2012, and are only
| slowly rolling out 10+ years later, due to the accompanying
| epidemic of manufacturers' not tracking new Linux kernels,
| (with all those accompanying vulnerabilities). I care very
| much about addressing security issues, but care about
| internet "latency under load" and better videoconferencing
| experiences more.
|
| There's only a billion or so devices left to upgrade.
|
| https://www.usenix.org/system/files/conference/atc17/atc17-h.
| ..
| SimingtonFCC wrote:
| Thanks again -- will review both links (especially the
| latter!)
|
| The FCC hasn't traditionally been a cybersecurity agency
| and will, most likely, never really be one; however, we can
| certainly do things through rules to empower experts, the
| public, and the agencies with cybersecurity expertise. If
| that one thing is all you ever did at the FCC, sounds like
| the public owes you a big debt of gratitude.
| dredmorbius wrote:
| As _communications_ increasingly overlaps with other
| elements of information --- data acquisition, storage,
| retrieval, processing, and transmission --- keeping the
| FCC out of the security space will become both more
| difficult and less tractable.
|
| We've already seen instances where broadcast channels
| have been hacked or hijacked, where false reports have
| been injected into news streams (at times affecting
| global financial markets, or disrupting emergency /
| disaster responses), where communications providers have
| disabled public access to alerts (mobile providers and
| wildfires, Twitter's recent hostile takeover), and more.
|
| There's also the overlap between communications and
| monopoly (generally the FTC's remit), which I realised a
| few years back: Censorship, surveillance, propaganda, and
| targeted manipulation (AdTech and similar tools) are all
| intrinsic properties of media monopolies:
|
| <https://web.archive.org/web/20201014011009/https://joind
| iasp...>
|
| <https://news.ycombinator.com/item?id=24771470>
|
| There are _other_ concerns where media are highly
| _decentralised_ or fragmented, including spread of
| rumours and confusion (e.g., "fog of war", or the
| general uncertainty in natural disasters or after
| political and military upheavals such as Germany as the
| Third Reich fell). But the monopoly -> media concerns
| issues seem well established. Most though not all of
| these are addressed by people such as Tim Wu, Bruce
| Schneier, Cory Doctorow, and Shoshana Zuboff, though I'm
| not aware that all the components I've identified had
| been linked previously.
|
| I'm aware that regulatory agencies are constrained by
| their legislative mandates, but communicating concerns
| over those limitations to Congress is also possible.
| CamperBob2 wrote:
| There's no small amount of irony in the fact that attempting to
| open your .PDF without the comforting assurance of SSL gives me
| a "security warning" that I have to go out of my way to
| circumvent. I'm sure that it won't be long before it will
| simply become impossible for me to open the file "for my
| protection."
|
| The push to mandate certificates and other gatekeeping
| mechanisms that enforce obsolescence for the sake of digital
| security theatre is ultimately going to benefit corporate
| bottom lines (especially those of landfill operators), but it
| will indisputably harm consumers.
|
| I guess I should turn _that_ into a comment and submit it...
| joeframbach wrote:
| Here are the concerns I care about at this time:
|
| 1. If Device Attestation/WEI takes off, and if it takes this new
| time-limited support lifetime into its attestation signature,
| then we'll see more physically healthy devices sent to the
| landfill. Devices that are reasonably fine for grandpa to play
| Mahjong on, but Google won't let her visit Facebook because WEI
| can't guarantee them their ad dollars, then it'll go to the
| landfill. I don't want to see this waste. I want the "support
| lifecycle" of a product to be the FULL lifecycle, including
| mandating a recycling program or something of the sort.
|
| 2. I want guarantees that I can keep using an old device after
| its support window closes. When Google decides to sunset the Nest
| Doorbell, I want to own it and be able to run it myself.
| vinay_ys wrote:
| IoT devices need regulatory standardization w.r.t a few things:
|
| 1. software stack - big fat "firmware" should not exist. Entire
| stack should be upgradable safely, securely and frequently during
| its official supported lifetime and should be open-sourced for
| owner's own upgrades past end of life. For this, the hardware
| stack needs some amount of standards compliance.
|
| 2. Vendor should clearly declare/advertise the period for which
| they will support the device. During this period the device
| vulnerabilities should make them liable. After this period, they
| should mandatorily open-source the device drivers and unlock the
| boot loaders to enable free software alternatives to work on
| them. For certain class of devices, there should be mandatory
| minimum period of support.
|
| 3. Networking capabilities should be legally standardized and
| verified/certified before being released to market and checked
| for continued compliance and fined if out of compliance.
|
| 3.1 Use of latest mainstream TLS with valid certificates should
| be mandated for all communication.
|
| 3.2 If there is outbound communication from the device, it should
| make it clear to which domains it will communicate with so that
| it is easy to allow only that through firewall and keep
| everything else locked.
|
| 3.3 IoT should not accept inbound communication without
| authentication.
|
| 3.4 Follow best practices w.r.t rollback resistant
| cryptographically verified secure and brick-safe software
| upgrades.
| MarcoPerazaFCC wrote:
| These could be great suggestions for the criteria a product
| must meet to quality for a label. I encourage you to file an
| official comment with your thoughts.
| treyd wrote:
| > 3.3 IoT should not accept inbound communication without
| authentication.
|
| Ideally the user should have to specifically consent to inbound
| communication on an instance-by-instance basis, _even from the
| manufacturer_. There 's many cases where forced updates are
| triggered that change/limit functionality unexpectedly. There's
| numerous anecdotes of people's devices being required to update
| to be used while they have some pressing need to use it.
| basch wrote:
| I wrote elsewhere, but a standard/compatible requirement for a
| rolled up management dashboard.
| https://news.ycombinator.com/item?id=37395102
|
| I dont want 30 semi/unmaintained apps to manage each
| manufacturers security settings.
| legohead wrote:
| At the very least, manufacturers should have to notify all users
| or via press release when a product has been compromised or can
| be compromised via a known attack, with maybe some required
| details like the severity of the breach and possible outcomes.
| TheMagicHorsey wrote:
| This is one of those areas where regulation might cause
| unintended consequences that are worse than the current state of
| affairs.
| smingo wrote:
| Regulating here is necessary, but the challenge is steep! IoT
| devices may include a complex bill of materials (BoM) including
| software (SBoM). Vulnerabilities can appear in any of those
| components.
|
| On the one hand, CVE and vulnerability databases are excellent,
| and with some automation of vulnerability and patch availability
| the's the possibility of automated re-build.
|
| But the manifests can be huge. And some component could be
| vulnerable, but was never anticipated to be so, and perhaps
| doesn't even have the means to be patched. Update processes for
| sub-sub-components may not have been exercised, and could lead to
| bricked products.
|
| So labelling and guarantees are welcomed. But the challenge is
| practically insurmountable, and until the entire industry steps
| up to meet it, labelling and guarantees are going to be 'best
| effort'.
| quercusa wrote:
| If a device does not violate (e.g.) RF emissions regulations,
| what authority does the FCC have to regulate its internals?
|
| Thanks!
| MarcoPerazaFCC wrote:
| That's a great question. Devices that emit RF could be hijacked
| and turned into signal jammers. With smart jamming attacks,
| even low-power transmitters could potentially cause serious
| harmful interference to other devices. Botnets of compromised
| devices could be especially damaging. Since vulnerabilities are
| often chained by attackers, sometimes in very unexpected ways,
| to accomplish their final goal, we think that the FCC has a
| legitimate interest in just about any vulnerability on a
| wireless device. But the question of legal authority is itself
| open for public comment and we hope there's vigorous debate on
| the record to make sure we get it right.
| karmicthreat wrote:
| Has there ever been an example of a consumer RF emitter being
| remotely hacked and turned into a jammer?
| barelyauser wrote:
| Of course not. But they don't operated based on evidence,
| they do based on fear. Like Apple, John Deere and pretty
| much any industry today.
| [deleted]
| exabrial wrote:
| ** THE REAL PROBLEM **
|
| Is companies making shit that has not business connecting to the
| internet. _THAT_ needs to be regulated. Why does your car need an
| internet connection? Why does your fridge need an internet
| connection? What does your robovac need an internet connection?
| ALL of these items could work just fine with zero internet
| connect, or a simple LAN connection.
|
| If we could regulate that, we'd solve 95% of the problem and the
| IOT Update problem goes away. Ounce of prevention worth a
| Terabit-Scale DDOS of cure.
| carreau wrote:
| Thanks for asking those question, and with the number of
| comments, thanks if you reach mine.
|
| One of my hope is that this will affect the market and in
| particular the ability to have non-connected variants of some
| appliances.
|
| My hope is that if the cost/risk if high enough, manufacturer
| won't put pointless connectivity - or at least the ability to
| disable connectivity - to some models.
|
| I'm also hopping that will put an end of application that collect
| personal data, like my headphone app requiring I turn on GPS and
| give it access to my location start.
|
| Thanks !
| CodeWriter23 wrote:
| With all due respect, I think the market should address this.
| Like UL Approval from Underwriters Laboratories, players in the
| market can submit their products to an organization that vets
| their security and sets standards about updates, product
| lifetimes, security incident response time commitments etc to
| obtain their seal of approval. Perhaps the seal has grade levels
| to indicate the vendor's commitment to security. The highest
| grades indicate regular audits of vendor practices. And a website
| where approval status (and possible revocation) can be looked up.
|
| This simultaneously enables innovation by small players while
| providing a pathway for bigger players to put a meaningful trust
| signal on their packaging and advertising.
| mixmastamyk wrote:
| Not a bad idea at all. However, if they are not doing this
| already voluntarily, they'll need to be persuaded. Perhaps a
| role for the FCC.
| SimingtonFCC wrote:
| This would make for a fine comment on the record. It would be
| great to have suggestions about pros and cons of government,
| court, third-party and other audit means.
| CodeWriter23 wrote:
| I'll work on it some more based on feedback I'm receiving and
| submit it. Thank you.
| cjalmeida wrote:
| The UL example is one where it would be hard for improved
| security to happen by itself. UL was founded to solve for fire
| risk when insuring buildings. It received funding from
| underwriters that would benefit from the label.
|
| I don't see any particular entity benefiting from security
| labels - it's a problem of the "commons" where you generally
| need government intervention of some sort of.
| theptip wrote:
| I think the way to make this proposal work is to pass
| legislation to actually have meaningful financial liability
| for data breaches.
|
| IFF companies have financial liability, then the market can
| be expected to find a cost-effective solution.
|
| Without any selection pressure though, there is no reason tho
| think the market will spend resources to solve this. Users
| empirically don't understand security, don't price it
| appropriately in advance, and aren't able to evaluate the
| security qualities even if they do want to pay more for a
| "secure" product.
| CodeWriter23 wrote:
| You can't see the consumer benefitting from a certification
| label? Interesting. Also, the vendor benefits by gaining more
| sales.
| agloe_dreams wrote:
| I'm not sure you are following them. The UL was funded by
| the Insurance companies. Their point was that there was
| some organized, rich entity to pay for the costs of
| operation as they had a financial stake.
| pbronez wrote:
| Yes, the consumer would benefit. But Consumers are not a
| concrete interest group like "property insurers". They lack
| the concentration of economic power need to cover the
| costs.
| bick_nyers wrote:
| I like this approach, it doesn't necessarily need to be just
| the "market" performing the audits however. The FDA handles
| audits of medical software companies just fine. Focusing on the
| Quality Management System and their Risk Assessment/Security
| practices seems like a solid approach, and of course centralize
| this data and make it easily searchable as much as possible,
| and provide API access to it in case vendors like Amazon want
| to integrate it and display certifications/grades for
| products/manufacturers automatically.
|
| All that being said, I have no idea how much manpower or money
| it would take to do audits at that scale, or even what the
| scale of IoT Devices vs. Medical Devices is.
| CodeWriter23 wrote:
| FDA: $450K per product. And they aren't doing very much more
| than asking the vendor to describe their protocols, then
| ensure the vendor complies with their protocols and any
| agency guidance. Source: I work at an FDA-regulated company.
| convivialdingo wrote:
| It depends... I just worked my part of certifying a
| product(security) and it was only ~$40k.
|
| Agreed on the current state of the FDA filings - there's a
| _lot_ of paperwork and process auditing - but guidance is
| lacking and I 'd like to have more clarity rather than just
| "industry best-practices." That said - things are much
| better and it seems like the trajectory is improving.
| bick_nyers wrote:
| Did not know it was $450k per product, my second
| responsibility outside of software engineering was being
| the risk manager at my previous company as well which is
| FDA-regulated.
|
| Still, many IoT companies that sell products don't even
| have protocols or a QMS at all, and need some kind of heat
| applied to them.
| gsuuon wrote:
| I can see it being useful for audiences who know what they're
| looking for. As an average retail consumer, if I saw such a
| label I would either have no idea what it means or have to do
| my own research about what UL is - not to mention the
| impossibility of them enforcing anything. I guess they could
| remove the label but how would I know a product I'm using has
| violated their commitment - routinely check a UL website?
| bick_nyers wrote:
| If Amazon etc. was partially responsible for checking the
| database for you and ensuring listings are properly updated
| in a reasonable timeframe then it would be more accessible
| for the average consumer. Even if a consumer doesn't know
| what UL certification means, if product A has it and product
| B doesn't and they are similar enough in price, the consumer
| may opt for product A.
|
| Edit: Reasonable timeframe should probably be dependent on
| the size/scale/competency of the marketplace platform. In
| other words, Amazon should be held to a higher standard than
| a low traffic web store.
| CodeWriter23 wrote:
| It would be up to the certification organization to market
| their seal of approval to increase awareness.
| Plasmoid wrote:
| This boils down the Right to Repair and Maintain.
|
| I always advise my friends and relatives to NOT buy smart
| appliances. The doom scenario is buying a $20k furnace that
| becomes useless. Imagine a scenario where you need an app (that's
| never updated) to adjust your house temperature. Or requiring
| people run insecure wireless protocols to control it.
|
| Appliances like this need to operate over an open control
| protocol, where the smart/internet bit is physically replaceable.
| Dropping $200 every 5-7 years for a new Furnace smart attachment
| is reasonable price, dropping $20k is not.
| indymike wrote:
| I'd be really happy with products having to be labeled with:
|
| 1. Final date the manufacturer will provide firmware updates &
| security updates 2. If the manufacturer will support open source
| alternative firmware & security updates. 3. If there are any
| subscription fees (and how much) to get firmware updates &
| security updates.
|
| Issue #1 is a big deal: I've purchased equipment, new in the box,
| after the mfg had discontinued support. I've also ran into issues
| with devices where updates required a subscription. I'd love a
| little disclosure.
| MarcoPerazaFCC wrote:
| > _I 've purchased equipment, new in the box, after the mfg had
| discontinued support._
|
| Exactly the kind of thing that sounds crazy but still happens.
|
| > _1. Final date the manufacturer will provide firmware updates
| & security updates 2. If the manufacturer will support open
| source alternative firmware & security updates. 3. If there are
| any subscription fees (and how much) to get firmware updates &
| security updates._
|
| It would be great if you could file an official comment with
| your thoughts on exactly what disclosures are needed and why
| you think they're necessary. We want to get this right.
| fuddle wrote:
| Marco Peraza, Not related to regulation of IoT security updates
| but since this is an AMA. How did you transition from software
| engineer into a cybersecurity lawyer?
| MarcoPerazaFCC wrote:
| Hi, the short of it is that I decided to go to law school and
| then looked for jobs focusing on cybersecurity. If you're
| interested in jumping over to law, I'm happy to talk about it
| more. You can find my email in the FCC directory
| https://www.fcc.gov/about-fcc/finding-people-fcc
| ckwalsh wrote:
| Is there any way to tie an expectation of long term security
| support with legal protection of the product against
| competitors/reverse engineers/other parties that manufacturers
| may not want looking too closely?
|
| I'm not suggesting granting additional protections to
| manufacturers, but codify an expectation of "if you abandon it,
| other people can come in and potentially salvage it"
| maerF0x0 wrote:
| IMO here's some better solutions.
|
| 1. Blend FCC action with right to repair -- Require device makers
| to provide software patch utilities to the public, and open
| source the code after a period of time.
|
| 2. Rather than regulate manufacturers, educate consumers.
| Companies that do dumb shit should go bankrupt because customers
| can understand the company sucks.
|
| 3. I'd prefer the government to defined standards and
| repercussions, not solutions. ie, Do not mandate security
| patches, instead add liability, per sold device and scaled to
| severity, for security flaws. Then let the market decide the
| solutions. Rather than giving patches, they might decide to just
| give free replacement devices, for example.
| kapilvt wrote:
| there are many parts of this problem, I have particular thoughts
| on two.
|
| one concrete recommendation I would make is mandatory third party
| pen tests. software companies have to do this for soc2, etc.
| Companies putting live mics in living rooms across the country
| should deal with the same. This is all to raising the level of
| initial security on devices, including the update process.
|
| the other consideration is about updates, and its much more
| nuanced against what's viable for a business. there is no
| security without updates, but the ability to produce those on any
| schedule is unclear. even more so when the originating company
| goes out of business. Ideally there would be a threat matrix here
| against a CVE list (remote access to hot mic/camera), would
| require a manufacturer to issue an update within x days.
| wiremine wrote:
| Thanks for advocating for these issues. They are important.
|
| I'm the CTO of a small software studio who has worked almost
| exclusively in the IoT space for the last 8 years. We've worked
| on large, Fortune 500 companies, all the way down to startups.
| Half our projects have been for consumer IoT, the other half for
| B2B projects.
|
| There are two core financial realities that regulators need to
| understand:
|
| 1. From a purely financial perspective, most manufacturers do not
| have financial models that make perpetual, ongoing updates
| possible. Without a recurring revenue stream tied directly to a
| device, any software update reduces the return on investment for
| a product. For example, say you make a consumer IoT device and
| sell it without a subscription. The BOM might be $50 and the NRE
| is $50. You might sell it for $200, and make $100 profit.
| However, without a revenue stream of some sort, that profit needs
| to somehow support all the software updates those devices will
| receive in the future. Say each update costs $5 to build and
| deploy, and you release once a year. After 4 years you've spent
| $20 in updates, likely more due to inflation. At some point this
| becomes a losing proposition. The fact that GAAP says non-
| recurring engineering can be capitalized, but the maintenance
| cannot, creates even more issues. And due to the maturity of
| security, it's difficult, if not possible, to guess upfront how
| many updates a device might require.
|
| This problem is compounded by the poor software practices at most
| manufacturers. It is non trivial to set up a software practice
| that keeps the cost of ongoing development in check. More model
| numbers and large fleets increase the development and QA costs.
| The per unit costs go down, but the absolute dollars go up.
|
| 2. The second issue is that IoT devices have a symbiotic
| relationship with other systems, and the financials for the
| overall product are tightly coupled. For example, consider cold
| chain monitoring systems. These devices are simple: measure the
| temperature, and send the data to a cloud-based pipeline. Alerts
| are forwarded to another. The value is in the outcome: alerting
| users to problems. However, to be competitive, the manufacturer
| might sell the hardware at a loss. If the _system_ is
| unprofitable, the vendor might turn off the system. In this case,
| it's hard to demand that the vendor provide updates for a defunct
| system. In the worst case, companies will go out of business and
| all the regulation in the world won't really help the consumer.
| Or the large companies will simply set up shell corporations to
| shield themselves.
|
| Some in this thread suggested that all the software be open
| sourced. This is a fool's errand, IMHO. Forcing manufacturers to
| do this isn't viable because they often don't own the entire
| software stack: they have suppliers who own the IP, who in turn
| have their own suppliers. And it's really hard to draw the line
| in embedded systems. The BSP, RTOS/kernel and applications are
| all tightly coupled.
|
| "But I bought the software!" you say. Yes, you did. You bought a
| binary snapshot in time of a software system. Unless you're
| paying for perpetual updates, you didn't buy unlimited free
| updates into perpetuity. And you definitely didn't buy source
| code.
|
| So, what's the solution? I don't have any silver bullets, but
| here are some thoughts:
|
| 1. For many devices, allowing the user to replace the
| microcontroller outright is the ultimate consumer safeguard,
| while protecting IP. If the vendor doesn't provide updates, or
| goes out of business, the owner can replace the MCU or SOC. And
| it protects the IP of the manufacturer's supply chain. This
| requires a clean separation of concerns, and it also would allow
| competitors into the market. But this is the best actual
| safeguard to consumer protections and respecting IP. There are a
| lot of ramifications to this. The user instantly voids the
| warranty, and would need to take responsibility for the security
| and safety of the system. But for a lot of use cases, this is
| fine.
|
| 2. Incentivizing a secondary market to encourage third-parties to
| take over failed systems. For example, if a vendor winds down a
| failed IoT project, give them a tax break to sell the system to a
| third-party, or open source it. This would give vendors a lot
| more reasons to try and own/license all the IP to make it open
| source-able. There _are_ knock on effects: the third-party might
| charge for updates, or raise prices.
|
| 3. Incentivizing common hardware/software platforms. Here's the
| reality: most manufacturers don't really want to write their own
| software. They want to sell hardware: it's what they're good at.
| Encourage more generalized software architectures for IoT
| devices. This will reduce the costs and enable parts of the
| system to be updated, without requiring access to the entire
| system.
| MarcoPerazaFCC wrote:
| Thank you for this detailed feedback. In the long-run, it's
| worth asking whether a business that doesn't make money once
| externalities have been internalized is a business worth
| having. But this is a voluntary program, and we're just hoping
| to spur growth of a segment of the device market where these
| issues are properly accounted for. Hopefully as more and more
| purchasers begin insisting on higher-standards, maybe by
| insisting on this label being present, economies of scale and
| componentization of secure IoT platforms will drive the costs
| of good IoT security down to the point where your concerns
| aren't as salient. Please consider sharing your thoughts
| through official comments.
| samstave wrote:
| > _Many manufacturers oppose making any commitments about
| security updates, even voluntary ones. These manufacturers are
| heavily engaged at the FCC and represented by sophisticated
| regulatory lawyers._
|
| Gee, I wonder if this has anything to do with the corrupt people
| like Ajit Pai?
|
| Sincerely - after the Ajit Pai debacle and the fraudulent selling
| off bandwidth rights, I literally dont trust the FCC with
| anything...
|
| So, prove to me the FCC actually understands IoT?
|
| Basically youre attempting to regulate a swarm of GNATs and how
| they _should_ behave, without understanding how they are born...
|
| look at Moores Law as it pertains to surveillance and fraud tech
| ; The size of cameras, the power of IP enabled wireless talking
| devices (regardless of protocol/tech/mech) is so incredibly small
| and easily, cheaply replicated in any cheap-tech-state (china,
| and many other places we dont talk about) - makes it such that
| one can only assume that they are under 100% surveillance 100% of
| the time...
|
| THAT is what you should be regulating - the scanning of an area
| for detection of IoT device _transmissions_
|
| Think of Purple (brand) air quality monitors, a frequency field
| monitor for all RF transmissions in a given area (as can be
| heard) would be great, with sensors for adding to such monitoring
| that can RSSI triangulate the location of devices.
|
| Think of Apple Air-Tags...
|
| If you had cell phones all reporting RF triangulation signals -
| you could map out the IoT problem, frequencies, locations,
| targeted devices/tech etc...
| ryukoposting wrote:
| As a firmware engineer, I'm one of the people who actually writes
| the code that goes inside the IoT devices. I'm very interested in
| what the FCC might be able to do here.
|
| How does the FCC define a security flaw? Would updates only be
| distributed when there is a flaw that needs fixing?
|
| Remote update mechanisms can themselves present security problems
| in some domains. Thus, some devices should only be updatable if
| the owner has physical access to the device. Will the
| manufacturer be liable for damages caused by attacks on
| vulnerable devices that were not sufficiently updated by their
| owners?
|
| IoT is making its way into defense and enterprise environments
| where reliability is a matter of national security. An update
| nearly always results in some downtime for the device, even if
| it's just a couple seconds. Sometimes, it may be in the best
| interest of a device's owner to defer an update indefinitely,
| until that device's continuous operation is no longer mission-
| critical. Even if the owner can't control exactly _what_ is in an
| update, they absolutely _MUST_ be able to control _when_ an
| update occurs.
| MichaelZuo wrote:
| This is a good point, some IoT devices really can't be designed
| to be physically serviceable, while still remaining reasonably
| compact, e.g. those that need very high levels of water
| resistance, especially saltwater resistance.
|
| And adding any remote update mechanism at all would more then
| likely decrease overall security.
|
| So there actually should be a counter mandate too, for devices
| that are impractical to design to be physically serviceable,
| while meeting certain size/weight/etc. requirements.
|
| To make sure remote update mechanisms, of any kind, are never
| implemented, unless the manufacturer can guarantee that the
| update mechanism itself doesn't introduce new flaws.
| MetaWhirledPeas wrote:
| Good comments.
|
| > The FCC recently issued a Notice of Proposed Rulemaking [2]
| for a cybersecurity labeling program for connected devices.
|
| This sounds like it is intended for consumer products, and it
| also sounds optional. I would hope that users with a legitimate
| reason to do so (defense, enterprise) would have the capacity
| to not participate and forego the label.
| ryukoposting wrote:
| The line between "consumer product" and "enterprise/defense
| product" can be blurry. For example, event security teams may
| use their personal smartphones to communicate with medical
| staff.
|
| A lot of IoT companies (especially the startups) focus on the
| customers with the deepest pockets (enterprise and defense).
| If big-ticket customers demand this label, it generates a
| great deal of incentive for IoT companies to just say "to
| hell with it, we want that label on everything we make."
|
| In any case, the words "national security" are usually a good
| way to get the attention of a three letter ;)
| alerighi wrote:
| > Remote update mechanisms can themselves present security
| problems in some domains.
|
| Not really if done right to be fair. It's just a matter of
| implementing a signature verification of the firmware updates
| that are installed on the device.
|
| > IoT is making its way into defense and enterprise
| environments where reliability is a matter of national
| security.
|
| If it's a matter of national security surely you don't use IoT
| devices connected to the public internet. At least the devices
| are in some private network, where the traffic is under your
| control. So if you don't do security updates it may be
| acceptable under that circumstances.
| TeMPOraL wrote:
| > _If it 's a matter of national security surely you don't
| use IoT devices connected to the public internet._
|
| Of course they do. That's the flip side of PaaS and reverse-
| NIH syndrome, the "opex > capex" thinking: "Industry 4.0" is
| built on web tech, with all the practices and assumptions
| baked in. Your critical infrastructure is, or is about to, be
| running JavaScript on a docker-compose cluster, and expecting
| to be piecemal-updated daily.
|
| And then, there's also "shadow IT" - going behind the back of
| IT and using COTS SaaS to work around red tape is still...
| going around IT and giving untracked third-party vendors
| access to organizational information and operations. "Making
| its way" doesn't only mean "introduced by design" - those
| vulnerabilities just creep in.
| SimingtonFCC wrote:
| I would love to see frank discussion on the record of
| consumer-grade vs infrastructure-grade practices and what
| label(s) would be appropriate for each! It's not lost on me
| either that the roots of much high-ticket critical
| infrastructure is about to rest on web tech and highly
| evolved descendants of 8-bit micros.
| arp242 wrote:
| > It's just a matter of implementing a signature verification
| of the firmware updates that are installed on the device.
|
| In principle: yes. In practice: signing keys seem to get
| leaked all the time.
|
| It's not a mechanism I would blindly trust in security
| sensitive domains.
| lnxg33k1 wrote:
| We could start by asking iot companies to be ISO 27002,
| stop saving passwords in excel files or in s3 bucket
| publicly accessible could help
|
| Security is not an update, security is a cultural trait of
| an entity or an individual
| MarcoPerazaFCC wrote:
| Thanks for this thoughtful feedback. I encourage you to file an
| official comment, especially regarding end-user control of
| update timing. Maybe my response here
| https://news.ycombinator.com/item?id=37394935 addresses some of
| your other concerns? We'd love to hear your thoughts.
| ryukoposting wrote:
| Thank you for the reply! I have submitted my official
| comment.
| baby_souffle wrote:
| > Even if the owner can't control exactly what is in an update,
| they absolutely MUST be able to control when an update occurs.
|
| +1 for this at the consumer level. My oven may have a critical
| update, but - for right now - *nothing* is more critical than
| finishing dinner. I'll let the update apply the day after
| thanksgiving when I'm doing the dishes.
|
| There are a few connected appliances brands that do this well:
| updates are broken down into two classes - "critical/security"
| updates and "all the other updates" - and I get to pick from
| "do nothing, notify, notify and download, notify,
| schedule/auto-apply" for both channels. Unfortunately this is
| not common because it takes planning and more than the bare
| minimum to pull off.
| klausa wrote:
| I think this is oversimplifying things.
|
| Is finishing the dinner more important than applying a patch
| that fixes actively exploited bug that locks your oven into
| cleaning mode and burns everything inside into ash over the
| next three hours? Or something that disables the safety
| checks and lets the oven overheat and burn your house down?
|
| (Granted, the latter shouldn't physically be possible because
| it should have physical temperature killswitches etc.)
|
| People always (understandably so!) consider software updates
| to be annoyances; but especially when you give an example
| like _an oven_, the potential for _catastrophic_ failures is
| too great.
| MarcoPerazaFCC wrote:
| One my favorite IoT botnet scenarios is an attacker taking
| control of thousands of ovens/air conditions/other high-
| wattage devices and using them to cause power outages. http
| s://www.usenix.org/system/files/conference/usenixsecurit...
|
| I wonder how the impulse to connect everything to the
| internet will be remembered.
| hot_gril wrote:
| I'm just wondering why someone would have a smart oven in the
| first place.
| 1vuio0pswjnm7 wrote:
| Please consider requiring making source code available instead of
| "updates". If the vendor will no longer "support" a product, then
| the vendor should let the buyer support it themselves and release
| the source code. In practice, what we know can happen is that
| buyers may share their support solutions and actually support
| each other. The story of Cisco's WRT54G router is an example of
| what's possible.
|
| If security is truly a concern, then all IoT devices connecting
| to the internet should be routed through a computer that the
| owner fully controls, which is likely to be running OpenWRT. Any
| tactics used by IoT vendors to evade traffic monitoring by the
| computer owner, e.g., discouraging self-signed TLS certificates,
| should be prohibited.
| ChoHag wrote:
| [dead]
| evanwolf wrote:
| Thanks for this, Nathan. Orphaned devices pose a suite of
| security problems. They outlast the companies that sell them, the
| companies that make them, the upstream suppliers of hardware and
| software, the companies that service and repair them. Smart
| building devices and power systems can run for decades. Implanted
| medical devices, home health devices, and hospital systems
| persist longer than five years and can outlast the corporations
| behind them.
|
| Please address orphaned products so that security continues with
| a duty by the maker to sustain safety and security beyond the
| life of a product or its manufacturer. This is like the requiring
| a sale-time deposit into an independent fund to reclaim/recycle a
| product's waste.
|
| Beyond the current proposal, you might require a device's IP to
| be put in escrow in the event of product or corporate end-of-
| life, allowing customers or third-parties to take up maintenance
| and security. (#RightToRepair #EoL)
| SimingtonFCC wrote:
| Thanks for your response! This would be an excellent comment on
| the record, and implanted devices are a particularly compelling
| example considering cases such as Second Sight.
| dantheman wrote:
| Does the FCC have any authority over IOT devices? and if so how?
|
| This seems like a massive overreach, how can a body designed to
| for managing shared spectrum have any authority on devices that
| use the internet?
| MarcoPerazaFCC wrote:
| Good question. There's some discussion in this thread
| https://news.ycombinator.com/item?id=37395218
| karteum wrote:
| You might be interested in this (in French, but you may try with
| google translate or other alternatives :)
| https://www.bortzmeyer.org/8240.html
|
| It is a very interesting explanation of debates around
| https://www.rfc-editor.org/rfc/rfc8240.txt
| JoshTriplett wrote:
| A mechanism requiring _disclosure_ of how long security updates
| are available seems like a _great_ step.
|
| Another great step would be a guarantee of making the firmware
| Open Source after no more than a certain amount of time, and
| having that guarantee known at compile time. Effectively, that
| means the device will always be supportable.
| worthless-trash wrote:
| > A mechanism requiring disclosure of how long security updates
| are available seems like a great step.
|
| So, as I work in this space, there needs to be realistic
| guidelines on this, does a security flaw need to have a CVE ?
| Do they need to fix every CVE ? What is the timeframe
| requirement ?
|
| This kind of thing keeps me up at night.
| SimingtonFCC wrote:
| _Another great step would be a guarantee of making the firmware
| Open Source after no more than a certain amount of time, and
| having that guarantee known at compile time. Effectively, that
| means the device will always be supportable._
|
| It's not inconceivable that this could be a requirement for
| getting a label (or some tier of label.) It depends how the
| advocacy comes out on the record.
| kijin wrote:
| The requirement can be easily bypassed by going bankrupt
| before the required time is up. You will soon hear advice
| like "if you want to get in to the IoT space, create a new C
| Corp for each iteration of your product..."
|
| Whatever you require them to disclose after X years, it must
| be escrowed with a trusted third party _in advance_.
| JoshTriplett wrote:
| Agreed: any kind of future disclosure requirement should be
| backed up by a source code escrow requirement.
| jddj wrote:
| I don't know who those manufacturers are, but I can guess. One
| left-field piece of advice I would offer is looking at what they
| specify for their own offices/HQs.
|
| "Smart" commercial office space has a bit of a head start in this
| area, and the specifiers have now had some time to find their
| feet.
|
| Some prominent IoT device manufacturers have had written into the
| specifications for their own buildings that, for example, the end
| user (read: them) shall be able to manage the certificates on the
| devices, and so on and so forth.
|
| A couple that come to mind would make for nice blueprints for
| consumer protections if you can cut through the prescriptive talk
| about preferred tech.
| leeter wrote:
| First and foremost I applaud the effort. I think this is a
| worthwhile concept. However, I think this is something that would
| be better if the FCC delivered a report asking for specific
| things to congress. Because while we can look at this just
| through the IOT lens I think that's very shortsighted. There are
| CNC shops still running DOS and Windows95. So what happens when
| the new fancy CNC they are buying today running Windows 11
| embedded goes out of support from MS? These are things that are
| intended to be in use for 30+ years.
|
| So to me there needs to be a formal process in the law for
| dealing with abandonment, and minimum support duration.
|
| 1. Minimum support duration: This needs to be in federal law and
| enforced by private right of action, and more specifically one
| that cannot be waived or arbitrated. This cannot be something
| that the FCC or FTC must enforce. This must also be binding with
| valid legal remedies if the company fails to comply or no longer
| exists. Which leads me to my next point.
|
| 2. Abandonment: The law must require that if an OEM abandons a
| device that sufficient information (including PCB schematics and
| PCB BOMs!) are made public that both individuals and third party
| commercial operations can supply support. Again, this must have
| legal remedy to enforce. My preferred remedy if a company
| completely fails to provide anything is loss of copyrights to
| that specific software. Thus negating all the digital locks
| provisions of the DMCA in regards to that specific hardware. If
| the company provides the necessary information under an
| appropriate free software and/or documentation license then they
| maintain all copyrights. They only need submit the information to
| the library of congress and a third party such as archive.org;
| they do not need to host it themselves. Nor would they be
| required to provide any support after that point. Furthermore,
| any components not currently in production would have to be made
| available until such stocks are depleted.
|
| Having a formal abandonment process for a device including a
| formal notice of termination of support, and releasing
| appropriate documentation and necessary information to the public
| provides a massive boost to both ongoing security but also to
| reducing waste.
| [deleted]
| freeopinion wrote:
| I have two points. First, remember that things like cell phones
| are also IoT. Laptops are IoT. So make sure that your regulations
| make sense for all IoT and make sure they apply to all IoT.
|
| Second, I tend to be libertarian. I'd prefer less regulation, not
| more. So if your concerns are about security update timeframes, I
| like your idea to treat it more like "Best if used by" labeling.
| That is, if somebody wants to bake some bread without any
| preservatives that should be consumed within 24 hours, that's ok.
| You don't force any lifetime. You just have that lifetime clearly
| displayed on the packaging.
|
| Some people would prefer bread that "expires" sooner than later.
| It could become a badge of honor. Likewise, a cell phone or mesh
| router that "expires" later than sooner could become a badge of
| honor. It could become a thing. It could be a feature that
| affects sales.
|
| Keep the regulation as light as possible and be smart about it so
| that it can still accomplish your desire. Give the labels some
| standard presentation and prominence like Nutrition Facts. I
| think it is a great idea.
| blobbers wrote:
| Tbh, I think this will add unnnecessary regulatory burden for
| start-up companies.
|
| Take for example general IoT cloud connected equipment: it will
| get security upgrades more often than one that is completely
| offline. That was a big selling point of the Meraki cloud
| offering that is now part of Cisco. There would be millions of
| unpatched networking equipment, but Meraki could _force_ upgrades
| onto networks without them managing the patching. The result
| being they would have secure products, and the non-cloud
| providers would have to rely on their customers to update their
| phone. The meraki solution was by definition a better upgrade
| path than the standalone solution. Why would you burden them with
| regulatory hoops that non-cloud devices do not require?
|
| When you buy an IoT device, you're taking on a risk on anything
| not open source, and betting that a product/company will succeed.
| For example, I bought some cube sensors to monitor my home air
| quality. These sensors are now garbage because they connect to a
| closed cloud that has been shut down. They don't even function
| let alone get security upgrades.
|
| If anything, non-cloud connected IoT devices are more likely to
| cause problems.
| cjalmeida wrote:
| Enforcing mandatory updates might not be a good idea, but
| creating standards that can inform the consumer in making
| decisions is helpful.
| mrweasel wrote:
| > Companies may cease supporting a device well before consumers
| have stopped using it
|
| In which case all information required to create and load custom
| firmware should be released to the public. This information
| should be placed in escrow, in case the company ceases to exist.
| The same rule should apply to backend services, in case of a
| device being depended on such a service to operate.
|
| > security updates for a reasonable amount of time
|
| Which is 25 year or more for some classes of devices. Phone have
| already reached a point where they should be required to come
| with 10 years of security updates. I'd expect light switches to
| get at the very least 20 years of security updates.
|
| Generally I believe that governments are being WAY to lenient
| towards manufactures of any type of electronics when it comes to
| updates. It's bad for security, the environment and the causes
| consumers to make bad investments. The companies making these
| devices have long since proven that they DO NOT CARE and
| shouldn't be trusted to deal with the issues themselves.
| sokoloff wrote:
| From the speech:
|
| > Wi-Fi deauthentication attacks, which can render useless every
| Wi-Fi network in an area, can be carried out by a single device
| with a Wi-Fi antenna.
|
| Is the prevention of such attacks within the mandate of the FCC
| (so long as all other relevant RF parameters are adhered to in
| the device)? I understood that unlicensed ISM users must not
| cause interference to licensed users, and they must be tolerant
| of interference generated by licensed users. I read this
| logically to conclude that unlicensed users must also be tolerant
| of interference from unlicensed users. (The opposite conclusion
| would seem to be infeasible to enforce, if any single unlicensed
| user could effectively bar the operation of another unlicensed
| user merely by being unable to tolerate the interference emitted
| by it.)
|
| A WiFi deauth attack is an attack on unlicensed users of the
| frequency spectrum.
|
| I'm perfectly happy for the FCC to change the rules, provided
| they follow the rule-making process in that rule change. If WiFi
| deauth attacks are to be prevented (and if I'm correct that they
| are legal-albeit-anti-social now), we should go through a
| rigorous rule-changing process to ensure that the new rule
| correctly balances the desire for continued, unlicensed use and
| the desire for that unlicensed use to be practically
| useful/usable.
|
| (By the way, I appreciate you engaging the HN community and hope
| that you're targeting other, similar communities who may have
| relevant expertise on either technical or policy matters here.)
| MarcoPerazaFCC wrote:
| In the 2010s, the FCC began enforcement proceedings against
| more than one hotel chain for using Wi-Fi deauthentication
| attacks against guests using their own Wi-Fi hotspots instead
| of the official hotel Wi-Fi networks. The claims were settled,
| so there's no court ruling on the matter, but our office is
| inclined to believe that the FCC has legal authority over such
| attacks. But we definitely encourage you to share your views on
| the record.
| sokoloff wrote:
| I'll do that, after taking some time to actually read the
| relevant CFR Parts to ensure my understanding is as
| reasonably informed as I can.
|
| Thanks to you and your colleague for making that process
| well-announced.
|
| For the record here (and I'll add to the comments above): I'm
| in favor of _perfect regulation_ that would allow the FCC to
| perform that hotel enforcement action, provided it didn 't
| significantly further impair the ability of hobbyists and
| entrepreneurs to create prototype products that use RF
| communications without having to engage with the FCC or
| third-party certification labs at every turn/step. (I worry
| that perfect regulation of an unlicensed usage of the
| spectrum is at least very difficult and may be practically
| impossible and I'm pretty sure that I don't want to flip all
| WiFi usage over to FCC-license-required.)
| tptacek wrote:
| Hey! Welcome back, Marco (he was a pretty active HN'er back in
| the day).
| jacquesm wrote:
| - Isolate security updates from feature updates and allow those
| to be ignored without imperiling future security updates
|
| - Require that products that are no longer supported with
| security updates have their firmware and build tool chains open
| sourced, even better would be a required escrow of the full build
| toolset + source for every version released to the public, with
| automatic release once certain conditions are met
|
| - Require that manufacturers maintain documentation and build
| tool chains for up to a decade after the last item has left the
| factory
|
| - Standardize update protocols; create guidelines and mandatory
| review procedures
|
| - Require up front disclosure of what is in a release
|
| - Create a set of requirements to ensure that the conditions
| under which upgrades/updates take place are safe. For instance
| (it seems obvious, but alas not obvious enough to certain
| manufacturers) OTA updates of firmware in vehicles should only
| happen if the vehicle is not in motion and in a mode where the
| user indicates that an update may take place.
| elihu wrote:
| Some ideas:
|
| Customers should be able to return for a full refund any products
| that have security vulnerabilities that aren't addressed within
| the support period.
|
| Companies could opt to participate in a source code escrow
| program where the source code for the product is deposited with a
| third party, and if the company goes out of business or
| something, the source code is released with a sufficiently-
| permissive license that a sufficiently-motivated user community
| can fix bugs themselves and distribute them (but not necessarily
| use the code in other unrelated/competing products unless the
| company is okay with that).
|
| Companies should be required to disclose up-front any classes of
| vulnerability that they don't consider to be a security flaw.
| (E.g. a software product probably wouldn't be secure when run in
| an operating system that has been compromised by a malicious
| actor, or a network security product might not be secure against
| an attacker with physical access.)
|
| Just as a matter of terminology, I think it would be appropriate
| to refer to software security patches as product recalls, because
| that's effectively what they are.
|
| In the long run, I'd like to see a system where organizations
| could run something like a combination comilation/notary service.
| For instance, you have a server somewhere that people or
| companies can submit code to, and the server compiles the
| software and issues a digital signature for the compiled binary
| attesting that it compiled with no errors or warnings, and their
| linter couldn't find any problems. For something like C++ this
| might not be very interesting, but languages with stronger type
| guarantees might provide some confidence the program is at least
| not doing something that's nonsense. (Whether it's correct is a
| different problem than whether it's at least using memory and
| concurrency primitives in a sane way.) Someone might upload their
| code as safe Rust or Haskell or Agda or whatever, and the service
| could say "yeah, we're pretty sure this is memory safe and
| doesn't exercise undefined behavior." Companies could seek
| certificates from whoever the most respected compilation services
| are at the moment.
| ultra_nick wrote:
| I'd like if all IOT devices had an offline mode where network
| access is shut off.
|
| Most companies don't have the skills to make their devices
| secure. We should have the option to buy devices without network
| access. Devices that haven't been updated for a year should
| shutoff their network access automatically.
| convivialdingo wrote:
| As a developer and a consumer, what I'd really like to see is:
|
| - Manufacturer voluntary guarantee of 1/3/5 years security
| updates with an expiration date.
|
| - Separation of functionality and security updates.
|
| - The ability to "turn off" connectivity and retain full local
| functionality.
|
| - An industry security certification like UL.
|
| - A single point way of identifying and validating devices.
|
| As it is, I avoid using IoT mostly for security reasons. Having
| worked in security for many years I have seen the best and the
| worst. Having security isn't a panacea either - it needs an
| ongoing management & reporting infrastructure.
| thfuran wrote:
| >-The ability to "turn off" connectivity and retain full local
| functionality.
|
| >- An industry security certification like UL.
|
| I don't think those should be separated. UL is about safety
| and, while insecurity is roughly the software equivalent of a
| device's propensity to suddenly catch fire, reliability is also
| an important part of safety in all but the most frivolous
| applications, and local functionality is an important
| consideration for reliability.
| TeMPOraL wrote:
| Nest thermostat being one example, but myself I'm very happy
| I have IR remotes to the A/C at home, because I wouldn't want
| to be unable to turn on the cooling during one of the recent
| heatwaves over in Europe, just because Internet is down and
| the control app can't connect to the damn cloud.
|
| (Not that I mind networking in general. Operating those A/C
| units via Home Assistant app is a glorious and pleasant
| experience - entirely unlike the vendor's official app.)
| AnthonyMouse wrote:
| > Manufacturer voluntary guarantee of 1/3/5 years security
| updates with an expiration date.
|
| I just have to point out that these are all extraordinarily
| short numbers. There are industrial control systems that are
| still in operation despite being made out of mechanical relays
| from before the advent of microprocessors.
|
| We got used to electronics getting replaced every 3-5 years
| because if it's a laptop by then it will be considered slow and
| have a questionable battery. But these devices are now being
| permanently affixed to real estate.
|
| We need a way to update these devices that will outlive the
| manufacturers. Because many of the devices will.
| chromoblob wrote:
| Strange that in such a popular country this is so late.
|
| > Defining the Internet of things as "simply the point in time
| when more 'things or objects' were connected to the Internet than
| people", Cisco Systems estimated that the IoT was "born" between
| 2008 and 2009, with the things/people ratio growing from 0.08 in
| 2003 to 1.84 in 2010.[29]
|
| (https://en.wikipedia.org/wiki/Internet_of_things)
| mgulick wrote:
| Computer security is hard, and I think a "security label" would
| give a false sense of safety. Requiring manufacturers to respond
| to critical security vulnerabilities for a given period of time
| sounds like a good idea, but such rules often have unintended
| side-effects (like impacting startups, who maybe couldn't afford
| the certification or can't guarantee long term support). What we
| really need is local-only device access, so that I can firewall a
| device off completely from the internet, and still make full use
| of it with a local controller like home assistant. Locking down
| devices with the threat of DMCA violations to reverse-engineers
| actively reduces device security, and takes away my ability to
| fix devices myself.
|
| This overall strikes me as much lower priority than the currently
| ongoing ATSC 3.0 DRM doom. Please please please do something
| about this nightmare that broadcasters are imposing on the
| public. Don't let broadcasters take away my ability to watch live
| TV without an internet connection (resulting in a complete
| emergency broadcast system failure?). Don't let broadcasters take
| away my ability to record/time-shift live TV using software-based
| DVRs (e.g. Plex, Jellyfin), which could never possibly meet the
| "Nextgen TV" certification requirements!
| ptero wrote:
| > I've advocated for the FCC to require device manufacturers to
| support their devices with security updates for a reasonable
| amount of time [1].
|
| No offense intended, but I would be worried about this more than
| I would be worried about the current state of the IoT world. A
| blanket requirement would punish hobbyists and small companies
| prototyping new technologies. But big players could spend
| relatively minor technical and legal resources for publishing
| regular "security updates" without trying to find and close the
| biggest security holes.
|
| I would prefer that FCC works to inform: maintain an up-to-date
| database of issues (reported by both the manufacturers and by
| third-parties), impacts and recommended fixes for those that have
| a fix. My 2c.
| [deleted]
| wolverine876 wrote:
| > I would prefer that FCC works to inform: maintain an up-to-
| date database of issues (reported by both the manufacturers and
| by third-parties), impacts and recommended fixes for those that
| have a fix. My 2c.
|
| How would that help 99.99% of consumers? They are not going to
| look in databases, understand the issue, and apply fixes.
| SimingtonFCC wrote:
| None taken, of course. Several people in this thread have made
| this point, and it's a very reasonable one.
|
| The current framework is 100% voluntary for what amounts to a
| marketing label. There are non-FCC government databases for
| issue reporting, and a commitment to reporting to such DBs
| could be part of what earns you a higher label. Would be great
| to see commentary on this point from the tech public.
| nfriedly wrote:
| Here's a few things that I would find useful for IoT device
| labeling:
|
| 1) An indication of whether it supports local control, or
| requires an internet connection. (I can control my Philips Hue
| lights from my phone even when the internet is down, as long as
| they're on the same network. However, my MyQ Garage Door opener
| can only be controlled from my phone when both the phone and the
| garage door have an internet connection.)
|
| The reason this relates to security is that devices supporting
| local control can be completely firewalled, significantly
| reducing the attack surface.
|
| 2) A commitment of how long the device will receive updates.
|
| It should probably be in the form of an end date, or a number of
| years from the date of purchase, because "5 years of support"
| currently often means "5 years from when the product was first
| sold, which was 4 years ago, so you really only get 1 year of
| support if you buy today".
|
| Separate dates for features and security fixes would be
| acceptable.
|
| There should probably be some provision for vendors to extend
| this, since they would generally want to for devices that sell
| better. They should just be prevented from shortening it without
| penalties (e.g. a full refund offered to all purchasers.)
|
| 3) A clear indication of what happens after the above date passes
| - does the device continue working? become completely inoperable?
| loose some features? etc.
|
| 4) Some indication of openness, ideally in a way that encourages
| it. Maybe an "A+" rating requires that the vendor make available
| everything needed to compile and install a new firmware.
|
| Some differentiation could be made between devices that are open
| at the time of purchase and devices where the vendor has made a
| commitment to open it up after the support period ends.
___________________________________________________________________
(page generated 2023-09-05 23:00 UTC)