abritishguy

It is hard to make something that isn't being used somewhere in the fortune 500. Completely meaningless.

I work for a startup bank in the UK (Mondo). Our Go microservices architecture allows us to maintain velocity whilst staying secure.

The core banking services that actually move money around are isolated from the more "fluffy" customer facing ones that we want to be able to push updates to several times a day. We have to have incredibly rigorous procedures for updating services that control money, if we had a monolithic architecture then these procedures would have to be used even if the change was simply cosmetic.

I would concede that it only happens at scale but I would contest that it is rare.

Given they are managing the certs anyway they can revoke on behalf of the "average pleb", Just like CloudFlare did.

It is debatable how useful revoking is anyway so I agree that this provides more security, I just wasn't sure (until reply from Sandstorm) whether it would be worth the effort of setting up private key rotation.

It would be nice if you included the financial motivation in the article as well. Makes total sense, and I totally agree that 7 day certs are better (security wise) than 1 year, I just wasn't sure that in the absence of any financial motivation whether it would be worth the effort (having to roll private keys every week) for the limited protection it gives you.

Which is why we need a new micro-transaction system.

A requirement of the SSL provider, it doesn't really do much to protect against heartbleed like vulnerabilities - just limits the time an attacker can use the key to 7 days.

>To solve this, Sandcats issues certificates valid for only seven days.

I'm not sure I'm convinced that the primary motivation for the 7-day certs was users security.

Down again

Just say you are leaving the country - no more rententions.

>Who buys a car based on the software?

I imagine in the next few years more and more people will. Tesla have just announced that they will have self driving cars in 3 years.

The article seems to be quite US centric when talking about regulation. The UK banking market is very different than the US with just a handful of banks. The regulator is actively trying to increase competition. Atom, a new challenger bank just got their banking license and Mondo (where I work) is on its way.

We are looking to differentiate ourselves by simply not sucking, providing features people want when they want them not two years later. Water bill doubled this month, we'll flag it. Salary not come in when it should have, we will send you a notification.

Api? Yup

Simple.

The only one of them that is not doable is the cheque deposit as in the UK the bank needs the physical cheque.

Nothing stops you using javascript in your own packages

I hope from this we get a really well engineered standard and not some silly mess.

Some really bad text contrast on that page.

Apple need to be careful, I'm surprised they haven't had an antitrust lawsuit already.

SF takes over abandoned projects and ads the adware themselves.

Typical request: "X-AppEngine-Resource-Usage ms=259 cpu_ms=4"

That particular request is authenticated, writes a file to google storage, and then returns a response (with a few other things like logging etc.)

>meaning each request must take substantially less than 10 ms

Correction, each request would need to have less than 10ms of CPU time - the instances support concurrency.

My web frontend, by design, does very little - any CPU heavy operations are done by other systems using the task queue. Writing it in golang has helped as well, wouldn't get that performance from python.

Write a simple Hello world example in golang and get it to do some mathematical calculations to simulate "work", I think you'll be surprised at how many requests a second you can squeeze out of a single instance.

Before the pricing change app engine did not support concurrent requests to a single instance for python. As a result, applications used many more instances than they needed.

When using the calculator this would make the price increase seem enormous to many customers. When concurrent request support was added (it was available to trusted testers at this time) all a user would have to do was add "threadsafe:true" to the app.yaml file to enable it (assuming their code wasn't doing anything silly).

This doesn't surprise me at all. It is trivial to run a site on app engine that can handle hundreds of requests a second continuously without leaving the free tier.

Sure, when the change from billing CPU time to instance hours came in some app's bills sky-rocketed. But that was because they were poorly coded such that instances were blocking and unable to serve incoming requests.

With a thread safe application and the proper configuration there is absolutely no reason why instance-hours pricing shouldn't be competitive.

I'm happy to accept that risk

I am so tired of this response.

Claiming that I don't personally feel the need for a fully enclosed, solid steel cubicle to get changed in doesn't mean I'm happy to get naked in public. I feel that whilst the changing cubicle you find at a public swimming pool wouldn't prevent a determined actor from invading your privacy it provides adequate privacy for me.

Yes, servers at Google can read my email - I'm willing to accept the risk of a Googler committing a fireable offence and going through my emails.

I don't need the extra security provided by end-to-end encryption for the vast majority of emails I receive and send. I value that ability to search/filter these emails far more than I value the security.

For the few emails I send where the value of the security provided exceeds the lost value due to being unable to search I can, using their extension, enable end-to-end encryption.

This system suits my needs perfectly, I appreciate that others may want all the emails they send to be encrypted but why should Google cater to this - they cannot make any money from encrypted emails.

Based on logs it would seem that the crawler, or at least parts of it are written in golang. When following some redirects the useragent would be cleared and would identify itself as golang.

This new direction that MS is going in is very interesting

The oyster travel cards in London are Mifare cards (not actually classic ones though) but the system was designed in a way to be resilient to attacks on the card.

When you tap the card on the reader the transaction happens locally with the card and the reader, this means that there is no latency and the system can continue to operate even if the central server goes down.

Every minute or so the machines sync with a central server and if at any point a machine saw a card with a balance or journey history that conflicted with the server copy then that card gets blacklisted and no machine will accept it any more. This means if you clone a card you can use it to start your journey but by the time you get to your destination you won't be able to get out.

It was a piss poor system if all he did was "change the time"