This certificate question from Andy is a good one, and is the final reason I'm emailing to say I would vote against this proposed edit:
1. I can't see the security risk you're trying to protect against. We are looking at applications that use OSM data and will refer users to third party websites; what is the risk of a malicious user MiTM'ing a http request to a restaurant website (for example) and sending me to location other than the https version of the site? What web clients are you expecting this applies to? 2. I can see in the comments of your diary entry that you were told about HSTS recently. I'm not trying to be offensive, but that shows you're not a HTTPS / web security expert. Do you really think you're the person to be making world wide automatic changes to the database? As an aside, HSTS is interesting here because the website operator is saying "only use this domain over https", but at that point, we don't need to make changes to the database because the web client should be aware of the HSTS preload list; the protocol listed in the referrer is not relevant. 3. Again, are you checking https certificates? Do you know that the https site actually works? 4. Are you checking the redirect code? Do you differentiate between temporary and permanent redirects? 5. Are redirects even that bad? If I was to set up some careful redirects and have them ignored by a bot that thinks it knows better, I may be a little annoyed. What about geographic redirects? http://example.com becomes https://de.example.com, for example. 6. A different, but related issue: You say you "abhor www", but does that mean you should be making changes based on this? What about the people that like www. ? www. and the bare domain can be different hosts, so what about the small number of cases in which people host a different site on the bare domain? I notice your own domain resolves a different IP for the bare domain and the www subdomain. I can see that you want to promote https adoption, but I can't see that the OSM database is the place to do it. In the end, the website operator is responsible for deciding upon transport security, or not, and in how they publicise their sites; working with site operators, I think there is better work to be done encouraging https adoption outside of OSM, or more advanced topics such as HSTS. I also think you could explore the applications that use OSM data, and determine if they're using resources such as the HSTS preload list. I don't think there has been enough consideration of some of the issues here, and I think an automated bot edit would create a lot of noise without any obvious improvements. Cheers, Joseph On Tue, 26 Feb 2019 at 13:14, Andy Townsend <ajt1...@gmail.com> wrote: > On 26/02/2019 12:34, Bryce Jasmer wrote: > > Correct. No change will be made on anything other than the most > > straightforward of redirects. So even http://example.com -> > > https://example.com/home.aspx will be ignored. > > What about certificate checking? Suppose someone primarily uses http:// > for accessing their server, but has either a self-signed certificate on > https:// or an untrusted / expired one (perhaps they were testing). > Presumably in that case you wouldn't change http:// to https:// ? > > Best Regards, > > Andy > > > _______________________________________________ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk >
_______________________________________________ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
