- Python, solid ML lifecycle experience, computer vision preference
- AWS SageMaker
- SQL, data strategy, data warehousing
- Desire to work in highly dynamic/changing environment
- $150k-180k plus bonus/equity
Please read the JD on the site. If interested, please send your MLOps, SageMaker experience, and any other information you feel is relevant to the email below.
* Unfortunately we unable to sponsor H1B/transfers at this time
Would be interested to also know how they handle per-title audio. With stereo -> 5.1 -> 7.1 and the sides and wide layout variants, how do they think about this during the inspection and encoding process? Being completely naive to Netflix's source media, and assuming it comes in a variety for formats and media, it seems like there are decision to make there. Though audio obviously has a much lower bandwidth burden, one would think there could still be QoE gains (and bandwidth savings) by doing things that AV1 can do with different scenes in something like OPUS.
Early in my career, when I first started interviewing, I used to ask a version of this to recent grads. It was never a make-or-break question, but I found it to be a great way to a.) see how people approach problem solving and probability and b.) see how they respond when you start asking whys (even if they answered/guessed 1/3). It's something that takes zero code to answer, and the intuition is easy to grok once explained.
The other part I particularly enjoyed was the people who initially guessed wrong, but then got to the answer intuitively almost always sent me code proving the answer.
For the record, my question was: "Two points are randomly and uniformly selected on a line 0.0 to 1.0. What is the most probable distance between the two points?"
> what is the most probable distance between the two points?
> even if they answered/guessed 1/3
1/3 is not the most probable distance, it's the expected value. The most probable distance does not exist, but PDF(d) is strictly decreasing for (d>0).
> Two points are randomly and uniformly selected on a line 0.0 to 1.0. What is the most probable distance between the two points?
Unless I am reading this wrong, I think all values between 0 and 1 have an equal probability (of 0).
The probability that a random uniform variable will equal any number between 0 and 1 is zero. It seems to follow that the probability of the difference between two uniform variables equaling any exact value would also be 0.
Have I missed something obvious? If zero really is the correct answer, that is pretty tricky.
You have two random uniform variables and the distance/difference/change between to finite points.
Put another way (and code it up if you want). Select two random uniformly distributed points between 0 and 1. Do this 10_000 times, whats the average distance between the two?
This gets to the question of "most probable" vs "expected value". A conversation I always welcomed.
This is a bit old in SD terms, but I wanted to post here if anyone ever wanted to use a fine-tuned SD model to create a WSJ-style hedcut of themselves (or others I guess).
* I wanted to express that this work would not be possible without Noli Novak's incredible artwork, and attribution should be given to her when appropriate (and certainly not to me) *
It does what I need. Fast, search-capable, markdown, and handlebars. The community isn't huge, but it's just what I need to get a little bit of writing online.
"HIRWAY: ...Just music. It allowed some space for my brain to get bored. Another thing that I learned was how much boredom was, like, an essential part of creativity. Maybe boredom is too strong of a word for it, but it's something like..." mindfulness.
I remember hearing Sam Harris (I think) say something to the effect of 'once you reach some stage/awareness of mindfulness, you can never be truly bored.' Like, if you're bored, you're not paying attention. That's stuck with me.
In this randomized clinical trial of the cardiometabolic effects of omnivorous vs vegan diets in identical twins, the healthy vegan diet led to improved cardiometabolic outcomes compared with a healthy omnivorous diet.
Would like to see a couple of the middle ways peppered in (pescetarian, vegetarian).
Agree, but I do think there are real clinical benefits to short trials like this. For example, it's good to have evidence that one could quickly improve their cardiometabolic health immediately after a cardiovascular event just by switching to vegan.
My recollection is that pescatarian significantly outperforms all other eating patterns in terms of mortality, when treated as a distinct group. It is infrequently broken out in large studies, unfortunately. This also often isn't highlighted in the headlines for these studies, probably because they get more engagement along the popular "meat or plant" angle.
As usual, Gruber was right on the money. Via Threads yesterday:
"My prediction is that Apple will make changes—fixing bugs and/or closing loopholes—that break Beeper Mini. It’s untenable that there’s unsanctioned client software for a messaging platform for which privacy and security are a primary feature.
It’s a very nice app, remarkably clever, and for now works like a charm, but if Apple wanted an iMessage client for Android they’d release an iMessage client for Android. Seems irresponsible for Beeper to charge a subscription for an unsupported service."
>It’s untenable that there’s unsanctioned client software for a messaging platform for which privacy and security are a primary feature.
I don't follow this logic at all. Shouldn't supporting thirdparty clients be desirable if security is a primary feature in the interest of transparency? Especially if the reference client is proprietary and undocumented.
We've really done one over on ourselves by adopting the mental model that only a vertically integrated corp can deliver privacy and security to users. This rigid tendency towards homogeneity is bound to suffer a tragic systemic failure before too long.
It would be healthier to assume multi-polarity and lean into it.
> We've really done one over on ourselves by adopting the mental model that only a vertically integrated corp can deliver privacy and security to users. This rigid tendency towards homogeneity is bound to suffer a tragic systemic failure before too long.
Look no further than the other news that came out this week re: government spying via push notifications. (https://www.reuters.com/technology/cybersecurity/governments...) Consumers rationally trust the few big companies which are incentive-aligned to protect their data and government then goes after those few big companies. I thought this was particularly galling:
> In a statement, Apple said that Wyden's letter gave them the opening they needed to share more details with the public about how governments monitored push notifications.
> "In this case, the federal government prohibited us from sharing any information," the company said in a statement. "Now that this method has become public we are updating our transparency reporting to detail these kinds of requests."
I suspect there's more where that came from. The only reason we learned of this, is because the cat was let out of the bag, and Apple was able to talk about it (gag order).
People might want to think about how AirTags and Find My Phone work...
> We've really done one over on ourselves by adopting the mental model that only a vertically integrated corp can deliver privacy and security to users.
Who is saying that? Certainly nobody anywhere in this HN thread. It is, however, fair to say that the only guarantor of privacy and security is a network of trust. There are plenty of examples where trust is partially decentralised, the most notable being the system of certificates used for establishing trust in HTTP over TLS.
That is not even remotely similar to the claim you made. Nowhere in that sentence is the claim that privacy and security cannot exist without a vertically integrated corporation.
All they're saying is that the existence of third party software compromises Apple's ability to make blanket statements about the security and privacy of this one specific platform. An unofficial third party client breaks an established network of trust — which is an objective fact. If you doubt this, then you really should use this Chromium fork I just developed. Use it to log into your internet banking. Don't be scared. There's nothing to worry about. See, there's a lock symbol in the address bar and everything.
Sure, but also recognize: web browsers constitute a mature, multi-polar ecosystem; we do not clutch pearls when a user chooses Firefox, or Safari, or Chrome (or myriad others) to transact on the web.
Can a bad actor slap a green lock on an insecure browser clone and harm users? Certainly. And yet, in a survey of the systemic threats to security and privacy on the open web, such attacks are relegated to the margins.
Apple encourages a popular narrative that centralization and control beget trust, and from there may enable privacy and security. Look no further than the comments on this HN post to see the narrative echoed!
It's fair to point out that it's not literally what Gruber wrote, but readers will fill in the negative space around his uncritically apologetic commentary. To state the implied message: trust in Apple's way, and remember that third parties (who are not accountable to Apple) will ultimately deprive you of privacy and security!
Having a system where trust is embodied in a single entity is one valid solution. It's also not the only solution and I haven't heard anyone claim that it is.
That is technically a remark I agree with, but you're skipping past the actual point of my comment: it may be a valid strategy on its face but it is fragile and makes users vulnerable to systemic exploitation.
The web browser ecosystem has its own (different) problems, but iMessage lacks requisite variety to back up its particular claims to privacy and security (see that Reuters article for a preview).
I skipped past that because that wasn't what I had expressed disagreement about. Though now you elucidate further I'll say I fundamentally disagree with your "actual point" as expressed. While I agree that systems of distributed trust are fundamentally healthier, they are an order of magnitude harder, and rely upon educating users. And some percentage of users will always be impervious to education — see the continued prevalence of phishing scams for example.
A system which relies upon trusting fewer entities is inherently less fragile and less vulnerable to exploitation. It's true that systems can be designed which rely on users trusting a large number of entities, and can sometimes result in a more educated user base, but they're much harder to implement and much, much, much, much rarer in the real world.
I think the difference here is whether we're considering the plausibility that there aren't any security violations versus the overall frequency and severity. Centralization significantly increases the chance that all the systems involved will be safe; that's what makes it so useful for individual organizations, where centralizing their operations wouldn't attract significantly more bad actors to try breaking their security than decentralizing.
But if we have centralization on the scale of a society, then anyone interested in any of the groups using that centralized source of secure data storage/transfer will be drawn to look for the flaws in that source. And there are always flaws, either technical, legal (as with the government spying mentioned elsewhere in the comments), or otherwise. And once any group manages to infiltrate that one source, they get access to everything dependent on it.
Sure, decentralized security is harder to get together, meaning we have an initially-high violation rate that decreases over time (though this can be supplemented by security-conscious users taking their own steps to protect their data).
But centralized security at sufficiently large scales essentially guarantees a breach impacting everyone within its domain; and the kind of trust that would be required to sustain such centralization also anti-correlates with users independently adding additional layers of security to their systems.
This seems like a much greater risk than just accepting that users who are "impervious to education" will be vulnerable to certain social-side exploits, while everyone else will be reasonably safe.
I don't remember anyone "clutching pearls" over https by default? Do you have any suggested references where I can find those? I do recall people really complaining that anything at all was allowed to be http, even sites that most people would consider "unimportant".
There were a lot of complaints that websites which never had to bother with certificates before now had to set one up (and pay for one). Though that's now largely solved by Lets Encrypt.
> All they're saying is that the existence of third party software compromises Apple's ability to make blanket statements about the security and privacy of this one specific platform.
We’ve also got examples of Apple making misleading statements about the security and privacy of their platform, as a result of government gag orders.
That recent disclosure makes me suspect that every vector that they do not disclose explicitly as being private, is very much not private. To that end, the platform is clearly neither private nor secure if you value privacy from the government.
…so I’m not particularly concerned about third party software being a cause for concern anymore.
> An unofficial third party client breaks an established network of trust
I think this is key. The problem is the security of iMessage as a protocol is dependent on trust between client (implementations). Which is actually not that great from a security perspective.
I don’t mean that there are necessarily vulnerabilities in the protocol (there very well may be), but that the protocol is not something that Apple is willing to depend upon to uphold their desired security guarantees.
What's untenable is that the third party software is unsanctioned. You can make the argument that it would be a good or better system with third party clients, or that Apple should open the system up, but it is ridiculous that anyone would trust a client/integration that depended on some kind of hack (regardless of the nature of that hack--such as whether it's decrypting and proxying or getting into the ecosystem in a "secure" way)
They are planning RCS support. They've said nothing about how that will look in the app, it's not a given that will be in blue bubbles or fully feature complete with iMessage
Even better, and not surprising at all. I was kind of surprised that everyone just assumed RCS would get the blue bubble treatment when Apple made their announcement.
This would be the case if it were a protocol designed to be opened up for use by 3rd party clients. As it stands, this was a clever hack which would undermine the integrity of the system if left in place. Within a few weeks we’d see 100 3rd party iMessage clients, and it would be luck of the draw if the one someone downloads is secure or not.
If the existence of a working unsanctioned client undermines the integrity of a system as prominent and security- and privacy-focused as iMessage proclaims to be, then that system has big problems.
Certainly this is not the first time some entity in the world has reverse-engineered iMessage; it's just the first time that it was publicized.
This is also notable, because the technology that Beeper Mini is based on was public and available to potential attackers before Beeper Mini launched. Beeper didn't invent this, they contracted the developer and based the project off of their open Github repository.
Apple did leave the hole open; they left it open until it threatened their customer lock-in. Only at that point did they decide that it was a security risk.
The system wasn't designed with those 3rd party clients, and security around them, in mind. Beeper Mini is spoofing/reusing device IDs, pretending to be some random person's Mac, for example. True support for 3rd party clients wouldn't not require this kind of thing.
From what I understand Beeper Mini is interfacing with iMessage on-device, what's to stop another clients from using a server and intercepting messages? While I don't have time to look it up again, I think there was also something on how Beeper Mini is handling the push notifications when the app isn't open. While that may not leak a lot of information, and there is also the news of Apple/Google sharing push info with some governments, that's something that can at least raise some eyebrows when it comes to how private it is.
> The system wasn't designed with those 3rd party clients, and security around them, in mind.
It sure as heck better have been designed with that in mind, because it sends SMS messages to uncontrolled 3rd party clients that could be stealing your information or spying on push notifications every single time you message an Android user.
I genuinely don't understand this argument. Do people think that SMS messages don't generate push notifications? Does Apple have a 1st-party SMS messenger available on Android that I'm not aware of? You're already communicating with 3rd-party clients that could be spying on you, and you're already receiving messages from those clients in the iMessage app. The biggest difference is that your messages with those clients today are fully unencrypted, so spying on them doesn't even require compromising an app.
It's weird for people to be so concerned about push notifications as if that's a decrease in security when the alternative system they're proposing is for iOS messages to be sent to Android devices fully unencrypted. Apple/Google can share all of that information with the government as well; if they're not being asked to it's only because the government can get it even more easily directly from the telcos.
There is no iMessage app. There is a Messages app that implements two systems: iMessage and SMS/MMS. iMessage is the system whose security model is being discussed here, and the security model of SMS/MMS is mostly irrelevant to it.
This is splitting straws; the overwhelming majority of Apple users don't make this distinction (if they even realize there is a distinction to make). For all practical purposes they use one app that lets them talk to their friends and some of the bubbles are green and some are blue. How many of those Apple users even realize that the green bubbles are unencrypted rather than just being a designation for Android contacts?
It also changes nothing about my comment, because you can call SMS a different system all you want, but your conversations with Android users are still being sent unencrypted and any malicious payloads you get from SMS phones are still being loaded into the same Messages app. If you're worried that a 3rd-party client on Android is going to let a company spy on conversations you're having with Android users, then I still have real bad news for you about how Apple sends messages to Android users.
Draw the lines however you want between Messages and iMessages, but the security implications of Apple's setup are exactly the same. When you write a message to an Android contact, Apple sends that message unencrypted to a 3rd-party client that could by spying on you, leaking your data, or sending malicious payloads to your iOS Messages app. It still makes no sense whatsoever to be this concerned about the security of the push notifications for your messages to Android users when the alternative being proposed is to throw security entirely out of the window for those conversations. It is still a clear security improvement for conversations between Apple and Android users to be E2EE rather than to be sent over SMS, because the risks being raised about 3rd-party messaging clients are already present within those conversations today.
Third party clients offer many more cases for average users to lose their security, because you can’t prevent malicious actors from releasing “SuperMessengerSecure” that just mirrors everything off to a server somewhere.
How would third-party clients _increase_ security (other than indirectly, by people using SMS less)? On the contrary, third-party clients is a gigantic security hole, since Apple can't even know if a client app is spying on users.
> On the contrary, third-party clients is a gigantic security hole, since Apple can't even know if a client app is spying on users.
Security isn't about Apple knowing if an app is spying on users, but about THE USERS knowing that nobody is spying on them.
At best a third party iMessage client can only be as secure as iMessage itself because the back end is still closed and has no transparency, so it's the weakest link. If Apple (or a third party) is spying on the back end then no client can be safe.
> How would third-party clients _increase_ security (other than indirectly, by people using SMS less)?
They can increase security by breaking a single target into multiple targets, by increasing competition around security and privacy issues, by having more people use and work with the protocols and able to spot potential problems, by encouraging more transparency around issues when they arise, and by having alternatives readily available if one of the clients is found to be compromised or insecure.
And of course open source clients can be verified and validated by other developers and security professionals.
> They can increase security by breaking a single target into multiple targets, by increasing competition around security and privacy issues, by having more people use and work with the protocols and able to spot potential problems, by encouraging more transparency around issues when they arise, and by having alternatives readily available if one of the clients is found to be compromised or insecure.
I believe you are speaking to transparency, not third party clients.
Beeper Mini actually bundled binaries that they didn't understand to bootstrap registration. They could only attempt to be compatible with messages that they have received, and verify messages they send show up correctly - they cannot know they covered all available options.
I speak to this as someone who reverse engineered MSN Messenger back in the early 2000s for an XMPP gateway - you'd occasionally find an entirely new type of message (requiring an entirely new parsing code path for their undocumented/bespoke messaging protocol) because someone registered for a stock ticker or the like.
There was no fuzzing the official servers or clients to see if they were robust or secure - the goal was to have a salable product. In fact, we saw other messaging systems where we had significant concerns based on our understanding of the protocols through reverse engineering, and we saw one vendor exploit a security vulnerability in their own shipping product in order to verify authenticity and block third party clients (which worked for a period of time)
From what I saw of the iMessage system, third party support is not going to be feasible even with a documented protocol without partnership, because there is an assumption of attestation of real, unique hardware as part of registration to prevent mass abuse.
I don’t know a lot about how it works, so forgive me if this is a silly idea. I wonder if attestation could be done using real Apple devices, while leaving the private key on the user’s android. So similar to the old beeper to get the signed attestation, and send the result to the phone. Still could be secure since you can keep the private key used to encrypt messages local on the users device. I guess the issue might be a cat and mouse game if detecting beepers flock of Apple hardware to try and disable them all… (given many people would be using the same Apple devices)
I think iMessage is still using older attestations, but generally an attestation of this sort (App Attest, Play Protect API) represent a chain of the hardware, boot process, OS and application.
So iMessage is not going to be willing to hand out private keys or negotiate them for a third party application, and Beeper will not be trusted to register a private key itself.
Android iMessage support would be weird because there is no iMessage application - there is an application which lets you send SMS and to upgrade to MMS or iMessage when available. So, if there ever was an official Messages app for Android, I would somewhat expect it to also offer to take over being the default application for SMS/MMS.
> Security isn't about Apple knowing if an app is spying on users
Clearly, what matters to Apple is what _they_ believe is secure, and they of course trust themselves more than they trust Beeper.
> At best a third party iMessage client can only be as secure as iMessage itself
Exactly, they can never be safer, and given that Apple, or we as users, know very little about the company behind the client, third-party clients are much less secure.
> Security isn't about Apple knowing if an app is spying on users, but about THE USERS knowing that nobody is spying on them.
True, but Apple caters specifically to a consumer base that can't know this and does not want to think about this. Whether this is health or sustainable in the future is another matter.
No. This is an entirely self-centred view. The only people that equate this sort of transparency with genuine security are computer nerds. These tend to be the sorts of people that don’t sit very highly on my internal list of “people who stand to benefit the most from increased privacy measures”. For…literally every other member of society, this sort of implementation detail doesn’t mean anything^. They hear some (from their perspective) very abstract words like ‘open’, and all that means is that they’re trusting some league of computer nerds to tell them that something is ‘secure’. This is somehow meant to be more convincing than Apple, who, to most people, is at the very least another mob of computer nerds, but in reality also happen to have a pretty good track record of making phones that seem to work alright for people.
Beyond optics, let’s just look at attack surface. The implication that the sort of security holes that “openness” would fix are anywhere near the top of the list is…where’s that xkcd about cryptography and crowbars? It’s very clearly in the realm of nerdy cosplay. You know what is* a much more realistic threat? Some stupid third-party client on the Play store that exfiltrates all messages sent and received. Apple has absolutely no control over that. No protocol security accounts for that.
> You know what is a much more realistic threat? Some stupid third-party client on the Play store that exfiltrates all messages sent and received.
One way to avoid that outcome would be to have a first-party client on the Play store.
Instead, Apple drops all message security entirely from cross-platform communications for iOS users, allowing anyone to read those messages whether or not they have a crowbar. This is security 101: users do dangerous crap when the secure options don't have affordances for their use-cases. Users are lazy. If an official 1st-party secure client exists that meets their needs, they won't install a 3rd-party client. Users resort to dangerous and unsupported options when the safe, obvious options either don't work or aren't available.
And thankfully, we now know that it would be entirely possible for Apple to fix that problem and to move its own users off of SMS for communication with Android contacts, and we know that because a 16 year-old high-schooler was able to build that support with zero documentation. Presumably Apple is capable of doing the work of a 16 year-old. We now know that it would in fact be entirely possible for Apple using a 1st-party controlled, proprietary client with a proprietary protocol, to encrypt virtually every message that Apple users send to every one of their contacts, rather than what Apple does today where it encrypts... some of them.
None of this requires Apple to Open Source anything or to document or make available any of their protocols. The only reason Apple is in this position right now of needing to deal with 3rd-party clients is because of a lack of support from their 1st-party client.
> Instead, Apple drops all message security entirely from cross-platform communications for iOS users, allowing anyone to read those messages whether or not they have a crowbar.
I think that's my biggest gripe with the situation. Or my second-biggest. My biggest gripe is that the only notification that your messages are now not end-to-end encrypted is the green bubble. They don't tell you anywhere that the green bubble (also) means that.
No need for transparency here. Just know that no one has broken the encryption is all you need. Also you likely will not know if beeper sends a copy of your messages to their servers to sell, but who would you trust more won’t sell your info, beeper or Apple?
The first half definitely made me think sarcasm, then the second half... I mean I know some people actually believe this... Then I noticed you said "encryption" instead of "protocol". Breaking an encryption standard is obviously very hard, breaking a protocol is obviously not nearly so hard.
On the other hand, taking this stance would be insane given the post we're talking about. A company that actively circumvented apples security measures. So you must be being sarcastic. You just have to be.
Remember, on the internet it's kinda hard to tell. Make sure to throw in a /s unless you really REALLY sell it.
I wasn’t being sarcastic, I mean you do know there exist closed source for a reason whatever that is. For Apple to open their protocol would mean your messages sent to 3rd party clients, which means they could sell your messages for ad targeting or worse.
When Apple sends messages via SMS, they are sending your messages to 3rd party clients who could sell your messages for ad targeting or worse. Apple already does this. They already send your messages to random clients who could be spying on you.
It's just that in addition to sending your messages to 3rd party clients that could be stealing the data, Apple goes the extra step to make it even more insecure and also sends your messages completely unencrypted, so that everybody along the path from your device to the 3rd-party client can join in and also read your messages and can also use them for ad targeting or worse.
I'll make the argument that this is strictly worse for security than tolerating an encrypted 3rd-party client (or better, releasing their own 1st-party client rather than relying on SMS).
But Apple doesn't have to use it. They could release a messaging app for Android that used their own encryption, and they could encourage Android users to switch. But they don't do that, because distinguishing between Android and iOS users is ultimately more important to Apple than securing the conversations that Apple users have.
If RCS is garbage (and it is) then it is extremely weird that Apple has committed to supporting RCS for cross-platform messages instead of encouraging adoption of what would be a superior form of encryption for those conversations.
What you have to ask is, if you are an Apple user, why isn't Apple trying to encrypt every message that you send? Why are they asking you to use a garbage protocol when you send messages to Android users?
> yeah can’t imagine why apple doesn’t use it
Really, this statement should be reversed, it's difficult to imagine why Apple is planning to use RCS. Why is Apple more willing to implement a garbage protocol than they are willing to release a messaging app for Android?
His first sentence about privacy and security is nonsense, but his second sentence hits the nail on the head.
If the richest company in the world wanted their chat app to run on Android, it would by now.
It's strange Apple doesn't sell an iMessage Android app, but I'm sure they've had somebody do the math and found out that it's more money for Apple in the long run if they don't.
Completely agreed about the nonsensical first claim. We have many third-party clients for other messaging platforms where privacy and security are a primary feature. It's completely tenable, especially for a player like Apple.
Or put another way: If the privacy and security of imessage is compromised by someone building another client, I'd argue that you never had either to begin with.
> Completely agreed about the nonsensical first claim. We have many third-party clients for other messaging platforms where privacy and security are a primary feature.
I can't think of an any with independent implementations.
For instance, have a few third party Signal clients, which work by using the official libSignal . These are not third party clients, but third party GUIs. Use of libSignal on the official Signal network is also not supported or recommended.
Likewise, all the third-party Telegram clients I know of are forks using Telegram source.
This makes sense, because neither of these are stable systems. A third party has to stay up-to-date with features and changes made to the official servers and clients.
Do you know of a security and privacy focused messaging platform which is both:
1. documented
2. has multiple independent implementations of the networking and security protocols?
I suppose it is determined by where you set the bar, even more so with privacy which still varies person-to-person and can sometimes take a qualitative feel.
Security wise, there is interesting work adopting MLS (and I believe key transparency) under Matrix, see https://arewemlsyet.com for example.
the american consumer punches far above its weight. apple cares and goes to great lengths to wall imessage. See the article linked in this post for instance
you’re talking to a forum that is probably 50% iPhone and has very good technical reasons to do so, this is insulting and it’s absurd that it’s so casually normalized to directly insult people in this fashion
How did you manage to take this as a personal insult? Some people buy an iPhone for the blue bubble, some have what they believe to be good technical reasons to buy one, some people like the aesthetics, some people buy one out of habit. Stating that each category exists is not an insult to those who fall outside it.
> How did you manage to take this as a personal insult?
years and years of "apple sheeple" variants tend to take their toll, you're just the latest in an endless parade of microaggressions even if you don't think your particular case was notable.
why is it so important for you to push on the idea apple users being thoughtless trend-followers? just don't do that, be better. you can do it. the next time you feel like posting that, simply take a deep breath and don't post it.
there is just no reason to go around posting that "[device that 50% of people own] users are all doing it for [trite/dismissive reason]" in the first place, let alone on a tech forum where everyone has very specific reasons for their tech purchases. and it's so completely normalized, android users do it so routinely and don't even think that what they are saying is offensive. it's literally the classic microaggression problem.
It's a socioeconomic indicator for high status, and it would be foolish to ignore that as part of Apple's strategy.
Android doesn't suffer from that kind of complaint because it's often perceived as the opposite: a socioeconomic indicator for low status. It's socially acceptable to mock people for choosing high socioeconomic indicators, but not low socioeconomic indicators.
"You only bought that because you're rich" has a very different ring than "you only bought that because you're poor".
That perception of low vs high indicators is somewhat wrong (high-end Android phones cost more than the latest iPhone, used iPhones are pretty affordable) but it is the perception.
> on a tech forum where everyone has very specific reasons for their tech purchases
Thats a very funny statement. From my experience tech people in general are the ones falling for vanity, fashion, dogmas etc. most often while claiming some "practical" reasons
> It's strange Apple doesn't sell an iMessage Android app
Apple doesn’t sell apps they sell hardware and services. There’s no incentive for them to provide a free iMessage app for android, and I doubt many people would pay for one.
Look no further than blackberry... Their days were always numbered as the only reason to keep it is the messaging (and a bit the keyboard).
Another theme here is BBM (Bloomberg Messaging). People/Companies pay BB five figures per year just to get BBM. Why would they ever release a messaging app outside of the terminal. They will die before this happens.
I didn't compromise the security of iMessage as a whole, it just exploited a way to get people into the system that was not planned.
Imagine there is a theme park that has normal ticket booths and some requirements there to get in. Then there comes a Beeper that finds a hole in the fence on the perimeter and sets up their ticket booths there. It's in theme park's best interest to close that hole and cut off the revenue stream of somebody pigging back on their theme park.
Except they charge a thousand dollars to enter and then let everyone else in for free but they have to wear a badge and the pictures they get from the roller coaster photo booth are 240p.
And no one is obligated to come to the Theme park. There's an entire world of people who never visit the theme park, mock the people who do, and couldn't care less about it. But some people want to be included as going to the park, when they don't. Some people are very judgy and don't want to talk to people who don't go to the park...
> It’s untenable that there’s unsanctioned client software for a messaging platform for which privacy and security are a primary feature.
What a stupid take on the situation. At most it's untenable to Apples short term financial interests. A well designed protocol and implementation would be even better at protecting user privacy and security especially from a privileged attacker like the service provider and anyone able to put covert pressure on them.
The only way in which vendor lock-in helps the the existing users is that spammers and scammers have to invest additional money to acquire Apple devices to create new accounts instead of just phone numbers and a labor to create accounts.
On the money, but unsurprising. Gruber is an Apple fan-boy through and through and it doesn't take much of a guess to posit the exact "prediction" he made. It was clear Apple was never going to put up with this, but it was likely accelerated by all of the media attention.
Apple is, however, nothing for "privacy and security" beyond what they need to do to be marginally better, and that's a stretch these days. If Gruber really believes what he wrote he's full-on living in Apple's orchard behind the walled garden that Tim Cook splendidly gatekeeps. But because Apple puts marketing dollars behind ads that say "privacy" and "security" it must be so!
This is why it's always funny to me when the trope of the hour is the mass privacy failures of Signal through use of phone numbers. And then the author turns around and types out an iMessage to a blue-bubble friend. I really hope we can move beyond the Apple reality distortion machine and move to truly user focused platforms that aren't designed to steal user data or make the board richer.
yes, you can indeed build a secure system on the basis of increasing the economic cost of attack beyond reasonable levels and by forcing attackers to repeatedly slash their stake to perform an attack
Easy to be right on the money here. This is the default MO. Regardless of if you are paying for it or are licensed or are doing it despite the tech giant whose toe you are tickling. Twitter API springs to mind.
I heard/saw quite a few people saying Apple either couldn't or wouldn't cut them off—and that even if they did, it would take a while. They were ridiculous takes, yes, but apparently made in earnest.
While it would ruin the experience in practice (not being able to receive any notifications), I don't see why someone couldn't perfectly reverse engineer the protocol.
Beeper made several design decisions that made the app super easy to use (i.e. using a single certificate that wasn't supplied by a user's phone), but if you extract the necessary source material from an old jailbroken iDevice, you could create an iMessage clone that Apple can't ban without either legal action or breaking compatibility with all easily jailbroken iOS devices.
Back in the days of AIM and MSN, even large companies used reverse engineering to get chat interoperability, and it was so successful that AIM left open an RCE vulnerability to push shellcode so that Microsoft couldn't chat through their service.
There were a lot! Usually taking the form of: 1. They’ll have to do a major update to iMessage, 2. But what about Hackintosh?, or 3. EU regulators will stop it
It looks to me like there is an advantageous business relationship between Beeper and their customers. As a general rule, Apple is free to change their programs and how they work. However, I think there’s a plausible argument for tortious interference here if the sole purpose was to prevent interoperability.
There's a bunch of reasons why this is unlikely to be tortious interference, but one of the obvious ones is the contractual Terms & Conditions that apply between Apple and its users; I doubt Beeper is liable here, but if interference was a thing, my bet (not a lawyer!) is that the liability would point the other direction.
My read of GP's comment was that the claim of tortious interference would be by Beeper against Apple (for interfering with Beeper's relationship with Beeper's customers).
Apple is not preventing anyone from downloading beeper, or giving beeper money, or running beeper software. They are exercising control over their own servers.
My understanding of tortious interference is that it is broader than actually preventing others from using a service. Even just saying things to dissuade them from doing business with a company can qualify.
Apple would claim that you pay for the iMessage service as part of the purchase price of hardware and software. From this perspective it's not blocking interoperability, it's blocking theft.
Whether that argument holds is for governments and courts to decide, ultimately.
I agree. The obsession with "blue bubbles" is something I only hear about from tech writers. No one I communicate with in the real world has ever mentioned it. Supposedly teenagers care about this, but that seems like a poor basis for anti-trust action.
At the same time, I miss the era of rich third party client ecosystems for things like AIM or MSN messenger. Blocking interoperability is a bummer for innovation.
Android vs iPhone is definitely a thing people in their 20s and 30s even use to judge others. I have polled quite a few family/friends, and it is near unanimous that it is a dealbreaker in dating, mostly because they assume there is a higher likelihood they will not mesh with the type of person the non iPhone user is.
>but that seems like a poor basis for anti-trust action.
Yes. And I'm saying, were this a live issue (I don't think it is), the graver liability might be for Beeper interfering with Apple's contracts with its users.
In what way would Beeper's action cause Apple's customers to breach a contract with Apple? I would think most of the people who would purchase a service like this would be Android users, not iPhone users. Some of them might own Macs, but what would be the contract that the user would be breaching that would result in damage to Apple?
So your thinking is that these end-users have signed some sort of agreement with Apple, and that agreement says they won't use any unauthorized services to connect to Apple servers, or some such thing?
There’s certainly a contract there, but it’s not obvious how a customers compliance the terms and obligations create a profit for Apple. I think most outside observers would generally assume that Apple‘s profits come from the payments the customers make to Apple, when purchasing devices or making subscriptions. After all, the only people subject to, and breaching the terms of service are Apple customers who did pay for their phones, etc..
> The CFAA prohibits intentionally accessing a computer without authorization or in excess of authorization, but fails to define what “without authorization” means.
- From the National Association of Criminal Defense Lawyers
Other way around. If anything, it sounds to me like Beeper Mini was acting illegally by accessing Apple’s servers in a way they didn’t give permission for.
The CFAA is ripe for abuse. I’m not saying applying it here would be just or not, only that Apple likely wasn’t the one acting illegally.
I think that’s certainly an argument that Apple would make. However, it seems that this app was simply sending requests and receiving responses that there was no code injection or compromise of Apple servers, or of credentials, or anything of that sort.
It's also entirely possible that no law has been violated by anyone at all. What Beeper Mini did is probably not illegal. What Apple did in response is probably not illegal.
Not particularly relevant due to lawsuits involving game cheating, where the circumstances are very similar.
Beeper is lucky they weren't sued under the DMCA anti-circumvention clause, as they clearly were bypassing the technological measures Apple uses to prevent genuine devices from connecting to iMessage & Apple services.
I wonder if any of the encryption stuff Apple uses would give them an argument, like convincing their system to generate keys.
I think you’re likely right though. If they had such a claim I think their lawyers would have been on it instantly.
That’s why I mentioned the CFAA. Accessing servers without someone’s permission is the exact kind of thing people have gotten very stiff punishments for under the CFAA in the past. It’s basically the main reason I know the law exists, stories about peoples ridiculous punishments for relatively benign things.
Sure it’s useful for real things. I bet you can prosecute ransom under it. Or hacking to break into a rival company.
But it’s also great for when someone embarrasses a politician with stuff that they published on their own website and “something has to be done”.
Beeper mini includes a hosted service to receive APNS notifications (meant for Apple software)
So I would summarize it as the corporate entity connecting to an Apple API and using it in undocumented ways that they reverse engineered, intercepting messages meant only for Apple software, doing so without prior permission, for purpose to selling access to services which would normally be covered by an Apple EULA.
It is not quite like a smaller word processor wanting to be able to import Word documents - without tying into Apple's service, Beeper Mini has zero value.
That’s fair, but compare it to SMS. What if Apple blocked SMS messages sent via cellular carriers, which are also using their services (software on phones, etc.) Then suppose it wasn’t malicious SMS or spam, but legitimate messages sent using a competitor’s product (e.g. from all Samsung phones).
How are you going to make a case for tortious interference when the would be interferee is profiting by using the interferer’s resources without payment?
From beepers website, there’s no use of apples servers when iMessages are sent from a beeper user to a beeper user. Rather, they only pass through Apple when sent to an iPhone user and in that case it’s the iPhone user that’s utilizing apples resources. And in that case there’s an Apple device owner, who is paid for the right to use iMessage servers.
Not sure why this is getting downvoted – IAAL and this is definitely something worth considering. This particular type of law varies from state to state, and can be quite broad. I've talked with other lawyers about it in the past, and my understanding is that it's frequently asserted when companies make counterclaims in business litigation.
That doesn't mean it's a sure winner, just that it's a live question until more info is known. I imagine Apple would say they need to tighten up any parts of their system that could allow for spoofing or other security issues, and that was their 'legitimate' reason to make these changes.
I think most or all states recognize that the defendant’s actions must not be justified or privileged. It’s hard to imagine how Beeper would meet that element on these facts.
I’m not a lawyer, but I do know how computers work. I’d bet the farm on the very safe assumption that any protocol change that blocks a third-party client at the very least can plausibly be claimed to be in service of security, and most likely be a legitimate claim in reality. It is probably being downvoted because it’s incredibly far-fetched.
I agree that this would be their argument. But as other commenters mention, this area could be a minefield for Apple due to their dominance in various markets. It's possible they wouldn't want to get sucked into a lawsuit about this, even if they thought they could win, since they might end up making statements that would have a larger detrimental effects in other cases/potential cases.
Maybe (or maybe not) plausible, but I think it's irrelevant, because there's no way a small company like Beeper could beat Apple's lawyers at this game. It will end up bankrupting Beeper long before it would even matter.
This is unfortunate, but not untrue. Even just going through discovery on this issue would be quite expensive — and would be critical to proving Beeper's case.
> Seems irresponsible for Beeper to charge a subscription for an unsupported service.
Completely wrong. It's a job-seeking ad. “Look, I'm ruthless enough to fuck over users who buy this bogus subscription.” Which SV startup wouldn't pay millions for a crook of that caliber?
