If you browse with #JavaScript disabled, you'll want to CTRL-U to view source. The article starts at line 377 and ends at line 426 (out of 798).
It should make one wonder what evil intentions are behind hiding the text unless #JabbaShit is enabled. This is true on any site, but a domain like "Malware Tech" should pay special attention to this idea. It's probably a decent site with no ill intentions, but what they're doing is shady and questionable at best.
I remember using 3rd party clients to access #Twitter. There was the commandline #TTYtter, the #Flock browser's built-in social client, and many others.
As Twitter added ads andspewed tons of #JavaScript, leading to a "jumping and twitching" interface that would move underneath your mouse pointer and cause mis-clicks, and as it took 5-10 minutes after logging in for the page to fully load, it was clients that made the site tolerable.
There was the "OAuth-pocalypse", when they required all clients to use OAuth (v2?) and it intermittently failed for a few weeks.
Then came the day when clients and other API uses "that substantially reproduce" the Twitter UI were notified that their days were numbered. I remember @evan telling them that Identica and other StatusNet instances had a similar API ... but few, if any, clients came over. Most just shut down.
Hilariously, there was a trivially reproducible social ranking thing that was cited as an example of the kind of API uses Twitter considered interesting and allowable.
There were other, lesser bumps in the road, but as Twitter had already strangled most of its client ecosystem, I did not pay attention.
@fu I have definitely noticed that when I use the phone's hotspot, the Friendica UI on Libranet doesn't work correctly and takes forever to load anything. I would say the real issues are (1) too much #JavaScript instead of native HTML + CSS (2) infinite scroll instead of pagination. The combination makes every page load into a [b]REALLY[/b] big download.
Tagging this thread with #Fediverse #Security ... whomever made the script obviously read some protocol docs and some source code. With just a little #JavaScript, they were able to knock some #Misskey and #Mastodon instances to their knees.
This isn't the first, and it won't be the last. Remember when someone posted a humongous image and locked up any #GNUSocial instance that tried to download the image? Remember when someone's instance was replaced by some sort of cryptocurrency site and PuSH es from your site to theirs would crash your site because of their site's response? (I'll bet I still have that domain blocked at the firewall.)
We have to stop being naive about the intentions of those in the current migration. The overwhelming majority will have benign, if not good, intentions. But a select few will have bad intentions. Among those intentions is to colonize the Fediverse with #Twitter's culture, to come here and impose that culture of anger and disrespect upon the inhabitants here ... which already happened once with the first wave of people joining #Mastodon instance, except it was Twitter and #Tumblr at that time.
At the time, he was making $100,000+ and taking time off whenever he wanted. I think he made a lot more during the fixes that prevented #Y2K from becoming the expected meltdown, but he then ran into headwinds because foreign programmers were being imported to do the work for a lot less than what he was accustomed to earning, so he retired.
I thought about this back when the lockdowns geared up and state governors were crying about lacking the COBOL programmers to fix their unemployment insurance systems.
I bought tickets to a !baseball game. The process is unpleasant. If I wasn't already committed to go, I would not have gone through it.
1. Visit MLB.com on the (older) tablet and click on the team, then on tickets. 2. Oops! Their 3rd party processor does not like your #VPN. You're going to have to enter sensitive financial data across #hotel_Wi-Fi. I know that we're using HTTPS, so there's already encryption from me to mpv\.tickets\.com. Okay, I'll risk it. 3. Okay, pick a game that you want to buy tickets for. Wait up to 4 minutes for the #JavaScript to load and the page to stop jumping around. Now slide the price slider, so you can look at tickets at prices you are willing to pay. Wait for the JS again. 4. Now you're supposed to choose your seat by which section it is in, so you try to expand the map to see where each section is. The map seems unresponsive, but after 3-4 minutes, it will suddenly start moving. Okay click the back button and do it again. 5. Click 'buy now'. Wait 3-4 minutes and the 'create an mlb.com account' page opens. Account creation is followed by adding a credit card (or Google Pay) to your account. 6. You only had 9 minutes to complete the purchase before the tickets go back in the pool. Let's use the laptop instead. And the hotel log in page takes almost 15 minutes to go through tonight. (Once you get in, you've got 10Mbps up and the same amount down.) 7. Log in to mlb\.com, go back to the ticket buying site. This time, you're able to complete the purchase in a few minutes. Thanks to excessive #JabbaShit, the page is still twitchy. But you got it done anyway. 8. When you get to the field, you'll need to use the MLB app on your phone in order to present a bar code for entry. No Google account? You can't install the app.
Case in point, in any of the #Chromium based browsers, you can turn #JavaScript totally on or totally off. There is no option to turn it off for 3rd party domains.
So many sites are #JavaScrippled these days that turning JS all the way off (without a one-click way to turn it on for one site) is too frustrating for anyone to do.
I did see in #Edge today that I can add sites individually to either a separate Yes to JS or No to JS list. I don't recall seeing it until recently. But that's cumbersome.
lnxw48a1 (lnxw48a1@nu.federati.net)'s status on Tuesday, 01-Feb-2022 23:39:01 EST
lnxw48a1Apparently, Linus Sebastian (of "Linus Tech Tips") said that ad-blocking is basically piracy. But given the intrusive, invasive, interruptive nature of many ads and the extreme data-collection that accompanies them, ad-blocking is the only sensible and sane choice. It is okay to choose a small number of trusted sites and unblock for them--if you choose to do so--but in general, ads should be blocked.
The #JavaScript used to serve ads has been hijacked on occasion to install malware, in addition to its role in the data collection and spying that advertising networks do.
But as for the moral argument he's reaching for: * the site is paid by the ad vendor * the ad vendor is paid by the advertiser * therefore, the site visitor has no obligation to allow or view ads on the site. If that affects the site's revenue so deeply that it is no longer worthwhile to run the site & produce the content that the site displays, then someone should be looking at alternate revenue sources (e.g., offer t-shirts and mugs with the site's name and logo * the site visitor and site owner / administrator have no agreement express or implied which requires the allowance and viewing of advertisements
There’s no question that PoW mining uses a lot of power. But so does Facebook and so does gratuitous #JavaScript on web pages. No one is suggesting that we forbid or boycott Facebook or JavaScrippled web pages over their expected climate impacts.
Link seen because @moon@shitposter.club repeated someone's post.
I refused to turn on #JavaScript, so I can't see most of the content, but I think this is a really bad idea. I'm not anti-cryptocurrency (as I think of it as one possible way to prevent bankers' tyranny over us), but whatever one thinks about RadioShack / Radio Shack, I don't think attaching a different product or service to the name makes any sense.
Too many people still remember going into thir stores and buying computers and somewhat outdated stereo systems, so the new owner's product or service _is_ going to clash in their minds.
after a nuclear war, the remaining people will probably not be able to spin up a modern operating system on their improvised chips. How do you build a simple, reliable, legacy-free OS from scratch? What ideas 💡 and techniques should be passed down to those people?
If we think hard enough about this, I think we’ll agree that closed-source systems are basically designed to be almost impossible for people outside the sponsoring organization to reproduce (for an example, consider [ReactOS](https://reactos.org/), which launched as [a project to produce a system compatible with Windows 95](https://reactos.org/wiki/FreeWin95) and [then changed to focus on Windows NT](https://reactos.org/wiki/ReactOS/History), and after more than 25 years, is still not capable of being a daily use system.
But we may also determine that most open-source systems are likewise not designed in such a way that reconstruction is viable. The Linux kernel is *huge* these days.
Additionally, in my opinion, they’d probably want to use programming languages designed for readability, ease of learning, and error-reduction first (that is, more like #COBOL than #C, more like #Java than #CPlusPlus, more like !Smalltalk and #Lisp / #Scheme than #Perl / #Raku and #JavaScript) and then performance and low-level access.
I think it is a mistake to assume that one could start with a modern version of #gcc or #llvm or #msvc … because it is not a given that the software itself and someone who knew how to use it (and update, modify, and adapt it) would still exist.
I did not anticipate this, because I figured they’d have learned from Lavabit and designed their systems such that there was no way for them to have any metadata (user’s IP address, user’s ‘user agent’, timestamps of users’ correspondence, pretty much everything except what is required to send and receive messages). Any information your system has, however briefly, can be the subject of a government order.
My issue over the years has been that both Protonmail and Tutunota send you the JavaScript used to “end-to-end encrypt” your message. At any time, they could be ordered to modify that JS to cache the encryption keys for later reuse by government agencies.