Skip to content
This repository has been archived by the owner on Nov 6, 2023. It is now read-only.

Initial commit of Pleasuredome.xml #8195

Merged
merged 2 commits into from Feb 13, 2017
Merged

Initial commit of Pleasuredome.xml #8195

merged 2 commits into from Feb 13, 2017

Conversation

ghost
Copy link

@ghost ghost commented Jan 13, 2017

This ruleset covers the Pleasuredome Tracker and its associated forums.


<securecookie host=".+" name=".+" />

<rule from="^https?://pleasuredome\."
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't redirect https domains.

<securecookie host=".+" name=".+" />

<rule from="^https?://pleasuredome\."
to="https://www.pleasuredome." />
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not a valid TLD

Copy link
Contributor

@J0WI J0WI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This host serves a self-signed cert and the rule syntax has several issues.

@ghost
Copy link
Author

ghost commented Feb 12, 2017

Sorry, I didn't realise that self-signed certs are disallowed. Several parties have tried - and failed - to convince the webmaster to make use of a properly signed certificate. Therefore, this ruleset will remain inadmissible and I am closing the request.

@ghost ghost closed this Feb 12, 2017
@J0WI
Copy link
Contributor

J0WI commented Feb 12, 2017

They are not disallowed, but then the rule should be default_off.

@ghost ghost reopened this Feb 12, 2017
@J0WI J0WI merged commit 5328c76 into EFForg:master Feb 13, 2017
@ghost
Copy link
Author

ghost commented Feb 13, 2017

Incidentally, it is neither mentioned here nor here that redirects from https URLs are a QA violation. Further, some existing rulesets exploit the fact that it can be done.

$ cat *.xml | perl -ne 'print if /rule from="\^?https/ and not /<!--\s*<?rule/' | wc -l
98

Why does HTTPS-Everywhere honour such rules (downgrade attribute notwithstanding) if it is not considered to be an acceptable practice?

EDIT: Thanks for the merge!

@J0WI
Copy link
Contributor

J0WI commented Feb 13, 2017

The documentation will soon be improved: https://github.com/EFForg/https-everywhere/pull/8193/files#diff-6a3371457528722a734f3c51d9238c13R230

We hope to get rid of the existing cases, but sadly some servers are really bad configured (see also discussion started in #7717).

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants