Now there're users reporting in village pump that
http://bits.wikimedia.org/ is blocked in China Mainland. Users
visiting http://zh.wikipedia.org/ see unstyled pages without scripts
while https://zh.wikipedia.org/ works fine.
Tell them to use https then? Have them petition their Government
Indeed, I live in europe and bits seems to be very blocked to me :)
there is a problem with connectivity I guess, because I am having this
problem as well most of time, the service is up, but slow, which makes
the load of one page to take minutes
On Thu, Apr 5, 2012 at 8:55 AM, Ryan Lane
Actually bits is a great target for the country which wants to prevent
people from having access, it makes it look as the problem is on side
of capitalist wikipedia, which is broken most of time and thus
people should use the proper encyclopedias of China which are correct
and looking better than
On Thu, Apr 5, 2012 at 3:27 PM, Petr Bena benap...@gmail.com wrote:
Actually bits is a great target for the country which wants to prevent
people from having access, it makes it look as the problem is on side
of capitalist wikipedia, which is broken most of time and thus
people should use the
On Tue, Apr 3, 2012 at 11:43 PM, Petr Bena benap...@gmail.com wrote:
Can we move to the initial discussion regarding http redirect to https
please :-) That page doesn't contain anything interesting anyway...
(Now after saying this I guess that it's gonna have way more visitors
than ever, hehe)
Ryan Lane wrote:
What's https://secure.wikimedia.org?
- Ryan
The server which contains
https://secure.wikimedia.org/keys.html
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Tue, Apr 3, 2012 at 12:26, Platonides platoni...@gmail.com wrote:
Ryan Lane wrote:
What's https://secure.wikimedia.org?
- Ryan
The server which contains
https://secure.wikimedia.org/keys.html
When I access that page, Google Chrome gives this error message:
Failed to load resource: the
Can we move to the initial discussion regarding http redirect to https
please :-) That page doesn't contain anything interesting anyway...
(Now after saying this I guess that it's gonna have way more visitors
than ever, hehe)
On Tue, Apr 3, 2012 at 5:34 PM, Helder helder.w...@gmail.com wrote:
On
That's not what I wanted to say, I wanted to say https may cause
troubles with caching, In fact some caching servers have problems
with https since the header is encrypted as well, so they usually just
forward the encrypted traffic to server. I don't say it's impossible
to cache this, but it's
On 2012-04-02 09:20, Petr Bena wrote:
That's not what I wanted to say, I wanted to say https may cause
troubles with caching, In fact some caching servers have problems
with https since the header is encrypted as well, so they usually just
forward the encrypted traffic to server. I don't say
Perhaps have a black list of countries that are know to break the
privacy of communications, then make https default for logued users in
these countries.
This may help because:
- It only affect a subgroup of users (the ones from these countries)
- It only affect a subgroup of that subgroup,
I believe it would be best if login form was served using http with
check box Disable ssl which would be not checked as default. The
target page of form would be ssl page in case users wouldn't check it.
So that in countries where ssl is problem they could just check it and
proceed using
Serving the login page over http opens login up to MITM attacks by
injecting scripts to swipe passwords or modifying the form to only use
http. So you've already eliminated half the reason we introduced https.
Additionally you cannot control the action= using a checkbox unless you
use JS to
On Mon, Apr 2, 2012 at 12:33 PM, Tim Starling tstarl...@wikimedia.org wrote:
On 02/04/12 06:14, Ryan Lane wrote:
TL;DR: we have no plans for anonymous HTTPS by default, but will
eventually default to HTTPS for logged-in users.
1. It would require an ssl terminator on every frontend cache. The
On Mon, Apr 2, 2012 at 4:20 PM, Petr Bena benap...@gmail.com wrote:
That's not what I wanted to say, I wanted to say https may cause
troubles with caching, In fact some caching servers have problems
with https since the header is encrypted as well, so they usually just
forward the encrypted
On Mon, Apr 2, 2012 at 6:34 PM, Tei oscar.vi...@gmail.com wrote:
Perhaps have a black list of countries that are know to break the
privacy of communications, then make https default for logued users in
these countries.
This may help because:
- It only affect a subgroup of users (the ones
Ryan Lane wrote:
On Mon, Apr 2, 2012 at 6:34 PM, Tei oscar.vi...@gmail.com wrote:
Perhaps have a black list of countries that are know to break the
privacy of communications, then make https default for logued users in
these countries.
This may help because:
- It only affect a subgroup
On 02/04/12 20:34, Ryan Lane wrote:
It's also possible for governments to snoop on HTTPS communications,
by using a private key from a trusted CA to perform a
man-in-the-middle attack. Apparently the government of Iran has done this.
We really should publish our certificate fingerprints. An
Indeed. Detecting a potential MITM is useless if you can't determine if
it's real or not. For instance the switch from RapidSSL to DigiCert
certificate was quite suspicious.
I don't know how to best publicise it, though. I suppose we would list
them somewhere like
On April 2nd, 2012 at 23:35, Ryan Lane wrote:
What's https://secure.wikimedia.org?
Some old experiment. Nothing to see here :-)
--
Antoine hashar Musso
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
I see no point in doing that. Https doesn't support caching well and
is generally slower. There is no use for readers for that.
On Sun, Apr 1, 2012 at 12:06 PM, David Gerard dger...@gmail.com wrote:
Lots of monitoring going into place:
On 1 April 2012 11:55, Petr Bena benap...@gmail.com wrote:
I see no point in doing that. Https doesn't support caching well and
is generally slower. There is no use for readers for that.
The use is that the requests themselves are encrypted, so that the
only thing logged is that they went to
On 1 April 2012 13:01, David Gerard dger...@gmail.com wrote:
On 1 April 2012 11:55, Petr Bena benap...@gmail.com wrote:
I see no point in doing that. Https doesn't support caching well and
is generally slower. There is no use for readers for that.
The use is that the requests themselves are
On 1 April 2012 12:06, David Gerard dger...@gmail.com wrote:
http://www.bbc.co.uk/news/uk-politics-17576745
Also, this article was written on 1 April and is far beyond any
monitoring scheme ever suggested in the Western World. And I am sure
we would have heard about it being mentioned up until
On 1 April 2012 12:23, Svip svi...@gmail.com wrote:
On 1 April 2012 12:06, David Gerard dger...@gmail.com wrote:
http://www.bbc.co.uk/news/uk-politics-17576745
Also, this article was written on 1 April and is far beyond any
monitoring scheme ever suggested in the Western World. And I am
I said there is a little benefit for most of users, of course there
would be some who could find it usefull, however that's no reason to
redirect all users. I use wikipedia a lot, and I don't care if someone
see which pages I open. If someone does care, they should switch to
https themselves.
On
On 1 April 2012 13:59, David Gerard dger...@gmail.com wrote:
On 1 April 2012 12:23, Svip svi...@gmail.com wrote:
On 1 April 2012 12:06, David Gerard dger...@gmail.com wrote:
http://www.bbc.co.uk/news/uk-politics-17576745
Also, this article was written on 1 April and is far beyond any
On 1 April 2012 14:53, Svip wrote:
On 1 April 2012 13:59, David Gerard dger...@gmail.com wrote:
On 1 April 2012 12:23, Svip svi...@gmail.com wrote:
So I would take that article with a grain of salt. Particularly the
statement about 'real time'. That's not even feasible.
That a desired
2012/4/1 David Gerard dger...@gmail.com
http://www.bbc.co.uk/news/uk-politics-17576745
This one may be an April 1 joke, let's wait one day. :-)
--
Bináris
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
On 1 April 2012 17:00, Bináris wikipo...@gmail.com wrote:
2012/4/1 David Gerard dger...@gmail.com
http://www.bbc.co.uk/news/uk-politics-17576745
This one may be an April 1 joke, let's wait one day. :-)
No, it really isn't, sadly.
- d.
___
Le 01/04/12 12:55, Petr Bena wrote:
I see no point in doing that. Https doesn't support caching well and
is generally slower. There is no use for readers for that.
HTTPS has nothing to do with caching, it just transports informations
between the client and the server so they can actually handle
On 01/04/12 18:43, Antoine Musso wrote:
Le 01/04/12 12:55, Petr Bena wrote:
I see no point in doing that. Https doesn't support caching well and
is generally slower. There is no use for readers for that.
HTTPS has nothing to do with caching, it just transports informations
between the
TL;DR: we have no plans for anonymous HTTPS by default, but will
eventually default to HTTPS for logged-in users.
1. It would require an ssl terminator on every frontend cache. The ssl
terminators eat memory, which is also what the frontend caches do.
2. HTTPS dramatically increases latency,
On Sun, Apr 1, 2012 at 1:14 PM, Ryan Lane rlan...@gmail.com wrote:
TL;DR: we have no plans for anonymous HTTPS by default, but will
eventually default to HTTPS for logged-in users.
1. It would require an ssl terminator on every frontend cache. The ssl
terminators eat memory, which is also
On 02/04/12 06:14, Ryan Lane wrote:
TL;DR: we have no plans for anonymous HTTPS by default, but will
eventually default to HTTPS for logged-in users.
1. It would require an ssl terminator on every frontend cache. The ssl
terminators eat memory, which is also what the frontend caches do.
35 matches
Mail list logo
