The poimap2 code is provided by Wikivoyage eV, updated on toolforge twice a week via crontab. I haven't touched this in years, and English Wikivoyage has since moved on to using the production maps service AFAIK. Mey2008, the author of poimap2, is probably the best person to contact about this, but they are unfortunately not active.

I did a quick check, if &layer=NSM portion of the URI is left out it will load the tiles and data from Wikimedia servers instead of OSM. I do not know what NSM means, but I think hewikivoyage should be contacted to not use it by default.

I do not know what NSM means

I just checked the code, N means layer "Traffic", S means layer "Hill shading", and Mmeans base layer "Mapnik". The layer chooser at the top right shows that all of these are externally hosted.

Thank you for the detailed response. That's very helpful to know (about the default layers).

Let's keep the relevant projects and subscribers (inherited from parent) (unless they remove themselves), though.

We can resolve it once we verify:

• No wiki projects are using external tiles by default.
• This is complaint with the OSM tile policy.

Also, where is the source code for this?

In T186247#3938827, @Mattflaschen-WMF wrote:

Also, where is the source code for this?

The url that the tool downloads from is http://maps.wikivoyage-ev.org/archive/w.zip, which should be the latest (and I think the download & unzip script is written by torty3). I do not know how the association internally does the development. A quick google search also shows two old mirrors on GitHub 1 2.

Digging the history led me to https://meta.wikimedia.org/wiki/Wikivoyage/Lounge/Archive/2014-11#Maps_loading_external_resources

In T186247#3938919, @zhuyifei1999 wrote:

In T186247#3938827, @Mattflaschen-WMF wrote:

Also, where is the source code for this?

The url that the tool downloads from is http://maps.wikivoyage-ev.org/archive/w.zip, which should be the latest

Thanks.

Matt, I am not sure a CL is really needed here? (I am super curious though about how this will end, and how to find all the communities equally affected.)

In T186247#3958372, @Elitre wrote:

Matt, I am not sure a CL is really needed here? (I am super curious though about how this will end, and how to find all the communities equally affected.)

We will need to communicate with the community about taking over their current templates and replacing them with the new (and non-privacy-hurting) maps stack. I don't know if there's a lot to do, but we should definitely have a good way of communicating why and how we're doing it since it will change the way they see the maps and how it works a little bit. They'll also probably gain a few things (translateability, RTL support) so the argument is easier, but there probably should be some communication going on.

In T186247#3968585, @Mooeypoo wrote:

In T186247#3958372, @Elitre wrote:

Matt, I am not sure a CL is really needed here? (I am super curious though about how this will end, and how to find all the communities equally affected.)

We will need to communicate with the community about taking over their current templates and replacing them with the new (and non-privacy-hurting) maps stack. I don't know if there's a lot to do, but we should definitely have a good way of communicating why and how we're doing it since it will change the way they see the maps and how it works a little bit. They'll also probably gain a few things (translateability, RTL support) so the argument is easier, but there probably should be some communication going on.

I believe that as a member of the WP community, speaker of that language and involved in this project, you will be totally set to discuss the change there :)
However (especially if we discover this actually affects other languages) someone in that team can look at the "template" at https://office.wikimedia.org/wiki/Community_Liaisons/Support_requests and adjust this task accordingly so we'll have the info we need to resource this if needed. TY!

Just to confirm, Collaboration team is planning to take this task on right away?

Loading external resources without a click through advising users that they are loading a third party resource is a big no-no and rectifying it should be considered a high priority task.

For many reasons this is entirely unacceptable, whether it be loading external resources or making depending upon tools.wmflabs.org. I've asked stewards to disable this for now: https://meta.wikimedia.org/wiki/Stewards%27_noticeboard#Disable_privacy_violating_JavaScript_on_he.wikivoyage

Local script temporarily suspended by @Rxy at https://he.wikivoyage.org/w/index.php?diff=190999.

rxy has disabled it for now. Once it's no longer possible for external resources to be loaded without user's consent, it should be fine to renable it.

Am I missing something here or has something gone wrong in the handling of this ticket? How was it known for two weeks but stayed online?

In response to https://meta.wikimedia.org/w/index.php?title=Stewards%27_noticeboard&oldid=17746565, I was going to recommend removing the layer parameter from https://he.wikivoyage.org/wiki/MediaWiki:MapFrame.js, which I believe is what was making it possible to enable the third-party layers by default on an article.

The availability of third-party layers in the interface is in itself not a problem, we do the same in Kartographer maps, but they're opt-in.

The edit would be:

function insertIFrame() {
    var exhtml = '//tools.wmflabs.org/wikivoyage/w/poimap2.php?';
    var map = $('#mapdiv');
    if ( map.length ) {
        validateMap(map);
        var exsrc = exhtml+'lat='+map.data("lat")+'&lon='+map.data("long")
-            +'&zoom='+map.data("zoom")+'&layer='+map.data("layer")+'&lang='+wgContentLanguage+'&name='+wgPageName;
+            +'&zoom='+map.data("zoom")+'&layer=O&lang='+wgContentLanguage+'&name='+wgPageName;

I've confirmed locally that previewing https://he.wikivoyage.org/wiki/קופנהגן/אינדרה_בו page with this script instead, result in no third-party requests being made.

We need to be careful not to completely and immediately destroy functionality on hewikivoyage. This should be fixed, but we should and can fix it right.

I tested <mapframe> and it works on hewikivoyage: https://he.wikivoyage.org/wiki/%D7%9E%D7%A9%D7%AA%D7%9E%D7%A9:Mooeypoo/maptest

We should migrate hewikivoyage {{mapframe}} template to use <mapframe> rather than the frame it uses. Whatever we do, though, let's try not to completely disable hewikivoyage's map ability without having the replacement ready.
What exists right now is bad for privacy policy, but it's been like that for years. We can give it a couple of days to do this in a way that doesn't suddenly remove all maps from the site, like replace the {{mapframe}} template properly.

In T186247#3980292, @Mooeypoo wrote:

What exists right now is bad for privacy policy, but it's been like that for years. We can give it a couple of days to do this in a way that doesn't suddenly remove all maps from the site, like replace the {{mapframe}} template properly.

Sorry, but privacy policy violations are different different. The fact it's been like this for so long is a huge problem that we need to address (CSP, etc.) but leaving it even longer is unacceptable in my view. This ticket was filed over 2 weeks ago, but nothing changed, so the leeway for a couple of days is well past.

In T186247#3980297, @Legoktm wrote:

In T186247#3980292, @Mooeypoo wrote:

What exists right now is bad for privacy policy, but it's been like that for years. We can give it a couple of days to do this in a way that doesn't suddenly remove all maps from the site, like replace the {{mapframe}} template properly.

Sorry, but privacy policy violations are different different. The fact it's been like this for so long is a huge problem that we need to address (CSP, etc.) but leaving it even longer is unacceptable in my view. This ticket was filed over 2 weeks ago, but nothing changed, so the leeway for a couple of days is well past.

Fair enough, but imho we should at least make sure we notify the community about this (which you've done, thank you!) since in this case it's also a pretty major feature for the wiki that is now completely broken.
Also, the fact that there was a possible mid-step as to removing the privacy issue while still having the functionality work sounded like we may have a good temporary solution before completely migrating to kargographer.

I've flagged this to @eranroz and @Matanya in hopes that one of them can maybe point to a way forward in fixing the map stack properly. If we migrate it properly to Kartographer, the issue is gone and the functionality is even a better one than what they had.

I applied T186247#3980290, @Krinkle 's hack.

No external resources now.

In T186247#3980254, @Legoktm wrote:

For many reasons this is entirely unacceptable, whether it be loading external resources or making depending upon tools.wmflabs.org.

Lego, I guess making depending upon tools.wmflabs.org is not rare, and used by other wikis. If this by itself could be unacceptable - this can be reviewed either static analyses using mwgrep tools.wmflabs.org in all WMF wikis in MW NS or dynamicly using PhantomJS (see T71519) and can be reviewed further in different task.

In T186247#3980396, @Mooeypoo wrote:

I've flagged this to @eranroz and @Matanya in hopes that one of them can maybe point to a way forward in fixing the map stack properly. If we migrate it properly to Kartographer, the issue is gone and the functionality is even a better one than what they had.

I ported he.wikivoyage templates to use Kartographer.

In T186247#3980676, @eranroz wrote:

In T186247#3980254, @Legoktm wrote:

For many reasons this is entirely unacceptable, whether it be loading external resources or making depending upon tools.wmflabs.org.

Lego, I guess making depending upon tools.wmflabs.org is not rare, and used by other wikis. If this by itself could be unacceptable - this can be reviewed either static analyses using mwgrep tools.wmflabs.org in all WMF wikis in MW NS or dynamicly using PhantomJS (see T71519) and can be reviewed further in different task.

To clarify, depending upon tools.wmflabs.org is OK from a privacy policy perspective but not great from a maintenance/performance point of view. The main problem was that resources were being loaded from *.openstreetmap.org, which is not OK.

In T186247#3980676, @eranroz wrote:

I ported he.wikivoyage templates to use Kartographer.

Excellent, thank you! This also means that the maps actually work better (full screen, for instance, works inside the article) and that they are benefiting from the recent minor (but crucial) RTL support fixes.
There are a couple of minor issues we should continue adjusting, but I'll create other tickets for those.

Checked he.wikivoyage maps for general functionality - seems to be working fine.
To summarize

• the default option (out of three: Wikimedia, Mapnik, Relief map) is Wikimedia option. Selecting other options during a user session won't be saved after a user logs out.
• Mapnik and Relief map options has an icon indicating that the options refer to external sources. There is also a tooltip, e.g.

<span> Mapnik&nbsp;<span class="leaflet-control-layers-oo-ui-icon oo-ui-widget oo-ui-widget-enabled oo-ui-iconElement oo-ui-iconElement-icon oo-ui-icon-linkExternal oo-ui-iconWidget" aria-disabled="false" title="This content is hosted externally, so enabling it shares your data with other sites."></span></span>

Other than that, users are not additionally informed when they switch to options that use external maps.

• the page where @Mooeypoo did testing - https://he.wikivoyage.org/wiki/%D7%9E%D7%A9%D7%AA%D7%9E%D7%A9:Mooeypoo/maptest - has a Console error:

Uncaught ReferenceError: getElementsByClassName is not defined
   at HTMLDocument.updateUserEditCounter (load.php?debug=false&lang=en&modules=ext.gadget.Contributions%2CDwim%2CSummarieslist&skin=vector&version=17lh3b0:1)
   at mightThrow (load.php?debug=false&lang=en&modules=jquery%2Cmediawiki|mediawiki.legacy.wikibits&only=scripts&skin=vector&version=14kbqyi:49)
   at process (load.php?debug=false&lang=en&modules=jquery%2Cmediawiki|mediawiki.legacy.wikibits&only=scripts&skin=vector&version=14kbqyi:50)