HTTPS anywhere extension prevents iD from loading on openstreetmap.org

[pnorman]

The OpenStreetMap Wiki ruleset prevents iD from loading on the main page in Firefox. This is browser-specific as it works fine in Chrome with the wiki ruleset enabled.

Upstream bug: https://trac.torproject.org/projects/tor/ticket/8841

[jfirebaugh]

Is there anything iD can do to mitigate this?

[tmcw]

It's easy to turn off https anywhere in this case. Maybe we should have a 'Troubleshooting' guide for things like this?

[pnorman]

I can see a few ways to mitigate this

• Default to something more sensible than blankness if iD fails to load. If you try P2 without flash you get some kind of error message letting you know something is wrong. The blank window doesn't let you know if it's a browser issue, server issue, or you did something wrong.
• Build up a troubleshooting guide with common problems, etc
• See what is causing the problem with Firefox but not Chrome. My guess is some file that one is allowing but the other isn't. We may not be able to fix it and conclude its an extension bug (specifically with the HTTPS anywhere OSM wiki ruleset) but we should know what it is

[pde]

Hi. I'm one of the HTTPS Everywhere developers. This bug looks fairly mysterious to me, so I think we might have to mitigate it by disabling our OSM wiki ruleset in our next release. This of course will leave OSM accounts completely vulnerable to surveillance, hijacking, cookie theft, etc :(

We do have the following information available for anyone who wants to work on debugging this:

https://www.eff.org/https-everywhere/atlas/domains/openstreetmap.org.html

[pnorman]

I installed firebug and the error I got was

SecurityError: The operation is insecure.
http://www.openstreetmap.org/assets/iD-1d6bb550b040bb8d426e995f36f1e2d1.js
Line 93

Since the ruleset is called OpenStreetMap wiki it probably shouldn't include the OSM website at all regardless of this bug.

If creating a new ruleset for the OSM website it's probably safe to direct /login and /user/new to HTTPS. Although this leaves open some attack vectors it closes off at least one, and I think that would work with iD.

[jfirebaugh]

According to https://gitweb.torproject.org/https-everywhere.git/commit/6d45cb17509225cf4f5faa88c903b4a5b18a67d2 the OSM.org rule is now disabled by default. If someone wants to figure out how to fix it and reenable, go for it. Closing here.

[yardenac]

If I go to https://www.openstreetmap.org/edit today, it bumps me back to port 80. Is the server rewriting on purpose to work around this bug? Meanwhile I've submit an https-everywhere patch which just excludes /edit here: EFForg/https-everywhere#158

[pnorman]

That's out of scope for iD, as it does it for all editors. /edit is not on HTTPS because it hasn't been tested, and there are almost certainly mixed content issues.