b6z

No slip up here. "Which?" is a consumer information and testing organization in the UK. https://www.which.co.uk/

When I have seen time estimates, everyone is referring to Mosca's Theorem. This is the idea that "store now, decrypt later", combined with the estimated time until a working quantum cryptanalysis is feasible, and a finite transition time for existing crypto standards and technologies (think update times for long-living tokens like ID cards with certificates) makes the available delay until a change must start quite short.

Dammit. This was also my first thought. Might consider it, if customs doesn't make it too expensive.

That sounds too negative. How about that:

"The prize-winning Excel service is in high demand right now. We apologize for any delay this might cause. Do you want to become an 'Excel Prime Plus User' with preferential treatment? Just upgrade your subscription now and increase your productivity!"

I don't understand what you mean. Half of the article is using jq.

It's mentioned and linked in the article. And "[i]t’s made by the same people that maintain Postgres.app."

I read on and on to find where the interesting, eye-opening, mind-boggling part started. Then the article ended.

> These are email companies.

ProtonMail and Tutanota, yes. Threema does secure messaging, Tresorit encrypted file hosting.

> With or without EU's snooping what is more likely to happen is that people will migrate to messaging systems that the EU can't snoop: WhatsApp, Signal, Telegram, etc.

Well, at least here in Germany people are more likely to migrate away from WhatsApp to Threema, Signal or Telegram.

I paid €0.80 for the app in 2014. Yes, that was a temporary discount, normal price was €2.99, I think. It is €3.99 now, single payment. I still wouldn't call that expensive.

I think one of the main problems protocols like XMPP and Matrix have to solve is the combination of good crypto + decentralization + offline-capability.

Most of my contacts (tech-oriented, Europe-based) are using Threema and I am most happy with it, especially because I do not have to share my phone number (or complete address book!). And the new video call capability is also working well. Unfortunately, most of the family is WhatsApp only. Since I will not use anything Facebook, they either have to use SMS or contact me via my wife.

Many years ago, I made that mistake two or three times, rebooting the wrong machine. Since then, I use molly-guard on all my remote machines. Never happened again.

One example, unfortunately not very scientific: Years ago, I had a bunch of Web comics I visited daily. To make this more efficient, I had a script on one of my servers which scraped the corresponding sites in the morning and produced the daily collection on a single page.

Every few weeks or months, one of the comics would just not appear or not be updated (i.e. there was the same strip day after day). I had to update the code each time, checking the source code and finding the new page and location of the image. Later, some pages started using JavaScript to load the image file, and I lost interest in sophisticating my script. So, no single page comic collection for me anymore. :)

  /* XPM */
  static char * treachery_xpm[] = {
  "10 10 1 1",
  "       c #0000FF",
  "          ",
  "          ",
  "          ",
  "          ",
  "          ",
  "          ",
  "          ",
  "          ",
  "          ",
  "          "};

X Pixmap format. Save as treachery.xpm. (Made using Gimp, because it was faster than writing by hand. Sorry. But I have generated large pixel files programmatically in the X Bitmap format, which is similar but only one bit color information. Easier than writing a GIF.)

That is a good argument, and I should have mentioned it, yes. For a one-off job, web scraping will probably be the best choice, and maybe even the fastest to implement. I have done my own share of web scraping for personal projects (and thus know about the fragility), but I didn't care much about broken results in the long run.

But in the article they mentioned re-running their program to update their data, so it could be a long-term effort. And anyone planning a long-term project reading that article and taking their advice should at least be warned about this possible problem.

I admit being a bit disappointed that a well-known disadvantage of web scraping was not mentioned: Web scraping is fragile!

Web sites change, web frameworks evolve, and just some subtle reordering of some <divs> or renaming of CSS classes, and your perfect scraping code from yesterday will break tomorrow -- maybe not leaving you empty-handed, but probably missing some data or delivering the wrong one.

If there is an API you can use, use it. If your budget allows to pay for API access, buy it. APIs tend to be more stable than scraping, and the data provider will probably inform you if it changes. Contacting them might even get you more interesting data, as not every column they have in their database might become published on the web site.

I absolutely agree with you. I have more trust into my local European ISP than into Google, Cloudflare and such.

Same for me.

From Kromtech's article I deduced that this only happens when a docker daemon (or kubernetes interface) is exposed to the Internet and an attacker uses that to download and start a docker image on the victim's host. Then they can bind mount a host directory like described and attack the host computer.

I like the included http://perldoc.perl.org/perlpacktut.html.