> 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.
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.
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.
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.
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.
"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.
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.
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.
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.
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.
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.
The work seemed to pointedly avoid micromanaging, by instead finding out how to open up the correct pathways between cells in a region and instruct them to become something else. No need to say "OK, these cells need to become a retina, these need to become a cornea" or to figure out how to change the body plan of the creature at the DNA level—just place a "become an eye" marker in the right spot, and boom, the cells self-organize to become an eye, and may even manage to connect themselves to the CNS such that it becomes a functioning eye!
The key insight seems to be that you can hack the (as the research put it, by analogy) software of a set of cells and let the hardware (DNA, cell mechanisms) worry about exactly how to do what you told them to do, so rather than, say, figuring out how to read DNA and tell what kind of organism will come out of it such that we can start adding or removing bits here and there (very, very hard), you can instead screw around with inter-cell signaling to hijack functionality that the cells already have, but just aren't using, to get them to do new things.
I thought there were several "holy shit" moments in the video. The cancer thing—yikes. Reconnect genetically-broken, actively dangerous cells to the inter-cell communication network and they stop acting crazy, while still having messed-up DNA? That's a surprising result, and a powerful demonstration of what the technique can accomplish (may not be therapeutically useful for a bunch of reasons I can think up, but it still seems like a notable, surprising result)
Another was the sticky "memory" of a modified organism, that is, the worm that'd had its tail cut off then been instructed to make a second head there instead, and then had that cut off and... grew a head again, without further prompting, demonstrating that body layout and gene expression is some combination of DNA and a kind of cell-memory or cell-state across the whole organism, not something driven entirely deterministically by DNA alone.
The part about tricking worms into growing heads for 100-150 million-year separated evolutionary relatives, complete with the correct-for-the-other-species brain, was nuts. The "instructions" are still there, just dormant, and if you confuse the cell-memory (if you will) of what it's supposed to be it'll sometimes decide to be the wrong species. WTF.
> The mechanisms in the body that grew out your more complicated macro qualities are finely tuned to do all of it at once. Maybe we could micromanage it ourselves, but the actual body doesn't know how to do it itself.
The linked video in the grandparent post argues pretty convincingly that the body might know exactly that, actually.
t͡ʃ, t͡ɕ, ʈ͡ʂ all sound so close to my poor ear that I'd struggle to articulate the difference. They sound like exactly the same thing at slightly different speeds.
Gmail's so bad now that I only use "classic HTML" Gmail in the browser, and native clients (Apple's Mail, for example). I have no idea how they managed to make a relatively simple "web app" so huge and heavy. You could add all of full-fat Gmail's features to "classic HTML" Gmail for very little cost in bundle size and active resource use—though the result might not be an "app" in many folks' opinions, I guess. I just know navigating classic Gmail, with its "bad" full-page loads, is way faster than the "efficient" AJAX-style crap on normal Gmail.
Mobile Gmail's not just heavy—it's broken. Whatever stupid, misguided bullshit they're doing with scrolling makes it register clicks where they weren't intended if I'm not super careful.
But you don't need to run a giant spying system to make that happen, so the companies whose moat is their giant spying system don't want to even try that. They also happen to have all the users/eyeballs (they need them for their spying system, in addition to serving ads to them). So it's hard for anyone else to try it to see how well it works.
The collection is per se harmful as long as warrants exist.
Beyond that, it's an open secret (as in: it's been mentioned several times in available documents, but never deliberately disclosed or extensively discussed publicly, so far as I know) that since at least the mid or late 00s the US government has had contracts with multiple major tech companies that have a high level of access to citizen Internet traffic to basically search their databases of Internet activity at will. Which companies these are, I'm not sure—I suspect it's mostly telcos, personally—but it's another reason the existence of these datasets is inherently dangerous, and that they should not be permitted to exist at all, no matter who holds them.
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.