Hacker News Reader

Comment by ryandrake | Hacker News Reader

Try making this argument with compiled code instead of HTML:

"The company included the code to do $BAD_THING in the binary executable, but it was the user's choice to run it, and he could have easily modified the binary to ignore $BAD_THING, but didn't. Therefore, it was the user doing $BAD_THING, not the company."

A lot of people in this discussion are splitting hairs here, trying to blame the user or the browser. The technical details of what a browser does are less important than the end effect: Fundamentally, the web developer added "stuff" to the HTML, knowing that this "stuff" will cause most browsers in the field to access these fonts on another computer. The fact that the end user could technically block it, doesn't change the developer's intent.

View on HN

Correct. The question for law is: what does a reasonable person expect?

This is a problem because people (in general) are not good at understanding or reasoning about what computers do... and the entire purpose of the web is to put a simplifying, abstract model in between what humans want to do and how computers work. Models are always wrong, sometimes useful. The web is very useful because it is wrong.

If the web were more like Gemini -- I'm not advocating for this -- every link would be an explicit change, and the argument that a reasonable person would be aware that different things came from different entities would be solid. If JavaScript existed but a web page could not request any resource from a non-origin domain, the argument would be solid.

It's not reasonable for a random user to have to internalize a model that says that sometimes the font used by a page is local, sometimes it is supplied by the website, and sometimes it is a call to a third party. It's true, but it's not reasonable.

From my experience, I think the average user treats the browser and the internet as a black box anyway, they don't reason about what is happening. As long as they can get to what they want, they don't really care what happens in between. Cookie notices get in the way, and therefore annoy them. Most also just accept the fact that there data gets leaked everywhere and there's not much that they can do about it. I genuinely don't believe that the average user can make sense of the TOS that they agree to when signing up for something...

This is definitely not a good thing, and should change, but I also believe that ad-driven companies will continue to find a way, we just continue to rack up operating complexity, which in turn, favours large companies. This ruling seems like a pretty weird and unhelpful way (in the grand scheme of things) of helping protect user privacy, but then again, that was not the goal of the lawsuit.

Yeah, I guess this stands. But HTML is not executable. It has to be parsed, like words in a book, not chemicals in a tube. Who is liable, the person who creates the poison, or the book (encyclopedia) which describes the process (and therefore the person who wrote it/distributes it)?

Again, I'm not saying what is right and wrong, but I think this issue is fundamentally much, much more complex than the court may have thought, and more importantly, may have repercussions on almost every website out there.

> Yeah, I guess this stands. But HTML is not executable. It has to be parsed, like words in a book, not chemicals in a tube. Who is liable, the person who creates the poison, or the book (encyclopedia) which describes the process (and therefore the person who wrote it/distributes it)?

I know as soon as you typed this, you probably thought "oh crap, what about Python?" so I won't go there.

I think the major underlying thing here that makes developers uncomfortable with this court ruling is that the whole industry of software development has a chronic and pervasive problem with the idea of consent. I'm not saying individual software engineers don't know what consent means, but we constantly put out software that does things without giving the user informed consent and control, and resist all efforts to force us to ask for this consent.

Imagine trying to use the Software Industry's idea of consent when dating: "Hey, Alice, do you want to go out on a date with me? I'll only accept the answers [Yes] or [Ask me again later]". Ridiculous! But software regularly does this! "Hey, Bob, I love you and I'm going to keep sending you text messages. Do you want [all my text messages] or [only essential text messages]?" Ridiculous, but look at the "consent" options when it comes to cookies.

Not to be crass, but when software wants to get users to do something, they need to treat it as if the software is trying to get laid: You need to ask for, and receive, informed consent at every step of the way, at every new and different request. This is an uncomfortable idea to developers who are used to just commanding the code to do things.

I didn't, actually, but it's a fun thought experiment :)

Python code is instructions that are executed in a very precise manner, they could, in theory, encrypt a hard-drive. You execute the program the same way you execute binary instructions.

HTML is a description of a problem, there are different interpretations, and different solutions, depending on screen-size, etc. You don't always get the same result. Technically, JS could mine crypto, but I don't believe that's illegal (correct me if I'm wrong?), just very inconvienient, and there wasn't any JS involved here. You could make a browser that leaks data due to misinterpretation of the HTML. The problem also lies with the eager-evaluation of HTML, it's difficult to put a disclosure or ask for consent, such as the responsibility clause of most software licenses, without greatly annoying the user...

> makes developers uncomfortable with this court ruling

Guilty. At the end of the day, we need to get stuff done, without creating a private internet infrastructure for our customer. The small guy is at a disadvantage here, not big companies.

Not really. You are making this much harder than it has to be by bringing in irrelevant technical arguments. The court mostly cars about intent and effect, not technical minutiae.

Also by your logic machine code isn't executable either since it too has to be parsed (by the CPU which transforms it into microcode instructions).

In your paradigm: shell, Python, Ruby and Java programs are not executable either, since they require interpreters before they become machine code. Java calls this bytecode and wants to run on a whole JVM, which is rather like a browser.

To follow down the difference here I think that the browser is much more aware of what it is doing than compiled code. It know what this is a stylesheet or a font, it knows it is coming from a different origin and more. Technically the browser is very capable of blocking all third party resources (if you assume that party == domain).

With compiled code stopping it from executing one particular instruction or feature is much harder.

Basically I think the declarative is a significant difference.

Of course I don't think the law thinks that. Otherwise we would have implemented technical measures for limiting cookies such a permissions (with legal backing) rather than these legal-only ones which are abused more often than implemented as they are supposed to be.

Reply on news.ycombinator.com