/tech/ - Technology

Buffer overflow

Posting mode: Reply

Check to confirm you're not a robot
Name
Email
Subject
Comment
Password
Drawing x size canvas
File(s)

Remember to follow the rules

Max file size: 350.00 MB

Max files: 5

Max message length: 4096

Manage Board | Moderate Thread

Return | Catalog | Bottom

Expand All Images


(20.69 KB 541x167 my2020census.jpg)
I Don't Run Javascript Anonymous 03/20/2020 (Fri) 19:21:36 [Preview] No. 14056
Instead of going out of the way and making extra unnecessary effort to write a garbage fail web site, why not stick with standard HTML forms and POST and always Just Work on any fucking browser made in the last 20 years?


Anonymous 03/20/2020 (Fri) 21:12:42 [Preview] No.14057 del
Because the web has evolved over the last 20 years and most sites that actually serve an important purpose require JavaScript to do anything remotely interesting.


Anonymous 03/20/2020 (Fri) 21:31:08 [Preview] No.14058 del
>require JavaScript to do anything remotely interesting

Except that the vast majority of web sites that "require" it don't actually need it for anything. They could easily do exactly what they're doing using nothing but HTML and POST.

This is the problem with the current generation of shitty programmers. They think that you have to use WYSIWYG HTML generators and massive Javascript libraries that pull shit from six different servers and serve no less than a megabyte per GET to paint a field and receive a response.

Very little of the web has "evolved." In many cases, what it has done is gotten fat, inefficient, unreliable, and broken. If the first thing someone thinks about is what javascript library they should use to do something, they should just stop and not inflict their idiocy on the web any more.


Anonymous 03/20/2020 (Fri) 22:24:10 [Preview] No.14059 del
Okay, so then how does one create some complicated website without using JavaScript of any kind? What would the web look like if everyone kept using the standard stuff? It'd look like shit and we wouldn't have the services that we know today.

Also UI/UX is a thing, shit needs to be easy to use so that any retard can use your service. Innovation! If you own a business right now and your site looks like it hasn't been changed since 2002, would you leave a good impression?

Can we solely use HTML and POST? I agree on the fact that JS sucks but we're dependent on the damn thing. In fact, Twitter was pretty good when it was using non-proprietary JS for a good period of time.

>Very little of the web has "evolved."
Honestly, what part of the web hasn't evolved? I can sit on my lazy ass, order and pay for a pizza online and have it delivered to my house within an hour without having to stand up once. And I can thank JS for that.

I see what you mean, we should refrain from using JS as much as possible, but what can we do if we have to make complicated shit?


Anonymous 03/21/2020 (Sat) 07:13:22 [Preview] No.14060 del
I already told you: standard HTML and HTTP POST. If you are desperate to make the web site look like you got a venture capitalist to spend a million dollars on it, then add some CSS and some img tags and go ahead and charge them $5000 an hour for it.

The actual functionality of pretty much any web site you care to name - amazon, ebay, itunes, certainly ANY site you would order a pizza from, go ahead and name a site that you consider too complicated to implement without javascript and I will describe to you how to implement it without javascript - can be handled with tables, the form tag, and the submit tag. If you want to display a big graphic and have different things happen depending on where someone clicks on the graphic, use HTML image maps and the aforementioned standard HTML forms.

It's like the old saw about how when someone learns how to hammer, everything becomes a nail. Javascript is used for even the most rudimentary things where it wasn't needed at all. It certainly isn't needed by anything the us census site is doing.


Anonymous 04/12/2020 (Sun) 00:34:09 [Preview] No.14074 del
(17.10 KB 1024x768 out.png)
I guess netsurf-fb supports JS, but nahhhh fuck that. I'm staying with plain html.


Anonymous 04/12/2020 (Sun) 06:54:16 [Preview] No.14075 del
Nothing good ever came out of JavaScript.

Anon defending it in this thread is confusing form and function.
JavaScript does nothing to improve function, much less form.

JavaScript is the beaurocracy of technology - it exists on a myth that it is needed; it is busywork invented in order to employ unnecessary people.

And the only monetary gain in JavaScript is to offload server costs to the user as the code is executing on their machine (read: their electricity bill).

A couple of years ago there was talk of Bitcoin wasting electricity - makes you think - exactly how much electricity does JavaScript waste on a global scale?


Anonymous 04/13/2020 (Mon) 23:28:32 [Preview] No.14085 del
>>14059
E-commerce have been a thing way before JS nigger


Anonymous 04/13/2020 (Mon) 23:31:05 [Preview] No.14086 del
>>14060
I think the only website that I use which requires JS is Google maps.


Anonymous 04/23/2020 (Thu) 02:44:14 [Preview] No.14101 del
>>14075
Will JS ever go away then? Any way to convince people not to use it?


Anonymous 04/23/2020 (Thu) 20:46:48 [Preview] No.14105 del
>>14101
JS isn't the problem, shitty programmers/dataminers/designers are. Websites like Youtube or Twitter that are 100% javascript end up being extremely buggy and slow as fuck for absolutely no reason whatsoever. These massive corporations have no fucking reason to not be able to afford teams of competent designers to do it the proper way instead of exporting work to 3rd world teams that are a dime a dozen.


Anonymous 04/24/2020 (Fri) 00:49:02 [Preview] No.14106 del
(60.84 KB 736x736 1244915770142.png)
>>14105
>These massive corporations have no fucking reason to not be able to afford teams of competent designers to do it the proper way instead of exporting work to 3rd world teams that are a dime a dozen.

You buy cheap, you get cheap I suppose. We end up paying for it with awful user experiences though. Companies have been outsourcing since the 90s and I don't see them stopping anytime soon


Anonymous 05/02/2020 (Sat) 13:40:45 [Preview] No.14112 del
>>14105
the problem is that it's possible
web browser shouldnt have 9000 extensions which only exist for malware and rendering complex magazine articles
you fucking luser scum


Anonymous 05/02/2020 (Sat) 13:56:31 [Preview] No.14120 del
Auto updating of pages is a javascript thing right? If so that is why its useful imo.


Anonymous 05/02/2020 (Sat) 14:05:19 [Preview] No.14121 del
>>14120
no shit you fucking retard. too bad it doesnt make up for the fact that once you enable anyone to run arbitrary code on your computer, it's gonna be shit the moment you have more than 3 pages open


Anonymous 05/03/2020 (Sun) 02:24:27 [Preview] No.14123 del
>>14120
>Auto updating of pages is a javascript thing right?

Nope. HTML meta refresh tag.

Thanks for another example of needlessly reaching for javascript (which would make a page that won't refresh without it) when there's a better and simpler way to do exactly the same thing that would always Just Work though.


Anonymous 05/17/2020 (Sun) 01:56:38 [Preview] No.14156 del
>>14123
Now see how simpler it would be to update a long message thread for all it's 100 readers on limited bandwidth uplink when one of them appends just one short message. It would be reasonable to download only the increment data, not the whole thing, right? But www can't do this without JavaScript.


Anonymous 05/17/2020 (Sun) 13:44:22 [Preview] No.14158 del
(210.57 KB 485x713 Orbquest-ad.png)
>>14156
Well the way it was done prior to the web made more sense. Instead of trying to manage a single "page" of messages (that aren't even threaded properly), your news client would query the requested posts over NNTP (typically from your ISP's local Usenet server).
Or there was the BBS model where you simply read whatever message you want directly (while dialed-in to the BBS) or downloaded all new/unread messages in QWK format to be read offline later on.
Either way you could also easily archive threads and sort 'em however you wanted. And your computer could be just any old 8-bit machine with a modem. Didn't need graphics, fast connection, or anything fancy.


Anonymous 05/17/2020 (Sun) 19:03:49 [Preview] No.14159 del
>>14156
>increamental updates, www can't do it without javascript

The very board you are looking at right now already does that without javascript. The numbers that you can click on at the bottom of this page are used to send an HTTP GET to the web server with an indicator of where in a long list of threads to begin fetching threads without having to fetch all of them. Applying the same concept to a single thread and allowing a GET to fetch only the last N messages in a thread, or only messages added after mm/dd/yy would be trivial. No javascript needed.


Anonymous 05/17/2020 (Sun) 19:20:20 [Preview] No.14160 del
In fact, doing that using javascript would be a lot less efficient because you would need to send a bunch of index information about the messages that are not being downloaded to the client so that its javascript, running locally on the client, could do filtering and selection.

Put the logic in server-side CGIs and pass parameters back and forth in CGI variables. You don't ever even need to use cookies. The server generates HTML with a bunch of different things that a user could click on each with unique CGI variable values in them like ?session=382798&authcode=KjHHnfJd&page=4&sort=by_name&arg=3&etc=more and the client sends that selection back when they choose one. You can make arbitrarily complex systems that way with authenticated logins, clickable graphic maps, auto refreshing dynamic pages if nothing is clicked on in X amount of time, whatever you want. No cookies and no javascript needed ever and far less costly to produce and test because it will run on any browser without even having to check what kind of browser it is. You can even CSS that shit and have dyamically resized windows and wrapping panes for mobile. It's a better way of doing things because it's cleaner, simpler, cheaper, easier to maintain, more robust and less dependent on third party libraries, MUCH more efficient in terms of bandwidth because you're not pulling .js files... what's not to like about building web sites that way?


Anonymous 05/17/2020 (Sun) 22:16:44 [Preview] No.14161 del
>>14159
What numbers are you talking about? I'm using my web browser with javascript off, and I see no numbers at the bottom of the page besides those in the captcha image. You're talking bullshit. HTTP has no codes for incrementally updating a page, it downloads the whole thing and painfully refreshes it showing the ugly blank default background before drawing page styles and graphics. Some sleek imageboards with proper javascript and json databases either refresh on timer every X seconds, or instantly upon new message arrival. It's not a hard thing, but it requires user-side programs a fucking document distribution system was not designed with in mind.
>>14160
Have you ever seen an IM client in your life? It either pulls messages off the server, or establishes a socket connection for server to push messages in real time. Stop reinventing webshit from 90's, it doesn't work when there's more than 2 people accessing your server at the same time.


Anonymous 05/17/2020 (Sun) 22:26:40 [Preview] No.14162 del
I've been thinking about that question - why do people insist on building with javascript, making web sites that are fragile, inefficient, don't work with Tor or anyone who cares about security, expensive to maintain, and much harder to build requiring checking browser versions and coding to browser inconsistencies. They keep wanting to do it; there has to be a reason.

My theory is that it's because Javascript is the first language they learned. Before the web existed, many programmers learned assembly language and C as their first languages. When it came time to develop websites, Apache CGIs and Postgres or MySQL was the way. Sun started pushing Javascript as a cutesy way to beautify web pages in the 90s, but nobody doing serious development did anything other than basic cosmetic scripting with it because it was obvious that it would always have to be tailored to specific browsers and even specific browser versions. In the 2000's, a new generation of CompSci classes started teaching Javascript as a first language because all you needed was a text editor and a browser to display what you'd written locally. It was easy, and anyone could get text in a pretty window to show up on the screen - even if they really should never be writing production software. A generation was fed a top-down conceptual model of programming and started implementing stuff with little understanding of what was happening in the layers below. They knew that Javascript was running in the browser, but they had no concept of machine instructions and registers and CPU cycles. Everything bad that could happen as a result of minting an entire generation of programmers who've never debugged or understood an interrupt service routine reentrancy condition or cared about how many CPU cycles a sequence of code that they'd written consumed did happen, and that's why we are where we are today and why a significant portion of web sites pull megabytes of crap from eight different servers and don't work at all when you disable javascript or if you are using the "wrong" browser.


Anonymous 05/17/2020 (Sun) 22:46:15 [Preview] No.14163 del
(46.05 KB 927x310 herpderp.jpg)
>>14161
>What numbers are you talking about?
See attached.

>Have you ever seen an IM client in your life?
I've written a number of them. I've written ecommerce sites. I've written sites accessed concurrently by a hundred thousand people.

>Stop reinventing webshit from 90's, it doesn't work when there's more than 2 people accessing your server at the same time.

I really don't think you understand how the basic stuff works. You certainly don't understand how CGIs work. When the browser does a GET to something like /domain.com/foo.cgi?var1=val1&var2=val2, the web server executes foo.cgi and passes it the parameters that were provided to it. When the browser does a POST, it sends that plus whatever was entered into fields. That's all standard HTTP. Your program, which can be as sophisticated as you want it to be, storing a hundred thousand concurrent sessions in a backend database cluster or whatever you need it to do, processes the input and then it generates the HTML, typically using static templates and adding whatever dynamic ocntent it wants such as messages or an updated chat window or whatever, and sends that. It's much, much faster and scalable than using javascript. In fact, you have to have all that backend stuff anyway. What you don't need is the javascript.


Anonymous 05/17/2020 (Sun) 23:35:58 [Preview] No.14164 del
>>14163
>I tell him about thread messages, he shows me page numbers on board page
Wheeze, man. Pagination too can be eliminated with lazy-loading scroll. I just remembered the thing that does append new stuff without requesting all the previously downloaded articles, it's called RSS.
>uses outdated Tor browser
>writes enterprise-grade webshit(TM) and tells me how CGI scripts are better than client-side logic
Ok, boomer. It looks ugly, it is computationally intensive for a server with multiple concurrent users, it can be done on individual clients, you don't need any backend for this besides one database and interface to read/write in it. An encrypted websocket chatroom can be run on esp32 microcontroller with 500k of RAM using it only for initial download of page with javascript and for message store/routing.

>>14162
No. It's because what you see on modern web as "bad javascript" used to be delivered by mail on floppy disks and executed on your PC anyways: databases, phonebooks, interactive catalogues, videogames, scene zines as amalgamation of the former. What wasn't run locally, before Internet adoption, you had to dial up, one service at a time since telephone lines can only establish one connection due to the nature of circuit switching architecture, most of the time people logged into large mainframes owned by telephone companies, or ones located at their workplace, these mainframes contained all the services people used daily, so there was no need to connect to different ones for specific task: electronic mail, news, classifieds, chatrooms, spreadsheet, text processing software, heavy math software, on some advanced systems even graphic stuff like maps and weather forecasts projected onto them. Reminds somethin', eh? Millennials call it C-L-O-U-D, exact same services modern Google soup provides, and everybody shits their pants over how good ol' days were before web when you had to do your taxes on university mainframe because your home computer was an equivalent of modern smartphone, an overpriced kid's toy.


Anonymous 05/18/2020 (Mon) 13:17:27 [Preview] No.14166 del
(36.42 KB 640x480 Java.png)
>>14164
> need mainframe for filling out 1040 form
Nah. Most people in the 80's just used the paper forms and a calculator. When I turned 18, my aunt showed me how to fill out the form and I've done it that way ever since, even when I did contract work (form 1099) and had a bunch of deductions and investments.
But if you did want the computer to do all the work, it wouldn't need to be any kind of fancy computer, just something powerful enough to run a spreadsheet, because that's the kind of basic math that taxes are. Actually here's an "official" software for DOS:
https://winworldpc.com/product/turbo-tax/9x
Needs an 8088 CPU, but I'm sure a Z80 could handle it just fine too (I mean it's capable of doing those calculations, not that it can run DOS software made for Intel x86). Anyway a plain old desktop calculator can do taxes, so you really don't need much.
As for javascript, well it's a piece of botnet-enabling shit. Unlike the early micros, today's computers are full of serious bugs at every level. It's a very bad idea to keep such computers networked all the time, and it's even worse to allow remote sites to run unverified code on them.


Anonymous 05/19/2020 (Tue) 18:08:26 [Preview] No.14169 del
Because the model of a static webpage for everything has proven unfit for purposes of modern™ Web®.
I think the smarter move would be to redesign the protocol and the markup language itself, allowing for more in-page interactions with a server in a standardized manner and defining more semantics in general instead of just a document markup, but things like those are hard to plan in advance and redesigning shit would mean losing/splitting the userbase.

Honestly I just feel bad mostly because Web was used for things it wasn't designed for thus thwarting the establishment of some competitive standards. For example, web online banking/payments shouldn't really be a thing, web browser games shouldn't be a thing (though actual native games didn't really suffer because of this afaik), web-based instant messaging like webchats shouldn't be a thing and so on. Instead, there should be applications covering use cases out of the scope of Web. That's what I feel bad for. JS is just a symptom of this and a solution to extend that scope to the infinity, because now we can have pages do pretty much whatever webmasters want, and the world has pretty much moved into the Web world, not the application world as far as user experience goes (JSON applications still talk pretty much Web).

>how to fix this
I actually don't know. Allowing web pages to do whatever they want is more powerful than designing some very powerful but static scheme first to later find out users (webmasters) want to do something entirely different. One thing people could do is stop using Web entirely but I don't see it happening anytime soon. The worst thing that happened to Web users' recklessness so far is the snowden- and whole privacy awareness thing, I think, but it is not nearly enough to stop that "whatever works, goes" train. Also to be completely honest, JS isn't necessarily a terrible user experience nor a privacy/security risk (no more than using web by itself). Probably even the most sophisticated logic could be coded in some tens of kilobytes of JS but instead we have obfuscated monsters taking actual megabytes of space that actually could fail to load and guess what - robust™ JS have logic for that also which bloats them even more lol. Yeah. Programming is hard, I guess.


Anonymous 05/20/2020 (Wed) 10:45:32 [Preview] No.14171 del
Besides 3rd party javascript, if I'm not behind something like TOR, is there any security reason to really block it?


Anonymous 05/20/2020 (Wed) 12:58:02 [Preview] No.14172 del
>>14171
Unfortunately in the Web, you cannot really trust even a "trusted" site with 3rd party requests blocked in your browser, because the injected JS can still do shit on the site without you knowing about it. Do note also that I said "requests" - you have to block all 3rd party requests with something like RequestPolicy or uMatrix for ffx, or else even legal JS can access some fingerprinting resources which in turn could be hijacked as well.
Also JS enables sites to do much more elaborate fingerprinting of your browser, however I do admit that there are way too few people disabling JS these days, so running sites without a JS is a distinguishable fingerprint by itself.

tags: fingerprinting, DNS rebinding, XSS, HTML injection


Anonymous 05/25/2020 (Mon) 21:35:39 [Preview] No.14196 del
Javascript clearly exists only for malware purposes (and there are a few of those).

It's padded out by a cargo cult. Morons who want to look like they are selling malware to run on targets' computers.

In this thread the javascript morons think that a web browser can serve as a kind of package manager that works by allowing remote execution of a kind of php when you trick the person into "visiting a web page".

It seems convenient to have a remote execution engine built into customers' computers, but on inspection it's obviously not a good idea.


Anonymous 05/25/2020 (Mon) 21:46:12 [Preview] No.14197 del
>>14172

I think that the idea of automated registeration your domain with shadowy regulators shouldn't be called trusted.

They're trying to confuse TLS with "registered with me".

This wasn't a good response but that was a good post.


Anonymous 05/27/2020 (Wed) 18:10:51 [Preview] No.14201 del
>>14056
Same, when using tor.


Anonymous 05/31/2020 (Sun) 16:22:42 [Preview] No.14218 del
(14.04 KB 953x764 foo.png)
>>14105
I use a plain HTML browser without javascript, and up until today, I used to be able to get some useful information out of youtube's website, like for example information about a video or links to similar videos or other stuff published by the same author. But now I don't get any of that, and instead it looks like pic. So I won't be going back there anymore.


Anonymous 06/01/2020 (Mon) 02:02:57 [Preview] No.14219 del
i use https://video.genyoutube.net/
just add the 11-char youtube code to the end of that and you can download it as an mp4 or whatever


Anonymous 06/02/2020 (Tue) 22:07:48 [Preview] No.14225 del
>>14219
Use youtube-dl


Anonymous 06/03/2020 (Wed) 14:31:27 [Preview] No.14228 del
>>14219
it's under cloudcucks. you better warn bois before posting shitty links. use y-dl.


Anonymous 07/10/2020 (Fri) 09:54:12 [Preview] No.14256 del
(133.31 KB 550x301 1995-pizza-dot-net.jpg)
>>14059
>I can sit on my lazy ass, order and pay for a pizza online and have it delivered to my house within an hour without having to stand up once
Sandra Bullock could do this back in 1995 without having to load 50MBs worth of JavaShit.



Top | Return | Catalog | Post a reply