Opened 7 years ago

Closed 7 years ago

#5912 closed defect (fixed)

MyWOT extension breakage

Reported by: pde Owned by: graffatcolmingov
Priority: High Milestone:
Component: HTTPS Everywhere/EFF-HTTPS Everywhere Version:
Severity: Keywords:
Cc: graffatcolmingov@…, skrubaduba@…, thejoshmeister@…, support@… Actual Points:
Parent ID: #3190 Points:
Reviewer: Sponsor:

Child Tickets

Change History (11)

comment:1 Changed 7 years ago by graffatcolmingov

I'm looking for a way to contact the developers of the extension to see if they'll consider 2 or 3. I'm also going to contact the user who suggested those additions to the ruleset. They have accounts on MyWOT and may be able to assist us in testing any changes or the MyWOT extension developers make.

comment:2 Changed 7 years ago by pde

MyWOT's support person is CCd in this ticket; they should receive emails with whatever you say here.

comment:3 Changed 7 years ago by graffatcolmingov

Didn't notice that. They can disregard my message then. I'm still waiting to hear back from Janne, but I personally would like to see the extension make use of HTTPS for everyone. As I understand it (from a very brief browsing of their website) they're collecting reports on websites from users. One page even has a list of top comments on certain websites and I for one think any kind of browsing habit, even if voluntarily shared publicly in some manner, should be sent over HTTPS. If it would just be easier for them in the short run to just add a listener for the uri rewrite event, that's fine too. I just dislike options 1 and 4.

comment:4 Changed 7 years ago by sami

Guys, requests from the WOT add-on are already encrypted and authenticated, which is why HTTPS is not used by default. However, our servers do support HTTPS, so forcing the requests to use HTTPS shouldn't be a problem.

However, the problem appears to be that HTTPS Everywhere 3.0development.3 simply breaks the XMLHttpRequests our add-on makes to api.mywot.com, instead of transparently redirecting them to use HTTPS. I'm not sure what has changed, because there were no conflicts with 2.0.5.

Are you saying it's not possible for you to rewrite the requests transparently, but it would require changes to our add-on instead?

Note that the add-on only communicates with api.mywot.com, so any rules that apply to other subdomains do not affect it.

comment:5 in reply to:  4 ; Changed 7 years ago by pde

Description: modified (diff)

Replying to sami:

Are you saying it's not possible for you to rewrite the requests transparently, but it would require changes to our add-on instead?

That's right, unfortunately :(

We actually just worked with a developer who figured out a way to make XHR requests without us breaking them,

http://lduros.net/posts/https-everywhere-and-xhr-other-add-ons/

(it may be possible for us to make changes so that something simpler is possible, but we aren't sure yet)

In any case, if this sounds like too much work, we can just remove api.mywot.com from the ruleset, especially if you are certain that won't leave users worse off.

comment:6 in reply to:  5 Changed 7 years ago by graffatcolmingov

Owner: changed from pde to graffatcolmingov
Status: newaccepted

Replying to pde:

In any case, if this sounds like too much work, we can just remove api.mywot.com from the ruleset, especially if you are certain that won't leave users worse off.

Yeah, I'll remove it if sami would like that. It'll stop the breakage and if they're already encrypting information, I see no reason for this not to be ok. Janne also gave me another cookie for a securecookie rule.

comment:7 Changed 7 years ago by graffatcolmingov

The changes are in my branch.

comment:8 Changed 7 years ago by janne

Status: acceptedneeds_information

The domain api.mywot.com is accessed on the MyWOT website as well as on other web services, so it would be better if the devs at WOT could assess this problem as theres a good reason for it to be included in HTTPS Everywhere due to this. Its not restricted to only the addon, but elsewhere on the web as well on websites.

comment:9 Changed 7 years ago by sami

Instead of rewriting all XMLHttpRequests to use nsIIOService, is there a recommended way for add-ons to detect the presence of HTTPS Everywhere? I suppose it would be easier for us to just use HTTPS in that case to avoid the issue entirely.

In the mean while, I don't see any major problems with removing the rule for api.mywot.com. There's a widget on our website (and many others), which sends requests to api.mywot.com, but it uses HTTPS automatically if the page itself was loaded over HTTPS to avoid warnings about insecure content.

comment:10 Changed 7 years ago by janne

Priority: normalmajor
Status: needs_informationnew

"bumping" this as this is kind of a big deal.

comment:11 Changed 7 years ago by pde

Resolution: fixed
Status: newclosed

Expecting this to be fixed in new releases later today.

Note: See TracTickets for help on using tickets.