[At-Large] UA Days

Fri Mar 29 18:01:10 UTC 2024

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<mailto: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<mailto: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<mailto: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/20240329/87f2ae27/attachment-0001.html>