Archive for January 17, 2020

Friday, January 17, 2020

The Flask Mega-Tutorial

Miguel Grinberg:

Welcome! You are about to start on a journey to learn how to create web applications with Python and the Flask framework. The video above will give you an overview of the contents of this tutorial. In this first chapter, you are going to learn how to set up a Flask project. By the end of this chapter you are going to have a simple Flask web application running on your computer!

Via Sean Heber:

[It] is quite possibly the best and most complete technical tutorial I’ve ever come across.

Malicious WebAssembly

Catalin Cimpanu:

In an academic research project that was carried out last year, four researchers from the Technical University in Braunschweig, Germany, looked at WebAssembly’s use on the Alexa Top 1 Million popular sites on the internet, in an attempt to gauge the popularity of this new technology.

[…]

However, while the vast majority of samples were used for legitimate purposes, two categories of Wasm code stood out as inherently malicious.

The first category was WebAssembly code used for cryptocurrency-mining. These types of Wasm modules were often found on hacked sites, part of so-called cryptojacking (drive-by mining) attacks.

The second category referred to WebAssembly code packed inside obfuscated Wasm modules that intentionally hid their content. These modules, the research team said, were found part of malvertising campaigns.

Via Kyle Howells:

WebAssembly should be a user opt-in per website feature.

App Movement Monitoring

Daniel Jalkut:

Essentially, when a Mac app is launched, the location of that app on disk is saved, and used repeatedly whenever an internal component needs to located. The dynamic nature of resource loading in Mac apps means that these components are not typically loaded until they are need. For example, if you never show the Preferences window in a typical Mac app, the resources that define that window will never be loaded.

If, on the other hand, you decide to show the Preferences window, but you’ve moved the app since it was launched, things have a tendency to go haywire. The app will go searching for its Preferences resources in the location on disk where they used to be, and it won’t find anything.

Why doesn’t Cocoa use file reference URLs to delay resolving the path until it’s actually needed, like it does for the document architecture? Or at least try to prevent users from moving apps that are open?

Paul Kafasis:

To avoid these issues, the Finder already works to avoid multiple types of changes to running applications. For instance, if you try to delete an application that’s open, the Finder stops you[…] As well, if you attempt to rename an open application, the Finder will warn against it[…] However, while any Unix geek can tell you that a rename is really just a move by another name, the Finder does nothing to stop you from actually moving the app.

Paul Kafasis:

I discussed this issue with Daniel and Brent, and provided them with the code we’d been using to watch for this issue. This actually led us to make several changes and tweaks, and a simplified implementation of this “Application Moved” watcher can be found below[…]

RSAppMovementMonitor:

RSAppMovementMonitor handles the nuanced details of monitoring for the movement, prompting the user, and relaunching the app[…]

This is more complicated than it seems, due to quarantine, translocation, sandboxing, and need to preload any localized strings before the app is moved.

The latter was surprising to me, but I recently ran into a similar issue when updating my apps to en.lproj instead of English.lproj.

Previously: