The death of privacy front ends?(tux.pizza)
tux.pizza
The death of privacy front ends?
https://tux.pizza/posts/service2/
66 comments
> It should be possible to export 100% of one's data stored in a service like Twitter or Reddit in a reasonably-parseable format (a tarball of JSON as one possible example, or maybe a SQLite database, or whatever is appropriate)
You can do that. You've been able to download, directly from twitter, an archive of pretty much your entire account. It's not quite JSON - it's actually a .js file that declares a single variable, but it's close enough.
You can do that. You've been able to download, directly from twitter, an archive of pretty much your entire account. It's not quite JSON - it's actually a .js file that declares a single variable, but it's close enough.
It's incomplete, though - my archive for my old accounts misses all media (including the profile of my long-deceased cats...), and it's a bit useless because while yes I could probably import it into some fork of Mastodon, that doesn't mean the "social web" still works as there is no federation between Twitter and Mastodon.
Expecting a best effort archive of data the platform still has archived is one thing, but expecting it to be complete and portable to a totally different service isn't realistic, especially when Twitter never claimed to support any protocols similar to WebMentions or ActivityPub.
You can do the same with reddit. They give you a bunch of CSVs in a zip file.
Regulations on data exports doesn't solve this problem at all, it just means an endless goose chase of exporting and importing. Additionally, we open people up to even larger data leaks if the entire export and import path isn't regulated. We already have a problem with this in regards to switching password managers.
Regulations on what data can even be collected will solve this problem, and negate the entire reason for using these front ends.
Regulations on what data can even be collected will solve this problem, and negate the entire reason for using these front ends.
Agreed that we desperately need privacy legislation that makes surveillance-based software much less prevalent. In addition, stopping this bundling of proprietary javascript clients with service hosting seems like straightforward antitrust action that doesn't even need any new legislation. Any action that a user can do through a web browser should be required to be made available as an API for programmatic access.
I'd expect this kind of regulation to kill off many of the popular web apps once and for all. The would also be open questions like whether the API must be free to use, could have some legal freemium model, and how a "fair" price would be determined.
Companies aren't going to want to be forced to provide a fully functional API. Not only would that mean a large amount of extra cost to build, test, and maintain but they are also more open to issues from hacks and bots. It's be much easier to kill their web app and tell everyone to use a mobile app instead.
Companies aren't going to want to be forced to provide a fully functional API. Not only would that mean a large amount of extra cost to build, test, and maintain but they are also more open to issues from hacks and bots. It's be much easier to kill their web app and tell everyone to use a mobile app instead.
> I'd expect this kind of regulation to kill off many of the popular web apps once and for all
I wouldn't be so sure. This whole industry works on having defaults that most people just accept. It's quite easy to set up an ad blocker, and yet most people just don't.
> The would also be open questions like whether the API must be free to use, could have some legal freemium model, and how a "fair" price would be determined.
I phrased my proposal the way I did on purpose. There's no restrictions on what a company can charge for an account, just that "API access" is always included with it. If a company wants a freemium model, that's fine. If a company charges a subscription for all accounts, that's also fine. If a company bans an account for whatever reason, API access for that account goes away (the arbitrarity and capriciousness of bans is a separate topic though)
> large amount of extra cost to build, test, and maintain but they are also more open to issues from hacks and bots
This is the standard FUD about anything that's "different" or creates a modicum of requirements on companies. They're already publishing APIs for the proprietary apps to use. Nothing changes for "hacks" unless they're relying on the thinnest of obfuscation. And the whole point is that a user using a "bot" should be given the same consideration as a user using a proprietary front end - services should police user behavior rather than being lazy with method of access.
> It's be much easier to kill their web app and tell everyone to use a mobile app instead.
Except most "apps" are also just proprietary front ends to services hosted elsewhere, and thus run afoul of the same bundling.
I wouldn't be so sure. This whole industry works on having defaults that most people just accept. It's quite easy to set up an ad blocker, and yet most people just don't.
> The would also be open questions like whether the API must be free to use, could have some legal freemium model, and how a "fair" price would be determined.
I phrased my proposal the way I did on purpose. There's no restrictions on what a company can charge for an account, just that "API access" is always included with it. If a company wants a freemium model, that's fine. If a company charges a subscription for all accounts, that's also fine. If a company bans an account for whatever reason, API access for that account goes away (the arbitrarity and capriciousness of bans is a separate topic though)
> large amount of extra cost to build, test, and maintain but they are also more open to issues from hacks and bots
This is the standard FUD about anything that's "different" or creates a modicum of requirements on companies. They're already publishing APIs for the proprietary apps to use. Nothing changes for "hacks" unless they're relying on the thinnest of obfuscation. And the whole point is that a user using a "bot" should be given the same consideration as a user using a proprietary front end - services should police user behavior rather than being lazy with method of access.
> It's be much easier to kill their web app and tell everyone to use a mobile app instead.
Except most "apps" are also just proprietary front ends to services hosted elsewhere, and thus run afoul of the same bundling.
> I wouldn't be so sure. This whole industry works on having defaults that most people just accept. It's quite easy to set up an ad blocker, and yet most people just don't.
That's totally possible, I just expect the regulation would kill many services unless the regulation is either full of loop holes or uninforced (or both)
> This is the standard FUD about anything that's "different" or creates a modicum of requirements on companies. They're already publishing APIs for the proprietary apps to use.
That isn't FUD, requiring API access absolutely adds to business costs and overhead. You need to document the API, test it, security audit it, etc. Sure these should be done already but they rarely are. I've seen plenty of companies that largely ignore these tasks when it's an internal API onyl, believing that shipping fast is more important and the obscurity of an undocumented API is itself a layer of security.
I'd be extremely impressed to find literally any company with an internal-only API that is proepryl tested, documented, and audited. I'd be even more impressed if they worried too much about versioning and backwards compatibility beyond the scope of what it takes to update their own consuming code.
There are still huge gray areas to define in anything similar to your proposal, writing laws with loose definitions and purposely building in unanswered questions is worse than having no laws at all.
Is the legal requirement only related to the API surface available? Can I rate limit all unique users, even to say one request per hour, day, or year? Can I code my API in any way I deem fit, like a Soap API or one with an obfuscated API surface that runs through a random RPC protocol? Do I have to follow semantic versioning or similar?
Regulations can't just be thrown together on a whim. That's how we end up with confusing laws and overpaid lawyers trying to game the system in favor of the person with more money. Laws should always be clear on what is being deemed illegal, why, and what the punishment is.
That's totally possible, I just expect the regulation would kill many services unless the regulation is either full of loop holes or uninforced (or both)
> This is the standard FUD about anything that's "different" or creates a modicum of requirements on companies. They're already publishing APIs for the proprietary apps to use.
That isn't FUD, requiring API access absolutely adds to business costs and overhead. You need to document the API, test it, security audit it, etc. Sure these should be done already but they rarely are. I've seen plenty of companies that largely ignore these tasks when it's an internal API onyl, believing that shipping fast is more important and the obscurity of an undocumented API is itself a layer of security.
I'd be extremely impressed to find literally any company with an internal-only API that is proepryl tested, documented, and audited. I'd be even more impressed if they worried too much about versioning and backwards compatibility beyond the scope of what it takes to update their own consuming code.
There are still huge gray areas to define in anything similar to your proposal, writing laws with loose definitions and purposely building in unanswered questions is worse than having no laws at all.
Is the legal requirement only related to the API surface available? Can I rate limit all unique users, even to say one request per hour, day, or year? Can I code my API in any way I deem fit, like a Soap API or one with an obfuscated API surface that runs through a random RPC protocol? Do I have to follow semantic versioning or similar?
Regulations can't just be thrown together on a whim. That's how we end up with confusing laws and overpaid lawyers trying to game the system in favor of the person with more money. Laws should always be clear on what is being deemed illegal, why, and what the punishment is.
> Is the legal requirement only related to the API surface available? Can I rate limit all unique users, even to say one request per hour, day, or year? Can I code my API in any way I deem fit, like a Soap API or one with an obfuscated API surface that runs through a random RPC protocol? Do I have to follow semantic versioning or similar?
Sorry, but these "questions" are still just FUD.
First, an HN comment is not expected to be a fleshed out legislative proposal, nor is HN a place for fleshing out legislative proposals. So demanding that I readily come up with some perfect implementation details right here isn't good faith discussion, but rather derailing by implying that any law would have to specify a technical implementation (which would indeed be ridiculous). In reality, these details are determined through judgements by the courts, which rubs us software people the wrong way, but does make the problem tractable.
But really the crux of my original comment, which you brushed right past, is that this bundling seems straightforward afoul of the basic concepts of anti-trust. If existing laws do not suffice, a new law still doesn't actually need to specify how exactly something must be made available to the wider market, only that it is. So all of the technical details fall away - whatever technical arrangements a company uses to make its publishing service available to its own in-house app, need to be made available to the wider market. Likely whatever modern web technology they're already using. If that's SOAP then it's SOAP. If that's a bespoke protocol running on bare IP, then so be it.
And if companies attempt to implement this in bad faith and continue colluding between what should be two separate business units, then they should be split up into independent entities.
Sorry, but these "questions" are still just FUD.
First, an HN comment is not expected to be a fleshed out legislative proposal, nor is HN a place for fleshing out legislative proposals. So demanding that I readily come up with some perfect implementation details right here isn't good faith discussion, but rather derailing by implying that any law would have to specify a technical implementation (which would indeed be ridiculous). In reality, these details are determined through judgements by the courts, which rubs us software people the wrong way, but does make the problem tractable.
But really the crux of my original comment, which you brushed right past, is that this bundling seems straightforward afoul of the basic concepts of anti-trust. If existing laws do not suffice, a new law still doesn't actually need to specify how exactly something must be made available to the wider market, only that it is. So all of the technical details fall away - whatever technical arrangements a company uses to make its publishing service available to its own in-house app, need to be made available to the wider market. Likely whatever modern web technology they're already using. If that's SOAP then it's SOAP. If that's a bespoke protocol running on bare IP, then so be it.
And if companies attempt to implement this in bad faith and continue colluding between what should be two separate business units, then they should be split up into independent entities.
Regulations? Legislation? None of that means anything in this age of "it's only wrong/illegal if you get caught". What's needed is to kick these shitty anti-user services to the curb, and switch wholesale to ones that actually care about user agency, security, and privacy.
I agree with where you're coming from with the approach of users needing to kick shitty anti-user services to the curb. But I'd say why not both? It doesn't need to be an either-or.
Legislation sets normative behavior, even if it is not enforced fully or companies find loopholes. It is simply not right for a free society to have surveillance databases that would make the most staunch Stasi agent blush, and we should work towards the goal of ending them by every avenue possible.
Also how do you propose to kick say Equifax to the curb through individual action? There are many services that don't exist via user consent or interaction, but rather just by purported assent through contracts of adhesion from some de facto mandatory industry.
Legislation sets normative behavior, even if it is not enforced fully or companies find loopholes. It is simply not right for a free society to have surveillance databases that would make the most staunch Stasi agent blush, and we should work towards the goal of ending them by every avenue possible.
Also how do you propose to kick say Equifax to the curb through individual action? There are many services that don't exist via user consent or interaction, but rather just by purported assent through contracts of adhesion from some de facto mandatory industry.
I alluded to this on Mastodon recently [1], and I strongly agree. Here's a copy of the toots:
---
Thought that just crossed my mind: what if - a law that mandated any service accessed over the web must not interfere with any attempts to develop or use third party clients?
Not a software license. A law, with actual teeth and massive fines for companies (it's always companies) violating it.
Discord banning folks for using Ripcord? Yeah that'll be $(insert massive fine here) per user banned. Your credit union? Sure, write your own mobile app for it.
Like GDPR, but a hundred steps further.
To give it proper teeth, the fines for willful infringement should be basically company-ending events, because fuck abusing users. No $1000 slap on the wrist. Nah, "up to 5% of company net profit for the year of occurrence, or $X minimum amount, whichever is higher" (to handle unprofitable VC-backed entities) or something truly fear-inducing.
And no, I can't currently think of anything that should be excepted from this. If you think you can write a better GUI for the SaaS version of TurboTax and not land yourself with tax fines, go for it, dude. The law should allow you to do that, too.
[1]: https://merveilles.town/@klardotsh/110749363058611919
---
Thought that just crossed my mind: what if - a law that mandated any service accessed over the web must not interfere with any attempts to develop or use third party clients?
Not a software license. A law, with actual teeth and massive fines for companies (it's always companies) violating it.
Discord banning folks for using Ripcord? Yeah that'll be $(insert massive fine here) per user banned. Your credit union? Sure, write your own mobile app for it.
Like GDPR, but a hundred steps further.
To give it proper teeth, the fines for willful infringement should be basically company-ending events, because fuck abusing users. No $1000 slap on the wrist. Nah, "up to 5% of company net profit for the year of occurrence, or $X minimum amount, whichever is higher" (to handle unprofitable VC-backed entities) or something truly fear-inducing.
And no, I can't currently think of anything that should be excepted from this. If you think you can write a better GUI for the SaaS version of TurboTax and not land yourself with tax fines, go for it, dude. The law should allow you to do that, too.
[1]: https://merveilles.town/@klardotsh/110749363058611919
>And no, I can’t currently think of anything that should be excerpted by this
You’d make it illegal to take active action against Phishing? That’s uh… bold…
You’d make it illegal to take active action against Phishing? That’s uh… bold…
I'm open to hearing examples of effective phishing prevention that cannot be replicated with open APIs like this proposal - or even the counterexample, phishing attempts that rely on freedom of client choice to do.
I said "currently" - this means I'm open to hearing worthwhile exceptions, but I do want to have a chance to think about those exceptions and think of how companies would abuse them to in turn abuse their users, too.
I said "currently" - this means I'm open to hearing worthwhile exceptions, but I do want to have a chance to think about those exceptions and think of how companies would abuse them to in turn abuse their users, too.
Exports only help if new services support imports.
And some of those wouldn't be particularly helpful; @tags would lose a lot of meaning as you migrate, especially if others on the destination platform already have that handle.
And some of those wouldn't be particularly helpful; @tags would lose a lot of meaning as you migrate, especially if others on the destination platform already have that handle.
>Exports only help if new services support imports.
Of course I can understand why a service wouldn't want you to be able to post thousands of posts in a matter of minutes, or to fake timestamps, or...
The whole idea of massively importing stuff is complete nonsense.
Of course I can understand why a service wouldn't want you to be able to post thousands of posts in a matter of minutes, or to fake timestamps, or...
The whole idea of massively importing stuff is complete nonsense.
Fair-ish. Certainly some types of services have an incentive to allow you to import, as a way of making it easier to move to them. Like an email hosting service would want to make it easy for you to move your old emails to them when switching.
I could understand why a Twitter alternative might not want you to be able to import a ton of old posts at once. But this is why we need open standards and open source. Some random large Mastodon instance might not want to allow imports, but you should at the very least have the option to spin up your own instance, import all your old Twitter posts, and still participate in the ecosystem.
As others have pointed out, an @tag can still be useful by linking back to the original service. Or the importer can support a username mapping so it can rewrite names from the old service to names to the new service. Sure, all of this requires extra work, but it can be possible if people care enough.
Regardless, export functionality at the old service is the first necessary step. Even if there's no import on the other side now, someone might build one eventually. And even if that never happens, being able to archive your old data is useful by itself.
I could understand why a Twitter alternative might not want you to be able to import a ton of old posts at once. But this is why we need open standards and open source. Some random large Mastodon instance might not want to allow imports, but you should at the very least have the option to spin up your own instance, import all your old Twitter posts, and still participate in the ecosystem.
As others have pointed out, an @tag can still be useful by linking back to the original service. Or the importer can support a username mapping so it can rewrite names from the old service to names to the new service. Sure, all of this requires extra work, but it can be possible if people care enough.
Regardless, export functionality at the old service is the first necessary step. Even if there's no import on the other side now, someone might build one eventually. And even if that never happens, being able to archive your old data is useful by itself.
@tags are just one of many features, and the lack of a matching user on the import side isn't a critical issue: a link back to the original post instead suffices.
And regardless, Twitter-alikes aren't the only thing worth considering. Exporting all of one's video data from YouTube, or all of one's comments from Reddit, or all of one's search history (and Google Voice texts, and Docs documents, and etc.) from Google are all usecases that fall under these data moats that are useful to be able to take with you and move to another service. There's probably more usecases I'm not even thinking of, but the point is that by exposing all the data by mandate, we don't have to be limited by the imagination of today, we have the data, we can build whatever future frontends and replacement services and etc. we want.
And regardless, Twitter-alikes aren't the only thing worth considering. Exporting all of one's video data from YouTube, or all of one's comments from Reddit, or all of one's search history (and Google Voice texts, and Docs documents, and etc.) from Google are all usecases that fall under these data moats that are useful to be able to take with you and move to another service. There's probably more usecases I'm not even thinking of, but the point is that by exposing all the data by mandate, we don't have to be limited by the imagination of today, we have the data, we can build whatever future frontends and replacement services and etc. we want.
To be fair, Google is one of the few services that best support taking your data away by using their "Google Takeout" tool. YouTube videos, Photos, whatever, downloaded from a single website in ZIPs, TARs or whatever.
Microsoft doesn't have such tool for OneDrive, Outlook or their services in general, so downloading 1D docs means going to the website, selecting then and pressing "download". For Outlook emails... well, good luck
Microsoft doesn't have such tool for OneDrive, Outlook or their services in general, so downloading 1D docs means going to the website, selecting then and pressing "download". For Outlook emails... well, good luck
Yet even Google itself lacks import capabilities, even for the very portable export formats they generate. And this is understandable, because en masse imports are undoubtedly a security issue.
As for OneDrive and Outlook exports, if only there were a way to synchronize data to a client. Oh well.
As for OneDrive and Outlook exports, if only there were a way to synchronize data to a client. Oh well.
> Yet even Google itself lacks import capabilities, even for the very portable export formats they generate. And this is understandable, because en masse imports are undoubtedly a security issue.
Depends... Under their POV, why would anyone want to import stuff to a Google account en masse if they already have it on their "original" acc?
> As for OneDrive and Outlook exports, if only there were a way to synchronize data to a client. Oh well.
There are OneDrive clients for Windows, Android (and I guess Apple systems too), but it's still less convenient than downloading a single ZIP. Using the official client means I need to copy the stuff to my local drive first, and then compress it if I want to store it in a more efficient way.
Depends... Under their POV, why would anyone want to import stuff to a Google account en masse if they already have it on their "original" acc?
> As for OneDrive and Outlook exports, if only there were a way to synchronize data to a client. Oh well.
There are OneDrive clients for Windows, Android (and I guess Apple systems too), but it's still less convenient than downloading a single ZIP. Using the official client means I need to copy the stuff to my local drive first, and then compress it if I want to store it in a more efficient way.
> why would anyone want to import stuff to a Google account
I have 3 personal Google accounts, and that doesn't count my work and school Google accounts. It is conceivable that I'd want to move at least a few things around among them.
Also, it is conceivable that someone could write up a utility that prepped arbitrary types of data for import into an arbitrary Google property. Whether it's JSON or XML or whatever, I could see there being use cases for importing data that has not yet been in a Google account at all.
I have 3 personal Google accounts, and that doesn't count my work and school Google accounts. It is conceivable that I'd want to move at least a few things around among them.
Also, it is conceivable that someone could write up a utility that prepped arbitrary types of data for import into an arbitrary Google property. Whether it's JSON or XML or whatever, I could see there being use cases for importing data that has not yet been in a Google account at all.
> Google is one of the few services that best support taking your data away by using their "Google Takeout" tool. YouTube videos, Photos, whatever, downloaded from a single website in ZIPs, TARs or whatever.
Agreed. The bigger issue is relying on a broadcast-esque provider as your sole storer of video. If your account gets blocked somehow (or locked out) then you're done for. Have a separate, storage-only video account and push to YouTube as well.
Agreed. The bigger issue is relying on a broadcast-esque provider as your sole storer of video. If your account gets blocked somehow (or locked out) then you're done for. Have a separate, storage-only video account and push to YouTube as well.
Yeah, I mean, you should totally store your videos somewhere that can't lock you out for no reason. Whether that is a hard drive, an S3 glacier bucket (which I believe must give you at least 24 hours warning before they can cut you off) or anything else, you should keep a copy that you and only you control, instead of being at Google's mercy.
Exports help always. Someone in the future could write a tool. Someone can finance writing a tool. AI could be used to create a tool.
[deleted]
> Data moats must end, or we'll be doing this same stupid dance every few years when the next MySpaceBookTokDit enshittifies and takes everyone's social data with it.
Data moats haven't been a thing since GDPR passed and everyone implemented "data dump" features as a result.
The real problem is the lack of federation requirement. Say I'm a competitor to Facebook - what use has a potential customer of mine from an import feature when there is no way for my service to interface with the customer's Facebook friends?
Data moats haven't been a thing since GDPR passed and everyone implemented "data dump" features as a result.
The real problem is the lack of federation requirement. Say I'm a competitor to Facebook - what use has a potential customer of mine from an import feature when there is no way for my service to interface with the customer's Facebook friends?
The GDPR data dump requirement is pretty lame: the user can’t specify a format, so a PDF scan of a printout of your data would qualify as a “data export”, even though it’s basically useless.
It also only technically protects EU citizens/residents. Some companies extended that infrastructure to US folks willingly, but certainly not all.
I think California has a similar requirement under the CCPA
EU courts generally don't just take the letter of the law but also its spirit into account.
[deleted]
data should be stored locally in the first place.
The recent WEI (aka user-agent discrimination) proposal might be the end-game of all this.
We shouldn't give up, but keep fighting to be able to use services with the software and hardware we choose. The whole "API" concept has always seemed like a power-grab since it was introduced.
We shouldn't give up, but keep fighting to be able to use services with the software and hardware we choose. The whole "API" concept has always seemed like a power-grab since it was introduced.
> The whole "API" concept has always seemed like a power-grab since it was introduced
What do you mean? Do you mean a public, free API offered by these services?
What do you mean? Do you mean a public, free API offered by these services?
I mean the idea of promoting a separate "API" that you need to specifically request access to ("API keys") and possibly agree to other conditions, just to get the same information you'd already be able to with the "normal" way using a browser, but in a possibly slightly easier to parse format.
That's why I like to say that all sites already have an API: HTTP + HTML.
That's why I like to say that all sites already have an API: HTTP + HTML.
yep. people seem to forget that the whole API key is a recent invention. for many years you could just access many APIs anonymously. this should still be possible. if abuse is an issue, all they need to do is set rate limits for anonymous access. GitHub does this, and even Instagram.
the only point of an API key is to extract information from API users that would otherwise be anonymous.
the only point of an API key is to extract information from API users that would otherwise be anonymous.
[deleted]
Data is the life blood of AI algorithms. Hence the effort by Big Tech to silo their mega-platforms & impose WEI upon browsers so only their crawlers are able to scrap whatever data remains outside the silos. Its a race to the bottom and individual & smaller players are going to get crushed even before they can start.
While I wouldn't be surprised if it died soon, my personal Libreddit instance remains running perfectly fine, although it has a user count of one.
Teddit, my preferred Reddit frontend, still manages to have an updated frontpage, but clicking on anything gives HTTP 429 for several weeks now (I think, only use it intermittently).
If the frontends quit working though, I just won't go to those websites anymore.
If the frontends quit working though, I just won't go to those websites anymore.
you can go to one of the many other instances running the teddit code
go to this link (at bottom of main teddit.net page)
https://codeberg.org/teddit/teddit
and look under "instances"
just replace "reddit.com" with the instance name in your reddit url
I actually have a bookmark that does it automatically when I click on it.
javascript: (location.hostname="teddit.net")
or whatever instance you want
go to this link (at bottom of main teddit.net page)
https://codeberg.org/teddit/teddit
and look under "instances"
just replace "reddit.com" with the instance name in your reddit url
I actually have a bookmark that does it automatically when I click on it.
javascript: (location.hostname="teddit.net")
or whatever instance you want
I believe it's the same for Libreddit.
I think HN took the site down? While i understand the pain, i think a little bit of a surge shouldnt be able to take down a public instance host. Another reason, perhaps?
The web is slowly being killed. The culprit? Capitalism.
Sorry, not sorry. Use Gemini, search with Marginalia, socialise with real people and reach your communities with email.
Sorry, not sorry. Use Gemini, search with Marginalia, socialise with real people and reach your communities with email.
> socialise with real people
I have some real-life, non-internet-based hobbies for which I come together with other people. All the rest of those people frequently talk about social media, online influencers, DRM-controlled streaming, and WhatsApp groups, and I’m the weirdo because I don’t follow any of that. In fact, it is socializing with real people that convinces me that the world will just go along with tech companies’ nefarious plans, and ultimately it may no longer be very feasible for us nerds to just drop out.
I have some real-life, non-internet-based hobbies for which I come together with other people. All the rest of those people frequently talk about social media, online influencers, DRM-controlled streaming, and WhatsApp groups, and I’m the weirdo because I don’t follow any of that. In fact, it is socializing with real people that convinces me that the world will just go along with tech companies’ nefarious plans, and ultimately it may no longer be very feasible for us nerds to just drop out.
My real friends use group text. Nothing fancy. Real names. Real numbers. No data collection. No cost.
Memes flow. Links get posted.
All is just a setup for the next IRL meeting.
I found the end of the internet in '99.
This is the last few sites that have a low bot ratio.
Memes flow. Links get posted.
All is just a setup for the next IRL meeting.
I found the end of the internet in '99.
This is the last few sites that have a low bot ratio.
> [...] and reach your communities with email.
"office hours" / calls with random people where they can ask for advice, talk about their ideas (or just rant!) worked pretty well for me: https://sonnet.io/posts/hi
"office hours" / calls with random people where they can ask for advice, talk about their ideas (or just rant!) worked pretty well for me: https://sonnet.io/posts/hi
This is fantastic and I may just take you up on it if you're still doing it!
yeah, I've spoken to +100 people so far this way. Come and say hi! :)
Ayo I just recently started using the tux.pizza Nitter instance as my main
It's not just a privacy frontend. You're accessing content and services without helping the freely provided stuff be monetized. I get that you want to protect your identity. Then don't use these services or data. It's not public and not free - nor should it be.
Privacy is not piracy. This is piracy.
Privacy is not piracy. This is piracy.
"Piracy" is a bit of a strong denouncement. If someone puts something on the internet, and their server responds to your request for data with... y'know... the data, then the you can display that data however you want.
Certainly the server owners can try to do tricky things to make it so you can only display the data in ways they want you to display it, but there's no natural right that makes it morally or ethically wrong for you to display things how you want.
Certainly the server owners can try to do tricky things to make it so you can only display the data in ways they want you to display it, but there's no natural right that makes it morally or ethically wrong for you to display things how you want.
RSS by its very nature is designed to not be restricted to the "way of presentation and ad earning of the producer".
Producer produces content and RSS syndicates it that can be read by clients IN WHATEVER MANNER OR FORM THEY DESIRE.
That's the whole idea of internet. Now, you go ahead and lament how this is piracy. Its not. YouTube provides RSS feeds. Same do other platforms so as long as they do, we can do whatever the hell we want with the feed
Producer produces content and RSS syndicates it that can be read by clients IN WHATEVER MANNER OR FORM THEY DESIRE.
That's the whole idea of internet. Now, you go ahead and lament how this is piracy. Its not. YouTube provides RSS feeds. Same do other platforms so as long as they do, we can do whatever the hell we want with the feed
The article highlights several front ends most of which do not rely on the official RSS feeds provided by the service.
So if they only use RSS would you be fine with sponsor block and ad striping and proxy frontends and downloads and not paying?
>That's the whole idea of internet.
No, the idea of the internet is to create a global scale network of computers.
>YouTube provides RSS feeds.
Which links you to a webpage that includes ads to monetize the video, the RSS feed, and the rest of the site.
No, the idea of the internet is to create a global scale network of computers.
>YouTube provides RSS feeds.
Which links you to a webpage that includes ads to monetize the video, the RSS feed, and the rest of the site.
But that's only if the producer wants to provide an RSS feed. While annoying, it's perfectly within their rights not to provide one.
> That's the whole idea of internet.
I think it's very hard to assert that anything is "the whole idea of the internet". If you want to go back to its roots, the "whole idea of the internet" was to have a reliable military/government communications system in the case of nuclear war.
These days the internet means different things for different people, and no one person can credibly assert that any particular purpose is valid or invalid.
> That's the whole idea of internet.
I think it's very hard to assert that anything is "the whole idea of the internet". If you want to go back to its roots, the "whole idea of the internet" was to have a reliable military/government communications system in the case of nuclear war.
These days the internet means different things for different people, and no one person can credibly assert that any particular purpose is valid or invalid.
They surely meant the "world wide web", which is often used interchangably, and (to some) incorrectly, with "internet"?
Seeing as how this is hurting usage to the point that monetization is hurt, maybe they should actually just let the privacy-concious users be...
Surveillance capitalism is one of the most immoral things I can think of. Privacy and piracy are not only ethical but necessary
No it is not.
Migrating to services where the data is free and not captive was always the only long-term solution.
Next up: rather than inventing technical solutions to work around walled gardens, we need serious legislative efforts to mandate data freedom. It should be possible to export 100% of one's data stored in a service like Twitter or Reddit in a reasonably-parseable format (a tarball of JSON as one possible example, or maybe a SQLite database, or whatever is appropriate) and import it to a new service. Data moats must end, or we'll be doing this same stupid dance every few years when the next MySpaceBookTokDit enshittifies and takes everyone's social data with it.