[At-Large] UA Days

Sun Mar 31 12:40:05 UTC 2024

Karl,

You bring important points to the discussion.

Our daily internet use hides a bustling world of devices talking to each
other, from smart thermostats to fitness trackers. This device-to-device
communication (D2D) is essential, but challenges arise. Devices might not
be fully tested for real-world internet quirks, and slight variations in
how they speak the same language can cause problems. Efforts to make
devices accept all information can be risky for critical systems like cars
or medical equipment. Just like ensuring smooth conversations between
people, we need to make sure these silent exchanges run safely to keep our
devices working as expected.

Your statement argues against forcing embedded device controllers to run
Universal Acceptance (UA) code for several reasons:

   -

   *Security Risks:* Embedded devices often control critical functions and
   are rarely tested for complex code like UA. Running UA code on them
   significantly increases the risk of vulnerabilities that could be exploited
   by attackers.
   -

   *Unnecessary Burden:* Most embedded devices have limited functionality
   and don't need to understand a wide range of information. UA forces them to
   handle potentially risky data they're not designed for.
   -

   *Fragile Infrastructure:* The internet is already vulnerable, and adding
   complexities like untested UA code on embedded devices only makes it more
   fragile and prone to widespread disruptions.

If it is dangerous to make these essential, often unseen devices handle
complex tasks they're not built for, this could create new security holes
and make the entire internet infrastructure even more vulnerable,
especially when these devices have an international/global purpose.

My 2cents!
[image: photo]
[image: photo]

Alfredo Calderon
eLearning Consultant

aprendizajedistancia.blogspot.com

calderon.alfredo at gmail.com  |  wiseintro.co/alfredocalderon  |  Alfredo_1212
  |  Virtual School on Internet Governance  |  https://virtualsig.org

[image: facebook] <https://facebook.com/calderon.alfredo>

[image: linkedin] <https://pr.linkedin.com/in/acalderon52>

[image: twitter] <https://twitter.com/acalderon52>

[image: pinterest] <http://www.pinterest.com/acalderon/>

[image: slideshare] <http://www.slideshare.net/acalderon>

[image: twitter] <https://twitter.com/virtualschoolIG>

[image: wiseintro] <https://wiseintro.co/alfredocalderon>

IMPORTANT: The contents of this email and any attachments are confidential.
They are intended for the named recipient(s) only. If you have received
this email by mistake, please notify the sender immediately and do not
disclose the contents to anyone or make copies thereof.
Create your WiseStamp email signature
<https://www.wisestamp.com/lp/promo/professional-email-signature?utm_source=promotion&utm_medium=signature&utm_campaign=create_your_own&srcid=>

[image: __tpx__]

On Fri, Mar 29, 2024 at 2:33 PM Karl Auerbach via At-Large <
at-large at atlarge-lists.icann.org> wrote:

> 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>
> <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 listAt-Large at atlarge-lists.icann.orghttps://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/at-large/attachments/20240331/20f381c1/attachment-0001.html>