Hacker News Reader

Comment by blfr | Hacker News Reader

If there are already so many ways to fingerprint via cookies, JavaScript, Flash, etc. that it probably doesn't matter then why do cookies matter? That the EU parliament decided to pass some weird law is not much of an argument. They're not exactly known for their technological proficiency. And it did nothing for privacy. It only annoys people[1].

Sure, we could start with cookies. However, that would break a lot of the web with no immediate benefit.

On SSL everywhere (not "anywhere"), how much resources does it cost to negotiate SSL/TLS with every single smartphone in their area? Supposedly, not much[2]. I run https websites on an Atom server.

Frankly, that was rather unconvincing. Although it does seem likely than the entire process was driven by IETF trying to stay politically relevant in the face of SPDY.

[1] https://github.com/r4vi/block-the-eu-cookie-shit-list

[2] https://istlsfastyet.com/#cpu-latency

View on HN

For what it's worth, the cookie law in the EU is far more general than cookies, and had a totally different origin. Originally, the law was to require explicit consent when installing something on an electronic device, to combat malware. However, some clever politicians later realized that setting a cookie also "installs" something on an electronic device, and thus the law further known as the cookie law was passed.

If a webserver were to set some secure session identifier, the same laws still apply -- just as installing software without explicit consent is covered by the same law.

Not if you are using the session identifier for it's intended purpose, see the exceptions at: http://ec.europa.eu/ipg/basics/legal/cookies/index_en.htm#se...

We all know how broad "intended usage" can be defined. Google has a cookie that is required for logging in into gmail (clearly intended usage), but is reusing that exact same cookie for tracking purposes.

Until there is actual legal precedence after people sueing businesses abusing these abilities, I have no idea how to interpret these laws other than "they are very broad and vague".

I don't think the laws are vague so much as how we use cookies today. With different mechanisms for different purposes it would (could) be much more transparent to the end users how things work. It would be more like the "save password" feature in various browsers. Of course since all the major browsers vendors also make money from ads this isn't really in their interest.

Cookies are a historical band-aid. The implementation is a mess, cross-domain cookies require all sorts of hacks, and there's nothing you can do with a cookie that you can't do with a session identifier.

Also, SSL gets way more complicated when you are using a CDN.

You could say that most of the modern web is a historical band-aid. Here we are, 20+ years later, building "apps" on top of a document delivery system.

It's worked pretty well though, just sayin'.

No, it hasn't. The web is a terrible, hacked-together mess. Things break often and catastrophically. HTTP 2.0 is layering on more hacks instead of trimming the fat.

It works, yes, but with great effort. Think of all the development time spent grafting applications on top of what is fundamentally a document delivery system.

It's hack upon hack, kluge upon kluge.

Example: Do you think HTML/CSS/JS is the right way to develop a user interface for an application? I don't.

It's a damned sight better than tk, wxWigets, Swing, SWT, AWT, MFC, or any of a bajillion other things we've tried in the desktop.

Yeah, you're right, all those things are terrible, too. Can't we do better than what we have?

Yeah, with AngularJS and REST I can finally approach the level of productivity that Visual Basic 4.0 had 20 years ago.

Remembering the later BBS days and their own GUI protocols for applications, I don't consider web applications really any worse... Realistically today, you can use WebSockets (or a safer abstraction, shoe/sock, socket.io, SignalR or otherwise) to act as an application channel, with static resources grabbed via HTTP(S).

In such a way, your application channel can maintain all the state it needs in that websocket... no cookies needed. The downside of the web today is the lack of a standard display interface/size... you have to work from a phone all the way to a 1080p or larger desktop or big screen display.

These abilities to use the web and enhance things is exactly why the web is as pervasive as it is... if it weren't for such open, broadspread ability we'd all be stuck with a natural monopoly (windows) everywhere.

Reply on news.ycombinator.com