You can't realistically keep apps from tracking users without permission unless you're rejecting apps that are discovered to be doing that. If they have network access, they can track. The behavior is too abstract to be handled with permissions alone.
The apps cannot track if they have no permission to access the respective APIs that give them data they are tracking. What are they going to send via the network? Only things that the users specifically give to the app.
Look up what the Apple's tracking-prevention policy prevents for users that don't opt-in to tracking. You cannot ban generating device or user identifiers with OS permissions alone. Prevent using the built-in ones, sure, but fingerprinting or otherwise creating device or user IDs to share with 3rd parties and other apps? I'd love to see what a permissions model would look like that could do that automatically, at the OS level. I don't think such a thing exists. Not for any app with enough access to the system to do anything remotely useful in the first place.
Getting sued for stealing software from the users, and for interfering with the business of the suppliers, neither of whom have any agreement with Apple to let them ‘reject’ software arbitrarily.
Apple would not be 'stealing' software. Nobody promised that OSX could run any software the user wishes. Does Apple steal software and "interfere with the business of suppliers" every time they break backward compatibility?
They just need to time a new policy to a major release (say they make it apply only from that release on), and that would be no different then any other breaking change.
It wouldn't be popular on HN, but it's technically possible and legal. I'm sure that the Apple fans here will support it unreservedly.
>>Nobody promised that OSX could run any software the user wishes.
>In fact they have said this publicly in interviews.
So I can sue them for not running Apple II programs? Cool! There were always programs that failed to run for some reason or another, and programs taken out of the Mac store, etc.
>Apple doesn’t force you to install operating system upgrades, and many people don’t upgrade if it will break the software they work with.
Sure, just apply a new rejection policy after an upgrade, and state it applies from that version on. That's what Apple would normally do anyway. So you're just admitting I'm right.
>>In fact they have said this publicly in interviews.
> So I can sue them for not running Apple II programs? Cool! There were always programs that failed to run for some reason or another, and programs taken out of the Mac store, etc.
No, you just don’t know much about Apple.
They haven’t promised to be backward compatible with everything, but they have promised not to stop you from running what you want to run.
I.e. they have promised not to do what you are saying they should do.
> Sure, just apply a new rejection policy after an upgrade, and state it applies from that version on. That's what Apple would normally do anyway.
Apple has never done this.
> So you're just admitting I'm right.
Obviously not. In fact you have proven yourself completely wrong, by acknowledging that they could not do it under their current license and with their current software and would need to get people to agree to a new contract.
Yes, Apple, (or anyone else) could offer a service for the Max that users sign up for to remotely disable software they disapprove of.
I've always taken Zuck's infamous "dumb fucks" comment to come from a place of astonishment, more than malice. Posting tons of private info under your own name online was strongly against Web norms at the time, but all those newbies didn't know that. FB and others made it normal, but the reasons it was a bad idea to begin with didn't go away.
I would even say it was against social norms. Don't talk to strangers. Don't give away your phone number. Don't give away your address. Don't tell state your mother's maiden name.
It was such a simple thing to get all of those new people on social media to give up all of that very personal information without hesitation. Yet, if some random person at the supermarket asked you any of those questions in person you'd definitely raise an eyebrow and walk away. SocialEngineering++
Exactly. If you used the internet from the beginning you clearly saw how Facebook is a data harvesting scam. By late 2010 I'd chatted with several engineers at Facebook about how they were clearly storing all chats/messages indefinitely, even if you deleted your PMs. So to the dude up there downvoting me, yes, many of us in tech knew this very early on. It was literally the goal of Facebook from the time you ever heard about Facebook.
"Social" should be an Internet protocol. The only reason it's not is that we basically stopped making protocols (well, ones that gain any meaningful traction, anyway—I'm aware there are some lightly-used efforts at social protocols) because all the companies in a position to push them to a meaningful number of users are better served by making interoperability difficult. The "free" services spyvertising economy, where captive non-paying user count & eyeball time is what matters, is why things are this way.
I see this argument made often on HN, but it's not clear to me how an internet protocol would make social networks more accountable towards their users. Do you mind explaining your reasoning here? Specifically, how would a protocol prevent motivated companies from tracking your personal information?
> Specifically, how would a protocol prevent motivated companies from tracking your personal information?
They could still try! But you'd have options.
Take email, for example. I cannot imagine something like that coming into existence today.
I can use my own client to avoid ads and tracking from my service provider—did I download this message? Sure, the server knows that. How long have I looked at the message? Which message did I look at next? Did I follow any links (yes, someone might track that part, but my email provider's going to have a hard time doing that)? What mouse movements did I make while looking at it? No such luck there, and yes websites and closed-platform services do track that stuff.
I can switch providers. Say my email provider starts injecting trackers into all links. I can just dump their ass if I don't like it. I keep using email, and now they receive zero info about me (I mean, they might get a little if I send emails to their users, but you get my point). If I have my own domain name I don't even need to tell anyone I switched.
I can email someone using a different provider. Yes blocklists or whatever might cause a problem but, fundamentally, this does work.
Protocols force providers to act like a telco, at least, except that the situation's even better for software because the barriers to entry in the market are so low... unless all your competitors are giving away access to their strictly closed ecosystem for free, and not supporting open protocols. Then you're screwed, and that's exactly what's happening now and why the Internet protocols are largely frozen in time.
I see, thanks for the detailed reply. Yeah it's sad that companies have no incentive nowadays to support open protocols (besides the ones that already exist). I wonder if regulation could solve this problem or at least encourage healthy competition into the marketplace.
at the very least it'd mean you could take your data and connections out of one service and go to another which would mean there is genuine competition that isn't hampered by network effects of platforms.
Usenet, email, http, XMPP, IRC, et c. Yes, just like those. In combination, that bunch is already not too far off. The trouble is that anything trying to do that is competing with "free" spyvertising services, which have no incentive to integrate with them (i.e. implement the protocol), unless it's to do it temporarily to eat their meager market share before cutting them off. IMO that dynamic is why protocols have stagnated for decades. Working on a client or server for some new protocol is thankless when you know it'll be niche at best, and more likely DOA. Making a go at a business with one is insane in this market. So they stagnate. No new ones catch hold, and old ones make slow progress at best, or gradually die.
ActivityPub is more than lightly used, it just isn't used by people you want to associate with. You pretty much have to either accept radical leftism and hang out with tankies or you get to hang out with the actual Nazis that are blocked by the "mainstream" leftist servers
Yes yes, there's radicalization for everyone! God forbid you want to use social media for something besides political fighting though
There's such political fighting everywhere on the 'net. I use ActivityPub for musicians, programmers and Cory Doctorow, and don't have to deal with much of that, because I just avoid it.
The Federated Timeline is slightly cursed (I haven't curated it for a while), but less so than Twitter. (My instance, Fosstodon, doesn't really federate with the Nazi instances; those it has ended up federating with have been swiftly blocked, because Fosstodon's admins don't like admin-condoned harassment of their users.)
> My instance, Fosstodon, doesn't really federate with the Nazi instances; those it has ended up federating with have been swiftly blocked, because Fosstodon's admins don't like admin-condoned harassment of their users.
And I'm glad that with email we don't have server operators deciding on politics for their users. ActivityPub has a long way to go if labeling instances as "Nazi" is enough break federation.
It's bigger than that: iOS is big enough that Facebook charging on that platform would be an existential threat to the company.
How?
It opens up the perfect opportunity for some competitor burning VC cash to swoop in and grab a ton of market share in a hurry, with a free iOS app.
FB knows this, so yeah, it's a completely hollow threat. But, just the idea that one of the tech giants has been backed into a corner by the risk of competition from paying-for-marketshare VCs or operating-in-the-red-on-purpose other tech giants, is really, really funny to me. No fun, eh Facebook? Hahahaha.
The strategic lesson is, always move upstream until you own the hardware.
Google had the search and moved upstream to own the OS and protect his search. But still has to beg Apple for 25% of its users (and 40% of its revenue, if I understand).
Content (films, instagram personalities) are at the mercy of apps; Apps, even on Heroku or Atlassian platforms, are at the mercy of the platforms; Platforms are at the mercy of cloud platforms (AWS, etc) who own the hardware.
The only counter-example is telecoms, who owned the hardware but became dumb pipes, after 20 years of extremely bad behavior (including modifying HTTP pages on the go and injecting JS to insert ads, for Verizon).
I was just thinking of this. And came to the conclusion how fragile Facebook really is compared to the rest of FAANMG. Google has search/YouTube/Android. Apple has a thriving iOS and hardware business. Amazon has AWS. Microsoft has Azure abd Office. All of Facebook's business is based on data mining. If Whatsapp starts charging money Signal will laugh all the way to the bank.
I won't be surprised if Facebook starts shopping for a phone manufacturer and spins their own Facebook mobile distro in the future.
Facebook Mobile distro would be something, but it’s an expected move. They’d have to be more creative and attack sideways.
Facebook could enter the actor/actress recruitment market, own contracts and manage their Instagram along all their artists’ public reputation and persona. It’s not hardware but at least it’s real-world assets that reinforce their network’s desirability.
Facebook could buy Homebrew or IntelliJ and become a tool that every developer for most languages need to use, and it would give it more leverage in negotiating with AWS/Azure (Oh, the SDK has bugs with GCP? too bad!)
Those are just examples that have not been implemented because they are half-ideas, but it’s the idea of attacking really sideways.
IMO it was always a fundamental mistake to force the programmer to deal with the event loop by default. Run async in the background, but present as sync to the developer unless otherwise requested, would have been a much saner design. Unless you're developing a framework or library, odds are good your ratio of leveraging async versus contorting yourself to make it (from your script's perspective) go away will be 1:10 at best.
JS keeps coming up with new ways to make this less painful, but it's ridiculous every time because it's a fundamental problem with how Node presents itself. A comical sea of "await"s in front of damn near every call is the modern version of this, and is utterly typical in real JS codebases, but before it's been callback hell, or screwing around with promises all over your codebase when 90+% of the time you just wanted things to execute in order (from your perspective), and so on.
I think it's also made much worse by how JS doesn't care about whole classes of bugs. Forgot an `await` somewhere or called an async function assuming it's sync? Now you've got a bug and in some cases no idea where to look for it. TypeScript is also blind to it (although now that I think of it a linter might flag it?).
A really good point, and all the more reason to make developer-visible async behavior something the developer has to to ask for, even if the call is in fact async under the hood and might let, say, code handling another request run while it's waiting on I/O.
I think a pattern where there are one or two great places at the lowest level of a Node program for program flow to act async, and then a bunch of business logic where it rarely is (probably running "under" the part where async makes sense, if you take my meaning) is far more common than those where async-friendly flow is what you want for over 50% of calls. "Call this chunk of code async, but run everything in it exactly in order" is super-common, and the interface to achieve that is exactly backwards in Node.
I can't even count the number of times I've seen a unit test giving a false positive (or, perhaps more accurately, not even run) because the developer forgot to properly use async/await or use the done callback.
Linter flags when you put an await in front of a-non async function, but, alas, the opposite is not true (call of async without await). This has always been source of bugs in my code.
The notion that people making $350K are having a particularly rough time is nuts.
As for inflation, it's threatening to price people under your $150k/yr cut-off for "hardship" out of decent housing even in mediocre cities, ever, and may eventually hurt creditors some (which, I mean, that's a fine outcome according to most people, I'd think). Those with $150k+ salaries had damn well better have some assets to their name, including maybe a (mortgaged) house, and so will ride the inflationary wave alright. Those with little or nothing, on the other hand, may now never be able to afford anything. Young workers just starting out, who have high-ish income but only because they live in a place with insane housing prices, are getting screwed, too, sure, but established professionals will be fine, unless they've somehow managed not to acquire assets over the years.
Pity the normal couple with $60,000/yr household income. Believe it or not, they raise kids on that income. Go figure.
I wouldn't trade places with someone getting by on unemployment for their $12/hr job they were laid off from, certainly. I don't think they're "looting". We're clearly top-heavy on capital, given how the markets are behaving, so I think I've got a better idea of where the looting's happening.
So you're saying that it's the high earning savers that are screwed but professionals that took a mortgage will ride the inflationary wave. Got it. Everybody most be over-leveraged for the system to work.
A lot of JS in the wild favors putting everything in objects (maybe not explicitly, but they end up doing it a lot anyway) so gets away with a lot of "const" use that still lets them mutate the values of those objects. If you're dealing with primitives you're going to need "let" a lot more.
That is kind of my point, I don't often work with primitives that need to be redefined. I'd rather operate on an object where I can mutate its value rather than redefine the whole thing.
Now, whether asking users to pay for a social network at all is a viable business model, is another question.