New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support of IGN arial imagery (France) #3420

Closed
bagage opened this Issue Sep 14, 2016 · 5 comments

Comments

Projects
None yet
4 participants
@bagage
Contributor

bagage commented Sep 14, 2016

As stated to latest SOTM France, IGN local authority allowed use of their aerial imagery for openstreetmap contributions. It provides an alternative to Bing in France, with locally (much) better quality and/or up-to-date data.
Integration for JOSM was done by Christian Quest through a TMS proxy: http://proxy-ign.openstreetmap.fr/bdortho/{zoom}/{x}/{y}.jpg (authenticated by user-agent).
However this TMS is restricted to the use of a referer (hence the question/issue #3197). It has been 4 months since JOSM (working!) integration, I would really like (as other French iD users 😄 ) to see it available in iD as well.
We are currently stuck on this referer issue so here are my questions:

  • having a public token seem impossible to handle with upstream IGN authority. Is support of referer in iD possible? If it is planned, is there any ETA?
  • otherwise, is anybody aware of an alternative solution (no public token / no referer) that would allow us to use IGN ortho within iD?

Thanks!

@bhousel

This comment has been minimized.

Show comment
Hide comment
@bhousel

bhousel Sep 14, 2016

Member

Sorry, aside from what I already mentioned in #3197, I don't have any ideas on how to accomplish this..

Member

bhousel commented Sep 14, 2016

Sorry, aside from what I already mentioned in #3197, I don't have any ideas on how to accomplish this..

@tyrasd

This comment has been minimized.

Show comment
Hide comment
@tyrasd

tyrasd Oct 22, 2016

Member

Is support of referer in iD possible?

AFAIK, that's simply impossible to achieve in a web application: The referrer header is set by the browser itself and a web page can't influence the presence, absence or content of it in any way. What the browser decides to send depends on a number of factors, such as a user's privacy settings, installed privacy/ad-blocker addons and whether the web page and requested assets are on the same server/subdomain and/or use the same protocol (https or http).

If a web app could change the content of the referrer header, the effect would be the same as a public token (any other non-iD web page could fake the iD referrer).

PS: Are you aware that a malicious desktop application could fake the user agent it sends in order to illicitly scrape the imagery? Isn't that also basically the same as a public token (or less: a token could be easily revoked and replaced by a new one, while the user agent of JOSM will basically always stay the same)? 😕

//cc @cquest //cc @althio

Member

tyrasd commented Oct 22, 2016

Is support of referer in iD possible?

AFAIK, that's simply impossible to achieve in a web application: The referrer header is set by the browser itself and a web page can't influence the presence, absence or content of it in any way. What the browser decides to send depends on a number of factors, such as a user's privacy settings, installed privacy/ad-blocker addons and whether the web page and requested assets are on the same server/subdomain and/or use the same protocol (https or http).

If a web app could change the content of the referrer header, the effect would be the same as a public token (any other non-iD web page could fake the iD referrer).

PS: Are you aware that a malicious desktop application could fake the user agent it sends in order to illicitly scrape the imagery? Isn't that also basically the same as a public token (or less: a token could be easily revoked and replaced by a new one, while the user agent of JOSM will basically always stay the same)? 😕

//cc @cquest //cc @althio

@tyrasd

This comment has been minimized.

Show comment
Hide comment
@tyrasd

tyrasd Oct 22, 2016

Member

Some people in OP's linked forum thread seem to complain that this ticket was closed too quickly (see auto-translation below), so let's reopen it.

I am surprised at the speed with which closed bhousel this issue ... : Shock:
As he says himself, he has no idea to solve the problem (so there is a problem! ) but closing the end it leaves anyone the ability to have an idea.
Strange behavior! :?

On topic: I think what @bhousel wanted to say is that there's no easy way to implement such a usage-restriction really securely with the current code infrastructure. I would recommend talking to the provider of the imagery again and ask if using a public token would be OK for them. IMHO, if they are OK with the referrer-based check used with JOSM, they should also be OK with using a token-based system for iD (because it provides about the same level of security against scrapers, and also because it has been used as a solution in similar cases in the past, for example the geoimage imagery in Austria), but I'm certainly not the one to decide. If a token-based system isn't going to work out, one would have to implement some elaborate system where users log-in (maybe with their OSM account) in order to authenticate themselves against the imagery source or proxy, which would require changes to both iD and the server. And I also don't know how to accomplish this easily – ideas pull requests are very welcome!

Member

tyrasd commented Oct 22, 2016

Some people in OP's linked forum thread seem to complain that this ticket was closed too quickly (see auto-translation below), so let's reopen it.

I am surprised at the speed with which closed bhousel this issue ... : Shock:
As he says himself, he has no idea to solve the problem (so there is a problem! ) but closing the end it leaves anyone the ability to have an idea.
Strange behavior! :?

On topic: I think what @bhousel wanted to say is that there's no easy way to implement such a usage-restriction really securely with the current code infrastructure. I would recommend talking to the provider of the imagery again and ask if using a public token would be OK for them. IMHO, if they are OK with the referrer-based check used with JOSM, they should also be OK with using a token-based system for iD (because it provides about the same level of security against scrapers, and also because it has been used as a solution in similar cases in the past, for example the geoimage imagery in Austria), but I'm certainly not the one to decide. If a token-based system isn't going to work out, one would have to implement some elaborate system where users log-in (maybe with their OSM account) in order to authenticate themselves against the imagery source or proxy, which would require changes to both iD and the server. And I also don't know how to accomplish this easily – ideas pull requests are very welcome!

@tyrasd tyrasd reopened this Oct 22, 2016

@bhousel

This comment has been minimized.

Show comment
Hide comment
@bhousel

bhousel Oct 22, 2016

Member

AFAIK, that's simply impossible to achieve in a web application: The referrer header is set by the browser itself and a web page can't influence the presence, absence or content of it in any way.

☝️ This is why the ticket is closed - you restated the issue very well. It's closed simply because there is nothing we can do from iD to change how browsers fetch images.

I agree that the French OSM community should continue to work with IGN to open up their imagery, or find a way to proxy it themselves that satisfies the upstream requirements.

Member

bhousel commented Oct 22, 2016

AFAIK, that's simply impossible to achieve in a web application: The referrer header is set by the browser itself and a web page can't influence the presence, absence or content of it in any way.

☝️ This is why the ticket is closed - you restated the issue very well. It's closed simply because there is nothing we can do from iD to change how browsers fetch images.

I agree that the French OSM community should continue to work with IGN to open up their imagery, or find a way to proxy it themselves that satisfies the upstream requirements.

@bhousel bhousel closed this Oct 22, 2016

@althio

This comment has been minimized.

Show comment
Hide comment
@althio

althio Oct 30, 2016

Contributor

French OSM community should [...] find a way to proxy it themselves that satisfies the upstream requirements.

That is the chosen path, eg see osmlab/editor-layer-index#194

Contributor

althio commented Oct 30, 2016

French OSM community should [...] find a way to proxy it themselves that satisfies the upstream requirements.

That is the chosen path, eg see osmlab/editor-layer-index#194

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment