> is having me click on an email going to make it more secure?
We implemented this at Mercury recently to stop phishing attacks, and I believe Coinbase implemented it for the same reason [1].
TOTP authenticators are super ineffective at combating phishing. If a user is willing to give their email and password to a phishing site, there's very little standing in the way of them also providing their TOTP code.
WebAuthn solves this by working with the browser to tie authentication to a particular domain, but not everyone has a WebAuthn authenticator yet.
Meanwhile, email verification links are a really simple and effective way to shut down these phishing attacks. The phisher can't click the links, because they don't have access to the user's email. The user can't click the links on behalf of the phisher, because clicking the link only verifies the device that clicks the link.
Oh, I hadn't read that as merely having the e-mail address and password to the site, but having the password to the e-mail account. I get it now. Though, it still irks me that we are now up to 3 factor authentication--password, TOTP, and e-mail--under the premise that the user is too dumb to secure 2 factors, and yet somehow is smart enough to secure the third one.
I've been using DDG for around six months now, largely because I love their keyboard shortcuts. Weirdly there doesn't seem to be a shortcut to help insert bang commands.
I've been using this greasemonkey script[1] as a workaround, but I'd love to have an official solution.
> Update: On a more detailed examination of those two states, I’m convinced the contrast here is due to differences in the sizes of the blocks. North Dakota’s blocks are more consistently small (StDev of 3.3) while South Dakota’s are more varied (StDev of 9.28). West of the Missouri River, South Dakota’s blocks are substantially larger than those in ND, so a single inhabitant can appear to take up more spaaaaaace. Between the states, this provides a good lesson in how changing the size and shape of a geographic unit can alter perceptions of the landscape.
Yep, I grew up in ND, and my nearest non family neighbor was 7 miles away. This was pretty common. So if you parcel things up smaller than say 5 miles you'll miss people there pretty easily.
Yeah, it looks like they are setting the census blocks small on what is farm, ranch, park, and reservation land. The Red River divides ND and MN and there is space there because of previous moves from flooding.
Most census geographies aim for equal-ish population, so they vary widely in size. Blocks are a little different, though, and are designed to be a more or less nicely boundaried thing as well -- surrounded by streets with no crossings, etc.
1) Client uploads a bloom filter with all contacts on phone
2) Server responds with a bloom filter with all registered contacts that match the client's bloom filter
3) Client displays contacts that match server's bloom filter
You can optionally trade contacts back and forth again with a larger bits/contact ratio to decrease false positives.
I think it works out so that in exchange for 7 bits of information about each contact from the client, you can reduce the server's response by a factor of 128.
The problem with this is that (1) + (2) means the server now knows the user's address book. They're trying to avoid that with encrypted bloom filters and blind signature queries.
(0) The server informs the client about the parameters of the bloom filter where it currently keeps all the contacts.
(1) The client builds the bloom filter with the same parameters based on its address book. After building the bloom filter, the client XORs it with a fuzzing pattern [a].
(2) The server performs a logical AND of the received bloom filter and (its own bloom filter XOR another fuzzing pattern [b]), and sends back the result.
(3) The client XORs the result with the fuzzing pattern [a], and uses this bloom filter to perform the local queries.
(4) The client stores the differences in results between the subsequent results, and each time the same result is returned, it doubles the query interval [c].
(5) The client sends its own ID with each query, so as the network grows and the server inevitably needs to recreate the bloom filter with different parameters, it can do so gradually ahead of time from scratch just based on the IDs of the queriers.
[a] I haven't done any napkin calculations of how random it should be, nor how many bits would need to be set to 1. The idea is to add a certain amount of false negatives here so the server were not able to recover the contact list just by bruteforce lookups. To avoid the leakage of information by correlating the subsequent requests, this pattern should probably be a PRF(client_contacts), rather than a purely random function - thus, if the contact list did not change, it should not change either, and if the contact list did change, it should change in a way to mask the change in the contact list somewhat.
[b] This may not be needed. The idea is to try to protect against the client sending an all-1 list and getting the entire bloom filter. But given that both [a] and [b] may both introduce false negatives and false positives, maybe there should be another approach to restrict what is sent to the client.
[c] Especially given the [a] and [b], chances are quite high that this might be a no-op.
It is obvious this method will introduce the false negatives, and if [b] is used, can add false positives as well.
Good point. Now I understand why they were suggesting bucketing.
I came up with this method for maintaining privacy while retrieving installed apps (to give app recommendations). Sounds like it might not translate across so well.
However, it's even worse than you think. It's making a lot of references to minified/obfuscated names. Things like $('.nH.hx'). When I was working on a gmail script[1] a year or two ago, many of those were changing every few hours.
https://mercury.com/404
My high score today is 33.