Hacker News new | comments | show | ask | jobs | submit login
Chrome/macOS users in The Netherlands cannot visit google.com or google.nl
155 points by dutchbrit 268 days ago | hide | past | web | favorite | 69 comments
Users cannot visit google.com or google.nl in The Netherlands on Mac OSX & Chrome in the latest update, our whole company is experiencing this issue since this morning.

For those experiencing this issue, disable the following setting in chrome://flags/ :

Experimental QUIC protocol Mac, Windows, Linux, Chrome OS, Android Enable experimental QUIC protocol support. #enable-quic

Quicker link to the setting: chrome://flags/#enable-quic

I had the same problem this morning. Disabling QUIC solved it.

I experienced problems with several Google services from DK after upgrading Chrome this morning.

Disabling QIUC as parent links to unbroke things for me.

same here in Germany on windows this morning.. also had to disable QUIC.

Funnily I switched to Microsoft Edge for a short while, but have once again realized why its unusable. After about 1-2 minutes using it, the entire browser became unresponsive for about 60 seconds. Afterwards I couldnt press sign-in on YouTube because an invisible IFrame from the OneNote Web Clipper Extension was overlaying it. Nobody seems to be testing those either :)

No dedicated testing team is ever going to beat the developers dogfooding the tool daily. I wish I had access to metrics from stackoverflow et al, to see if Microsoft inhouse developers use Edge

I don't think they use Office either.

The only software where you can tell that they dogfood it is Visual Studio. Every change makes sense, is useful, user friendly and corresponds to problems I have met.

The other software that you would assume they dogfood but it doesn't show is Windows 10...

What? I'm sure they use Office at MS, it's used in every other non-sv office I've ever worked at.

The 2007 UI was a major step backward in term of productivity. Everyone I know who uses Office extensively still miss the 2003 UI.

Also there are lots of use cases that they never bothered fixing or improving, which show they don't really use it. Like non resizable windows in excel (eg function wizard). Linking a powerpoint deck to an excel model (no good solution now). No way to do placeholders within a textbox in powerpoint (like you can in word). VBA not having evolved in nearly 20 years. You don't see this sort of "I don't give a shit" attitude with Visual Studio.

I am sure someone in the finance or marketing department at Microsoft uses office and is as frustrated as every other power user. But the developers in the office team clearly do not use their own product. If there are still any dev in the office team. The only changes I see from version to version are purely cosmetic.

Pretty much everyone I know likes the Ribbon UI, you don't have to drill down in nearly as much menus. Granted, it only really started to get better after 2011, but its excellent now. There's a reason there's such a huge pressure on LibreOffice to come with some kind of interface paradigm that doesn't feel like it's from the 90s.

My main and continuing complaint with the Ribbon is that using it is slow. It encourages mouse usage and if you have to use a mouse for an operation, the operation is slow.

Not to mention that the action of the Ribbon is kind of seizure inducing as the entire thing is in constant change as various objects are selected thereby unhiding specialized menus.

I've taken to minimizing the entire Ribbon so I don't have to see it, requiring me to re-learn and re-memorize the multi-key keyboard shortcuts since they are different than the 2003 version.

If I could kill the Ribbon with fire, I would.

I don't think I've ever seen a person at MS that doesn't use at least one Office app. Outlook is pretty much a given.

Well, yeah. It's Windows 10, you're beta testing it for them.

Yup, Edge is finally more stable in 1703, but that's a week away ;)

That's what they always say about IE: it'll be good next patch or version.

And it's always true - the next version, not the current, will be good! just wait for it! again! ;-)

Direct fiber connection to Level 3 (Columbus, Ohio) here at work. Had to disable QUIC as I am getting the same errors as well when trying to access Google. Using local DNS, not sure what upstream DNS we are using though.

It's happening in Minneapolis on Comcast as well. Requests will hang for a while and eventually fail with "ERR_QUIC_PROTOCOL_ERROR".

Regardless of this issue, the QUIC protocol is still fascination and deserves some attention: https://ma.ttias.be/googles-quic-protocol-moving-web-tcp-udp...

This looks like an implementation error, either client or server-side.

Had the same issue. Restart didn't work and Safari was working fine.

For me what worked was removing Google's DNS server from my network settings and voila; it worked.

Is there a more detailed write-up about what exactly is causing the problem?

If there is, please submit it to HN and let's get an accurate summary of what's happening, i.e. 'Some Dutch and German providers break QUIC'.

Map overview shows that Berlin might be experiencing the same issue: http://allestoringen.be/problemen/google/kaart/

Indeed. I had this problem yesterday.

I've had problems with QUIC in various networks (corp, home) mainly in Singapore for more than a year. Until the point I disable QUIC as one of the first steps when I encounter GMail connectivity problems from Chrome/Chromium on a fresh machine.

I find it odd that QUIC is enabled by default when it apparently has poor fallback capabilities to "non-QUIC" mode.

The internet is in a pretty sad state if a simple UDP stream isn't possible any more because of interfering middleboxes. It's not like QUIC is a new IP protocol. One of the reasons for lack of good fallback is probably an expectation that basic IP operations are functional.

I'm guessing NAT has a lot to do with UDP issues on the interwebz.

I am on Ubuntu and have exactly the same issue for google.nl, youtube.com and google.com.

So it is not only on Mac OS X

Edit: And it started working again :)

Any explaination about this?

QUIC is quite interesting https://en.wikipedia.org/wiki/QUIC

So.. Dutch ISPs - or someone else along the route - interfering with UDP traffic?

I suspect they are throttling UDP traffic on "non-web" ports, traffic might look like torrent encrypted stream :). Anyway you can test whats going on with https://github.com/lucas-clemente/quic-go

This is probably not the case, as traffic shaping is illegal in The Netherlands.

In a world where every router has the capability to do things which are illegal in various countries, do you think that Netherlands ISPs always obey the law? In the US, convention center operators keep on getting busted for sending deauth packets to "rogue" WiFi access points, i.e. those brought in by conference attendees and exhibitors.

The Dutch internet market is not really comparable to the US market. We do not have data limits for cable/dsl/fiber and I've never had issues downloading torrents at full speed, even before the net neutrality law.

I had issues with VPN and some dutch ISPs, so Im not sure about that.

They wouldn't be the first ISP to break the law, and they most certainly wouldn't be the last.

Is this the reason googleapis is having trouble? Maps and fonts are really slow for me today.

Yes, we experienced the same issue with our clients. Disabling QUIC solves this issue.

Dutch here. I can confirm the issue. Problem also appears on Chromebook and Linux. Solution as proposed in an other comment in thread solves the problem.

Ah so that's what was going on. The issue insofar I could perceive it is fixed now though. All googly sites are up again.

I happen to be in the Netherlands today and have had no problem using Google on OS X & Chrome

I have started experimenting the same last year on our Android devices at a customer network, thanks to QUIC we weren't able to use their network authentication any longer.

For some reason, even disabling it did not help.

Our workaround, was to use the old system browser for authentication and then switch to using chrome after being authenticated.

El Capitan latest public beta, with Version 58.0.3029.19 beta (64-bit) no problems.

This is happening for me in the US East Coast and disabling QUIC fixed the issue.

Danish google down as well..

Google.dk works fine from my newly updated Chrome on macOS.

Same for me. Youtube as well.

I can confirm this

google in luxembourg too :)

Anyone got a packet capture and can tell what's the problem?

Same here in Belgium :-(

Having the same issue (behind a company network) in Germany.

We had no issues today - but we are IPv6

Also those of you who have disabled QUIC - you should enable it again. It has a serious benefit for most of Google services.

Works for me...

Confirm issue here as well

ok mom

The title is misleading, Google has not broken anything, Dutch providers have. I hope Google will do nothing, and the providers will be pressured into fixing their shitty hardware.

I work a Belgian hosting provider, directly uplinked to our datacenter via Cogent/TINET. The same happened here.

There's no hardware cause, it appears to be a minor chrome update combined with a QUIC server-side update (unconfirmed) that caused issues. As soon as Chrome auto-updates to the next minor release, things appear better (but not fully fixed).

It's entirely in the browser <-> Google server-side, ISPs have nothing to do with this.

Alright, thanks, and sorry for implicating you. I guess it's the history of ISP's messing with transport layer protocols that got me finger pointing.

Can you provide a source? If this is the case that's quite a serious fault, but it seems unlikely that multiple independent providers would simultaneously do this.

The title isn't misleading, it's describing exactly what the parent was experiencing, "Chrome/macOS users in The Netherlands cannot visit google.com or google.nl". There was no assignment of blame to Google or anyone else.

> Google has not broken anything, Dutch providers have.

Based on what evidence, exactly? Aside from a grand scheme of evil world domination by Dutch ISPs, what exactly would their motive be for a coordinated action like this one which seems to only hurt Google properties and only over QUIC? Aside from a court order or responding to some kind of attack, I can't find a single compelling reason for ISPs to do this (and the fact that it's illegal by law and the fines are pretty big) unless they have a desire to flood their help desks.

could you explain with more details. I'm curious what is all about.

fuc u nunbs jajajdjajdja

good time to switch to startpage.com....

No problems here. Must be one of the shitty providers like ziggo or kpn

I'm going to hijack this thread to describe something weird that's happened to me yesterday w/ Google: just connected on my usual BT (UK) wifi, and when I opened google.com, Safari complained about an invalid SSL certificate: it was self-signed, with expiration in 2111. After a dozen refreshes, everything started to work, with the correct certificate.

Anybody seen anything like that? Is it possible that a corrupted packet could appear as a self-signed certificate? Did some MITM screw up?

Yes, your BT router MITMs from time to time just because :)

Every time you connect a new device, you get a start page with the "welcome to your BT broadband" or whatever stupid thing they want. This screwed me for a few hours when I bought an Xbox One and most of the images wouldn't load. Had to open the browser, acknowledge the f*cking page and go on with my life.

Looking for a new router now...

You should post the certificate details here. Issuer, fingerprint, etc.

I was so weirded out I totally forgot. How dumb of me. I'll just ascribe it to a glitch in the matrix.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact