https://wikimediafoundation.org/w/index.php?oldid=79658&action=edit
This page is currently loading an <iframe> from http://hire.jobvite.com. Besides banishing the pretty green lock icon in Chrome (due to the mixture of http and https), as far as I understand it, the use of an <iframe> like this exposes user data (such as a user's IP address) of every visitor to any page where the frame is loaded. That is, whoever is running hire.jobvite.com will be able to track who has viewed the page where this template is loaded on wikimediafoundation.org on their own server/in their own server logs.
Are there policies or guidelines surrounding the use of <iframe>s like this? Typically the tag is banned on Wikimedia wikis, but wikimediafoundation.org allows raw HTML.
I know other activities such as loading Google Analytics in site-wide JavaScript have been shot down due to concerns of third parties tracking users, but this is a separate case with fewer privacy implications, I think.
Thoughts?
MZMcBride
That should be reverted right now per our privacy policy and any others on site. No different than share button usage.
K. Peachey wrote:
That should be reverted right now per our privacy policy and any others on site. No different than share button usage.
As far as I've come to understand it, it's a matter of whether Jobvite's privacy policy is compatible with Wikimedia's:
* https://wikimediafoundation.org/wiki/Privacy_policy * http://recruiting.jobvite.com/privacy-policy.php
I don't know the answer, but I imagine someone will be along in short order to clarify.
MZMcBride
HR recently switched to an externally hosted applicant tracking system called Jobvite. It's sadly proprietary, but very feature-rich and used by many tech companies, including e.g. Mozilla. Basically the previous process was for candidates to be dumped in a shared inbox, where recruiters and hiring managers would have to keep track of them with the aid of tracking spreadsheets and lots of emails. An ATS automates a lot of the tracking and workflows, and helps ensure that people don't get dropped. It also sends hiring managers reminders to submit all the required hiring documentation, etc. So in general it's a good thing, although we sometimes curse at aspects of its UI.
The rationale for the iframe is to automate the job listings on the WMF site and surface the various Jobvite features.
Yes, that means that the user's browser will contact hire.jobvite.com when loading the page (although all its resources will be loaded in the context of the iframe). AFAICT the main issue here is to clarify in the footer that job applications and job descriptions are run through an external service called Jobvite and subject to the Jobvite privacy policy, to avoid any confusion.
Whether the iframe is a good idea still remains to be seen. Jobvite makes it unnecessarily hard to link to JDs directly (because their ideology is that everyone should come through some social media funnel, I think), and the navigation is heavily JS dependent right now. So we might want to switch back to a hybrid format. The job pages are also still actively being re-designed, and the setup might change significantly in coming weeks.
Erik
On 15 March 2012 06:34, Erik Moeller erik@wikimedia.org wrote:
Whether the iframe is a good idea still remains to be seen. Jobvite makes it unnecessarily hard to link to JDs directly (because their ideology is that everyone should come through some social media funnel, I think), and the navigation is heavily JS dependent right now. So we might want to switch back to a hybrid format. The job pages are also still actively being re-designed, and the setup might change significantly in coming weeks.
Pointless waffle. You forget what the WMF is meant to be.
I am personally concerned that the WMF website is promoting Jobvite by allowing the in-house template to include generic links such as http://recruiting.jobvite.com (from the "powered by Jobvite" link) which leads the page with the number of the Jobvite sales hotline.
Even if Jobvite are providing these services for free, this seems highly inappropriate for a website that under the Values should not carry advertizing for other companies.
If I need to escalate this through a different venue in order for prompt action to be taken, please advise me by direct email.
Links: * http://wikimediafoundation.org/wiki/Job_openings * https://wikimediafoundation.org/w/index.php?oldid=79658&action=edit
Thanks, Fae
Erik Moeller wrote:
The rationale for the iframe is to automate the job listings on the WMF site and surface the various Jobvite features.
Right. But any feature comes with an associated cost. :-)
Yes, that means that the user's browser will contact hire.jobvite.com when loading the page (although all its resources will be loaded in the context of the iframe). AFAICT the main issue here is to clarify in the footer that job applications and job descriptions are run through an external service called Jobvite and subject to the Jobvite privacy policy, to avoid any confusion.
Well, it's a lot more than that, surely. It reads to me like you're kind of down-playing the implications when you say "yes, that means the user's browser will contact hire.jobvite.com." This particular data is treated as sacrosanct within the Wikimedia community (for better or worse). <iframe>s have serious privacy and security issues. If they didn't, they'd be an awfully convenient tool for implementing all kinds of neat ideas both between Wikimedia wikis and between Wikimedia wikis and the outside world. But they're banned in MediaWiki by default (with good reason).
Through a loophole (allowing raw HTML on wikimediafoundation.org), they're allowed in this specific case, but it's a matter of figuring out whether Jobvite's privacy policy is compatible with Wikimedia Foundation's, I think.
Whether the iframe is a good idea still remains to be seen.
Indeed. I've commented out the iframe for now while discussion continues. Once there's a clearer understanding of the implications of using this code and whether this particular third-party's policy is compatible with Wikimedia's.
I say "compatible" as it's a passive read action of wikimediafoundation.org that will trigger data being sent to Jobvite. Adding a footer might be nice, but if the user doesn't consent to Jobvite's privacy policy, simply reading wikimediafoundation.org has already sent their data to the other server, correct? In my mind, that means a footer or additional warning text is insufficient.
MZMcBride
MZMcBride wrote:
Indeed. I've commented out the iframe for now while discussion continues. Once there's a clearer understanding of the implications of using this code and whether this particular third-party's policy is compatible with Wikimedia's.
I say "compatible" as it's a passive read action of wikimediafoundation.org that will trigger data being sent to Jobvite. Adding a footer might be nice, but if the user doesn't consent to Jobvite's privacy policy, simply reading wikimediafoundation.org has already sent their data to the other server, correct? In my mind, that means a footer or additional warning text is insufficient.
Quick update on this. I blanked the page, but it's already been switched over as the central repository for Wikimedia Foundation job listings, so simply blanking wasn't an option. It's kind of obscure, but Jobvite does allow direct links to individual job listings. I put together an index of the current job openings and even added back some of the old styling: https://wikimediafoundation.org/w/index.php?oldid=79813. It doesn't auto-update and it doesn't have the same categorization, but for right now, as a stop-gap measure, it'll work.
I think the ideal solution would be for http://hire.jobvite.com/Jobvite/Jobs.aspx?c=qSa9VfwQ to have an RSS feed so that outsiders can follow Wikimedia job postings and the content can be brought in to sites like wikimediafoundation.org using the same code that powers the auto-updates of the Wikimedia blog to the home page of wikimediafoundation.org. I'm not sure if this would support the same kind of categorization scheme (perhaps multiple feeds would be needed or an attribute could be specified?).
MZMcBride
wikimedia-l@lists.wikimedia.org