Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add mitigation strategy for focuseable elements #206

Closed
wants to merge 1 commit into from

Conversation

alexshalamov
Copy link

@alexshalamov alexshalamov commented May 19, 2017

Fixes #189


Preview | Diff

@alexshalamov
Copy link
Author

I don't have rights to push to #190 @anssiko @tobie @rwaldron please take a look. Thanks.

@anssiko
Copy link
Member

anssiko commented May 22, 2017

Thanks, LGTM. @tobie, can you review?

tobie added a commit to tobie/sensors that referenced this pull request May 23, 2017
This mitigates both nested browsing context and
other top-level browsing contexts gaining focus
while a top-level browsing context from a different origin
is collecting sensor readings by preventing the latter
to do so.

Fixes w3c#189.
Closes w3c#206.
Copy link
Member

@tobie tobie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I think we want to make this mandatory like page visibility and also handle cases when focus is lost to another top-level browsing context. I originally planned to just do a quick writeup of what I had in mind and paste here (as I don't think I'm able to push to your branch). In doing so, I realized I had to rewrite the prose around sensor task source (turning it into an algorithm) and by the time I was done, it was a full blown diff: tobie@a9050bf. I think the best solution is for me to submit it as a separate PR at this point.


User agents may choose to keep the user informed
about current and past use of the API.

Note: this does not imply keeping a log of the actual [=sensor readings=]
which would have issues of its own.

<h4 id="focuseable-areas">Focuseable areas</h4>

When [=currently focused area=]'s associated [=browsing context=] is [=nested browsing context=],
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you need to formalize that a bit more like so:

When the [=currently focused area=] of the current [=top-level browsing context=]
is a [=nested browsing context=] whose [=active document=]'s [=origin=]
is not [=same origin-domain=] with the [=origin=] of the [=top-level browsing context=]'s [=active document=],
then […]

tobie added a commit to tobie/sensors that referenced this pull request May 30, 2017
This mitigates both nested browsing context and
other top-level browsing contexts gaining focus
while a top-level browsing context from a different origin
is collecting sensor readings by preventing the latter
to do so.

Fixes w3c#189.
Closes w3c#206.
@tobie tobie closed this in #213 May 30, 2017
tobie added a commit that referenced this pull request May 30, 2017
Refactor existing task source-based security mechanism into
security check algorithm.

Fixes #189.
Closes #206.
Closes #222.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants