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

How can users prevent user-hostile frame pausing? #14

Open
bzbarsky opened this issue Sep 16, 2017 · 9 comments
Open

How can users prevent user-hostile frame pausing? #14

bzbarsky opened this issue Sep 16, 2017 · 9 comments

Comments

@bzbarsky
Copy link

bzbarsky commented Sep 16, 2017

Consider a site which as an "anti-copying" feature puts all its content into a frame that it then pauses. It allows scrolling the parent document of that frame. Per the letter of the explainer, this means the user cannot select text in the subframe. Can the user even bring up a context menu for things in the frame? What about other sorts of interaction?

@jkarlin
Copy link
Owner

jkarlin commented Nov 2, 2017

These sorts of anti-copying features have long existed (e.g., hijacking mouse and keyboard events). Does this add anything new?

@bzbarsky
Copy link
Author

bzbarsky commented Nov 2, 2017

Yes, it does. UAs have user overrides for the existing user-hostile things and extensions that allow bypassing them, and those overrides can be done in a way that is not exposed to web pages in any way. But overriding pausing has all sorts of observable effects by the web page, because its scripts run when they "shouldn't".

@jkarlin
Copy link
Owner

jkarlin commented Nov 2, 2017

Presumably that's unspecced UA intervention? It's hard to maintain compatibility with unspecced UA features.

@bzbarsky
Copy link
Author

bzbarsky commented Nov 2, 2017

The point of "UA interventions" is that we realize a spec we had is bad and willfully violate it for the benefit of users.

Designing a new spec with the assumption that UAs will just come up with interventions to work around problems in it is not desirable, especially when the interventions will be easy to detect by sites.

@jkarlin
Copy link
Owner

jkarlin commented Nov 2, 2017

My point was that the interventions themselves should be added to the spec. Designing a spec that doesn't interfere with undocumented interventions is rather challenging.

I don't see why we wouldn't want the frame to know that it was unpaused.

@bzbarsky
Copy link
Author

bzbarsky commented Nov 2, 2017

My point was that the interventions themselves should be added to the spec.

Yes, that is my point too. Good, we're in violent agreement. ;)

I don't see why we wouldn't want the frame to know that it was unpaused.

Well, one simple problem is frames that remove themselves from the DOM if unexpectedly unpaused, to hide their stuff...

@bzbarsky
Copy link
Author

bzbarsky commented Nov 2, 2017

Maybe we're ok with that, of course. It just needs a conscious decision.

@jkarlin
Copy link
Owner

jkarlin commented Nov 2, 2017

I think it's totally fair for a page to hide its stuff.

@bzbarsky
Copy link
Author

bzbarsky commented Nov 2, 2017

It really depends on the page.

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

No branches or pull requests

2 participants