This reminds me of https://github.com/jo-m/trainbot, a neat example of stitching together frames of passing trains to form a panorama.

This frontend presents them nicely: https://trains.jo-m.ch

Surprised I've never come across this idea before

For a long time I've wanted to install one of these to pull graffiti off of trains. As art goes, graffiti is one of the last 'free' expressions where it is essentially truly anonymous and definitely not for money. Being free of those constraints, I think, frees the mind to truly create.

And I'd love an archive somewhere of some of the truly awesome train art I've seen.

here you go... https://trains.jo-m.ch/#/trains/44010

This shouldn't be possible as the server-to-server request to Facebook to exchange the Authorization Code for an Access Token requires the client_id and client_secret to be provided. Facebook should (though I haven't actually confirmed this) verify that the code was issued to the given client_id. If the code was issued for client 123, when client 456 tries to exchange it for an Access Token Facebook should throw an error.

Yup that's the thing, Facebook doesn't do that. The token is the only thing needed, no validation on their half if it matches a client id

It's called Insulation Resistance Testing and an electrician would typically use a device like a Megger tester.

Here's a good video about it: https://www.youtube.com/watch?v=CsXUuuV4_sw

Oh, of course. I was not thinking right. I was imagining a 'chunky' HV supply rather than a hi-pot tester, like some Stanford Research PSU, but those only went up to a few kV if I'm remembering correctly. Thanks.

You have to draw the line somewhere. Otherwise we'd be saying that HTTPS/TLS is not secure since the webpage is rendered to your monitor unencrypted.

I agree with the parent quote:

> I’ve found statements like these to not contribute very much towards solving any practical security problems.

But HTTP/TLS indeed is not secure from the point of your local machine. Its entire point is protection of data in transit.

You might be interested in the full list of UK trail delay codes: https://wiki.openraildata.com/index.php/Delay_Attribution_Gu...

Those extenders typically backhaul the traffic over a VPN back to the telco, so your router would never see the true destination (e.g. Facebook).

I think they've always done this redirect. Release artifacts are uploaded to S3 and then their Rails app generates a presigned S3 URL that gives short-term access. This is because the artifacts could belong to a private repo, so access control is required.

You should first consider what you want to achieve from this “revamp”. Are you facing some issue with your existing tech stack?

I’m wary when I hear teams discuss a total rewrite of an existing application.

I’m building a side project that has an enterprise customer, and the Enterprise Ready website was a good intro to the concepts that enterprises value: https://www.enterpriseready.io

From my (limited) experience, one thing that enterprises love is asking you to fill out a 30 page security questionnaire. They take an age to complete so be aware of this if you’re thinking of going down the enterprise-sales path. I think it’s one of the big reasons that “contact us for pricing” exists for very large customers.

I think that site pretty much nails it, especially SSO (depending on what you're doing you probably want LDAP, SAML and OIDC/OAuth2) and audit logs.

It misses a couple of other nice to have differentiators, though:

The ability to pay by invoice to their purchasing department (you probably want to insist people do this upfront and yearly and not monthly, to avoid the pain of chasing people). Plenty of enterprises won't be able to buy your product without this.

Some decent consideration given to self-service (which RBAC might cover, but best to be explicit), by which I mean that you can delegate admin control such that you don't need to put in tickets with the team that runs the system in order to get changes made to its configuration. (Example: GitHub enterprise let's you set up multiple orgs, so you can give each dept. or team an org to do what they like with.)

If you put some thought into granular permissions from the beginning (in the GitHub case, for example giving away perms to create repos, but not allowing that user to change how auth works for the org, for example) you will avoid pain later.

APIs. Dependent on product, but ideally design your UI so that it is backed by an API that lets me do everything programmatically, so I can drive your product with other integrations via we hooks, or GitOps, or whatever else I want to do.

The article has quite a nice introduction to deep learning concepts, but the headline claim of building an ID card reader from scratch is little more than "use our API".

Ok, we've changed the title from "Building an ID card reader from scratch with deep learning" to the what the article's title says.