search

w3c / web-nfc

Web NFC
https://w3c.github.io/web-nfc/
Other
311 stars 68 forks source link

Define "sub-domain match" #33

Closed jyasskin closed 9 years ago

jyasskin commented 9 years ago

Ideally just by reference to an existing algorithm in another web standard.

Alternatively, consider just requiring that the origins be equal. The web is moving away from use of sub-domains for security.

annevk commented 9 years ago

Yeah, if we're going to do eTLDs here that would need to be justified somehow.

zolkis commented 9 years ago

As a default, we could write the origin of the page browsing context using the API, for instance https://mydomain/mypage. To make it a bit more useful, we said the page could write any sub-domain match of its own origin, to differentiate between different writes, for instance https://mydomain/mypage/mygame1. This is more generic than the algorithm for same origin.

annevk commented 9 years ago

I think you need to read up on "subdomain", "origin", and "path". (Also, a browsing context doesn't have an origin, its active document does.)

kenchris commented 9 years ago

@zolkis don't you mean 'more specialized path'? A subdomain would be something like hangouts.google.com (a subdomain of google.com)

zolkis commented 9 years ago

The example above was screwed, but IMO both would qualify for the NFC use cases I described. It is up to us to decide.

kenchris commented 9 years ago

Can't we say that the url needs to have a path relative to the base url? (or would that allow ../other path)

jyasskin commented 9 years ago

Don't implement security restrictions based on paths. The origin is the fundamental concept of web security, so that's what your restrictions should be based on.

Anne's point about using the incumbent settings object is good. It has an origin.

kenchris commented 9 years ago

but what about services having different projects under the same domain?

I know github uses subdomains for that, so maybe it is not a problem

jyasskin commented 9 years ago

They're not secure against each other. For a very few things (maxScopeString in ServiceWorkers) there's some attempt to let servers segregate paths, but that's only when the impact from cross-path attacks is big (persistently overwriting the other path's contents, for SWs). In NFC, the impact is small (reading another path's data), and could also be accomplished with any of the other storage APIs, so it's not worth worrying about.

zolkis commented 9 years ago

This became obsolete.