[HN Gopher] State Partitioning
___________________________________________________________________
State Partitioning
Author : oedmarap
Score : 308 points
Date : 2021-02-24 10:40 UTC (12 hours ago)
(HTM) web link (hacks.mozilla.org)
(TXT) w3m dump (hacks.mozilla.org)
| deostroll wrote:
| Found a concise video explaining the concept:
|
| https://www.youtube.com/watch?v=ETYmvjxc1h4
| eMGm4D0zgUAVXc7 wrote:
| Can the heuristics which do allow cross-site state access be
| disabled so cross-site access is never possible unless I
| explicitly allow it?
| cameronh90 wrote:
| I understand from the article is they're saying the future way of
| doing SSO is through an iframe with the Storage Access API?
|
| How does this work with being able to verify the HTTPS URL? How
| do I know I'm typing my credentials into my legit SSO provider
| and not a phishing site?
| pyentropy wrote:
| You don't need a shared storage if you do SSO the right way.
| Just redirect with a session token.
|
| And if the SSO server wants to share state with the other
| services, like forcing a logout on a specific app, it can
| always do it on the server side (app backend <-> SSO backend
| with user token).
| cameronh90 wrote:
| Sure and that is how we do SSO (though SameSite=Strict can
| interfere with that method too).
|
| But if that's the recommended approach, why are they
| providing a standard route to do SSO via an iframe with the
| Storage Access API? Does that API have any other valid uses
| that aren't tracking or SSO related?
| [deleted]
| pyentropy wrote:
| If the SSO system is legacy and must use cookies, then to
| request access for cookies you need to call
| requestStorageAccess() in a frame hosted on the origin,
| which will open a prompt asking the user to allow such
| cookie access.
| boshomi wrote:
| Is co.uk a registrable domain?
| dstick wrote:
| Yes? https://www.namecheap.com/domains/registration/cctld/co-
| uk/
|
| Has been for as long as I can remember. It's the UK's ccTLD.
| GavinMcG wrote:
| Whether something is a TLD isn't equivalent to whether it is
| a domain. The comment taken literally asked about the latter.
| jefftk wrote:
| No. It's a public suffix. Subdomains of public suffixes
| (example.co.uk) are registrable domains.
|
| The list of public suffixes is: https://publicsuffix.org/
| sambe wrote:
| Looking at the proposed permission UI, I would - as a programmer
| and heavy web user - have no real clue what to click/what the
| implications were. If it were Google - do I know and trust them?
| Well, sort of. I know them; I trust them in the same sense I
| don't trust a scammer.
|
| Also: 30 day timeout? I'm getting pretty fed up of re-logging
| into websites already over the last couple of years. Add on re-
| allowing various permissions for access to various things
| (sometimes every single time), trying to figure out why websites
| are broken (ad-blocker vs browser blocker vs not cross-browser
| tested vs temporary problem vs just totally broken) and it's
| rather a big productivity drain.
| onion2k wrote:
| _30 day timeout? I 'm getting pretty fed up of re-logging into
| websites already over the last couple of years._
|
| Users having to log in to a website 12 times a year, or 13
| times in a bad year, is a price worth paying to improve privacy
| and security across the internet.
| mFixman wrote:
| According to Firefox I have 217 saved logins in different
| websites.
|
| Even if I only used a fifth of them once a month, I wouldn't
| want to re-login 521 times every year. This is a big UX
| decline for pretty much zero privacy gain.
| sambe wrote:
| I'm not sure why you'd think you should make a statement on
| behalf of everyone. If you are happy with this trade-off, you
| are free to make it.
|
| The 30-day timeout is for Storage Access API - cookies expire
| much more often already.
|
| As I said, there is an _accumulation_ of productivity harms.
| My claim is that the pro-privacy solutions are not good
| enough relative to the problems they cause (and their effect
| on improving privacy is also debatable).
| stickfigure wrote:
| I think the concept is good, I just think 30 days is too
| short. Make it 60 days and now we're talking 6 times per
| year, much more reasonable. Make it 90 days and I don't think
| anyone will notice.
|
| This is going to affect every user of every website using
| federated auth. That's a lot of buttonclicking to add to the
| universe.
| kevincox wrote:
| I disagree. This is making a significant UX downgrade to a
| core workflow while making the tiniest blip on tracking. (Oh
| no! You lose cookies every 30 days)
| kome wrote:
| Isn't blocking all third party cookies still better after all?
| stickfigure wrote:
| I like this. After it rolls out, can we quit with those silly
| GPDR cookie messages? That always seemed like "a social solution
| for a technical problem", with all the jurisdictional and
| enforcement problems you would expect from one political body
| trying to legislate behavior worldwide.
|
| Don't want to be tracked? It's your browser after all, just stop
| handing the trackers data!
| tomjen3 wrote:
| I would happily set my browser to only accept cookies for a few
| sites but if you do that, those cookie popups are even worse.
| coldpie wrote:
| NoScript mostly fixes those, and there's also this[1] if you
| want to try something less drastic.
|
| [1] https://www.i-dont-care-about-cookies.eu/
| chrisan wrote:
| Thanks for this! I'm at a point where I am way more annoyed
| by cookie banners all over the place than whatever tracking
| is being done on me that I almost wanted to go back in time
| before GDPR, now I don't have to :)
| coldpie wrote:
| NoScript also blocks those fucking "give us your email
| address!!!!!!!!" popups and other similar trash. It's a
| hassle to use, and it sucks that it's required, but that's
| the web we built.
| jefftk wrote:
| _> After it rolls out, can we quit with those silly GPDR cookie
| messages?_
|
| Cookie banners also include notification around first party
| cookies. For example, first-party cookies used to implement
| analytics are included. See
| https://en.wikipedia.org/wiki/Privacy_and_Electronic_Communi...
| ComodoHacker wrote:
| Can you imagine the next step adtech will take in this arms race?
| I can imagine adtech giants like Google offering free web hosting
| and cloud resources to gather most of the Web under a few TLDs.
| They did it with e-mail, they can do it again with Web.
| Joe8Bit wrote:
| This is a very positive change, but I'd be interested to know how
| the Mozilla folks think about 'collateral damage' from a policy
| point of view.
|
| The exceptions and shared state lead me to believe they've
| thought about it and tried to mitigate it as much as possible,
| but how much is acceptable? If this breaks more than they thought
| it would, is it something they'd be comfortable rolling back or
| changing?
|
| For example, if I read this post correctly, this change would put
| a hard upper limit in SSO logins to 30 days for Firefox users
| (because StorageAccess is only granted for 30 days). That might
| not be a _huge_ issue for most people, but it'll add a hard limit
| to something that's never had a browser enforced hard limit
| before.
| pyentropy wrote:
| Just do a redirect with session as a query parameter (like many
| OAuth apps do it anyway). Each site can then persist the user
| session for more than a month.
| Ayesh wrote:
| I think cookies have a limit too. It may be not from the spec,
| but I never saw a single cookie in my Firefox that's longer
| than a year.
| Chilinot wrote:
| I guess the SSO token will still be valid, just not usable for
| SSO purposes after those 30 days. And most likely you will just
| have to click "Accept" again on the cookie popup to get it
| working as before for another 30 days.
|
| However, dont basically all SSO cookies live far shorter than
| 30 days? To my knowledge all SSO services i have used have
| expired earlier requiring me to log back in again.
| stickfigure wrote:
| > However, dont basically all SSO cookies live far shorter
| than 30 days?
|
| At least in the case of Google auth: While G may
| reauthenticate you every 30 days, it's global to your web
| browser. So after you have reauthenticated, you are back to
| "logged in" to websites you've logged in to with Google.
|
| In the "old way" you only need to reauthenticate to Google,
| Microsoft, etc once a month.
|
| With this new Firefox UX, you still need to reauthenticate to
| Google, Microsoft, etc once a month, but you also need to
| click "OK Keep StorageAccess granted" once a month for every
| website that you use federated login on. There are few auth
| providers but many more auth consumers.
| mxxx wrote:
| The 30 day limit is access to the storage API. So presumably
| the data is still there, you just need to give permission for
| it to be accessed again. It doesn't necessarily imply that it
| just logs you out on 30 days by emptying the state.
| joenathanone wrote:
| This needs to be bypassed to use SSO, to bypass it the SSO
| providers site will need to ask for Storage Access, in some cases
| the user will be asked for permission...
|
| "After the user has granted access, Firefox will remember the
| storage permission for 30 days."
|
| So lay users will get used to just clicking through and blindly
| granting the permission.
|
| The end result will be an additional step for trackers, and a
| bunch of headaches for all the legit services that get broken
| from this change.
|
| I'm all for less tracking but this doesnt seem like a good
| solution.
| swiley wrote:
| At least they're getting asked. That's a huge improvement over
| what was there before.
|
| I still prefer the lynx UI: prompt yes/no/always for accepting
| _any_ cookie.
| ancarda wrote:
| It's a shame that "always" will whitelist a whole site
| though. It'd be nice if Lynx whitelisted a cookie name (per
| site). That way I could permit "PHPSESSID", but not "_ga".
|
| I never found a Firefox plugin that let me whitelist specific
| cookies. I might try to write one when I have time.
| marcosdumay wrote:
| > So lay users will get used to just clicking through and
| blindly granting the permission.
|
| Does it break anything else besides cookie based SSO? Because
| for those, people will probably just login into the site, and
| ignore the permission.
|
| Firefox is also adopting the policy of not showing those
| permission windows at most cases, just showing a small
| notification. It's not clear on that page if this is one of
| those cases.
|
| Anyway, I agree that limiting the permissions to 30 days is
| bad. The users should be entitled to make permanent changes,
| and revert them themselves when they want. Firefox should at
| least give them the option, even if it's not the default one.
| treis wrote:
| Lots of third party stuff like chat widgets and shopping
| carts are going to break. Had to deal with this when Chrome
| did their 3rd party cookie stuff. It's not insurmountable but
| adds friction for stuff like that.
| undecisive wrote:
| I commend Firefox for trying to do this... but it worries me.
|
| 3 obvious holes:
|
| - Proliferation of dialogs. When you don't know whether a site
| will suddenly break or not, standard users will be implicitly
| trained to say yes to all dialogs.
|
| - Domain "homogenizing" (spoofing) services will win. Trackers
| that offer a widget you can install on your server will win.
| Facebook et all will still know where they sent you, and will be
| able to track you server side. If mozilla provide a centralized
| whitelist, then SSO providers who also provide trackers will win.
| Essentially, the big players will find a way, the little players
| (who users weren't worried about anyway) will still lose.
|
| - The web will break. SSO will be broken for a good couple of
| months on over 50% of websites using it - possibly more. "This
| only works in Google Chrome" will become more and more popular.
| Potentially, Firefox doesn't have the market share to make this
| work.
|
| Those of us who will stick with Firefox regardless are in for a
| world of pain, and not a lot of gain. I guess it's necessary to
| move the web on, but the pessimist in me doesn't see that
| happening any time soon.
| ThePhysicist wrote:
| SSO really doesn't need cookies to function, you can e.g. pass
| short-lived authentication tokens via URL hash fragments, that
| is already supported by OAuth 2.0 via the implicit grant flow
| (and for API-based flows it's not a problem).
| twodave wrote:
| IMO this and referrer URL are the only information that ought
| to be able to be shared between two different domains via the
| browser. Either put it in the query string so the user can be
| aware of it or leave it alone.
|
| Of course, there are downsides. Query string character limits
| constrain what can currently be passed (some would say a it's
| good thing in this context), and browsers are headed more and
| more towards showing only the domain in the address bar by
| default.
|
| The other remaining problem would be tracking via XHR. The
| only mechanism for limiting which servers an XHR request can
| talk to currently is CORS, and that config is controlled by
| the server, not the user.
| the8472 wrote:
| > SSO will be broken for a good couple of months
|
| OpenID Connect should continue to work just fine. It's redirect
| based so 3rd-party cookies don't apply.
|
| But I can see HTTP-based redirects being used for tracking on
| every page load (so much for SPAs, heh). Techcrunch already
| does that.
| ulucs wrote:
| Nothing that ultimate bypass/redirector can't solve, assuming
| the target url is somewhere in the GET data
| CuriousSkeptic wrote:
| OIDC in an 3rd-party iframe breaks with SameSite
| ignoramous wrote:
| > _...the little players (who users weren 't worried about
| anyway) will still lose._
|
| The little players not having data is a win in my eyes, because
| those are more likely to get breached or sell data to the
| highest bidder.
|
| > _This only works in Google Chrome_
|
| Regardless of Firefox abiding by the standards (or doing what
| Chrome does) or not, this was _always_ going to be the case,
| and so it isn 't that big a deal.
|
| > _Trackers that offer a widget you can install on your server
| will win._
|
| This is already a thing thanks to the popularity of content
| blockers like Pi-Hole and uBlockOrigin. Firefox's move here is
| another nail in the coffin for third-party tracking through
| third-party servers. At least, first-party tracking with third-
| party "widgets" means first-party would need to shell out the
| cost of running that infrastructure.
|
| > _The web will break._
|
| The web always has been :)
|
| > _Those of us who will stick with Firefox regardless are in
| for a world of pain, and not a lot of gain._
|
| For me, Firefox seems to be making decisions with user's
| security and privacy in mind, and I see that as a net positive.
| As a long time user, it is the _only_ reason I use Firefox.
| jerf wrote:
| "Regardless of Firefox abiding by the standards (or doing
| what Chrome does) or not, this was always going to be the
| case, and so it isn't that big a deal."
|
| The "dealedness" of this isn't a binary. One may tolerate a
| small amount while rejecting a large amount.
|
| I point this out more to put the idea out there (it's an
| important concept even in your day-to-day job) than because I
| disagree with the main thrust being made here; as a uMatrix
| use I traded security for a functional web a long time ago.
| Breaking trackers is a feature, not a bug, for me. If that
| breaks your website, goodbye.
| undecisive wrote:
| I agree with pretty much everything you've said :)
|
| I guess my gripe is more "Why does the world not work right"
| than "Firefox has done a stinker here".
|
| And I suppose my reaction really should be "How can we work
| to give Firefox a leg up, while still encouraging it to
| intentionally fail many of the metrics most people care
| about".
|
| It's a hard battle to fight. Don't suppose Google will
| implement these things that might hurt their user tracking
| businesses... yeah?... no?... no.
|
| > thanks to the popularity of content blockers like Pi-Hole
| and uBlockOrigin
|
| Unfortunately these are "block these please" which hurts all
| the big players for the tiny portion of web users that use
| them. Every time I've ever moved a feature in software I've
| written from "all except this" to "none except this", it has
| always failed spectacularly, at least for a few people. The
| fact that users will get an option to unblock the services
| they need is encouraging... the fact that they mention that
| users might see the dialog multiple times for the same
| service is not.
|
| But yes, I will try to be hopeful - and you are right, the
| fact that Firefox does this kind of thing is a big part of
| the reason I use them in the first place.
| hctaw wrote:
| > Regardless of Firefox abiding by the standards (or doing
| what Chrome does) or not, this was always going to be the
| case, and so it isn't that big a deal.
|
| It's a huge deal to me as a Firefox user. This is a total
| anecdote, but the number of websites and apps that are broken
| in Firefox seem to be on the rise. I try to report bugs when
| I can but the task is Sisyphean.
|
| If Firefox is increasing the friction between web developers
| and the browser while chrome is lowering it, the problem will
| only get worse.
| freeopinion wrote:
| I remember a time when Firefox didn't work for anything
| that required ActiveX.
|
| I remember when Firefox didn't support Flash without a
| seriously dangerous plugin.
|
| I remember when somehow enough people woke up and banded
| against ActiveX and Flash.
|
| It seems popular here to make the argument that "doing
| what's right" poses an existential threat to the right-
| doer. The corollary to that argument is that in order to
| survive you must do what is wrong.
|
| For some, it is better to die than to go along with what is
| wrong. Luckily, it often works out that those who have the
| courage to do the right thing survive. And when they do the
| world is often a better place.
|
| Don't cave into the naysayers who predict the end of the
| world. Keep fighting the good fight.
|
| "And herein do I exercise myself, to have always a
| conscience void of offence toward God, and toward men."
| picks_at_nits wrote:
| +1
|
| Your handle "freeopinion" reminds me that although people
| often say "you get what you pay for," just because
| something's free does not mean that it's worthless.
| hctaw wrote:
| Cool story, I still have to use Chrome to talk to my
| doctor, view my healthcare documents, and get my W2.
| While Firefox is "doing the right thing," me, the Firefox
| user, has to use a different browser that doesn't respect
| my privacy because they don't do what web developers
| expect.
|
| And you can blame web developers, businesses who hire
| them, or Google for turning the world into this sorry
| state. But oftentimes the only choice I have as a
| consumer is what browser I use, and most of the time it's
| Firefox. But more and more frequently, I can't choose to
| use Firefox because some functionality is broken on a
| website I need to visit.
|
| The more of this functionality that they break, the more
| often I need to use Chrome.
| freeopinion wrote:
| Your claims are suspicious. A company cannot require you
| to have internet access to supply you a W-2 tax form. You
| choose to keep your healthcare documents in some format
| that requires Chrome? That seems very very strange. Your
| doctor won't talk to you in person or on the telephone?
| Again, strange.
|
| You are not forced into any of these things. You choose
| them as a matter of convenience, cost-savings, or some
| other reason. You have your reasons, but it is highly
| unlikely that you don't have a choice.
|
| The choices you have purportedly made have allowed others
| to make poor choices with little consequence. With less
| effort than it took to install Chrome, you could have
| asked for a paper copy of your W-2. That would have put
| the pain of a bad decision back upstream where it
| belongs.
|
| > The more of this functionality that they break, the
| more often I need to use Chrome
|
| From context, "they" would refer to the party that breaks
| functionality. From the sentence above, I take that to be
| "Google for turning the world into a sorry state." Your
| response to this is to "need to use Chrome." Your choices
| seem irrational to me.
|
| But again, they are your choices and you do have them.
| jsjohnst wrote:
| > The little players not having data is a win in my eyes,
| because those are more likely to get breached or sell data to
| the highest bidder.
|
| I somewhat agree with everything but the above. I've looked
| at data on thousands of breaches and have found that size of
| organization isn't really correlated with "having better
| security".
| horsawlarway wrote:
| I'm having exactly the opposite thought.
|
| As a developer, shit like "Automatic unpartitioning through
| heuristics" alone is enough that I won't touch this. Full
| stop.
|
| Firefox is now breaking the contract I expected it to fulfill
| as the user's agent, and it's doing it fucking at random.
|
| I happen to live in a space where I do need cross site
| support (both for cookies and requests) and frankly, between
| Google's push for SameSite, and now Firefox's selectively
| breaking the cookie jar, I'm pissed.
|
| I'm a bit boggled that we haven't settled on a decent
| solution to let a site declare how it wants to interact with
| other sites.
|
| This already fucking exists for mobile too, both Android and
| iOS support an opt-in manifest declared at a /.well-known/
| path on the origin in question, why the fuck are the browser
| vendors so DEAD SET on removing control from the sites
| themselves in favor of these rushed, half assed, shoddy
| solutions.
|
| Let me declare the sites I want to allow to share my
| resources. Let me do it at a known location, with a standard
| manifest, with finer grain control than "Random fucking
| heuristic" and "strict/lax/none".
| xnzakg wrote:
| I feel like the entire purpose of this is to take the
| control from the sites and give it to the users. The site
| owners obviously do want the cookies to be shared with
| trackers if they embed them.
| horsawlarway wrote:
| I don't mind at all if Firefox wanted to propose a
| standard way to declare cross site sharing, and then
| allows the user to overrule my settings as a dev (or even
| if they pick more restrictive defaults, if user opt in is
| a problem).
|
| There's a standard in place, so arbitrary exceptions and
| heuristics don't create incredible headaches, and there's
| a clear path to resolving the issue in support/triage
| with the customer if they create a rule that does
| actually break my site's functionality.
|
| I do mind, quite a bit, when Firefox essentially goes
| "Fuck the standards", and starts playing fast and loose
| with the rules. And I mind for two reasons
|
| 1. I expect better from them. I'm old enough to remember
| how much steam Firefox picked up from IE by just treating
| a standard as a standard. It was novel, and transformed
| front-end development in a great way.
|
| 2. They are not the market leader, and non-standard, site
| breaking bullshit only does more to sink their ship, and
| I desperately want a competitor in the browser ecosystem
| that is not Google Chrome (or a rebranded chromium port).
| lutoma wrote:
| Isn't that pretty much exactly what this accomplishes? It
| means sites first have to request your permission in a
| popup.
|
| I thought the article made it pretty clear that the
| heuristics are only intended as a temporary stop-gap
| measure to prevent every current SSO service from breaking.
| horsawlarway wrote:
| > I thought the article made it pretty clear that the
| heuristics are only intended as a temporary stop-gap
| measure to prevent every current SSO service from
| breaking.
|
| That sentence alone is mind boggling - Hey, Mozilla is
| breaking every standard that previously allowed cross
| domain authentication, or 3rd party authentication
| services, but don't worry, it's only temporary... until
| what exactly?
|
| Either every site under the sun is suddenly asking the
| user to accept unpartitioning because critical features
| are broken and a user literally has to click yes to
| continue, in which case all you're doing is training
| users to always click yes (EU cookie popups, take two,
| lovely...)
|
| Or users move away from Firefox because sites are just
| broken.
|
| They don't even have a long term solution for how SSO
| services are expected to work here, other than "use this
| other API that happens to cause the behavior as a side
| effect, and oh, btw, the global market leader (chrome)
| doesn't support it yet! Enjoy!"
|
| Where the fuck is my RFC. Where is real planning I'd
| expect from a from the company that I only know the name
| of because they _actually_ gave a shit about standards
| when IE was doing this kind of crap left and right?
|
| I like Firefox precisely because they normally don't do
| this bullshit (and their standards based docs on MDN are
| literally some of the best around).
|
| ---
|
| My take is that this is essentially security advertising
| and social signaling, and is another death blow to
| Firefox from Mozilla trying to push privacy focused paid
| services.
| thayne wrote:
| > For me, Firefox seems to be making decisions with user's
| security and privacy in mind, and I see that as a net
| positive. As a long time user, it is the only reason I use
| Firefox.
|
| I agree that that is a good thing. However, the more firefox
| breaks compatibility with sites people use, the harder it
| will be to regain marketshare. And if Firefox keeps losing
| marketshare it will have less ability to influence web
| standards, and could potentially die altogether, which would
| be bad for privacy and security in the long run.
|
| Fortunately, state partitioning isn't enabled by default on
| Firefox yet (it is part of "strict" ETP), so only people who
| are ok with it potentially breaking sites will turn it on.
| sdeframond wrote:
| > Firefox doesn't have the market share to make this work.
|
| Potentially indeed. On the other hand it will give FF
| evangelists one more selling point.
|
| "Why should I switch to Firefox?" - "Because it lets you chose
| who is tracking you and who is not."
| laurent92 wrote:
| It's a difficult argument, depleted of its true meaning by
| its overuse in VPN ads (which make it... easier to track you
| at the VPN level). But Firefox has a good enough corporate
| image to tell that _they_ are the ones who really do it.
| baybal2 wrote:
| Mozilla went chasing Chrome, and lost almost all of its market
| share.
|
| Chasing Chrome was a bad decision. When they realised it was,
| they should've corrected the mistake, but instead Baker doubled
| down on the wrong direction, breaking all fiduciary duties she
| has as a CEO of non-profit in the process.
| jamespo wrote:
| If you're referring to XUL extensions being given the elbow,
| the small proportion of users using those does not correspond
| to Firefox market share loss.
| Karunamon wrote:
| That's not Mozilla's only or most significant misstep.
|
| CEO drama, Hello, Pocket, UI indecisiveness, repeated
| feature removal over objections, breaking everyone's addons
| first with the XULening then with the addon cert fiasco,
| opt-out telemetry, force-pushing addons without affirmative
| consent, opt-out advertising, buying into scummy tracking
| outfits like cliqz (and trying to hide it), poor
| prioritization, lack of focus..
|
| If there's ever a choice between giving the user more
| control and transparency or taking it away, Mozilla seems
| to take the latter option.
| coldpie wrote:
| Outside of HN, no one I've ever talked to has mentioned
| any of those as reasons for using Chrome. The two most
| common reasons I've heard are "dunno" followed distantly
| by "I use ten hundred thousand million tabs and Firefox
| crashed on me once fifteen years ago."
|
| I suspect the rise of mobile browsing, with Chrome as the
| default, plus users' Google account having strong
| integration with Chrome--not to mention Google pushing
| Chrome across all of their properties--have a lot more to
| do with Chrome's popularity than a button on Firefox's
| toolbar that you don't like.
| Karunamon wrote:
| Maybe, but evangelization is a significant source of
| market share. That's what led to FF eclipsing IE back in
| the browser dark ages.
|
| *response to stealth edit:
|
| I listed 13 separate problems with Mozilla, I'd thank you
| to respond to what I actually wrote, not a caricature you
| cooked up.
| coldpie wrote:
| Fair cop. That was lazy of me and I apologize.
| jacquesm wrote:
| Mozilla still hasn't figured out that they are synonymous
| with Firefox and until that happens you can expect the
| marketshare to further deplete. Meanwhile, Chrome gain
| little by little until Mozilla will be utterly
| irrelevant, which is a huge pity because we _really_ need
| an independent browser.
|
| I'm still writing this using Firefox but Chrome is now
| also running all the time on this machine because of one
| of my private projects which requires web midi (and
| which, according to Mozilla can not be implemented
| safely, though Chrome is existence proof that this is
| nonsense).
| IggleSniggle wrote:
| Wow, I had actually forgotten about a ton of this stuff,
| shines a different light on how hard it's been working to
| gain trust and be the "privacy browser" in recent years.
| _pmf_ wrote:
| Layering leaky abstractions over leaky abstractions and calling
| it security is what the web has turned into. All the while
| introducing new side channels and attack vectors like WebGL
| that allow completely covert access via unknown access paths in
| GPU driver binary blobs.
|
| It's unfixable.
| jannes wrote:
| > The web will break.
|
| I have been using the First-Party Isolation feature for a few
| months now. FPI (privacy.firstparty.isolate) is a flag that was
| originally created for the Tor Browser project. It's a strict
| version of State Partitioning without any way to unpartition
| (no permission dialogs, no heuristics).
|
| So far I have only come across one broken website: Microsoft
| Teams login through Okta SSO.
|
| The rest of my logins worked flawlessly with FPI turned on.
| Nothing close to the 50% that you mention.
| egeozcan wrote:
| I don't understand why the SSO would be broken. AFAICT, I'd
| just need to re-login to the SSO-provider (Okta in this case)
| in the context of the initiator (Microsoft Teams, in this
| case). They'd otherwise need to be doing something silly if
| it stops working.
| hirsin wrote:
| Teams relies on iframe auth to fetch the Nth token from AAD
| (multiple resources to call, multiple tokens required). The
| iframe calls are partitioned and lose cookies, even under
| Firefox's helpful "redirect exemption" setup, it's not
| clear why.
| undecisive wrote:
| That's encouraging news. Do you use a lot of sites with SSO?
| Are they mostly mainstream (where I would class MS Teams to
| fall in that bracket) or do they tend to be more niche
| services?
|
| (I totally accept that my "50% of SSO systems will be broken
| by this" to be a worst-case random number i-have-no-idea-but-
| for-all-I-know value. Probably shouldn't have been so blase
| about it! But very much interested to hear what real-world
| values look like)
| not2b wrote:
| Okta SSO is used heavily inside my company to access
| internal sites, but if there's a way to whitelist, or the
| user sees a popup the first time and allows Okta cookies
| after that, this problem is taken care of.
| kuu wrote:
| > Facebook et all will still know where they sent you, and will
| be able to track you server side
|
| This is not a problem a browser can fix
| eevilspock wrote:
| California should split into at least 4 states ;)
| GiftCard2021 wrote:
| 7 Most Common Birds That You Can Find In Singapore
| http://bit.ly/3shBg7U
| timwis wrote:
| This seems brilliant! But the solution for SSO concerns me, given
| most SSO providers (Google, Facebook) are among the main ones
| partitioning aims to stop from tracking you. By giving Google SSO
| unpartitioned access, doesn't that also let google track you
| anywhere?
| ambentzen wrote:
| My understanding is that if you use Google SSO from xyz.com
| Google can track you only there and not abc.com. So the
| partition is only lifted for a single domain.
| intrasight wrote:
| From the title, I thought perhaps the article was about FINALLY
| partitioning California into two states ;)
| ThePhysicist wrote:
| I think what you want is essentially an entirely fresh browser
| session for every website you visit. Pretty mind-boggling to what
| lengths we need to go in order to prevent companies from tracking
| us. That said most tracking companies seem to have devised
| strategies to construct fingerprints from data like IP addresses,
| user-agent strings and any other meta-data they can get their
| hands on, so the next step will probably be to restrict what kind
| of information can be learned about the browser environment via
| JS (e.g. getting exact screen resolution).
|
| Also, data exfiltration via browser extensions is still not a
| solved problem, there are very popular extensions (Ghostery for
| example) that are highly privileged in the browser and often
| collect a ridiculous amount of data. Really can't get my head
| around why browser vendors still allow that while being so strict
| on all other forms of tracking.
| iainmerrick wrote:
| I use "private tabs" exclusively on my phone now, and it works
| great with not too many downsides.
|
| On HN, I can browse just fine; when I want to vote or comment,
| logging in only takes a few seconds.
|
| News sites either just work, work with some nagging that you
| have to click through, or hit paywalls and other dead ends. I'm
| happy to stick with the sites that work and spend less time on
| the more annoying ones.
|
| _Edit to add:_ I realise I'm still being tracked, but at least
| I'm making a best effort to limit it. So the idea of a
| completely siloed browsing session per site sounds great to me.
| TedDoesntTalk wrote:
| > Ghostery for example
|
| What data is Ghostery collecting?
| ThePhysicist wrote:
| https://www.ghostery.com/about-ghostery/ghostery-plans-
| and-p...
| mckirk wrote:
| There's the awesome 'Containerise'[1] add-on for Firefox that
| lets you define containers for specific sites based on URL
| filter expressions. Pretty handy to e.g. keep Google cookies in
| their own Google container.
|
| (The only downside I've found is that, if you navigate from
| Google directly to a site belonging to a different container,
| the tab will forget its history and you won't be able to go
| back to the Google results using the Back button. You just need
| to remember to open results in a new tab instead.)
|
| Using 'Cookie Quick Manager'[2] you can also move your existing
| cookies for some domain to their new container, so you don't
| have to re-login everywhere after creating your new custom
| containers.
|
| [1]: https://addons.mozilla.org/en-
| US/firefox/addon/containerise/
|
| [2]: https://addons.mozilla.org/en-US/firefox/addon/cookie-
| quick-...
| jsjohnst wrote:
| > You just need to remember to open results in a new tab
| instead
|
| Google[0] and DDG[1] both have user settings which allow you
| to open results in a new tab by default.
|
| Sources are first results which appeared accurate:
|
| [0] https://www.askdavetaylor.com/how-to-have-google-bing-
| search...
|
| [1] https://ccm.net/faq/40410-duckduckgo-open-results-in-new-
| win...
| imhoguy wrote:
| Good luck solving Google's reCAPTCHA, it is nightmare if you
| have no tracking history. I think currently FF Containers is a
| best way in UX terms to isolate stuff.
|
| I agree with you that web extensions is still a grey area, pity
| they can't be configured per container.
| foolinaround wrote:
| Can privacy focussed browsers that extend Chrome ( Brave,
| Vivaldi, etc) provide something similar to this, or is it baked
| deep within Chrome internals, and cannot be overriden?
| miedpo wrote:
| Brave already does this as far as I know (cross-site cookies
| are blocked by default). Don't know about Vivaldi, but I would
| not be surprised if they do.
| the8472 wrote:
| How long until someone will do side-channel attacks on cookie
| stores for tracking purposes?
| Ayesh wrote:
| You can't. The permission is granted per embedded domain per
| top domain.
___________________________________________________________________
(page generated 2021-02-24 23:01 UTC)