Earlier quoted context omitted.
> That's exactly the same situation as any other TLS failure, not at all unique to HPKP in any way that I'm seeing. Yup. But the feeling I'm getting is that browser vendors see this behavior as non-ideal since it trains users basically ignore the error. Yeah, in theory the user gets to make their own decision. My theory is that almost no user is actually equipped to make such a decision. > admins of bricked sites can…
Ah, well that's fair, and I think I'd generally agree with that. I don't have an alternative proposal for handling TLS failures in general, but I think it's silly to arbitrarily make HPKP's UX a special case, and then cite that special case UX as a reason for deprecating it.
Brute Force Incognito Browsing
41–50 of 50 posts
Re: Brute Force Incognito Browsing
#42I 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…
What Firefox extensions are you using? Check out Multi Account Containers on Firefox if you haven't already. It fulfills all my privacy requirements when paired with uBlock Origin and Privacy Badger. https://addons.mozilla.org/en-US/firefox/addon/multi-account...
Re: Brute Force Incognito Browsing
#43Earlier quoted context omitted.
Ah, well that's fair, and I think I'd generally agree with that. I don't have an alternative proposal for handling TLS failures in general, but I think it's silly to arbitrarily make HPKP's UX a special case, and then cite that special case UX as a reason for deprecating it.
Fair enough. The way that HPKP was deployed and designed and then undeployed was really quite awkward.
Re: Brute Force Incognito Browsing
#44Earlier quoted context omitted.
Doesn't that assume that the only way they track your data is with cookies? Perhaps by agreeing you are also allowing them to track you based on browser fingerprint / IP address so private browsing wouldn't be fullproof for this use case?
You are right, and I have considered that, but what is the practical alternative? At least if they do they seem to have the decency to ask for reconfirmation each visit.
Re: Brute Force Incognito Browsing
#45I use Firefox Focus on my mobile devices. It blocks trackers and you can easily delete your history and cookies. https://support.mozilla.org/en-US/kb/focus
Note: it's packaged on F-Droid as Firefox Klar, the German version, but the name is the only difference as far as I can tell. https://f-droid.org/en/packages/org.mozilla.klar/
Re: Brute Force Incognito Browsing
#46Earlier quoted context omitted.
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 scenari…
The boogie man went away when I turned five years old.
Re: Brute Force Incognito Browsing
#47Earlier quoted context omitted.
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.
Would you leave your car and house unlocked if you never had a burglar?
Re: Brute Force Incognito Browsing
#48Earlier quoted context omitted.
> That's exactly the same situation as any other TLS failure, not at all unique to HPKP in any way that I'm seeing. Yup. But the feeling I'm getting is that browser vendors see this behavior as non-ideal since it trains users basically ignore the error. Yeah, in theory the user gets to make their own decision. My theory is that almost no user is actually equipped to make such a decision. > admins of bricked sites can…
Ah, well that's fair, and I think I'd generally agree with that. I don't have an alternative proposal for handling TLS failures in general, but I think it's silly to arbitrarily make HPKP's UX a special case, and then cite that special case UX as a reason for deprecating it.
The original sin the Browsers had is that the initial SSL UI was built by people who had no security UX background because almost nobody had any security UX background. This was the era when PGP was considered usable security technology.
So when HCI studies start being done (e.g. at Microsoft) and they come back with the scary result that real users just perceive TLS error dialogs and interstitials as noise to be skipped, there is a problem. Lots of real world systems depend upon skipping these errors. I worked for a large Credit Reference Agency which had an install of Splunk, but for whatever insane reason it was issued a cert for like 'splnkserver.internal' and the only HTTP host name that it accepted was 'splunkserver.internal'. So every single user of that log service had to skip an interstitial saying the name doesn't match. For years. Probably still happens today.
Browsers couldn't just say "OK, that was bad, flag day, now all TLS errors are unskippable" because of the terrible user experience induced, so what happened instead is a gradual shift, one step at a time, from what we know was a bad idea, to what we think is a better idea. That means e.g. "Not Secure" messages in the main browser UI replacing some interstitials, and brick walls ("unskippable errors") in other places where we're sure users shouldn't be seeing this unless they're being attacked.
HPKP was new, so like HSTS it does not get grandfathered into the "skippable because this is already so abused we can't salvage it" state. If you went back and asked HPKP designers "Should we do this, but with skippable UI?" they would have been unequivocal, "No, that's pointless". HPKP and HSTS only improve security if the users don't just ignore them, and the only way we've found to make the user actually pay any attention is to make the error unskippable.
Yes that means "badidea" and subsequent magic phrases in Chrome were, as they say themselves, a bad idea. Because users who know them just skip the unskippable errors and end up back in the same bad place.
Re: Brute Force Incognito Browsing
#49Earlier quoted context omitted.
Ah, well that's fair, and I think I'd generally agree with that. I don't have an alternative proposal for handling TLS failures in general, but I think it's silly to arbitrarily make HPKP's UX a special case, and then cite that special case UX as a reason for deprecating it.
How is this UX behaviour a special case? HSTS also requires the brickwall UX, so does the OpenSSH key change scenario. The original sin the Browsers had is that the initial SSL UI was built by people who had no security UX background because almost nobody had any security UX background. This was the era when PGP was considered usable security technology. So when HCI studies start being done (e.g. at Microsoft) and th…
In any case, if it was unclear, my point here wasn't that I necessarily dislike the brickwall UI. In light of the studies you've referenced, I definitely prefer it, and if it were up to me it would be enabled for all of TLS regardless of how many existing services with broken deployments are out there.
My point is that, if the more secure UX is part of the reason for Google's decision, I would rather have HPKP with a less secure UX than not have it at all.
Re: Brute Force Incognito Browsing
#50Earlier quoted context omitted.
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 scenari…
And then what does said government do with that data? They can buy and sell my information all they want. I don't care. Nothing has happened to me. Nothing will happen to me. I only wish I started a business to cater to people who live with such great fear as so many companies have been doing for the past 10 years or so. The boogie man went away when I turned five years old.