[EURO-Discuss] [At-Large] UA Days
Karl Auerbach
karl at cavebear.com
Fri Mar 29 18:33:18 UTC 2024
No, what I am saying is that things like embedded device controllers
ought not to be forced (or even socially coerced) to bear the risks of
running UA code that will almost certainly (for those devices) almost
never tested and may create vulnerabilities.
Our internet is already dangerously vulnerable and brittle, we don't
need to make it worse in the areas that we least see (such as the area
of device controllers.)
--karl--
On 3/29/24 11:01 AM, Roberto Gaetano wrote:
> Hi Karl
>
> I am not sure to understand correctly. Are you saying that farmers in
> Bangladesh, as an example, should not have access to the Internet in
> their language and script because of some bad code in Tesla cars?
>
> I hope I have misunderstood, please clarify.
>
> Cheers,
> Roberto
>
> Inviato da iPad
>
>> Il giorno 29.03.2024, alle ore 18:36, Karl Auerbach
>> <karl at cavebear.com> ha scritto:
>>
>>
>>
>> I would add, however, the observation that a large amount of internet
>> traffic does not involve humans at all. Rather it is device-to-device
>> traffic.
>>
>> I work with trying to test and improve the resilience of devices to
>> real or potential, but usually inadequately tested conditions. Many
>> devices wobble or simply fail when they face conditions beyond the
>> nice, calm networks of their developers. Those conditions may be
>> caused by natural conditions or otherwise.
>>
>> I have, for example, seen how the introduction of new devices, that
>> may speak a slightly different (but fully RFC compliant) version of a
>> protocol can knock-out what were previous stable devices on the
>> network. One of favorite examples comes from the days when we still
>> had TCP/IP bakeoffs when the introduction of a single PC using FTP
>> Software's stack could crash any and every instance of machines
>> running one of the their competitor's protocol stacks - the cause was
>> simply that they they sent a sequence of IP fragments with the last
>> fragment first (which allows the receiver to better optimize its
>> buffer space). That's 100% RFC legitimate, but it crashed other devices.
>>
>> Back to UA - We usually forget that anything beyond the most basic
>> cases will be mis- or weakly implemented and inadequately tested -
>> and thus potentially subject to outages due to "unusual" network traffic.
>>
>> I have fear that the "U" part in "UA" efforts will drive the addition
>> of that kind of mis- or weakly implemented UA code in devices that
>> almost always will not have any operational reason to go beyond
>> classic ASCII. Such devices may be in critical roles - self driving
>> vehicles, power plant controls, etc etc. (An appropriate protective
>> strategy for such devices might simply be for them to silently reject
>> and drop anything that is not ASCII rather than trying to deal with it.)
>>
>> I have a Tesla automobile. It is already filled with some really
>> badly designed and badly written code. Automobiles are already
>> speaking TCP/IP on automotive Ethernets that are sometimes connected
>> to the outside world. A typical vehicle of today may have hundreds
>> of processors attached-to and chatting-on those internet networks. I
>> fear further risks should, hypothetically, should something like a
>> Unicode string get onto a controller net in a car and cause something
>> like a brake anti-lock/stability-control processor to go awry. (I've
>> already experienced what can happen when a stability control system
>> goes bad - it can be a shockingly terrifying experience, especially
>> if it happens on a crowded highway downhill curve at high speed.)
>> (And I am reminded of the fate of the Mars Climate Orbiter when a
>> mismatch between US measurements [inches, feet] and metric
>> measurements caused the probe to crash.)
>>
>> As a kid I worked with my grandfather and father repairing TVs - ones
>> with vacuum tubes! Those boxes were very sensitive to less-than
>> usual operating conditions - like being used on the same power
>> circuit as a refrigerator that had a motor that generated noise onto
>> the utility power wiring in a house. In those days there was a joke
>> that was quite applicable: A person goes to a Doctor and says it
>> hurts when I do this (and demonstrates some activity that constitutes
>> "this"). The Doctor's reply is: Then stop doing that.
>>
>> Same for UA. Perhaps the "Universal" part needs to be de-emphasised
>> by a recognition that there will be large parts of our internet for
>> which that is not necessary, could add costs, and, worse, could
>> create risks.
>>
>> --karl--
>>
>> On 3/29/24 9:51 AM, Carlton Samuels via At-Large wrote:
>>> A proposition worthy of our support, especially from those of us
>>> that are still concerned with equitable Internet access! An
>>> insightful view of how a change in the conversation could
>>> positively impact the lowly end user.
>>>
>>> Many thanks Roberto.
>>>
>>> Carlton
>>>
>>> ==============================
>>> /Carlton A Samuels/
>>> /Mobile: 876-818-1799
>>> Strategy, Process, Governance, Assessment & Turnaround/
>>> =============================
>>>
>>>
>>> On Fri, 29 Mar 2024 at 11:23, Roberto Gaetano via At-Large
>>> <at-large at atlarge-lists.icann.org> wrote:
>>>
>>> Hi all
>>>
>>> I have attended the UA Days in Belgrade. I am taking the
>>> opportunity of a delay in my flight back to drop some notes.
>>>
>>> The meeting was very interesting. We had a full house in the
>>> morning, with numbers decreasing in the afternoon. I don’t know
>>> about the online participation. Please find the programme here:
>>> https://uaday.rs/program/?lang=en
>>>
>>> The first panel was about multilingualism, Sally Costerton was
>>> among the speakers. It seems that the concept that the ultimate
>>> goal is multilingualism in the Internet is taking speed. To be
>>> noted that Anil Kumar Jain, UASG Chair, mentioned the four
>>> “pillars” among which there is no mention of the role of the
>>> user community. Interesting contribution by Leonid Todorov,
>>> arguing that we will have a stronger push to UA readiness from
>>> places and people that are more disadvantaged rather than from
>>> places and people that are better aware - in an intellectual way
>>> - about the need for equality of opportunities in internet access.
>>>
>>> The second panel featured some registries that have been active
>>> in achieving results in term of UA readiness. I was the last
>>> speaker, and brought the point of view of the users, who are the
>>> most affected by lack of UA, making also a couple of examples.
>>> The good news is that my contribution was well received, the bad
>>> news is that I made the point that the user community should
>>> play a role - I argued that it should be the “fifth pillar” in
>>> the UA strategy - as users can put pressure on the providers
>>> that are not UA ready, proposing that we have a paradigm shift
>>> from “providers will graciously become UA compliant as a bonus
>>> for the users” to “users worldwide have the right to demand that
>>> all users have the same Internet experience regardless their
>>> language or script they use”. The bad news is in the fact that I
>>> have proposed that the user community - and At-Large at the
>>> forefront - use their footprint in the wider community to build
>>> awareness of the user rights and produce pressure - also in
>>> collaboration with governments - to providers to be UA
>>> compliant. That means a call for action for At-Large.
>>>
>>> In summary, we need to move from being spectators, waiting for
>>> things to happen, for the technical community to provide
>>> solutions, for providers to deploy UA-compliant services, to an
>>> active part of the community to demand and obtain the same level
>>> of service for all Internet users, regardless language, script,
>>> physical location, or other factors.
>>>
>>> Cheers,
>>> Roberto
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> At-Large mailing list
>>> At-Large at atlarge-lists.icann.org
>>> https://atlarge-lists.icann.org/mailman/listinfo/at-large
>>>
>>> At-Large Official Site: http://atlarge.icann.org
>>> _______________________________________________
>>> By submitting your personal data, you consent to the processing
>>> of your personal data for purposes of subscribing to this
>>> mailing list accordance with the ICANN Privacy Policy
>>> (https://www.icann.org/privacy/policy) and the website Terms of
>>> Service (https://www.icann.org/privacy/tos). You can visit the
>>> Mailman link above to change your membership status or
>>> configuration, including unsubscribing, setting digest-style
>>> delivery or disabling delivery altogether (e.g., for a
>>> vacation), and so on.
>>>
>>>
>>> _______________________________________________
>>> At-Large mailing list
>>> At-Large at atlarge-lists.icann.org
>>> https://atlarge-lists.icann.org/mailman/listinfo/at-large
>>>
>>> At-Large Official Site:http://atlarge.icann.org
>>> _______________________________________________
>>> By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://atlarge-lists.icann.org/pipermail/euro-discuss/attachments/20240329/27dd714d/attachment-0001.html>
More information about the EURO-Discuss
mailing list