I don't see this as an urgent priority, although planning it as a small piece of work for a future quarter would be fine. We could then share this with the mailing lists and contacts we have at places where people are employing these sorts of algorithms in their own code.

This sort of algorithm is in use in several prominent high scale media properties, but people are recreating the work in their specific cases, as opposed to having one easy-to-call API that reflects this line of thinking. The idea was to expose something that, given a title, produces the correct revision. I strongly agree that it should also take into consideration whether that last correct revision is reportedly non-damaging (and scrub backwards further if so), as sometimes humans can't keep up with the backlog.

@BBlack in https://gerrit.wikimedia.org/r/490120 I checked in with @Pginer-WMF today. Pau said deploying this the day or two prior to ExternalGuidance being activated for the source wiki of enwiki (for Indonesian) would be ideal.

Okay, so based on @TheDJ feedback @JMinor it seems the issue may surface in fleeting edge case scenarios. Of course some would say making those errors visible is a feature, not a bug. Anyway, obviously this is your area for prioritization.

Thanks @TheDJ.

Thanks. I'm not sure if something changed in a Scribunto module or somewhere in extension land, but it doesn't seem like it's really turning up on enwiki source, at least - there are some Village Pump discussions on this.

Hi all - I was aware of this task but hadn't been following it. But it was brought to my attention as having some momentum, so here I am! I have some information I can dredge up that I think may help shed some light on some paths forward. I also want to check in with some product and design people about any sense on forthcoming product interventions in the area of interactive or, for that matter, materialized graphs.

For those following along, I ran a query to get a sense of global usage of Google Translate and using the "Desktop" link. On 11 February 2019 there were only 89 such requests globally, about 2/3 where enwiki was the source wiki. This figure is not a perfect predictor of desktop user behavior, as for desktop users using enwiki as the source wiki receiving the mobile treatment it will be a new thing. But it probably suggests that, in addition to the rationale @Pginer-WMF provides about the basis of stopping showing broken stuff, the mobile read view is okay for consumptive purposes in general.

Thanks, @santhosh !

@BBlack ^ would you please review the enwiki VCL patch? We'll only want to merge it after ExternalGuidance has been tested with simplewiki and @Pginer-WMF has given the greenlight, but I figured it best if we go through review ahead of that.

@santhosh ^ would you please review and verify it has the intended effect? I need to reset my Vagrant stuff, but figured this was simple looking enough to post a patch (we'll see if I'm right!).

Heads up @chelsyx: for simplewiki access via the Google Translate proxy the traffic pattern is now mobile web based even for desktop UAs. The same will happen with enwiki when we make that change later. I thought I should make this clear for any intervention analysis.

@santhosh and @Gilles the footer list containing the "Desktop" link and other list items places the dot character between elements using an li::after pseudo-element. Do you think we should just use JS to remove the "Desktop" <li> instead of using a CSS rule? Setting the opacity to 0 like the other hidden elements would leave the dot character for any preceding bullets in place, which looks unusual because it leaves a dot at the end of the list. If we use JS is there a preferred segment of the JS code to do so to avoid any performance issues?

I should note that, concerning the edge case regression, it has historically been the case that, even after the mobile Google Translate user taps/clicks "Desktop" link and is landed in a desktop presentation, subsequent taps/clicks in article links would wind them back into a mobile presentation. This has to do with the way cookies are not capable of being enforced in this translation context like when users access the site directly. So addressing the regression for the mobile user is only a modest improvement. But for the genuine desktop user, it may not be perceived as so modest because the desktop user may have been accustomed to the desktop treatment (even if we think the mobile treatment is more reader friendly). I'll need to check with @Pginer-WMF about the mental model and nearer term (next six to twelve months) user journey here and determine how to handle this, in a sustainable way, if at all. Given that users can use inbuilt translation in user agents, we may just want to notify the user on tap to do that upon the "Desktop" click/tap by way of ExternalGuidance JavaScript, for example.

Hi team.

Heads up @phuedx . @BBlack and I spoke yesterday and we'll go with a simpler patch instead of the fuller refactor, given the plan to have the Varnish stuff in maintenance mode and switch to ATS (i.e., don't fix it if it ain't broken).

Okay, @BBlack, now it's ready for review.

@BBlack hold that thought, one more condition to add.

@BBlack patch posted for your review ^. Would you please review and let me know on patch for any additions?

Hi @BBlack , any suggestion here?

@Tbayer what do you have in mind? Heads up, T208795 captures the first concrete case where the full transcoding indeed goes all the way through the Wikimedia servers and stuff is already counted as a pageview but there's an X-Analytics key-value made available for query purposes.

Paraphrasing a dialogue with @BBlack immediate edge side HTTP redirects based on header/regex might be feasible without fragmenting caches/backends.

Approved.

It's working nicely. Thanks @BBlack @Nuria!

@Nuria thanks. You understood the question well. Okay, so my read of sessionInSample and randomTokenMatch is that the populationSize values between different schemas would need to have a common base value so that they divide cleanly in order to guarantee intersection, as it's a divisor in a modulo calculation. Do I have that right?

The question of whether you can sample events per session with stickiness is a different one, and the answer to that is yes, you can do that as of today deterministically and decide that event 1 and event2 are always going to be sampled for session "25". Session here means " identifier assigned to your browser until you close it down" . This identifier is sent in eventlogging events but it is not sent in general requests. It will be reset when you re-start your browser.

• IE11+ (6.8%)
• Safari 5.1-11.2 (1.7%)
• Opera 15-26
• iOS Safari 8-11.3
  • After a brief peak at pageviews_daily in Turnilo, this looks like ~0.7%

Yes, we discussed collision avoidance as part of T201124 and increased the length of mw.user.sessionId() to a value that should be safe for all foreseeable scenarios (see in particular T201124#4521002). I'm not quite sure what salting and hashing has to do with that though.

• For unique device:
  • (an example that can include both scenarios you mentioned above) Any kind of experiment or data collection that requires asking the same unique device multiple questions across a period of time. For example, when we want to learn about how users "learn" on Wikipedia, we need to be able to interfere with their experience on Wikipedia in multiple stages of their interaction and ask them questions. Not being able to say which unique device has answered the first batch of questions is a blocker for this line of research.

@leila @Nuria @Tbayer @phuedx thanks. I'll try to respond in order.

Thanks for the review. The User-Agent field is that of the end user's device.

@JoeWalsh @Dbrant would you please chime in here as well?

Follow up here: Kosta and I spoke, and we don't need the token, as logging should take place on a per-user basis, not just on a per-session basis. So the key will be constructed by hashing two non-sensitive items. This is an okay approach in my view given the requirements.

@Bawolff I added a question in the patchset about getToken(). Basically, although the cost of computing a rainbow table to reverse engineer the hashed values of getToken() in case of someone spilling Redis keynames is moderately high, I wanted to check whether there's even a risk if an attacker does so. If there's a risk if an attacker does so, I'm thinking we should instead take just a portion of the token (I'm working from the assumption this is tied to something fixed between the client and the server - a cookie issued post login) and the user's numerical ID and concatenate those and then hash that concatenated value for setting the keyname - that would still be basically collision free for keynaming purposes.

@leila to clarify, which of the following do you desire?

Thanks, @Ottomata.

@Tbayer @Neil_P._Quinn_WMF @chelsyx @mpopov @nettrom_WMF curious about your thinking here for session overlap between events that are sent at the global (perhaps per-project, if we need that) default and those that are oversampled for the sessions.

@phuedx do you think it might be sensible to simply make sendBeacon a pre-requisite at this point for client side event logging?

@Ottomata I agree with @phuedx on your question that opt-in (eventually via SCS) makes sense. After all, for feature teams or feature clusters where session sampling as the norm would be wanted, they could follow some convention of their own to make it simple.

I'm interested in filling out the TODOs here.

The understanding from @Tbayer is correct about this task being separate from the question on retention beyond 90 days.

@JKatzWMF adding you in here. I believe reading-platform may have been your dashboard based on [T102036#1524744]. Okay to delete?

This appears to be related to fully qualified links in the page. Links to [[articles]] are automatically rewritten for mdot if on mdot already IIRC.

Ah, interesting point @Nemo_bis . @Varnent @srishakatux who's the audience for people clicking through from https://wikimediafoundation.org/technology/ ?

That's fine. I have some suggestions on the content on https://wikimediafoundation.org/technology/ and https://www.mediawiki.org/wiki/New_Developers#Choose_a_software_project , but I'll take that to an email thread.

Thanks, @Rfarrand for closing. Further summary posted at https://www.mediawiki.org/w/index.php?title=Wikimedia_Developer_Summit%2F2018%2FKnowledge_as_a_Service&type=revision&diff=2840141&oldid=2699409

Update to the ticket: webmaster console access has been provided to Ian for https://it.m.wikipedia.org/ and https://it.wikipedia.org/ for investigation/remediation.

What's needed?

Oh, interesting: https://developer.apple.com/videos/play/wwdc2018/204/

Marking this as resolved. Thanks @mforns for the review.

Approved.

Approved.

Approved.

Thanks, all. It's working for me now.

Nah, I'm good. I seemingly set this to Declined after thinking about it, but never actually submitted the change. Thanks for checking.

Understood it's low priority. Just adding another URL to the heap: https://www.mediawiki.org/wiki/Thread:Project:Support_desk/Adding_custom_style_for_special_pages/reply_(2)

Any update here?

In T187014#4139773, @Nuria wrote:

@dr0ptp4kt trying to understand: is this the bug that makes the request for the proxy list return empty when they should not?

The lack of tagging did not appear to be related to any config blob change on the portal at Zero:-OPERA (the last change was too far back for that to be plausible).

It's too tall an order for today - I'll need to be tracked down should this be resurfaced.

Hi all, I apologize for not replying on this ticket. In practice while I know of good solutions here, it's moot given current resourcing and projected projects. Now, if this becomes an area for further prioritization as part of security/privacy initiatives, I'm happy to consult.

The other night I woke up in the middle of the night thinking that I need to follow up here. Thanks @Rfarrand for the follow up on Phabricator!

I can't speak to all of the particulars, but I've added Roan and Joe to this task. Roan and Corey have been in discussion about technical architecture matters concerning push architecture as I understand. Web push is presently part of the FY 18-19 plan.

@Dbrant was there a patch or something in support libraries that would have fixed this?