Closed Bug 669792 Opened 13 years ago Closed 13 years ago

gov.uk is not considered to be a public suffix

Categories

(Core Graveyard :: Networking: Domain Lists, defect)

defect
Not set
normal

Tracking

(firefox6 .2-fixed, firefox7 fixed, firefox8 fixed, status1.9.2 .22-fixed)

VERIFIED FIXED
mozilla9
Tracking Status
firefox6 --- .2-fixed
firefox7 --- fixed
firefox8 --- fixed
status1.9.2 --- .22-fixed

People

(Reporter: alex, Assigned: gerv)

References

Details

(4 keywords, Whiteboard: [qa-])

Attachments

(2 files)

Bug 658965 updated the public suffix list such that gov.uk is no longer considered to be a public suffix.

This does not seem right to me. The gov.uk domain name acts like a public suffix (similar to co.uk or org.uk). It definitely doesn't act like a single registered domain name (as bl.uk and jet.uk do). It doesn't act like both (as nhs.uk and police.uk do).

The most notable effect is that if one visits a gov.uk site, like http://www.direct.gov.uk/, http://www.tfl.gov.uk/ or http://home.scotland.gov.uk/, only the "gov.uk" part gets highlighted in the location bar.

The relevant rule that makes gov.uk not a public suffix was added at the request of Nominet, so it has some authority behind it (even though Nominet do not manage gov.uk; the Central Office of Information do, with day-to-day operations delegated to JANET). However, I still think it should be reconsidered. I can't see the need for the Northern Ireland Executive and Transport for London to share cookies.
(In reply to comment #0)
> The relevant rule that makes gov.uk not a public suffix was added at the
> request of Nominet, so it has some authority behind it 

This is why I approved the change.

> (even though Nominet
> do not manage gov.uk; the Central Office of Information do, with day-to-day
> operations delegated to JANET). 

That's interesting. If it's so, I would take a counter-opinion from them and change it back, if they provided one.

> However, I still think it should be
> reconsidered. I can't see the need for the Northern Ireland Executive and
> Transport for London to share cookies.

However, this sort of consideration can't be a factor. The PSL is not defined by what we think should or shouldn't be the case, it's defined by what the domain owners tell us they want - taking into account all the factors, such as UI presentation, cookie sharing and whatever. We can't make that call for them.

Gerv
(In reply to comment #2)
> (In reply to comment #0)
> > (even though Nominet
> > do not manage gov.uk; the Central Office of Information do, with day-to-day
> > operations delegated to JANET). 
> 
> That's interesting. If it's so, I would take a counter-opinion from them and
> change it back, if they provided one.

It is so. From http://coi.gov.uk/guidance.php?page=192#section1a:

".gov.uk - the Digital Policy team at COI through the Naming and Approvals Committee is responsible for maintaining this guidance which acts as the policy governing the SLD. JANET(UK) administers the SLD on behalf of COI, providing the name submission, name modification, approval and registration systems."

See also: http://www.nic.uk/registrants/aboutdomainnames/sld/delegated/

Of course, neither the COI nor JANET have ever expressed an opinion on whether gov.uk is a public suffix or not (only Nominet have, though of course their decision may have been informed by either of the other two organisations).

> > However, I still think it should be
> > reconsidered. I can't see the need for the Northern Ireland Executive and
> > Transport for London to share cookies.
> 
> However, this sort of consideration can't be a factor. The PSL is not
> defined by what we think should or shouldn't be the case, it's defined by
> what the domain owners tell us they want - taking into account all the
> factors, such as UI presentation, cookie sharing and whatever. We can't make
> that call for them.

I see things have changed since bug 460776. While the maintainers of the list cannot make the call for a particular domain name, they do control the guidelines that the domain owners use to determine what is and what is not a public suffix.

I feel that in this case the guidelines have been wrongly interpreted and that the COI should be urged to re-examine their decision (or make a decision in the first instance, depending upon how much involvement they had with Nominet's initial request). It was never my intention to suggest that the public suffix list entry for gov.uk should be changed unilaterally; the relevant authorities must be involved.
(In reply to comment #3)
> I see things have changed since bug 460776.

Hmm. Perhaps. Although I think it's more reasonable to regard the government as a single entity than it is a collection of NHS trusts which have no shared organizational structure.

> I feel that in this case the guidelines have been wrongly interpreted and
> that the COI should be urged to re-examine their decision (or make a
> decision in the first instance, depending upon how much involvement they had
> with Nominet's initial request). It was never my intention to suggest that
> the public suffix list entry for gov.uk should be changed unilaterally; the
> relevant authorities must be involved.

I'm not sure I have time to chase this up, but would happily hear from whichever official representatives anyone else is able to make contact with.

Gerv
We use the public suffix list to provide a default assignment of new customer email addresses to existing accounts in our online shop. It usually works very well in this regard, but a rule change such as !gov.uk screws it up.

We know that such a use is not "officially supported" in any way, but it may be interesting to know that the PSL _is_ used in other ways and there are other effects of erroneous rules besides a wrong highlighting in the location bar.

Michael
I work for a London Borough council and came here to report this same "bug". I don't have an opinion on the complex issue of ownership and management of the ".gov.uk" suffix and whether or not it is a public suffix, but from an end user perspective, this *looks* like a bug, plain and simple. Our domain is walthamforest.gov.uk - not gov.uk. Internet Explorer has the same highlighting feature, and it recognises our domain as walthamforest.gov.uk.
If someone wants to contact the Nominet guy who originally submitted the change, or the COI, and ask them to request this to be changed, that would be fine :-) But as it stands, Nominet want it this way.

Gerv
Did this just land or did I just get it with an upgrade?  What a nightmare.  It is wrong and all sorts of stuff is broke with this.  Who do I have to contact to get this clarified?
(In reply to Ian Nartowicz from comment #9)
> Did this just land or did I just get it with an upgrade?  What a nightmare. 
> It is wrong and all sorts of stuff is broke with this.  Who do I have to
> contact to get this clarified?

It landed as part of Firefox 6.0, alas.

I've been sending an email to the COI everyday as soon as I was made aware of this.

naming@coi.gsi.gov.uk - which has not responded yet - and after some searching in whois, I'm now starting to email gsi@ogcbs.gsi.gov.uk as well. So I can find out who needs to make a decision on this.

(In reply to Gervase Markham [:gerv] from comment #4)
> (In reply to comment #3)
> > I see things have changed since bug 460776.
> 
> Hmm. Perhaps. Although I think it's more reasonable to regard the government
> as a single entity than it is a collection of NHS trusts which have no
> shared organizational structure.
> 
> > I feel that in this case the guidelines have been wrongly interpreted and
> > that the COI should be urged to re-examine their decision (or make a
> > decision in the first instance, depending upon how much involvement they had
> > with Nominet's initial request). It was never my intention to suggest that
> > the public suffix list entry for gov.uk should be changed unilaterally; the
> > relevant authorities must be involved.
> 
> I'm not sure I have time to chase this up, but would happily hear from
> whichever official representatives anyone else is able to make contact with.
> 
> Gerv


I've no idea why Nominet decided to make this change.

Unfortunately Bug 658965, does not include the email address of the originator.

Nor, indeed the actual email. 

Frankly it seems unusual that they were able to bypass utilising bugzilla themselves. It, the bug, and patch went via Gerv. 

Anand
Bug 658965 has the patch request that modified the entry.

In any regard, I am more interested in solving this than pointing fingers.

This seems like it would be solved if the entry were to be changed from !gov.uk to gov.uk in a request from Nominet.

I am reaching out to Nominet on this to have them submit a patch request.
Status: NEW → ASSIGNED
Here is another side-effect of this problem: the NoScript extension uses this to propose the scripting rules. This means that you must manually edit the "Whitelist" entries to allow a site to work - no one in their right minds would allow all *.gov.uk websites to run JavaScript etc. without limit.

For example, go to http://cityark.medway.gov.uk/ (I've intentionally picked an obscure site unless you happen to be a genealogist so that NoScript will require a rule to be configured) and NoScript will ask whether to allow the "site" gov.uk
Hello, 

We have spoken with JANET to ask what they would prefer to do regarding this matter.

If they confirm they would like a patch request submitted to reverse the change, Nominet will do this.
Doug: that's good to hear :-) Let us know if we can provide further technical input, advice or explanation.

Gerv
Hi Gerv,

JANET have confirmed that they would like a patch request submitted.

You should get one in the next few minutes.

-Doug
Here's the patch.

Gerv
Assignee: nobody → gerv
Attachment #555979 - Flags: review?(jothan)
Firefox 7 releases on 27th September; in order to get this in, we need to:

- get it reviewed
- check it in on the trunk
- let it bake for a day or two
- apply for approval to check in to branches
- check it in, in good time

Gerv
Gerv,

Can I just clarify:

This patch will not resolve the issue in Firefox 6 and the behaviour it currently exhibits for .gov.uk will remain always?
Doug: the new Mozilla rapid release process means that we release a new version every 6 weeks, and that Firefox 7 is the successor to Firefox 6 for all purposes - just as 6 was for 5, and 5 was for 4. There won't be a separate "security release" branch for Firefox 6, or anything like that, unless there's a security firedrill before September 27th.

However, Mozilla now does silent updates, which means that a few months after 7 is released, we hope very few people will be running 6.

Gerv
(In reply to Gervase Markham [:gerv] from comment #19)
> Doug: the new Mozilla rapid release process means that we release a new
> version every 6 weeks

That said, they - Mozilla - released 5.0.1 to fix a severe problem on a specific platform.

With things as they are, Firefox 6 allows all .gov.uk sites to impact each other.

Apart from the privacy implications of leaking cookies from one site to another there are security implications for users too.

I would hope that this lands fairly quickly (I assume you are able to do r=, gerv?) and land it on central (and then aurora, beta) and release?

If not you (since you landed the original patch, and this is just backing it out), who would do the review?

> separate "security release" branch for Firefox 6, or anything like that,
> unless there's a security firedrill before September 27th.

As I indicated above, I believe that this is a privacy and security firedrill.

And that a 6.0.1 is warranted.

Regards,
Anand
Anand: this is way, way below firedrill level. I think you misunderstand the implications.

If foo.gov.uk sets a cookies for foo.gov.uk, then it will be sent to foo.gov.uk - not to bar.gov.uk. bar.gov.uk cannot read those cookies.

The difference is that foo.gov.uk is currently _capable_ of setting cookies for all of gov.uk, and if they do, they will be sent to every gov.uk domain. (This would allow, for example, single signon across all of the UK government.) This will change when we check in this patch. But the fact that foo.gov.uk may do that does not mean that it actually does do it. It's certainly not recommended practice. And if it did, perhaps by accident, the results would most likely be harmless.

In some circumstances, it might be easier for a malicious UK government site to attack another UK government site - but that seems to me to be highly unlikely. Are you aware of any malicious sites in the .gov.uk domain?

I would note that the current situation is exactly what was the case before the PSL was introduced, and therefore what was the case for a decade or more as the web developed. It is not a firedrill-worthy thing.

Gerv
Hi, I am a Digital Policy Manager at COI and I manage the .gov.uk domain. I don't know how the Nominet request originated but I certainly don't want individual government websites to be able to set cookies for the whole of .gov.uk. Only the owner of .gov.uk (root) should be able to do that.

I understand that the list will be updated following a request from Nominet and approval by JANET, who operate the .gov.uk DNS on our behalf. My concern now is that this leaves us open until 27 September which is way past a reasonable timeframe for sorting this out.

Whilst I don't know of any malicious .gov.uk sites, I don't want to take any security or privacy risks. From a government perspective this problem erodes user trust that we have worked hard to build over the years. Therefore, can I request that this is firedrilled and fixed in a version 6.0.1 as soon as possible?
Comment on attachment 555979 [details] [diff] [review]
Patch v.1 from Nominet

I can confirm that this patch applies cleanly to mozilla-central, mozilla-aurora, mozilla-beta and mozilla-release. Making it apply to other branches, if any modifications are required, is left as an exercise for the reader ;-)

Gerv
Attachment #555979 - Flags: review?(jothan)
Attachment #555979 - Flags: approval-mozilla-release?
Attachment #555979 - Flags: approval-mozilla-beta?
Attachment #555979 - Flags: approval-mozilla-aurora?
Blocks: 658965
Keywords: regression
We'll want this fixed in 3.6.x too, right?
Yep.

Gerv
Attachment #555979 - Flags: approval-mozilla-beta?
Attachment #555979 - Flags: approval-mozilla-beta+
Attachment #555979 - Flags: approval-mozilla-aurora?
Attachment #555979 - Flags: approval-mozilla-aurora+
Attachment #555979 - Flags: approval-mozilla-release? → approval-mozilla-release+
If anyone has some testing hints on how to verify this fix in a black-box way for desktop and Fennec builds (particularly the ones w/o URL bar highlighting) it would be very useful. 

Right now, based on current knowledge, this bug is at risk for not being verified.
Yes, see comment [12] above - the NoScript add-on relies on this functionality, so when you go to an xxx.gov.uk website NoScript proposes to whitelist/blacklist "gov.uk" instead of the actual domain. Before release 6.0, NoScript picked out the domain correctly. If using NoScript is an acceptable method of testing, I can provide a list of xxx.gov.uk pages (for Record Offices) and some notes on what should/shouldn't happen.
It's better than nothing, thanks! If anyone else has other suggestions, we could use them. I'm fine with indirect methods like this.
(In reply to Geo Mealer [:geo] from comment #29)
> It's better than nothing, thanks! If anyone else has other suggestions, we
> could use them. I'm fine with indirect methods like this.

I've just tested using NoScript 2.1.2.6 with Firefox 6.01 under Windows XP by visiting an xxx.nhs.uk and an xxx.gov.uk web-site (for which I didn't have rules in NoScript), and NoScript only picked up the "gov.uk"/"nhs.uk" parts of the domain names.

If it helps (and someone can guide me on where to get/how to install the patched version under openSUSE 11.4), I can do some testing for you.
Charles,

That'd be great! I can't guide you on OpenSUSE, though, unfortunately, and I'm guessing our default Linux builds don't work for you. That's really what we'd want tested most urgently, since this is a pre-release test of the generated binaries.

If they do work for you, though, they'd be here:

ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/3.6.22-candidates/build2/
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/6.0.2-candidates/build2/
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/7.0b4-candidates/build2

Otherwise, if you're able to get builds on those branches you can test and don't mind doing so, we'd appreciate any help. Just post in the bug what you've done and what you saw, just like you did in c30.
(In reply to Geo Mealer [:geo] from comment #27)
> If anyone has some testing hints on how to verify this fix in a black-box
> way for desktop and Fennec builds (particularly the ones w/o URL bar
> highlighting) it would be very useful. 
> 
> Right now, based on current knowledge, this bug is at risk for not being
> verified.

Actually, you don't need NoScript to check this. Just go to a site like http://www.direct.gov.uk/ : in Firefox 6, you'll see that "gov.uk" is bold in the location bar. In a Nightly build, you'll see that "direct.gov.uk" is bold.

This has nothing to do with cookies ofcourse, but it follows the same rules.
Jo, excellent point! The challenges there are 3.6.22 and Fennec, neither of which have that behavior, unfortunately, and which are being qualified for this upcoming release.
I'm about to test Firefox 6.01 --> 6.02 under Windows XP, saving screen-shots in a LibreOffice document. (I couldn't install the 6.02 nightly-build under openSUSE 11.4 because of a dependency problem with libc.6.so and I don't yet know enough about gcc under Linux to solve this quickly.)

I'm not sure what to look for/test under Firefox 3.6.22 - I have the downloads ready to install - I last used 3.6 quite some time ago.
Successful test with Firefox 6.02 nightly build under Windows XP (compared with 6.01 which has problems).
Verified fixed by checking the location bar highlight and trying to add exceptions with NoScript in the following builds:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0a1) Gecko/20110904 Firefox/9.0a1

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0a2) Gecko/20110904 Firefox/8.0a2

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0) Gecko/20100101 Firefox/7.0 (build #2)

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20100101 Firefox/6.0.2

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.22) Gecko/20110902 Firefox/3.6.22

Not sure how to mark this bug as verified fixed for Firefox 6. Looks like there is no keyword for it around.
Status: RESOLVED → VERIFIED
Charles,

Thanks tons for your help, and for tipping us off on a good way to verify (and sorry I missed your c12 where you did it the first time. ;) ) We'd have been stuck here in QA without you.
(In reply to Geo Mealer [:geo] from comment #37)
> Charles,
> 
> Thanks tons for your help, and for tipping us off on a good way to verify
> (and sorry I missed your c12 where you did it the first time. ;) ) We'd have
> been stuck here in QA without you.

Is testing version 3.6.22 nightly build still outstanding? If yes, what should I look for when I compare it with version 3.6.21? (I have both sets of software ready to install side-by-side under Windows XP if this is required - testing should take about 10 minutes.)
Charles, I believe Henrik has already verified this on 3.6.22 per comment #36. Thanks for your help.
If you wish to test this on 1.9.2 without using an extension, an easy way to do so is to go to an https page:
https://www.brent.gov.uk/
If gov.uk is a domain name, "gov.uk" is written with white letters on a blue background. On the other hand, if the domain name is brent.gov.uk, the white letters read "brent.gov.uk".
QA no longer needs to track this.
Whiteboard: [qa-]
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.