luci-app-attendedsysupgrade and owut by default?

[Hauke Mehrtens]

On 9/27/25 17:02, David Lang wrote:
> re: opt in vs opt out. If we can have this check mirrors rather than one 
> central point (and especially if we allow the check to hit non-optimal 
> mirrors randomly), it should mitigate the privacy concerns as there is 
> nobody who has logs from all the mirrors.
> 
> Also, a check every 24 hours seems aggressive, once a week or once a 
> month should be sufficient (as long as there is a way to manually 
> trigger the check as well)
> 
> David Lang
> 
> 
> On Sat, 27 Sep 2025, Jonas Gorski wrote:
> 
>> Date: Sat, 27 Sep 2025 13:30:36 +0200
>> From: Jonas Gorski <jonas.gorski at gmail.com>
>> To: Thibaut <hacks at slashdirt.org>
>> Cc: Karl Palsson <karlp at tweak.au>, openwrt-devel at lists.openwrt.org
>> Subject: Re: luci-app-attendedsysupgrade and owut by default?
>>
>> On Fri, Sep 26, 2025 at 5:06 PM Thibaut <hacks at slashdirt.org> wrote:
>>> > Le 26 sept. 2025 à 16:57, Karl Palsson <karlp at tweak.au> a écrit :
>>> >
>>> >> +1
>>> >>
>>> >> I think that if OpenWrt devices started *by default* to « phone 
>>> home » (whether directly or via an in-browser query), that would 
>>> certainly be a concern.
>>> >>
>>> >> Such a feature - while appealing - should *absolutely* be an opt- 
>>> in, and not an opt-out.
>>> >> Opt-out may also have legal implications (e.g. GDPR?).
>>> >>
>>> > FWIW, CRA implies that it _should_ be _opt out_ for updates, and 
>>> they should be enabled by default.  Yes, I know some people don't 
>>> like that, but people don't opt in :)
>>> >
>>> > Annex I, 2c)
>>> >
>>> > "ensure that vulnerabilities can be addressed through security 
>>> updates,
>>> > including, where applicable, through automatic security updates that
>>> > are installed within an appropriate timeframe enabled as a default
>>> > setting, with a clear and easy-to-use opt-out mechanism, through the
>>> > notification of available updates to users, and the option to 
>>> temporarily
>>> > postpone them;"
>>> >
>>> >
>>> > I would believe Hauke is looking at this from a CRA compliance 
>>> viewpoint, ... yeah, it should be opt out, not in....
>>>
>>> I see, thanks for the explanation. I indeed don’t like it but I see 
>>> the rationale, I stand corrected :)
>>>
>>> Hopefully we can make this work in an « as private as possible » way.
>>> Daniel’s suggestion seems pretty good in that context.
>>
>> Annex I(2) is "On the basis of the cybersecurity risk assessment
>> referred to in Article 13(2)", and Article 13 is "Obligations of
>> manufacturers". Since OpenWrt is not a "manufacturer" in the CRA
>> sense, this may not apply to us, so arguably we could get away with
>> disabled by default / opt-in.
>>
>> It's up to those that monetize OpenWrt to have this enabled by
>> default. Though more likely they'll have or want their own system for
>> that anyway, so what we do wouldn't have any impact on them.
>>
>> We could have an opt-in package that does nothing but enabling this by
>> default so you can easily create an image with it enabled by default.
>> Or remove from the package list it to have it disabled by default.
>>
>> Best regards,
>> Jonas

Hi,

We do not plan to do anything because of the CRA as long as nobody 
approaches us and is offering to pay us for services related to the CRA.

I agree with Jonas that automatic checking for updates should be an opt 
in in OpenWrt. We should direct it to our CDN which can handle the load.
Maybe we can cache it. In LuCI we can just ask the browser to check if 
the user opted in.

I like the requirement in the CRA for normal manufactures to have opt 
out automatic updates to increase the likelihood that user upgrade. This 
is very good for consumer devices and for internet security in general.

OpenWrt is not a manufacturer or open source steward in regard to the 
CRA. OpenWrt is out of scope of the CRA. People building commercial 
devices on top of OpenWrt are covered by the CRA.

If we really want to do automatic updates we need a much better QA 
process. We have to test the image on all supported real hardware before 
shipping. We have to test many different configurations. We have to 
install the updates in waves. We have to get telemetry back from the 
devices to judge if the update is successfully running on the first waves.

Hauke