On Thu, Apr 5, 2012 at 3:27 PM, Petr Bena 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 proper encycl
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
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 wrote:
>
> 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 Governme
On Tue, Apr 3, 2012 at 11:43 PM, Petr Bena 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)
>
> On Tue, Ap
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 wrote:
> On Tue, Apr 3, 2012 at
On Tue, Apr 3, 2012 at 12:26, Platonides 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 server respo
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 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
https://lists.wikimedia.org/mailman
> 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 https://secure.wikimed
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 fingerp
Ryan Lane wrote:
> On Mon, Apr 2, 2012 at 6:34 PM, Tei 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 user
On Mon, Apr 2, 2012 at 6:34 PM, Tei 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 from these count
On Mon, Apr 2, 2012 at 4:20 PM, 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 serv
On Mon, Apr 2, 2012 at 12:33 PM, Tim Starling 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 ssl
>> termina
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
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 unencryp
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, th
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
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 ve
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.
On Sun, Apr 1, 2012 at 1:14 PM, 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 fronten
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, which
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 th
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 handl
On 1 April 2012 17:00, Bináris wrote:
> 2012/4/1 David Gerard
>> 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.
___
Wikitech-l mailing list
Wikitech-l@list
2012/4/1 David Gerard
> 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
https://lists.wikimedia.org/mailman/listinfo/wiki
On 1 April 2012 14:53, Svip wrote:
> On 1 April 2012 13:59, David Gerard wrote:
>> On 1 April 2012 12:23, Svip 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 monitoring regime would r
On 1 April 2012 13:59, David Gerard wrote:
> On 1 April 2012 12:23, Svip wrote:
>
>> On 1 April 2012 12:06, David Gerard 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
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 S
On 1 April 2012 12:23, Svip wrote:
> On 1 April 2012 12:06, David Gerard 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
On 1 April 2012 12:06, David Gerard 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 this point, if
i
On 1 April 2012 13:01, David Gerard wrote:
> On 1 April 2012 11: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.
>
> The use is that the requests themselves are encrypted, so that the
> on
On 1 April 2012 11: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.
The use is that the requests themselves are encrypted, so that the
only thing logged is that they went to Wikimedia. You di
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 wrote:
> Lots of monitoring going into place:
>
> https://en.wikipedia.org/wiki/Wikipedia:List_of_articles_censored_in_Saud
35 matches
Mail list logo