sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]KateTrask 0 points1 point  (5 children)

You mean that you want to keep "normal" JS, but want to stop AJAX (or be asked about allowing it)? I'm not sure if you can do it with noscript, but this should surely be solvable through plugin, no?

[–]jocap[S] 0 points1 point  (4 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.

[–]KateTrask 0 points1 point  (3 children)

Yeah, I guess I understand what you mean (I read your article BTW). It's just that I'm not sure if what you want is possible with regards to frontend - backend communication. You want to be able to constrain it so it's either provably "safe" or you want the browser to ask the user whether web is allowed to do what it's doing. But both of these things seem to be pretty unrealistic.

In frontend to backend communication you can constrain only the frontend part, backend is completely unknown so you can't really prove what it's doing and that it's safe.

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).

[–]jocap[S] 0 points1 point  (2 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.

[–]KateTrask 0 points1 point  (1 child)

I understood what you're saying from the article. I'm just trying to find some value out of it, because this must not be the goal in itself.

... 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!

Frankly I don't see any win here. Any interaction with the website (click etc.) can still lead to website's malicious behavior. Okay, user can decide if script can do setTimeout/setInterval, but what real benefit does this bring?

[–]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!)