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.
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.
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.
(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.
Trac: Description: Recent changes to the MyWOT ruleset, released in 3.0development.3, are reportedly causing breakage in the MyWOT Firefox extension. This is an instance of bug #3190 (moved).
The available courses of action are:
Wind back the recent changes to the ruleset, although that will presumably leave mywot.com vulnerable to lots of attacks such as Firesheep-style cookie hijacking that those changes were trying to protect against.
Have the MyWOT extension make all of these requests over HTTPS, in which case it will no longer trip over the HTTPS Everywhere redirects.
Have the MyWOT extension listen for the "https-everywhere-uri-rewrite" event that we sendwhen we rewrite things, and re-start those requests over HTTPS
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.
Trac: Username: graffatcolmingov Owner: pde to graffatcolmingov Status: new to accepted
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.
Trac: Username: janne Status: accepted to needs_information
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.