Re:Ask HN: Is there a justification for a Facebook browser e...
by db48x on Friday February 01, 2019 @02:18PM
(#19057476)
Maybe, but it would be entirely dependent on the good will of Facebook, and you would gave to continuously react to the whims of Facebook's engineering dept as they change their website. Neither of those are going to be acceptable in the long term.
[ Parent
| on HN ]
Re:Ask HN: Is there a justification for a Facebook browser e...
by smt88 on Friday February 01, 2019 @03:39PM
(#19058335)
FB intentionally obfuscates their HTML classes and IDs to make it harder to scrape or to build browser extensions on top of their site. It's almost impossible to keep up these days.
Re:Ask HN: Is there a justification for a Facebook browser e...
by stratenjine on Friday February 01, 2019 @04:10PM
(#19058644)
They do obfuscate, but they still have to follow basic markup rules and can't beat css selectors.
Keeping up with Facebook changes does not even require releasing new versions, as updated regex(-ish) selectors can be downloaded.
I think it's a (theoretically) losing battle to rely on such obfuscation.
Re:Ask HN: Is there a justification for a Facebook browser e...
by db48x on Saturday February 02, 2019 @01:26AM
(#19061490)
I don't work at Facebook, but I don't think that's intended primarily as an obfuscation step. Instead it's a _compilation_ step. It ensures that css rules for widget X can't accidentally apply to and therefore break break widget Y.
But yes, it is effectively obfuscated, and it would be foolish to try to reverse-engineer it every time the identifiers change, since they're effectively random.
Re:Ask HN: Is there a justification for a Facebook browser e...
by stratenjine on Saturday February 02, 2019 @03:51AM
(#19061955)
Actually, I've built a side project/POC, to check if the concept works, 6 months ago.
Recently I picked it up and continued. Selectors still valid.
Just sayin :)