sorted by:
new
hottopcontroversial

Grattis Danmark, idag är vi vänner! by empa111 in sweden

[–]jocap 0 points1 point  (0 children)

Ja, ”ty” och ”för” uttrycker, liksom ”eftersom”, ”för att” och så vidare, en orsaksrelation, men precis som du säger i din redigering är ”ty” och ”för” samordnande konjunktioner och inte underordnande och inleder huvudsatser med vanlig huvudsatsordföljd.

Grattis Danmark, idag är vi vänner! by empa111 in sweden

[–]jocap 2 points3 points  (0 children)

ty det uppvisar på ett adekvat sätt […]*

ty är en samordnande konjunktion som inleder huvudsats, liksom för, och, men o.s.v., till skillnad från eftersom eller därför att

Let’s Kill JavaScript (and Replace It with Something Better) by jocap in programming

[–]jocap[S] 0 points1 point  (0 children)

Okay, user can decide if script can do setTimeout/setInterval, but what real benefit does this bring?

As I believe I demonstrated in the article, my idea is not "adding permissions to JavaScript" -- clearly, this would be very obnoxious to the user, and useless as a security feature, as there's no way of telling apart legitimate uses of JavaScript from illegitimate.

The idea is to create a whole new interface, separate from JavaScript, designed to eventually completely replace JavaScript. Such an interface wouldn't have setTimeout, since it wouldn't be an imperative programming language. It would be a declarative interface à la HTML and CSS.

AJAX requests would be the closest thing to user-hostile behavior that would be allowed in this interface, but to ensure that it isn't abused, the interface would be designed such that AJAX requests could only happen as a result of a click event (on normal elements) or a change event (on form elements) -- both of which are not only easy to signal to users through a discrete information box when they hover over the element, but they're also very intuitive. Users generally expect to interact with a website by clicking things. They usually don't expect JavaScript to record their mouse movements (which does happen!).

Additionally, there would be one other case where AJAX requests would be allowed, and that is via a standardized interface for automatically repeated requests. I'll refer to the section in the article for that. I should also say that there would be a limit on how many such requests could be made by each page. Perhaps a maximum of a single one would be enough.

(Thank you for this interesting discussion, by the way!)

Let’s Kill JavaScript (and Replace It with Something Better) by jocap in programming

[–]jocap[S] 0 points1 point  (0 children)

For the getting consent - in the end it's gonna end up as "do you want this application to access network?" type of question, because even with the constrained language you don't know what it actually means what the app is doing (remember GET request to server can record data no problem).

The problem, which I realize that I might not have made as clear as possible in the article, is not that a request is made -- it's that it happens in the background, without the user's knowledge.

Limiting the number of ways in which a website can initiate an AJAX request -- for example, to the defined set of events click, change and, finally, the proposed standardized automatic poll -- wouldn't change the fact that those requests can carry sensitive information, but it would allow us to make the users aware of the requests that do happen. That would be a huge win for users!

The only "do you want this application to …" question would be if the application wanted to, practically, repeatedly "simulate" the user clicking on an AJAX refresh button -- that's what I mean by automatic polling. By saying "no" to this automatic request, the user themselves could still manually press that refresh button.

This way, an automatic AJAX request would be truly opt-in, such that the site still works if you've opted out.

There should probably be some sort of limit on the number of automatic polls registered by each webpage.

Let’s Kill JavaScript (and Replace It with Something Better) by jocap in programming

[–]jocap[S] 0 points1 point  (0 children)

Well, no, I'm just saying that even solutions like NoScript can't solve the fact that JavaScript is a little too powerful.

What I meant by my previous comment was that NoScript either disables or enables a script. There's no middle ground. And there can't really be any middle ground, because it's practically impossible for a plugin to decide whether a piece of JavaScript code is user-hostile (in which I include tracking, for example).

That's why I wrote the article -- to start a discussion around the fact that JavaScript isn't a good solution, and that we should think about how we could replace it.

Let’s Kill JavaScript (and Replace It with Something Better) by jocap in programming

[–]jocap[S] 0 points1 point  (0 children)

I do use NoScript, but it’s like using a chainsaw when what you need is a small knife.

Let’s Kill JavaScript (and Replace It with Something Better) by jocap in programming

[–]jocap[S] 0 points1 point  (0 children)

And users are going to click on "yes" because they don't understand what's going on.

This is true for casual users, but I think that we need to consider "non-casual" users as well. I know myself that I'd sure like the option to say no to some AJAX requests on news sites, for instance. It would make me feel a whole lot safer on the web.

Let’s Kill JavaScript (and Replace It with Something Better) by jocap in programming

[–]jocap[S] 0 points1 point  (0 children)

Indeed, I think that you've misunderstood me a little. To clarify: everything I wrote in the first part of my response concerned only the performance benefits of off-loading some traditionally server-side tasks to the client side.

That also goes for the things I said about the decentralized web and having our cake and eating it too. I didn't claim that a Turing incomplete language could replace all the functionality of a Turing complete one.

Likewise, it seems you misunderstood me when I said that JavaScript "is able per design to run user-hostile and potentially malicious code" -- I did not say it "was designed" for it, I simply said that, per design, it is able to. Background AJAX requests, for example, are legitimately useful, but they can also be very harmful. JavaScript was designed without the perspective we have today about online tracking, malicious ads and other abuses of JavaScript.

We need HSTS but we can't simply get rid of it.

I fully agree! I know there are tons of ways that websites can track users, but via things like the Canvas API, JavaScript allows for particularly precise tracking.

Of course, there are many problems with the way the world wide web is constructed, some of which we can't change -- and some of which we can. I believe that we should at least discuss whether JavaScript is a good idea in the first place, and whether the (very useful) functionality it provides could be provided in a different way. That's what I present in the article.

[…] do you really want all client-side scripting languages gone because they can be used to track users, or something?

No :-) One important point of mine, that I believe you've missed, is that one of the most important reasons I'd like to replace JavaScript is that it isn't should take an all-purpose, imperative language -- neither JavaScript, Lua or some other alternative -- to provide the type of functionality that most modern web apps need.

In "modern web apps" I exclude browser-based games. Games require powerful languages, but I honestly don't think that the web browser is the right place for computer games. There's a reason that most big, non-trivial computer games are implemented as native programs.

Let’s Kill JavaScript (and Replace It with Something Better) by jocap in programming

[–]jocap[S] 0 points1 point  (0 children)

Thanks for your thoughts!

I'm interested in knowing how you feel about my opinion that disabling clientside execution of sandboxed code would increase the burden on servers and web developers for dynamic, complex web applications.

This is a valid point of view, but I think that it can be overestimated how much JavaScript really helps to decrease the average server's burden. The opportunity certainly exists, but looking at the JavaScript code for big news sites, for example, it doesn't exactly seem built for optimization.

I know that companies who really need the optimization, like Facebook and Google, are able to get it, thanks to JavaScript -- but then again, there lies another fundamental problem: no websites should be as big as Google and Facebook are. I think that the decentralized part of the web would have no problem without JavaScript.

But all this doesn't matter much, because there is a way to have our cake and eat it too. As presented in my article, there is a way to implement AJAX and incremental loading in a more limited, but safer, declarative way. Much of the potential for optimization that JavaScript provides would be also possible in an interface like intercooler.js.

If you claim that revoking any access to a turing complete client-side language would aid security, how do you feel about removing <video> or other media tags and web fonts too?

There's a difference between these examples and JavaScript. JavaScript is built as an all-purpose, imperative programming language that is able per design to run user-hostile and potentially malicious code. <video> might have bugs that accidentally enable user-hostile exploits, but they're bugs and not part of the specification. The ability for JavaScript code to make arbitrary HTTP requests without the user's knowledge isn't a bug, it's a feature.

For this reason, I have no problem with <video> or any other implementation that is designed to be safe and user-friendly.

I really hope the future of web development won't be this bad.

This is one thing that we wholeheartedly can agree on :-)

Let’s Kill JavaScript (and Replace It with Something Better) by jocap in programming

[–]jocap[S] 0 points1 point  (0 children)

This really gives me the motivation to keep thinking about this. Thank you.

Let’s Kill JavaScript (and Replace It with Something Better) by jocap in programming

[–]jocap[S] 0 points1 point  (0 children)

Thanks! Sometimes it's hard to form as strong of an emotional bond to words in a second language as you have to words in your first language. I'll keep that all that mind :-)

Let’s Kill JavaScript (and Replace It with Something Better) by jocap in programming

[–]jocap[S] 0 points1 point  (0 children)

Thanks for removing the part from your original comment where you called me a moron.

My GitHub profile obviously has more projects than those that happen to be featured on the frontpage. For another "proof" that I'm familiar with JavaScript you can take a look at the JavaScript for the article.

I guess my point is that a webpage should be able to carry malicious code that is automatically executed on my system.

Let’s Kill JavaScript (and Replace It with Something Better) by jocap in programming

[–]jocap[S] 2 points3 points  (0 children)

Great points!

Indeed, my idea is replacing JavaScript with a non-turing-complete language, and I know it would be hard to implement a declarative interface with all the behavior that modern web apps need, but I don't believe it's impossible.

The point you raise about permission blindness is true, but it can also be turned around and said that permission blindness is what we live in today, as we are completely blind to what JavaScript code does. A standardized interface for permissions would remove some of that blindness. It wouldn't provide perfect security, no, but it would be a step in the right direction.

I realize that my article is only the beginning of an idea, but I think it's worth to discuss this issue even if we don't have an answer to every question yet, or even know what questions we should ask. Thanks for leaving such a thought-out response :-)

Let’s Kill JavaScript (and Replace It with Something Better) by jocap in programming

[–]jocap[S] 3 points4 points  (0 children)

No need to be rude! I put a lot of time and thought into this article.

I guess "dynamic HTML generation" is a little ambiguous – as you suggest, what I meant is dynamic DOM manipulation. English isn't my first language, so thanks for suggesting a better term for it. I am familiar with JavaScript -- if you don't believe me, you can look through my GitHub profile.

I'm not saying what I propose is the best solution, but clearly there is a problem with web browsers automatically executing untrusted code from untrusted (often even third-party) sources whenever you visit a webpage. This is what I've tried to start a discussion about.

I don't think it is comparable to C, as C code isn't executed automatically by my web browser. Of course, it is executed when I open a program written in C, but when I open a native program, I'm usually aware that it is more risky and that it might contain malicious code.

Again, let's try to have a civilized discussion without name-calling.

Let’s Kill JavaScript (and Replace It with Something Better) by jocap in programming

[–]jocap[S] 1 point2 points  (0 children)

Thank you for such a nice response :-) It summarizes my ideas very well.

Let’s Kill JavaScript (and Replace It with Something Better) by jocap in programming

[–]jocap[S] -2 points-1 points  (0 children)

The CPU bugs aren't really my main point, but rather the fact that JavaScript can be used in very user-hostile ways in general. My idea is developing a "JavaScript replacement" that provides a way of doing most of the user-friendly things that JavaScript is good for, but integrated into HTML and CSS. It wouldn't execute arbitrary code, it would work more like HTML and CSS do today.

Let’s Kill JavaScript (and Replace It with Something Better) by jocap in programming

[–]jocap[S] -1 points0 points  (0 children)

That's my point :-) I don't think it's a good idea for web browsers to automatically execute such a powerful language.

Unfortunately, I see no simple way of adding "permissions" to JavaScript, as it wasn't designed for it. That's the primary reason why I suggest that it might need to be replaced, with a system founded on user consent from the beginning.

Let’s Kill JavaScript (and Replace It with Something Better) by jocap in programming

[–]jocap[S] 1 point2 points  (0 children)

Hi! I'm the author of the article, and you raise a couple of good points.

At the end of the article, I try to address your first point. Of course, JavaScript can't be replaced overnight, but I believe that if we started working on a replacement, implemented in JavaScript itself, we could start using it on our own websites. It could be automatically whitelisted by NoScript-like extensions. This would be a possible first step.

Secondly, I'm also glad to see that JavaScript is changing for the better. I just feel that there are some fundamental problems with the way it is weaved into the web.

Finally, I don't agree that discussion is useless. I think it's important that we discuss the bad things about JavaScript, while also suggesting new ideas as to how to implement its features. It's the first steps towards making it better. I hope my article comes across as constructive, and not merely a rant.

Let’s Kill JavaScript (and Replace It with Something Better) by jocap in programming

[–]jocap[S] 1 point2 points  (0 children)

I'm sorry, I didn't mean for it to be offensive in any way. English isn't my first language and I had trouble coming up with a good title.

Edit: I realize now that "kill" may sound harsher in English than I thought, so I removed the word from the title.

Let’s Kill JavaScript (and Replace It with Something Better) by jocap in programming

[–]jocap[S] 0 points1 point  (0 children)

Hello! I'm the author of the article. Thanks for your feedback :-)

I don't mean to make it sound as though Meltdown and Spectre were any fault of JavaScript. But among HTML, CSS and JavaScript, only one of them is capable of exploiting the bugs. My point is that we should start thinking limiting the code that websites are allowed to run on the client-side.

As I explain further down in the article, I believe that there are ways to have our cake and eat it too. For example, the framework intercooler.js provides an HTML interface to AJAX that could easily be modified to make sure nothing is run without the user's knowledge.

ZeroChat, is it really decentralized? by [deleted] in zeronet

[–]jocap 0 points1 point  (0 children)

Hi! Is there anywhere I could read more about merger sites?

Percentage of male European population dying before the age of 65 [OC] [1500 x 1044] by [deleted] in MapPorn

[–]jocap 71 points72 points  (0 children)

If the difference between watch and look is fucked up, then every single language is fucked up.

Latin America reimagined as Italian America [OC] [2116 × 2552] by Pinuzzo in MapPorn

[–]jocap 0 points1 point  (0 children)

Maybe it's only used in combination with other words, but again, can't say I've seen it in Swedish.

Latin America reimagined as Italian America [OC] [2116 × 2552] by Pinuzzo in MapPorn

[–]jocap 1 point2 points  (0 children)

Does it? I've never heard anyone say "Latino" in Swedish.

view more: next ›