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

Security #16

Closed
rdeltour opened this issue Jan 29, 2016 · 5 comments
Closed

Security #16

rdeltour opened this issue Jan 29, 2016 · 5 comments

Comments

@rdeltour
Copy link
Member

The wiki has no use cases on security. We must identify what is specific to PWP.

@hlflanagan
Copy link
Contributor

How about:
Alice is working on potentially Nobel prize winning research, and has
drafted her paper describing her discoveries. She asks Bob to review the
paper, but needs to make sure that the PWP retains specific protections,
regardless of whether it is read online or offline.

Requirement: A PWP must allow for access control and write protections as part of the resource.

@iherman
Copy link
Member

iherman commented May 19, 2016

+1 to me

@TzviyaSiegman
Copy link
Contributor

+1

@baldurbjarnason
Copy link

Technically the use case @hlflanagan outlines isn't a security use case but an access control use case. The two (access versus security) are intertwined but separate. The web analogy would be HTTP authentication versus HTTPS. Authentication can be utterly insecure (basic auth) but then secured using separate security features (HTTPS, CSP, etc.).

On the server, access control works by mediating user access to resources that are situated on the server. It doesn't try to control access or prevent modification of the file once it's in the user's browser (this is why extensions still work on HTTPS sites and why you can always save the page you have to file).

The distinction between access control and security becomes very important in portable documents because secured access control in a portable document is DRM. You are trying to restrict the use of a file that the user already has.

So that's a massive -1 from me on secured/encrypted access control. Also, this would be an extremely controversial feature. The last time the W3C tried a watered down version of this sort of thing (EME), it lead to people protesting outside their offices.

The only exception is if the access control metadata is just intended to be a hint or suggestion that the user can override. As in, the access control is intentionally made completely and utterly insecure and no hooks included that would allow the feature to be made secure in the future. Something like the user agent MUST allow the user to override and ignore the access control hints and that the user agent MUST NOT use encryption to control the user's access to a portable web publication. In that case I'd be +1. I'm all for usage hints in metadata provided they remain only hints.

(The reason why the use of encryption needs to be explicitly prevented in this context is that many existing anti-circumvention laws have no usable exemptions and pose criminal liabilities for bypassing encryption in this context. Using encryption would turn a lot of regular users into criminals, which is obviously sub-optimal.)

@hlflanagan
Copy link
Contributor

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

5 participants