Changeset: 117029707
Change Wikimedia flag URLs of European states to 'https'
Closed by janolezab
Tags
changesets_count | 1961 |
---|---|
created_by | iD 2.20.4 |
host | https://www.openstreetmap.org/edit |
imagery_used | None |
locale | de |
Discussion
-
Comment from janolezab
There are still many states left: https://overpass-turbo.eu/s/1fNe
-
Comment from Kovoschiz
This seems to be a mistake on its own. `flag=` is mostly used for bus stop signs (British term). This info is already included in `wikidata=`. If anything, it should be `flag:wikimedia_commons=` to not worry about the protocol prefix, as in `wikimedia_commons=File:*`. `man_made=flagpole` uses `flag:wikidata=`.
-
Comment from Kovoschiz
Ps easiest method is Find & Replace the data file in a text-based tool.
-
Comment from janolezab
Yes, flag is used in two ways.
flag:wikimedia_commons would indeed be better, but that should probably be a mechanical edit at some point in the future.
-
Comment from Lee Carré
“Change Wikimedia flag URLs of European states to 'https'”
Why?
Ultimately you're addressing a client-side problem by altering data. That's what HSTS and HTTPS Everywhere are for. The /^https/ is a pseudo-protocol, after all. /^http[^s]/ is more robust & future-proof (when encryption is done using the default port, over the same original connection, to preserve more port numbers (closer to 2¹⁶ for other uses (instead of 2⁸, because each protocol demands 2)).
Besides, not all User-Agents need encryption (bots).You're also defeating caching for a resource which is ideal for caching.
So, I don't see anything being gained by this changeset.
Worse, the bbox is nebulous. Would've been much better to change each nation individually. That would enable separate discussions.
-
Comment from janolezab
"Why?"
"http:" links refer to unencrypted HTTP resources and should not appear anywhere where TLS is available. You just assume the client would know to use https instead, but this is not always the case. So let me put your question the other way round. Why should it stay "http"?"Besides, not all User-Agents need encryption (bots)."
They do, because Wikimedia does not support unencrypted HTTP connections. See https://meta.wikimedia.org/wiki/HTTPS for more info."the bbox is nebulous."
Which is the case every time you edit France or the United Kingdom.Separating the edits would generate more edits in almost every watched bounding box.
I could understand the whish to remove the "flag" tags everywhere. But not the whish to keep "http" links.
-
Comment from woodpeck
Wide-ranging and automated edits like this need to be discussed with the community in advance as per our mechanical editing policy (https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct).
-
Comment from woodpeck_repair
This changeset has been reverted fully or in part by changeset 117109398 where the changeset comment is: reverting undiscussed mechanical edit
-
Comment from janolezab
This changeset was done manually with iD.
Yes, it could be considered wide-ranging. Which is but out of scope for the wiki article you posted.
-
Comment from Lee Carré
> "http:" links refer to unencrypted HTTP resources
Incorrect. You clearly didn't read what I stated, or didn't comprehend it.
Only the L7 protocol is specified. Encryption is another matter. You're assuming that HTTP is non-encrypted, based on the HTTPS pseudo-protocol. There are actually several modes of encryption for HTTP.
Compare IMAP with STARTTLS.
> should not appear anywhere where TLS is available.
Based on anything other than your preference or opinion? Particularly since I gave examples earlier.
You just assume the client would know to use https instead
Not at all. You're projecting.
> this is not always the case.
Which is fine, and up to the client. Authoritarianism and know-better-than-the-reader-what's-best-for-him doesn't belong on the Web; by design.
> So let me put your question the other way round. Why should it stay "http"?
Already answered that. See my earlier response.
The burden of proof is yours; you're asserting that s/^http:/https:/g should be so. This is your changeset, too.
> "Besides, not all User-Agents need encryption (bots)."
> They do, because Wikimedia does not support unencrypted HTTP connections. See https://meta.wikimedia.org/wiki/HTTPS for more info.LOL, you assume much.
Besides scope, Wikipedia insisting on HTTPS isn't a matter of the bot (assuming one which is concerned about fetching from WP) itself needing HTTP+TLS, but the site requiring it. The bot would be perfectly happy without.
Wikipedia does indeed respond to TCP/80, else how does it redirect to TCP/443 ?
Sounds like you don't understand relevant networking, either.
> "the bbox is nebulous."
> Which is the case every time you edit France or the United Kingdom.Relevance for this changeset?
> Separating the edits would generate more edits in almost every watched bounding box.
Perhaps (but evidence?), but they would be scored, and more locally relevant, allowing independent discussion, like I already said.
Your failure to read documentation causes extra changesets, due to the needed reversion.
> I could understand the whish to remove the "flag" tags everywhere. But not the whish to keep "http" links.
That's not a technical or OSM matter / problem.
-
Comment from janolezab
> Only the L7 protocol is specified.
Encryption is another matter. You're assuming that HTTP is non-encrypted, based on the HTTPS pseudo-protocol. There are actually several modes of encryption for HTTP.
Which of these modes is implemented by Wikimedia or how else could that be relevant? The answer is: It is not, "https:" URLs are the only way to retrieve resources from Wikimedia using HTTP. Also, do not confuse protocols with URL schemes. While HTTP does not exclude the usage of TLS, an "http:" URL does most certainly.
What you are referring to is that HTTP is specified separately from encryption. Which is true: A plain HTTP connection will not be encrypted. An "http:" URL refers to such a connection (or an alternate encryption mode, which is not relevant in this case, like in most other cases; and would also involve unencrypted HTTP communication before upgrading the connection).
With an "http:" URL, the client will not immediately know that it has to use a TLS connection until it gets the redirection.
Unless it has some state that tells to rewrite the URL to "https:" in the first place. Which you even mentioned, with HSTS and HTTPS Everywhere. But you wanted to convince me of the advantage of "http:" URLs. If these are only used for the redirect and avoided when the client has better knowledge, why not link to the resource directly?
> > You just assume the client would know to use https instead
> Not at all. You're projecting.Above, I can read you speaking about HSTS. According to https://https.cio.gov/hsts/, "HSTS exists to remove the need for the common, insecure practice of redirecting users from http:// to https:// URLs." Note that redirecting is considered insecure here.
Where available, it is a good tool to avoid requesting "http:" resources and heading for "https:" URLs instead.But with your statement "That's what HSTS and HTTPS Everywhere are for" you seem to assume that something alike is present. What about the bot you mentioned? What about a user who has no state from a previous visit? They will first use the URL that is written, thus using an unencrypted HTTP connection, weakening the advantage of HTTPS. If the link itself referred to the secure and correct location, everything would be fine and such mechanisms are not needed.
There are many cases with good reasons to leave redirecting links, e.g. shortlinks. This is not one of those cases.
> > So let me put your question the other way round. Why should it stay "http"?
> Already answered that. See my earlier response.My fault, now I see it. You claim that "http:" URLs would be more "robust & future-proof". What makes you think this might be the case?
Also, you connected that with another assumption ("when encryption is done using the default port, over the same original connection"); an assumption that just did not hold up in this case.
Furthermore, your salty side-note "instead of 2⁸, because each protocol demands 2" leads me to think you might just not be a fan of dedicated protocol-over-TLS ports.
By the way: half of 2¹⁶ would be 2¹⁵, not 2⁸.Also, from the same comment: "You're also defeating caching for a resource which is ideal for caching.".
The pictures are not subject to caching by middleware, as they will always be sent out encrypted. Caching a few redirects would be still possible, but is less benecificial than to avoid them.> The burden of proof is yours; you're asserting that s/^http:/https:/g should be so. This is your changeset, too.
The correct behaviour of OSM is to link to resources by using the correct URL. I tried to replace outdated links by securer and more direct links.
> > "Besides, not all User-Agents need encryption (bots)."
> > They do, because Wikimedia does not support unencrypted HTTP connections. See https://meta.wikimedia.org/wiki/HTTPS for more info.
> LOL, you assume much.I believe I have proven my "assumption" well, with an article that directly tells that the transition to HTTPS-only has ended.
A "LOL" is a possible answer, but does not help you in making a counter argument.
> Besides scope, Wikipedia insisting on HTTPS isn't a matter of the bot (assuming one which is concerned about fetching from WP) itself needing HTTP+TLS, but the site requiring it. The bot would be perfectly happy without.
Maybe the bot would be "happy" without TLS, but it is still required, so what choice does the client have? What does "happy" mean, by the way?
> Wikipedia does indeed respond to TCP/80, else how does it redirect to TCP/443?
Which is all you will get from "http:" URLs at Wikimedia: A redirect. They redirect to the correct resource, which is behind an "https:" URL. Which in turn is the correct resource locator.
Try it out right now: `curl -v http://meta.wikimedia.org/wiki/HTTPS` for example, if you have curl installed.
You will not get the desired resource, but a redirection to its correct location: "Location: https://meta.wikimedia.org/wiki/HTTPS"The TCP/80 webserver is only present for backwards compatibility with older URLs and the like.
I have to rephrase my sentence to "Getting content on Wikimedia requires requesting an HTTPS URL", though. Requesting the "http:" resource beforehand is not necessary or constructive, as the location has changed.
> Sounds like you don't understand relevant networking, either.
Your opinion that "http:" URLs have to stay indefinitely is not the prevailing one in the IT industry and seems technically not very grounded. It staggers me you have no insight in this and even start to make insulting assumptions about people.
> > "the bbox is nebulous."
> > Which is the case every time you edit France or the United Kingdom.
> Relevance for this changeset?In this changeset, I edited at least one country which generates a big changeset bounding box when changed. When noting a "nebulous" bbox, I assumed you were referring to its size.
> Your failure to read documentation causes extra changesets, due to the needed reversion.
It is still 2 changesets – versus many more, if I used one CS for one country. Your impression of "extra changesets" seems to be not correct.> > I could understand the whish to remove the "flag" tags everywhere. But not the whish to keep "http" links.
> That's not a technical or OSM matter / problem.I do not fully understand the motivation behind this sentence. Both intents would be only fulfilled by adjusting tags, which could be achieved by a changeset like this.
Again, this was not a mechanical or half-automated edit. I just selected objects with iD and discovered and changed tag values that were a bit outdated. Just that countries are a bit harder to select than other objects.
Relations (1-20 of 37)
- 1
- 2
- Andorra (9407), v74
- Slovensko (14296), v596
- Österreich (16239), v1169
- Magyarország (21335), v496
- Civitas Vaticana - Città del Vaticano (36989), v93
- Polska (49715), v1192
- Danmark (50046), v152
- Deutschland (51477), v1831
- Česko (51684), v901
- Schweiz/Suisse/Svizzera/Svizra (51701), v522
- België / Belgique / Belgien (52411), v985
- Sverige (52822), v326
- Shqipëria (53292), v197
- Crna Gora / Црна Гора (53296), v247
- Suomi (54224), v259
- San Marino (54624), v75
- Moldova (58974), v426
- Беларусь (59065), v912
- Україна (60199), v1314
- Éire / Ireland (62273), v654
Welcome to OpenStreetMap!
OpenStreetMap is a map of the world, created by people like you and free to use under an open license.
Hosting is supported by Fastly, OSMF corporate members, and other partners.
https://openstreetmap.org/copyright | https://openstreetmap.org |
Copyright OpenStreetMap and contributors, under an open license |