On Apr 10, 2012, at 9:07 PM, Jonas Sicking wrote: > On Tue, Apr 10, 2012 at 4:59 PM, Lucas Adamski <[email protected]> wrote: >> >> == Regular web content (unauthenticated) == >> Use cases for unauthenticated code: Prevent screen orientation from changing >> when playing a game utilizing device motion > > I'd also add: Switch screen orientation when switching between > different parts of an app. For example when switching from UI to > browse lists of videos, to UI which plays a specific video. Or > switching orientation between people facing one another playing a game > on the device.
Ah ok, so the ability of the app to specify a specific orientation. >> Authorization model for normal content: implicit for detecting orientation, >> explicit runtime for locking orientation > > I'm not sure what "explicit runtime for locking" entails here. I don't > think we want an explicit prompt when the page requests that the > orientation be locked in a particular direction. Basically it seems to > me that prompting the user for something as "trivial" as screen > orientation (which you can basically do by simply rendering your text > sideways anyway) would just lead to "prompt fatigue" with users. I think I had confused orientation of the content with orientation of its container/app. Disregard, I agree that it doesn't need any explicit authorization. > >> Potential mitigations: Orientation should remained locked only while focused. > > I think we might need more than that, especially since I'd prefer to > not have an explicit ask-for-permission prompt for screen locks, even > for uninstalled apps. What I propose is this: > > 1. Orientation locks only affect the locked app/page. If the user > switches tab or app, the other pages aren't affected. > 2. If the page is installed content, always allow the orientation lock. > 3. If the page is in fullscreen mode, always allow the orientation > lock. There is no browser UI being displayed anyway and so the page > could cause the same behavior by simply rendering text sideways. Need > to verify that this will work on mobile. > 4. If the page isn't in fullscreen mode, and is contained in an > <iframe> (or <frame>) never allow the lock request. > 4. If the call to lock the screen orientation happens in response to a > user action, always allow the orientation lock. > 5. If the call to lock the screen orientation doesn't actually require > the screen to be immediately re-orientated, always allow the > orientation lock. > 6. If no other calls to change the lock orientation has happened in > the last X (say 5) seconds, allow the orientation lock. This is mostly > to cover the case of the page setting its lock during initial page > setup. > > We could potentially skip rule 5 since it doesn't actually solve any > real problems, and might just be confusing to developers. The other > rules should be enough to allow all sanely written code to "just > work". I'm having a hard time keeping this all in my brain. :) If I were to condense this into a set of simpler rules would it still meet the behavior as described above? a) Orientation locks only affect the locked app/page. If the user switches tab or app, the other pages aren't affected. b) Only top level or full-screen content can set the lock You have two #4s in that list, so regarding #4b I'm not sure why we need a special exception to user initiated locks if they are generally permitted. Is that just for iframes or frames? Same for 5 or 6 I guess. Fundamentally if this lock only affects the content requesting the lock, then I agree there's no reason to restrict its behavior (content can always choose to annoy the user). One thing that doesn't seem to have been discussed is whether a change to the top-level orientation also changes the orientation for embedded iframes and other content? > >> == Trusted (authenticated by publisher) == >> == Certified (vouched for by trusted 3rd party) == > > For the sake of simplicity for page authors, I think I would prefer to > keep these two the same as the unauthenticated. I agree that we could > relax constraints here, but I think that would cause more confusion > than it would add value. And for now these two groups consist of > installed content only, which basically means full rights to the API. Makes sense (modulo finalizing discussion above). Lucas. _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
