Re: Intent to Implement: Storage Access API
On Sun, Sep 9, 2018 at 5:10 AM Mike O'Neill wrote: > This is great but I have a couple queries. > > > >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. > >- > > > Presumably this is restricted to iframes *of the same origin* on the same > first party, i.e. if there are 2 iframes on different origins they would > each still have to request storage access. Can you confirm this? > Yes, of course. > > > > > > 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. > > > The legal requirement in Europe is that storage can only be accessed if > the user has unambiguously given their "freely given, specific & informed" > consent. How will a European website top-level context (first-party) ensure > that embedded third-parties will not be granted storage access without the > user first being prompted? > In general in order to comply with regulations such as GDPR, websites need to do a lot more than just look at the Storage Access API, so this is a very partial answer to your question. The API provides the ability right now for the embedder to control the ability of the embedded third-party to request storage access using an iframe sandbox flag. In the future we may consider adding further controls in this regard, for example, allowing the top-level embedder to control whether the embedded content can call the API using feature policy. Please note that Firefox will grant storage access permissions automatically under certain circumstances for web compatibility reasons, so even when the iframe has never called this API it may still obtain storage access. In order to prevent that from happening, the usual approaches against embedded content gaining storage access (through sandboxing the iframe to give it a unique origin) could be used. 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
On Mon, Sep 10, 2018 at 11:19 AM James Graham wrote: > On 07/09/2018 21:27, Ehsan Akhgari wrote: > > > 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. > > You want an example of a spec adding a WebDriver-based test API? (I'm > not 100% sure I interpreted your message correctly). The permissions > spec has one [1]. > > [1] https://w3c.github.io/permissions/#automation > Thanks, this is exactly what I wanted to find! -- Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
PSA: searchfox now indexing macOS Rust/C++ code
Just a heads up that as of today Searchfox is also indexing Rust and C++ code that is conditionally compiled only on macOS. It was previously only doing code compiled on Linux. Windows and Android are not yet indexed; those will be added as time permits. One caveat is that there are some generated sources (e.g. the C++ code produced for IPDL files) where the generated file is different for Linux and macOS. In such cases, Searchfox will use the Linux version of the file. It shouldn't be hard to add the macOS version as well, but I'm not sure what a good UX would be for exposing that. If you have suggestions please leave them in bug 1487583. Thanks! ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: searchfox now indexing macOS Rust/C++ code
This is awesome - thanks kats! On Tue, Sep 11, 2018 at 12:58 PM Kartikaya Gupta wrote: > Just a heads up that as of today Searchfox is also indexing Rust and C++ > code that is conditionally compiled only on macOS. It was previously only > doing code compiled on Linux. Windows and Android are not yet indexed; > those will be added as time permits. > > One caveat is that there are some generated sources (e.g. the C++ code > produced for IPDL files) where the generated file is different for Linux > and macOS. In such cases, Searchfox will use the Linux version of the file. > It shouldn't be hard to add the macOS version as well, but I'm not sure > what a good UX would be for exposing that. If you have suggestions please > leave them in bug 1487583. Thanks! > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
MinGW Target Re-Enabled on TaskCluster
Previous Thread: https://groups.google.com/forum/#!topic/mozilla.dev.platform/r3mYWbb42pM As of a few hours ago, there is a new Tier 2 MinGW build on TaskCluster. It's in the 'Windows MinGW all' line, with the group WMC64 for 'Windows MinGW Clang x64'. The MinGW builds are part of the Tor Uplift project, where we work closely with Tor to upstream their patches and in general move Tor Browser closer and closer to 'Firefox with Addons and Pref Changes' - instead of a fork of Firefox with a bunch of custom patches. Tor is currently using ESR releases: the bump to ESR60 (which occurred last week! It's a huge release for them with a lot of UX improvements: https://blog.torproject.org/new-release-tor-browser-80 ) was a lot smoother - build-wise - than other bumps because we had the MinGW build running in TC. Without keeping the MinGW build working, every ESR they have to go through a potentially colossal amount of work on a short timescale to get the build working under MinGW again. By minimizing their effort in fixing the build, rebasing patches and the like - we can free up their limited resources to continue to research and experiment on privacy technology like First Party Isolation and Fingerprinting Resistance. Now, you might be wondering "I thought we had a MinGW build?" We did. But we had to disable it. Shortly after 60 went to beta, we removed support for --disable-stylo. Stylo requires libclang to build; and getting that working with MinGW was very complicated (see https://bugzilla.mozilla.org/show_bug.cgi?id=1390583) so MinGW fell behind and had to be disabled. However, thanks (again) to the efforts of all the reviewers, build peers, and especially Jacek Caban - we've been able to re-enable a MinGW build. We are now building with clang using the MinGW headers. (Previously it was gcc.) I believe we're the first 'real' project that is building with MinGW-clang, and Tor will be the first major project to ship it (but I could be wrong there.) In configure and moz.build files, CC_TYPE will be 'clang-cl' for our normal Windows builds (which build on Windows) and will be 'clang' for the MinGW-clang builds (which build on Linux). There are still some outstanding issues: I hope to land a x86 build, we need to remove some of the --disable-foo flags, and once ESR60 gets a NSS uplift I intend the backport the jobs there also. We hope to get pdbs generating so we can debug easier - major appreciation to David Major and Bob Owen who both have debugged pretty ugly crashes without symbols. Eventually, I'd like to enable a limited set of tests to catch browser crashes. Because there is no path forward for getting the MinGW gcc builds re-enabled (nor anyone who wants to work on it...) I intend to remove the (disabled) build jobs from the tree also. And finally I need to document how to get a local build environment for it. MinGW is Tier 2, and sometimes breaking it is unavoidable because the fix needs to happen upstream in MinGW. Other times breaking it is avoidable, and one just needs to special-case it. The Tor Uplift team and Tor themselves greatly appreciate all of your efforts to keep the build green. As always, if you have a MinGW question or a build error you can't quite understand - feel free to reach out to me via irc or email. -tom ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
