Issue with https everywhere with Chrome v.29.0.1547.0 dev-m [German Screenshots]

I'm using Chrome Version 29.0.1516.3 dev-m, and often I get "extension error" with https everywhere!

I have done two screenshots, see here:

http://s.gullipics.com/image/q/r/9/8yv9mt-kq1x97-zg76/1d1.png

http://s.gullipics.com/image/7/1/9/8yv9mt-kq1xbi-tgwr/https.png

Trac:
Username: SonnyIgor

added component::https everywhere/https everywhere: chrome owner::zyan priority::very low reporter::SonnyIgor resolution::fixed status::closed type::defect labels

Trac:
Username: SonnyIgor
Priority: major to normal

Trac:
Username: SonnyIgor
Summary: [German] Issue with https everywhere with Chrome v.29.0.1516.3 dev-m to Issue with https everywhere with Chrome v.29.0.1516.3 dev-m [German Screenshots]

Neu_ Warnung: Die Erweiterung konnte die Netzwerkanfrage nicht an https://encrypted.google.com/webhp?source=search_app weiterleiten, da eine andere Erweiterung (Disconnect) sie an https://www.google.com/webhp?source=search_app weitergeleitet hat.

Trac:
Username: SonnyIgor

Is this only happening when Disconnect is also installed?

Trac:
Priority: normal to major
Cc: N/A to dtauerbach

I tested this on Chrome 23.0.1271.64 and found:

• When accessing facebook.com with both Disconnect 5.3.0 and HTTPS Everywhere enabled, the HTTPS Everywhere extension gives "Warning: This extension failed to modify a network request because the modification conflicted with another extension." I ultimately get directed to https://www.facebook.com/.

• When performing the same action with Disconnect disabled, HTTPS Everywhere works fine.

• Other popular sites (Google, Twitter, Tumblr, Flickr, Wordpress) worked fine with both extensions enabled.

(This is Yan, by the way, on a new account.)

Also, I opened an issue at https://github.com/disconnectme/disconnect/issues/117 for this.

[Reposting from https://github.com/disconnectme/disconnect/issues/117.]

This issue is similar to https://github.com/disconnectme/disconnect/issues/100. As in that case, I think HTTPS Everywhere's ruleset should be updated. Since www.google.com supports HTTPS now, I don't think encrypted.google.com is the canonical name for the service anymore.

Trac:
Username: byoogle

http://s.gullipics.com/image/7/2/p/8yv904-kr485g-txq0/ddd.png

Today I got this here, Chrome v.29.0.1541.0 dev-m

greeTz`

Trac:
Username: SonnyIgor

Thanks, byoogle! The GoogleMainSearch.xml ruleset in https-everywhere, which causes searches to go to https://www.google.com rather than https://encrypted.google.com, resolves the conflict when it is enabled. However, this rule has been disabled by default because previously there was a privacy difference between google.com and encrypted.google.com (see https://www.eff.org/deeplinks/2011/10/google-encrypts-more-searches).

Someone here suggests that this behavior has now been removed recently: http://www.reddit.com/r/google/comments/1ddpr0/what_is_difference_between/. If this is confirmed, then the GoogleMainSearch.xml ruleset should be enabled by default.

(I fixed the Facebook and Gmail https-e/disconnect.me conflicts at https://github.com/diracdeltas/https-everywhere/commit/cb3c9743329955d0c156b21baaf7a6fd508ca8c5 and https://github.com/diracdeltas/https-everywhere/commit/18008ed2fd9931084a761c770e49decae6c7a76e.)

http://img0.www.suckmypic.net/img/8/6/zHoqzhgq/Unbenannt.png

Trac:
Username: SonnyIgor
Summary: Issue with https everywhere with Chrome v.29.0.1516.3 dev-m [German Screenshots] to Issue with https everywhere with Chrome v.29.0.1547.0 dev-m [German Screenshots]

Replying to zyan:

Thanks, byoogle! The GoogleMainSearch.xml ruleset in https-everywhere, which causes searches to go to https://www.google.com rather than https://encrypted.google.com, resolves the conflict when it is enabled. However, this rule has been disabled by default because previously there was a privacy difference between google.com and encrypted.google.com (see https://www.eff.org/deeplinks/2011/10/google-encrypts-more-searches).

Note also the different encryption algorithm :

• https://encrypted.google.com

Subject Public Key Algorithm : Elliptic Curve Public Key
Algorithm Parameters : ANSI X9.62 elliptic curve prime256v1 (aka secp256r1, NIST P-256)
Subject's Public Key : Key size: 256 bits
Base point order length: 256 bits
Public value:
04 e1 78 81 1d 38 c3 2f a4 c0 dd e7 0a 9e 12 f3 
d4 7b 12 e8 da 97 aa 6f 4b 9d 89 bb a5 35 b5 5c 
3a 46 5a 27 e5 af 77 06 6d 74 75 f0 e6 ae 45 99 
84 ac 1b fe 64 c9 41 27 f7 b2 55 80 23 a6 9c b6 
d0 

• https://www.google.com

Subject Public Key Algorithm : PKCS #1 RSA Encryption
Subject's Public Key : Modulus (1024 bits):
98 6e 8d 4e cb e2 3d c2 b2 11 8e 76 fd e3 65 7c 
d6 8f 93 9c 4e a7 cd 80 01 4e 38 72 27 ac 33 ed 
dd 6d 50 b6 22 02 f0 7a ea f7 bc 5b 9c 52 b7 64 
5e 25 c6 82 fe 15 43 c1 f0 80 58 4a 9b 75 d9 06 
48 12 6f a4 6f f2 77 f8 6e 8f fb a5 8c c7 f2 48 
92 f3 59 e6 2d 9e 5a 40 9b fd 85 50 4c b7 bb 15 
e9 26 2a 0c e0 e7 fa 73 51 eb 15 54 b2 c0 8d c9 
3a d0 91 e2 99 64 f2 fc 62 38 34 2f af df 5e 01 

Exponent (24 bits):
65537

[Apologies for the sluggish reply. I seem to have been filtering mail from this thread but got pointed back here by Twitter.]

Thanks for making the Facebook and Gmail changes, zyan!

zyan and cypherpunks, switching from www to encrypted would seem to be a mixed bag: no search terms leaked to advertisers (although I haven't verified) and possibly stronger crypto but may be more likely to be blocked by network admins. I lean towards www still as the more usable option. What do you think? (If we go with encrypted, I'd like to make sure the advertiser claim continues to be valid first.)

Trac:
Username: byoogle

This is mostly resolved, except for the question of whether encrypted.google.com or www.google.com is the canonical https url. Marking it as super low priority for now.

Trac:
Status: new to assigned
Priority: major to trivial
Owner: pde to zyan

Actually, I'm closing this as a duplicate of #9459 (moved).

Trac:
Status: assigned to closed
Resolution: N/A to fixed

Has this been deployed to the latest extension?

I'm still seeing issues for facebook.com redirects per comment #9 (closed)

Disconnect 5.7.1 HTTPS Everywhere 2013.08.17

on Chrome

Trac:
Username: sugarkidder

We've resolved the encrypted vs www debate. www should not direct to encrypted anymore.

If there's still issues with Facebook and Disconnect, please open a separate ticket.

closed

mentioned in issue #9459 (moved)

moved to tpo/applications/https-everywhere-chrome#8995 (closed)