Their list of supported sites isn't a declaration of where you should use this tool for moralistic reasons. It's just a list of popular sites it works on.
For Firefox Send, it was actually malware and spearfishing attacks that were spread.
The combination of limited file availability (reducing the ability to report bad actors), as well as Firefox urls being inherently trusted within orgs (bypassing a lot of basic email/file filtering/scanning), was the reason it became so popular for criminals to use. Like we've seen in the spearfishing attacks in India[1].
This is Bridge leveraging failed talks for future funding rounds or in hopes of finding another faster buyer. Stripe has been making a plethora of acquisitions recently, but have kept all of them quiet and mostly directed towards tiny teams that were covering blind spots for Stripe.
I just don't see how any of that aligns with Bridge, not when Stripe has already been implementing crypto related features and is well positioned to offer everything Bridge does without the $1B purchase cost for a company that can only get valuation at 200m.
Odds are they have Resist Fingerprinting turned on. When I use it in a Firefox profile I encounter this all over the place. Drupal, FedEx.. some sites handle it better than others. Some it's a hard block with a single terse error. Some it is a challenge which gets blocked due to using remote javascript. Some it's a local challenge you can get past. But it has definitely been getting worse. Fingerprinting is being normalised, and the excuse of "bot protection" (bots can make unique fingerprints too, though) means that it can now be used maliciously (or by ad networks like google, same diff) as a standard feature.
I also use Mullvad Browser (a browser based on Firefox), and it supports resisting fingerprinting without any of those blocks. Tried it on Drupal and Fedex. Loads Cloudflare sites normally.
I'm guessing if it's really Resist Fingerprinting on Firefox (something Mullvad also has on by default), then there are other settings that aren't being enabled causing the issue. Mullvad actually lists the settings related to resisting fingerprinting here - https://mullvad.net/en/browser/hard-facts
Or it could simply be that since it is on by default for Mullvad, that Cloudflare and others have an explicit exception built in for it. It might also be dependent on where traffic is coming from. I have had different behaviour with different ISPs. Perhaps your entire VPN network gets a pass due to, perhaps depending on how they manage abuse, or how much unique information they can get just based on the few bits of info the browser leaks combined with the uniqueness of the browser and VPN connection IPs.
Not sure a random UA extension is giving you much privacy. Try your results on coveryourtracks eff, and see. A random UA would provide a lot of identifying information despite being randomized.
From experience, a lot of the things people do in hopes of protecting their privacy only makes them far easier to profile.
coveryourtracks.eff.org is a great service, but it has a few limitations that apply here:
- The website judges your fingerprint based on how unique it is, but assumes that it's otherwise persistent. Randomizing my User-Agent serves the exact opposite - a given User-Agent might be more unique than using the default, but I randomize it to throw trackers off.
- To my knowledge, its "One in x browsers" metric (and by extension the "Bits of identifying information" and the final result) are based off of visitor statistics, which would likely be skewed as most of its visitors are privacy-conscious. They only say they have a "database of many other Internet users' configurations," so I can't verify this.
- Most of the measurements it makes rely on javascript support. For what it's worth, it claims my fingerprint is not unique when javascript is disabled, which is how I browse the web by default.
The other extreme would be fixing my User-Agent to the most common value, but I don't think that'd offer me much privacy unless I also used a proxy/NAT shared by many users.
Randomizing to throw trackers off only works if you only ever visit sites once.
But yes, without javascript a lot of tracking functions fail to operate. That is good for privacy, and EFF notes that on the site.
You can fix your UA to a common value, it's about providing the least amount of identifying bits, and randomizing it just provides another bit to identify you by. Always remember: an absence of information is also valuable information!
You kind of have to go out of your way to not have your keys backed up. By default, the easiest route is using your android or iphone and both of them back the keys up using icloud Keychain or google password manager. 1Password, bitwarden, all support syncing. Chrome will allow saving it to icloud or your google account. Keepass can be manually synced. Windows is adding sync in the next update for windows hello. List goes on.
The other thing is that multiple keys can be created. Easiest way to see this in action is google's account security settings. Log in (if you have an account), hit create passkey, see your options and play around with them. You'll also see you can add a hardware security key too, which isn't nothing new but if you have one that's another key that doesn't rely on a mobile device!
If all else fails, the usual account recovery process applies. Much like it would if you forgot your password.
It depends on your security risk profile and the type of passkey provided. The passkey's response describes if the credential is transferrable or not, and if the user has been positively verified as present.
They're as secure as having your password + 2FA in a password manager.
Should be noted that there's still debate on user presence, to the point that someone submitted a CVE[0][1] on KeePassXC for not abiding by this part of the protocol (and which I take Keepass's side).
A key difference between a passkey and a password is that a passkey is never transmitted off of your device. The existing tech that they most resemble is ssh keys.
How does Google Password Manager sync your passkeys then?
EDIT: Private key is not transmitted off of your device when authenticating, but it can be transmitted off of your device by your password manager.
"The difference between passkeys and passwords is that passkeys are cryptographic key pairs. The key pair is specific to a website. One half is shared with the website, and the other half is private and stored on your device or in your password manager." [0]
"Passkeys are securely backed up and synced between your Android devices" [0]
"Passkeys are stored in your Google Account..." [0]
"Your iCloud Keychain stores and syncs them [passkeys] between iOS, iPadOS, and macOS devices." [0]
> Private key is not transmitted off of your device when authenticating.
Thank you. I should have been more specific. Non-transerral during auth is important because it virtually eliminates fishing, and that also explains why the Powers That Be are touchy about exporting. Exfiltration enables scenarios where a nefarious party tricks a user into transferring their cryptographic keys.
And the interaction between the thing that generates the passkey and my password manager is very confusing. I got multiple popups and it wasn’t completely clear which was chrome ans 1password.
Strictly speaking, passwords do not have to be shared during auth, either. There are password-agreement schemes (e.g. SRP [1] as used in TLS-SRP) which allow one or both parties to prove they know the password without sharing it. However, these schemes never gained broad adoption.
> The other thing is that multiple keys can be created.
That depends on the site. For Google, sure you can add multiple passkeys. But many other sites will just do minimum effort and only allow you to register a single passkey.
It's easy to have your keys backed up to a device, but then the question becomes losing the device and being able to get back into a new one. I know that Google really, really likes to make sure it's you when you log in from an unexpected device, location, IP, etc, and it might be hard to prove that it's you without that one device.
You can also do this directly through Github's normal interface, as creating new markdown files through it is as easy as hitting the add file button and then naming the file ending in md. It also supports dragging and dropping files (the file has to have the markdown file extension added before it'll accept drag and drops btw). Super useful on iPads where vscode's editor can be a little cumbersome.
