https all the things (including i18n communities)

[rvagg]

http://roadmap.iojs.org is currently not available as https.

https://iojs.org is only available as https.

io.js should be setting a good example and doing strict https on all its public web-accessible resources.

1. we should stop using GitHub pages - this includes encouraging all WGs (including the i18n groups) to not use GitHub pages
2. management of publishing web resources should be delegated to the build team who are also working on scalable and HA solutions to publishing all io.js resources
3. we need to get a wildcard SSL cert to make this happen since we are already going beyond just iojs.org (or, can't we just put the roadmap on iojs.org/roadmap and keep it simple??)

/cc @iojs/build

[mikeal]

@rvagg I'm not in to dictating to other WGs what they can and cannot use. While I agree with this sentiment about HTTPS it's a barrier to entry to run every new site we want to throw up through the build group.

In addition, we encourage the i18n groups to run their stuff wherever it will get the most visibility so many of them post on third party sites and a few use gh-pages.

Security is super important for the main website and any resources that might end up being an endpoint for automation but it's overkill to say all resources, even simple static websites, must be HTTPS especially when it's significantly more work to set up each resource that way.

[rvagg]

That's why I used the word "encourage" for other WGs. Roadmap is the big oversight IMO and should be moved to better hosting. Ultimately it should be up to @iojs/build to help provide the infrastructure for all io.js that want/need it, including easing the pain involved in setting up things like https.

[mikeal]

What would be pretty amazing is if the build HTTPS hosting just used the same format/API as gh-pages (minus jekyll templates cause fuck that).

As far as the roadmap, I'm not opposed to putting it on HTTPS but we can't move off of roadmap.iojs.org. Once you've got a wildcard cert just start pulling it like we do the website and we can switch over the DNS.

[rvagg]

@indutny can you confirm that you only got a single-domain cert for iojs.org?

[snostorm]

One hole for the WG all running their own sites of GH pages, separate hosting, elsewhere, etc. is that it makes it really simple for somebody to hijack one of the "rogue" sites that are doing their own thing and then start to swap out download urls, etc.

\ I use rouge here nicely -- just to refer to domain / hosting outside of the iojs.org umbrella.

[snostorm]

Rephrasing, we should work with all WG to make sure build/website are meeting their needs for publication to help encourage them to want to use our resources. (Not mandate.) But really, no need for each group to reinvent the wheel on certain things either. If they have an improvement, we should encourage pushing them it upstream to help everyone out :)

[jbergstroem]

@snostorm Not sure what you mean here. I treat iojs.org and its hosting as inside the umbrella? It also currently caters all io.js downloads -- so if that'd be out of control we would have a bigger issue.

[snostorm]

@jbergstroem I refer to how the i18n groups have setup domain names like http://www.iojs.no/ -- which falls outside of our control. (The download link there could easily be redirected to some other URL if the domain/hosting was compromised.)

I'm agreeing we should give groups incentive to stay within domain names with trusted SSL :)

[bnb]

+1 for encouraging groups to use the official domain, within the trusted SSL. I think you nailed it with giving them an incentive. There should be a good reason for them to stay with the official domain, but they are free to use an external one if they wish.

[jbergstroem]

@snostorm ah, assumed for some reason that all published materal lived/was supposed to live at iojs.org.

[rmg]

@rvagg just to clarify:

• Is "strict https" in this context referring to HSTS (Strict-Transport-Security header)?
• Is the reason to discourage GH Pages because it doesn't support https with custom domains and we want to use *.iojs.org subdomains for all the things?

[rvagg]

@rmg yes, strict in the HSTS sense and also the fact that we have a redirect at port 80. Also yes on the GitHub Pages question.

[kenperkins]

@mikeal I'm not sure I agree this:

I'm not in to dictating to other WGs what they can and cannot use...

I feel like leaving to each WG to figure out how to communicate their efforts (especially with regards to localized websites) is a poor separation of concerns. It feels like the translation efforts should be focused on translating the content, and the website and/or build WGs should be focused on delivering this content in a consistent and secure fashion. @snostorm's comment highlights this: all it would take is for one of the localized sites (i.e. http://www.iojs.no/) to be compromised.

[mikeal]

@kenperkins The language communities aren't just translators, they are actually community hubs for developers in that language to interact with each other and the project.

When we post a resource that can be translated there is almost always an "easiest path" to publishing the translated content but if that community thinks there is a better way to publish it for their community we aren't in a position to tell them they are wrong. In the case of the website it's actually quite difficult to post localizations anywhere else because it's highly templatized and updated quite often, but still, if they think it's better for their community to post somewhere else I'm not going to stand in the way. We know very little about each community (we literally don't even speak the language), they are the experts and are autonomous for a good reason.

[kenperkins]

The language communities aren't just translators, they are actually community hubs for developers in that language to interact with each other and the project.

Good clarification. Thanks.

I'm going to reserve the right to disagree here, but I'm not sure it's a huge deal :)

[therebelrobot]

On the agenda for Mar 2nd Website WG meeting #240