Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Not trying to defend anyone here, but I wonder if there's a non-nefarious reason for this.

Specifically, there have been a lot of changes to cookies lately because malicious actors (malware/adware) figured out how to access the cookie store and infer/determine cookie information from other sites.

I suspect that maybe this cookie store is kept in a more secure part of the application and only the cookies relevant to the site you visit get pulled out of it. It may even be a risk to have the information for all domains even loaded into memory for the application.

With all that said, there should be some way to manage/introspect that cookie store from outside of the browser imho.



Let's remain serious. It is entirely within the capability of modern computers to admit a dialogue which would let the user view their cookies without magically exposing them to websites. There is no non-nefarious reason for this.


Thank you. The pretence (naivety) of "there must be a good reason" has to stop


There’s usually a “good reason” — however that “good reason” is subjective to the people maintaining the application and might not align with the preferences of its users.

Reasons don’t really matter to users though. It’s pointless arguing if we should assume innocence or guilt because irrespective of the developers motives, if a particular feature is a show stopper for you then you switch to a platform that supports said feature. Anything else added to colour the discussion is irrelevant.


I agree with what you pointed out about subjectivity. I think it’s still worth discussing though to serve as a warning to others who act with their own best intentions only to have them get bitten. Without calling this out it just always leans on the malicious side which doesn’t trend with reality in my experience.

In terms of end users driving decisions ultimately, I agree. That said, this is a discussion forum so I figured it was open for discussion and assumed that folks would be deciding on their own how to react to the change.

I guess this all depends on what we think we’re having a discussion about!


The problem is any such discussion is going to be entirely speculative. Sure, you can discuss what you presume the developers motives might have been but it reveals more about the opinions and personalities of the people holding the discussion than it does about the developers since all you’re doing is projecting your own story to fill in some pretty sizeable blanks.


But what many others in this thread have done is just as speculative, assuming malice, and to be clear, I think it could very much be the case, but I’m sharing another perspective based on a lot of experiences I’ve had where external parties assumed malice when internally it was far from it. Take it or leave it. This is the internet and I’m typing into a box.


I agree, but I suspect this was also what was believed when they originally did it and adversaries found very clever ways to find that cookie store - that part at least is true, which is why I bother mentioning it, given the complexity of browsers it is likely very daunting to redesign this kind of thing around the existing features. Anyways, I'm glad I'm not working on browsers, it seems like an ever-losing cat and mouse.


Those two things are unrelated if there is such interaction and the fix was removing the dialog I would be scared to use that browser.

So whether your theory is true or not, no one should use Chrome.


I agree.


Chrome already has functionality to put different sites in different processes and sandbox the processes, so that if there's a renderer bug, the attack is stuck in the sandbox of a single site and can only access that site's data. This also helps with CPU speculative execution bugs.

https://www.chromium.org/Home/chromium-security/site-isolati...


> Not trying to defend anyone here, but I wonder if there's a non-nefarious reason for this.

The tools are designed for developers who often want to manually edit cookies on pages they are debugging.


I recently had to develop a feature that would have been much easier to develop and debug had I been able to view the contents of Local Storage and Session Storage before loading the site.

A particular feature of a web application (shopping cart) had different behaviour depending if the page was loaded as "an initial pageview on revisit", e.g. the user coming from [search engine|other link|bookmark|url bar] or from normal site browsing. By storing data in both Local Storage and Session Storage, and comparing the two on page load, I could determine if the user, who had been to the site in the past, had just come back. This all had to be developed in the dark as the major browsers have no method of viewing Local Storage and Session Storage for websites not loaded.


I know that. It seems like a given for this forum and topic specifically that I am not ignorant of that.


If the browser is designed properly (this does not apply to Safari), the UI can and should have totally different permissions from the site executor/renderer.


>If the browser is designed properly (this does not apply to Safari),

Slow clap. Well done.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: