Dran_Arcana

It's a hardware defect that requires a very specific workaround. More likely it's just a regression that nobody thought to make a test for and it slipped through the cracks because modern developers aren't likely using workstation/consumer CPUs from that era anymore.

Very cool idea, but I think general-use practicality goes out the window when you list

Wildly unpredictable precision

As a feature

It was an adblock-spcific paywall

What browser/adblocker(s) are you running? (For everyone else, simply blocking JavaScript on their main domain seems to do the trick)

Outlook being on that list is crazy.

I don't know of any off the top of my head, but with a cheap digital caliper and tinkercad, I assume you'd be able to model one fairly trivially. You could friction-fit two halves around the cable, and secure it with some simple adhesive, or some kind of simple bolt/nut fastener mount if you wanted to get clever.

Never not learn a new skill!

Depends on where you work and what their policies are. My work does have many strict policies on following licenses, protecting sensitive data, etc

My solution was to MIT license and open source everything I write. It follows all policies while still giving me the flexibility to fork/share the code with any other institutions that want to run something similar.

It also had the added benefit of forcing me to properly manage secrets, gitignores, etc

The canvas API needs specific access to hardware that isn't usually available via browser APIs. It's usually harder to get specific capability information from a user's GPU for example. The canvas API needs capability information to decide how to draw objects across differently capable hardware, and those extra data points make it that much easier to uniquely identify a user. The more data points you can collect, the more unique each visitor is.

Here's a good utility from the EFF to demonstrate the concept if you or anyone else is curious.

https://coveryourtracks.eff.org/

If you made that naan at home I need the recipe!

Just think, an extra long shirt can cover that hole, and we could embed a flexible display, wifi module, and a camera in the extra space. This could scan the faces of those around you, and display personalized ads! This is an excellent solution to the hole in your pants, and frankly, the only secure one.

You're correct that nesting namespaces is unlikely to introduce measurable performance degradation. For performance, I was thinking mostly in the nested virtual network stack adding latency. Both docker and lxc run their own virtual interfaces.

There's also the issue of running nested apparmor, selinux, and/or seccomp checks on processes in the child containers. I know that single instances of those are often enough to kill performance on highly latency sensitive applications (SAP netweaver is the example that comes to mind) so I would imagine two instances of those checks would exacerbate those concerns.

There are security performance and capability concerns with that approach, apparmor on the first layer lxc probably being the most annoying.

If you want to isolate your docker sandbox from your main host, you should use a vm not a container.