HN user

notoverthere

103 karma
Posts0
Comments27
View on HN
No posts found.

I'm not disagreeing about the severity of the security vulnerability that has been uncovered – to be clear, it's an absolute shocker of a bug. It's really disappointing to see.

But I still disagree that the use of Firebase, in and of itself, is a bad engineering decision. It's just a tool, and it's up to you how you use it.

Firebase gives you all features needed to secure your backend. But if you configure it incorrectly, then _that's_ where the poor engineering comes into play. It should have been tested more comprehensively.

Sure. You could build your own backend rather than using a Backend-as-a-Service platform. But for what gain? If you don't test it properly, you'll still be at risk of security holes.

DuckDuckGo also allows you to switch off ads, for free, without any fuss or adblocker needed. Just go to the settings page.

Although if you aren't going to support DDG with ad revenue, I'd suggest supporting with a donation if you can afford it and value their service.

Back in the early days of Docker, I did a whole bunch of work to make WordPress behave as a Twelve-Factor App.

It traditionally hasn't behaved as one – which sort of makes sense, because WordPress grew-up in a world where long-lived servers with writable and persistent local disk storage was commonplace.

I'm sure things have moved on since those days. This was back in 2016. But it sure was a fun challenge!

This isn't even a realistic use case of tracking. Nobody needs tracking cookies to get reminders about buying birthday cards.

Online stores can (and do) remind us about this stuff via email. No third-party tracking cookies needed – you're already a customer of theirs. If they want to get in touch, they already know your order history and contact details.

Or, you know, we can add our own reminders to a personal calendar.

Honestly, this is the reason why I think Google's Firebase (and accompanying Firestore database) is absolute gold.

Firebase handles all the complexity for you. You get a nice set of JS SDKs for auth, database, cloud functions, file storage and static hosting.

And the best part is how damn cheap it is.

No fussing with low-level Redis clusters or paying for things on the edge. It all 'just works' and it does it fast.

Switch the `<link href="">` value to point to a high contrast stylesheet.

Or alternatively, apply a class to the body tag – e.g. `<body class="high-contrast">` – and declare CSS rules accordingly. Specificity should take care of overriding the 'normal' style rules where needed.

I'd recommend you check out rclone. It's a command line tool, so you'd need to be comfortable in the terminal.

https://rclone.org/

It comes with an adapter for Google Photos, so you can use it to download / backup photos and videos in your library.

Note: there are some limitations to this approach – namely that rclone won't be able to download your original image files, even if you uploaded with 'original' quality. These limitations are documented on the rclone website: https://rclone.org/googlephotos/

This. If the link preview fails to load on the sender's device, it'll never appear for either party. The preview is sent along with the message – the receiving device never generates the preview.

If you're quick enough, you can see it in action:

Paste a link in a WhatsApp message. The preview might take about half a second to load. Hit 'send' before the preview has loaded, and it'll never show for that message.

Paste the same link again, but wait for the preview before hitting send. It'll stay attached to that message.

HTML is the Web 7 years ago

But according to the docs that's "for convenience". Its semantic value isn't discussed.

So presumably the 'proper' way to do it, if you're not looking for convenience, is to use `div`s. /s

Serverless backends tend to work quite well when paired with a Single Page Application on the frontend – e.g. Vue.js or React. That way your frontend can be served from a static host – e.g. S3 or GitHub Pages – almost instantly. And so the perceived performance of your application isn't harmed (as much as you'd think) by the latency of your backend, since other aspects of the application's interface can load and continue to be responsive.

Is the UK most advanced? In Australia they can pay for anything up to $100 with tap. Over $100, they can still tap, but then need to enter their PIN into the terminal (i.e. no need to insert the card for PIN entry – a tap is sufficient). We don't have that in the UK.

This sort of model also fits nicely with the AWS ecosystem. EC2 instances (virtual machines) can be given an IAM Role when they boot-up. An IAM Role is essentially an automatically generated access key which is unique to that EC2 instance, and has pre-determined permissions.

So in other words – a unique key is generated every time a virtual machine is created. It's fully automated, never shared between instances, and never needs to be handled manually. That key will give the virtual machine permission to access other AWS services, in this case the AWS Secrets Manager.

So as long as you're using EC2 instances, you won't need to worry about securely passing a 'master password' to your VMs in order for them to access secrets.

If you're interested in building it as a web app but want a keyboard-accessible grid / spreadsheet-like interface, then you have a few options.

The first resource I'd recommend is JSpreadsheets, which is a list of open-source JavaScript spreadsheet & data grid libraries. https://jspreadsheets.com

One of the most fully-featured JS libraries is Handsontable. It looks very flexible. They have some demos on their website to play with: https://handsontable.com/examples.html?headers

(Bonus: If you're using react, there's already a react component for using Handsontable: https://github.com/handsontable/react-handsontable )

I think @telesilla's point is that a Skype call would be going through all the cellular network's infrastructure, and then off to Microsoft, before coming back.

It's an extra link in the chain, meaning another potential bottleneck and added latency.