Failed to load resource: net::ERR_BLOCKED_BY_CLIENT - Uncaught ReferenceError: Ably is not defined

[mattheworiordan]

Browser extensions, as of 21 September 2019, as far as we know, do not block the Ably CDN or any of our endpoints by default.

However, a customer recently reported that Privacy Badger was blocking traffic for their browser. This is the first report and could be a local setting affecting only that user. However, we wanted to open this issue to track any further occurrences.

See https://github.com/ably/docs/issues/730 for the details on this issue.

Default Privacy Badger example showing Ably is not blocked:

Examples of Ably being blocked:

┆Issue is synchronized with this Jira Task by Unito

[dfdeagle47]

I've managed to reproduce this issue with Privacy Badger, but it doesn't happen each time.

If the website was accessed before Privacy Badger was turned on, the Local Storage contains the following key

ably-transport-preference: {"value":"web_socket"}

(at least in Chrome/Firefox).

If this key is set, Ably is not blocked: the only request that's sent is the websocket request GET wss://realtime.ably.io/?key=... (101 Switching Protocols) and everything is working fine, even if Privacy Badger is active.

On the other hand, if Privacy Badger was turned on before accessing the website (or just by deleting the Local Storage key), the following happens

• A request to GET https://rest.ably.io/comet/connect?key=... is sent, but blocked by Privacy Badger (net::ERR_BLOCKED_BY_CLIENT).
• This request is retried multiple times, but it always fails

Tested on

• Google Chrome Version 83.0.4103.116 (Official Build) (64-bit)
• Windows 10

So Privacy Badger is the culprit here. However, since the websocket request is not blocked by Privacy Badger, one potential workaround is to force the transport to web_socket here instead of using the baseTransportOrder here, provided that you don't need support other that websockets for instance.

[SimonWoolf]

one potential workaround is to force the transport to web_socket here

Thanks for investigating! We will consider what to do further wrt privacybadger. (we might might even want to consider making ably-js try websockets first and fall back to comet, rather than starting with comet and upgrading, cc @QuintinWillison ).

@dfdeagle47 to be clear, if you want to force websocket, you don't need to (and shouldn't) be editing connectionmanager in the ably-js source. You can just specify a transports property in the client options. E.g. new Ably.Realtime({ authUrl: "...", transports: ["web_socket"]}).

[dfdeagle47]

@dfdeagle47 to be clear, if you want to force websocket, you don't need to (and shouldn't) be editing connectionmanager in the ably-js source. You can just specify a transports property in the client options. E.g. new Ably.Realtime({ authUrl: "...", transports: ["web_socket"]}).

Yep that's exactly what we're considering. We're just checking to make sure we don't break real-time for our customers, so we'll make a quick check regarding browser usage on our app. Just wanted to refer to the lines where this is defined.

Thanks for the feedback and keep up the good work!

[QuintinWillison]

Regarding @SimonWoolf's:

we might might even want to consider making ably-js try websockets first and fall back to comet, rather than starting with comet and upgrading

That could be considered when we work on #605.

[QuintinWillison]

There's no work to be done under this issue and it has seen no activity for over two years.