pde3

And then check out this very cool project from six years ago, which uses a block-stacking game inspired by Shrdlu but learns whatever language you choose to teach it instructions with :) https://shrdlurn.sidaw.xyz/

This is a nice fantasy, but it's a fantasy. The tech stack and network we have is too dense a forest to be replaced by clean slate designs. But maybe some of the problems could be improved with some new platforms and APIs. Mind you, ML is making so much progress so quickly that what happened over the last thirty years is at best a partial model of the problem we have to solve now, and the tools we have to do it with...

A possible experiment to try: what happens when you only browse Reddit through an anonymous, not-logged-in browser and IP address? And then only use your account when you are actually sure you want to post something?

Split this into two questions:

(1) Why do we procrastinate? (2) What is it about various Internet platforms and patterns that makes them so addictive, and good for procrastination?

For me, (1) turned out to be about not having a clear picture of what exactly I needed to do next for my goals, and sometimes not having enough social reinforcement and accountability for the things I'm working on; (2) there are lots of tricks and accidents that have made modern platforms really addictive, but one of the big ones is uncertain reward. I reload all sorts of things hoping for something new and interesting. Noticing that pattern is the first step to damping it.

How do you find the RF performance? For me the OnHub was vastly better than other home wifi gear I've used, but would consider more trustworthy replacements if they have comparable performance...

In addition to tests, I wonder if anyone has thought about a risk pool where car manufacturers pay in (or are paid out) according to whether their vehicles cause more or fewer pedestrian & cyclist fatalities. That would give them a clean incentive to optimise for reducing risk to others...

Many workers experience monopsony for their labor for reasons that might not make sense to you (switching costs, rational risk aversion, fallible human psychology). A union on their side just levels the playing field. Empirically, societies that support monopoly bargaining by unions (and structurally encourage creative thinking and incentive alignment between unions and employers) have become much better places for their worst-off cohorts. Possibly not better if you're a smart and talented entrepreneur or highly skilled technologist; parts of the US are clearly great for that. But you may have to step over homeless people to get to work.

Yes, this is one specific safety problem -- there are many other RL safety problems that deserve high quality benchmarks too. See eg https://arxiv.org/pdf/1606.06565.pdf or https://medium.com/@deepmindsafetyresearch/building-safe-art... for discussions of the problem space.

The problem is very easy to solve if the reward function (avoid altering the green life patterns) is specified. The aim in SafeLife version 1.0 (future versions will add more safety problems) is to find an agent/architecture that naturally has conservatism with respect to side effects, without being told which particular side effects in particular are bad.

We spent a lot of time thinking about this before we started building Let's Encrypt. In the case of the Web we didn't think there was a way to make self-signed certificates workable for anything because older browsers will always error on them. In the case of mailservers, self-signed certificates work for enabling TLS, and that's great, but you're extremely vulnerable to MITM attacks. So this project offers a way to prevent the MITMs, if you want it.

If there aren't major technical obstacles we might be willing to take pull requests for STARTTLS Everywhere that allow mailservers to announce self-signing policies, but it hasn't been a priority thus far because LE certs are so easy to get and are slightly more authenticated.

We think we can make a huge difference even by listing a few dozen or a few hundred of the highest-traffic email domains.

We did think about those issues before writing the piece.

It's safer to figure out how to get AI systems to be robust, reliable and safe in civilian contexts before rushing to weaponize them. We need to understand how to avoid technical problems like adversarial examples, and how to recognize and avoid accidental action-reaction-escalation pathways, before militaries start deploying this stuff.

Objectively speaking, the US is one of the planet's more belligerent nations. But if there was evidence that other belligerent countries were already deploying AI weapons systems, there might be an argument for the US keeping pace. If there isn't such evidence, the US should think more carefully about whether to move first, and how to move first, or whether certain kinds of restraint in this space might be in its long term strategic interest.

Turns out "anyone can edit" also meant anyone could mess with the sharing settings. So I've made it read only, which is a pity. Will investigate alternative hosting arrangements that might support pull requests at some point...

Which is what stopped me from using them for some serious crowdsourced data projects in the past. This was a sheet I had lying around anyway and thought others might find useful :)

Might be nice to have someone define a clean 1:1 mapping between a google sheet/airtable and a git repo...

Heh, you might be right :)

You should consider adding gradients in addition to flat colors!

EFF and other privacy groups fought against this for a long time, and eventually succeeded in having the FCC intervene to stop these practices: https://www.eff.org/deeplinks/2016/03/victory-verizon-will-s...

Then one of the first things Trump and the Republicans in Congress did after the election was repeal the FCC's privacy rules :( https://www.eff.org/deeplinks/2017/03/five-ways-cybersecurit...

Yes, we've also thought about the "meta metric" idea. We may try to make one if we feel that the taxonomy is at all complete and trustworthy.

You're asking great questions :)

EFF isn't necessarily a fan of the way that current institutions of governance or the law operate, but when those institutions attempt to interfere with the development of technology, we step in to try to mitigate the damage and make the case for sensible outcomes.

In the case of general-purpose human level AI, which to be clear is an extremely speculative kind of technology that might not happen in our lifetimes, I don't think anybody knows how humanity would deal with it. If it does happen, I think the biggest responsibility of participants in that process would be to minimize the risk of instability and conflict while humans and the new species (possibly species, plural; possibly not a species at all), figured out how to relate to each other.

How best to accomplish that is largely a very difficult and mostly unanswered research question, though you can find some pointers to some interesting early work in the safety section of the Notebook.

The measurements for each metric are tabular, but the taxonomy of problems above them is currently tree (or forest) structured.

CSV export or import for specific metrics would be very easy to add if you'd like it. We already have a rough JSON export of the data:

https://raw.githubusercontent.com/AI-metrics/AI-metrics/mast...

A couple of suggestions based on recent (0.5.0+) Certbot features:

1. You can now do certbot certonly --post-hook "service XYZ reload" to run something if and only if certs were obtained / renewed. Or if you use the renew verb, you can use --renew-hook to get a callback for each renewed cert individually. See certbot --help renew for details.

2. You can set "quiet = True" to minimize output from the client (but see https://github.com/certbot/certbot/issues/2990)

Yes certbot-auto should work on Raspbian 7 but note you'll need a large swap file enabled in order for it to succeed at building the recent version of python-cryptography that it depends on:

https://github.com/certbot/certbot/issues/1081

This is resolved by .deb packages; they're available in jessie-backports, but I'm not sure if/when those will ever make it to Raspberry Pi land.

Certbot supports both use cases; "certonly" stops after getting the cert; "run" installs it if there's a plugin available for your webserver.

You can now get those instructions in concise form from the simple widget at https://certbot.eff.org.

Let us know if there are any tweaks you'd like to see made to them (or send a PR to https://github.com/certbot/website, the instructions are in _scripts/instruction-widget)

Perhaps you mean HPKP, not HSTS?

We're working on it: https://github.com/certbot/certbot/issues/2782

At the moment you can get that behaviour with "certonly --csr". You'll need to make a CSR file yourself. It'll drop your cert and chain files in the current directory. You'll still have an account key and some other ACME protocol housekeeping state in /etc/letsencrypt.

https://github.com/certbot/certbot/issues/2373 will track implementation a nicer version of that functionality; it'll probably be --no-lineages (lineages are Certbot's notion of a succession of renewed or updated certificates that replace each other; they live in /etc/letsencrypt/live, though you can put them somewhere else with the --config-dir option)

Hooks to perform arbitrary restarts and housekeeping upon renewal were added in version 0.5.0. Run with "--help renew" and/or see https://certbot.eff.org/docs/using.html#renewal

This is a discussion about letsencypt-auto, not the underlying letsencrypt/certbot program. Here's what the docs said about letsencrypt-auto:

"Because not all operating systems have packages yet, we provide a temporary solution via the letsencrypt-auto wrapper script, which obtains some dependencies from your OS and puts others in a python virtual environment: <instructions to download and run letsencrypt-auto>"

If users don't read the label before downloading and running a script, they might be surprised by what it does. But we've learned that users don't read those instructions and get upset anyway, so cerbot-auto now asks for additional interactive permission before installing things.

This should be fixed in the new release. For backwards compatibility we've kept the behavior of letsencrypt-auto the same, but certbot-auto will request (Y/N) permission before installing things.

For the many folks who want the previous behaviour, they'll need to run certbot-auto --non-interactive (-n for short).