Paint timing test for :visited attacks |
||
Issue descriptionQuoting tdresser@ from email thread to make sure I come back to this: "We dodge :visited attacks today, but I'm worried that at some point in the future, someone is going to optimize out the swap when we paint white text on a white background, which would enable a :visited attack. Does it make sense to have a test for this case? Something I find pretty odd - if you have an element with alpha of 0, we don't swap to paint it. If you have an element of color rgba(0, 0, 0, 0), we do. If you could prevent something from swapping by changing its color, we'd have a :visited attack. I can imagine other browsers having different behavior than we do here." "Start with page with a single link on it, and an observer waiting to see FP. Give the link a :visited style which is transparent. If we receive FCP, it means the link wasn't visited, as we didn't swap because the link was transparent. If you want to avoid having a completely blank page, you can start loading content after FP, and after some timeout."
,
Oct 5 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/bad662e4f0711b9924d959b35794cd47dea39507 commit bad662e4f0711b9924d959b35794cd47dea39507 Author: Nicolas Pena <npm@chromium.org> Date: Thu Oct 05 00:40:25 2017 Paint-timing test for visited attack Bug: chromium:764851 Change-Id: I10fbb98f9e18e013ce4ad8a7ae5f0a74c585d114 Reviewed-on: https://chromium-review.googlesource.com/688385 Commit-Queue: Nicolás Peña Moreno <npm@chromium.org> Reviewed-by: Timothy Dresser <tdresser@chromium.org> Cr-Commit-Position: refs/heads/master@{#506587} [add] https://crrev.com/bad662e4f0711b9924d959b35794cd47dea39507/third_party/WebKit/LayoutTests/external/wpt/paint-timing/paint-visited.html
,
Oct 5 2017
|
||
►
Sign in to add a comment |
||
Comment 1 by npm@chromium.org
, Sep 28 2017