The real question is can Windows defender scan these drives?

I don't know what it scans in the background by default, but it can custom scan mounted volumes with no visible mount points assigned at all, e.g., my EFI partition containing a copy of the EICAR test file[1]:

  PS C:\Users\jtm> & 'C:\Program Files\Windows Defender\MpCmdRun.exe' -Scan -ScanType 3 -File '\\?\Volume{91ada2dc-bb55-4d7d-aee5-df40f3cfa155}\'
  Scan starting...
  Scan finished.
  Scanning \\?\Volume{91ada2dc-bb55-4d7d-aee5-df40f3cfa155}\ found 1 threats.
  Cleaning started...
  Cleaning finished.

[1] https://www.eicar.org/download-anti-malware-testfile/

I've been wanting to do this for ages. Originally I wanted to do this at the home router level, but that quickly got shut down when I got a test net up and running and my friends could control the Chromecasts in my house.

For us a "tailscale" equivalent with SoftEther is what we used to manage the DNS/Tunneling for our fileshare/services.

So cool to see more people playing in this space. Please post more! <3

Some people have just opened up their entire home networks, other people have VLANs set up and only share that VLAN with TPL. However, as written in the article, everyone knows at least a few other people on TPL and that interpersonal real life trust is what keeps people from screwing around on everyone else's networks. Everyone is also an adult.

I'm one of the people whose home LAN is completely exposed to TPL. There's an amount of "screwing around" where I wouldn't care. If you want to print an xkcd cartoon to my desk, fine, lol, a minor surprise in my day. If you print 1000 pages of dicks while I'm not home so that my paper and toner run out, that would be uncool. After years of caring about this problem, I came to believe that this kind of normative social contract cannot scale to include "everyone in the entire world," and that this kind of unwritten normative code is the only thing that makes any social space tolerable.

"How do you get corporate secrets out of a software engineer? Sit them next to another engineer on a plane."

It's elegant. The other person can spill amazing secrets, but there's no way to prove it, so nobody will believe you second-hand.

Well they aren't in Canada for me yet, but that's probably because we aren't the public that needs to know.

"Show me what you got"

WebWorkers do not have access to DOM.

I understand, but things like https://github.com/GoogleChromeLabs/comlink enable it. Similar to how iFrames don't have access to their parent page you need a facilitator. My question is why not use a js facilitator that could work in all browsers, rather than just Chrome.

I find it an interesting choice that the author decided to invest in new iFrame technology rather than existing multi-thread technology in the browser.

I don't think Comlink supports DOM as well. It's just syntax sugar over Web workers making them easier to use rather than providing new functionality over them.

That's part of the FAQ?

I see it now, I don't know how I missed it.

so I don't fully understand what you're preventing

    const db = await openDatabase();
    const keyPair = await getKeyPair(db);
    await crypto.subtle.exportKey("jwk", keyPair.privateKey)

exports the private key if I have a XSS vuln.

The recommendation for IP address in the JWT is good, but I don't understand your last recommendation of 1) sending the JWT, 2) additionally sending the base64 JWT in a header 3) sending the signature in the header. The crypto.subtle api only works on https domains so you're not defending against mitm attacks on unsecure networks either. And if we can't trust TLS what can we trust on the web?

> The recommendation for IP address in the JWT is good, but I don't understand your last recommendation of 1) sending the JWT, 2) additionally sending the base64 JWT in a header 3) sending the signature in the header. The crypto.subtle api only works on https domains so you're not defending against mitm attacks on unsecure networks either. And if we can't trust TLS what can we trust on the web?

So here I'm basically trying to describe what changes you would make to the way JWT validation is currently done. IIRC, the JWT goes over in the headers. I'm suggesting adding 2 headers - one with the base64 of the json of the JWT, the other header is the ecdsa signature of that.

This way, you know whoever it is that logged in and provided their signed public key, has to be sending this request because they signed it with the same key - which is locked to _this_ browser.

I'm confident then that you can skip the base64 encoded header and just have the server use the jwt passed in the bearer token and the new signature you propose. (As the base64 encoded version can be reconstructed from the JWT itself)

But I think ideally I would use a wrapped JWT with `"alg": "ES256"` and just pass it as normal in a bearer token[0] as JWTs natively support signed primitives.

[0]: https://jwt.io/#debugger-io?token=eyJhbGciOiJFUzI1NiIsInR5cC...

tbh, I haven't worked with JWT's a _ton_, so apologies if there's an _obvious_ better way to do something, lol.

I think you're right. Just sign the JWT that's going over as a header (as its a string), and add a signature from the webcrypto pieces - and BAM! you can verify that the jwt came from who it was originally assigned to...unless I'm missing something.

Rather than generating key data on the client in the open, and storing it in IDB, I would recommend the Credential Management API[0]. Hand off the responsibility to proper generation and storage to the user agent. Then do your signing of the JWT with them instead.

[0]: https://developer.mozilla.org/en-US/docs/Web/API/Credential_...

I'll have to check that out, thanks!

If it can store live objects - its perfect.

IDB is neat because it can store a PrivateKey Object whose `extractable` attribute has been set to false. So when you try to see the crypto data, you cannot.

When you `.get` a credential you can provide a challenge that it signs which you can make the JWT. With an added bonus that this passkey can exist on your phone or password manager which you can use to authenticate on a different device while still feeling confident in it's security.

TBH, I'm not an expert here.

What you're describing looks like webauthn which is used to verify the identity of a user by creating a private key on their HSM/TPM when the user signs up, and usually requires biometrics or a PIN iirc. This is used for future authentication events - which usually return a JWT.

This JWT that says "My name is Justin. I am logged in. I am an admin".

What I'm trying to solve for is "Make it so that the JWT doesn't work, except with the computer it was issued to".

In the setup I'm proposing, the JWT your server creates has your client's webcrypto Public Key in it (Naturally you verify it before putting it in there).

Now, whoever steals your JWT needs to be able to sign things with the private key that's locked on your browser - which is hard if you set it to inextractable.

Sounds like you are trying to prevent replay attacks.

How do you imagine JWTs are being stolen in the first place though? XSS sneaky websites or someone over the shoulder.

Just seems that if the attacker is all up in your browser extensions can't they just inject email and password text elements into the dom and see what gets filled by the browser saved logins?

Its not so much replay attacks I'm trying to solve for here ( although putting the instantiating user's IP address in the JWT seems like it would do a lot to thwart that )

I think the main thing here is preventing anyone from using my JWT who isn't on my browser.

Even if I'm on a site that leaks data via xss, and have several plugins that broadcast my cookies, localstorage, etc - and my live JWT and refresh tokens make it into the hands of bad guys; its worthless in the setup I'm proposing - I think...

OH FFS!!!!

Serves me right having ChatGPT add commentary and me not double checking.

This is what it should be:

          const keyPair = await crypto.subtle.generateKey(
            { name: "ECDSA", namedCurve: "P-256" },
            false, // this makes it not extractable
            ["sign", "verify"]
          );

Run that in HTTPS (here if you want) and try to extract the private key - I don't think you can, but could be wrong.

Yeah that does it for new keys generated, any old keys in IDB obviously still are exposed.

Not much here explicitly in the source code dump. A little insight into their worker node infra but no "secret sauce" imo.

Isn't the secret sauce just VNC with playwright? What more do you need to achieve 80% of what they are showcasing (basic doordash orders, spotify controls)?

I can't find any purported auomation scripts for those services as claimed in the Github page. There is a reference to "cm-spotify-client" which seems to be some sort of custom integration code they've written, but other than that there is no reference to doordash, midjourney, or uber eats. This dump seems to just be the code/infrastructure to run chromium/playwright in kubernetes, wrapped in a Node API to accept commands, persist/hydrate browser state, etc.

Is there a less convoluted less enterprisy implementation of such a project someone can point to. I was interested to see what is or isn't so intensive about it. Or is this a good scaffold to start a fork?

Hyperswarm has been my go-to for stuff like this, but you bring up a good point that I don't think it's encrypted.

https://github.com/holepunchto/hyperswarm

Quite a solid project and approach. Both founders seem smart and to know the problem well. I can see their new framework (Pear runtime) getting huge in the future.

Can hyperswarm be used to set up a generic IP network?

I don't know if 5 miles is long enough for the people who actually need it, but if I was a postal worker, these would be pretty sweet. And 1400 USD is cheaper than some car insurance here in Canada for young males.

My previous mailman was the walk, door to door type. There's all kinds of challenges...terrible roads, gravel, mud, having to walk through grass, etc.

I'm really skeptical these wouldn't just gum up after a few days.

Yeah and for $1400, wouldn't it make more sense to just get an electric scooter or bike?

You could have three electric scooters for that money and rotate them out in the mail truck as you tap out the battery on each.

At least in my neighborhood I think these would be more trouble than they're worth. It's a historic neighborhood so all the houses are built up on berms from when they dug the basements cuz the streets were full of muddy manure, so every walk up to a mailbox has stairs. Unless you're agile enough to go down stairs without doing the lock/unlock dance, these would probably slow you down overall.

Supposedly you can easily go up/down stairs with these as the wheels lock automatically. Not sure how that works.

Edit: In the video, it looks like a heel-up-toe-down motion with your right foot locks and unlocks the wheels.

I watched the video, which is why I called it the lock unlock dance. Note that in that video, which is obviously going to be the best looking version of it they can show, it's still a pretty significant pause in your motion, because the control is both motion and timing based. Doing that two times per house for the 10 miles or so a carrier walks is gonna get old.

It's probably simpler to walk up stairs with actual inline skates I expect

It has a 3.0 Ah battery (not Wh, assume one 18650 lipo cell -> 11 Wh), comparable with a smartphone or flashlight. At a full 300W discharge, you're emptying the batteries in just over 2 minutes. You'd better have well-insulated soles before stepping on a pair of 150W space heaters, also, no 18650s are rated for 100C discharge, 20C is a lot and 5C is more common for the high-capacity low-discharge 3.0 Ah cells.

You get 5 mile range by using them like roller skates, using your own legs to power them. The motors are just to aid in walking up stairs and such.