I'm not really sure how the U1 data is particularly relevant to governments. They don't generally need to know the precise movements of your phone about a single room. GPS will already locate you to the building and frequently to the room itself.
Why does the attacker gain a time advantage here? Is the attacker capable of transmitting at a much higher rate than the original sender? Even in that scenario, they just have to negotiate a send/receive rate up front, and that way the attacker can't jump the line because that would violate the negotiated rate (nor can the attacker intercept and increase the rate because then the original sender won't be transmitting fast enough).
Can you opt out of my brain recognizing your face?
Centralized face recognition where a single entity knows everybody a la Facebook would be a dystopian nightmare. Personalized face recognition where everyone has their own instance trained purely on the data they have access to (e.g. Apple's existing Photos face recognition) and only linking that face to the user's Contacts entry for the recognized person, that's not a privacy violation because that's just offloading information from my brain into my personal digital assistant.
Face recognition is something I absolutely need. I can't remember people's names for the life of me. If I could train a set of AR glasses to recognize people I've met before and pull up their contact info on the fly, that would be immensely helpful.
> If a big profitable unfriendly government asked them to track someone, what would Apple do?
Presumably the exact same thing they'd have done if they hadn't rolled out this Find My feature. They designed it so Apple can't tell where your device is, which means if anyone wants to demand this info from Apple, then Apple has to implement that tracking separately, which they could do regardless of the Find My feature's existence.
If Apple had access to the device data themselves, then that's a huge problem because governments can reasonably start issuing warrants for that info. The fact that Apple doesn't have it means nothing has changed on the governmental front.
Beyond explicitly using secure notes (which are encrypted), I don't recall Apple promising "confidentiality" of those things. I mean, I don't expect Apple to give that data to others, but I also don't assume Apple has no way of accessing that given a court order.
Apple uses end-to-end encryption for iMessage, which is the only Apple-related confidential communication I can think of (well I have no idea what the guarantees around FaceTime are).
2) We know one point of its derivative. This means we know 2 more points of the function (one step in either direction).
3) We know one point of its second derivative. This means we know 2 more points of the derivative, which in turn gives us 2 more points of the function.
etc.
Or at least, that's the impression I get from this thread, since I wasn't familiar with the series before that.
It's literally the definition. And very little qualifies. An abstraction is zero-cost if there's no runtime penalty, including if the code you'd write by hand to accomplish this goal is no better than what the compiler synthesized for you via the abstraction.
If the use of the abstraction forces your data model into a suboptimal representation, it's not zero-cost. If the compiler emits code that's worse than the straightforward manual implementation, it's not zero-cost. If the emitted code involves runtime checks that aren't necessary without the abstraction, it's not zero-cost.
For example, reference-counting is an abstraction over tracking the lifetime of your object. In some cases (where ownership isn't clear) the retain count introduced by reference counting is required and therefore not a cost, but in most cases the point at which the object ends up freed is actually predictable, and therefore the cost of all the reference counting is something that would have been avoided without the abstraction. Therefore, reference-counting as a replacement for manual alloc/free is generally not zero-cost.
Or how about iteration. Rust has an external iterator model (where you construct an iterator and run that, rather than passing a callback to the collection). In most languages an external iterator model is a non-zero cost, because you need to construct the iterator object and work with that, which is a bit of overhead compared to what the collection could do with an internal iterator model. In Rust, external iterators are frequently zero-cost because they usually get inlined. So you can write a high-level loop that includes a filter and map and the end result is very frequently just as good as (if not better than) what you'd have done if you wrote the iteration/filter/map by hand without Rust's iterator abstraction.
> What part of my comment made you think I didn't understand that?
This part:
> But that's like saying if you don't use rust you don't pay for it. Just because there is the unsafe escape hatch in the language, you don't get to label the language as zero cost abstraction.
Rust isn't "zero-cost" because of the unsafe hatch; that's completely orthogonal. It's zero-cost because if you don't use a feature you don't pay for it. The fact that you need unsafe to get non-checked subscripting isn't particularly relevant to the fact that using non-checked subscripting in Rust means you're not paying for the existence of checked subscripting.
> Under your description an opt in generational GC is zero cost.
You're conflating implementation with semantics. If you have a choice between different allocation strategies that all result in the same observable runtime behavior, using a garbage collector over manual alloc/free is a cost. With manual alloc/free there's no runtime tracking to determine when an object should be freed, it's entirely static. Using a GC dramatically simplifies this from the developer's perspective and avoids a whole class of bugs, but comes with a runtime cost. Meanwhile for single-owner models, Rust's Box type has no runtime overhead compared to alloc/free, since there's no runtime tracking, the alloc and free points are determined statically by the compiler.
The link isn't removed on the keybase side but the next time it's checked it will be flagged as bad. Clients will check it automatically when you follow; otherwise, I believe what happens is the system will periodically check it and cache that data for some time (so that way you're not hitting the external services every single time you visit someone's profile).
I would assume the airdrop ensures the GitHub/HN proofs are up-to-date before sending the lumens.
I have a Keybase account with a wallet. I haven't actually used the wallet for anything, but it does exist. And I didn't receive any lumens.
If this surprise gift was for "each active Keybase user", how do they define "active Keybase user"?
Edit: Also, the desktop app didn't show anything about joining the monthly airdrop. I had to fire up the mobile app to see it.
Edit 2: After fully quitting the desktop app (including status item) and relaunching, the Wallet section finally shows an "Airdrop" entry. I shouldn't have to fully quit out of Keybase for this to work though.
It's pretty weird how the article doesn't even bother to mention that Apple has an official API for doing encrypted notifications, and I really have no idea why these apps are abusing the VOIP stuff instead of using the actual encrypted notification feature. The article quotes someone as claiming APNS isn't reliable, but with zero evidence, and it seems pretty darn reliable for all of the non-encrypted apps using it.
Yeah, which is why fuzzing is important even with tests covering every code path. And even with that, this is why I simply said that SQLite is probably the codebase that comes the closest, rather than saying it actually is bug-free.
Why does Google hate virtual cards though? It's an anti-fraud mechanism. Google's declaring that using an anti-fraud mechanism is in fact an indication of fraud?
I heard about that a long time ago, back when it looked kind of dead. Glad to see it's still under development. I'm skeptical though, does it actually support all of Slack's features (or even a majority of them)? The screenshot is rather minimal, showing nothing in the way of unfurls, no formatting beyond a link and an @mention, no userlist, no channel info, no pinned messages, no reactions, etc.