2FA! 2FA! 2FA!

Howdy, all! I’m back, and we’re getting the Two-Factor Train rolling again!

We had our first meeting yesterday at the usual time (22:00 UTC / 5pm Eastern) in #core-passwords.

https://wordpress.slack.com/archives/core-passwords/p1449784908000119

Following some critical feedback and discussions both at the Community Summit and at WordCamp US, we’re adjusting our focus. Technical feasibility is turning out to be far less of a concern than ensuring we don’t create an undue support burden by users getting locked out and providing a way back in.

Previously, we had been anticipating the primary way to override a loss of their second factor would be either adding a constant or modifying the database records (either directly or via a shell tool such as WP-CLI). However, we have had a number of concerns from assorted interested parties, and the fact of the matter is that it is feeling like too high of a barrier for many WordPress users. As @macmanx (new Forums Team Rep) summarized in our chat yesterday,

I’ll say it this way: We want users to be able to secure their sites with 2FA, not sit back and watch outdated abandoned sites pile up because they locked themselves out and simply give up when when we mention FTP, Database, or SSH.

So, there are several things that have been brought up:

Require a constant in `wp-config.php` to enable 2FA

The idea being that, by adding a constant to wp-config, the user has demonstrated that they know how to use FTP and edit files on their server manually, so if all goes to heck, they have the ability and knowledge to take the constant back out, so they can get back into their site admin.

I feel that this is a bad idea, because it violates many of the WordPress Core Philosophies. It wouldn’t work out of the box, and we’re no longer designing for the majority. It results in us adding not only an option, but an option that’s hard to set.

If we have to hide it behind a constant, I feel that it shouldn’t even be in Core, and would be better left as a plugin.

(yes, I know Multisite runs this way, but there are other reasons that was merged into core)

Require multiple providers being enabled

The idea here being that if the user has two, there is less likelihood of getting locked out as they’d have a backup. However, for myself, I can’t tell you how many times I’ve downloaded backup codes and promptly lost them. Or how many times my phone has been destroyed (washing machines and phones shouldn’t be friends). There’s still a lot of opportunity for things to go wrong, especially on the scale of powering a quarter of the web. Edge cases become commonplace. 🙁

Send Text Messages

No can do, this would require a third-party server to send them through, and that’s plugin territory.

Leave Emailed Codes as an always-available fallback

This, I feel is our best option.

There are some concerns regarding the large percentage of WordPress sites that are on servers that can’t send email (as high as 25% by some guesstimates I’ve heard floated), so we’d need to send a code and make sure it gets received before turning on the actual two-factor login prompt.

While it doesn’t provide the best security (if someone breaks into your email address, they could both reset your password and get the incoming authentication code), it is 1) no worse than the status quo, 2) not our responsibility to keep secure, and 3) if they’ve broken into your email, you probably have bigger concerns.

We can certainly include a filter for methods to disable / add from plugins, and so if someone wants to disable email manually, they totes can. By explicitly disabling the Core security feature, they’re then demonstrating that they know enough to fix it if it goes wrong.

In the end, my feelings were largely best summed up by @michael-arestad, describing the two ways of balancing ease of use versus airtight security:

Ease-of-use: core potential
Airtight security: plugin town

And we can always ship the plugin ourselves to let folks disable Email, but that feels like if it were in wp-admin that we’d be giving them just enough rope to hang themselves. 🙁

===

Now, none of this is finalized, so if you disagree, please voice your concerns in the comment section below. I’m hoping that we’ll get enough discussion that we’ll be able to confidently make a final decision on what path we’re taking at next week’s meeting — which will be on Thursday at 5pm Eastern / 22:00 UTC in #core-passwords

#feature-plugins, #two-factor, #updates

Shortcake (Shortcode UI) chat summary – November 2nd, 2015

Present: @danielbachhuber, @goldenapples, @matth_eu

Logs: https://wordpress.slack.com/archives/feature-shortcode/p1446494424000273

  • We released Shortcake v0.6.0. Read through the full release notes.
  • Weekly meetings are on hold until January. Between now and then, we’ll be thinking about what we need to do to put forth a core proposal. @matth_eu might put together sketches.
  • We missed the boat on getting a Shortcake representative to the community summit, and are researching ways to helicopter @goldenapples to said community summit boat.

Next chat: sometime in January 2016

#chats, #feature-plugins, #meeting-notes, #shortcode-ui, #shortcodes, #updates

Shortcake (Shortcode UI) chat summary – October 5th, 2015

Present: @danielbachhuber, @goldenapples, @matth_eu

Logs: https://wordpress.slack.com/archives/feature-shortcode/p1444071794000007

  • Matt’s making process on support for encoding HTML in attributes. Gallery functionality is also almost done, but there’s one small bug.
  • Than started work on trying to add some filters that can be used to handle floated/non-block previews. It still some work to go, as it’ll involve overriding some methods deep in mce.view.
  • Daniel will hit up the backlog when he has a moment, as there are a number of unanswered open issues.
  • We discussed inline editing and agreed upon an ideal abstraction .

Next chat: same time and place

Next release: v0.6.0 – Tuesday, November 3rd

#chats, #feature-plugins, #meeting-notes, #shortcode-ui, #shortcodes, #updates

Responsive Images Feature Plugin Update

Following up on our first official project update, here’s a brief status update to keep everyone informed about the progress we’ve made.

Updates

  • Released v2.4.0 early last week, fixing several bugs and adding a few filters (changelog). Please test on your sites and leave us feedback!
  • Created placeholder tickets for adding srcset and sizes support ( #33641 ) and improving the compression settings of Imagick ( #33642 ).
  • @jaspermdegroot is digging into the content filter approach to support responsive images for old posts. Performance tests and details on GitHub. Feedback appreciated!

Next Steps

We’re ready to create an initial patch candidate for core. We’ll be working on that over the next week, with a more detailed update at that time.

Check out the logs from our last meeting and join us for the next one on Friday at 19:00 UTC in #feature-respimg.

Questions? Please leave feedback below, or ask anytime in #feature-respimg.

#feature-plugins, #media, #respimg, #updates

oEmbed Feature Plugin Update

After kicking off the oEmbed feature plugin a couple of weeks ago, it’s high time for another status update.

In case you have missed it, the oEmbed API plugin makes WordPress an oEmbed provider, allowing you to embed blog posts just like YouTube videos or tweets. Of course everything happens with security and ease-of-use in mind.

oEmbed Feature Plugin

Embedding a post is super simple!

We made some great progress over the last few weeks. The highlights are:

  • Improved test coverage, which led to many fixed bugs
  • Auto-resizing of the embedded iframe so it looks great on every screen
  • It seamlessly integrates with the REST API, but also works perfectly without it

The plugin is very stable so far. We’re looking into bringing it to WordPress.com for testing, but of course we also need your help to bring this further! Download the plugin from the repository — play with it, break it, and help us fixing all bugs that may appear. We’re always looking for areas to improve.

We’re now mainly working on getting it into shape for an eventual core merge proposal and implementing the different oEmbed response types. This means supporting embedding attachment posts and posts with different post formats.

Please, test and report both errors and suggestions either on GitHub or our #feature-oembed Slack channel. Anyone is welcome to join us!

Next chat: September 7 2015 9pm UTC

#embeds, #feature-plugins, #feature-oembed, #updates

Shortcake (Shortcode UI) chat summary – August 31st, 2015

Present: @danielbachhuber, @matth_eu

Logs: https://wordpress.slack.com/archives/feature-shortcode/p1441047764000146

Next chat: same time and place

Next release: v0.6.0 – Tuesday, November 3rd

#chats, #feature-plugins, #meeting-notes, #shortcode-ui, #shortcodes, #updates

Two-Factor Auth Update

It’s been a couple weeks since our last update, but we’ve had some solid headway in the last couple days!

Current status of default providers:

  • Email: In and works.
  • FIDO U2F: In and works, but only for PHP 5.3+ (library dependency, non-trivial to revise for 5.2)
  • Backup Codes: In and works.
  • TOTP (Google Authenticator): Pull request open (several, actually), I expect to see it merged in the next couple days.

For the providers that are in and works, there may be minor issues either via code architecture or enhancements like better ui / ajax or whatnot — it’s just easier to solve those via small pull requests to master, versus endlessly debating in a pull request without actually merging it in. 🙂

Application Passwords are also included in the plugin currently, however I’m not sure whether they should be a part of it or not in the end — they are included to allow users who use two-factor authentication to still use xml-rpc functionality, which can’t support two-factor authentication.

For TOTP, we will need to be able to generate QR codes, and the de facto standard library I’ve found for generating them locally seems to be https://github.com/kazuhikoarase/qrcode-generator — which has both PHP and JS implementations and is MIT licensed. I’m currently leaning towards the JS implementation, but I’d be fine with PHP instead. Either way works just as easily.

Please, test and report both errors and suggestions either on GitHub or on our Slack channel — #core-passwords.

As always, our next chat will be on Thursday at 5pm Eastern, in #core-passwords.

#feature-plugins, #two-factor, #updates

Update: Responsive Image Support for Core

The responsive image team has been meeting regularly for a while. After our meeting earlier this week, we realized that make/core needs an update on what’s been going on with the RICG (Responsive Images Community Group) feature plugin, as well as to request feedback on a few questions.

Our meetings are in #feature-respimg each Friday at 1900 UTC, so please come and chat to give feedback or if you’re interested in helping out!

Background

Several years ago, a ragtag group of web professionals identified a need for new HTML markup which would allow developers to declare multiple sources for an image—allowing devices to select the image source that was most appropriate for its own capabilities. Fast forward to today and all major browsers have either implemented these new tools or currently have them under consideration for development.

With that as background, the RICG has been working on an Official WordPress Feature Plugin™ to test the viability of adding responsive image support natively into WordPress. Specifically, our aim is to automatically add srcset (using w descriptors) and sizes attributes to the image markup generated by WordPress. According to the WordPress.org plugin directory, there are over 10k active installs, so we’ve definitely seen an interest in this functionality.

There are two main pieces of functionality included in the plugin, which can be considered separately for inclusion in core:

  1. Logic for producing responsive image markup
  2. Advanced image compression (via ImageMagick)

Responsive Image Markup

There is a lot to consider when proposing a change to the way WordPress outputs image markup, so I want to be clear about some of our assumptions going in:

  • Responsive image support should be added ‘invisibly’ without introducing new settings for users to worry about.
  • WordPress, out of the box, should only deal with resolution switching, and not the art direction use case for now. In other words, we would not be adding any API or admin UI for outputting different cropped images at specific breakpoints. (For more information about use cases and all things related to responsive images, I’d recommend reading the terrific Responsive Image 101 series by Jason Grigsby).
  • Provide this functionality using default and available user-defined sizes (via add_image_size()) for source sets rather than creating an additional set of crops. This choice is based on early feedback from Nacin regarding file-count concerns on some shared hosts.
  • Provide filter hooks so theme/plugin authors can extend/override defaults.
  • All sizes of an image (i.e., _wp_attachment_metadata['sizes']) with the same aspect ratio are resized versions of the same image, not custom art directed crops. This assumption has been okay so far, but there may be be plugins that replace the default image sizes with art directed crops that maintain the same aspect ratio. We’ll need to determine how to handle these cases.

Questions to Consider

  1. How should we handle markup embedded in post content?
    • Currently, we embed the srcset attribute directly into posts with sizes added as a data attribute to make it easier for theme authors to filter the sizes attribute later. It’s tricky to decide when it’s appropriate to add layout relative markup to the database, but WordPress is currently doing this to a certain extent by adding width/height attributes to images, so this may be the best solution for now.
    • Instead, a more elegant solution would be to filter the content on output. This would avoid saving layout markup in the database, and extend support to posts with images that were published before the feature became available. We have a proof of concept but are unsure if adding another filter to the_content is appropriate. Confirmation either way on this question would help us move forward.
  2. Should we support srcset and sizes in older browsers?
    • The plugin includes the picturefill.js polyfill, which provides support for older browsers, but would be a new dependency for core.
    • We could view srcset and sizes as a progressive enhancement and only provide support in WordPress for newer browsers. In that case, we could drop the polyfill and save WordPress an extra JS dependency. Note that this polyfill is written by the same people writing and implementing the spec. We consider it to be very reliable.
  3. Should we turn responsive image support on by default?
    • “Decisions not options.” We propose that responsive images are enabled by default in core, with filters provided for disabling or modifying the feature.
    • If core does not want responsive images enabled by default, they could be enabled through a current_theme_supports() flag. Themes would have to “opt-in” to the feature.

Advanced Image Compression

The second potential enhancement introduced through our plugin is an improvement to the default ImageMagick compression settings currently being used in core. RICG contributor Dave Newton has done great research on the best compression settings for ImageMagick, and included them as an opt-in option within the plugin.

The updated settings are absolutely killer when there are sufficient CPU and memory resources on the host server. In our trials, file sizes have decreased by >50% compared to the default core settings.

However, on limited servers, these new settings could cause problems. We are iterating on them to find the right balance between the file-size savings and the CPU resources required to process large files.

Final Notes

We need your help!

New features need lots of feedback and testing. Help us test these enhancements by installing the latest version of the plugin from WordPress.org.

Be sure to enable advanced image compression and tell us how it does with your setup so we can gather more feedback.

If you know of plugins that heavily modify or interact with custom image sizes or art-directed crops, please leave a comment below so we can test it with this feature.

Have thoughts on the questions above? Let us know in the comments!

Want to get involved? We meet each week in #feature-respimg on Friday at 1900 UTC.

#feature-plugins, #media, #respimg, #updates

Shortcake (Shortcode UI) chat summary – August 24th, 2015

Present: @danielbachhuber, @goldenapples, @miqrogroove, @azaozz

Logs: https://wordpress.slack.com/archives/feature-shortcode/p1440442841000013

  • We triaged the remaining issues for v0.5.0. Daniel will be picking them up over the next day.
  • A big project for v0.6.0 will be to go through core’s feature plugin guidelines and identify what we need to change to be valid.
  • Spent time discussing @miqrogroove summary of shortcode problems, and proposed solutions

Next chat: same time and place

Next release: v0.5.0 – this week (a bit overdue)

#feature-plugins, #meeting-notes, #shortcode-ui, #shortcodes, #updates

WP REST API: Versions 1.2.3 (Security Release) and 2.0 Beta 4

First and foremost: version 1.2.3 of the REST API is now available. Download it from the plugin repository or from GitHub. This is a security release affecting sites running version 1.2 or a 2.0 beta releases.

Security Release

Recently, we were alerted to a potential XSS vulnerability introduced in version 1.2 of the API related to the JSONP support. This vulnerability also existed in version 2.0. Thanks to Alex Concha (@xknown) for reporting this issue to the team responsibly.

This release was coordinated by the REST API team and the WordPress core security team. The security team is pushing automatic updates for version 1.2.3, but do not wait or rely on the automatic update process. We recommend sites or plugins that are using either v1.2.x or 2.0 beta releases update the plugin immediately.

If you’d prefer not to upgrade, you can instead disable JSONP support through a filter. For version 1:

add_filter( 'json_jsonp_enabled', '__return_false' );

To disable JSONP on version 2:

add_filter( 'rest_jsonp_enabled', '__return_false' );

If you have a question about the security release, you can find the team in #core-restapi on WordPress.org Slack, or you can privately message @rachelbaker, @rmccue, @danielbachhuber, or @joehoyle.

Version 2.0 Beta 4

Alongside the security release for version 1.2, we’re also releasing the latest beta for version 2.0: 2.0 Beta 4 “See My Vest”. You can download this from the plugin repository or from GitHub.

This beta release includes the security fix from version 1.2.3, so we recommend everyone running a version 2 beta update immediately to fix the issue.

As well as the security release, this beta also includes a bunch of other changes. Here’s some highlights:

  • Show public user information through the user controller.

    In WordPress as of r32683 (scheduled for 4.3), WP_User_Query now has support for getting users with published posts. To match current behaviour in WordPress themes and feeds, we now expose this public user information. This includes the avatar, description, user ID, custom URL, display name, and URL, for users who have published at least one post on the site. This information is available to all clients; other fields and data for all users are still only available when authenticated.

  • Send schema in OPTIONS requests and index.

    Rather than using separate /schema endpoints, the schema for items is now available through an OPTIONS request to the route. This means that full documentation is now available for endpoints through an OPTIONS request; this includes available methods, what data you can pass to the endpoint, and the data you’ll get back.

    ⚠️ This breaks backwards compatibility for clients relying on schemas being at their own routes. These clients should instead send OPTIONS requests.

  • Update JavaScript API for version 2.

    Our fantastic JavaScript API from version 1 is now available for version 2, refreshed with the latest and greatest changes. Thanks to Taylor Lovett (@tlovett1), K. Adam White (@kadamwhite) and Nathan Rice (@nathanrice).

  • Embed links inside items in a collection.

    Previously when fetching a collection of items, you only received the items themselves. No longer! You can now request a collection with embeds enabled (try /wp/v2/posts?_embed).

  • Move /posts WP_Query vars back to filter param.

    In version 1, we had internal WP_Query vars available via filter (e.g. filter[s]=search+term). For our first betas of version 2, we tried something different and exposed these directly on the endpoint. The experiment has now concluded; we didn’t like this that much, so filter is back.

    ⚠️ This breaks backwards compatibility for users using WP Query vars. Simply change your x=y parameter to filter[x]=y.

  • Respect rest_base for taxonomies.

    ⚠️ This breaks backwards compatibility by changing the /wp/v2/posts/{id}/terms/post_tag endpoint to /wp/v2/posts/{id}/tag.

As always, we have a detailed changelog as well as the full set of changes if you’re interested.

(Note that while this version 2 beta breaks backwards compatibility, the 1.2.3 security release does not break compatibility with the 1.2 branch.)

This release had 11 contributors, and we’d like to thank each and every one of them:

$ git shortlog 2.0-beta3...2.0-beta4 --summary
     1   Daniel Bachhuber
    11   Daniel Jalkut
     1   Fredrik Forsmo
     1   Jared Cobb
     3   Jay Dolan
    26   Joe Hoyle
    10   Josh Pollock
    25   Rachel Baker
    50   Ryan McCue
    24   Stephen Edgar
     8   Taylor Lovett

Thank you again to all of our beta testers, and thanks to everyone who let us know how you’re using the API. We’re taking note of all of your feedback, and you might see some further changes related to that in coming releases.

#feature-plugins, #json-api, #rest-api, #security, #updates