Re: On longstanding webcompat issue about padding-bottom/padding-right missing in scroll containers

2021-03-26 Thread Anne van Kesteren
Thanks for untangling this mess! Always great to see.

On Thu, Mar 25, 2021 at 8:20 PM Ting-Yu Lin 林庭宇  wrote:
> [1] This table
>  in
> the spec issue summarizes the webcompat situation across different element
> types and engines.

Could you please summarize what the table ends up looking like after
these changes? I also saw bz note that we only want to change our
behavior once in this area, but I guess since this has taken so long
to resolve we changed our mind on that and will now proceed in two
stages?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to ship: Return pixel deltas in wheel event if deltaMode is not checked by authors

2021-03-10 Thread Anne van Kesteren
On Wed, Mar 10, 2021 at 9:11 AM Masayuki Nakano  wrote:
> Indeed, in long term goal must be that we'd dispatch exactly same wheel
> events as Chrome/Chromium. However, without implementing alternative new
> API, web apps will not be able to handle raw value for better UX.
> Therefore, I filed a spec issue, but it's not been fixed yet.
> https://github.com/w3c/uievents/issues/181

That does seem unfortunate, but unless other browsers are interested
in picking this up, I think it will hurt us more to be different than
that it helps. I don't think we should make aligning with Chrome and
Safari conditional upon some new API.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to ship: Return pixel deltas in wheel event if deltaMode is not checked by authors

2021-03-09 Thread Anne van Kesteren
On Tue, Mar 9, 2021 at 4:45 PM Emilio Cobos Álvarez  wrote:
> Let me know if you have any concerns with this or what not.

So if I understand it correctly we'll have a getter with side effects.
Is the expectation that we can eventually remove this? Are other
browsers on board with this model?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to prototype and ship: :user-valid and :user-invalid pseudo-classes.

2021-02-24 Thread Anne van Kesteren
On Tue, Feb 23, 2021 at 9:49 PM fantasai  wrote:
> We wanted it to be flexible enough that UAs could experiment with behavior and
> improve usability over time, so we locked down the one period in time that we
> felt was not up for debate (between attempted submission and next interaction
> with the invalid input) and left the rest open to interpretation.

I played with this some more and I think that might be a tad too
vague. E.g., if you cancel an invalid event Firefox will no longer
show UI messages to the user about filling in a form control, but
:-moz-ui-invalid still matches (see
https://software.hixie.ch/utilities/js/live-dom-viewer/saved/8957 for
a demo). And flexibility here is tough as web developers likely want
these to be fully deterministic to be able to build consistent
experiences.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to prototype and ship: :user-valid and :user-invalid pseudo-classes.

2021-02-23 Thread Anne van Kesteren
On Mon, Feb 22, 2021 at 2:59 PM Emilio Cobos Álvarez  wrote:
> Let me know if you have any objections about this change, but I think
> having a prefixed pseudo-class for this is not a great state of affairs.

This seems reasonable, but I think we should define the processing
model for them in the HTML Standard as well, to ensure everyone can
align on when exactly these are supposed to match.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to unship: FTP protocol implementation

2021-02-10 Thread Anne van Kesteren
On Wed, Feb 10, 2021 at 9:37 AM Valentin Gosu  wrote:
> FTP support is currently disabled on Nightly.

Does this have any impact on the URL parser? Do we still (want to?)
support the ftp scheme in form submission (to then delegate the
computed URL to some kind of handler rather than the browser)? Not
sure there are other bits in standards that are impacted by this, but
it will certainly allow for some nice cleanup in Fetch. 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to ship: beforeinput event and InputEvent.getTargetRanges()

2021-01-29 Thread Anne van Kesteren
On Fri, Jan 29, 2021 at 3:07 AM Masayuki Nakano  wrote:
> Therefore, we probably ship
> `beforeinput` aligned to current Blink (this is the default behavior in
> Nightly channel). And then, we should change the behavior to conform to
> new Level 1, when Blink updates its behavior. Even though changing
> behavior is risky after shipping it.

Thank you for this detailed description of the situation Masayuki!
This seems like the right decision to me given the rather messy state
of the specification and other implementations, as well as not having
insight into when those other implementations might or might not be
updated.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to ship: remote-protocol (CDP)

2021-01-12 Thread Anne van Kesteren
On Tue, Jan 12, 2021 at 5:43 PM James Graham  wrote:
> CDP is not part of any web standard, and is not exposed to content.

Seems unfortunate we cannot standardize on this format if we have to
support it anyway, but I guess that was already considered and found
not feasible?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to Ship: Make wheel event listeners passive by default on the root

2020-10-28 Thread Anne van Kesteren
On Mon, Oct 26, 2020 at 5:45 PM Emilio Cobos Álvarez  wrote:
> Standard: None, this is an intervention, though
> https://w3c.github.io/uievents/#cancelability-of-wheel-events is loosely
> related.

I'm not sure "it's an intervention" is sufficient reason as making
breaking changes to the web platform is not great for web developers,
but the fact that both Chrome and Safari already do this is, somewhat.
There is https://github.com/whatwg/dom/pull/366 which hasn't been
looked at since there only was one interested implementer. You should
probably take a look at that if that roughly matches part of the
changes you had to make. (Not sure who should own the "default passive
algorithm" for the root element though, HTML?)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to ship: Update browsing context name on cross site navigation or history traversal

2020-09-14 Thread Anne van Kesteren
On Fri, Sep 11, 2020 at 10:55 PM Shuran Huang  wrote:
> Thanks for the pointer. I did not realize it's about the cross-origin 
> navigation that not switch BrowsingInstance. Just to confirm, is the case for 
> top-level navigation only or not?

Cross-origin navigations of top-level browsing contexts whose opener
browsing context is either null or disowned. (It might be that null
and disowned can be merged, but currently they are not
specification-wise.)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to ship: Update browsing context name on cross site navigation or history traversal

2020-09-11 Thread Anne van Kesteren
On Fri, Sep 11, 2020 at 5:00 PM Shuran Huang  wrote:
> FYI, here is the tracking bug for this issue in Chrome: crbug.com/1090128.

Hey Shuran,

I think the bug you're looking for is
https://bugs.chromium.org/p/chromium/issues/detail?id=706350. In
particular this intent to ship is about resetting window.name when the
browsing context group (aka BrowsingInstance in Chrome) is not
replaced.

Kind regards,

Anne
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Intent to ship: returning shared memory to the web

2020-06-24 Thread Anne van Kesteren
At the end of August 2019 we expressed an intent to prototype the
re-enablement of SharedArrayBuffer[1]. Many bugs and design
iterations later, we’re happy to announce that it’s now ready. We
would like to ship this in Firefox 79 or 80.

To do this in a post-Spectre-safe manner we have worked with others
to add the cross-origin isolated primitive to the web platform, which
provides sites that opt into it with their own process that cannot
pull in non-consenting external resources. In that process they get
to use high-resolution clocks and shared memory.

To address novel attacks, we have added the ability to throttle
JavaScript execution with JSExecutionManager[2]. With more
implementation work, we could also use this capability to reduce
resource consumption and improve battery life, e.g., by enabling it
for background tabs.

Here’s a summary of the changes:

* We have already shipped[3] JavaScript’s Atomics and
  SharedArrayBuffer to release, although globalThis.SharedArrayBuffer
  returns undefined as long as the cross-origin isolated primitive is
  false. This included support for the shared:true parameter of
  WebAssembly.Memory’s constructor.
* As part of this intent we’ll ship the Cross-Origin-Opener-Policy
  and Cross-Origin-Embedder-Policy headers, that when set to the
  same-origin and require-corp values respectively, for a top-level
  document, enable its browsing context group to be cross-origin
  isolated. (Cross-Origin-Opener-Policy also helps sites close a
  security hole in the web platform by preventing themselves from
  being opened in a popup an attacker might control.)

  If a document is cross-origin isolated:

  * globalThis.crossOriginIsolated will return true.
  * globalThis.SharedArrayBuffer will no longer return undefined.
  * postMessage() can be used to message SharedArrayBuffer objects,
restricted to the agent cluster[4] (the smallest unit a browser
could isolate in a process) it was created in.
  * Agent clusters within a cross-origin isolated browsing context
group are keyed on origin rather than site: this means that 1)
shared memory is bound to a single origin (postMessage()’ing
elsewhere results in a messageerror) and 2) document.domain is
ineffective (it returns just before changing the origin, for
maximum compatibility with existing libraries that reportedly set
it a lot, but don’t really care if it works). (With Fission this
would allow us to use actual processes at the origin boundary
too, but we have not looked into that much thus far.)
  * Timers are no longer throttled, including performance.now().

Chrome plans to match this model by August 2020 for Android, March
2021 for all except sites that opt-out, and May 2021 for all without
exceptions.[5]

It’s being standardized primarily in the Fetch and HTML standards,
through a number of pull requests that are close to done:

* https://github.com/whatwg/html/pull/5334 (COOP)
* https://github.com/whatwg/html/pull/5454 (COEP)
* https://github.com/whatwg/fetch/pull/1030 (COEP)
* https://github.com/w3c/ServiceWorker/pull/1516 (COEP)
* https://github.com/whatwg/html/pull/4734 (cross-origin isolated)
* https://github.com/w3c/hr-time/issues/89 (timers; not much progress
  on this unfortunately; timers in general are a somewhat poorly
  defined piece of infrastructure)

Shipping bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1619649.

(Following this work we plan to change the header parsers from strict
byte sequence comparisons to using structured headers, which will
also pave the way for adding reporting functionality. We also plan to
eventually support cross-origin isolated for shared and service
workers and roll all of this out on mobile.[6])

In no particular order, many thanks to Nika, Tom, Valentin, Eden,
Jens, Luke, Bas, Neha, Andrew (x2), Hsin-Yi, Perry, Steve, Mike,
Lars Thomas, Jeff, Junior, Selena, Yaron, and Eric for their help
getting this done in Firefox!

[1] 
https://groups.google.com/d/msg/mozilla.dev.platform/IHkBZlHETpA/dwsMNchWEQAJ
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1563335
[3] 
https://groups.google.com/d/msg/mozilla.dev.platform/yl0BXW-_ou0/u9CKDvuABgAJ
[4] 
https://html.spec.whatwg.org/multipage/webappapis.html#integration-with-the-javascript-agent-cluster-formalism
[5] 
https://groups.google.com/a/chromium.org/d/msg/blink-dev/_0MEXs6TJhg/QzWOGv7pAQAJ
[6] https://bugzilla.mozilla.org/show_bug.cgi?id=1563480
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to ship: a change to the initial value of image-orientation

2020-02-17 Thread Anne van Kesteren
On Sun, Feb 16, 2020 at 10:19 PM Cameron McCormack  wrote:
> This doesn't really fit the format of an Intent email, but just as a heads 
> up, I am landing a change to the initial value of the image-orientation 
> property, from "none" to "from-image".  The effect of this change is that 
> EXIF orientation data in JPEG images used in HTML  elements and in the 
> CSS content property will be honored by default.

Where is this standardized? See
https://github.com/whatwg/html/issues/4495 for some tricky questions
that come up that haven't been conclusively answered yet, as far as I
can tell.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to prototype and ship: lazy load images

2020-02-14 Thread Anne van Kesteren
On Mon, Feb 10, 2020 at 3:22 PM Hiroyuki Birchill Ikezoe
 wrote:
> Is this feature enabled by default in sandboxed iframes?: no, as of now
> there is no proposed flag to enable this feature in sandboxed iframes.

I think the answer to this question is more complicated. It's disabled
if scripts are disabled, but if scripts are enabled, image lazy load
is enabled, right?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Some changes to how errors are thrown from Web IDL methods

2020-02-14 Thread Anne van Kesteren
On Thu, Feb 6, 2020 at 3:12 PM Boris Zbarsky  wrote:
> I would really like to get to the point where when web developers see
> errors in their console they don't have to guess what caused those
> errors, and having meaningful messages is the simplest way to get there.

This is a great goal and we should definitely improve our error
messages, but I continue to be worried about exposing more data there
than is advisable from a security/privacy standpoint. In particular as
from a developer ergonomics standpoint it can be hugely valuable to
include such data. (Since I raised this last time we actually had a
security bug related to this.)

I don't know how much work this is, but ideally the signature is
something like throwType(safeMessage, consoleMessage), whereby
consoleMessage defaults to safeMessage or some such. This would allow
for exposing confidential data to developers when debugging locally
and keeps user data secure/private (assuming all callers are holding
it correctly and get reviewed as such).
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Improvements to Web IDL exception message strings

2020-02-14 Thread Anne van Kesteren
On Mon, Feb 10, 2020 at 3:23 PM Boris Zbarsky  wrote:
> You can test this now in the console using:
>
>CSS.escape() /* no args */
>document.getElementById() /* no args */
>
> My changes did not affect the error messages from those, note; just used
> that same string in more places.

Would using Document.prototype.getElementById be too long? I've
sometimes seen developers advocate using # to mean .prototype (e.g.,
Document#getElementById via
https://mathiasbynens.be/notes/javascript-prototype-notation), but I
don't know how widespread that is. It does seem a little funky to use
Document.getElementById.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Proposed W3C Charter: Service Workers Working Group

2019-12-05 Thread Anne van Kesteren
On Tue, Dec 3, 2019 at 3:58 PM L. David Baron  wrote:
> The W3C is proposing a revised charter for:
>
>   Service Workers Working Group
>   https://www.w3.org/2019/11/proposed-sw-wg-charter-2019.html
>   https://lists.w3.org/Archives/Public/public-new-work/2019Nov/0004.html

A couple of us looked at Background Sync and thus far have not been
able to come up with a way to get informed consent from users for
executing scripts in the background in a way that is non-intrusive and
doesn't lead to abuse. Given that, I think Mozilla should object to it
being in the charter. Background Fetch has a similar issue, but
(thanks to Youenn Fablet for the insight) there might be a way to
salvage that, by running the "fetches completed" script on next visit.
This might require some API changes though so hopefully the charter
can indicate that somehow. (Bikeshed: Background Downloads.)

(The description for Service Workers, "This specification defines an
API to enable applications to take advantage of persistent background
processing.", also seems wrong or perhaps multiple uses of
"background" are used in the same text, but development of SW remains
important of course.)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to Implement- Double-keyed HTTP cache

2019-11-13 Thread Anne van Kesteren
On Wed, Aug 21, 2019 at 7:40 PM Sebastian Streich  wrote:
> Estimated or target release: Firefox 70

The plan is to enable this on Firefox 72 Nightly to see if there's any
fallout that needs addressing. It will not ride the trains. This is
tracked by https://bugzilla.mozilla.org/show_bug.cgi?id=1594004.

As network caches in general are a privacy and security concern, we're
tracking isolating all of them using the top-level origin in
https://bugzilla.mozilla.org/show_bug.cgi?id=1590107. If there are
further caches that could use such isolation, please do file a bug
blocking that bug.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to prototype: heading levels

2019-11-13 Thread Anne van Kesteren
Unfortunately, this was not a success (too many h1s got adjusted to be
h2s) so we've removed this code and abandoned this particular plan for
dealing with heading levels in HTML:
https://bugzilla.mozilla.org/show_bug.cgi?id=1590366.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to prototype: re-enabling SharedArrayBuffer

2019-11-13 Thread Anne van Kesteren
On Thu, Aug 29, 2019 at 1:47 PM Anne van Kesteren  wrote:
> We might ship 1 and 2 on Nightly to see what kind of breakage that
> gives. A risky part of this plan is that folks will have to test for
> postMessage() rather than SAB support going forward.

Enabling the prototype on Nightly can be tracked using
https://bugzilla.mozilla.org/show_bug.cgi?id=1594748. It appears to be
on track for 72. (It will not ride the trains. There'll be an intent
to ship when that happens.)

We also created a non-Release preference
dom.postMessage.sharedArrayBuffer.bypassCOOP_COEP.insecure.enabled
that can be used for playing with SharedArrayBuffer without requiring
these new HTTP headers to be set (you'll also need to enable
SharedArrayBuffer via javascript.options.shared_memory). (At some
point we probably need to create a more holistic strategy for our
various insecure preferences, that also involves DevTools.)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


PSA: changes to numerous DOM components on Bugzilla

2019-11-08 Thread Anne van Kesteren
Heya,

In https://bugzilla.mozilla.org/show_bug.cgi?id=1594717 the DOM team
requested quite a number of changes to their various components in
Mozilla's Bugzilla. Those components are now prefixed with either
"DOM:" or "Storage:". Please keep this in mind if you can't find a
component in its usual place.

Thanks to everyone who helped with this cleanup and please let me know
if you have any questions or further suggestions.

Kind regards,

Anne
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to ship: Add image/webp to default Accept header

2019-11-04 Thread Anne van Kesteren
On Fri, Nov 1, 2019 at 8:35 PM Boris Zbarsky  wrote:
> On 10/31/19 7:31 PM, Junior Hsu wrote:
> > However, it doesn't not align the spec
>
> Is that covered by https://github.com/whatwg/fetch/issues/274 or is
> there a new spec issue needed?

That covers it. The specification says "should" currently and probably
needs to be less strict. Not a big fan, but as long as media formats
continue to be messy and Chrome keeps extending Accept in this way we
cannot really improve the situation I think.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Intent to prototype: heading levels

2019-10-16 Thread Anne van Kesteren
Summary: The HTML Standard has for the longest time defined a feature
whereby you could exclusively use the h1 and sectioning elements, and
user agents would take care of adjusting the heading level according
to the nesting depth. Due to the complexity it never got adopted.
There’s an alternative proposal that amounts to counting sectioning
element ancestors for h1 elements only (and h2-h6 if their parent is
hgroup), which is much more doable performance-wise. That proposal
might see some further refinements for behavior around hgroup, based
on discussion in the issue linked below.
(https://annevankesteren.nl/2019/10/heading-levels goes into the
high-level idea a bit more.)

The idea is to ship this by default on Nightly and maybe Dev, but not
ride the trains (until the standard is more fully agreed and there's
an intent to ship).

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=998590.

Standard: https://github.com/whatwg/html/pull/3499 coupled with
https://github.com/whatwg/html/issues/5002.

Platform coverage: All.

Preference: accessibility.heading-element-level-changes.enabled.

DevTools bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1588784.

Other browsers: Have expressed mild interest to get to it eventually,
us having some code hopefully gets them more fully on board.

web-platform-tests: Unclear how to test heading levels, but once
there's a corresponding CSS pseudo-class to expose them there will be.

Secure contexts: No, bifurcating an existing HTML feature like that
doesn’t seem like a good idea.

Is this feature enabled by default in sandboxed iframes? Yes.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Web IDL now uses mixin syntax, not "implements"

2019-09-25 Thread Anne van Kesteren
On Wed, Sep 25, 2019 at 7:13 PM Christopher Mills  wrote:
> Updated our WebIDL page to include this new information:
>
> https://developer.mozilla.org/en-US/docs/MDN/Contribute/Howto/Write_an_API_reference/Information_contained_in_a_WebIDL_file#Mixins
>
> Let me know if you'd rather see something different here.

Thanks! I think my main suggestion would be to lead with the new
syntax as that should soon be more common. We also do expect that
eventually all specifications are updated. As part of updating syntax
in the IDL specification downstream dependencies are notified of
changes (and thanks to Kagami there's now an experiment of doing so in
automated fashion for the constructor change).
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Please aim to add informative messages to your exceptions

2019-09-25 Thread Anne van Kesteren
On Sat, Sep 14, 2019 at 6:50 AM Boris Zbarsky  wrote:
> That means not using the following when throwing nsresults/DOMExceptions:
>
>ErrorResult::Throw(nsresult)
>ErrorResult::operator=(nsresult)
>
> and instead using:
>
>ErrorResult::ThrowDOMException(nsresult, const nsACString&)
>
> which allows passing a message string that explains why the exception is
> being thrown.

One word of caution here. Please be careful putting variable data in
these messages (e.g., data that varies based on state) as that might
end up exposing more information to the site than we are comfortable
with. Both from a compatibility/refactoring hazard as well as end user
privacy.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to prototype: re-enabling SharedArrayBuffer

2019-08-29 Thread Anne van Kesteren
On Thu, Aug 29, 2019 at 3:30 PM J. Ryan Stinnett  wrote:
> On Thu, 29 Aug 2019 at 12:48, Anne van Kesteren  wrote:
>> Note that SharedArrayBuffer itself is already enabled by default as
>> ECMAScript (JavaScript) was never changed. And that standard requires
>> a host to allow cross-thread usage as while it describes
>> infrastructure for threads (agents) it doesn’t provide access to them
>> without a host.
>
> Thanks for writing up this comprehensive intent notice. I am having
> trouble parsing this part though...

This paragraph discusses the state in standards (together with the
preceding paragraph). It's not about Firefox.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Intent to prototype: re-enabling SharedArrayBuffer

2019-08-29 Thread Anne van Kesteren
Summary: SharedArrayBuffer (SAB) is a feature that allows
high-performance applications using shared-memory multi-threading to
run on the web. Shortly after releasing SAB, Firefox (and other
browsers) disabled SAB as part of our initial Spectre mitigations (see
https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/),
because it provides a very high-resolution clock which makes Spectre
attacks more effective.

Work is ongoing to enable these high-performance applications again.
The plan is:

1. Prevent postMessage() of SAB by default (throw) so it cannot be
used cross-thread.
2. Enable SAB by default as combined with number 1 above it’s no more
effective than an ArrayBuffer. (Though there might be some benefits as
it cannot ever be detached.)
3. Implement the Cross-Origin-Opener-Policy (COOP) and
Cross-Origin-Embedder-Policy (COEP) headers that when combined will
allow postMessage() of SAB cross-thread (within the same scope as
before). See 
https://docs.google.com/document/d/1zDlfvfTJ_9e8Jdc8ehuV4zMEu9ySMCiTGMS9y0GU92k/edit
for a high-level, but detailed, explanation of these headers. We’ll
likely do COEP support (and thereby full SAB support) for
shared/service workers as a follow-up.
4. Implement a way to sequentially execute threads that can have
shared memory as a security backstop (follow
https://bugzilla.mozilla.org/show_bug.cgi?id=1563335 for details).

We might ship 1 and 2 on Nightly to see what kind of breakage that
gives. A risky part of this plan is that folks will have to test for
postMessage() rather than SAB support going forward.

Product: Mike Conca.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1477743 (though see
https://bugzilla.mozilla.org/showdependencytree.cgi?id=1477743 for a
better overview of the full scope of the work).

Standard: None of this is fully standardized, but the processing model
is agreed upon with Google (and has had at least some review from
Apple, more so for COOP) and described in great detail. There’s some
difficult refactoring necessary of the HTML navigation algorithm to
integrate the various changes:
* COOP: https://gist.github.com/annevk/6f2dd8c79c77123f39797f6bdac43f3e
(and issue linked from there)
* COEP: https://mikewest.github.io/corpp/ (and issues linked from there)
* postMessage() with conditional SAB support:
https://github.com/whatwg/html/pull/4734

Note that SharedArrayBuffer itself is already enabled by default as
ECMAScript (JavaScript) was never changed. And that standard requires
a host to allow cross-thread usage as while it describes
infrastructure for threads (agents) it doesn’t provide access to them
without a host.

Platform coverage: Desktop. Until mobile has better multi-process
support we cannot do number 3 of the plan above.

Preference: browser.tabs.remote.useCrossOriginOpenerPolicy (for COOP),
browser.tabs.remote.useCrossOriginEmbedderPolicy (COEP), and
javascript.options.shared_memory (SAB). postMessage() conditional
support for SAB depends on the first two being set.

DevTools bug: N/A.

Other browsers: Based on the standards discussion and other
information we believe Chrome will end up with the same end state.
Safari is holding off for now.

web-platform-tests: html/cross-origin-opener-policy/,
html/cross-origin-embedder-policy/,
html/infrastructure/safe-passing-of-structured-data/shared-array-buffers/,
and 2dcontext/imagebitmap/ have lots of relevant tests.
https://github.com/web-platform-tests/wpt/issues/18354 tracks
remaining work.

Secure contexts: COOP and COEP are gated on secure contexts and
therefore the postMessage() support for SAB is as well. SAB itself is
not, though without a secure context you can only use it in a single
thread, as a non-detachable ArrayBuffer.

Is this feature enabled by default in sandboxed iframes? Yes.

How stable is the spec: Even though this is not fully standardized I
believe that the processing model is stable, with a good mutual
understanding between implementers.

Security & Privacy Concerns: Even though we isolate high-resolution
timers to an isolated process per site, an attacker might be able to
learn things from such a process. This should lessen over time as we
continue to make progress with Fission. In the event of a dangerous
cross-process zero-day attack, we’ll have the option to “disable” this
feature by sequentially executing threads.

Developer use-cases: Google Earth wants to use this to speed up
rendering per 
https://medium.com/google-earth/performance-of-web-assembly-a-thread-on-threading-54f62fd50cf7
(please excuse the Medium link).

Example: 
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer
has a basic SAB example, though no cross-thread usage yet
unfortunately.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to Implement- Double-keyed HTTP cache

2019-08-22 Thread Anne van Kesteren
On Thu, Aug 22, 2019 at 4:26 AM Martin Thomson  wrote:
> What is the tuple we're keying on?

Top-level origin only. This still allows C to attack B in your
scenario (or vice versa). There's a variety of other side channel
attacks on " sites" too, including various members of the
Window object, history.length, and clickjacking. It would also allow B
or C to attack A, though there's a number of other things possible
there too.

I definitely think it's worth figuring out how we can enable "
sites" to better protect themselves as well as figuring out how to
improve sandboxing of " sites", but it would require a broader
effort than caches I think. I think isolating by top-level origin is a
huge improvement over the status quo and stops a fair number of
practical attacks against major sites (modulo popup attacks, see
Cross-Origin-Opener-Policy for that). (Many of which you can't frame
to be clear, due to X-Frame-Options.)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to ship: Make elements always unvisited.

2019-08-09 Thread Anne van Kesteren
On Thu, Aug 8, 2019 at 8:39 PM Emilio Cobos Álvarez  wrote:
> Standard: https://drafts.csswg.org/selectors-4/#location (though note
> https://github.com/w3c/csswg-drafts/issues/3817).

So the real standard for this is
https://html.spec.whatwg.org/#pseudo-classes as CSS tries to be
host-agnostic (somewhat). It seems okay to me to get rid of this as
the  feature set always mismatched that of  and  a bit
and practically nobody would display a  anyway. Would you file
an issue against HTML to make it so?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to ship: accumulating most JS scripts' data as UTF-8, then directly parsing as UTF-8 (without inflating to UTF-16)

2019-08-06 Thread Anne van Kesteren
On Sat, Jul 20, 2019 at 2:05 AM Jeff Walden  wrote:
> (*Only* valid UTF-8: any invalidity, including for WTF-8, is an immediate 
> error, no replacement-character semantics applied.)

Wouldn't adding this allow you to largely bypass the text decoder if
it identifies the content to be UTF-8? Meaning we'd have to scan and
copy bytes even less?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Resolving URLs in c++

2019-07-12 Thread Anne van Kesteren
On Fri, Jul 12, 2019 at 9:05 AM Boris Zbarsky  wrote:
> You could simplify this a bit by calling
> nsContentUtils::ewURIWithDocumentCharset, but that doesn't solve most of
> the issue.

>From the name that sounds somewhat wrong to me too. At least, for new
APIs I think we should always use UTF-8 as the encoding passed to the
URL parser and having now looked up
https://wicg.github.io/web-share/#share-method that is also what
should happen per the draft (Safari might actually do this wrong then,
I recommend adding a test).
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to ship: Percentage opacity

2019-07-10 Thread Anne van Kesteren
On Wed, Jul 10, 2019 at 9:20 AM  wrote:
> Why fixing something that isn't broken and a well established standard for 
> something longer?

https://github.com/w3c/csswg-drafts/issues/3342 as pointed out in OP
offers plenty of justification to make this change. That's also a
better forum if you want to give design feedback.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Changes to “ExposureGuidelines” (Intent to *)

2019-07-05 Thread Anne van Kesteren
On Sat, Jul 6, 2019 at 2:44 AM Ehsan Akhgari  wrote:
> Does the page need to include some of this description?

It has this:

# It's acceptable to merge the "intent to prototype" into the
# "intent to ship" email as long as all the relevant
# requirements are met.

I suppose it could be a little clearer on whether to send two emails
or one though. Is that what you meant?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Changes to “ExposureGuidelines” (Intent to *)

2019-07-03 Thread Anne van Kesteren
Hi all,

In consultation with others I have made some adjustments to
https://wiki.mozilla.org/ExposureGuidelines.

“Intent to implement” has been renamed to “Intent to prototype” to signify
more clearly that the change does not affect the shipping product and has
no direct relation to standardization processes (though continues to be an
important input for them).

“Intent to ship” encompasses “Intent to implement and ship”. Include the
fields from “Intent to prototype” if the change does not warrant going
through two stages.

“Intent to unship” remains as-is.

(Despite some recent emails, “Intent to experiment” is not part of the
process. Fortunately “Intent to prototype” works well for them.)

I also took this opportunity to revise the page so that it now leads with
the more significant information. Please do feel free to edit this further
or message me suggestions.

Kind regards,

Anne
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to unship: typeMustMatch attribute on elements

2019-05-03 Thread Anne van Kesteren
On Fri, May 3, 2019 at 11:06 AM Frederik Braun  wrote:
> In bug 1548773, annevk suggested to unship the `typeMustMatch`attribute
> from  elements[1].

I've now also changed the HTML standard in
https://github.com/whatwg/html/pull/4590 and updated WPT in
https://github.com/web-platform-tests/wpt/pull/16656.


> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1548773
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: PSA: web-platform-tests (dashboard | fuzzy-reftests | reftest comparisons)

2019-04-16 Thread Anne van Kesteren
On Mon, Apr 15, 2019 at 7:16 PM Jonathan Watt  wrote:
> These are all really great. Thanks, James!

Indeed, thanks a lot for working on this! This will help a lot with
prioritizing work and also with standards development.

Some feedback for the Interop Dashboard:

* It would help me a bit if it clarified which versions of Chrome,
Firefox, Safari are represented to make local comparisons more easily.
* It would also be nice to be able to give a wpt path rather than have
to find the corresponding bug component.
* I don't see all the bug components, e.g., DOM::Core: Networking is missing.

Kind regards,

Anne
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Proposal to remove unnecessary [type] attributes on script tags in mozilla-central

2019-04-09 Thread Anne van Kesteren
On Tue, Apr 9, 2019 at 5:56 AM Cameron McCormack  wrote:
> On Tue, Apr 9, 2019, at 1:39 PM, Brian Grinstead wrote:
> > I'd like to rewrite markup in the tree to avoid using the [type]
> > attribute on 

Re: Intent to unship: Some Shadow DOM v0 APIs

2019-03-16 Thread Anne van Kesteren
Thanks for cleaning this up Emilio!

On Sat, Mar 16, 2019 at 1:37 AM Emilio Cobos Álvarez  wrote:
> The code implementing them remains untouched, since it's the same for
> ShadowRoot and Document, so resurrecting them should we need that would
> be trivial.

That seems highly unlikely. Unless live sets somehow get back in fashion.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to ship: implicit rel=noopener for target=_blank on anchor and area elements

2019-01-25 Thread Anne van Kesteren
On Fri, Jan 25, 2019 at 1:52 AM Tantek Çelik  wrote:
> I am seeing some publisher uptake of rel="noopener" so it is good that
> we are shipping this.

To be clear, we've supported rel="noopener" for a while. This makes it
so that you don't need to specify rel="noopener" if your target
attribute is set to "_blank".
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to implement: implicit ref=noopener for target=_blank on anchor and area elements

2018-11-23 Thread Anne van Kesteren
On Thu, Nov 22, 2018 at 6:00 PM Ehsan Akhgari  wrote:
> Do you mean adding a rel attribute to ?  Not sure if all of the other
> link type values for rel make sense for  but having some way of
> passing "noopener" (and "opener" for that matter) directives for  is
> indeed something that we should probably look into doing, especially when
> it comes to changing the default behavior of .  I have
> no good ideas for how to do it other than inventing yet a new attribute...

Since  is effectively a more complicated , adding rel=""
seems very reasonable to me ("noreferrer", "noopener", "search",
"help", and "nofollow" make some amount of sense there).
https://github.com/whatwg/html/issues/2983 tracks this standards-wise.
(They also request  there, not sure about that one given how
annoying global mutable state is.)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to implement: implicit ref=noopener for target=_blank on anchor and area elements

2018-11-22 Thread Anne van Kesteren
On Thu, Nov 22, 2018 at 7:07 AM Ehsan Akhgari  wrote:
> I wonder if it makes sense to make a similar change here, to make  target="_blank"> imply noopener behaviour and then if that proves to be Web
> compatible, propose to change the spec to pass false there?

Yeah, I think we should try to keep it consistent. I think Apple was
worried that  would be the least likely to be web-compatible, so
they started out smaller.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to implement: implicit ref=noopener for target=_blank on anchor and area elements

2018-11-21 Thread Anne van Kesteren
On Wed, Nov 21, 2018 at 4:08 PM Alex Gaynor  wrote:
> Do we have any sense of how large the breakage will be, and do we have any
> docs for developers who are impacted? (I assume rel=opener is the fix?)

The "fix" would be to use target=someuniquename.

And I don't think there's data, other than Safari folks not having
heard anything yet.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: nsIHttpChannel not trying to authenticate if presented BASIC and an unknown auth method

2018-11-20 Thread Anne van Kesteren
On Tue, Nov 20, 2018 at 3:48 PM Honza Bambas  wrote:
> Our implementation reflects the reality we can see in the wild.  I
> believe the spec has always been wrong here, and apparently has never
> been widely respected by servers because commas may be contained in the
> challenge header values.  The spec should consider authentication as an
> exception, similarly to Set-Cookies.  This is, tho, only my opinion.

Given that intermediaries are free to combine headers (other than
Set-Cookie) that seems problematic. It also seems doable to define a
parser that acts on the combined value, but I agree that doing so
requires buy-in from others and due diligence with respect to tests
and compatibility. (Also, per
https://github.com/httpwg/http-core/issues/136 it looks like the HTTP
WG isn't close to consensus on accepting the browser status quo, if
any exists.)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: nsIHttpChannel not trying to authenticate if presented BASIC and an unknown auth method

2018-11-20 Thread Anne van Kesteren
On Tue, Nov 20, 2018 at 3:15 PM Boris Zbarsky  wrote:
> On 11/20/18 8:55 AM, Honza Bambas wrote:
> > because comma can be contained in a single header value
> > (against what the spec says).  We can't correctly separate the headers
> > by commas, potentially even opening security holes if we do that blindly.
>
> Do we know what other UAs do here?

Similar, e.g., https://bugs.chromium.org/p/chromium/issues/detail?id=872772.
Doesn't seem like a high priority for anyone to fix.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: nsIHttpChannel not trying to authenticate if presented BASIC and an unknown auth method

2018-11-20 Thread Anne van Kesteren
On Tue, Nov 20, 2018 at 9:50 AM john.bieling--- via dev-platform
 wrote:
> Thanks for your feedback. As you have the much deeper knowledge about these 
> thinks, I think it would be better if you file that bug?

I forgot that it was already filed and marked as a dependency:
https://bugzilla.mozilla.org/show_bug.cgi?id=669675.


> Solved that by checking getRequestHeader("Authorization") in case of 401 and 
> if that is missing, I know nsIHttpChannel did not try to authenticate.

Once we fix the bug you filed that will no longer be true though,
right? But I guess you can determine from the value that Firefox
wasn't able to parse it somehow...
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: nsIHttpChannel not trying to authenticate if presented BASIC and an unknown auth method

2018-11-20 Thread Anne van Kesteren
On Tue, Nov 20, 2018 at 9:20 AM john.bieling--- via dev-platform
 wrote:
> Now it looks like that nsIHttpChannel itself is not able to split 
> WWW-Authenticate headers?

Right, I reported that in
https://bugzilla.mozilla.org/show_bug.cgi?id=1491010#c22.


> Should I add a link to this thread to the existing bug?

I think it's worth filing a new bug on parsing WWW-Authenticate, as
this bug at this point is really about how fetch() and XMLHttpRequest
end up exposing things. And while they arguably should have the same
fix, the priority and complexity between the two might vary quite a
bit.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to implement and ship: WebP image support

2018-10-12 Thread Anne van Kesteren
On Thu, Oct 11, 2018 at 5:43 PM Andrew Osmond  wrote:
> Is this feature restricted to secure contexts?: No, it isn't. This is not a
> new API, instead it is just accepting more types of content via existing
> channels.

This isn't the rationale you're looking for. New formats would
generally be expected to be restricted. New formats already shipped by
other browsers and likely in use on insecure contexts however probably
deserve an exception.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: What is the future of XMLHttpRequest.mozAnon ?

2018-09-14 Thread Anne van Kesteren
On Fri, Sep 14, 2018 at 12:50 PM Gijs Kruitbosch
 wrote:
> This seems like an issue with the fetch spec (
> https://fetch.spec.whatwg.org/#concept-header-value-combined ) that you
> could report to them ( https://github.com/whatwg/fetch ) if that hasn't
> already been done.

FWIW, I'm pretty sure it's a bug in XMLHttpRequest caused by Necko's
API: https://bugzilla.mozilla.org/show_bug.cgi?id=1491010.
XMLHttpRequest and fetch() should be equivalent when it comes to
headers.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: What is the future of XMLHttpRequest.mozAnon ?

2018-09-14 Thread Anne van Kesteren
On Thu, Sep 13, 2018 at 11:05 PM john.bieling--- via dev-platform
 wrote:
> Is mozAnon going to stay or are you thinking about removing that in the 
> future?
>
> https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/mozAnon

It'll be marked ChromeOnly:
https://bugzilla.mozilla.org/show_bug.cgi?id=1454588. Maybe at some
future point it might be removed altogether as fetch() can be used
instead (in combination with the credentials dictionary member).
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to Implement: Storage Access API

2018-09-12 Thread Anne van Kesteren
On Tue, Sep 11, 2018 at 9:06 PM Ehsan Akhgari  wrote:
> 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.

Unfortunately, that will still share cookies. Adding a feature policy
or some such for that might be worthwhile.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: nsIClearDataService

2018-06-01 Thread Anne van Kesteren
Thanks for working on this! Clear-Site-Data seems pretty essential to
have now we ship service workers.

On Fri, Jun 1, 2018 at 6:26 PM, Andrea Marchesini
 wrote:
> Note for the DOM/QuotaManager/ServiceWorker people: this component covers
> all the DOM storages under 1 single flag: CLEAR_DOM_QUOTA. This is done
> because I know that the integration of localStorage and
> ServiceWorkerRegistrar into QuotaManager is in progress. Plus, there are no
> reasons to delete just localStorage, or just ServiceWorkers or just IDB
> data.

It is even disallowed as it likely messes with the expectations of the
site: https://storage.spec.whatwg.org/#buckets

> A bucket is considered to be an atomic unit.
> Whenever a bucket is cleared by the user
> agent, it must be cleared in its entirety.

(There's still quite a bit of work to be done to actually layer all
these APIs properly on top of the Storage Standard, but one day I'm
sure we'll get rid of our technical debt.)


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Proposed W3C Charter: Devices and Sensors Working Group

2018-05-04 Thread Anne van Kesteren
On Fri, May 4, 2018 at 2:07 AM, L. David Baron  wrote:
> On the flip side, sensor APIs are offered by mobile (and to some
> degree desktop) operating systems and widely used by apps running on
> them, and there's clear demand for having them on the Web.  So I
> think it seems worth having a clear venue for that discussion, which
> would suggest that it's good to have the discussion in the scope of
> the working group.

This is true for a number of APIs not offered by the web, many of
which don't have standardization efforts or a viable path to be
exposed (or were standardized and then dropped due to issues, e.g.,
batteries).


> I'm inclined to think that if we want to suggest changes to address
> this security/privacy issue, we should be suggesting clarifying the
> success criteria for the working group so that these issues are
> clearly considered, and making it more explicitly OK for the group
> to decide not to produce some of its deliverables.
>
> The final paragraph of section "1. Goals" already says a bit here,
> as does the third paragraph of "2.1 Success Criteria", but perhaps
> there's more to say, perhaps by making not producing a spec
> explicitly OK in both "2.1 Success Criteria" and "3. Deliverables"?
> And perhaps something in there should also explicitly mention the
> difficulty of properly informing the user in order to obtain
> informed consent for the real risks underlying the sensors, or
> something like that?
>
> Or do you instead think that some of the deliverables should be
> removed from the charter because they're not likely to succeed?  If
> so, which?

I hadn't looked in detail yet, but they're doing quite a lot of APIs. Of those

  Generic Sensor API
  Geolocation Sensor

might be the least controversial as its a new API for an existing
feature, but I have not looked in detail whether this is a straight
mapping or not. If Google's Layered APIs initiative
(https://github.com/drufball/layered-apis) is successful that might
also be a better way to go about things.

  Wake Lock API

We've explored this for FxOS. In terms of mozilla/standards-positions
I guess this would be non-harmful.

  Battery Status API

We've unshipped this: harmful.

  Network Information API

I'm pretty sure Mozillians have raised issues with this in the past
and we don't intend to ship it. I suspect harmful.

  DeviceOrientation Event specification

We ship this on Android I think, but per earlier dev-platform threads
we're not exactly happy with it.

  Proximity Sensor
  Ambient Light Sensor
  Accelerometer
  Gyroscope
  Magnetometer
  Orientation Sensor

These are the ones my initial comment was for. As I understand it the
proposed defense is to restrict these to foreground top-level browsing
contexts without user prompt. It's unclear to what extent they are
throttled. If they are throttled, they are less or not useful for
AR/VR. If they are not throttled, they are an interesting
fingerprinting vector. It's unclear to me how a standardization group
is going to help resolve that and I don't think we'd want them to make
that trade-off for us.

There's also Vibration API and HTML Media Capture and I'm not sure
what the state of those is. Neither seems particularly problematic.

Hope that helps,


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Proposed W3C Charter: Devices and Sensors Working Group

2018-05-03 Thread Anne van Kesteren
On Thu, May 3, 2018 at 12:51 AM, L. David Baron  wrote:
> Please reply to this thread if you think there's something we should
> say as part of this charter review, or if you think we should
> support or oppose it.

Perhaps I've missed something, but I feel like we never resolved the
security question around high-resolution sensors. If I haven't missed
anything, I suggest we say we're still skeptical about exposing these
to the web.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Proposed W3C Charter: Timed Text Working Group

2018-05-03 Thread Anne van Kesteren
On Thu, May 3, 2018 at 12:42 AM, L. David Baron  wrote:
>   Timed Text Working Group
>   https://www.w3.org/2018/04/proposed-tt-charter-2018.html

What does

# The Group is expected to produce annual updates for the Recommendation
# with previously unspecified features.

mean?


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: License of test data?

2018-04-24 Thread Anne van Kesteren
On Tue, Apr 24, 2018 at 4:24 PM, David Teller  wrote:
> Ideally, I'd like to put a few well-known frameworks in jsapi tests, to
> be used as data for SpiderMonkey integration tests.
>
> What's our policy for this? Are there any restrictions? All the
> frameworks I currently have at hand are have either an MIT- or an
> MIT-like license, so in theory, we need to copy the license somewhere in
> the test repo, right?

Per https://www.mozilla.org/en-US/MPL/license-policy/ it sounds like
you would need to file a licensing bug, even if it's MPL-compatible,
because it's Third Party Code.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to unship: URL.createObjectURL(MediaStream)

2018-04-23 Thread Anne van Kesteren
On Mon, Apr 23, 2018 at 9:50 AM, Andrea Marchesini
 wrote:
> . I haven't checked edge (I don't run windows locally)

Ask for a BrowserStack account (not entirely sure who arranges these
though, I got mine via jst).

Edge still supports it:
https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/17021183/.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to implement and ship: ping, rel, referrerPolicy, relList, hreflang, type and text properties on SVG elements

2018-04-10 Thread Anne van Kesteren
On Tue, Apr 10, 2018 at 3:58 AM, Jeff Gilbert  wrote:
> Do we have a heuristic for when to /not/ include something from HTML in SVG?
>
> More or less, these additions to SVG just strike me as having solid
> potential risk (for both spec-interaction and implementation bugs) and
> negligible upside. Do we have people asking for this?

Microsoft and the SVG WG seem to be driving this somewhat. I think
there's mostly upsides to having HTML and SVG share more code as it
means ongoing maintenance will be more shared as well. It seems it
might also lead to some simplification on the SVG side (e.g., a
further change being considered is to make target a simple string
rather than an animated string).

OP did not mention this, but the idea is that pretty much everything
would end up being defined in HTML:
https://github.com/whatwg/html/issues/3591.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to implement and ship: same-site cookies

2018-04-10 Thread Anne van Kesteren
On Tue, Apr 10, 2018 at 4:25 AM, Francois Marier  wrote:
> Secure contexts: not restricted to secure contexts since cookies are
> already available in non-secure contexts

I'm not entirely convinced that is a good enough reason. We keep
trying to find ways to limit cookies transmitted over HTTP (and
limiting HTTP in general). Offering better cookies over HTTPS seems
like a good incentive for sites to migrate.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to unship: CSSStyleDeclaration.getPropertyCSSValue

2018-03-27 Thread Anne van Kesteren
On Fri, Mar 23, 2018 at 9:16 PM, L. David Baron  wrote:
> I should clarify that it isn't actually non-standard:  it was part
> of DOM Level 2:
> https://www.w3.org/TR/DOM-Level-2-Style/css.html#CSS-CSSStyleDeclaration
> but ended up never being widely implemented.  It's not a
> particularly nice API, nor was it specified in a way that could lead
> to interoperability, and its replacement is intended to be
> https://drafts.css-houdini.org/css-typed-om/ .
>
> I'm still in favor of removing it.

FWIW, note https://lists.w3.org/Archives/Public/www-style/2003Oct/0347.html
and https://www.w3.org/TR/2011/WD-cssom-20110712/#history which aimed
to replace the document you reference. Maybe not quite non-standard,
but definitely some flavor of obsolete.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Use cases for invalid-Unicode atoms

2018-03-21 Thread Anne van Kesteren
On Wed, Mar 21, 2018 at 10:27 AM, Henri Sivonen  wrote:
>  * A bunch of things atomicize URL components. I'd hope that the URLs
> were converted from UTF-16 to UTF-8 at some prior point ensuring UTF-8
> validity, but it's hard to be sure.

At least per the specification all URL components end up with only
ASCII code points after parsing the URL. I think we match that these
days, though for UI purposes we go back to Unicode at times. I don't
think we convert to Unicode if the percent-encoded sequences are not
valid UTF-8 byte sequences though.


> To the extent these are used for
> security checks, having NaN atoms that match nothing could be safer
> than having different inputs yield the same U+FFFD sequences to make
> them match.
>
> The query string can introduce invalid UTF-8 into a URL, but I believe
> we never do security checks based on query part. I believe we're
> supposed to be doing security checks on the scheme (always ASCII),
> port (number) and the Punycode form of the host (always ASCII). Is
> this true?

We do some important checks on other parts (e.g., what service worker
to use depends on the path), but again, I'd assume those are all full
ASCII comparisons.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

2018-03-19 Thread Anne van Kesteren
On Mon, Mar 19, 2018 at 11:48 AM, Martin Thomson  wrote:
> Yes, it pays to remember that this is Nightly.

Even on Nightly we place pretty severe restrictions on ourselves when
it comes to user data, e.g., for telemetry. This definitely goes
beyond the kind of data I would expect Mozilla, let alone a
third-party, to collect from Nightly users.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

2018-03-19 Thread Anne van Kesteren
On Mon, Mar 19, 2018 at 8:10 AM, Henri Sivonen  wrote:
> On Mon, Mar 19, 2018 at 3:18 AM, Eric Shepherd (Sheppy)
>  wrote:
>> I definitely see some easy ways this could be problematic from a public
>> relations perspective given things going on in the industry these days and
>> some of our own mistakes the in the past. It's definitely worth taking a
>> little while to consider the implications before throwing the switch.
>
> Indeed.
>
> Sending the hostnames the browser accesses to a third party that would
> not normally be part of the network activity (regardless of what
> policy agreements Mozilla has with them) should be opt-in even if it
> makes the study data less representative, even if it's Nightly only
> and even if Cloudflare is better than some people's ISPs.

Agreed, especially since the experiment as announced is Cloudflare in
addition to your ISP. So even if we could say they're better than your
ISP, which seems tough on a world-wide scale, that defense won't work
here.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Proposed W3C Charter: Web Payments Working Group

2018-02-02 Thread Anne van Kesteren
On Fri, Feb 2, 2018 at 7:49 PM, Peter Saint-Andre  wrote:
> What you have seems fine (modulo s/Web Auth/Web Authentcation/). The
> first comment is just housekeeping, whereas the second comment is
> substantive and concerning. Phrasing it as a formal objection might
> result in greater attention to the seemingly significant overlap. I'd be
> curious what other folks here think (Marcos, Tantek, Anne, etc.).

I'd lean towards objecting as otherwise you might get a group of
people with lots of different objectives and nobody really getting
what they want. (Both 1.2 and 1.3 are pretty concerning, and 1.2
sounds like the thing that made the Web Crypto effort somewhat
dysfunctional.)


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Requiring secure contexts for new features

2018-01-17 Thread Anne van Kesteren
On Wed, Jan 17, 2018 at 12:02 AM, Martin Thomson  wrote:
> Either of these criteria are sufficient, right?  However, I expect
> that we'll want to hold the line in some cases where other browsers
> ship anyway.  How do we plan to resolve that?  One potential
> resolution to that sort of problem is to ship in secure contexts
> anyway and ask other browsers to do the same.
>
> My expectation is that we'll discuss these and exercise judgment.  But
> I thought that I'd raise this point here.  I want to avoid creating an
> expectation here that we're happy with lowest common denominator when
> it comes to these issues.

I was hoping that the section "Exceptions to requiring secure
contexts" makes it quite clear that it is indeed an appeals process.
We already have a process for shipping new features ("intent to
implement/ship") and now you need to present justification if you want
to ship a feature available on insecure contexts. It is likely that an
exception is granted for either of the reasons given, but it's not a
guarantee. The dev-platform community can still object and if that is
sustained by the Distinguished Engineers I would expect us to not ship
it (or ship it restricted to secure contexts).

I have clarified https://wiki.mozilla.org/ExposureGuidelines that
secure contexts needs to be part of the "intent to implement" emails
and also linked the secure contexts post from the suggested
implementation process.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Requiring secure contexts for new features

2018-01-16 Thread Anne van Kesteren
Yesterday Mozilla announced Firefox will be restricting new features
to secure contexts (i.e., HTTPS):

  https://blog.mozilla.org/security/2018/01/15/secure-contexts-everywhere/

I'm glad to report that thus far this has been very well received.

I'm posting this here per suggestion from Ben Kelly and because:

* Not all module owners and peers might have seen the blog post and
this might impact them if their module currently, or in the future,
exposes features to web content.
* Modules might want to look into ways of enforcing this
programmatically, to ease ongoing maintenance and guide everyone to do
the right thing without having to ask/review/etc. E.g.,
https://bugzilla.mozilla.org/show_bug.cgi?id=1429014 has some ideas
for enforcement around our bindings.
* Mozillians might have questions not addressed in the post and this
seems like a good place to centralize those and address them.

Insofar as documenting this policy elsewhere goes I've updated
https://wiki.mozilla.org/WebAPI/WebIDL_Review_Checklist and I'll
update https://wiki.mozilla.org/WebAPI/ExposureGuidelines too in some
manner. (The latter will probably also need to be generalized as
currently it suggests it's for APIs only.)

Hope that helps,


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Device Orientation API future

2018-01-11 Thread Anne van Kesteren
On Thu, Jan 11, 2018 at 6:48 PM, Blair MacIntyre  wrote:
>> In that case I'm not entirely sure why we'd also pursue new
>> variants separately.
>
> I’m not sure what this means?

That if our main usage for the new sensor APIs (those discussed in
https://github.com/w3ctag/design-reviews/issues/207) is WebVR/XR and
we don't have any other uses that are compelling enough, and WebVR/XR
will come with their own APIs for this, there's no reason for us to
worry about the new sensor APIs.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Device Orientation API future

2018-01-11 Thread Anne van Kesteren
On Thu, Jan 11, 2018 at 5:30 PM, Blair MacIntyre  wrote:
> First, this discussion pertains to FF on Windows, Mac, Android and Linux, I 
> assume?  FF for iOS just uses the wkWebView and it’s up to Apple to decide on 
> things like this.  Is this correct?

I believe there's some tricks we could pull on iOS in theory.


> From a WebVR perspective, the polyfill (that uses device-orientation) defers 
> to the built in WebVR API if it exists.

So WebVR/XR has its own equivalents for these APIs? I was not aware of
that. In that case I'm not entirely sure why we'd also pursue new
variants separately.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Device Orientation API future

2018-01-10 Thread Anne van Kesteren
On Thu, Jan 11, 2018 at 5:39 AM, Chris Van Wiemeersch  wrote:
> Anne and Martin, can you think of changes to request for the Sensor API
> that we would resolve or reasonably improve the existing fingerprinting
> concerns?

It sounds like Chrome's approach is throttling, which would probably
work, but it doesn't work for WebVR, right? (At which point we're back
at looking at a permission prompt and being unsure how to phrase the
question.)


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Device Orientation API future

2018-01-10 Thread Anne van Kesteren
On Wed, Jan 10, 2018 at 4:23 AM,   wrote:
> 1. Lock down the Device Sensor APIs APIs in Gecko to only secure contexts, 
> with `deviceorientation`, `absolutedeviceorientation`, and `devicemotion` 
> being enabled by default.

This helps with encouraging HTTPS adoption, but it does not solve the
underlying issue one bit. Secure contexts do not make a feature
secure. Secure contexts are a good defense-in-depth strategy and we'll
soon go all-in for new features, but they do not (and will never)
address fingerprinting or tracking issues.


> 2. Implement the Generic Sensor APIs in Gecko.

I don't see how this helps WebVR given that Chrome throttles these
APIs to address the security issues and if they're throttled they
reportedly become much less useful for WebVR. (I mentioned this in the
W3C TAG review you referenced and have thus far not received a reply
alleviating these concerns.)


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to unship: navigator.registerContentHandler()

2018-01-10 Thread Anne van Kesteren
On Wed, Jan 10, 2018 at 2:06 AM, Fabrice Desre  wrote:
> WebShare is more a trimmed down version of the WebActivities/WebIntents
> apis. I think it's unfortunate that instead of fixing the issues with WA/WI
> they went with a single purpose API - this doesn't scale at all with uses
> case they don't think about and limits the innovation for content
> publishers.

It's a little off-topic, but the overall issue with both of those
technologies was that the approach was too general. And such overly
generic APIs do not translate to good UX. I think starting small and
slowly expanding the types of things we want to make extensible, and
thinking those through all the way up to and including the user
experience, makes for a much more viable approach.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to unship: navigator.registerContentHandler()

2018-01-09 Thread Anne van Kesteren
On Tue, Jan 9, 2018 at 5:30 PM, Gervase Markham  wrote:
> I'm sure unshipping it is the right thing to do, but it's very sad. :-(
> Allowing web pages to register for content types and protocols seems
> kind of important if you want the web to have the capability of
> seamlessly replacing desktop and mobile apps.

It might still be worth pursuing, but note that the current API is
rather broken and results in two loads of the content (and how it
integrated with navigation/fetching was never really defined in
sufficient detail). A better API would be handing of the stream of the
download somehow to the third-party. Also note that the "protocol" API
is still there.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Device Orientation API future

2018-01-04 Thread Anne van Kesteren
On Thu, Jan 4, 2018 at 11:15 AM, Blair MacIntyre  wrote:
> If we are going to break existing websites, then perhaps looking at the 
> Generic Sensor API (as CVan suggests in his email) is a more rational 
> approach;  is it implemented in FF yet?  Plans for it?

See https://github.com/w3ctag/design-reviews/issues/207. There are
quite a few concerns with the new APIs (that also apply to the old
ones, granted, which is why we're discussing limiting those first). I
also don't think we have anyone signed up to do the necessary
implementation work.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to remove Ambient Light and Proximity sensor APIs

2017-12-18 Thread Anne van Kesteren
On Mon, Dec 18, 2017 at 7:36 PM, Gervase Markham  wrote:
> appear.in, which supports both audio and video calling via WebRTC, works
> in Firefox for Android, although performance is not awesome on my Z3C
> Compact.
>
> It does not blank the screen when you place the device to your ear.

There might be more secure ways we can address this use case. E.g.,
having a dedicated signal just for that, perhaps only given if the
user already granted access to the microphone and such.

(And if something does require the full power of the proximity API, we
should first work out how to expose it securely. I'm sure folks can
come up with use cases for running arbitrary code as root too, but
that doesn't mean we can offer it.)


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: W3C Proposed Recommendations: WAI-ARIA and Core Accessibility API Mappings

2017-12-01 Thread Anne van Kesteren
On Fri, Dec 1, 2017 at 11:49 AM, Jonathan Kingston  wrote:
> If roles are mapped 1:1 to HTML features we basically:
> - Promote the use of bad markup and the expectation that bad markup will
> use good ARIA.

It's pretty clear that  and  et al have limitations
that are not acceptable for certain UIs on the web. At that point you
need to implement those controls yourself. If we don't offer the same
APIs that the browser uses to implement  and  et al,
we're basically saying that only high-level approaches can be
accessible. That's not acceptable. We should strive to remove the
limitations of the high-level approaches so they become more appealing
and more widely adopted, but we should not withhold low-level APIs.


> - The need to reimplement all of HTML into ARIA becomes greater.

It's not a reimplementation. It's effectively exposing the signal the
browser sends to assistive technology for a particular element so
custom controls can send the same signal indicating they behave in a
roughly equivalent way.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Browser Architecture Newsletter 5

2017-11-30 Thread Anne van Kesteren
On Wed, Nov 29, 2017 at 9:47 PM, Dave Townsend  wrote:
> If you’re working on improving storage or syncing of data in any of our
> products or projects, on any platform, or if you’re currently struggling to
> work with what currently exists, then we’d like to hear from you and align
> our efforts.

We have quite a bit of ongoing activity linked from
https://bugzilla.mozilla.org/show_bug.cgi?id=1147820 focused on APIs
exposed to web content (HTTP cache, cookies, localStorage, Indexed DB,
service worker registrations, etc.) and the associated UI exposed to
users. There should maybe be a discussion at some point if the backend
can be reconciled somehow as I think it would be beneficial to users
if at some point some or all of this data could be synchronized in the
same manner bookmarks are today. (No reason to "install" a web
application twice or not having access to locally stored documents if
the user agent can just synchronize the necessary data for you.)


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Please do not use GetNativePath and GetNativeTarget in XP code and Windows-specific code

2017-11-29 Thread Anne van Kesteren
On Thu, Nov 30, 2017 at 12:00 AM, Kris Maglione  wrote:
> I don't think this is true. The native filename isn't even available to JS,
> which always deals with UTF-16 strings.

JS deals with 16-bit unsigned integers. In particular, you can
represent lone surrogates in JS, but not in UTF-16.


> On Windows, the UTF-16 path always corresponds to the wide native pathname,
> which is always UTF-16.

Per https://github.com/rust-lang/rust/issues/12056 that is not true
and Windows has the same flaw as JS.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Any intent to implement the W3C generic sensor API in Firefox?

2017-11-08 Thread Anne van Kesteren
On Thu, Nov 9, 2017 at 6:29 AM, Boris Zbarsky  wrote:
> On 11/3/17 3:00 PM, Jonathan Kingston wrote:
>> Which specific issues?
>> The API in the specification is promise ready by using the permissions
>> API,
>> is behind a permission prompt and requires a secure context.
>
> Does that address the privacy concerns we had with device APIs before?

Only if we know what question to pose to users and make it clear what
the implications of their choice are. I haven't seen as much as a
mockup, but if Chrome is indeed planning on doing this we might see
something soon?


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to ship: (hyperlink auditing)

2017-11-03 Thread Anne van Kesteren
On Tue, Oct 17, 2017 at 11:00 PM, James Graham  wrote:
> Are there cross-browser (i.e. wpt) tests for this feature?

Not that I know of, html/semantics/links/downloading-resources/ is
still empty. I added a comment to our bug.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Threadsafe URLs - MozURL

2017-10-23 Thread Anne van Kesteren
On Mon, Oct 23, 2017 at 4:01 PM, Valentin Gosu  wrote:
> A few weeks ago we landed MozURL. This is an immutable threadsafe wrapper
> for rust-url.

What is the plan for these issues:

  https://github.com/servo/rust-url/issues/163
  https://github.com/servo/rust-url/issues/290

I'm rather worried that no serious effort to align with the standard
has taken place for close to two years. Quite a few things changed,
especially in response to feedback from the implementations by Safari,
Node.js, and jsdom. And also in response to work undertaken in
Firefox.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Intent to ship: (hyperlink auditing)

2017-10-02 Thread Anne van Kesteren
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=951104

Rationale: There's already a myriad of ways to obtain this data
through script. We might as well ship the protocol that both Chrome
and Safari ship in the hope that along with sendBeacon() it decreases
the usage of the slower alternatives; ultimately giving users a better
experience.

Previously: This was already discussed in
https://groups.google.com/d/msg/mozilla.dev.platform/DxvZVnc8rfo/RxSnyIFqxoQJ
and I think concluded given Jonas Sicking's statement in the
aforementioned bug, but since it's been a few years without action we
thought it would be worth it to send another ping.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to implement and ship: CSP exemptions for content injected by privileged callers

2017-10-02 Thread Anne van Kesteren
On Mon, Oct 2, 2017 at 6:09 PM, Boris Zbarsky  wrote:
> On 10/2/17 12:03 PM, Daniel Veditz wrote:
>> Fair enough. Could we propose improvements to the APIs that would make
>> them more usable? For example an object argument to createElement() that
>> contained attribute/value pairs?
>
> This has definitely been proposed before.  Worth checking with Anne to see
> what the status is.  Specifically, did it die, and if so why? Because I,
> too, think this would be an interesting avenue to explore...

See https://github.com/whatwg/dom/issues/150. There's not really any
dominant pattern that's succeeded here in libraries that we could
adopt. You typically end up looking at templating and that has its own
host of issues. The other thing that would solve some of this is
browser-backed sanitization, but that's also a hard problem to solve
nobody has been willing to tackle and get standardized.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Status of deprecating non-secure HTTP

2017-09-25 Thread Anne van Kesteren
On Mon, Sep 25, 2017 at 2:47 PM, Boris Zbarsky <bzbar...@mit.edu> wrote:
> On 9/25/17 3:18 AM, Anne van Kesteren wrote:
>> But it would also be good if we could all communicate this on behalf
>> of Mozilla without caveats. E.g., Chrome might ship worklets soon and
>> being able to object to that happening (specification-wise) on
>> insecure contexts on behalf of Mozilla would be good.
>
> The Chrome intent to shop thread for CSS paint raises some good concerns
> about what exactly it would mean to not support paint worklets in insecure
> contexts.  Do they still parse but just fail to paint?  Do the not parse?
> Note that a _stylesheet_ doesn't have a concept of secure or insecure
> context right now

It does not seem hard to come up with solutions to those problems, if
we're actually committed to going down this path. Especially if we're
all aligned that the goal is restrict as many new features to secure
contexts as possible. (E.g., just like globals have isSecureContext,
there could be a media query that can be used from CSS for the same
purpose. Or @supports could be used if we make parsing fail.)


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Status of deprecating non-secure HTTP

2017-09-25 Thread Anne van Kesteren
It seems that with Richard leaving Mozilla we dropped the ball on
requiring HTTPS more often:

  https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/

At least I can't find any follow-up with an agreed upon date and we're
still rather hit-or-miss when it comes to using [SecureContext] on new
APIs. Let alone non-IDL-driven features. We have made some modest
progress on the second action item however.

David Baron has made some efforts to more require this to pass a W3C TAG review:

  https://github.com/w3ctag/design-principles/pull/75

But it would also be good if we could all communicate this on behalf
of Mozilla without caveats. E.g., Chrome might ship worklets soon and
being able to object to that happening (specification-wise) on
insecure contexts on behalf of Mozilla would be good.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Device orientation/motion events privacy issues

2017-09-22 Thread Anne van Kesteren
On Fri, Sep 22, 2017 at 4:50 PM, Ehsan Akhgari  wrote:
> We discussed this a bit with Anne on IRC.  It seems like this API is a good
> use case for a permission prompt to the user.  Since the API works by
> registering an event listener, the only realistic option seems to be
> Permission.request() before registering the event listeners.  Unfortunately
> it seems that a while ago we have pushed back on this API
> , but it seems that this use
> case wasn't considered back then.  Anne said he'll look into opening up that
> discussion again to see if we can use a permission prompt for this API...

I filed https://github.com/w3c/permissions/issues/158 for a simplified
version of the API and pinged Jeffrey Yasskin from Google about it on
IRC. Another alternative we could pursue is add something dedicated
for orientation/motion somewhere; perhaps on the navigator dumping
grounds. But it would be good if we could get orientation/motion
events maintained somehow then so this can just be put in that
document.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to ship: CSP directive worker-src

2017-09-22 Thread Anne van Kesteren
On Fri, Sep 22, 2017 at 4:18 PM, Christoph Kerschbaumer
 wrote:
> We plan to ship the CSP directive worker-src within Firefox 58.

Will we also start enforcing script-src for workers? It seems good
that if you restrict script it actually stops all scripts.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Eiminating nsIDOM* interfaces and brand checks

2017-09-04 Thread Anne van Kesteren
On Fri, Sep 1, 2017 at 5:01 PM, Boris Zbarsky  wrote:
> Thoughts?  It really would be nice to get rid of some of this stuff going
> forward.  And since the web platform seems to be punting on branding,
> there's no existing solution we can use.

It's punting on exposing it to web developers, but we do want it
formalized per https://github.com/heycam/webidl/issues/97 in some kind
of form. An API that acts on [[PlatformBrand]] is probably the most
likely thing that other browsers might be interested in adopting down
the road, assuming they hit similar issues.

I'd personally favor a single global method with branching over
polluting each object, but I don't have strong rationale.

Also, do we need this for Promise, Map, Set, etc., or just IDL-defined objects?


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: nsIURI API changes - punycode domain names

2017-08-10 Thread Anne van Kesteren
On Wed, Aug 9, 2017 at 8:37 PM, Boris Zbarsky  wrote:
> On 8/9/17 1:43 PM, Daniel Veditz wrote:
>>
>> What do web pages do if they want to reflect a pretty URL into their page?
>
> Cry, basically.

I have a proposal: https://github.com/whatwg/url/pull/288.

There's two issues:

1) Ryan Sleevi is opposed and nobody else from Google seems to care
enough to convince him. (We could potentially try to convince them by
shipping something in Firefox and Safari (Apple has shown interest).)

2) What is the exact algorithm that it should use. In particular,
should it use the same heuristics as the browser for whether it
becomes Punycode or Unicode, should those heuristics be standardized,
or should it always go to Unicode if possible, even if the browser
wouldn't (e.g., in case of mixed scripts).


> This is the fundamental reason I was opposed to this behavior change, but
> apparently no other browsers care about this issue and we were getting
> compat problems.  :(

Well, we also didn't use an algorithm that was standardized anywhere
so other browsers sticking with Punycode seems fairly reasonable in
light of that.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Restricting the Notifications API to secure contexts

2017-08-07 Thread Anne van Kesteren
Chrome wants to restrict the Notifications API
https://notifications.spec.whatwg.org/ to secure contexts:

  https://github.com/whatwg/notifications/issues/93
  https://github.com/w3c/web-platform-tests/pull/6596

Given that the API involves prompting the user as well as a permission
that remains stored across different networks it seems like a good
idea to restrict this API to HTTPS.

I was wondering if anyone has concerns with restricting the API as
such. If there are no concerns within a week I'll let Chrome go ahead
with the change to the standard and tests and file the necessary
implementation bugs against the remaining browsers, including Firefox.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to remove: sensor APIs

2017-08-02 Thread Anne van Kesteren
On Wed, Aug 2, 2017 at 4:39 PM, Blair MacIntyre  wrote:
> Are we still talking about deviceorientation?

As I said twice and Frederik repeated, we're not, other than asking if
anyone has a plan for how to make it interoperable. Note that it's far
from a W3C standard: https://www.w3.org/TR/orientation-event/. Doesn't
seem like anything got approved there.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to remove: sensor APIs

2017-07-31 Thread Anne van Kesteren
On Mon, Jul 24, 2017 at 6:11 PM, Anne van Kesteren <ann...@annevk.nl> wrote:
> Please consider the request to remove device orientation retracted for
> now. We'll still need to figure out some kind of long term plan for
> that API though. WebVR building on it through libraries that abstract
> away the browser incompatibilities will just make it harder to fix the
> underpinnings going forward. (And there's always the risk that folks
> don't use libraries and code directly against what Chrome ships. Seems
> likely even.)

Small update: we'll start by just disabling proximity. Disabling
ambient light will follow soon after, but is a little trickier as we
use the web-facing API in the Firefox for Android frontend.
(Suggestions for fixing the orientation interoperability mess are
still welcome!)


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: [PATCH] gfx: thebes: decouple GfxSurfaceType from cairo_surface_type_t

2017-07-31 Thread Anne van Kesteren
Hey Enrico, patches are certainly appreciated, but please attach them
(and corresponding rationale) to bugs instead. This one should
probably go here:
https://bugzilla.mozilla.org/enter_bug.cgi?product=Core=Graphics.
dev-platform has a ton of subscribers and is really only meant for
more high-level discussion. Thanks!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to remove: sensor APIs

2017-07-24 Thread Anne van Kesteren
Please consider the request to remove device orientation retracted for
now. We'll still need to figure out some kind of long term plan for
that API though. WebVR building on it through libraries that abstract
away the browser incompatibilities will just make it harder to fix the
underpinnings going forward. (And there's always the risk that folks
don't use libraries and code directly against what Chrome ships. Seems
likely even.)

On Mon, Jul 24, 2017 at 5:07 PM, Mike Hoye  wrote:
> I have a sense that as AR gets richer and more nuanced that ambient light
> and proximity sensing will become important as well, even if we're not there
> yet.

I'm not sure that's a good reason to keep the current APIs around
though. Ambient light in particular leaks cross-origin data. It's
rather surprising we haven't acted on that thus far. And none of what
we ship ended up being standardized as such. If we actually think we
need these APIs we should put in the effort to solve the security and
standardization issues.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Intent to remove: sensor APIs

2017-07-24 Thread Anne van Kesteren
As a follow-up to the Ambient Light Sensor API thread, which ended up
not really concluding, I hereby suggest we remove the various sensor
APIs from our code base. Flipping the preference first to make sure
there's no undue impact on web content and quick reversal is possible
and then removing the code in a later release.

This affects these APIs:

* Ambient light
* Proximity
* Device orientation

The rationale:

* These APIs have various privacy leaks, including violating the
same-origin policy, without the user being informed.
* These APIs do not match the current standards for sensor APIs and
some are incompatible with what is being shipped by Chrome (e.g.,
device orientation).
* There's no interest to address these shortcomings. (Mostly in the
sense of engineering resources and having other problems to tackle
first.)
* As these are event-driven APIs the compatibility impact should be
minimal to none. The events simply won't fire.

The bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1359076


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: W3C Charter Advance Notice: Web Platform (recharter) & Service Workers WGs

2017-07-12 Thread Anne van Kesteren
On Tue, Jul 11, 2017 at 8:38 PM, L. David Baron  wrote:
> Also, for what it's worth, given offline feedback, I plan to support
> the Service Workers WG charter.  Apparently much of the discussion
> about service workers happens in WHATWG forums, but it still seems
> valuable to have the work happening in W3C, and it seems to be
> functioning reasonably.

That's only true for where Service Workers touches DOM, Fetch, and
HTML. There's a fair bit of tightly coupled parts between those four
standards, but everything that's specific to Service Workers happens
in the W3C GitHub as far as I know (there might be some occasional IRC
discussion in #whatwg on Freenode I suppose).


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Proposed W3C Charter: WebAssembly Working Group

2017-07-11 Thread Anne van Kesteren
On Tue, Jul 11, 2017 at 3:29 AM, L. David Baron  wrote:
> The standard sentence:
>   "Most WebAssembly Working Group teleconferences will focus on
>   discussion of particular specifications, and will be conducted on an
>   as-needed basis."
> doesn't seem to make sense for a working group that basically has one
> specification.  Perhaps it should be reworded for something that is more
> appropriate here.

I think they'll have to produce multiple eventually. I can think of at
least WebAssembly, a JavaScript API for compiling and executing
WebAssembly modules, and IDL bindings for WebAssembly.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to unship: moz*Frames attributes of HTMLVideoElement

2017-07-10 Thread Anne van Kesteren
On Fri, Jul 7, 2017 at 5:57 PM, Ehsan Akhgari  wrote:
> Yes indeed.  (I just commented the same about unshipping another feature in
> a different thread, so I won't repeat literally all of the same points here,
> but they all apply here too!)

I created 
https://wiki.mozilla.org/WebAPI/ExposureGuidelines#Guidelines_for_removing_features
so we have a place to point folks towards. Review appreciated.


> FWIW I don't think we have ever included a version number (at least
> according to my knowledge) and I don't think that is a good idea, since the
> specific version number depends on the data and our guesses often end up
> being wrong.  But we usually don't consider these messages as "ultimatums",
> rather we try to monitor usage and err on the side of not breaking content.

A while back Blink changed how they handled this. They use the
developer console to give a heads up when the telemetry gives very low
numbers and they'd previously just remove it straight away. They
basically do this for intranet deployments which likely would not have
opted into telemetry and might therefore not have noticed yet still
depend on such marginal features. And giving those folks a deadline
helps them with planning.

Also, they more or less stopped using the developer console to drive
down usage. Not entirely sure about how I feel about this as I think
it has been somewhat successful at times and for XMLHttpRequest it has
resulted in less synchronous usage I think (though by far not enough
to consider removing the functionality). On the other hand, too many
warnings about "harmful" features and developers will start using a
browser with a different console that's less spammy.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Leakage of amount of storage used

2017-07-10 Thread Anne van Kesteren
On Mon, Jul 10, 2017 at 8:54 AM, Shawn Huang  wrote:
> I wondered that it's easy to find the identity by collecting how much space
> all other origins take up together. It's possible that the size of other
> origins that user has visited could change next time. Unless users don't
> browse other sites. Maybe I missed something?

Yeah, at best it tells you something about the user's device (which
storage tier they got). And since it's opt-in I think it's fine. Just
wanted to double check with dev-platform.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to unship: moz*Frames attributes of HTMLVideoElement

2017-07-07 Thread Anne van Kesteren
On Fri, Jul 7, 2017 at 8:51 AM, Jet Villegas  wrote:
> Depending on what you find, we may have to keep this API around :-/

Yeah, I would expect us to follow the "normal" deprecation and remove
path to be more confident in the eventual unshipping:

1. Gather telemetry on how often these APIs are used to measure feasibility.
2. Indicate in the console when these APIs are used that they are deprecated.
3. Bonus points for indicating in the console by which Firefox release
they are expected to be gone. (This might require more knowledge on
usage though.)

(Perhaps this is not documented anywhere currently?)


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Leakage of amount of storage used

2017-06-30 Thread Anne van Kesteren
On Fri, Jun 30, 2017 at 10:47 AM, Tom Tung  wrote:
> I think there are the similar issue but not the same. The bug 1290481 is
> focus on not exposing the size of opaque responses while the leakage of
> amount of storage used is about exposing overall usage of other origins.

Yeah indeed. The leak I attempted to describe is at best a
fingerprinting data point. It can reveal to an origin (after the user
has agreed to let that origin use persistent storage in some manner,
currently through a dialog) how much storage combined all other
origins the user has visited use.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Leakage of amount of storage used

2017-06-29 Thread Anne van Kesteren
Persistent storage gets the global quota. We also expose the local
quota (that of the origin). That means that by filling up space you
can determine how much space all other origins take up together.

Persistent storage for an origin is user opt-in through a dialog (and
maybe "add to homescreen/new tab" at some point in the future).

Presumably we already have this leak with a proprietary extension to
IndexedDB that enables persistent storage (though slightly different
in nature; it's not bound by the global quota but by disk space).

This data could be used for fingerprinting.

Is this acceptable or should we seek to actively avoid it somehow?
E.g., by limiting persistent storage to an amount less than the global
quota.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


  1   2   3   4   >