Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Brute Force Incognito Browsing

nullprogram.com

Post reply on HN
Print view View original

21–30 of 50 posts

Re: Brute Force Incognito Browsing

#21

Post by sureaboutthis »

systoll wrote: post #14
probably_wrong wrote: post #13

I have two use cases requiring private browsing, and dealing with both of them is very annoying. On one hand, I don't want to be tracked. Disabling cookies in this case is fine, because if I open my webmail then all I do afterwards is tracked, courtesy of analytics code. On the other hand, disallowing cookies leads to all the problems mentioned in the post. I wish there was a feature "keep multiple tabs, but cookies…

> "keep multiple tabs, but cookies are not shared between them" That's how Safari does it. It can be a little awkward, in that [eg] if you log into HN, then open a comments page in a new tab, you'll need to log in again -- but I think it's better than Chrome's approach. There's a middle ground that seems like it'd be the best of both worlds — sharing things between multiple private tabs, but not multiple private wind…

Except when one uses server push and that's not true anymore.

Re: Brute Force Incognito Browsing

#22

Post by sureaboutthis »

probably_wrong wrote: post #13

I have two use cases requiring private browsing, and dealing with both of them is very annoying. On one hand, I don't want to be tracked. Disabling cookies in this case is fine, because if I open my webmail then all I do afterwards is tracked, courtesy of analytics code. On the other hand, disallowing cookies leads to all the problems mentioned in the post. I wish there was a feature "keep multiple tabs, but cookies…

I have never been concerned with tracking and no one has scammed me, broken into any account, knocked on my door, or tried to kill me yet.

Re: Brute Force Incognito Browsing

#25

Post by samet »

I went through the very same path and wrote almost the same Bash script, then packaged it as a MacOS app:

http://github.com/samet/sessionless

When I need a true sessionless browsing experience, here is what I do:

1. cmd+space, open Sessionless

2. do whatever do you want with a true sessionless mode

3. cmd+q, quit with sweeping every trace

4. profit

Besides, I can open more than one independent Sessionless windows; a feature which is not possible using Incognito mode.

Re: Brute Force Incognito Browsing

#26

Post by jacobr »

sureaboutthis wrote: post #22
probably_wrong wrote: post #13

I have two use cases requiring private browsing, and dealing with both of them is very annoying. On one hand, I don't want to be tracked. Disabling cookies in this case is fine, because if I open my webmail then all I do afterwards is tracked, courtesy of analytics code. On the other hand, disallowing cookies leads to all the problems mentioned in the post. I wish there was a feature "keep multiple tabs, but cookies…

I have never been concerned with tracking and no one has scammed me, broken into any account, knocked on my door, or tried to kill me yet.

But in two decades, after your data has been sold and bought countless times, to who knowns which government? In 30 years, when I'm nearing retirement, I have no idea which political system I will live in, what power companies will have over my daily life, or who has bought all the data mined about me.

Best case I will not get any insurance because I googled some weird disease symptoms in 2018, for worst case scenarios just look 30 years back in Eastern Europe.

Re: Brute Force Incognito Browsing

#27

Post by patagonia »

tldr: Why should I be made to feel dirty if I don’t want to be surveilled?

If the new profile is sufficiently similar to your actual profile, the browser’s “fingerprint”, combined with network and machine information might still register.

On a non technical note I have a problem with browser makers chosing “sleuth” or risqué masquerading looking icons to represent “private” browsers. I turn on private browsing and the browser makes me feel sneaky or shifty or shady or suspicious (I’m just now noticing how many of those words start with “s”, interesting).

When I step out of my house and hope to not be tracked and surveilled I do not put on some Carmen Sandiego looking private eye get-up. (Unfortunately, I actually might have to in some cities, like London. And I’d def need to leave my digital devices at home.)

We opt-in to “do not track” and the servers ignore. We choose “incognito” mode and that’s not quite enough, even though at this point we are feeling dirty and sneaky because of the UI. I add uBlock Origin and Disconnect and now I feel like a full blown activist.

How do we flip the table so that the servers have to opt in to “Private Eye” mode? And if they’re still not getting enough info they have to enable “Five Eyes” mode. And if they’re still not getting what they need they can ask us to install the optional “surveillance state” module.

Not having the largest social network and largest browser maker both be for profit corporations with business models based on harvesting user information would be a start.

Re: Brute Force Incognito Browsing

#28

Post by tialaramex »

buu700 wrote: post #9

This sounds like pretty much the same argument that @eganist and I made to Google and Mozilla a little while back before demoing an HPKP supercookie ( https://github.com/cyph/hpkp-supercookie ) at Black Hat and DEF CON. Our position was that doing just about anything less than what Chris did here was essentially lying to users about incognito mode's threat model, but if I recall correctly both teams viewed other secu…

Do you really feel that deprecation of the HPKP self-ransoming foot gun came out of nowhere?

Re: Brute Force Incognito Browsing

#29

Post by yolandaruiz »

sureaboutthis wrote: post #22
probably_wrong wrote: post #13

I have two use cases requiring private browsing, and dealing with both of them is very annoying. On one hand, I don't want to be tracked. Disabling cookies in this case is fine, because if I open my webmail then all I do afterwards is tracked, courtesy of analytics code. On the other hand, disallowing cookies leads to all the problems mentioned in the post. I wish there was a feature "keep multiple tabs, but cookies…

I have never been concerned with tracking and no one has scammed me, broken into any account, knocked on my door, or tried to kill me yet.

> I have never been concerned with tracking and no one has scammed me, broken into any account, knocked on my door, or tried to kill me yet.

Is this a challenge?

Re: Brute Force Incognito Browsing

#30

Post by buu700 »

tialaramex wrote: post #28
buu700 wrote: post #9

This sounds like pretty much the same argument that @eganist and I made to Google and Mozilla a little while back before demoing an HPKP supercookie ( https://github.com/cyph/hpkp-supercookie ) at Black Hat and DEF CON. Our position was that doing just about anything less than what Chris did here was essentially lying to users about incognito mode's threat model, but if I recall correctly both teams viewed other secu…

Do you really feel that deprecation of the HPKP self-ransoming foot gun came out of nowhere?

Well, the timing wasn't 100% random since the newly supported Expect-CT header was HPKP's "replacement", but I do think three years is a ridiculously small turnaround time between initially adding support for the feature and killing it with low adoption as a stated reason.

I'd also say the footgun aspects of HPKP are a weak excuse to kill it, given that nothing really new about them has been discovered that wasn't acknowledged as a consideration in the original spec. If anything, I think it would've made more sense to improve the UX for both end users and admins/devs to reduce the likelihood of deployment mistakes (better documentation and tooling) and the potential for damage when mistakes did happen (e.g. make HPKP error screens skippable like any other TLS errors).

Post reply on HN