Tools for Everyone - international and beyond

Features
1

Having tools that cater for everyone, is most important… and SAFE is one step ahead of the unsafe internet already. :ok_hand:

IDN and international urls

There is an accepted standard for urls, to allow use of international character sets.
Internationalized Domain Names (IDNA), sees urls transformed to form xn–blah and back again. So, browsers can choose to display the international url or the xn-- and look to the xn-- address in both cases. This get round one of the problems with how the old internet was established as latin centric.

So, for example, on the unsafe internet, президент.рф works as xn--d1abbgf6aiiy.xn--p1ai

Enter SAFE

  • SAFE network appears to handle international characters (I’ve not tested but expect it’s just bytes and not character sets)
  • SAFE Browser appears to just accept those more exotic characters as url!.. but does understand to translate to xn--

Question then: is IDN a legacy that we do not need - or is it so widely used that it is needed to assist domain owners move to SAFE?

=============

So, “test this”…

testthis
测试这个
kiểmtra
מבחןזה
проверитьэто

A simple hello world index.html
safe files put ./test/ --recursive

and create domains on the back of that with

safe nrs create testthis --link safe://hnyynywou5hf1dhw61jdsmc7ryoud65yeinn68sdgbojpzg97668p5877ebnc?v=0
safe nrs create 测试这个 --link safe://hnyynywou5hf1dhw61jdsmc7ryoud65yeinn68sdgbojpzg97668p5877ebnc?v=0
safe nrs create kiểmtra --link safe://hnyynywou5hf1dhw61jdsmc7ryoud65yeinn68sdgbojpzg97668p5877ebnc?v=0
safe nrs create מבחןזה --link safe://hnyynywou5hf1dhw61jdsmc7ryoud65yeinn68sdgbojpzg97668p5877ebnc?v=0
safe nrs create проверитьэто --link safe://hnyynywou5hf1dhw61jdsmc7ryoud65yeinn68sdgbojpzg97668p5877ebnc?v=0

sees option on these

safe://testthis
safe://测试这个
safe://kiểmtra
safe://מבחןזה
safe://проверитьэто

the result of which is

safe://testthis -> works
safe://测试这个 -> safe://xn--ciqt27ee4ursd stops because null at that address
safe://kiểmtra -> safe://xn--kimtra-qj8b stops because null at that address
safe://מבחןזה -> safe://xn--5dbgfd7ai stops because null at that address
safe://проверитьэто -> safe://xn--b1agjvdbhdta3im stops because null at that address (atm)

but just by example, this is fixable, if the xn address is also registered.
safe nrs create xn--b1agjvdbhdta3im --link safe://hnyynywou5hf1dhw61jdsmc7ryoud65yeinn68sdgbojpzg97668p5877ebnc?v=0
now works fine.

To remove IDN from the browser or not?

There is option then to consider xn-- legacy, in a world that the browser can handle international character sets directly… because the safe network handles those. That alternate would need a fix to the browser to remove the bounce onto xn–.
I wonder that we leave this as it is, noting the oddity that you need to also register the xn address.

to note

if you want to play with idn on linux install idn
sudo apt-get install idn
then you can move through idn with for example conversion and unconversion as:
echo "президент.рф" | idn | idn -u

:+1:

13 Likes
2

Yes. Junk it. 20 chars.

3 Likes
3

But the problem that idna solves for web site is still present: how to prevent safe sites spoofing. Simple well-known example: googIe.com is not google.com (and you can imagine the greater mess with non-ascii characters).

There is a Rust crate managed by the servo team that implements it (appropriately named idna). No need to reinvent the wheel, just use it.

2 Likes
4

I didn’t recognize that idn is dealing with known confusables… that above was just about the handling of utf-8 characters in urls and a conversion from xn–
Still, confusables are important to keep in mind. :+1:

1 Like
5

Sometimes inverting ideas, can prove creative…
=> “There is option then to consider xn-- useful”
but not for the legacy reason…

That a browser can use a url with a prefix, like xn-- warping urls to something else, tempts a simple solution to a challenge that SAFE will face.

Problem:

We understand SAFE is for everyone but that immediately raises some default challenges. People want censorship that reflects their values and politics exists necessarily to see some leaders represent others. So, for example, the individual might not want spam or covid19 or offensive material, where they can be sheilded from that. I wonder this capability in the browser, offers a simple answer…

Premise:

The network should not have opinion - because opinion is in part assumption; and errors follow from assumptions, because reality does not tolerate assumptions over time. However, the tools that people use, necessarily will support opinions. People are prone to error, through the assumptions that they make. With the best will in the world, most people will tend to error and for many that will be their route to progress. So, there is a question of how to accomodate and cater for everyone.

The like of the fierce anarchist and chaotic good, doesn’t always win the arguement in real world because they meet resistance from people who do not want to be forced or challenged. If you put anything out there, there is always controversy and difference of opinion. The important issue, is choice… the user should have choice; if they choose to default to anothers opinion to help support their own interest, then that it to be expected and no point resisting it.

Solution:

Looking at how simple it is atm to attribute domain to a SAFE url with safe nrs create I wonder that a domain host - a browser owner, could own prefix for example safe://yn–; their browser could display urls without that prefix and the user navigates as normal but with the browser affecting as-if it had replaced links with that prefix, because it manages those as and when the link is clicked, to look towards safe://yn–link rather than safe://link.

That domain registrar would need to pick up the cost of registering all the names that are the pointers, to what content they want to include. The cost obviously would setup a significant resistance, that would encourage include all by default… so, perhaps back to front but then the option might be, that they register domains for what they want to exclude with safe nrs create zz--domain --link safe://null?v=0 and then browser could test for safe://zz–domain before also then allowing follow on to download safe://domain, in the case that safe://zz–domain doesn’t null.

Consequence:

So, a domain prefix owner would populate as whitelist or blacklist or perhaps some mix, domains and urls that it considered appropriate for its audience.

The better test of any thought, is the extreme outliers; so, consider a group of users and how those are catered for - the sum of all groups then is everyone.

If you had a vulnerable group, for example children or conservatives, there could be domain registrar safe://abc-- who issues their own browser that only navigates safe://abc-- websites and excludes all others. They perhaps would choose to include, rather than choose to exclude domains.

Another extreme, would be a domain registrar safe://zz-- that excludes only a certain set of content and includes all other safe:// content by default. For example, excludes only safe://covid19 but by default includes all else.

The raw browser as safe:// could still exist as a view of all content - cli would do that too… but at risk.

This I wonder is a first pass at a world in which the network is truth and works because it is pure function; and the form of what follows then is a variety of tools that people choose to use. There is no one tool that suits everyone… but there is one network to rule them all!

Disclaimer: it’s midnight and I might have errored above :smiley:

4 Likes
6

:baby: or :snowflake:
:rofl:

7

Seems doable, how about rather than a prefix use the NRS name with subnames:

safe://covid19info.<my preferred censor>
safe://news.<my preferred censor>

I’m other words, no change need, it’s available as is. Or have I missed something?

2 Likes
8

So, that would see <my preferred censor> or <browser provider> or <my preferred firewall> own one domain. :thinking: :+1:

Is there no limit on the number of subdomains?.. if not, then browser provider would need to figure a way to limit to their own domain… defaulting to that for every request and then either checking for a subdomain that is a suggestion of what they do not approve of; or a subdomain that is a bounce forward to what they do allow; or a mix.

Is that doable with an add-on or is that a browser hardhack?.. and no, I’m not looking to pursue this but I wonder it is good to know there are options to offer to those who insist that they want them…

Seems like a good alternate… so, long as very many subdomains are possible.

9

The owner of the NRS name controls all possible subnames, so I think it does what you have in mind.

Someone can’t come along and register a subnames on someone else’s NRS name.

1 Like
10

This follows the ‘safe://<service>.<operator>’ style of self-organization that is possible via the safe network nrs which we have discussed in the past. A lot of possibilities.

1 Like
11

That’s the clincher. :+1:

Makes a lot of sense.

So for IDN… unless that is required for managing utf-8 confusables:
=>