Fingerprinting via video time information leak
Reported by
s.h.h.n....@gmail.com,
Dec 17 2017
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36 Steps to reproduce the problem: 1. Go to https://webrtc.github.io/samples/src/content/capture/video-video/ 2. hover over the video on the right side and observe the video playing time What is the expected behavior? video playing time should be same as left video. What went wrong? When captureStream() is used to load a video, playing time shows some timing information. I'm not sure that it is, but following is what I observed. 1. Time displayed is just keep increasing (for me, it shows 50 hours something). 2. This information is synced with incognito as well as other build in same PC (Dev, Canary, etc). I'm guessing that this is some OS level information because of 2nd observation. This might be useful for tracking same user who uses incognito and normal mode. This information can be obtained by website. You can type "document.querySelectorAll("video")[1].played.end(0)" on console. I'm hiding this bug because I'm not quite sure what's going on. If this isn't a security issue, feel free to remove restrict view. Did this work before? N/A Chrome version: 63.0.3239.84 Channel: stable OS Version: OS X 10.13.1 Flash Version:
,
Dec 18 2017
Niklas, can you triage this please? Thanks.
,
Dec 18 2017
Repros on Linux, too.
,
Dec 18 2017
And Chrome OS.
,
Dec 18 2017
mcasas@, can you add some context around why this happens in our implementation?
,
Dec 18 2017
I thought this was a duplicate of crbug.com/698468 , but, lo and behold, the latter is no more. My guess is that the VideoFrame timestamp [1] should not be base::TimeTicks::Now() - base::TimeTicks() but something more interesting, like base::TimeTicks::Now() - start_time_ [1] https://cs.chromium.org/chromium/src/content/renderer/media_capture_from_element/html_video_element_capturer_source.cc?q=html+video+element+capture&sq=package:chromium&dr=CSs&l=150
,
Dec 22 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/0369eaa8b964c9d916f1a9e4f8d943c240713360 commit 0369eaa8b964c9d916f1a9e4f8d943c240713360 Author: Miguel Casas <mcasas@chromium.org> Date: Fri Dec 22 01:47:28 2017 HTMLVideoElementCapturerSource: fix timestamp origin HTMLVideoElementCapturerSource produces VideoFrames that have a timestamp == TimeTicks::No(). This CL changes that to start from the moment the capture starts, and adapts the unittests. Bug: 795553 Change-Id: I9e27c8a5d4ae73a5e5f8add5db9359670ac841fb Reviewed-on: https://chromium-review.googlesource.com/840962 Reviewed-by: Daniele Castagna <dcastagna@chromium.org> Commit-Queue: Miguel Casas <mcasas@chromium.org> Cr-Commit-Position: refs/heads/master@{#525886} [modify] https://crrev.com/0369eaa8b964c9d916f1a9e4f8d943c240713360/content/renderer/media_capture_from_element/html_video_element_capturer_source.cc [modify] https://crrev.com/0369eaa8b964c9d916f1a9e4f8d943c240713360/content/renderer/media_capture_from_element/html_video_element_capturer_source.h [modify] https://crrev.com/0369eaa8b964c9d916f1a9e4f8d943c240713360/content/renderer/media_capture_from_element/html_video_element_capturer_source_unittest.cc
,
Dec 22 2017
s.h.h.n.j.k@ could you verify the fix landed in #7 in a Canary containing it? https://storage.googleapis.com/chromium-find-releases-static/index.html#r525886 would tell us the version.
,
Dec 22 2017
My Canary on Mac is keep crashing (because of some other bug) and I can't verify. If it's fixed on your side with my PoC then it should be fine.
,
Dec 23 2017
I can confirm that it's fixed now! |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by elawrence@chromium.org
, Dec 17 2017Labels: -Type-Bug-Security -Restrict-View-SecurityTeam Type-Bug
Status: Untriaged (was: Unconfirmed)
Summary: Fingerprinting via video time information leak (was: Time information leak)