You're very much not alone, this comes up frequently here at hn, because other sites also frustratingly block this behaviour often by popping up "tweet this" links after highlighting.
There is no way that in reality visual basic is surging up the charts and more popular than most other languages, instead I would guess they are attributing some .Net results to VB instead of C#.
The source of the noise at any given moment is where the tire is (or has just caused) the strip to vibrate. That point is moving away from the observer about as fast as the car is moving away from the observer
So, the doppler effect is present since the point of friction is moving to a different point on the road, even if the road is stationary.
I'll add one thing: normally you hear Doppler effect with a nearly constant sound (emergency sirens.) Here the pitches are changing, but because our minds instantly recognize the 8-step Western scale we can pick out the frequency shift even though the frequency changes between the different notes may be the larger change.
I think your explanation is correct, apart from that i do not think it is the tire that causes the strip to vibrate as much as it is the strip that causes the tire to vibrate.
If it is the tire that makes the noise, it is no surprise that there is a Doppler shift.
I don't think the tire is vibrating at an audible frequency. The tire colliding with the road creates a burst of air, and since these 'bursts' are moving you have a doppler effect.
In theory you could create the same effect by setting off fireworks.
> It's interesting how you still observe the doppler effect even though the road isn't moving
Relativity. Christian Doppler's equation for the change in frequency of a wave, for subsonic velocities, is approximated by three variables: the velocity of the receiver relative to the source, the velocity of waves in the medium and the emitted frequency [1]. The first term is symmetric between a source approaching the receiver and a receiver approaching a source.
(The actual equation measures the velocity of the source and the receiver relative to the medium. Here, too, the symmetry between a source moving towards a receiver, the latter un-moving relative to the medium, and a receiver moving towards a source, the latter un-moving relative to the medium, is preserved.)
Did it actually raise 660m or was that the size of the "market cap" when it collapsed?
if I sell 100 tokens for a dollar then convince someone to buy 1 token for 10 dollars, if I run off with the money I've not run off with $1000 even if it feels like it for the people left with tokens.
In these situations they sell their bullshit tokens for real money (or BTC/ETH), so they would have run away with the actual money or something within an order of magnitude, not some fantasy "market cap".
It sounds like they pulled the plug after as little as 2-3 months of supposed ~50% monthly increases. So the chance that the real money stolen is somewhere in the vicinity of 1/4 the apparent loss seems high.
Your figure of 1/10 to be conservative sounds sadly sensible.
The UK has had data protection laws for years, people aren't scared of GDPR because it finally provides laws, they're scared because they actually look enforceable.
edit: The original headline before being changed, "Web standard brings password-free sign-ins to virtually any site", and contained a paragraph espousing fingerprints in place of passwords.
This meme needs to die. Fingerprints are a perfectly fine authentication factor. They are unique enough and require effort to fake.
Consider a simple fingerprint USB vault which stores your keys:
* Factor 1: You must have physical possession of my vault.
* Factor 2: You must be me or have a convincing fake of my fingerprint.
Before we even think about a password I've already prevented almost all of the attacks I'm likely to ever encounter against my accounts.
* I have made it impossible for someone to casually break into my accounts/device.
* I've created enormous distance between myself and remote attackers.
* I've eliminated password reuse and contained the effect of data breaches to the service that was breached.
* I've made it much more difficult for network operators to carry out MitM attacks since tokens are origin bound and the challenges are real-time with replay protection.
Yes in a forum of nerds you can point out that lifting fingerprints is possible but if everyone switched to this simple U2F device the world would be far far more secure. Passwords optional.
Then if you're worried about a more sophisticated attackers like corporate espionage or governments you can add a password.
The difference is you leave your password everywhere you go. Doesn't matter how unique it is, if I leave a sticky note with a password everywhere I touch, then it's not very good security.
Fingerprints are also not that reliable. Some gun safes that use fingerprints are notorious for opening too easily with wrong fingerprints. On the other end of the spectrum, India is struggling with their fingerprint authentication system, as the system fails to recognize the fingerprints on file. [1]
If you have something as sophisticated as TouchID, it's actually hard to replicate a valid print. CCC did it in a lab situation (wine glass + latex paint), how is a smear on a tabletop or mug going to be retrievable for a sophisticated scanner?
If I recall correctly, someone was able to fool TouchID a few years ago using a fake print created purely from pictures of a German government official.
That was impressive but it's still something of an edge case: he used it to register & unlock a phone but did not unlock her phone and it sounds like it required a photograph taken a few feet away at a press conference using a big lens:
I think for most people convenience remains a win over the marginal increase in risk — someone who can get that close to you can also use a hidden camera/drone to watch you enter a password, steal your wallet/bag with two-factor codes, etc.
That’s the English translation but, yes, recovering a fingerprint which can be used to unlock a test device doesn’t show it can replace the original. It’s prudent to assume that the attacks will get better but I think this really highlights the difference between broad and targeted attacks since so many people are better off with the fingerprint unlock.
Only because you have to lift and then manufacture them from scratch from glue and silicone and stuff. If someone automated the process it would require little to no effort. In theory it would be possible to manufacture a device that could present any given fingerprint when scanned with a popular scanner. You leave them everywhere, even on the scanner itself.
It is also a limitation of biometrics that you can only use them once. It might make sense for a phone, but after you have given Google your fingerprints, they can in turn use them for other purposes. It's like reusing a password that's also tricky to rotate.
That's the nice thing about webauthn biometrics, though: the biometric data is never sent to the server. The test is done locally, and the server can trust it by verifying a cryptographic attestation of the authenticator's capabilities. And on the flip side, the user can opt in to biometric authentication even if the server does not require or care about it.
Both of your factors boil down to the physical presence of two things that will usually be in close proximity to each other. Is it really fair to consider that “two-factor”?
Both your fingerprints and the vault can be taken from your person without your consent; a password much less easily.
You know this how? There has not actually been in real studies done, and the FBI and Law Enforcement resist any efforts to do studies on how Unique Fingerprints really are.
It is the bedrock of criminal prosecution many centuries, but they do not want any public analysis into how many people share similar prints..
Print Reading, even by a computer, is more of an art form, a massive guess, than it is a science.
Fingerprints are IMO fine for reoccurring logins. I set my phone to require my password on first boot but while it's running a fingerprint is good enough.
Same could go for websites. A simple biometric factor like fingerprints is easy and friction free enough to log in users on previously seen devices. My password can then also be much longer and the website can impose stricter rules (longer passwords, no breached passwords, etc.) without increasing user friction that much either since most people will probably only log in from 4 devices at most (desktop, phone, tablet and some library computer)
The fingerprint is just to authenticate to your local device. So an attacker with access to your fingerprint can't get at your account without also having your phone (which stores the private key _actually_ used for remote authentication in secure, tamper-resistant hardware).
1. A fingerprint is something you cannot change, cannot revoke if leaked and cannot be unique across different sites.
2. A fingerprint hash isn't a cryptographic hash because you need to be able to match to nearby matches. A small variation in input needs to have a small variation in the hash so a distance function can be applied.
Many builders/carpenters/etc will tell you this is not true. People who work in abrasive environments sometimes without proper protection often temporarily have no fingerprints as they are "warn off".
Many injuries can effectively modify or remove the too, at least temporarily.
This makes them bad usernames as well as bad passwords.
Either way, this is a terrible argument toward good security. "Oh, someone got a copy of your fingerprint? No problem! There's a belt sander right over there!"
This is a sore point with the new iphones for me. It happens at least once a week with routine hobby-farm work. I'm really looking forward to getting faceid.
Interesting. I wonder if anyone has studied what it would take to render fingerprints useless? Like N minutes/day of sanding with Y grit sandpaper?
Additionally, I was under the impression that some fingerprint readers looked at the blood vessels rather than the actual prints. Not sure how that would be affected by abrasion. Perhaps this is a misunderstanding on my end.
IMO, you don't even need any arguments beyond #1. Your fingerprint can't be changed and it's public information. You leave traces/copies of it everywhere you go. Just because it's more difficult to read now doesn't mean that technology won't make lifting and reusing your oily prints trivial someday.
Would you create a rubber stamp of your passwords, slather it with oil, and then go around stamping it on everything you own and everywhere you go?
No, in webauthn they don't, because the biometric data is never sent to the server. The test is done locally, and the server can trust it (if it cares) by verifying a cryptographic attestation of the authenticator's capabilities. All that's sent to the server is a public key and a private key signature.
How do two parties mutually verify, authenticate each other online?
I'm struggling to remember the protocol from a sci-fi novel where two secret agents who (separately) had their minds transferred to new meat sacks reconnected in a new (hostile) environment.
I think it had three parts: What you have, what you know, what you are.
> How do two parties mutually verify, authenticate each other online?
We verify the server's identity though it's public certificate that's signed by a certificate authority. The server can verify the client's identity via a public client certificate that's signed by an authority the server trusts. It's already possible to do this over a TLS connection.
> If the finger print is what you are, and password is what you know, then what is the "what you have"?
One possible form of "three factor auth" would be to use a passphrase for the private key, the client certificate to connect with the server over TLS, and a username/password login at the application level.
The certificate/certificate fingerprint is what you have, the password and passphrase are two things that you know. I don't know what would fit under the "what you are" category though (unless you're considering some sort of biometric based method).
Two humans who know each other can use the Socialist Millionaire's Protocol, this does some fancy mathematics to prove they were both thinking of the same number (for Bill and Ted this would be "69, dude") and of course we can encode any answer e.g. "Sarah", "Washington", "Lakers Game Six" as a large number trivially. The SMP would be weak if you could iterate it many times, but it's for humans, after "Ted" guesses 4, 19, and 22, Bill will stop asking and assume it's not Ted at the far end.
A machine can obtain Certificates from a CA which show the CA validated its identity, and use Public Key Cryptography to prove this is its certificate. This is how HTTPS works when you connect to a remote web site, but it can be mutually authenticated too, that's just not how web browsers use it.
Cascade is the worst possible word to use for someone coming from a CSS background. From the very beginning of CSS history, cascading was tied to a notion of specificity - if you have a rule for h1 it overrides what was in the html rule. https://css-tricks.com/look-back-history-css/
This is simpler and more efficient to implement and run at scale. But imagine if styling worked like that - you could never have colored overlays, or anything we take for granted.
When over-eager marketing speak encourages insecurity, it’s a significant ethical breach.
This isn't CSS, its a well documented behavior of Firebase Realtime Database because its "just" nested JSON. if you request one node in the JSON and it passes a security rule it gives you the entire node. Having to traverse all children for additional rules would be less performant.
I do think that if this is such a common behavior the rules DSL could be revised so that fewer people fall down the "pit of success". At the very least do not allow people to define rules that have already been defined by parents. This should be part of Firebase, the fact that theres a startup providing this service is the biggest code smell I can think of telling you there's a problem here.
Agreed - this doesn't seem to make sense to me. And the docs seem to corroborate this:
> Note that .read and .write rules shallower in the database override deeper rules, so read access to /foo/bar/baz would still be granted in this example even if a rule at the path /foo/bar/baz evaluated to false.
I dont speak for the firebase team but this is my rationale: its "just" nested JSON. if you request one node in the JSON and it passes a security rule it gives you the entire node. Having to traverse all children for additional rules would be less performant.
Picture a tree in which the roots contain protected data and the leaves contain public data. The further you go in the direction of the roots, the more certification you need.
I was trying out the javascript example, but managed to get a case where there is a negative conclusion but this goes against the introduction where it says negative conclusions are always definite.
My multiset was:
a, b, c, d, e, f, g, h, j, abc, def, asd, asds, 3g46stb6vy6vsyosyvosfsdfsdsah, oooooooooooooooo
Then trying oooooooooooooooo a second time, the bloom filter correctly says it might be in the set. The cuckoo filter says it is not.
I assume this is just a javascript bug in implementation, because previously the filter said it might be in the set, actually adding it to the set then gave a false negative when trying it again.
Yeah - pardon the crappy javascript and UX. Notice the colors on the cuckoo filter when you insert this sequence. When you try to insert `3g46stb6vy6vsyosyvosfsdfsdsah`, the fingerprint entries in the cuckoo turn red indicating an unsuccessful entry. All possible fingerprint slots in the cuckoo for that entry were already occupied, and the recursive rearranging of entries was unable to free up a slot.
This is a down-side to cuckoos (and counting blooms) - even when the filter has reasonable capacity remaining, an entry can be denied due to collision with previous entries and saturation of their slots.
The UX on this demo could be better - e.g. not insert into the bloom unless the cuckoo insert is successful (to keep them from diverging). Also, a message indicating an unsuccessful insertion would be nice.
I wish this was something that people brought up more prominently when discussing cuckoo filters. They fail catastrophically. A bloom filter gradually fails as the number of items inserted increases and the false positive rate tends to one. But a cuckoo filter that fills up the buckets for a fingerprint has to reject an insert meaning that either you start to have false negatives or to guarantee that you don't have false negatives you have to immediately return true for any query, which is a false positive rate of exactly one with a sharp discontinuity in behavior from before the failed insert. I think the salesmanship of cuckoo filters has been a little overdone and in most applications a bloom filter is a better choice.
Yes, cuckoo filters and counting bloom filters can start rejecting insertions before the filter is loaded - cuckoos because of the inability to find an open slot, and counting blooms because of saturation of a counter. Note that this is only the case if deletion or counting support are required.
In some cases, like the when there's a high likelihood of duplicate entries, this can represent a catastrophic failure mode. This is a good point, and when I get around to updating the tutorial, I'll make note of this.
Regarding the failure mode, an insertion can be knowingly rejected without mutating the filter, so the filter remains useful for subsequent insertions and all reads, retaining all its guarantees. The only loss is the rejection of the item - in our case we used this as signal to rebuild the filter at a larger size.
