Everydayfeminism.com.xml is broken (goes to CloudFlare always on with desktop, error about invalid certificate on mobile)

[Mikaela]

I was adviced to open an issue as contact attempts to them have been unsuccessful.

Other issues about that ruleset:

• https://github.com/EFForg/https-everywhere/issues/7317
• https://github.com/EFForg/https-everywhere/pull/6782

[jeremyn]

In https://github.com/EFForg/https-everywhere/issues/7317#issuecomment-254885246 @Hainish wrote that the problem you described in that issue, which is that the ruleset causes a problem on Firefox for Android but not desktop Firefox, is due to an unusual configuration by the everydayfeminism.com site admin. It's not something we can fix in HTTPS Everywhere.

What outcome do you want from this issue? Do you want the ruleset removed? Are you asking for an enhancement to HTTPS Everywhere where rulesets consider whether they're desktop or mobile? Please clarify.

Also, to clarify: who asked you to open this issue with HTTPS Everywhere -- someone with HTTPS Everywhere, someone with everydayfeminism.com, or someone else? Thanks.

[mnordhoff]

@jeremyn

Aside from the desktop/mobile issue, now the site (at least for me) always returns Cloudflare error pages. (The backend certificate is invalid.) That's certainly something that HTTPS Everywhere can't fix.

I was the person who mentioned opening an issue. I don't represent anyone. We were talking just about it.

I think that, sadly, the ruleset should be disabled.

[jeremyn]

@mnordhoff That's fine. I see what you mean about there being a problem on desktop and mobile. curl returns a "526 Origin SSL Certificate Error". Is that what you're basing your "The backend certificate is invalid." on, or do you actually have a way of checking that certificate? It would be nice to know why that certificate is invalid. I don't want to disable a ruleset if it's only a short-term problem.

I'll mark this with the "Before the Next Release" milestone. If we get close to the next release and it's still returning a Cloudflare error, we can disable the ruleset then. @Mikaela , is that all right with you?

[mnordhoff]

@jeremyn No, i don't have a way of checking the certificate. All i can say is "something is wrong with it" based on Cloudflare's documentation.

Edit: I agree with everything you said about waiting to see if they fix the problem.

[Mikaela]

Also, to clarify: who asked you to open this issue with HTTPS Everywhere -- someone with HTTPS Everywhere, someone with everydayfeminism.com, or someone else? Thanks.

I talked about this on #https-everywhere at OFTC (or https://matrix.to/#/#_oftc_#https-everywhere:matrix.org ) where I wish there would also be people who have something to do with HTTPS Everywhere as it gives no indication of being unofficial.

_Topic for #https-everywhere is "https://www.eff.org/https-everywhere | git pull requests here will eventually be looked at, even if it doesn't happen straight away | please stay in the channel after you ask questions! | https://bugzilla.mozilla.org/show_bug.cgi?id=878890 <--- answers at least half the questions here :("_

I'll mark this with the "Before the Next Release" milestone. If we get close to the next release and it's still returning a Cloudflare error, we can disable the ruleset then. @Mikaela , is that all right with you?

Yes. I am desperate with this ruleset and wish I never submit it as it has only given me stress and worry while I only wanted connections there to be protected by HTTPS as they don't seem to be going to enable HSTS or go to HSTS preload list.

---

Related IRC log:

2016-10-23 19:04:38+0300 < Riotela> Yay, everydayfeminism.com fixed their https being desktop-only, but broke their CloudFlare info complaining about invalid SSL certificate
2016-10-23 19:06:46+0300 < Peng_> :X
2016-10-23 19:07:05+0300 < Peng_> So now it's broken for everyone, i guess
2016-10-23 19:10:11+0300 < Riotela> Only for HTTPS Everywhere users, I think. Should I send a PR reverting that commit or something or wait for them to fix it or is notifying this channel enough?
2016-10-23 19:11:56+0300 < Peng_> You could send a PR setting <ruleset name="Everydayfeminism.com" default_off="something or other">
2016-10-23 19:12:10+0300 < Peng_> Or notify Everyday Feminsim. Or file an issue on Github.
2016-10-23 19:13:56+0300 < Riotela> I guess I will file an issue as everydayfeminism.com isn't very communicative unless this is answer to my first problem on them not using HSTS
2016-10-23 19:21:06+0300 < Riotela> actually it seems to work on desktop (by using CloudFlare always on which gives cached version of http page :D) so I am lost and have no diea what to do and creating issue to HTTPS Everywhere feels wrong
2016-10-23 19:23:31+0300 < Peng_> If a website doesn't work over HTTPS, the relevant HTTPS Everywhere rules should be disabled.
2016-10-23 19:23:43+0300 < Peng_> At the moment, Everyday Feminism doesn't work over HTTPS.
2016-10-23 19:23:52+0300 < Peng_> The question is whether they're going to fix it
2016-10-23 19:25:55+0300 < Riotela> It seems to work over https on desktop at least with that CloudFlare always on thing
2016-10-23 19:28:35+0300 < Peng_> I wouldn't count Cloudflare Always On as "working". They just have a cached copy of some pages, for now, while the backend is failing.
2016-10-23 19:31:27+0300 < Riotela> https://github.com/EFForg/https-everywhere/issues/7420
2016-10-23 19:31:55+0300  * Riotela is ashamed of ever sending that ruleset or saying anything about https or hsts to them even if there is no proof anyone heard her
2016-10-23 19:33:03+0300 < Peng_> Not your fault. :( You submitted the ruleset when everything seemed to work, then the website broke.
2016-10-23 19:34:55+0300 < Riotela> I should have tested it on Android to at least avoid https://github.com/EFForg/https-everywhere/issues/7317#issuecomment-254290933
<...>
2016-10-24 18:42:09+0300 < Riotela> Peng_: would you mind me pasting the logs of our talking to that issue?
2016-10-24 18:42:23+0300 < Peng_> Riotela: Feel free. :)
2016-10-24 18:42:32+0300 < Riotela> Thanks

[Hainish]

@Mikaela thanks for staying on top of this issue. I wouldn't feel bad about submitting this rule - you did what seemed most sensible at the time when you submitted it. Ruleset contributors shouldn't have to check whether a ruleset works under every conceivable browser configuration - this is an extreme edge case.

I'll make a note to check the site shortly before the next release, and if it still exhibits unusual behavior we can disable it at that point.

[jeremyn]

@Mikaela I want to add to what @Hainish wrote in the previous comment.

The HTTPS Everywhere project is not set up to provide quick turnaround or support, even for serious problems. If there is a problem, then please submit an issue or pull request here on GitHub.

You definitely should not worry, stress, or feel desperate about any ruleset you submit. You are not expected to maintain a ruleset after it's merged.

The HTTPS configuration for everydayfeminism.com has been very problematic. Having working HTTPS on desktop but not mobile is very unusual. We don't expect you to check for that problem and we don't check for that problem ourselves. Now HTTPS is broken entirely because I guess they have some certificate problem. If they didn't want users to rely on working HTTPS, then they shouldn't have provided HTTPS support in the first place. In any case, their problems are not your fault.

I hope you'll submit more rulesets in the future and continue to be involved with HTTPS Everywhere.

[Mikaela]

It appears that the situation has restored to https://github.com/EFForg/https-everywhere/issues/7317 so I hope I can forget this ruleset.

I am not pressing "Close and comment" just in case (I understood the situation is going to be checked before the next release(?) and the site can do anything after three issues here), but feel free if you think that is the appropiate course.

[jeremyn]

I can confirm that we're back to where we were in #7317: desktop works, mobile doesn't. Since desktop works now, there's no need to recheck this before the next release, so I'm closing this issue.