[swift-evolution] Prohibit invisible characters in identifier names

[Xiaodi Wu]

Yes. See earlier in the discussion about the Unicode confusables list. The
security issues that arise from confusable URLs aren't the same as those
for identifiers in Swift, and I think the short version of the previous
discussion is that prohibiting the use of Greek nu and mathematical bold
italic v, for instance, isn't necessary for security.

Thus, we're working off of a different Unicode recommendation specifically
drawn up for identifier normalization, which does not involve forbidding
confusables.

On Tue, Jun 28, 2016 at 14:43 Russ Bishop via swift-evolution <
swift-evolution at swift.org> wrote:

> Doesn't Unicode have a standard for this that specified which characters
> are look-alikes?
>
> Russ
>
> > On Jun 21, 2016, at 7:48 AM, Vladimir.S via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> >
> >> On 21.06.2016 7:37, Charlie Monroe via swift-evolution wrote:
> >>
> >>> On Jun 21, 2016, at 2:23 AM, Brent Royal-Gordon via swift-evolution
> >>> <swift-evolution at swift.org> wrote:
> >>>
> >>>> Perhaps stupid but: why was Swift designed to accept most Unicode
> >>>> characters in identifier names? Wouldn’t it be simpler to go back to
> >>>> a model where only standard ascii characters are accepted in
> >>>> identifier names?
> >>>
> >>> I assume it has something to do with the fact that 94.6% of the
> >>> world's population speak a first language which is not English. That
> >>> outweighs the inconvenience for Anglo developers, IMHO.
> >>
> >> Yes, but the SDKs (frameworks, system libraries) are all in English,
> >> including Swift standard library. I remember a few languages attempting
> >> localized versions for kids to study better, failing terribly because
> >> you learned something that had a very very limited use.
> >
> > Support Charlie's opinion. For me (as non-native English speaker)
> non-ASCII characters in identifiers had no sense, even when I start to tech
> the programming when I was a child. Expressions composed from identifiers
> written in my native language is not near correct sentences.
> >
> > Even more, we still have all other parts of language in English -
> for-while-guard-let-var-func etc..
> >
> >>
> >> When it comes to maintaining code, using localized identifier names is a
> >> bad practice since anyone outside that country coming to the code can't
> >> really use it. I personally can't imagine coming to maintain Swift code
> >> with identifiers in Chinese, Japanese, Arabic, ...
> >>
> >> While the feature of non-ASCII characters being allowed as identifiers
> >> (which was held up high with Apple giving emoji examples) may seem cool,
> >> I can only see this helpful in the future, given a different keyboard
> >> layout (as someone has pointed out some time ago here), to introduce
> >> one-character operators that would be otherwise impossible. But if
> >> someone came to me with a code where a variable would be an emoji of a
> >> dog, he'd get fired on the spot.
> >
> > Yes, but I don't believe Apple will accept limiting of character set for
> identifiers to ASCII *after* these presentations with emoji of a dog ;-)
> >
> >>
> >> I'd personally vote to keep the zero-width-joiner characters forbidden
> >> within the code outside of string literals (where they may make sense).
> >> I agree that this can be easily solved by linters, but: I think this
> >> particular set of characters should be restricted by the language
> >> itself, since it's something easily omittable during code review and
> >> given the upcoming package manager, this can lead to a hard-to-find
> >> malware being distributed among developers who include these packages
> >> within their projects - since you usually do not run a linter on a 3rd
> >> party code.
> >
> > I also think the main problem that could be caused by such tricks with
> zero-width-joiner or right-to-left-markers is injecting some malware code
> into sources in github, in package manager *or* even just in  code snippet
> on web page(so you copy-pasted it to your source). Right now I don't know
> exact method to implement such malware code, but I believe this
> vulnerability could be used some day.
> >
> > Btw, regarding the package manager. Will we have any protection from
> Typosquatting ?
> http://incolumitas.com/2016/06/08/typosquatting-package-managers/#typosquatting-package-managers
> >
> >>
> >> As for the confusables - this depends a lot on the rendering and what
> >> font you have set. I've tried  𝛎 → v with current Xcode and it looks
> >> really different, mostly when you use a fixed-space font which usually
> >> doesn't have non-ASCII characters which are then rendered using a
> >> different font, making the distinction easy to spot.
> >
> > In Russian we have these chars :
> > у к е г х а р о с ь
> > which are similar to english:
> > y k e r x a p o c b
> >
> > So you most likely can't differ `рос` and `poc` , `хае` and `xae` etc
> >
> > I don't think compiler should somehow decide if one non-English letter
> is looks like another English letter. But don't see any other method to
> protect myself other than using lints/checking tools for 3rd party code
> also.
> >
> >>
> >>>
> >>> Honestly, this seems to me like a concern for linters and security
> >>> auditing tools, not for the compiler. Swift identifiers are
> >>> case-sensitive; I see no reason they shouldn't be script-sensitive or
> >>> zero-width-joiner-sensitive. (Though basic Unicode normalization seems
> >>> like a good idea, since differently-normalized strings are `==`
> >>> anyway.)
> >>>
> >>> -- Brent Royal-Gordon Architechies
> >>>
> >>> _______________________________________________ swift-evolution
> >>> mailing list swift-evolution at swift.org
> >>> https://lists.swift.org/mailman/listinfo/swift-evolution
> >>
> >> _______________________________________________ swift-evolution mailing
> >> list swift-evolution at swift.org
> >> https://lists.swift.org/mailman/listinfo/swift-evolution
> >>
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160628/fb65ada0/attachment.html>