I predict Bluesky will add some form of targeted advertisements in the future once the user base has grown to a certain size. Isn't that obvious? I'd assume that's also why investors are willing to invest.
They are trying to avoid that. I hang around there pretty much. I expect premium services subscriptions will be the first try. If that works, and I think it could, that will be fine. The fact of it being a public benefit LLC makes the profitability requirement much less pressing.
Also, there will be revenue opportunities from being the canonical AT Proto first mover. It’s way too early to tell, or worry.
What does being a public benefit corp actually stop them from doing on a practical level? I'm not familiar with the classification.
I am, on the other hand, familiar with the likes of Blockchain Capital, from whom Bluesky has accepted 15 million dollars in Series A funding. At some point they're going to get crypto wallets and air drops integrated just like Keybase did and the profits will come out of scamming the uninformed.
I certainly hope it works because rebalancing the world away from X is a win for the world.
I'm not sure we have much precedent for that model working to sustain any form of social media for the masses. It has in my experience been great for specific services (happily paying for pinboard on a yearly subscription!) but I'm not sure it will work for aby service aspiring to be a universal town square.
Yeah, and then experts will use ad-free alternative clients and most people won't. But it will still be better than other social media systems that ban alternative clients.
Ah, the circle of life for VC-funded social media... Let third party devs write cool apps, copy the features that stick, then pull their rug. Then proceed to squeeze ad revenue in a death spiral as the MAU gently falls off.
Do you not understand fiduciary responsibility? If they can charge and make more money they are effectively obligated to. They would need to sell their investors against the plan that everyone uses AND propose a plan that will make more money.
That’s not how fiduciary responsibility works. It’s very easy to say, “we’re not going to do X because we don’t think it’s a good long term investment due to brand destruction”. This happens all of the time. It’s a complete myth that they are responsible to force short term charges for short term revenue.
What you’re confusing it with is shareholder pressure, which is orthogonal to duty. What Reddit went through was just kowtowing to large potential investors to increase IPO demand.
Not sure where you got that one; they were net profitable for two full years at least. They were generally FCF-positive, and could have reached paper profitability fairly easily at the cost of reducing spending (though their shareholders likely wouldn’t have liked that; the markets like to see smallish tech companies spending what they take in, not paying a dividend, as a general rule).
Twitter was not a massively lucrative company, but the idea that it was financially near death is a myth.
Twitter didn't wait for Musk to attack alternative clients, or charging for API access. Pretty sure that's why it took him all of 5 minutes to flip the switch and turn everything completely off.
> To save you a click, the social network wants to charge up to $2899.99 per month for developers to use this new API on up to 250 users. Of course, that’s untenable. The developers don’t want to pay it and, frankly, neither do their users, us, you, or any other sane person. Additionally, a good third party Twitter app will clearly have more than 250 users. However, as Luke explains, this new API is never (and was never) for third party apps.
You wouldn't be the first engineer to fade into irrelevance because they were too proud to adapt to the changing world around them. I'd encourage you to open your mind a bit.
The entire article is about office IT. Productivity software, etc. Basically, people emailing excel sheets to each other. I don't see how the OS running on servers is related to that.
Yes it does, but is it because some people believe and argue that jumping from a bridge "is not that bad" or "may be justifiable under some circumstances"?
You just need to use the right tool for the job, you see. If jumping from a bridge is sufficient for this person, who are you to categorically disallow it?
In my experience arguing with people about these kinds of bugs--which I have done a lot of, as people would write apps that are buggy and then blame me for their app being hacked, as, clearly, if jailbroken phones didn't exist or were more illegal or whatever, they would have been safe--a lot of the time people are under the impression that their code on the client is secure. They will believe:
1) that it is effectively impossible to reverse engineer binary code and understand it (particularly so if it is obfuscated in any way at all, as the security claims made by the people who develop such tools are often absurd).
2) that it is additionally possible to prevent the hacker from getting access to even their binary, as it is encrypted by the app store and might require jailbreaking the device; either way, it is akin to piracy and thereby illegal.
3) that it is possible to add further mitigations to prevent people from analyzing your app, such as certificate pinning for all of your network requests, or trying to verify the device is "authentic" and not running a jailbroken OS.
Now, "obviously", all these beliefs are all false; but the problem is that, in some sense, they also are not entirely wrong, and so they stick: I am extremely competent at reverse engineering, but I am going to groan given the task of reverse engineering an iPhone app if I find myself forced by certificate pinning to work around some obfuscated network checks after stealing a copy of the app using a jailbroken phone... like, these mitigations actually do make it a lot more annoying for me to do any of this work, and I certainly am not going to that much effort in a casual drive-by fashion.
Meanwhile, client-side security is also a thing the industry relies on in other ways: developers want to limit denial of service attacks or limit piracy of their product or limit external access to private user data stored on the device, and these techniques that "don't work" can certainly raise the bar for an attacker, and so aren't considered dumb in the general case.
I think the real core education is that people don't understand how to determine what kind of credential should be required to access what kind of information, and that different pieces of interoperating software might all possess different credentials, and the limits on those credentials need to be honored.
This also comes up with things like with tokens for various services: people will sign up for a service, and then store the with token in the app so they can make API calls from the client... but now, I have their auth token, right? They don't get that, and part of the reason is that a lot of services kind of encourage that model. And like, with your OpenAI key, at least the damage is probably "just" monetary; but, if it is your AWS key, suddenly it is super serious.
So, yeah: I think developers will, in fact, say stuff like client-side filtering "isn't that bad", or that "it might be justifiable under some circumstances"; and they might even be sort of almost right at times for certain kinds of checks (not with other user's data, of course ;P) under certain kinds of tradeoffs... but then misapply the boundary in a way that is flat-out incorrect.
Now, is this article the article that would explain this or convince the developer that these cases are wrong? I don't know... it isn't even clear to me that that's their audience, as opposed to being more of a portfolio piece that the author does understand this issue and thereby is competent at one or both of security engineering or website development (and, FWIW, I think it is sufficiently successful at that).
> First, you have to copy all production data. It’s expensive, and a reckless breach in privacy and security, but it’s doable.
So, what does "doable" mean in this context? We unnecessarily increased the attack surface for production data and until today haven't suffered a data breach because of it?
A staging env with actual prod data now needs be treated as a production environment. A system is only as secure as its weakest link, so an attacker will have an easier time getting into that "staging" environment where things are tested out, no?
