Re:uBlock Origin: Address first-party tracker blocking
by EvanAnderson on Wednesday November 20, 2019 @01:26PM
(#21586780)
You can be certain that, when this does happen, these considerations will be dealt with. I feel very strongly that this is going to happen. The chance to execute arbitrary code on clients will be too alluring for adtech companies to ignore.
[ Parent
| on HN ]
Re:uBlock Origin: Address first-party tracker blocking
by folkrav on Thursday November 21, 2019 @12:26AM
(#21591678)
"Dealing with it" basically means re-building a browser rendering engine inside the browser renderer.
Re:uBlock Origin: Address first-party tracker blocking
by naniwaduni on Thursday November 21, 2019 @02:16AM
(#21592053)
You don't need to build a browser rendering engine, with everything that entails; you only need to render your content. This is a much easier problem.
Re:uBlock Origin: Address first-party tracker blocking
by folkrav on Monday November 25, 2019 @10:26AM
(#21628879)
For accessibility compliance, you _need_ text and a DOM. Screen readers rely on HTML element semantics, ARIA attributes, and text content. The only way to make a canvas element (which is what you'd typically need to render custom UI) accessible is to have a textual fallback.
Outside accessibility there's also the issue of responsive design, huge SEO impacts, rendering performance... I'm probably missing a bunch.
Lifting a sedan with my bare hands is obviously easier than lifting a 10 wheeler, but it's still a massive problem. Rendering stuff is not the biggest issue.
Re:uBlock Origin: Address first-party tracker blocking
by EvanAnderson on Monday November 25, 2019 @07:39PM
(#21634529)
Embed a browser with all that stuff into a page. Whatever APIs are missing to make the "inner browser" unable to fulfill all the requirements that the "outer browser" will eventually be filled-in by well-meaning developers who want the Javascript VM in the "outer browser" to be able to host general purpose applications.