Wandering Thoughts archives

2019-09-20

Modernizing (a bit) some of our HTML form <input> elements

We have a Django web app for handling requests for Unix accounts, which has some HTML forms (in fact it's basically half HTML form filling). These forms (and all of the app's HTML) were put together years ago and only looked at on the desktop at the time. Recently, I poked around the app's forms on the work iPad to see how it would go. Even after I fixed the traditional viewport issue (see the comments), there were little irritations; for example, when you entered your desired Unix login, the iPad wanted to capitalize the first letter as part of its general auto-capitalization. Our Unix logins have to be all lower case, so this was a point of friction. Naturally I wondered if it was possible to improve the experience.

(Our Django web app was written in 2011, and we first got a work iPad in mid-2014. In 2011, not checking phone and table browser behavior was not crazy; today, it probably is and we likely should pay more attention to how all of our sites look on them.)

Unsurprisingly, there are ways to improve the situation by simple changes to our HTML, although not all of them were completely successful. You can find a variety of people writing about this online, and also the MDN page on <input type="text"> form fields, although it doesn't mention the autocapitalize attribute. The short version is that we apparently want to set all of the following attributes for text field that is supposed to be a login:

<input type="text" autocapitalize="none"
   autocorrect="off" spellcheck="false" ...>

Spellchecking is obviously not applicable; very few logins are dictionary words. Autocorrection is similarly probably not desirable, and autocapitalization is what we started out not wanting. The autocorrect attribute is a Safari extension, but apparently Android may want you to use autocomplete instead (which is a nominally standard attribute with all sorts of possible values).

The form also has a field for people's names. I set this to 'autocapitalize="words"', and should probably also set it 'autocomplete="name"' now that I've read about it. On my iOS devices, some combination of the attributes we're using (possibly including a 'name="name"' attribute from Django) causes Safari to be willing to autocomplete it from your contacts, which is handy if your contacts include yourself.

My less successful experiment was setting a 'pattern=...' and a 'title=...' attribute on the field for your login. What I wanted was for the browser to automatically react with a helpful error message when you entered an invalid character, but my flailing around so far hasn't produced this. We have some additional client side validation, but they involve a server check and so only trigger when the field is de-focused; faster feedback would be nice. However, my initial reading left me with the impression that doing a good job of this across both desktop and mobile browsers would require more JavaScript than I wanted to write.

(MDN has a useful page on general form validation, which I haven't read all of.)

All of this (including writing this entry) has done a good job of showing me how ignorant I am about modern HTML. Things have definitely changed here over the last decade or so, which is good to see even if it leaves me well behind the times.

PS: Django is already setting appropriate 'type=...' values on things like the field for your email address, or that would be another obvious and necessary change to make here.

ModernizingSomeInputElements written at 23:08:14; Add Comment

2019-09-18

Firefox, DNS over HTTPS, and us

The news of the time interval is that Mozilla will soon start rolling out DNS over HTTPS for US users, where by 'rolling out' Mozilla means 'enabling by default'. To their minimum credit, Mozilla says that they will explicitly notify people of this change and give them the opportunity to opt out. I hope and assume that this will work much like how Mozilla rolled out various tracking protection measures, including with how thoroughly informative that was.

(Clearly notifying people and giving them the chance to opt out is the obvious right thing to do, but Mozilla's track record on doing the obvious right thing is somewhat mixed.)

Since we're not in the US, this doesn't immediately affect people here; however, I have to assume that Mozilla is going to start rolling DNS over HTTPS out more broadly than just the USA. Given things like GDPR, Mozilla may not push this to Europe any time soon, but there probably aren't many roadblocks for rolling it out in Canada. My overall views on this remain unchanged; there are tradeoffs in either direction, and I have no idea what the right choice is in general.

For my department in particular, Firefox switching to DNS over HTTPS presents a potential problem because we have a split horizon DNS setup where some names resolve to different IPs internally than they do externally. According to Mozilla's blog post, the Firefox DoH implementation has some heuristics to detect a split horizon DNS environment, but from the vague descriptions we have so far it's not clear if they would reliably trigger for our users. If people here wind up with Firefox configured to use DNS over HTTPS and Mozilla's split horizon DNS heuristics don't trigger, they won't be able to connect to some of our hosts. We could theoretically say that this is people's fault in the same way that setting their machine to always use one of the public resolvers is, but this is the wrong answer, since Mozilla will have made this setting for them.

Mozilla currently supports a way for networks to explicitly disable DNS over HTTPS, by making your local resolver return NXDOMAIN for a canary domain. This is easy to do in Unbound, which we use on our local OpenBSD resolvers (see here or here). We could preemptively deploy this, but I tentatively think that we should wait to see if the Firefox split horizon detection heuristics work in our environment. Working heuristics would be the best answer for various reasons (including that Mozilla may find too many people abusing the canary domain and start paying less attention to it).

For work, there's probably no point in adding DNS over HTTPS to our local resolving DNS servers, even once it's supported on the OpenBSD version of Unbound. As far as I know, people here would have to specifically configure their Firefox to talk to our servers, and then their configuration would break when they moved outside of our network and could no longer reach our resolving DNS servers.

For my own personal use, I may eventually add DNS over HTTPS support to my resolving Unbound instances, because apparently DoH is the only way to get encrypted SNI. Unfortunately it also apparently normally requires DNSSEC, so unless I can get my Unbound to lie about that (or Firefox to not care), I may be out of luck. I do wish I could tell Firefox that a resolver on localhost was trusted even without DoH, but I suspect that I can't.

(This does raise long term issues about encrypted SNI support for our users, but perhaps in the long term people will come up with answers. Hopefully ones that don't involve DNSSEC.)

FirefoxDNSOverHTTPSAndUs written at 23:37:31; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.