Re: [I18nrp] Conservatism principle doesn't go far enough

[Nico Williams <[e-mail]>]

On Mon, Feb 04, 2019 at 12:10:15PM -0800, Larry Masinter wrote:
> Let me be a little more careful. The document 

Thanks.

> https://chromium.googlesource.com/chromium/src/+/master/docs/security/url_display_guidelines/url_display_guidelines.md

| In general, the web platform does not have limits on the length of
| URLs (although 2^31 is a common limit). Chrome limits URLs to a
| maximum length of 2MB for practical reasons and to avoid causing
| denial-of-service problems in inter-process communication.

Ha.  I've seen stacks that fail to handle more than 4KB or 8KB request
header sizes including the start-line.

| On most platforms, Chrome’s omnibox limits URL display to 32kB
| (kMaxURLDisplayChars) although a 1kB limit is used on VR platforms.

I'm not sure how I could understand a 32KB URI in a status bar.  Or even
1KB.  And we're not talking about my parents here.

That document seems reasonable otherwise :)

> seems to be primarily about one use case:  The user has somehow
> navigated to a site (through links, typing in, search, whatever), and

I think we really have just these cases:

 - the user followed a link
 - the user pasted a link
 - the user typed something in exactly
 - the user typed something in and selected a partial match from a
   search engine

The specific case matters because if the user types it in, the UA must
normalize and so on, but if it's followed then...

If the user followed or pasted a link, then that needs to be sanitized
to some degree, and if it's malicious, then simply fail to follow --
don't just follow and attempt to indicate the maliciousness through the
status bar.

If the user picked an incremental result while typing... we should treat
that a lot like following a link (even if we trust the search engine).

Following a link in a page of search results is still following a link,
so search in any context other than typing in the status bar is not
special.

> is now looking at a web page; what should the UA show (in the address
> bar or any other security context) to validate “who is this coming
> from? Which site sent me this data? It says it’s my bank, did it come
> from them?”

The original sin here is the username:password@ optional prefix to the
authority component of the URI: it confuses many users (probably most).

So we should start by removing the username:password from the status /
origin bar!  (The Chromium doc says as much.)

If the URI was typed in, prep it as usual and use it.

If a link was followed, no prep is needed, but perhaps we should apply
it anyways since it's idempotent, applying ToUnicode() and ToASCII()
again to normalize.

The linked doc's proposal for how to handle bi-di scripts and "sneaky"
codepoints and characters is a good start.

It would be useful to know what scripts the user can read, that way the
UA can be a bit more dramatic about URIs whose authorities contain
characters from scripts foreign to the user.

Zalgo detection would be nice :)

> The spec is only about the visual display and doesn’t cover copy/paste
> or save-as-bookmark or other operations which work with a different
> form.

Copy/paste seems no different that following a link -- the UA won't know
the origin of the link, but we must not assume the user typed it in
somewhere.

> Insofar as
> 
> *	normalization doesn’t change the visual display (?)

Normalization indeed does not change the display.  It cannot.  That's
part of the definition of Unicode equivalence forms.

(I suppose there may be implementations where form artifacts leak to the
rendering, but that would be a bug.)

> *	The URL that was actually used for DNS was normalized before use anyway
> 
> then at worst the advice to normalize is harmless. So I take back my
> critique.

It is harmless to normalize again and again.  Normalization is
idempotent.

> https://www.m3aawg.org/sites/default/files/m3aawg-unicode-best-practices-2016-02.pdf
> 
> is about different use cases, with similar but not identical advice
> and requirements.
> 
> The original point, though, stands: the “Conservatism” principle
> doesn’t go far enough in warning those registering domains to avoid
> those labels which downstream processors will reject or display
> poorly.

I mean, a registrant can test how browsers would handle their domains.

But browsers can change how they handle the registrant's domains...

> Is it possible to get any statistics on DNS requests that include
> unnormalized strings? And some hits about where they come from?

A-labels that decode into non-canonical Unicode are busted.  I have no
numbers about them.

Nico
--