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 <[email protected]>
To: Thibaut <[email protected]>
Cc: Karl Palsson <[email protected]>, [email protected]
Subject: Re: luci-app-attendedsysupgrade and owut by default?
On Fri, Sep 26, 2025 at 5:06 PM Thibaut <[email protected]> wrote:
> Le 26 sept. 2025 à 16:57, Karl Palsson <[email protected]> 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
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
