Hosts: apresolve.spotify.com is necessary for the Spotify web player to function, spclient.wg.spotify.com is necessary for the Spotify app to function.

Created on 18 Feb 2018  路  9Comments  路  Source: StevenBlack/hosts

I just reported this upstream at CHEF-KOCH/Spotify-Ad-free#2, but given that list is marked here as being updated "occasionally" I felt an issue here might also be worthwhile, since otherwise it means Spotify's web player will remain broken until whenever it gets updated over there and then merged over here.

EDIT: Appears to have been added in adc8004 as a result of #492.

Most helpful comment

The point is Steven @StevenBlack choose to include a list or not but on the other side, he does not touch any list. It's the responsibility of the upstream source maintainer to make the changes. Which means that you (or @StevenBlack ? :thinking: ) should add it to whitelist and that's all unless the maintainer of the upstream source decides to remove it.

So to resume there is two case:

  1. The upstream source maintainer removes the domain/IP

    • Steven updates this repo and that's it.

  2. The upstream source maintainer does not want to remove the domain/IP for his own and (always) valid reason (for example https://github.com/StevenBlack/hosts/issues/505#issuecomment-366695531)

    • You (or Steven) add the domain/IP to the whitelist list and you only have to update your copy with the script.

All 9 comments

Hello! Thank you for opening your first issue in this repo. It鈥檚 people like you who make these host files better!

Bonus: #153 and #270 are back in effect, as of the same adc8004 and also coming from the parent Spotify-Ad-free list. This marks the third time the same domain, spclient.wg.spotify.com has been added to the hosts list, breaking the Spotify app for mobile users.

Sorry but no. #153 && #270 applies to the old data (Cf: https://github.com/FadeMind/hosts.extras/blob/61f798c860e463b540889aed6a6df5066e85e5df/SpotifyAds/update.json) which was maintained by @FadeMind which is not the case here (cf: https://github.com/FadeMind/hosts.extras/blob/e5702b4e40edd63f4c5a53322e6cd3fe65862230/Spotify-Ad-free/update.json)

You're correct that the upstream source for the blocked domain is different to the one from those old issues, but I'm not sure what point you're making.

My comment above about spclient.wg.spotify.com "also coming from" Spotify-Ad-free refers to the fact that apresolve.spotify.com in the initial issue post is coming from that list.

And it's the third time this domain has been blocked by StevenBlack/hosts, albeit it's come from at least two different upstream sources.

If you're just making the point that it's technically a different issue to the previous ones because the upstream source is different, then sure. But I referenced them because they refer to the same domain being blocked in StevenBlack/hosts.

The Spotify list also blocks redirector.gvt1.com which appears to prevent Firefox from installing the Widevine decryption module.

redirector.gvt1.com is apparently also the domain over which Google Chrome browser updates are served. It seems quite important. This Chromium issue comment says redirector.gvt1.com "redirects to other hosts in the gvt1.com domain, which is shared with other services," which seems like it'd explain why you're having issues in Firefox. No idea what "other services" beyond Chrome and Firefox could be relying on this, but it seems like a great degree of caution should be observed in blocking it.

EDIT: Looking through some more Chromium issues for hints, Chrome also serves spellcheck dictionaries and dictionary updates via redirector (see comment) and the Pepper Flash plugin for Linux (see comment)

EDIT2: I'm also seeing anecdotal evidence that Chrome extension updates are served via redirector.

The point is Steven @StevenBlack choose to include a list or not but on the other side, he does not touch any list. It's the responsibility of the upstream source maintainer to make the changes. Which means that you (or @StevenBlack ? :thinking: ) should add it to whitelist and that's all unless the maintainer of the upstream source decides to remove it.

So to resume there is two case:

  1. The upstream source maintainer removes the domain/IP

    • Steven updates this repo and that's it.

  2. The upstream source maintainer does not want to remove the domain/IP for his own and (always) valid reason (for example https://github.com/StevenBlack/hosts/issues/505#issuecomment-366695531)

    • You (or Steven) add the domain/IP to the whitelist list and you only have to update your copy with the script.

Thanks @vaguerant I've just dropped that source of hosts data.

Please update your hosts file, and try it now.

Just confirming that everything's back to normal after a list update; thanks for the rapid support.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

TheGroundZero picture TheGroundZero  路  3Comments

bsd-source picture bsd-source  路  3Comments

Sego1234 picture Sego1234  路  3Comments

The-Compiler picture The-Compiler  路  3Comments

beerisgood picture beerisgood  路  3Comments