[technology taskforce] [At-Large] Google Developers : Humans can't read URLs. How can we fix it? - HTTP 203

Tue Feb 11 18:06:55 UTC 2020

I viewed the video and my takeaway was that browsers can be configured for
a role in building confidence in domain names.

Very good discussion guys.

CAS

On Mon, 10 Feb 2020, 10:08 pm Dev Anand Teelucksingh, <devtee at gmail.com>
wrote:

> Dr. Alejandro Pisanty Baruch <apisan at unam.mx> wrote:
> "is this just one more iteration of "domain names will cease to be
> relevant soon" or is it a move or trend that will definitely undermine
> their importance and therefore also change the markets?"
>
> I think no, this is not an iteration about domain names becoming
> irrelevant. The discussion focused on how to ensure browser users can
> identify
> what domain they are visiting so IMO, it strengthens the use of domain
> names by having users trust the domain they are visiting.
>
> The challenge as I see it is with the prevalence of many new TLDs, the
> risk of phishing and malware attacks are higher where bad persons try to
> trick persons to either:
> - go to bad persons' website(s) at domains pretending to be another
> organisation/service in order to get user login credentials to such
> organisations/services or
> - open links to malware files and become infected.
>
> So typically, bad persons would use typos that look similiar to the
> legitimate domain or add a few characters before or after the 2nd level
> domain
> So for example.com, there could be exannple.com , examp1e.com,
> eexamples.com and examples.com .
>
> With more TLDs and wider use of ccTLDs, bad persons could also do things
> like examples.xyz, examp1e.tv and so on.
>
> With longer URLs, one can mask the legitimate domain as a third or fourth
> level subdomain of a bad persons' domain.
> Very long URLs like this are more difficult to parse and read on a mobile
> phone. Content Management Systems for websites over the years unfortunately
> generate long URLs that do work to direct persons to websites
> but are obscure for persons to parse.
>
> So an example of a bad URL :
>
> https://community.icann.org.can.work/display/atlarge/2020-01-27+At-Large+Technology+Task+Force+Call?preview=/126420432/126422910/atlarge-technology-taskforce-27jan20-en.pdf
>
> Persons glancing at this URL would see icann.org and may think everything
> is fine and go ahead and click on the URL when its not.
>
> Nearly all browser vendors are using the Public Suffix List at
> https://publicsuffix.org/ which started as a Mozilla Initiative.
> From the Public Suffix List website, a "public suffix" is one under which
> Internet users can (or historically could) directly register names.
> Tracking this is important to ensure that a website can't set cookies that
> other websites can read or modify under the same domain.
>
> What the episode showed was that Mozilla Firefox (at least on the desktop)
> highlights the part of the domain that is the public suffix by making it
> slightly bolder than the rest of the URL.
> It is however to me, very, very subtle and I wish that Mozilla (and other
> browsers) make the public suffix part more bold or even a slightly bigger
> font size to alert users as
> to the true domain being viewed.
>
> Some mobile browsers are showing only the domain and not the rest of the
> URL and allow for the full URL can be viewed and edited when you tap on the
> URL bar which also helps.
>
> Kind Regards,
>
> Dev Anand Teelucksingh
>
>
>
> On Sun, Feb 9, 2020 at 3:23 PM Dr. Alejandro Pisanty Baruch <
> apisan at unam.mx> wrote:
>
>> Dev,
>>
>> thanks a lot for sending this. While at first it may seem off-topic, it
>> cuts deeply into very relevant questions for us: is this just one more
>> iteration of "domain names will cease to be relevant soon" or is it a move
>> or trend that will definitely undermine their importance and therefore also
>> change the markets? If it proceeds, what balances of power will appear that
>> we don't face now? One example: will the companies that operate search or
>> that provide browsers (or both!) earn new powers? This is already being
>> discussed elsewhere. What are the views that are relevant for ICANN
>> Internet users At Large, and other stakeholders?
>>
>> Yours,
>>
>> Alejandro Pisanty
>>
>>
>> - - - - - - - - - - - - - - - - - - - - - - - - - - -
>>      Dr. Alejandro Pisanty
>> Facultad de Química UNAM
>> Av. Universidad 3000, 04510 Mexico DF Mexico
>>
>>
>>
>> +52-1-5541444475 FROM ABROAD
>>
>> +525541444475 DESDE MÉXICO SMS +525541444475
>> Blog: http://pisanty.blogspot.com
>> LinkedIn: http://www.linkedin.com/in/pisanty
>> Unete al grupo UNAM en LinkedIn,
>> http://www.linkedin.com/e/gis/22285/4A106C0C8614
>> Twitter: http://twitter.com/apisanty
>> ---->> Unete a ISOC Mexico, http://www.isoc.org
>> .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
>> ------------------------------
>> *Desde:* At-Large [at-large-bounces at atlarge-lists.icann.org] en nombre
>> de Dev Anand Teelucksingh [devtee at gmail.com]
>> *Enviado el:* viernes, 07 de febrero de 2020 11:21
>> *Hasta:* At-Large Worldwide
>> *Asunto:* [At-Large] Google Developers : Humans can't read URLs. How can
>> we fix it? - HTTP 203
>>
>> "In this episode, Jake makes the case that URLs are impossible for
>> humans to interpret, especially when it comes to security. What are
>> browsers doing today to overcome that? And, is there a better way"
>>
>> Watch the 20 min episode :
>> https://youtu.be/0-wB1VY3Nrc
>>
>> Dev Anand
>>
> _______________________________________________
> ttf mailing list
> ttf at atlarge-lists.icann.org
> https://mm.icann.org/mailman/listinfo/ttf
>
> _______________________________________________
> 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: <http://mm.icann.org/pipermail/ttf/attachments/20200211/77b1c0bf/attachment.html>