timeless' review and my responses so far

Here's my responses. I've marked 6 of them as items I want to go through 
"first" during our meeting this week. If I get time I'll mark the second 
level batch before the meeting. If you do nothing else, I would appreciate 
you each going to these 6 items below, reading them, and posting any 
reactions. 

If folks have other items in any of the feedback we've received so far 
that they want to move towards the top of the agenda, just let me know.


Search for: 
**1**
**2**
**3**
**4**
**5**
**6**

My responses: 

> http://www.w3.org/TR/2010/WD-wsc-ui-20100309/
> 4.2.1 Common User Interface elements
> ...
> > Examples of... include the... "Security Properties" dialogue...
> 
> You use "dialogue" and "dialog" inconsistently, I'd suggest/request
> that you only use one.

editorial change - I support. 

> > We occasionally use the term [Definition: chrome] to refer to the 
> representation through which the user interacts with the user agent 
> itself, as distinct from the web content accessed.
> 
> "web content accessed" is awkward, "accessed web content" sounds better 
to me.

editorial change - I support.

> > This includes primary and secondary user interface.
> 
> i think you need 'both' or 'interfaces'

Or both. I support the change to:
This includes both primary and secondary user interfaces.

> > A trust anchor represents an authoritative entity represented via 
> a public key and associated data.
> 
> 'via' here seems odd, i think 'by' is more appropriate.

I support; am I missing any nuances?

> > by enforcing the constraints expressed in the associated data.
> 
> i think either "in their" or "by their"

The full sentence is: 
Relying parties use trust anchors to determine if digitally signed 
information objects are valid by verifying digital signatures using the 
trust anchor's public key and by enforcing the constraints expressed in 
the associated data. 

I believe the associated data is associated with the trust anchors and in 
them, so support "in their". 

> > Note that trust anchor update is therefore often handled as part 
> of user agent or operating system software updates.
> 
> "trust anchor updates" or "updating trust anchors"

I support the latter editorial change. 


> > to a agent's store
> 
> an agent's

I support. 

> > of trust roots
> 
> "trust roots" is used 3 times but not defined. I think you should use
> some other defined term.

Well, it's the root in a trust chain; a chain of certificates leading back 
to a root that is a trusted certificate. "trust root" seems to have plenty 
of hits on the web. If there's no better term, we can define it here. "A 
certificate trusted by the user agent which may be used to determine trust 
in a chain of certificates linked to it through signatures"? 

> > that certificate is not considered accepted interactively.
> 
> "interactively accepted" (this is a defined term)

Support the change.

> 5.1.2 Augmented Assurance Certificates
> 
> > Some trust anchors adhere to documented broadly accepted practices
> 
> the lack of punctuation between documented and practices troubles me.

I am notoriously bad at commas. My Strunk and White says:
In a series of three or more terms with a single conjunction, use a comma 
after each term except the last. 
We've only got two terms. But three words.
The guidance on dashes doesn't seem to apply either. 
I can suggest no useful change. 

> > (e.g. [EVTLSCERT]) that involve some level of guarantee that 
certificates
> 
> i think you want 'which' instead of 'that'

Strunk and White agrees. I support. 


> > chaining up to those roots embody augmented assurance
> 
> 'augmented assurance' is not a defined term, and in this context it's
> missing an indication of what it's assuring.

The assurance that is augmented is, I believe, "a statement intended to 
inspire confidence". The documented processes are meant to augment those 
assurances. If I'm unpacking it properly, then the natural language might 
better read "embodying augmented assurances". Other thoughts? 

> > and can therefore be treated more favorably in terms of the 
> primary security indicators.
> 
> note: you're spelling favorably according to en-US, as such, you
> should spell dialog according to en-US.

I support. 

> > an augmented assurance specification supported by the user agent.
> 
> I don't understand this. I think you're trying to say that it
> satisfies some EV specification, but for some reason it doesn't read
> well.

Satisfying an EV spec is one way (and the one way currently implemented by 
the participating user agents) of doing that, so even with the difficult 
reading it does seem to be getting the point across. Better phrasings? 

> > The certificate chain for such a certificate MUST be validated up 
> to a trust root that is recognized as augmented assurance qualified 
> by the user agent.]
> 
> What happens If it fails to validate up to such a trust root? This
> really should have been incorporated into your defining sentence --
> not added as a secondary sentence that's just included in your
> brackets.

Then it's not considered an augmented assurance certificate. It's a two 
sentence definition encased in []'s. I believe it's two sentences instead 
of one to try to increase clarity. I don't think it's a good idea to try 
to squish it into one sentence if it'll make it less clear. Other 
thoughts? 


> > This specification does not define what an "augmented assurance 
> qualified trust root" is,
> 
> that's true, but it doesn't use that quoted phrase anywhere else at
> all, which means it's a useless statement. Your document should be
> self consistent and is not.

We have a number of sentences that do talk about "augmented assurance 
qualified" "trust roots" (sometimes in that order and sometimes with that 
order switched). And the quoted phrase is used elsewhere (just not with 
quotes). Would italics be better in this sentence? 

> > except to note that this designation is made by user agents 
> through an out of band mechanism consistent with the relevant 
> underlying augmented assurance specification.
> 
> As written you're requiring that there be precisely one such
> specification ('the...specification'). That seems problematic as it
> essentially endorses EV as the one and only.

The word "relevant" is in the phrase for just that reason; to allow for 
multiples in the universe, but one being used. So we are not endorsing one 
and only one specification. 

> > Implementations MUST NOT enable users to designate trust roots as 
> augmented assurance qualified as part of a different interaction.
> 
> "different interaction" is odd, i'd suggest "unrelated interaction" or
> rewriting the sentence entirely.
> 
> Implementations MUST only allow users to designate trust roots as
> augmented assurance qualified via direct interaction for that purpose.

I do think the rephrasing captures the intention. If we can accept this 
level of rephrasing without any sort of process reset, I think it's a good 
clarification. 

> > In both situations, use of TLS provides confidentiality protection
> services against passive attackers.
> 
> This is an objectionable overstatement. "In both situations, TLS is
> used in an attempt to provide confidentiality protection services
> against passive attackers."

I don't find the current phrasing particularly absolutist, which I'm 
guessing is the concern. Am I missing something? TLS surely does provide 
(some) confidentiality protection services. 

> > Simply put, if a Web site consistently presents the same self-
> signed certificate ... then this can be strong evidence that 
> protection against an active attacker has been achieved as well.
> 
> Unless of course the attacker has taken over the remote server. Please
> qualify the attacker as not having attained local access/control on
> the machine.

The phrase "strong evidence" allows for situations where the evidence is 
not absolute. Attempts to enumerate those cases will always fall short. I 
don't think it's a good idea to provide a partial list. Other thoughts? 

> > Conversely, a change of certificates for the same site can be 
> evidence that a man in the middle attack occurs -- or it can be a 
> symptom that the legitimate site has changed to a different certificate.
> 
> "symptom" is a really odd word, "or it can merely indicate"

I'm ok either way, so don't have a problem with this change, or the 
simpler substitution of "an indication" for "a symptom". Anyone else? 


**1**
> > [Definition: A Web page is called TLS-secured if the top-level 
> resource and all other resources that can affect or control the 
> page's content and presentation have been retrieved through strongly
> TLS protected HTTP transactions. ]
> 
> If the user adds content, this isn't content that was retrieved via
> TLS and it does affect the page's content....
> This would also apply to HTML5 storage concepts.

I don't understand this point. In web applications I am familiar with, 
user content served up in the web application is served up (retrieved 
through) via TLS along with the rest of the web application. Anyone else 
understand this one? 

> > This definition implies that inline images, stylesheets, script 
> content, and frame content for a secure page need to be retrieved 
> through strongly TLS protected HTTP transactions in order for the 
> overall page to be considered TLS-secured.
> 
> You should probably mention plugins....

Plugins are retrieved? I didn't think that's how they worked. 

> > strongly TLS-protected interactions.
> 
> you've overloaded 'interactions' to include both user-content
> interaction and client-server, this is unfortunate.

I don't disagree. Anyone want to suggest a change? 

> > and the certificate chain presented was not pinned to the 
> destination at hand
> 
> I'd suggest avoiding colloquialisms such as "at hand".

Does the removal of the three "at hand"s remove any information? I don't 
think it does.


> > unless it is attested to.
> 
> ending a sentence with a preposition should be considered poor form
> for a technical document.

"without attestation"? 

> > certificates... are... revoked,... Danger Messages... MUST be used.
> > certificates... are... expired,... Danger Messages... MUST be used.
> 
> While I would generally agree, I think that this policy results in
> more harm than good. I know my employer can't get this right, and for
> Mozilla, I worked very hard to improve the latter without promoting it
> to be a DANGER message. Often the cause with our product is user error
> (incorrectly configured system clock).

The revocation is not (I hope) a system clock sort of thing.
I know we've discussed the expiration one a lot, and the wg believes the 
policy results in more good than harm. As do the implementers. 

> > On the other hand, a user agent such as a smart phone, individual 
> entertainment screen in an airplane seat back, or TV set which has a
> usage mode that makes minimal (but visible) chrome elements 
> available does need to preserve security indicators in such a mode.
> 
> This would make MicroB on the n900 non conformant. It has minimal
> chrome but does not show security indicators in the primary user
> interface. I think this decision was actually the correct one.

I think we all understand that implementations can choose to not be 
conformant with a specification for good reasons. I don't know enough 
about MicroB to know what the reasons are. 

> *****
> I've been instructed to be careful about my wording, so I'd request
> time to get back to you with a more appropriately phrased statement
> regarding this item.
> *****

I've sent a reply to timeless and the public comment list asking that he 
honor the March 31 deadline. 

> > User agents with a visual user interface MUST show the Identity 
> Signal in a consistent visual position. Web Content MUST NOT obscure
> security user interface, 7.4.1 Obscuring or disabling Security User 
> Interfaces.
> 
> Does not showing it at all satisfy this requirement? MicroB in the
> n900 shows security information in an animated transient manner.

I don't think that not showing it at all satisfies are requirement to show 
it in a consistent visual position. Anyone disagree? Anyone know of any 
pointers to what MicroB does? Perhaps a video or some such? 

> > During... The identity signal MUST include human-readable information
> 
> This seems to indicate that a simple lock icon (or any other form of
> pure iconography) is insufficient. In some browsers with space
> constraints, it's likely that all you'd see is a favicon with a
> special background color. Additional information is available in
> secondary ui, but I believe "identity signal" was used to mean
> primary.


If the user agent supports some form of AA, then it must do that. I 
believe (but have not thoroughly double checked) that a complying user 
agent can not support any form of AA at all. Does anyone disagree with 
that? 

> > an validated
> 
> 'a'

I support. 

> > If the identity signal does not include ... information ... then 
> it MUST include an applicable DNS name
> 
> Otherwise?

Otherwise the user agent does not conform (am I missing something on this 
one?). 


> > User agents MAY shorten such a DNS name by displaying only a suffix.
> 
> So I can shorten
> 
thisiswaytoolongtofitonanyreasonablecomputerscreenbecauseiintentionallywroteitjustlikethat.co.uk
> to "co.uk"? great, thanks.

I believe so. That's why it's a MAY. 

> >      Subject logotypes [RFC3709] derived from certificates MUST 
> NOT be rendered, unless the certificate used is an augmented 
> assurance certificate.
> 
> Since most vendors don't support logotypes, I'm not going to cry (I
> did try adding logotype support somewhere once about 5 years ago
> iirc).
> 
> > Note that this behavior does not apply when self-signed 
> certificates or certificate chains that chain up to an untrusted 
> root certificate are used.
> 
> What does "does not apply" mean?

We're restating that these requirements that apply to validated 
certificates do not apply to self-signed certificates or certificate 
chains that chain up to an untrusted root certificate. 

> > site identity information exceeding those
> 
> exceeding? perhaps "beyond"? those => that which is

I agree; "beyond that which is" reads better. I support. 

> > During interactions with mixed content, user agents MUST NOT 
> render any logotypes [RFC3709] derived from certificates.
> 
> Given how rare logotype support is, I don't think it's particularly
> appropriate to regulate its use. Let the market play out. So far, it
> played out by killing them.

The logotype items in the specification are consistent with both best 
practice and with lack of support, must like the AA items. 

> > Web user agents provide additional security context information as
> described in this section.
> 
> Odd statement. Web user agents provide additional security context
> information as they please. If you want to make a request with a
> SHOULD or MAY, then do so, but don't write a declaration of fact that
> oversteps your bounds.

This seems more accurate: 
Additional security context provided by some web user agents is described 
in this section.


> >   3. Whether the user has visited the site in the past.
> 
> Useragents can't tell a user if he's used another agent or another
> device to visit a site. Please don't ask them to do the impossible.

We're not. And the draft implementation reports indicate that Chrome and 
Firefox do it. Perhaps the addition of "with this user agent" would help? 
Although it could also be argued to be redundant. 

**2**
> > The [Definition: TLS indicator] MUST be part of primary user 
> interface during usage modes which entail the presence of signaling 
> to the user beyond only presenting page content.
> 
> i still object

My take is that this item has lost context, which it may regain if 
timeless adds more information within the review period. Does anyone see 
something I'm missing? 


> > Web content MUST NOT obscure security interface, 7.4.1 Obscuring 
> or disabling Security User Interfaces.
> 
> this isn't really a sentence.

The sentence is "Web content MUST NOT obscure security interface" and the 
rest is a reference. Any suggestions on cleanup on this one? 

> > Primary user interface error messages MUST NOT be phrased solely 
> in terms of art.
> 
> the term 'art' here is odd and unhelpful.

The sentence after that one is meant to provide additional helpfulness. 
Anyone have any other suggestions? 

> > They SHOULD NOT refer the user to enter the destination site that 
> caused the error,
> 
> I'd suggest "tell" instead of "refer". "refer" would be used if the
> object is a person not an action.

I support this. 

**3**
> > user agents SHOULD enable the user to easily return to the user 
> agent state prior to initiation of the last user interaction that 
> led to the error signal.
> 
> If a web page involves submitting a form (POST) to a broken site, or
> if the previous page the user was on is the result of a POST, then
> trying to let the user return to the previous state is hard, risky,
> dangerous, or perhaps simply impossible. SHOULD is perhaps too strong
> given this. It's also possible that the last "user" action happened
> long before the web page randomly contorted itself and then redirected
> to the broke site, in which case "returning" to the state where the
> user last interacted is impossible (javascript doesn't support
> rollblack...).

All three draft implementation reports indicate that the user agents 
conform. 

> > For advanced users ... have an option for advanced users
> 
> Please don't repeat yourself.

I support removing the second "for advanced users".

> > to request a detailed description of the condition that caused the
> interaction to occur.
> 
> this is odd the "condition"-"interaction" is "you clicked on a link to
> a bad server", do you want a detailed explanation for the user showing
> exactly how they managed to click on a link to a bad server? I
> wouldn't call an error state an "interaction" -- it seems like  you
> did here.

For consistency, the best I can come up with is calling "the interaction" 
"the error interaction". 

> > The error interactions characterized in this section typically 
> involve communication of security context information.
> 
> "characterized" is strange....

"discussed"? 

> > Warning / Caution messages MUST interrupt the user's current task,
> such that the user must acknowledge the message.
> 
> there's a second "must" in this sentence which is not in RFC form.
> There's also a huge risk of desensitizing the user if this is done
> wrong. There is already evidence that users ignore these messages and
> blame browsers for interrupting their task.

change second "must" to "have to"? 

Warning fatigue, discussed in 8.5. 

> > distinct options how to proceed
> 
> this sounds wrong grammatically

"distinct options for how to proceed"? 

> > their meanings can be understood
> 
> I find the plural "meanings" awkward, perhaps you can avoid using the
> plural form?

Nothing comes to my mind. Anyone else? 

**4**
> > Danger Messages are intended for situations when there is a 
> positively identified danger to the user (i.e., not merely a risk).
> 
> This is odd, if a site's certificate expired yesterday, how is that a
> positively identified danger? It's an indication of a careless site
> admin (of which my employer is a good example, but so are most sites).

I would say because the site is asserting an identity that it does not 
actually hold. Other thoughts? 

> [http://www-10.lotus.com/ldd/nflsblog.nsf/dx/RecertifyingIDs]  is
> vaguely interesting.
> http://venafiblog.com/?p=178 is also amusing.
> http://venafiblog.com/?p=24 is depressing.
> 
> > The interactions communicating these messages MUST be designed 
> such that the user's task is interrupted.
> 
> Yeah, I'd like to congratulate JAL, they sure interrupted the task of
> all those people trying to fly all over the world.
> 
> > These interactions MUST be presented in a way that makes it 
> impossible for the user go to or interact with the destination web 
> site that caused the danger situation to occur, without first 
> explicitly interacting with the Danger Message.
> 
> I'm unsure that this truly helps the check-in agents. I understand
> that there's a huge danger and that obviously no one should ever fly
> JAL again, but....
> 
> > For visual user agents, agent chrome SHOULD always be present to 
> signal security context information.
> 
> This SHOULD is annoying for minimal chrome agents. A user of a mobile
> browser doesn't care about the fact that many of the pages have or
> don't have valid certificates. Sadly, it makes more sense for such
> agents to enable the user to ask the browser "is it safe for me to
> enter information" at the time the user enters information instead of
> when the user visits pages. It might actually make sense in some case
> for a browser to allow interaction with sites but refuse to allow
> downloads. I'm not saying that I want my browser to do this, but I'm
> wondering if perhaps a browser should be allowed to make this choice.
> 
> Note that desktop browsers such as IE now show security information
> when presenting downloads, so the idea of a minimal user agent doing
> the same isn't so far fetched.
> 
> Asking MicroB to add extra chrome makes it harder for it to compete
> with Firefox for Mobile which has 0 visible chrome while browsing. It
> would essentially force us to change to a system where our chrome DOES
> NOT constitute a PRIMARY USER INTERFACE and is instead some strange
> "SECONDARY INTERFACE".

I'm not catching on to why the spec would apply to one but not the other. 
It might make sense for a category of user agents to target the basic 
conformance but not the advanced conformance (or only a subset of the 
advanced conformance). 

**5**
> > 7.2 Do not mix content and security indicators
> 
> If an iframe contains a link to a site with an expired certificate and
> the user clicks the link, do you want the user agent to destroy the
> outer browsing context just to show the security indicator alone? This
> does not seem ideal

I can't figure out how this scenario is related to this section. Can 
anyone else? 

> > attentive user might look for.
> 
> please avoid ending sentences with prepositions

Anyone have a rewording? 

> > Web User Agents MUST NOT communicate trust information using user 
> interface elements which can be mimicked within chrome under the 
> control of web content.
> 
> MicroB supports full screen flash, in such a mode, the flash content
> can mimic all user interface elements, and demanding that full screen
> flash not work is a violation of our ability to deliver Flash. There's
> a distinction in that if the user wants security information there are
> certain keys the user can press which ensures trusted content, similar
> to the use of CONTROL-ALT-DELETE on Windows.

I could have sworn we had a flash discussion. Joe? Also, this falls under 
the "only presenting page content" mode that is explicitly called out 
elsewhere (anyone know this MicroB mode well enough to verify that?). 

> > User interfaces used to inform users about security critical 
> events or to solicit input
> > MUST employ techniques that prevent immediate dismissal of the 
> user interface,
> > e.g., by using a temporarily disabled "OK" button on user 
> interfaces that make such
> > an interaction paradigm available.
> 
> Every time we force users to use such interfaces, they complain very 
loudly.
> 
> https://bugs.maemo.org/show_bug.cgi?id=6436#c0 (there are about 5 or
> perhaps even 10 complaints about our UI for this case).
> 
> Note that we don't make it easy for users to dismiss the error state,
> and as a result they complain. I'm not saying our UI or UE is
> wonderful, but we are compliant with your MUST and the result is
> annoyed users.

I followed the link and the bug report didn't seem to be on this item. I 
don't mean to dismiss this feedback; I just point it out in case I missed 
something. 

> > interactions caused by Web content MUST NOT be granted control of 
> the user agent's interaction.
> 
> the word 'interactions' here is unfortunate, can you try to use some
> other words or phrases? In this case, merely dropping "interactions
> caused by" would probably be the best course of action.

That seems ok to me. Other folks? 

**6**
> > A Web User Agent SHOULD NOT display a modal security dialog 
> related to a web page which does not currently have focus.
> 
> Showing a modal dialog doesn't necessarily mean showing it to the
> user. If I have two windows and the user is browsing in one, and the
> other redirects to a page which triggers a window modal dialog, which
> the user does not see, then i have shown a modal security dialog for a
> web page that does not have focus, but as long as the dialog does not
> get focus, because it is merely window modal and not application
> modal, it might not be a problem.
> 
> Please be careful not to overstep, and don't rely on SHOULD to protect
> you from overstepping.

But modal dialogs must be the next thing the user interacts with. And they 
can't see it. That does not seem like a case that it would be important to 
support. It actually sounds like a bug. What am I missing? 

> > User agents MUST restrict window sizing and moving operations 
> consistent with 7.1 Keep Security Chrome Visible.
> 
> This doesn't read as a sentence. Perhaps "keeping"

The final clause is a reference to a section title. 

> > User agents MUST NOT allow web content to open new windows with 
> the agent's security UI hidden.
> 
> MicroB has a user preference for whether windows open full screen or
> with chrome, in neither case do we show security UI, we don't
> specifically allow the web page to control whether it is opened in
> full screen or not, but when it asks for a page to be opened, the
> security UI is hidden.
> 
> Your requirement here is burdensome and unreasonable. I understand
> your intent, but you're going to cause more harm than good by
> structuring it this way.
> 
> > Allowing this operation facilitates picture-in-picture attacks
> 
> Typically does. For MicroB it does not, because of the way the ui
> actually works. To trigger menus, you either use:
> 1. Power Key (not trappable by web content)
> 2. Ctrl-Backspace (not trappable by web content)
> 3. Camera cover / button (not trappable by web content)
> 4. a full screen indicator which appears whenever you interact with a
> web page while in full screen (either by tapping the screen, or by
> pressing a key -- the latter sadly annoys customers, there's a bug
> reference for that if you want it).
> 5. if not in full screen, pressing the menu area, which would do
> something that would violate 4 if the page was trying to trick the
> user.

Full screen mode initiated by the user is allowed by the spec. 

> > Web user agents MUST NOT expose programming interfaces which 
> permit installation of software without a user intervention.
> 
> This is a good requirement, sadly we have a management requirement to
> the contrary, and while I personally hate it, they've overruled me,
> and I don't think that your requirement will help anyone in the face
> of management pressure. What it means is that management will ask
> about the spec, we'll say "we can't satisfy it because of _this
> point_", and they'll say, "ok, so ignore the whole spec". The user is
> then offered a browser which isn't compliant with this specification.
> How does that help the user?

I definitely sympathize. It turns out to be very hard in this area to hit 
the right level of protection and realism. As you yourself have pointed 
out elsewhere. 

> > User agents MUST inform the user and request consent when the user
> agent is attempting to install software outside of the agent 
> environment as a result of web content. The interaction used MUST 
> follow the requirements in 6.4.2 Warning/Caution Messages .
> 
> You have a random space before your period.

I support removing the random space.

> Again, your requirements here while noble are likely to result in us
> ignoring you. We already have complaints about how invasive our
> downloading/saving/opening story is (I believe I can find bug
> references for this too).

I don't doubt it. 

> > Web user agents MUST NOT permit Web content to add URIs to the 
> user's bookmark collection that do not match the URI of the page 
> that the user currently interacts with.
> 
> This is annoying. If I use http://delicious.com/ or Google to save my
> bookmarks as a set, why shouldn't I allow them to provide a way to add
> pages I'm not currently at? Obviously I'd have to design it so that
> the user can review the content in some safe manner, but....
> 
> A competitor (Firefox for Mobile) offers an API, "Weave", which allows
> a web server (weave) to add URIs to the user's bookmark collection. We
> have already received customer requests demanding this feature. In
> reality, Weave doesn't quite act as web content, however, I don't
> think users care about the distinction.

I believe Tyler had provided the attack pointer for this one. Anyone have 
it handy? 

> 7.4.4 Pop-up Window APIs
> 
> > This can be employed in interaction flooding attacks.
> 
> Google for "interaction flooding attacks" shows only 8 hits, most of
> which relating to your document. I'd request that you consider using
> industry terminology instead of inventing grammatically poor terms of
> your own.

Does anyone know what the industry terminology is? Is there industry 
terminology? 


> > 5.4.1 TLS errors leads
> 
> lead

It's a reference title; the verb refers to the section. 

> > to an additional
> 
> drop 'an'

See above. 

> > the user's flow of interaction,
> 
> "flow of interaction" is oddly enough an extant expression, however
> none of the Google top 10 hits seem to be contextual matches. I'd
> suggest you avoid it.

I'm not quite sure why nor what to replace it with. 

> > behaviour
> 
> this is en-GB which is inconsistent with favorably en-US earlier.

I support en-US spelling. 

> > require user agents to treat
> 
> drop "to"
> 

I support.