Internet Safety Labs provided our comments to the FCC’s IoT Cybersecurity label. Among the comments and recommendations we made, the FCC’s IoT Cybersecurity label should answer the question, “Does this product have reasonable cybersecurity in place throughout the device and integrated components?”

We’ve provided our comments for public view below:

 

October 6, 2023

Federal Communications Commission
45 L Street NE
Washington, DC 20554

To: Chairwoman Rosenworcel and Commissioners Starks and Simington

Subject: Regarding PS Docket No. 23-239, Cybersecurity Labeling for Internet of Things

Internet Safety Labs (ISL), a non-profit software product safety testing organization, respectfully submits the following comments on PS Docket No. 23-239, Cybersecurity Labeling for Internet of Things.

For context, ISL currently provides product safety labels for mobile apps (add link here appmicroscope.org, Appendix A includes a sample label). Since 2019, we have been measuring the risky behavior of software and software driven products to ensure product safety for the users of technology. Our ten principles of safe software can be found here: https://internetsafetylabs.org/resources/specifications/principles-of-safe-software/

Key software behaviors we test for in our open software safety standard for mobile apps and websites are:

– User privacy,
– User autonomy/freedom of action,
– Fair treatment of users [by the software], and
– Accuracy of notices.

Cybersecurity principles, methods and practices contribute to all of the above and are a necessary but not sufficient condition for safe software behavior. For instance, user privacy can be breached by malicious attacks on back-end business computing equipment, or on the consumer device itself, OR it can be breached through intended and unintended behaviors of the application software/logic. We refer to the latter as programmatic harms, inherent, unavoidable harms “baked into” software behavior. From the consumer perspective, both matter, but possibly only in a holistic context of “Is this product/service reasonably safe for me to use?” We, however, do not advocate for expanding the definition or scope of “cybersecurity” with respect to this proposed label. The cybersecurity measures as proposed in the current rulemaking are complementary to an overall product safety label and therefore valuable. From our experience in producing safety labels, limiting scope will facilitate implementation and scalability. To that end we suggest the following initial boundary to this label project: we suggest that the label focus strictly on measurable cybersecurity behaviors and not on broader data privacy issues. Essentially, the label should provide clarity on this question: “does this product have reasonable cybersecurity in place throughout the device and integrated components?”

Along these lines, we note that privacy enforcement currently appears to be the domain of the FTC, while the Product Safety Commission is responsible for other types of product safety. This program introduces the FCC into another facet of related product oversight. This governance fragmentation may be hampering a consumer-oriented, holistic view of product safety. People shouldn’t have to be cybersecurity experts or privacy practice experts, and from our research, they just want to know that they can trust the technology to be reasonably safe. Also from our research, it’s clear that a neutral 3rd party evaluation of product safety is necessary for credibility of any labeling/certification program. Thus, we have general confidence in the proposed operational architecture of the testing program, and scope of the label which appears to be limited to cybersecurity assessments.

Other recommendations:

– We recommend that the cybersecurity label indicate when and how personal data is encrypted. We also recommend that the program mandate encryption of data at rest and in transit throughout the software ecosystem.
– We recommend that the labels become mandatory for all IoT devices over time.
– We recommend that the standardized label design be a product of a multidisciplinary open forum, including a large proportion of end users, representing a diverse range of abilities.
– While manufacturers must provide testing results as an input to the label program, the testing results must be independently reproduced by the testing entity.
– Physical labels will be obsolete nearly as soon as they are printed. They seem quite likely to give customers a false sense of confidence in the information on the printed label.

• • Need to better classify which items on the label are relatively static over time and which aren’t. A printed label must remain true for as long as the product is in use, otherwise, the label must be so highly caveated as to be rendered toothless for consumers.
  • E.g. the first thing one does with nearly all IoT devices upon box-opening is update the firmware. Can we distinguish between immutable behaviors and the dynamic behaviors? Are there/can there be truly immutable behaviors?
  • The likelihood of someone clicking through to a dynamic safety label at the store seems low, though shoppers seem likely to research labels online beforehand. They won’t however know which version of the product is on the shelf when they arrive at the store, and that will therefore introduce doubt into whether or not their earlier research applies.

– This labeling project illuminates the challenge of trying to apply a static, physical artifact to an inherently dynamic (i.e. software-driven) collection of components that, frankly, not even manufacturers always fully understandⁱ.

• • We are not lawyers, but we wonder about the manufacturer liability for information on the label, printed or otherwise.

Thank you for the opportunity to provide comments on this important initiative, we hope these recommendations are of benefit.

Respectfully,

Lisa LeVasseur

Executive Director
Internet Safety Labs

 

Appendix A – ISL Mobile App Safety Label

Footnotes:

i. https://www.techradar.com/news/facebook-has-no-clue-where-your-data-goes-leak-suggests