(This email was originally sent six days ago Dmitry, Brion, Yuvi and Monte.
I'm forwarding to mobile-l for broader coverage)
Hey guys,
There's a proposal to reorganise the Wikipedia Apps product in Bugzilla to
make it slightly more intuitive.
Yuvi's proposed that we change the components from being a mix of both
platform and version (e.g. "Android (alpha)") to just platform (e.g.
"Android"), then changing the versions bit to Alpha, Beta, and Stable.
That'd allow us to better configure Bugzilla with default CC lists. Yuvi's
proposed change is documented here:
https://bugzilla.wikimedia.org/show_bug.cgi?id=64621#c3.
We're planning on going ahead with this in a few days, but if any of you
have objections, please do comment on the bug and we can find a solution
that works for everyone.
Thanks,
Dan
--
Dan Garry
Associate Product Manager for Platform and Mobile Apps
Wikimedia Foundation
by International Conference on Digital Security and Forensics (DigitalSec2014)
CALL FOR PAPERS
The International Conference on Digital Security
and Forensics (DigitalSec2014)
June 24-26, 2014
VSB-Technical University of Ostrava
Ostrava, Czech Republic
http://sdiwc.net/conferences/2014/digitsec2014/
-----------------------------------------------------------
The proposed conference on the above theme will be held at VSB-Technical
University of Ostrava, Ostrava, Czech Republic From June 24-26, 2014.
All papers will be published in the proceedings of the conference, sDIWC
digital library and best papers for special issue journals.
Important Dates:
================
Final Submission Deadline : May 25, 2014
Notification of Acceptance: 7 days from the submission date
Camera Ready : June 14, 2014
Registration : June 14, 2014
Conference Dates : June 24-26, 2014
I'm adding mobile-l to this as I think it is a useful discussion.
The plan is to move the nearby code into the Geodata extension. To do this
however we must remove the dependency on MobileFrontend code which is not
an easy.
Check out the Mantle extension. This isn't final but it will give you an
idea of a potential plan of action. This patch [1] will also give you an
idea of how we could do this.
[1] https://gerrit.wikimedia.org/r/129480
On 27 Apr 2014 23:58, "Prateek Saxena" <psaxena(a)wikimedia.org> wrote:
> Should we consider moving Nearby out of MobileFrontend and into its
> own extension?
>
> -prtksxna
>
The only issue is a scaling issue. Due to the traffic such a service would
create we need to be able to support our own tile server and have a team
that manages it. There is a bug around this. No legal issues as far as I'm
concerned...
https://bugzilla.wikimedia.org/show_bug.cgi?id=33980
On 10 May 2014 22:04, "Prateek Saxena" <psaxena(a)wikimedia.org> wrote:
On Sun, May 11, 2014 at 12:56 AM, Russell Nelson <russnelson(a)gmail.com>
wrote:
> I just read the whole Nearby card. Why is "OSM privacy situation is a bit
of
> a mess?"
I don't know about legal stuff, CC'd Luis to clarify.
On Sun, May 11, 2014 at 12:56 AM, Russell Nelson <russnelson(a)gmail.com>
wrote:
> Google by users and they'll be subject to Google's privacy policy. Simply
a
> non-starter.
Which is why it has been dropped.
Also, please note that the topic of discussion is whether to move
Nearby out of MobileFrontend. I understand now that WMF will/might
need its own tile server before any sufficient progress can be made on
this.
—prtksxna
_______________________________________________
Mobile-l mailing list
Mobile-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l
We have an updated alpha version of the Android app available on the Play
Store. If you'd like to opt in to get automatic updates of the alpha
version, please follow these instructions:
http://lists.wikimedia.org/pipermail/mobile-l/2014-March/006642.html
What's new in this release:
- Renamed "Saved Pages" to "Bookmarks", and no longer storing page content
locally.
- The table-of-contents for each page now slides out from the right-hand
side, just like the main menu slides from the left.
- Horizontal scrolling for extra-wide page content now works properly.
- Plenty of other fixes for bugs and crashes.
--
Dmitry Brant
http://dmitrybrant.com
Recently, I decided to clean-up some of the code in MobileFrontend related
to localStorage. The other mobile devs suggested that I implement a
generalized solution that could be upstreamed to core. I looked at some 3rd
party jQuery plug-ins and decided to implement a solution based on jQuery
Store. I stripped out all the extraneous crap and added support for cookies
(since localStorage quotas are often rather small for mobile devices) and
caching. The end result can be seen at:
https://gerrit.wikimedia.org/r/#/c/131239/
After I checked this in, I was informed that there is already a client-side
storage plug-in in core: jStorage, as well as another one being used by
Flow, Storer. Both of these seem a bit like overkill to me and I would
prefer to implement something simple and light-weight for mobile. Also
jStorage doesn't support fall-back to cookies.
What are people's opinions on moving forward on this? Should mobile have
it's own lightweight plug-in, should we modify jStorage in core so that it
meets our requirements, or should we adopt Storer and push for it to
replace jStorage in core?
Ryan Kaldari
When I view the Nearby test confusingly it tells me it passed... hence
the confusion :)
On Tue, May 6, 2014 at 9:50 AM, Chris McMahon <cmcmahon(a)wikimedia.org> wrote:
>
>
>
> On Tue, May 6, 2014 at 9:12 AM, Jon Robson <jrobson(a)wikimedia.org> wrote:
>>
>> https://gerrit.wikimedia.org/r/131714 fixes the toggling tests
>> https://gerrit.wikimedia.org/r/131715 fixes the uploads.
>> KeepGoing... not sure what's going on there but continuing to investigate.
>> Nearby same.. ran tests locally and they seem to work fine.
>
>
> For the Nearby test, click through to the SauceLabs jobs from
> https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs…
> and watch the screencast.
>
> Looks like a browser glitch: the test sets Beta mode and clicks Save, and
> then Chrome freaks out and says "No data received"
>
> I am looking forward to running these from the WMF Jenkins.
>
> -C
>
>
FYI, added sampling
---------- Forwarded message ----------
From: Adam Baso <abaso(a)wikimedia.org>
Date: Fri, May 2, 2014 at 1:16 PM
Subject: Re: [Wikimedia-l] Mobile Operator IP Drift Tracking and Remediation
To: Wikimedia Mailing List <wikimedia-l(a)lists.wikimedia.org>
Federico asked if sampling might make sense here. I think it will work, so
I've updated the patchset.
>From a patchset comment I provided:
"It's possible we may have situations where operators have not lots of
users on them accessing Wiki(m|p)edia properties, so we do run some risk of
actually missing IPs, even if exit IPs are concentrators of typically large
sets of users. That said, let's try a 2% sample ratio; and if we find out
it's insufficient, then we'll sample more, if it's oversampling, then we
can adjust the other way, too. New patchset arriving shortly."
(I've since submitted the updated code for review.)
-Adam
On Thu, May 1, 2014 at 7:52 PM, Adam Baso <abaso(a)wikimedia.org> wrote:
> After examining this, it looks like EventLogging is more suited to the
> logging task than debug logging and the trappings of needing to alter debug
> logging in the core MediaWiki software.
>
> EventLogging logs at the resolution of a second (instead of a day), but
> has inbuilt support for record removal after 90 days.
>
> Please do let us know in case of further questions. Here's the logging
> schema for those with an interest:
>
> https://meta.wikimedia.org/wiki/Schema:MobileOperatorCode
>
> Here's the relevant server code:
>
> https://gerrit.wikimedia.org/r/#/c/130991/
>
> -Adam
>
>
>
>
> On Wed, Apr 16, 2014 at 2:20 PM, Adam Baso <abaso(a)wikimedia.org> wrote:
>
>> Great idea!
>>
>> Anyone on the list know if there's a way to make the debug log facilities
>> do the YYYYMMDD timestamp instead of the longer one?
>>
>> If not, I suppose we could work to update the core MediaWiki code. [1]
>>
>> -Adam
>>
>> 1. For those with PHP skills or equivalent, I'm referring to
>> https://git.wikimedia.org/blob/mediawiki%2Fcore.git/a26687e81532def3faba646….
>> Scroll to the bottom of the function definition to see the datetimestamp
>> approach.
>>
>>
>> On Wed, Apr 16, 2014 at 12:47 PM, Andrew Gray <andrew.gray(a)dunelm.org.uk>wrote:
>>
>>> Hi Adam,
>>>
>>> One thought: you don't really need the date/time data at any detailed
>>> resolution, do you? If what you're wanting it for is to track major
>>> changes ("last month it all switched to this IP") and to purge old
>>> data ("delete anything older than 10 March"), you could simply log day
>>> rather than datetime.
>>>
>>> enwiki / 127.0.0.1 / 123.45 / 2014-04-16:1245.45
>>>
>>> enwiki / 127.0.0.1 / 123.45 / 2014-04-16
>>>
>>> - the latter gives you the data you need while making it a lot harder
>>> to do any kind of close user-identification.
>>>
>>> Andrew.
>>> On 16 Apr 2014 19:17, "Adam Baso" <abaso(a)wikimedia.org> wrote:
>>>
>>> > Inline.
>>> >
>>> > Thanks for starting this thread.
>>> > >
>>> > > Sorry if I've overlooked this, but who/what will have access to this
>>> > data?
>>> > > Only members of the mobile team? Local project CheckUsers? Wikimedia
>>> > > Foundation-approved researchers? Wikimedia shell users? AbuseFilter
>>> > > filters?
>>> > >
>>> >
>>> > It's a good question. The thought is to put it in the customary
>>> wfDebugLog
>>> > location (with, for example, filename "mccmnc.log") on fluorine.
>>> >
>>> > It just occurred to me that the wiki name (e.g., "enwiki"), but not the
>>> > full URL, gets logged additionally as part of the wfDebugLog call; to
>>> make
>>> > the implicit explicit, wfDebugLog adds a datetime stamp as well, and
>>> that's
>>> > useful for purging old records. I'll forward this email to mobile-l and
>>> > wikitech-l to underscore this.
>>> >
>>> >
>>> > > And this may be a silly question, but is there a reasonable means of
>>> > > approximating how identifying these two data points alone are? That
>>> is,
>>> > > Using a mobile country code and exit IP address, is it possible to
>>> > > identify a particular editor or reader? Or perhaps rephrased, is this
>>> > data
>>> > > considered anonymized?
>>> > >
>>> >
>>> > Not a silly question. My approximation is these tuples (datetime, now
>>> that
>>> > it hit me - XYwiki, exit IP, and MCC-MNC) alone, although not perfectly
>>> > anonymized, are low identifying (that is, indirect inferences on the
>>> data
>>> > in isolation are unlikely, but technically possible, through
>>> examination of
>>> > short tail outliers in a cluster analysis where such readers/editors
>>> exist
>>> > in the short tail outliers sets), in contrast to regular web access
>>> logs
>>> > (where direct inferences are easy).
>>> >
>>> > Thanks. I'll forward this along now.
>>> >
>>> > -Adam
>>> > _______________________________________________
>>> > Wikimedia-l mailing list
>>> > Wikimedia-l(a)lists.wikimedia.org
>>> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
>>> > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
>>> _______________________________________________
>>> Wikimedia-l mailing list
>>> Wikimedia-l(a)lists.wikimedia.org
>>> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
>>> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
>>>
>>
>>
>