SN 876: Microsoft's Patchy Patches

Beep boop - this is a robot. A new show has been posted to TWiT…

What are your thoughts about today’s show? We’d love to hear from you!

I was listening to Steve and @Leo talking about the 3rd party cookies In Firefox and how his cookie forensics page was showing that the new Firefox siloing of 3rd party wasn’t working.

I think he was talking at cross purposes, or I misunderstand how his forensics page is working.

The Firefox feature will not block 3rd party persistent cookies. It, by definition won’t do that, that is the whole point. It Silos them to the first party site you are visiting. The 3rd party then has a unique cookie for you for each site you visit, so the sites you visit still work (logins via Google or Facebook, for example), but they can’t follow you from site to site, because you will always have a different unique cookie for each first party site you visit.

That means a Facebook will see you at GRC, for example, and it will see you at Forbes, and it will see you at Medium and it will see you at Facebook itself, but it won’t know that they are all you, because each cookie is siloed to the first party site.

Or have I misunderstood something?

(By the way, Safari on my iPad got a clean bill of health on GRC, probably because of my PiHiole.)

1 Like

The more I hear @Leo and Steve talk about the FIDOfication of our devices, the more I think: why the heck does this monstrosity exist? And then I read the white paper

If you read about how the “multi-device” FIDO spec works, you will find that they have a “fallback option” for the multi-device setting: if you try to log in from your Windows computer which doesn’t have the credential, it will find the nearby Bluetooth-connected phone that does have it and give you some kind of notification on the phone. You would then complete the sign in process on that device. There is no talk about what happens after that one authentication.

Okay, can we just take a minute and think about how asinine this is?

So they know full well that you will come up against synchronization barriers. Indeed, they talk about it a few times in the paper.

To sidestep the issue, they have a local fallback, where they either (1) just shoot out a cry for help on Bluetooth and ask any unauthenticated device for the credential or (2) they know full well which devices are trusted and authenticated to you and simply query them for the key. If the answer is (1) I will look forward to Steve’s future episode, but let’s just assume it’s (2).

So why is syncing even needed at all? If I have already connected and authenticated my devices by Bluetooth (dare I say it, synced them), my devices should just share all of their credentials using an encrypted transfer by Bluetooth with a simple one-time dialog on the successful authentication event (Would you like to share keys across devices?). There is already a P2P implementation in the spec—just use it!

I think you’ve hit the nail on the head:

Total Cookie Protection works by creating a separate “cookie jar” for each website you visit. Instead of allowing trackers to link up your behavior on multiple sites, they just get to see behavior on individual sites.

So Steve’s test proves that it isn’t not working. He would have to create a third domain linking to the first or second. Each page would have to report an identifier in the cookie available to each page. If the ids are different, chef’s kiss. @Leo got one of those Hover domains ready for him? :wink:

PS, Firefox Container tabs are the most awesome feature ever. Do your shopping in a shopping container and you’ll never see 20 ads for a pair of shoes again.

1 Like

That would be good, except for 2 things:

  1. I don’t have BlueTooth on my Windows PC
  2. I am not allowed to connect a BlueTooth device to my work PC
  3. If I am at work, the same would apply for Wi-Fi, phones aren’t allowed on the company Wi-Fi.

Given that I would have my private IDs on my private phone, that would be a real problem.

What is when you are using a “public” terminal? Oh, wait, that won’t have BlueTooth enabled anyway (or USB either, for that matter).

A better solution would be a QR Code on the screen on the un-synced device, which the synced device could scan to then send out an authentication code to the registered website. Oh, wait, SQRL does that already.

Why don’t FIDO just buy up the rights to SQRL or ask Steve to allow them to implement it as the FIDO3 standard? It sounds like it would solve a lot of the problems FIDO is having.

Nor would you want to log in to cloud services on the computer…

Sounds like a job for Bitwarden! :sweat_smile:

Agreed.