Re: Intent to ship: accept arbitrary webkit-prefixed pseudo-element in selectors
Hi Xidorn, On 9/5/18 3:35 AM, Xidorn Quan wrote: In Firefox 64, I intend to turn accepting arbitrary webkit-prefixed pseudo-element in selectors on by default on all platforms. It has been developed behind "layout.css.unknown-webkit-pseudo-element". WebKit and Blink have had this behavior for long. Thanks for working on this. Happy to have one less cause for busted sites in Firefox. -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Implement: Storage Access API
On Fri, Sep 7, 2018 at 2:49 PM James Graham wrote: > > web-platform-tests: Our implementation unfortunately doesn’t come with > > web-platform-tests, for two reasons. One is that there is currently no > way > > to mock user gestures in web platform tests [4], and the second reason is > > that furthermore, our implementation also depends on being able to > > manipulate the URL Classifier backend for testing purposes. > > So this isn't true, however the present state of affairs may not yet be > useful to you. > > It is currently possible to make basic user actions in wpt using the > testdriver API [1]. I am helping extend this to allow more general > guestures via WebDriver-like actions [2]. > Very cool, I did not know this! It seems like test_driver.bless() is what we need here for simulating a user activation gesture. > However it sounds like in this case you may need to add test-only APIs > for manipulating internal browser state. There are two possible > approaches here: > > * Add a feature to WebDriver for manipulating this data. This can be > specified in the StorageManager spec and is appropriate if we want to > add something that can be used by authors as part of the automated > testing for their website. > > * Add test-only DOM APIs in the StorageManager spec that we can enable > when running the browser in test mode. Each browser would be expected to > have some implementation-specific means to enable these APIs when under > test (e.g. a pref). WebUSB has an example of this approach. > This is something that I should get some feedback on from at least WebKit before deciding on a path forward, but from a Gecko perspective, we basically need to call one function at the beginning and one function at the end of each test, so looks like the first option would be sufficient. Do you happen to have an example of that handy? I've never done something like this before, and I do appreciate some pointers to get started. I'm very happy to learn that it's possible to contribute wpt tests for this feature! Thanks, -- Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Implement: Storage Access API
On Fri, Sep 7, 2018 at 2:32 PM Tom Ritter wrote: > On Fri, Sep 7, 2018 at 12:54 PM, Ehsan Akhgari > wrote: > >>In our implementation, once the Storage Access API grants storage >>access, all newly created third-party iframes of the same origin will >> have >>storage access for a period of time (currently defined at 30 days) >> without >>calling requestStorageAccess() again, whereas in WebKit’s >> implementation >>they’d need to reaffirm their access by calling the API again. >> >> ... >> >>In our implementation, we phase out the granted storage access >>permissions after a number of days passed, whereas in WebKit’s >>implementation they phase out the permissions after a number of days of >>browser usage passed. >> > > > These two were confusing to me. AIUI: > First thing to note, the expiry mechanism is completely independent of when and how we choose to grant storage access, in case it helps clarify things. > The first one is solely about having to call the requestStorageAccess() > API again. It sounds like you're saying we give a 30 day grace window while > safari expires things immediately; but that's not what you mean. It's > solely about whether the javascript code needs to call > requestStorageAccess() (even if it will be granted without a prompt) or if > it doesn't need to call it. > That's right. It's also about the initial navigation of the document having storage access (before the document has a chance to call any JS APIs) which matters for HTTP layer cookies. > In Safari, you have to (even though it won't prompt), but in FF you won't > have to. In your pseudocode, I guess it works either way, but... what was > the reasoning for doing it this way instead of a pure Promise-based > approach? > What do you mean by "this way instead of a pure Promise-based approach"? If you mean why we chose to grant this access when it has previously granted before the page calls the API again, the short answer is for more web compatibility. One thing that I should explain here is that we also have a couple of heuristics that try to detect when the user interacts with a third-party widget in certain ways and grant this storage access automatically. These are designed to catch scenarios such as logins using things like social widgets, commenting widgets and the like. We'd like to treat the storage access permissions the same, no matter whether they've been granted automatically or programmatically through calling this API. The web compatibility are mostly about the former scenario. > In the second one: > Day 0: I do the thing, grant the access > Day 15: I sleep all day and don't use my browser > Day 30: Firefox expires permission > Day 31: Safari expires permission > > It's solely about the difference between counting Day 15 towards 30 days. > Right. I should also add that this isn't something that we particularly like in the current implementation, and may consider improving on it in the future. It's more a by-product of how our permission manager backend works. Cheers, -- Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Implement: Storage Access API
web-platform-tests: Our implementation unfortunately doesn’t come with web-platform-tests, for two reasons. One is that there is currently no way to mock user gestures in web platform tests [4], and the second reason is that furthermore, our implementation also depends on being able to manipulate the URL Classifier backend for testing purposes. So this isn't true, however the present state of affairs may not yet be useful to you. It is currently possible to make basic user actions in wpt using the testdriver API [1]. I am helping extend this to allow more general guestures via WebDriver-like actions [2]. However it sounds like in this case you may need to add test-only APIs for manipulating internal browser state. There are two possible approaches here: * Add a feature to WebDriver for manipulating this data. This can be specified in the StorageManager spec and is appropriate if we want to add something that can be used by authors as part of the automated testing for their website. * Add test-only DOM APIs in the StorageManager spec that we can enable when running the browser in test mode. Each browser would be expected to have some implementation-specific means to enable these APIs when under test (e.g. a pref). WebUSB has an example of this approach. [4] https://github.com/web-platform-tests/wpt/issues/7156 [1] https://web-platform-tests.org/writing-tests/testdriver.html [2] https://github.com/web-platform-tests/wpt/pull/12726 [3] https://wicg.github.io/webusb/test/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Implement: Storage Access API
On Fri, Sep 7, 2018 at 12:54 PM, Ehsan Akhgari wrote: >In our implementation, once the Storage Access API grants storage >access, all newly created third-party iframes of the same origin will > have >storage access for a period of time (currently defined at 30 days) > without >calling requestStorageAccess() again, whereas in WebKit’s implementation >they’d need to reaffirm their access by calling the API again. > > ... > >In our implementation, we phase out the granted storage access >permissions after a number of days passed, whereas in WebKit’s >implementation they phase out the permissions after a number of days of >browser usage passed. > These two were confusing to me. AIUI: The first one is solely about having to call the requestStorageAccess() API again. It sounds like you're saying we give a 30 day grace window while safari expires things immediately; but that's not what you mean. It's solely about whether the javascript code needs to call requestStorageAccess() (even if it will be granted without a prompt) or if it doesn't need to call it. In Safari, you have to (even though it won't prompt), but in FF you won't have to. In your pseudocode, I guess it works either way, but... what was the reasoning for doing it this way instead of a pure Promise-based approach? In the second one: Day 0: I do the thing, grant the access Day 15: I sleep all day and don't use my browser Day 30: Firefox expires permission Day 31: Safari expires permission It's solely about the difference between counting Day 15 towards 30 days. -tom ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to Implement: Storage Access API
Hi everyone, As we recently announced [0], we are working on a number of new anti-tracking features which are intended to change the current approach in Firefox with regards to how user’s data is shared with third-party trackers as the user browses the web. In the old world (the status quo for now), the data sharing is a non-consensual and invisible part of browsing the web. We would like to change this model by flipping the defaults, that is, make changes to Firefox to avoid sharing user’s data with third-party trackers by default, and also make the data sharing, where it happens, more visible and controllable by the user. As part of these efforts we are experimenting with a new cookie policy [1] that will block trackers from accessing cookies and other storage while in a third-party context. One of the new mechanisms that we would like to expose to web developers is to ask for consent in order to gain access to the user’s data in a third-party context. We are going to do this by adopting the Storage Access API [2] implemented by Safari for a very similar purpose. At a high-level, the Storage Access API allows content in third-party frames to request access to storage on a specific first party that would otherwise be blocked by our new policy. Safari uses this API as part of their Intelligent Tracking Prevention [3] feature, and there are some differences in the edge cases of how that feature works compared to our new cookie policy. We discuss this in more detail below, but the main differences include: - In our implementation, once Storage Access API grants storage access, all existing third-party iframes on the same first party will receive that storage access, whereas in WebKit’s implementation they each would require calling requestStorageAccess() separately. - In our implementation, all future resource loads from a third party that has been granted storage access will also be granted access on the same first party. This includes access to third-party cookie headers for content embedded into the main context of the page. - In our implementation, once the Storage Access API grants storage access, all newly created third-party iframes of the same origin will have storage access for a period of time (currently defined at 30 days) without calling requestStorageAccess() again, whereas in WebKit’s implementation they’d need to reaffirm their access by calling the API again. - In our implementation, when the promise returned from requestStorageAccess() is resolved, the third-party context will have access to its full first-party cookie jar. That includes things like cookies, localStorage, IndexedDB, DOM Cache, and so on. In WebKit’s current implementation, only access to cookies will be granted. - In our implementation, we phase out the granted storage access permissions after a number of days passed, whereas in WebKit’s implementation they phase out the permissions after a number of days of browser usage passed. We don’t necessarily believe that a model where the user is asked whether they consent to sharing their data with third-party trackers is ideal, because explaining the implications of the data sharing is very hard, and there are many problems associated with asking for permission from the user. But we are looking at this API as a programmatic hook into the point in time when a third-party context would like to obtain full storage access rights, which would allow the browser to perform various forms of security/privacy checks at that time. Prompting the user is only one of the options we’ve thought about so far. Note that the API limits granting access only to callers coming at times when processing a user gesture. Summary: Storage Access API is used to grant first-party storage access to third-party embedded content under some browser controlled conditions. [2] Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1469714 Link to standard: No standard exists yet, this is being discussed in https://github.com/whatwg/html/issues/3338. Platform coverage: All platforms. Estimated or target release: Unclear as of yet (an intent to ship will be sent later when a decision to ship has been made). Preference behind which this will be implemented: dom.storage_access.enabled Is this feature enabled by default in sandboxed iframes? No, the allow-storage-access-by-user-activation sandbox flag enables it. DevTools bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1462372. We will be filing more specific bugs as we work through the scenarios where devtools can assist web developers in order to use this functionality. Do other browser engines implement this? Shipped in Safari 11.1, no public signals from Chrome or Edge. web-platform-tests: Our implementation unfortunately doesn’t come with web-platform-tests, for two reasons. One is that there is currently no way to mock user gestures in web platform tests [4],
