As of 2015-04-15 I intend to turn identity for WebRTC on by default.
It has been developed behind the media.peerconnection.identity.enabled
preference. Firefox will be the first to implement this; I have only
informal promises from Google to implement once we ship.
This feature is the mutual authe
My bad, here's the bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1152538
On Wed, Apr 8, 2015 at 2:11 PM, Martin Thomson wrote:
> As of 2015-04-15 I intend to turn identity for WebRTC on by default.
> It has been developed behind the media.peerconnection.identity.enabled
> prefe
On Mon, Apr 13, 2015 at 12:11 PM, Gervase Markham wrote:
> Are you sure "privileged contexts" is the right phrase? Surely contexts
> are "secure", and APIs or content is "privileged" by being only
> available in a secure context?
There was a long-winded group bike-shed-painting session on the
pub
On Mon, Apr 13, 2015 at 3:53 PM, Eugene wrote:
> In addition to APIs, I'd like to propose prohibiting caching any resources
> loaded over insecure HTTP, regardless of Cache-Control header, in Phase 2.N.
This has some negative consequences (if only for performance). I'd
like to see changes like
On Tue, Apr 14, 2015 at 3:29 AM, Henri Sivonen wrote:
> Specifically, on point #2, I think we should start by, by default,
> forgetting all cookies that don't have the "secure" flag set at the
> end of the Firefox session. Persistent cookies have two main use
> cases:
> * On login-requiring sites
On Fri, Apr 17, 2015 at 11:22 AM, Anne van Kesteren wrote:
> As I said early on in this thread, this claim often comes up, but is
> never backed up. Where is the research that shows we need public
> caching proxies?
This is early days, but I'm working with a partner on two things:
- working out
On Tue, Apr 21, 2015 at 3:43 PM, Ryan VanderMeulen wrote:
> Seeing how often I get pushback from people over backouts, I wouldn't agree
> with this premise, FWIW.
People, remember to *thank* the person who backs out your code.
Just like you should thank people for finding your bugs. Better now
On Thu, Apr 23, 2015 at 11:22 AM, Ed Lee wrote:
> Similar to how we iterate on code to make Firefox faster, more usable, or
> more functional; we would like to improve on user trust and transparency for
> Suggested Tiles.
I don't think that piecemeal treatment of these issues in the way that
yo
On Thu, Apr 23, 2015 at 12:33 PM, wrote:
> Do you have suggestions on where each of the 4 topics I posted should be
> discussed?
In a meeting, where a small number of participants are well-prepared.
___
dev-platform mailing list
dev-platform@lists.moz
This is a digression, but it touches on an important question that
others are asking in response to this general push [1].
Fundamentally, better client authentication doesn't do anything to
help make the web a more secure place (in any of the dimensions that
we're primarily concerned about in this
On Tue, Apr 28, 2015 at 3:52 AM, Aryeh Gregor wrote:
> Personally, I was surprised when I first learned that override/final
> can only be used on virtual functions. I was definitely unaware that
> override/final imply virtual until I read this thread. It seems David
> Baron also didn't know. So
On Tue, Apr 21, 2015 at 10:02 AM, Christopher Lord wrote:
> I'd appreciate any feedback (even if it's "You're an idiot and this is not
> how we go about this") before taking this any further.
Doesn't this increase the effective page transition latency by adding
the animation duration to the page
On Fri, May 1, 2015 at 11:06 AM, Eric Shepherd wrote:
> There are a lot of things that don't need encryption,
This assertion is made quite often in this context. It's been shown to
be false in every example I've seen. I think Richard provided several
citations where this was believed to be corre
On Fri, May 1, 2015 at 11:25 AM, Chris Hofmann wrote:
> Is there a wiki page or some other comprehensive reference that defines the
> issues and arguments around this central question?
Richard was - I think - in the process of assembling an FAQ that
covered this and other issues. This is defini
On Mon, May 4, 2015 at 11:00 AM, Daniel Holbert wrote:
> (I think there's a strong case for disabling *persistent* fullscreen
> permission, for the reasons described in ekr's response to you here. I
> haven't seen any proposal for going beyond that, but I might've missed it.)
A little birdy told
On Wed, May 6, 2015 at 8:42 AM, Doug Turner wrote:
> This is important. We could mitigate by requiring https, only allowing the
> top level document access these clipboard apis, and doorhangering the API.
> Thoughts?
A doorhanger seems like overkill here. Making this conditional on an
"engag
On Wed, May 6, 2015 at 11:55 AM, Adam Roach wrote:
> Keep in mind the thesis of that plan isn't that we restrict
> security-sensitive features to https -- it's that /all new stuff/ is
> restricted to https. If this falls under the definition of a "new feature,"
> and if it's going to be released a
On Wed, May 13, 2015 at 3:46 PM, Ehsan Akhgari wrote:
> ise() was an alias to is() as of bug 949614. I landed bug 1154275 on
> inbound today which removes ise() and replaces its usages with is(). Since
> is() now does a === comparison by default, there should be no reason to use
> ise().
\o/
I
On Wed, May 13, 2015 at 4:54 PM, Matthew N.
wrote:
> "In JavaScript, == is preferred to ===." from
> https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Operators
Ahh, that's where it was hiding. Can we reverse that statement please?
___
On Thu, May 14, 2015 at 5:17 AM, Gijs Kruitbosch
wrote:
> On 14/05/2015 01:21, Martin Thomson wrote:
>>
>> On Wed, May 13, 2015 at 4:54 PM, Matthew N.
>> wrote:
>>>
>>> "In JavaScript, == is preferred to ===." from
>>>
>>&g
On Thu, May 14, 2015 at 9:40 AM, Gijs Kruitbosch
wrote:
> Do you think the people that wrote the style guide (not me, so I'm not
> trying to be defensive over the document, to be clear) did not understand
> what they wrote? :-)
No, but I do think that they were wrong.
>> Crockford offers plenty
On Thu, May 14, 2015 at 10:35 AM, Gijs Kruitbosch
wrote:
> I mean, obviously the example is simplified. You seem to think that "==="
> means "I'm sure this will be the right type". In the same way you imply that
> == indicates uncertainty about type (or acceptance of multiple types), I
> would arg
On Thu, May 14, 2015 at 11:16 PM, Panos Astithas wrote:
> This. From the perspective of a library method validating inputs, I've
> always found it pays off to rely on Postel's principle.
Sorry, that's a red flag for me. Postel was wrong. (Search for that phrase.)
__
On Tue, Jun 2, 2015 at 1:35 PM, Kyle Huey wrote:
>> auto len = aArray.Length();
>> auto display = GetStyleDisplay()->mDisplay;
>>
>> It can save having to look up whether aArray.Length() returns size_t
>> (I sure hope it does, though) or whether mDisplay is uint8_t or
>> uint16_t.
I have no s
On Tue, Jun 2, 2015 at 1:59 PM, L. David Baron wrote:
>
> My assumption was that this would be for cases where neither the
> reader nor writer is likely to care about which integral type it is,
> and also cases that are near the threshold for whether to repeat (in
> source code or perhaps only in
On Wed, Jun 3, 2015 at 6:14 PM, Eric Rahm wrote:
> I generated this list by grabbing the logs for a recent m-c linux64 debug
> run, normalizing out PIDs and timestamps and then doing some sort/uniq-fu to
> get counts of unique lines.
If your tool could be turned into a web page that runs again
On Jun 4, 2015 10:27 AM, "Daniel Holbert" wrote:
> Also: in layout, there are various warnings related to coordinate
> wraparound/overflow, where we're basically throwing up our hands and
> warning that broken layout is likely to occur because the page is
> millions of pixels tall. These can be u
On Wed, Jun 17, 2015 at 4:57 PM, Nicholas Nethercote
wrote:
> (At this point I expect people to push back against my claims that the
> automated tools aren't up to snuff. If you really think automated
> tools can do a good enough job, please run one and submit patches
> fixing up some files. I'd b
I wonder, has the subject of double-keying been raised in this
context? It comes up frequently in this context. And when I say
double-keying, I mean forming a key from the tuple of the requesting
principal and the top level browsing context principal (though origin
may suffice).
If there are disr
On Tue, Jun 30, 2015 at 4:18 PM, Ehsan Akhgari wrote:
> I personally am not sure if that is a sound idea for all permission types.
> It's probably the right thing for geolocation, but not for cookies.
As I understand it, the key for permission manager is a simple string.
Rather than make new APIs
On Wed, Jul 1, 2015 at 8:16 AM, Boris Zbarsky wrote:
> we'd need to decide what
> https://w3c.github.io/webappsec/specs/powerfulfeatures/#is-origin-trustworthy
> step 5 should mean in our particular case
Colloquially: "would you show a lock?"
Unfortunately, conveying the nuance involved in creat
On Tue, Jul 14, 2015 at 10:06 AM, Gregory Szorc wrote:
> That being said, every other organizations in the world is using the same
> or similar tools and is faced with similar challenges. Lack of a
> commit-skipping feature doesn't hinder other organizations from performing
> major refactorings. S
I'd rather see us solve the individual problems that manifests aim to
solve using some combination of meta tags, link relations and
plain-ol' DOM/JS APIs. The manifest is no better than the former two.
It already replicates features that these provide when it comes to
icons.
In particular, the id
On Wed, Jul 15, 2015 at 4:12 AM, wrote:
> some people believe that web applications should be "installable"
I don't subscribe to that theory. The web is comprised of pages, not
apps. (I mostly agree with Alex, but not regarding the perceived need
for "app discoverability"; I hear Google has a
This sounds like a good idea.
On Jul 15, 2015 10:10 PM, "Jonas Sicking" wrote:
> On Wed, Jul 15, 2015 at 12:42 PM, Jan-Ivar Bruaroey
> wrote:
> > This means it will throw TypeError on set of: MediaSource objects, Blob
> > objects, and File objects, for now.
>
> For what it's worth, I think imple
On Thu, Jul 16, 2015 at 12:26 PM, Anthony Ricaud wrote:
> In order to get accurate data and update it regularly, we need your help.
> Please go to the following etherpad and insert any information that can help
> us:
> https://etherpad.mozilla.org/gecko-web-platform-dashboard
That's a fairly clum
On Thu, Jul 16, 2015 at 5:44 PM, Benjamin Kelly wrote:
>
>
> FWIW, I've sent an intent to implement for the Streams API, but I won't be
> able to actually start work until Q4. I just listed that as "favorable"
> for now. Not sure if we need a clearer "we intend to implement this but
> just haven
I think that building these sorts of features into the web platform at
large is a very bad idea.
I appreciate that we operate under different constraints for Firefox
OS devices that might have native support for IMS on the baseband chip
and that we don't have much hope of convincing the industry o
On Wed, Sep 5, 2018 at 4:42 PM Mark Banner wrote:
> A couple of things that may help with the scrolling & finding, that
> people may or may not have found yet...
The keyboard shortcuts are more accessible (type ? to see the list
[1]), though in my experience they interact poorly with concurrent
m
This seems reasonable, but 50M is a pretty large number. Given the
odds of UTF-8 detection failing, I would have thought that this could
be much lower. What is the number in Chrome?
I assume that other local sources like chrome: are expected to be
annotated properly.
On Mon, Dec 10, 2018 at 11:2
On Thu, Dec 13, 2018 at 1:14 AM Henri Sivonen wrote:
> I changed the limit to 4 MB.
SGTM.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On Fri, Dec 21, 2018 at 3:01 PM Cameron McCormack wrote:
> On Fri, Dec 21, 2018, at 11:05 AM, Thomas Daede wrote:
> > nasm is now required for building on Linux.
>
> Is there a minimum version required? I am getting errors like this
> building:
>
The OP said >= 2.10. But you appear to have tha
On Sat, Jan 19, 2019 at 7:42 AM Emilio Cobos Álvarez
wrote:
> For others (assuming you're hitting the max_post_size limit) I think
> you're out of luck and need to submit them via splinter[2].
>
When vendoring NSS, which we do often, we've sometimes resorted to asking
for review for a script, or
On Thu, Jan 24, 2019 at 8:33 AM Andrea Marchesini
wrote:
> With my proposal, you will have 2 tabs, loading the same origin with 2
> different cookie behaviors.
> Let's assume that one is BEHAVIOR_ACCEPT and the other one BEHAVIOR_REJECT,
> doesn't matter the order.
> The 2 tabs will not be able t
Thanks for the piece about StoragePrincipal. I think that motivates this
well for me. Changing principal is not something we can do trivially (or
not something we should even contemplate ideally).
I do want to pick out one comment you made, which is probably off-topic for
the thread, but I think
Thanks for doing this Johann.
On Tue, Feb 26, 2019 at 12:31 AM Johann Hofmann
wrote:
> The Notifications API [0] allows websites to show notifications outside of
> the browser viewport, integrating into the native OS-like notification
> system. In combination with service workers this can be use
To add to Dan's comments here...
Assuming that I'm reading this correctly [1], the fingerprinting risks are
pretty extreme here. In the touch spec, we have a monotonically increasing
counter that doesn't appear to be origin-bound in any way. What is the
purpose of this identifier? In the light
Is there a way that doesn't rely on eval or eval-like mechanisms?
On Fri, Mar 8, 2019 at 1:55 PM Boris Zbarsky wrote:
> On 3/7/19 6:14 PM, rekt...@gmail.com wrote:
> > Is there any way to feature detect support for import() syntax?
>
> In Firefox, yes, as far as I can tell:
>
>try {
> n
Thanks. (And ugh, but that's how these things go.)
On Fri, Mar 8, 2019 at 2:40 PM Boris Zbarsky wrote:
> On 3/7/19 10:27 PM, Martin Thomson wrote:
> > Is there a way that doesn't rely on eval or eval-like mechanisms?
>
> I suspect the only detectable thing here (and J
On Thu, Mar 21, 2019 at 1:11 PM Tom Ritter wrote:
> Okay, good, not making this data available until the user activity
> engages with the gamepad/VR controller (mostly) assuages my concerns
> on this component. My remaining concern is around the sensitivity of
> axis movement. If I have my contro
This is a great move for improving transparency and accountability of
sites. Good work to all those who helped get us this far.
On Sat, 10 Aug. 2019, 01:02 Ehsan Akhgari, wrote:
> Hi everyone,
>
> We currently allow cross-origin iframes to request notification
> permissions. This is problematic
Hi Sebastian,
I'm glad to see us moving toward having better isolation in this way.
In discussions of this sort of keying strategy, the guidance I repeatedly
hear is that "double-keying" isn't sufficient and that you need to key on
the chain of origins. That is, if A frames B and C, and B in tur
(We’ve had a couple of blog postings about this [1][2], but this list
hasn’t received an explicit intent notice. Now that we’re starting to make
changes, it seems like a good time to correct that oversight.)
TLS 1.0 and 1.1 are old. They are also broken in myriad subtle ways. [3]
explains in mor
On Thu, Sep 12, 2019 at 5:50 PM Henri Sivonen wrote:
> Do we know what the situation looks like for connections to RFC 1918
> addresses?
>
That's a hard one to even speculate about, and that's all we really have
there. Our telemetry doesn't really allow us to gain insight into that.
The big que
Hi Nika, this is great. Is there a documented process for setting up and
maintaining the alias?
On Sat, Sep 21, 2019 at 1:37 AM Nika Layzell wrote:
> As of yesterday, a phabricator reviewers group for WebIDL has been created.
> If your patch needs review for WebIDL changes, you can tag this gro
On Sun, Oct 6, 2019 at 6:35 PM wrote:
> I would agree that these changes and changes that have already occurred
> over the last year or so, have broken access to admin consoles of older
> networking kit. I had to pull a WinXP machine out of storage recently to
> manage an HP 2610 switch.
>
For t
This is somewhat more aggressive than our plans for HTTPS. The usage rate
is significantly higher (that's about 3x) and we don't have DTLS 1.3 yet,
though the spec is now close to publication.
On balance, this is still justifiable given the nature of this feature.
On Fri, Nov 8, 2019 at 5:29 PM
On Fri, Dec 6, 2019 at 5:08 AM wrote:
> >> … Safari, Firefox, Edge and Chrome are removing support for TLS 1.0 and
> 1.1 in March of 2020. …
>
> Is that (timeline) still a _shared_ intent – for all four browsers?
>
I recently confirmed this, yes.
> Re: the screenshot at <
> https://user-images
I agree with this assessment. Maintaining accountability when sites don't
have a window to attribute activity to is a recurrent issue that this group
has never properly resolved. Asking for permission seems to be the defense
of choice, but that only prevents the initiation of unaccountable
activi
This sounds good. In the interests of transparency, it might be good to
get this (and AV1 even) added to our standards positions repo (
https://mozilla.github.io/standards-positions/). I don't know if this
necessarily rises to "important" in the same way that AV1 does, but it
would be good to hav
On Wed, Jun 10, 2020 at 8:01 AM L. David Baron wrote:
> It's also something that I think we shouldn't be doing, at least not
> without a clear and relatively short timeline for having the feature
> available across all graphics backends (whether by implementing it
> for more backends or by no long
Great news JC.
I've been watching this with interest. It's one of those rare cases
where we get a win-win-win. Faster page loads, better security
through more reliable revocation information, and better privacy.
It's taken a lot of effort, but it's definitely worth it.
On Thu, Nov 12, 2020 at
201 - 262 of 262 matches
Mail list logo
