Re: [Wikitech-l] Hi-DPI site logo fun: patch adding $wgLogoHD option?

[Erwin Dokter]

On 10-03-2015 01:07, Matthew Flaschen wrote:


For comparison, there is also https://gerrit.wikimedia.org/r/#/c/193434/
.  Paladox is proposing to make wgLogo SVG (will need back-compat of
course), with wgLogoPNG as a fallback for browsers that don't support SVG.


Depending on the complexity of the SVG logo, that could result in a 
large file being downloaded. The Wikipedia logo SVG is 162 KB vs. 19 KB 
for the PNG. But if someone wants SVG, by all means


One question though; the logo is now a background image, requiring media 
queries for PNG and a lot of CSS background hacking for SVG. Is there no 
way to do it using a regular  tag, using srcset for PNG, instead?


Regards,
--
Erwin Dokter


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Hi-DPI site logo fun: patch adding $wgLogoHD option?

[Daniel Friesen]

On 2015-03-10 1:56 AM, Erwin Dokter wrote:
> On 10-03-2015 01:07, Matthew Flaschen wrote:
>>
>> For comparison, there is also https://gerrit.wikimedia.org/r/#/c/193434/
>> .  Paladox is proposing to make wgLogo SVG (will need back-compat of
>> course), with wgLogoPNG as a fallback for browsers that don't support
>> SVG.
>
> Depending on the complexity of the SVG logo, that could result in a
> large file being downloaded. The Wikipedia logo SVG is 162 KB vs. 19
> KB for the PNG. But if someone wants SVG, by all means
>
> One question though; the logo is now a background image, requiring
> media queries for PNG and a lot of CSS background hacking for SVG. Is
> there no way to do it using a regular  tag, using srcset for PNG,
> instead?
>
> Regards,
IIRC there are some reasons related to something like overflow or
centering that require the use of a background in the MonoBook/Vector
style skins.
Plus site styles that use CSS to override the logo.

Either way, even if we switched Vector to use an  we'd still have
to solve the issue of using a background-image since there will be other
skins that use a background-image.

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] RFC meeting this week (new time)

[Tim Starling]

In the next RFC meeting we will discuss the following RFCs:

* Service split along presentation vs data manipulation line


* Support for user-specific page lists in core


The meeting time is the same as last week as measured in UTC, which
means that it will be an hour later for people in the US who observe
daylight savings time.

The meeting will be on the IRC channel #wikimedia-office on
chat.freenode.net at the following time:

* UTC: Wednesday 21:00
* US PDT: Wednesday 14:00
* Europe CET: Wednesday 22:00
* Australia AEDT: Thursday 08:00

-- Tim Starling

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] 503 errors in Phabricator

[Andre Klapper]

On Fri, 2015-03-06 at 16:43 -0800, Pine W wrote:
> I figured it out: this error happens whenever I use advanced search with my
> browser cookies disabled. This appears to be a bug in Phabricator.

If there are good and clear steps to reproduce, please file a task in
Phabricator.

Thanks,
andre
-- 
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Tor proxy with blinded tokens

[Chris Steipp]

Jacob Applebaum made another remark about editing Wikipedia via tor this
morning. Since it's been a couple months since the last tor bashing thread,
I wanted to throw out a slightly more modest proposal to see what people
think.

This is getting some interest from a few people:
https://zyan.scripts.mit.edu/blog/rate-limiting-anonymous-accounts/

Which lays out a way for twitter to use an external, trusted identity
provider to verify identifies / throttle requested, and then create an
account in a way that neither twitter or the identity provider can link the
account to the request (as long as you mitigate timing attacks).

What if we turn this around a bit and let the wiki establish identity and
throttle, and open up an editing proxy that is accessible via tor which
consumes the identities?

Basically:
* Established wiki user who wants to use tor makes a blinded request (maybe
public, maybe a private queue for some group with appropriate rights) for a
tor-based account creation token.
* User gets that blinded token signed if they're in good standing, and are
limited to some number (3 total, not less than 6 months since the last
request, or something like that).
* User creates an account on the editing proxy via tor, and gives their
unblinded token to the proxy. The proxy creates an account for them, and
allows edits via OAuth token using that new account.

If the use turns it to be a spammer:
* The anonymous account can be blocked like a normal account. The user is
throttled on how many requests for accounts they can make.
* If the proxy generates to much spam, a steward can revoke the key, and we
all go home to think up the next experiment.

To make this happen, we need:
* a light editing proxy (I already have a couple of those as demo OAuth
apps) which is run by a *non-wmf* entity
* something for normal users to download and run that does the blinding for
them
* work out how to address timing attacks if the volume of requestors is low
enough that we can correlate request to first edit by the proxy.

Anyone interested in helping?

Is this conservative enough for those worried about the flood of tor spam,
while being simple enough that the average editor would be able to
understand and go through the process?
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tor proxy with blinded tokens

[Kevin Wayne Williams]

Chris Steipp schreef op 2015/03/10 om 7:23:

Jacob Applebaum made another remark about editing Wikipedia via tor this
morning. Since it's been a couple months since the last tor bashing thread,
I wanted to throw out a slightly more modest proposal to see what people
think.


The easiest way to prevent a series of Tor bashing threads is to not 
make Tor promoting threads. At least for English Wikipedia, there is no 
reason now or in the conceivable future to permit, much less endorse or 
formalise, editing via Tor.


KWW


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tor proxy with blinded tokens

[Chris Steipp]

On Tue, Mar 10, 2015 at 7:45 AM, Kevin Wayne Williams <
kwwilli...@kwwilliams.com> wrote:

> Chris Steipp schreef op 2015/03/10 om 7:23:
>
>> Jacob Applebaum made another remark about editing Wikipedia via tor this
>> morning. Since it's been a couple months since the last tor bashing
>> thread,
>> I wanted to throw out a slightly more modest proposal to see what people
>> think.
>>
>
> The easiest way to prevent a series of Tor bashing threads is to not make
> Tor promoting threads. At least for English Wikipedia, there is no reason
> now or in the conceivable future to permit, much less endorse or formalise,
> editing via Tor.
>
>
I believe there is a strong reason for it.

Even if you use https for every connection to Wikipedia, traffic analysis
currently makes finding out what you're reading fairly easy. From a risk
perspective, if a user wants to edit Wikipedia on a subject and from a
location that could endanger themselves, I would much prefer they edit via
tor than rely on the WMF to protect their identity. We spend a lot of
effort protecting the privacy of our users, but all it would take is
compromising the right server in our cluster, and correlating which IP is
editing as which user becomes very easy. Promoting the user of Tor lets us
push some of the risk onto the Tor team, who are both experts in this and
have a strong motivation to make it work correctly.

So I think there is both a responsibility and a benefit (to the WMF) in
allowing editing via Tor.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tor proxy with blinded tokens

[Isarra Yos]

On 10/03/15 16:00, Chris Steipp wrote:

On Tue, Mar 10, 2015 at 7:45 AM, Kevin Wayne Williams <
kwwilli...@kwwilliams.com> wrote:


Chris Steipp schreef op 2015/03/10 om 7:23:


Jacob Applebaum made another remark about editing Wikipedia via tor this
morning. Since it's been a couple months since the last tor bashing
thread,
I wanted to throw out a slightly more modest proposal to see what people
think.


The easiest way to prevent a series of Tor bashing threads is to not make
Tor promoting threads. At least for English Wikipedia, there is no reason
now or in the conceivable future to permit, much less endorse or formalise,
editing via Tor.



I believe there is a strong reason for it.

Even if you use https for every connection to Wikipedia, traffic analysis
currently makes finding out what you're reading fairly easy. From a risk
perspective, if a user wants to edit Wikipedia on a subject and from a
location that could endanger themselves, I would much prefer they edit via
tor than rely on the WMF to protect their identity. We spend a lot of
effort protecting the privacy of our users, but all it would take is
compromising the right server in our cluster, and correlating which IP is
editing as which user becomes very easy. Promoting the user of Tor lets us
push some of the risk onto the Tor team, who are both experts in this and
have a strong motivation to make it work correctly.

So I think there is both a responsibility and a benefit (to the WMF) in
allowing editing via Tor.


Aye, even if people don't like something, that doesn't mean it should be 
avoided. For whatever it's worth, personally I think this sounds pretty 
awesome, and even if it doesn't work, it would be worth the risk to try 
it, because if it does the benefit could be enormous.


-I


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Hi-DPI site logo fun: patch adding $wgLogoHD option?

[Brion Vibber]

On Tue, Mar 10, 2015 at 1:56 AM, Erwin Dokter  wrote:

> On 10-03-2015 01:07, Matthew Flaschen wrote:
>
>>
>> For comparison, there is also https://gerrit.wikimedia.org/r/#/c/193434/
>> .  Paladox is proposing to make wgLogo SVG (will need back-compat of
>> course), with wgLogoPNG as a fallback for browsers that don't support SVG.
>>
>
> Depending on the complexity of the SVG logo, that could result in a large
> file being downloaded. The Wikipedia logo SVG is 162 KB vs. 19 KB for the
> PNG. But if someone wants SVG, by all means
>

Yeah, using a direct SVG is currently not ideal for Wikipedia unless
someone manages to make a much more lightweight SVG version of the logo. :(



> One question though; the logo is now a background image, requiring media
> queries for PNG and a lot of CSS background hacking for SVG. Is there no
> way to do it using a regular  tag, using srcset for PNG, instead?
>

Possible yes but it would change the skin layouts more dramatically and may
break customized skins/CSS.

"Fun!" :)

On the plus side, the $wgLogoHD setting would work fine with both the
background-image method currently used and a possible switch to
+srcset in the future if/when we're willing to make bigger skin markup
changes... so we can adopt this first and then do skin cleanup later.

-- brion
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tor proxy with blinded tokens

[Giuseppe Lavagetto]

Hi Chris,

I like the idea in general, in particular the fact that only
"established" editors can ask for the tokens. What I don't get is why
this proxy should be run by someone that is not the WMF, given - I
guess - it would be exposed as a TOR hidden service, which will mask
effectively the user IP from us, and will secure his communication
from snooping by exit node managers, and so on.

I guess the righteously traffic on such a proxy would be so low (as
getting a token is /not/ going to be automated/immediate even for
logged in users) that it could work without using up a lot of
resources.

Cheers,

Giuseppe

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tor proxy with blinded tokens

[Tyler Romeo]

Unless the status quo has changed recently, or there was some cryptographic 
achievement that provides a solution not already provided, I doubt this thread 
is going to make any progress beyond reiteration of the same back-and-forth 
that happens every time this thread pops up.

(Also, I don’t think relying on SMS verification is going to provide much faith 
for users competing against governments to hide their identity.)

-- 
Tyler Romeo
0x405D34A7C86B42DF

signature.asc
Description: Message signed with OpenPGP using AMPGpg
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tor proxy with blinded tokens

[Risker]

A few questions on this:


   - So, this would result in the creation of a new account, correct?  If
   so, most of the security is lost by the enwiki policy of requiring linking
   to one's other accounts, and if the user edited in the same topic area as
   their other account, they're likely to be blocked for socking.  (This is a
   social limitation on the idea, not a technical one.)
   - Why would we permit more than one account?
   - It's not usually experienced editors who seem to have an issue on
   English projects; most of the huffing and puffing about Tor seems to come
   from people who are not currently registered/experienced editors, so the
   primary "market" is a group of people who wouldn't meet the proposed
   criteria.
   - On reading this over carefully, it sounds as though you're proposing
   what is essentially a highly technical IPBE process in which there is even
   less control than the project has now, particularly in the ability to
   address socking and POV/COI editing. Am I missing something?


Risker/Anne

On 10 March 2015 at 13:16, Giuseppe Lavagetto 
wrote:

> Hi Chris,
>
> I like the idea in general, in particular the fact that only
> "established" editors can ask for the tokens. What I don't get is why
> this proxy should be run by someone that is not the WMF, given - I
> guess - it would be exposed as a TOR hidden service, which will mask
> effectively the user IP from us, and will secure his communication
> from snooping by exit node managers, and so on.
>
> I guess the righteously traffic on such a proxy would be so low (as
> getting a token is /not/ going to be automated/immediate even for
> logged in users) that it could work without using up a lot of
> resources.
>
> Cheers,
>
> Giuseppe
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tor proxy with blinded tokens

[Chris Steipp]

On Tue, Mar 10, 2015 at 10:16 AM, Giuseppe Lavagetto <
glavage...@wikimedia.org> wrote:

> Hi Chris,
>
> I like the idea in general, in particular the fact that only
> "established" editors can ask for the tokens. What I don't get is why
> this proxy should be run by someone that is not the WMF, given - I
>

It's due to a known issue with the scheme that Yan suggested-- if the same
person knows both the blinded and unblinded signatures, they can brute
force the blinding and correlate the identities. Splitting the two is
needed to prevent that.


> guess - it would be exposed as a TOR hidden service, which will mask
> effectively the user IP from us, and will secure his communication
> from snooping by exit node managers, and so on.
>
> I guess the righteously traffic on such a proxy would be so low (as
> getting a token is /not/ going to be automated/immediate even for
> logged in users) that it could work without using up a lot of
> resources.
>
> Cheers,
>
> Giuseppe
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tor proxy with blinded tokens

[Chris Steipp]

On Tue, Mar 10, 2015 at 10:39 AM, Risker  wrote:

> A few questions on this:
>
>
>- So, this would result in the creation of a new account, correct?  If
>so, most of the security is lost by the enwiki policy of requiring
> linking
>to one's other accounts, and if the user edited in the same topic area
> as
>their other account, they're likely to be blocked for socking.  (This
> is a
>social limitation on the idea, not a technical one.)
>

Registering a pseudonym through this process implies that you are an
existing editor (we could even limit the process to only one pseudonym per
existing account, so you know there's a 1-1 mapping), just not linking to
which one you are. Do you think enwiki be open to considering that?


>- Why would we permit more than one account?
>

I was originally thinking that if something happened (forgotten password,
etc.), you could start over. But not a hard requirement.


>- It's not usually experienced editors who seem to have an issue on
>English projects; most of the huffing and puffing about Tor seems to
> come
>from people who are not currently registered/experienced editors, so the
>primary "market" is a group of people who wouldn't meet the proposed
>criteria.


There may not be enough intersection between users who we have some trust
in and those who want to edit via Tor. I'm hopeful that we can define
"established" to be some group that is large enough that it will include
productive editors who also should use Tor, but small enough to preclude
spammers. I'm assuming if we start with some guideline, then we can adjust
up (if there's too much spam) or down (if there aren't enough users)
depending on the results.


>

   - On reading this over carefully, it sounds as though you're proposing
>what is essentially a highly technical IPBE process in which there is
> even
>less control than the project has now, particularly in the ability to
>address socking and POV/COI editing. Am I missing something?
>

In a way it is, but there are couple advantages over IPBE as I see it:
* Neither the WMF nor checkusers can correlate the identities, whereas with
IPBE, it's possible that a checkuser can still see the IP that created the
account requesting the IPBE. This is less control, but also less risk if
the wmf/checkuser is coerced into revealing that information.
* Hopefully it will be a less manual process, since the only manual (which
could be automated if the right heuristics were found) step is confirming
that the requesting user is "established". There's no further rights that
have to be granted and maintained.

It also give slightly more control in that:
* We're not giving out the IPBE right
* The whole system can be blocked (hopefully temporarily) with a single
block or revoking the OAuth key, if there is ever a sudden flood of spam

Admittedly, we could do all of this (except making the identities
unlinkable) by having an edit-via-tor right that is different from IPBE,
but the unlikability I think is important for our users.


>
> Risker/Anne
>
> On 10 March 2015 at 13:16, Giuseppe Lavagetto 
> wrote:
>
> > Hi Chris,
> >
> > I like the idea in general, in particular the fact that only
> > "established" editors can ask for the tokens. What I don't get is why
> > this proxy should be run by someone that is not the WMF, given - I
> > guess - it would be exposed as a TOR hidden service, which will mask
> > effectively the user IP from us, and will secure his communication
> > from snooping by exit node managers, and so on.
> >
> > I guess the righteously traffic on such a proxy would be so low (as
> > getting a token is /not/ going to be automated/immediate even for
> > logged in users) that it could work without using up a lot of
> > resources.
> >
> > Cheers,
> >
> > Giuseppe
> >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tor proxy with blinded tokens

[bawolff]

On Tue, Mar 10, 2015 at 11:23 AM, Chris Steipp  wrote:
> Jacob Applebaum made another remark about editing Wikipedia via tor this
> morning. Since it's been a couple months since the last tor bashing thread,
> I wanted to throw out a slightly more modest proposal to see what people
> think.
[..]

If enwiki doesn't like this, lets start with other wikis. We run
something like 700 wikis, I'm sure at least some of them would like
the idea. Having some other wiki then enwiki go first and demonstrate
that this is workable without vandals taking over may help alleviate
enwiki fears.

--bawolff

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tor proxy with blinded tokens

[Risker]

Thanks for your responses, Chris. Regardless of what processes are
proposed, I suspect that the strongest objections will be socially based
rather than technically based.  Bawolff has a valid point, that success on
a smaller wiki may have an effect on the social perception of the use of
Tor on enwiki - but if it is started on another wiki, please ensure that
there is actual community agreement and that there are sufficient
administrators who are willing and able to promptly address any problems.
We may have 700 wikis, but really only about 50-60 of them have sufficient
daily activity and editorial community size to be able to manage any
problems that might arise from this.

To my experience, the majority of experienced editors who are asking for
IPBE or something similar tend to be editing through VPNs that are
hard-blocked for various reasons (most commonly spamming and/or heavy-duty
vandalism - and if it's spamming, it's usually blocked at the global
level).  There are some exceptions - particularly related to users working
from countries where there are entirely valid security concerns (we could
probably all recite the list). And IPBE does permit editing through Tor
now.  Whether continuing with IPBE or providing an alternative, the user
would still have to persuade the same administrators/community members of
the legitimacy of their request.

I cannot speak for the entire enwiki community  (let alone any other
community) about whether or not there would be acceptance for the idea of a
user having two unlinked accounts, one "regular" account and one "Tor" one
- given my role as a Checkuser I'm exposed to a much higher frequency of
socking complaints than most community members - but given it's been darn
hard to keep the community from flat-out banning multiple unlined accounts,
I have my doubts it will be greeted with open arms, even if it "works" on
other wikis. (Pretty much the only exception that has received support is
"editing in a high risk topic area", so there *may* be some support).
Unfortunately, there's been plenty of history on enwiki of experienced
users having multiple accounts that were used inappropriately, including
administrator accounts, so that raises the bar even higher.

AlsoI'm a little unclear about something. If a "Tor-enabled" account
creates new accounts, will those accounts be able to edit through Tor,
too?

Risker/Anne

On 10 March 2015 at 14:33, Chris Steipp  wrote:

> On Tue, Mar 10, 2015 at 10:39 AM, Risker  wrote:
>
> > A few questions on this:
> >
> >
> >- So, this would result in the creation of a new account, correct?  If
> >so, most of the security is lost by the enwiki policy of requiring
> > linking
> >to one's other accounts, and if the user edited in the same topic area
> > as
> >their other account, they're likely to be blocked for socking.  (This
> > is a
> >social limitation on the idea, not a technical one.)
> >
>
> Registering a pseudonym through this process implies that you are an
> existing editor (we could even limit the process to only one pseudonym per
> existing account, so you know there's a 1-1 mapping), just not linking to
> which one you are. Do you think enwiki be open to considering that?
>
>
> >- Why would we permit more than one account?
> >
>
> I was originally thinking that if something happened (forgotten password,
> etc.), you could start over. But not a hard requirement.
>
>
> >- It's not usually experienced editors who seem to have an issue on
> >English projects; most of the huffing and puffing about Tor seems to
> > come
> >from people who are not currently registered/experienced editors, so
> the
> >primary "market" is a group of people who wouldn't meet the proposed
> >criteria.
>
>
> There may not be enough intersection between users who we have some trust
> in and those who want to edit via Tor. I'm hopeful that we can define
> "established" to be some group that is large enough that it will include
> productive editors who also should use Tor, but small enough to preclude
> spammers. I'm assuming if we start with some guideline, then we can adjust
> up (if there's too much spam) or down (if there aren't enough users)
> depending on the results.
>
>
> >
>
>- On reading this over carefully, it sounds as though you're proposing
> >what is essentially a highly technical IPBE process in which there is
> > even
> >less control than the project has now, particularly in the ability to
> >address socking and POV/COI editing. Am I missing something?
> >
>
> In a way it is, but there are couple advantages over IPBE as I see it:
> * Neither the WMF nor checkusers can correlate the identities, whereas with
> IPBE, it's possible that a checkuser can still see the IP that created the
> account requesting the IPBE. This is less control, but also less risk if
> the wmf/checkuser is coerced into revealing that information.
> * Hopefully it will be a less manual process, since the only 

[Wikitech-l] Reminder: VisualEditor weekly triage meetings – 2015-03-11

[James Forrester]

As a reminder, this week's VisualEditor triage meeting will be at
​19

:00 UTC

​
(
12
:00 PDT) – that's in approximately 24 hours' time (note the off-by-one-hour
state because of Summer Time in the US).

Joining instructions are on mw:Talk:VisualEditor/Portal

​; from this week onwards we're trying it via Google Hangouts, per request.
Hope to see many of you there.

J.
-- 
James D. Forrester
Product Manager, Editing
Wikimedia Foundation, Inc.

jforres...@wikimedia.org | @jdforrester
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Taking ContentHandler the rest of the way (mediawiki without wikitext)

[C. Scott Ananian]

It should be possible to create an HTML-only wiki, with Visual Editor
as the primary editing mechanism and no wikitext parsing for typical
views and edits. Advanced users could install Parsoid to round-trip
from the HTML DOM to wikitext for source editing, translating from
wikitext back to the HTML DOM for database storage and display.
(Eventually we may similarly allow round-trip "source" editing in
other formats, such as Markdown or a new and refreshed "wikitext 2.0"
-- but let's limit discussion to VE/HTML for now.)

So what are the architectural improvements needed?

* ContentHandler[1] laid the groundwork for non-wikitext page content.
Building on it, an HTML-format "Mediawiki DOM" ContentHandler must be
written, using DOM methods to separate sections and extract redirects.
The "Mediawiki DOM" Content implementation must extract secondary data
(links, categories, etc) directly from the DOM. (Alternatively, page
metadata should be stored in a separate JSON "page metadata"
attachment and custom editors provided.)

* An HTML-based DifferenceEngine[2] must be implemented to allow
visualizing changes without resorting to wikitext.

* VisualEditor must be tweaked to fetch Mediawiki DOM directly,
bypassing Parsoid; ditto on save.  (I believe RESTbase is working
toward this already.)

* System messages must be associated with a content model, to allow
HTML-formatted system messages. Localization workflows need to
accommodate non-wikitext messages. Most messages do not need/should
not have formatting and should probably shift to a "plaintext" content
model.

* The Sanitizer[3] will need improvement so that it is appropriate to
run directly on Mediawiki DOM.

* Compatibility thunks are also desirable. These would use Parsoid
(in-process?) to dynamically generate wikitext from the Mediawiki DOM
to allow some legacy extensions and APIs to function.

What other areas would present roadblocks to an HTML-only wiki (or,
more generally, to a non-wikitext mediawiki)? I'm hoping the mediawiki
hackers on this list can educate me on other areas that might be
problematic (or other place where useful groundwork has already been
laid).
  --scott

ps. I submitted a proposal very similar to this to wikimania 2015:
https://wikimania2015.wikimedia.org/wiki/Submissions/Mediawiki_without_wikitext
Help me improve my (proposed future) talk!

[1] https://www.mediawiki.org/wiki/Manual:ContentHandler
[2] 
https://git.wikimedia.org/blob/mediawiki%2Fcore.git/master/includes%2Fdiff%2FDifferenceEngine.php
[3] 
https://git.wikimedia.org/blob/mediawiki%2Fcore.git/master/includes%2FSanitizer.php

-- 
(http://cscott.net)

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tor proxy with blinded tokens

[Chris Steipp]

On Mar 10, 2015 12:05 PM, "Risker"  wrote:
>
> Thanks for your responses, Chris. Regardless of what processes are
> proposed, I suspect that the strongest objections will be socially based
> rather than technically based.  Bawolff has a valid point, that success on
> a smaller wiki may have an effect on the social perception of the use of
> Tor on enwiki - but if it is started on another wiki, please ensure that
> there is actual community agreement and that there are sufficient
> administrators who are willing and able to promptly address any problems.
> We may have 700 wikis, but really only about 50-60 of them have sufficient
> daily activity and editorial community size to be able to manage any
> problems that might arise from this.
>
> To my experience, the majority of experienced editors who are asking for
> IPBE or something similar tend to be editing through VPNs that are
> hard-blocked for various reasons (most commonly spamming and/or heavy-duty
> vandalism - and if it's spamming, it's usually blocked at the global
> level).  There are some exceptions - particularly related to users working
> from countries where there are entirely valid security concerns (we could
> probably all recite the list). And IPBE does permit editing through Tor
> now.  Whether continuing with IPBE or providing an alternative, the user
> would still have to persuade the same administrators/community members of
> the legitimacy of their request.
>
> I cannot speak for the entire enwiki community  (let alone any other
> community) about whether or not there would be acceptance for the idea of
a
> user having two unlinked accounts, one "regular" account and one "Tor" one
> - given my role as a Checkuser I'm exposed to a much higher frequency of
> socking complaints than most community members - but given it's been darn
> hard to keep the community from flat-out banning multiple unlined
accounts,
> I have my doubts it will be greeted with open arms, even if it "works" on
> other wikis. (Pretty much the only exception that has received support is
> "editing in a high risk topic area", so there *may* be some support).
> Unfortunately, there's been plenty of history on enwiki of experienced
> users having multiple accounts that were used inappropriately, including
> administrator accounts, so that raises the bar even higher.
>
> AlsoI'm a little unclear about something. If a "Tor-enabled" account
> creates new accounts, will those accounts be able to edit through Tor,
> too?

The account creation would come from the proxy, so the wiki would have to
trust that the proxy is only handing out accounts to users who have been

>
> Risker/Anne
>
> On 10 March 2015 at 14:33, Chris Steipp  wrote:
>
> > On Tue, Mar 10, 2015 at 10:39 AM, Risker  wrote:
> >
> > > A few questions on this:
> > >
> > >
> > >- So, this would result in the creation of a new account,
correct?  If
> > >so, most of the security is lost by the enwiki policy of requiring
> > > linking
> > >to one's other accounts, and if the user edited in the same topic
area
> > > as
> > >their other account, they're likely to be blocked for socking.
(This
> > > is a
> > >social limitation on the idea, not a technical one.)
> > >
> >
> > Registering a pseudonym through this process implies that you are an
> > existing editor (we could even limit the process to only one pseudonym
per
> > existing account, so you know there's a 1-1 mapping), just not linking
to
> > which one you are. Do you think enwiki be open to considering that?
> >
> >
> > >- Why would we permit more than one account?
> > >
> >
> > I was originally thinking that if something happened (forgotten
password,
> > etc.), you could start over. But not a hard requirement.
> >
> >
> > >- It's not usually experienced editors who seem to have an issue on
> > >English projects; most of the huffing and puffing about Tor seems
to
> > > come
> > >from people who are not currently registered/experienced editors,
so
> > the
> > >primary "market" is a group of people who wouldn't meet the
proposed
> > >criteria.
> >
> >
> > There may not be enough intersection between users who we have some
trust
> > in and those who want to edit via Tor. I'm hopeful that we can define
> > "established" to be some group that is large enough that it will include
> > productive editors who also should use Tor, but small enough to preclude
> > spammers. I'm assuming if we start with some guideline, then we can
adjust
> > up (if there's too much spam) or down (if there aren't enough users)
> > depending on the results.
> >
> >
> > >
> >
> >- On reading this over carefully, it sounds as though you're
proposing
> > >what is essentially a highly technical IPBE process in which there
is
> > > even
> > >less control than the project has now, particularly in the ability
to
> > >address socking and POV/COI editing. Am I missing something?
> > >
> >
> > In a way it is, but there are couple advant

Re: [Wikitech-l] Tor proxy with blinded tokens

[Risker]

>
> 
> >
> > AlsoI'm a little unclear about something. If a "Tor-enabled" account
> > creates new accounts, will those accounts be able to edit through Tor,
> > too?
>
> The account creation would come from the proxy, so the wiki would have to
> trust that the proxy is only handing out accounts to users who have been
>
> Sorry Chris, I seem to have been unclear.  For the purpose of responding
to this, let's call the account created by the third party the "Special
Account".  What I wanted to verify was whether or not child accounts
created by the Special Account would also be conferred with the privileges
of the Special Account (i.e., the ability to edit through Tor) or if they
would be treated as any other newly created account.  Remember that all
autoconfirmed accounts can create child accounts (I believe on enwiki it is
throttled to 5 accounts per day, absent special permissions).

To summarize the proposal as I understand it:

   - In addition to the existing process for experienced editors to obtain
   IPBE, which may vary from project to project, they could also request the
   creation of a new account, unlinked to their existing accounts, that will
   have the ability to edit viaTor.
   - The community will develop the process for approving which accounts
   will have this ability.  When granted, the user will be given a token
   - The user will take the token to a third party which will create for
   them a new account that has the requisite permissions to edit via Tor
   - The new, unlinked account will edit Wikipedia in the same manner as a
   regular user, subject to the same policies
   - There will be a process by which the token can be "broken" or removed
   from the account (still to be determined)

In other words, the difference between the existing process and the
proposed process is the addition of the third party and the deliberate
separation of the two accounts.  (I'm trying to put this into plain
language so that it can be explained to a broader audience on a project.)

Do I have this right?

Risker/Anne
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Wikimedia REST content API is now available in beta

[Gabriel Wicke]

Hello all,

I am happy to announce the beta release of the Wikimedia REST Content API
at

https://rest.wikimedia.org/

Each domain has its own API documentation, which is auto-generated from
Swagger API specs. For example, here is the link for the English Wikipedia:

https://rest.wikimedia.org/en.wikipedia.org/v1/?doc

At present, this API provides convenient and low-latency access to article
HTML, page metadata and content conversions between HTML and wikitext.
After extensive testing we are confident that these endpoints are ready for
production use, but have marked them as 'unstable' until we have also
validated this with production users. You can start writing applications
that depend on it now, if you aren't afraid of possible minor changes
before transitioning to 'stable' status. For the definition of the terms
‘stable’ and ‘unstable’ see https://www.mediawiki.org/wiki/API_versioning .

While general and not specific to VisualEditor, the selection of endpoints
reflects this release's focus on speeding up VisualEditor. By storing
private Parsoid round-trip information separately, we were able to reduce
the HTML size by about 40%. This in turn reduces network transfer and
processing times, which will make loading and saving with VisualEditor
faster. We are also switching from a cache to actual storage, which will
eliminate slow VisualEditor loads caused by cache misses. Other users of
Parsoid HTML like Flow, HTML dumps, the OCG PDF renderer or Content
translation will benefit similarly.

But, we are not done yet. In the medium term, we plan to further reduce the
HTML size by separating out all read-write metadata. This should allow us
to use Parsoid HTML with its semantic markup
 directly for
both views and editing without increasing the HTML size over the current
output. Combined with performance work in VisualEditor, this has the
potential to make switching to visual editing instantaneous and free of any
scrolling.

We are also investigating a sub-page-level edit API for micro-contributions
and very fast VisualEditor saves. HTML saves don't necessarily have to wait
for the page to re-render from wikitext, which means that we can
potentially make them faster than wikitext saves. For this to work we'll
need to minimize network transfer and processing time on both client and
server.

More generally, this API is intended to be the beginning of a multi-purpose
content API. Its implementation (RESTBase
) is driven by a declarative
Swagger API specification, which helps to make it straightforward to extend
the API with new entry points. The same API spec is also used to
auto-generate the aforementioned sandbox environment, complete with handy
"try it" buttons. So, please give it a try and let us know what you think!

This API is currently unmetered; we recommend that users not perform more
than 200 requests per second and may implement limitations if necessary.

I also want to use this opportunity to thank all contributors who made this
possible:

- Marko Obrovac, Eric Evans, James Douglas and Hardik Juneja on the
Services team worked hard to build RESTBase, and to make it as extensible
and clean as it is now.

- Filippo Giunchedi, Alex Kosiaris, Andrew Otto, Faidon Liambotis, Rob
Halsell and Mark Bergsma helped to procure and set up the Cassandra storage
cluster backing this API.

- The Parsoid team with Subbu Sastry, Arlo Breault, C. Scott Ananian and
Marc Ordinas i Llopis is solving the extremely difficult task of converting
between wikitext and HTML, and built a new API that lets us retrieve and
pass in metadata separately.

- On the MediaWiki core team, Brad Jorsch quickly created a minimal
authorization API that will let us support private wikis, and Aaron Schulz,
Alex Monk and Ori Livneh built and extended the VirtualRestService that
lets VisualEditor and MediaWiki in general easily access external services.

We welcome your feedback here: https://www.mediawiki.org/wiki/Talk:RESTBase
- and in Phabricator

.

Sincerely --

Gabriel Wicke

Principal Software Engineer, Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] Wikimedia REST content API is now available in beta

[James Forrester]

On 10 March 2015 at 15:23, Gabriel Wicke  wrote:

> Hello all,
>
> I am happy to announce the beta release of the Wikimedia REST Content API
> at
>
> https://rest.wikimedia.org/
>
> Each domain has its own API documentation, which is auto-generated from
> Swagger API specs. For example, here is the link for the English Wikipedia:
>
> https://rest.wikimedia.org/en.wikipedia.org/v1/?doc
>

​Congratulations, Services team
​, and all those who've helped you get to this point​
. This is a huge milestone and I'm so happy we've reached it. It'll be
hugely valuable for Mobile Web, Mobile Apps, VisualEditor and dozens​ of
other projects. Thank you!


​Yours,
-- 
James D. Forrester
Product Manager, Editing
Wikimedia Foundation, Inc.

jforres...@wikimedia.org | @jdforrester
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tor proxy with blinded tokens

[Kevin Wayne Williams]

Chris Steipp schreef op 2015/03/10 om 9:00:

On Tue, Mar 10, 2015 at 7:45 AM, Kevin Wayne Williams <
kwwilli...@kwwilliams.com> wrote:


Chris Steipp schreef op 2015/03/10 om 7:23:


Jacob Applebaum made another remark about editing Wikipedia via tor this
morning. Since it's been a couple months since the last tor bashing
thread,
I wanted to throw out a slightly more modest proposal to see what people
think.



The easiest way to prevent a series of Tor bashing threads is to not make
Tor promoting threads. At least for English Wikipedia, there is no reason
now or in the conceivable future to permit, much less endorse or formalise,
editing via Tor.



I believe there is a strong reason for it.

Even if you use https for every connection to Wikipedia, traffic analysis
currently makes finding out what you're reading fairly easy. From a risk
perspective, if a user wants to edit Wikipedia on a subject and from a
location that could endanger themselves, I would much prefer they edit via
tor than rely on the WMF to protect their identity.


Wikipedia isn't worth endangering oneself over, and we shouldn't 
encourage the delusion that any technical measure will change that.

KWW


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tor proxy with blinded tokens

[Chris Steipp]

On Tue, Mar 10, 2015 at 2:58 PM, Risker  wrote:

> >
> > 
> > >
> > > AlsoI'm a little unclear about something. If a "Tor-enabled"
> account
> > > creates new accounts, will those accounts be able to edit through Tor,
> > > too?
> >
> > The account creation would come from the proxy, so the wiki would have to
> > trust that the proxy is only handing out accounts to users who have been
>
>
Sorry about that, meant to hit save instead of send.

What I was going to say is that no, there shouldn't be a way for the
"Special Account" to even create child accounts through Tor. We can limit
that via OAuth, and we'll also have to trust the proxy to behave correctly.
If it looked like the "Special Accounts" were creating child accounts
through the proxy, I think that would be a reason to block the proxy.

I think we had different ideas about how the user would edit, which I've
addressed below. Happy to clarify if that doesn't make sense.


> > Sorry Chris, I seem to have been unclear.  For the purpose of responding
> to this, let's call the account created by the third party the "Special
> Account".  What I wanted to verify was whether or not child accounts
> created by the Special Account would also be conferred with the privileges
> of the Special Account (i.e., the ability to edit through Tor) or if they
> would be treated as any other newly created account.  Remember that all
> autoconfirmed accounts can create child accounts (I believe on enwiki it is
> throttled to 5 accounts per day, absent special permissions).
>
> To summarize the proposal as I understand it:
>
>- In addition to the existing process for experienced editors to obtain
>IPBE, which may vary from project to project, they could also request
> the
>creation of a new account, unlinked to their existing accounts, that
> will
>have the ability to edit viaTor.
>- The community will develop the process for approving which accounts
>will have this ability.  When granted, the user will be given a token
>- The user will take the token to a third party which will create for
>them a new account that has the requisite permissions to edit via Tor

   - The new, unlinked account will edit Wikipedia in the same manner as a
>regular user, subject to the same policies
>- There will be a process by which the token can be "broken" or removed
>from the account (still to be determined)
>

I'm actually envisioning that the user would edit through the third party's
proxy (via OAuth, linked to the new, "Special Account"), so no special
permissions are needed by the "Special Account", and a standard block on
that username can prevent them from editing. Additionally, revoking the
OAuth token of the proxy itself would stop all editing by this process, so
there's a quick way to "pull the plug" if it looks like the edits are
predominantly unproductive.


> In other words, the difference between the existing process and the
> proposed process is the addition of the third party and the deliberate
> separation of the two accounts.  (I'm trying to put this into plain
> language so that it can be explained to a broader audience on a project.)
>
> Do I have this right?
>
>
Almost! The accounts are deliberately separated so they can't be linked,
like you said. My proposal goes a little further by also restricting what
the accounts can do via this third-party proxy. For example, the proxy
could run each edit through the abuse filters, or another spam-scoring
service, before it even submits the edit, if we want to try and push spam
detection further up stream. It could have it's own rate limits, and refuse
to service users it feels might be be seen as spammers and could get the
whole system shut down.

If the user tries to edit using the "Special Account" directly via Tor
(skipping the proxy), Torblock will correctly prevent them from doing
anything, just like it currently does.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tor proxy with blinded tokens

[Chris Steipp]

On Tue, Mar 10, 2015 at 5:06 PM, Kevin Wayne Williams <
kwwilli...@kwwilliams.com> wrote:

> Wikipedia isn't worth endangering oneself over, and we shouldn't encourage
> the delusion that any technical measure will change that.


How do you know today what topics are going to endanger you next week?
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] Wikimedia REST content API is now available in beta

[Arthur Richards]

Wow! Awesome to see this come to life :D Congratulations on this milestone.

On Tue, Mar 10, 2015 at 3:29 PM, James Forrester 
wrote:

> On 10 March 2015 at 15:23, Gabriel Wicke  wrote:
>
> > Hello all,
> >
> > I am happy to announce the beta release of the Wikimedia REST Content API
> > at
> >
> > https://rest.wikimedia.org/
> >
> > Each domain has its own API documentation, which is auto-generated from
> > Swagger API specs. For example, here is the link for the English
> Wikipedia:
> >
> > https://rest.wikimedia.org/en.wikipedia.org/v1/?doc
> >
>
> ​Congratulations, Services team
> ​, and all those who've helped you get to this point​
> . This is a huge milestone and I'm so happy we've reached it. It'll be
> hugely valuable for Mobile Web, Mobile Apps, VisualEditor and dozens​ of
> other projects. Thank you!
>
>
> ​Yours,
> --
> James D. Forrester
> Product Manager, Editing
> Wikimedia Foundation, Inc.
>
> jforres...@wikimedia.org | @jdforrester
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] Wikimedia REST content API is now available in beta

[Erik Moeller]

On Tue, Mar 10, 2015 at 3:29 PM, James Forrester
 wrote:
> Congratulations, Services team, and all those who've helped you get to this 
> point.
> This is a huge milestone and I'm so happy we've reached it. It'll be
> hugely valuable for Mobile Web, Mobile Apps, VisualEditor and dozens of
> other projects. Thank you!

Well said. Very excited about the possibilities -- and great to see
Swagger in action, as well. :)
-- 
Erik Möller
VP of Product & Strategy, Wikimedia Foundation

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tor proxy with blinded tokens

[Risker]

Thanks, Chris.  But if the account is obviously not a normal account, I'd
suspect that this special  kind of user account would quickly become very
obvious to those who snoop and would actually increase the level of
scrutiny on the account, both internally and externally. I'm not really all
that sure it's an overall improvement in safety.

Risker/Anne

On 10 March 2015 at 20:40, Chris Steipp  wrote:

> On Tue, Mar 10, 2015 at 2:58 PM, Risker  wrote:
>
> > >
> > > 
> > > >
> > > > AlsoI'm a little unclear about something. If a "Tor-enabled"
> > account
> > > > creates new accounts, will those accounts be able to edit through
> Tor,
> > > > too?
> > >
> > > The account creation would come from the proxy, so the wiki would have
> to
> > > trust that the proxy is only handing out accounts to users who have
> been
> >
> >
> Sorry about that, meant to hit save instead of send.
>
> What I was going to say is that no, there shouldn't be a way for the
> "Special Account" to even create child accounts through Tor. We can limit
> that via OAuth, and we'll also have to trust the proxy to behave correctly.
> If it looked like the "Special Accounts" were creating child accounts
> through the proxy, I think that would be a reason to block the proxy.
>
> I think we had different ideas about how the user would edit, which I've
> addressed below. Happy to clarify if that doesn't make sense.
>
>
> > > Sorry Chris, I seem to have been unclear.  For the purpose of
> responding
> > to this, let's call the account created by the third party the "Special
> > Account".  What I wanted to verify was whether or not child accounts
> > created by the Special Account would also be conferred with the
> privileges
> > of the Special Account (i.e., the ability to edit through Tor) or if they
> > would be treated as any other newly created account.  Remember that all
> > autoconfirmed accounts can create child accounts (I believe on enwiki it
> is
> > throttled to 5 accounts per day, absent special permissions).
> >
> > To summarize the proposal as I understand it:
> >
> >- In addition to the existing process for experienced editors to
> obtain
> >IPBE, which may vary from project to project, they could also request
> > the
> >creation of a new account, unlinked to their existing accounts, that
> > will
> >have the ability to edit viaTor.
> >- The community will develop the process for approving which accounts
> >will have this ability.  When granted, the user will be given a token
> >- The user will take the token to a third party which will create for
> >them a new account that has the requisite permissions to edit via Tor
>
>- The new, unlinked account will edit Wikipedia in the same manner as a
> >regular user, subject to the same policies
> >- There will be a process by which the token can be "broken" or
> removed
> >from the account (still to be determined)
> >
>
> I'm actually envisioning that the user would edit through the third party's
> proxy (via OAuth, linked to the new, "Special Account"), so no special
> permissions are needed by the "Special Account", and a standard block on
> that username can prevent them from editing. Additionally, revoking the
> OAuth token of the proxy itself would stop all editing by this process, so
> there's a quick way to "pull the plug" if it looks like the edits are
> predominantly unproductive.
>
>
> > In other words, the difference between the existing process and the
> > proposed process is the addition of the third party and the deliberate
> > separation of the two accounts.  (I'm trying to put this into plain
> > language so that it can be explained to a broader audience on a project.)
> >
> > Do I have this right?
> >
> >
> Almost! The accounts are deliberately separated so they can't be linked,
> like you said. My proposal goes a little further by also restricting what
> the accounts can do via this third-party proxy. For example, the proxy
> could run each edit through the abuse filters, or another spam-scoring
> service, before it even submits the edit, if we want to try and push spam
> detection further up stream. It could have it's own rate limits, and refuse
> to service users it feels might be be seen as spammers and could get the
> whole system shut down.
>
> If the user tries to edit using the "Special Account" directly via Tor
> (skipping the proxy), Torblock will correctly prevent them from doing
> anything, just like it currently does.
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tor proxy with blinded tokens

[Brian Wolff]

On Mar 10, 2015 10:21 PM, "Risker"  wrote:
>
> Thanks, Chris.  But if the account is obviously not a normal account, I'd
> suspect that this special  kind of user account would quickly become very
> obvious to those who snoop and would actually increase the level of
> scrutiny on the account, both internally and externally. I'm not really
all
> that sure it's an overall improvement in safety.
>
> Risker/Anne
>

That's going to depend on your threat model

If secret agents are watching you through binoculurs then nothing is going
to save you.

If gov wants to track down all users who are "suspicious" (not very far
fetched in the current political climate), then yes using tor may make you
stand out. This is probably the case already for anyone using tor at all
(esp. If not using a bridge if i understand things correctly)

If your use case is you want to upload pictures of a pro democracy protest
in some fascist country where the pictures are likely to get you arrested,
and fascist gov has a list of all ips accessing wikimedia servers for the
specific time period, then tor might help you (emphasis on the maybe. If
you are the only person in the country at that time using tor and they are
able to detect your using tor then your dead. or if you are in the picture,
or the rest of a long list of operational security details the paranoid
have to deal with)

>re kevin's comment about worth the risk
Whether or not its worth the risk is the perogative of the person taking
the risk. Maybe they even consider whatever they are doing important enough
that they would still do it even without the protection of tor if tor is
not an option. Not that long ago thousands of people were taking "risks" by
buying illicit drugs on the silk road using tor for protection. I find it
easy to imagine that many people in repressive places would consider
spreading information a much more neccesary risk than what silk road
patrons thought was an acceptable risk in using that service.

Or perhaps tor users have nothing to hide and simply feel that what they do
online is nobody's bussiness. Or maybe they want to increase the
annonyminity pool for those who really do have legitament reason to hide.

--bawolff
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Event organised on Marathi Wikipedia (photothon and edit-a-thon)

[Santosh Shingare]

Dear All,

On occasion of "Marathi Bhasha Divas", we have organised Photothon on
Marathi Wikipedia from February 27 to March 6 , We have received more than
7,000 photographs through web and Android app.

We hosted an event called edit-a-thon during the celebration of womens day,
there were around  17 women members of Marathi Wikipedia who took part in
this event, wherein they were given a presentation on categorization of
images collected in Photothon and small description on 'How to write
Articles in Wikipedia'. Around 6,000 photographs were categorized by these
members, event conducted by Selva Rani.

Thank you

1)
https://mr.wikipedia.org/wiki/%E0%A4%9A%E0%A4%BF%E0%A4%A4%E0%A5%8D%E0%A4%B0:Marathi_Event_Report_3.jpg
2)
https://mr.wikipedia.org/wiki/%E0%A4%9A%E0%A4%BF%E0%A4%A4%E0%A5%8D%E0%A4%B0:Marathi_Event_Report_2.jpg
3)
https://mr.wikipedia.org/wiki/%E0%A4%9A%E0%A4%BF%E0%A4%A4%E0%A5%8D%E0%A4%B0:Marathi_Event_Report_1.jpg

---

Santosh M. Shingare,
Research Assistant ,
Indian Institute Of Technology  Bombay,
Powai , Mumbai - 400076
Maharashtra,  ( INDIA )

*Mob- *+91 9890984632
*Email ID : * santosh.shing...@gmail.com
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l