wftglf

Disappointed to discover OP didn't actually go and eat in all the kebab shops.

Hmm but is it excellent for kebabs? I'm more a falafel person so can't really judge but I think crystal kebab is the only one and it doesn't do any form of deep fried chickpeas I rate the chinese place over the road though!

I wouldn't say it's wanton abandon - here is a deeper explanation of the threat model of SecureDrop workstation https://github.com/freedomofpress/securedrop-workstation?tab...

Hey, author of the post here. I've had quite a bit of feedback on the post from some people with a lot more Qubes experience than me - there are definitely some issues with it - e.g. you can install software from non-default repos in Qubes without setting a netvm for the template. We'll publish an edited version soon in case anyone else stumbles across it.

"Qubes is awesome, but it's no substitute for an air gap." - agreed - for some stories an actually air-gapped machine is essential - if nothing else just because it's very easy when messing round in Qubes manager to add a netvm to the wrong Qube.

However, of the stories we receive coming through SecureDrop system, many don't have the risk profile of something like Snowden - e.g. a local politics story that GCHQ aren't likely to be too fussed about. For these cases, it's helpful to have an environment which is secure, but has a browser available for e.g accessing our CMS or doing research.

On our team we swapped databases 6 times in a year. We’ve landed on Aurora Serverless V2 – was it worth it?

Nice work! In the past I've used https://privnote.com/ for this kinda thing but it doesn't allow as short self destruct times

It's not too long ago they would ask for information faxed using company letterhead, as a form of legitimization.

I had PayPal ask me for exactly this (emailed rather than faxed) recently for my PayPal business account!

No, I think it's on our own infrastructure.

It's the same system, just without any tags on it that mix it in with editorial content. I think if we wanted it published somewhere like the technology section we'd have had to go through a much more rigorous editing process (we probably wouldn't have got away with 3000 words!)

The main advantage of the migration was getting onto a fully managed DB. What we didn't mention was that there were also huge cost implications - savings of ~£40k - through switching to RDS - compared to paying for a mongo support contract.

In a happy world the guardian wouldn't rely on a company we spend a lot of time reporting on for unethical practices (tax avoidance, worker exploitation etc.) - but we decided it was the only way to compete. One of the big drivers was a denial of service attack on our datacentre in 2014 on boxing day - not an experience any of us want to have to deal with again.

Thanks to hacker news and reddit this piece got over 100,000 page views which should be enough to justify the blog staying on platform!

Sadly we don't trust our security practices anywhere enough for that! Secret investigations happen in an air gapped room on computers with their network cards removed then get moved across to the main CMS when they're ready to publish.

Yep that's what we were doing, and the management software (OpsManager) was also running on EC2 instances. We messed up the VPC configuration so that NTP didn't work on some of the instances - which unsurprisingly broke authentication between OpsManager and the db instances

Yeah it did take a long time! Part of this though was due to people moving on/off the project a fair bit as other more pressing business needs took priority. We sort of justified the cost due to the expected cost savings from not paying for OpsManager/Mongo support (as in the RDS world support became 'free' as we were already paying for AWS support) - which took the pressure off a bit.

Another team at the guardian did a similar migration but went for a 'bit by bit' approach - so migrating a few bits of the API at a time - which worked out faster, in part because stuff was tested in production more quickly, rather than our approach with the proxy which, whilst imitating production traffic, didn't actually serve Postgres data to the users until 'the big switch' - so not really a continuous delivery migration!

Hi! I'm one of the authors. Good point, we should add something on that. Briefly our mongo db setup was running on 3 r4.xlarge instances which comes to around $5000/year with storage, plus the cost of opsmanager, which I think was around £40,000 including the support contract.

In Amazon it's harder to compare directly as the support contract is paid across all of our accounts, but we're spending around $13,000 for a highly available db.r4.xlarge postgres instance.

Performance wise, querying without an index is SLOW, basically not worth it - as we end up doing a scan of the entire database. Fortunately we don't need to do this as we can usually rely on the guardian content API for proper searching stuff. The average API (a Scalatra app) response time reaches 150ms at 'peak time'. This isn't a high-performance use case - around 1000 requests/minute at 'peak' time.

Fair criticisms! It's true if we'd used Mongo Atlas or something similar it would likely have been a different story - often the MongoDB support spent half the time on the phone trying to work out what version of mongo, opsmanager etc. we were running.

Re criticism of OpsManager - I think this is fair, given the sheer number of hoops we had to jump through to get a functioning OpsManager system running in AWS - no provided cloudformation, AMIs etc. £40,000 a year felt like a lot for a system that took 2 or more weeks of dev time to install/upgrade. The authentication schema thing was a bit of a pain as well, though we were going from a very nearly EOL version of Mongo (2.4 I think).

Hi! Thanks for your comments. I'm one of the authors of this post. It is the same platform at the moment (just not tagged with editorial tags so it stays away from the fronts), though sometimes the team that approves non-editorial posts to the site can be concerned about us writing about outages and things as it might carry a 'reputational risk', so we may end up migrating to a different platform in the future so we can publish more quickly, we'll see!