Matter / Thread and privacy - can we prevent devices from phoning home and spying?

Configuration Matter/Thread
1

Edit: I analyzed the spec, and it does not look good. See my post below Matter / Thread and privacy - can we prevent devices from phoning home and spying? - #20 by imagio

Boils down to no guarantee devices don’t spy, manufacturers can require you to use their (possibly defunct) app/site for pairing, and no guarantee local control works.

I guess I’m sticking with zigbee and zwave then! Matter seems like it will be a minefield of a few good devices in between a bunch of enshittified spying remote-brickable cloud junk you don’t own.

Original post

Now that Matter 1.5 is official (the spec, not in HA yet AFAIK) it’s looking like Matter/Thread are shaping up to be quite capable and probably a better experience than raw wifi and zigbee. That being said, I’m concerned about privacy, and searching hasn’t revealed much so I wanted to ask the knowledgeable and awesome people here.

Can we prevent Matter / Matter over Thread devices from accessing the internet given that Matter is an IP protocol?

I know the spec says they’re supposed to work local only, and that’s great, but it doesn’t say they can’t use their TCP/IP network capabilities to send every bit of data collected back to their manufacturers and/or worse, spying companies like facebook/google/amazon.

It’s well known that many/most cheap wifi smart home devices are wildly insecure and along with “smart” appliances they send loads of data back to their manufacturers. Sometimes that legitimately is used for innocuous product improvement. Other times it gets into the hands of advertisers and data brokers who build the kind of creepy profiles of you that cause ads to pop up about something you literally just discussed in the privacy of your own home.

For this reason I generally stick to zigbee devices and isolate IoT wifi devices to a vlan/subnet where they can’t talk to the internet or anything other than each other and HA. Unfortunately it doesn’t seem like that can work with Matter. AFAICT Matter (over wifi) has a pretty strict requirement for devices to be on the same ssid/subnet as devices that want to talk to them like homepods, iphones, etc.

Does anybody have any insight into Matter / Matter over Thread, privacy, and keeping it local only?

It would be great to gain more clarity on this topic so it could be formalized on a wiki page for others like me who are curious about Matter but privacy conscious (which I think is a lot of HA users).

1 Like
2

I don’t know, but if you are not already aware, there is a similar discussion @ Do Matter "owners" mind the integrated "kill switch"? 🧱

3 Likes
3

I had not seen that, thanks, very interesting! There’s a lot of hyperbole on that thread. I get why the CRS thing is a feature, but whether or not it’s a “remote kill switch” depends on a lot of factors such as

  • Does commissioning a matter device require an active internet connection that checks a remote master certificate revocation source, or is it up to the controller when/if to update that list?
  • Do any devices do certificate revocation checks themselves or is it entirely left to the controller?
  • Do controllers have the ability to ignore and commission a device anyway?
  • Do devices do any CRS check of other devices when communicating directly between them or is it entirely a commissioning time controller side thing?

The certificate revocation thing may not be an issue at all depending on the answers to those questions. If a certificate revocation means nothing more than “your controller warns you the device is uncertified but you can do what you want regardless” then I see no problem. If it’s “devices phone a master list regularly and check every device they communicate with against the revocation list” then it’s a really huge problem.

4

All of the info in the other thread along with your questions are the reasons I stay away from the Matter/Thread craziness!

With all of that, and the fact that you have to ask ‘Matter / Thread and privacy - can we prevent devices from phoning home and spying?’ makes me wonder why you even want to have those devices.

Just saying.

1 Like
5

Block all non local address(WAN). You can whitelist anything you deem OK or necessary. Really block it at firewall from all network connectivity and allow in HA or matter server. If that keeps
Inform working return it and move on

Pretty much what you should do for any IOT device.

1 Like
6

I don’t see any reason why the rug pull that futurehome did shouldn’t have worked the exact way if it would have been a matter device.

2 Likes
7

I get all that, but as I said above, the details matter.

If the answer to those things is “it’s up to the controller” then I see no problem at all. Sure a company could still “brick” devices aimed at non-technical consumers who run closed proprietary controllers but there would be no problem for us users of open systems.

1 Like
8

:point_down:

Onboarding via mobile is only possible with apple or google cloud according companion app docs :bulb:

It seems like a controller thing. But as matter specs allow to integrate third party cloud for full functional (even) OTA your device might also update itself an introduce new paywalls like futurehome did for example :money_with_wings:

The linked post does explain this, it probably violates matter specs but as HA matter controler is open source you might be able to (nothing for the faint hearted if you follow the link)…

Again probably controller thing as it delegates DCL downstream to the devices.

All of this is quite what the first response with link to your thread is about.

Matter specs allow to integrated cloud/app/account to have full functionality of a matter enabled devices. Matter devices therfor can be controlled by the owner/manufacture (not buyer!) the same way as any other WiFi enabled devices, again take futurehome as an example when the shit hits the fan :poop:

2 Likes
9

OK so poking around a little bit it seems it’s entirely up to the controller and completely bypassing attestation / cert verification is as simple as this tiny patch to the controller

diff --git a/src/controller/CHIPDeviceController.cpp b/src/controller/CHIPDeviceController.cpp
index 444b48bcf1..e014e531aa 100644
--- a/src/controller/CHIPDeviceController.cpp
+++ b/src/controller/CHIPDeviceController.cpp
@@ -1227,7 +1227,7 @@ void DeviceCommissioner::OnDeviceAttestationInformationVerification(
         }
     }
 
-    if (result != AttestationVerificationResult::kSuccess)
+    if (false && result != AttestationVerificationResult::kSuccess)
     {
         CommissioningDelegate::CommissioningReport report;
         report.Set<AttestationErrorInfo>(result);

So at least it seems like there’s not really a problem for open system users like us on HA. We can easily totally bypass cert checks or have it reported back to the user as a warning. Personally I’m fine with that, at least from this cursory glance at the code I don’t see anything nefarious in the design that’s intended to allow permanent remote bricking no matter what. It appears to simply be what it says – a check against a list of known bad certificates to protect non-technical end users whereas technical users can do whatever they want.

edit: Note that this still doesn’t address my original concerns of devices being able to phone home. At least so far it seems that for matter over wifi it would still be smart to mac block them from accessing wan.

10

Again, if it is a WiFi matter device it probably phones home already. It is quite normal to need an app/account and manufacture cloud to even have full functionality :warning:

11

Maybe I’m not communicating clearly, sorry if that’s the case. I know the spec allows for extra non-standard manufacturer specific functionality that depends on the manufacturer’s cloud. I’m fine with that. I’ll just avoid devices that have manufacturer specific cloud linked features or use them local only without those features.

AFAICT the spec allows for manu specific cloud linked features but for any standard spec compliant functionality local control is required.

edit: to clarify I see that as totally separate from phoning home telemetry and spying data. If manufacturers want custom functionality linked to their cloud fine, I just won’t use that function, but it’s still unclear if I use a device with no cloud controlled function whether or not it will phone home and spy on me anyway.

12

Then you think different from manufactures. Why do you think they force you to install an app with trackers (maybe even ads) and force to provide personal details like email address to be able to make use of “your” device? :thinking:

Well, it seems to be enough to get matter certified to only expose ON/OFF control and scene control to be matter compliant :person_shrugging:

Ending up with almost dumb smart devices. Simple things like power on state for example requires already some one else’s computer(cloud), app and account :put_litter_in_its_place:

2 Likes
13

I get where you’re coming from but this feels like FUD. Sure manufacturers can force you to signup for their service if you want to use the non-spec features that they added. They can’t force you to sign up for their service to use spec compliant features AFAICT. Just don’t buy devices that have manufacturer specific functions you want to use. I don’t see any problem with this. It supports non-technical users and enhances non-spec functional flexibility for manus to differentiate their products while allowing technical users choice.

14

Can we please try to return to the original purpose of this topic? That is can/do spec-compliant matter devices “spy” and phone-home to the internet even when you don’t use cloud linked manu specific functionality and only control locally?

1 Like
15

Or just to make use of matter :grimacing:

16

I understand your wariness and your position. AFAICT there’s no evidence that provisioning can force you to use some manu specific crap. Enshittification is very real, and I loathe it, but unless there’s some evidence (in the spec text, source code, or actual devices) it doesn’t appear to be applicable here. Let’s please keep this on topic about the privacy aspects of matter being an IP based standard.

17

You think twisted. If it is not specifically prohibited (freel fee to provide evidence!) it is allowed. The previous linked thread from August 2024 just comes to the conclusion that it is actually allowed (posted by a HA moderator who thought prevousily it isn’t) :person_shrugging:

18

Orange-assistant is targeting Matter in that Thread, but the fact is that Zigbee devices have the same features, so it goes for both Zigbee and Matter.

19

Directly the spec, in the section about commissioning

◦ If the Commissionee fails the Device Attestation Procedure, for any reason, the Commissioner MAY choose to either continue to the Commissioning, or terminate it, depending on
implementation-dependent policies.
◦ Upon failure of the procedure, the Commissioner SHOULD warn the user that the Commissionee is not a fully trusted device, and MAY give the user the choice to authorize or deny
the commissioning. Such a warning enables user choice in Commissionee trust on their Fabric, for development workflows, as well as homebrew device development. Such a warning
SHOULD contain as much information as the commissioner can provide about the Commissionee, and SHOULD be adapted to the reason of the failure, for example by being different
between the case of an expired certificate versus a revoked PAI certificate.

It is entirely up to the commissioner (open source in the case of HA) whether or not to allow devices thatt fail attestation to join.

More from the spec

5.7.3. Custom Commissioning Flow
• A Custom Commissioning Flow device SHALL require interaction with custom steps, guided by a
service provided by the manufacturer for initial device setup, before it can be commissioned by
any Matter commissioner.
• A Custom Commissioning Flow device that supports the Enhanced Setup Flow SHALL include a
usable Onboarding Payload on-device or in packaging, so that a Commissioner which supports
the Enhanced Setup Flow can commission the device using the information provided in the
Onboarding Payload.
◦ Such a device SHALL follow the rules for Manual Pairing Code and QR Code Inclusion.
• A Custom Commissioning Flow device which does not support Enhanced Setup Flow MAY
include the Onboarding Payload on-device or in packaging.
◦ If the Onboarding Payload is included, then it SHALL follow the rules for Manual Pairing
Code and QR Code Inclusion.
◦ If the Onboarding Payload is not included, then it SHALL be provided to the user through
other means provided by the manufacturer.

So it appears that manufacturers CAN require you to use a custom commissioning flow. They CAN preset terms and conditions you must accept to commission the device. They CAN force you to use their app/website for the commissioning flow. They have NO REQUIREMENT to keep their custom commissioning flow working or not to place arbitrary restrictions upon it.

Basically the spec says manufacturers can either use one of the standard flows or they can use their own custom one that does more or less whatever they want.

The one upside I found in the spec is that they’re required to indicate in the DCL (distributed compliance ledger, publicly readable) that they use a custom commissioning flow and the URL for said flow. That means it should be trivial to exactly list which matter devices are designed this way and which ones work with standard local setup.

Overall disappointing the spec allows this with absolutely no requirements on the manufacturer to support it or require an offline alternative. At least they made it easy to identify these devices I guess, and many will probably use standard flows where it’s not a problem.

1 Like
20

I ran the spec through chatgpt. Here’s it’s analysis of privacy with matter.

The Matter 1.5 specification provides no mechanisms to prevent devices from “phoning home,” no requirements for local-only operation, and no rules limiting a manufacturer’s ability to collect data once the device is commissioned.
The only privacy protections in the spec apply to the commissioning/advertising phase (rotating IDs, limited metadata). After joining the network, a Matter device behaves like any other IPv6 device and may freely contact external servers unless restricted by the user’s own firewall or network configuration.

and for local control the analysis is

What the spec does NOT say:

1. No clause requires that all operational features work offline

There is no mandate that:

  • All features must work without Internet
  • Control must be possible offline
  • Cloud lock-in is prohibited
  • Devices must remain operational forever offline once commissioned

There is no “right to offline operation” defined anywhere.

2. No clause prohibits a manufacturer from crippling devices without cloud connectivity*

Nothing prevents manufacturers from:

  • Requiring cloud authentication for control
  • Requiring periodic check-ins
  • Disabling major functions when offline
  • Preventing local control if cloud services are unavailable

The spec simply does not address—let alone forbid—these patterns.

3. No clause guarantees local control in perpetuity

There is no requirement that:

  • Local commands must always work
  • Cloud services cannot be required post-commissioning
  • Firmware cannot introduce cloud dependencies in the future

Matter is a local protocol, but the spec does not guarantee local autonomy.>

What the spec does enforce

Secure, local protocol mechanics

After commissioning:

  • Devices publish local IPv6 addresses for direct control(AAA records listing addresses they accept operational messages on)
  • Matter messaging is fully local, via secure PASE/CASE sessions
  • Operational discovery is local (DNS-SD/mDNS)
  • Controllers communicate directly with the device locally

But none of this stops a device from requiring cloud involvement at a higher level.

A device can always:

  • Reject local commands unless authenticated via cloud
  • Turn local endpoints “off” unless online
  • Require a cloud-driven policy engine
  • Disable functionality via firmware

The protocol only ensures that local transport is possible , not that local control must be honored .

and about commissioning that’s conditioned upon manufacturer’s app/website (you don’t own it and can’t commission it without their permission)

:heavy_check_mark: The spec does allow Matter devices that cannot be commissioned without manufacturer involvement.

:heavy_check_mark: The spec allows the manufacturer to require a cloud / website / app for commissioning.

:heavy_check_mark: Therefore, a manufacturer can effectively “brick” a device by shutting down the required commissioning service.

There is no requirement in the Matter 1.5 Core Spec that every device must support a local or offline commissioning path.

So unfortunately the conclusion seems to be no guarantee of privacy, local control, or even pairing a device without the approval of the manufacturer.

I guess I’ll stick to zigbee/zwave then!

3 Likes