eridius

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).

This syntax even made its way into CommonMark (https://spec.commonmark.org/0.29/#fenced-code-blocks)

1) We have one point of the function.

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.

That shouldn't even be a question. You shouldn't need to have working conditions be "so bad" before you consider a union.

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.

Bounds-checked indexing isn't an abstraction, it's a safety feature. The abstraction is compared to manually doing bounds checks like you would in C.

  // C safe subscript
  if (i < size) { return buf[i]; } else { abort(); }

  // Rust safe subscript
  return buf[i];

That's the abstraction, and Rust introduces no overhead here.

> 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.

> drivers’ work is outside the usual course of Uber’s business

What... how... I don't even know where to begin with this.

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.

"people" is "most users of the platform". A consistent native platform experience has been one of the cornerstones of macOS since even before OS X came along.

If you ask most people, they probably won't know to identify this as a desirable trait, but what they do know is that if they launch a non-native app it will likely not look or behave according to their expectations. For example, I'm an expert user and even I'm still tripped up by the fact that Slack has a rather anemic menubar, and Discourse's is even worse.

Is it Springboard that actually renders that notification, though? Seems like it should maybe be a separate process. Even if it is Springboard, rendering a notification that crashes the process shouldn't brick your phone, because it shouldn't re-render once Springboard relaunches.

Can someone please explain why this comment is getting downvoted? It seems like common sense.

Ok, but that just means SpringBoard (or some other system component) has to parse SMS messages. It doesn't mean SpringBoard has to be involved in the display of texts, and it also doesn't mean it has to be involved in iMessages. The moment SpringBoard determines that an SMS doesn't fall into the class of things that must be handled by the OS, it should stop and hand it over to the Messages app to do the rest of the parsing.

Ultimately I think the question is "why does iMessages have special integration in SpringBoard"? Because that's the cause of most of this. Messages doesn't have to be a "normal iOS app", it just has to be reasonably sandboxed. Running code using adversarial input inside SpringBoard is a serious problem.

That first screenshot looks like what I remember. I guess I never saw the graphics update.

Ah, interesting. I loved the heck out of the Exile games but I was unaware of details like this. I didn't even realize Exile I/II got graphics updates.

It's true that the corporation making a profit benefits the shareholders, but that doesn't mean the purpose of the corporation is to maximize this shareholder benefit. The corporation obviously wants to attract and retain shareholders, and so it must give them sufficient return on their investment, but that's it. And giving the shareholders value isn't at all the "purpose" of the corporation, it's merely something it must do. You may as well say "the purpose of a startup is to maximize return for VCs"; that's certainly what the VCs want but that's not a healthy mindset to be conducting business with.

Baba is You is I think a great example of something that looks really simple but is actually really challenging to pull off. It's also probably not something you could reasonably maintain across 25 years using freelance artists. It also helps that the total number of unique objects in Baba is You is rather limited.

> unprompted

The guy's been getting criticisms for 25 years. I think he's justified in writing a single blog post in defense of his art style. If you don't like it, you don't have to read it.