I lead the security and safety team for Wikipedia, at the Wikimedia Foundation. I’m hiring a product manager to lead our security roadmap and steer the priorities of our security engineering team.

It’s a high-pace, shipping-heavy time for the whole project right now, as we are dedicating ourselves to surviving all the ways AI is messing with us and the internet, and getting to the other side of it. I joined myself about a year ago, and have found it to be a great time and place to swing big and surprise people.

This is a PM role and PM background is certainly helpful, but it’s not strictly required (everyone has the first PM job at some point). A technical background and security expertise are a must for this role, so we’re also open to people in engineering roles, who have demonstrated PM-relevant skills and are interested in making a pivot.

You can apply at https://job-boards.greenhouse.io/wikimedia/jobs/8140060?gh_s... - we don’t auto-filter based on AI or anything like that, I will personally see your resume.

In those 5 years, HTTPS has gone from being the minority of traffic to being ~90% of the connections observed by most Chrome clients (scroll down a few graphs for the Chrome-observed one): https://transparencyreport.google.com/https/overview

Firefox has reported similar numbers. It's now more common for new web features to require HTTPS when they are introduced, to avoid developing HTTP sites as dependencies: https://blog.mozilla.org/security/2018/01/15/secure-contexts...

That doesn't mean that HTTP is banned, but given the magnitude of the change and the size of the web, I think it's fair to say that it's being deprecated.

More practically, anyone who wanted to build a product (or a government process) on intercepting or modifying people's unencrypted web traffic would find their dataset to be an order of magnitude smaller, and orders of magnitude less useful (since so much of the remaining HTTP traffic is in the long tail of small/older sites).

Comments URL: https://news.ycombinator.com/item?id=15509737

Points: 11

# Comments: 2

But to answer your other question, as part of the Department of Commerce, a "CFO Act" agency, USPTO would not be exempt.

Also, the DoD CIO has had, since ~2003, this excellent FAQ supporting open source:

http://dodcio.defense.gov/Open-Source-Software-FAQ/

But as people on this thread and elsewhere will tell you, that hasn't resulted in widespread support at DoD for open source.

https://https.cio.gov/certificates/#http-public-key-pinning

From an integrity perspective, connecting to alerts.fema.gov over HTTP does potentially subject the user to code injection attacks. Those do happen:

* https://arxiv.org/abs/1602.07128

* https://citizenlab.org/2015/04/chinas-great-cannon/

* http://www.forbes.com/sites/kashmirhill/2014/10/28/find-out-...

Now, are any of these likely to happen on an arbitrary request to alerts.fema.gov? Maybe not. (Especially since Verizon has since been fined by the FCC.) But I'm trying to point out that it's not just the service owner whose safety has to be weighed in policies like this.

FWIW, the GSA plan announced in this post is intentionally crafted to be gradual and to avoid breaking things. It only affects future domains, not present ones, and so we'll have plenty of time to see whether being a total hardass about HSTS causes negative effects. Agencies can still do specialized services on their existing domains.

There's also going to have to be some carveout somewhere for specialized services like OCSP/CRL, which are already exempted from the policy mandate that came out in June 2015:

https://https.cio.gov/guide/#are-federally-operated-certific...

But in any case, the push should be, clearly and loudly, towards changing the defaults that browsers and users accept, and I think GSA's change weighs the tradeoffs appropriately in making such a push.

The one downside of includeSubDomains is that, with dynamic HSTS (without preloading), you have to get the user to visit https://agency.gov to "see" the HSTS header once to get that coverage. Visiting https://www.agency.gov or http://agency.gov won't do it.

So another benefit of preloading is that you remove that problem from the table -- browsers will enforce HTTPS for all subdomains, even if the user has never visited the root site. It's a powerful tool, and there is no analogue for other protocols (like IPv6 or DNSSEC) to set policies for an entire zone that you can expect most clients to enforce.