On Tue, Apr 25, 2017 at 5:26 PM, Salvador de la Puente <
sdelapue...@mozilla.com> wrote:
> So the risk is not that high since if the image is not protected I can get
> it and do evil things without requiring the Light Sensor API. Isn't it?
>
Generally, we take cross-origin information theft prett
So the risk is not that high since if the image is not protected I can get
it and do evil things without requiring the Light Sensor API. Isn't it?
On Wed, Apr 26, 2017 at 1:30 AM, Eric Rescorla wrote:
>
>
> On Tue, Apr 25, 2017 at 3:40 PM, Salvador de la Puente <
> sdelapue...@mozilla.com> wrote
On Tue, Apr 25, 2017 at 3:40 PM, Salvador de la Puente <
sdelapue...@mozilla.com> wrote:
> The article says:
>
> Embed an image from the attacked domain; generally this will be a resource
> > which varies for different authenticated users such as the logged-in
> user’s
> > avatar or a security cod
The article says:
Embed an image from the attacked domain; generally this will be a resource
> which varies for different authenticated users such as the logged-in user’s
> avatar or a security code.
>
And then refers all the steps to this image (binarizing, expand and measure
per pixel) but, If
Sorry for my ignorance but, in the case of Stealing cross-origin resources,
I don't get the point of the attack. If have the ability to embed the image
in step 1, why to not simply send this to evil.com for further processing?
How it is possible for evil.com to get access to protected resources?
O
On Tuesday, April 25, 2017 at 1:20:29 PM UTC-4, Boris Zbarsky wrote:
> On 4/25/17 1:07 PM, Alexander Surkov wrote:
> > I bet there's always room for improvements, and I hope this was a
> > counterpoint for the example only, not for the bug organization approach.
>
> Sort of.
>
> It was a counter
I'm about to land some patches[1] that will allow configure to detect a
Visual C++ 2017 installation. You should be able to launch a
MozillaBuild `start-shell.bat` shell and build without having to have
the Visual C++ environment configured. The only thing that will change
from the current state of
On 04/25/2017 08:20 PM, Boris Zbarsky wrote:
On 4/25/17 1:07 PM, Alexander Surkov wrote:
I bet there's always room for improvements, and I hope this was a counterpoint
for the example only, not for the bug organization approach.
Sort of.
It was a counterpoint to "just check the bug; all the
On 04/25/2017 10:25 AM, Andrew Overholt wrote:
On Tue, Apr 25, 2017 at 9:35 AM, Eric Rescorla wrote:
Going back to Jonathan's (I think) question. Does anyone use this at all in
the field?
Chrome's usage metrics say <= 0.0001% of page loads:
https://www.chromestatus.com/metrics/feature/popula
On Tue, Apr 25, 2017 at 5:41 AM, Henri Sivonen wrote:
> What problem did you mean to address by code signing?
The reason I suggested code signing is because loading libvoikko would
provide an easy way for people to inject code into Firefox. For a while
we've been trying to make it difficult for
On 4/25/17 1:07 PM, Alexander Surkov wrote:
I bet there's always room for improvements, and I hope this was a counterpoint
for the example only, not for the bug organization approach.
Sort of.
It was a counterpoint to "just check the bug; all the info is there".
Often it's not there, or not
CSS may implement a 3 state light level for most use cases of this metric,
I would suggest that would be much better.
According to the removal bug I raised, it looks like the spec has vastly
changed anyway:
https://bugzilla.mozilla.org/show_bug.cgi?id=1359076#c7
I have a patch ready to measure al
Those stats aren't the old version of the spec, Google is pushing this
constructor version however the old version as mentioned in the issues is
event driven.
We perhaps remove safely for insecure based on previous comments though.
On Tue, Apr 25, 2017 at 4:46 PM, Eric Rescorla wrote:
> This su
On Tuesday, April 25, 2017 at 11:11:28 AM UTC-4, Boris Zbarsky wrote:
> On 4/25/17 10:50 AM, Alexander Surkov wrote:
> > I don't want to affirm that this approach suites every Mozilla module, but
> > it seems be working well in relatively small modules like accessibility one.
>
> Just as a counte
The W3C is proposing a new charter for:
Publishing Working Group
https://www.w3.org/2017/04/publ-wg-charter/
https://lists.w3.org/Archives/Public/public-new-work/2017Apr/0002.html
Mozilla has the opportunity to register support, comments, or
objections through Sunday, May 14, 2017.
Please
The W3C is proposing a revised charter for:
TV Control Working Group
https://www.w3.org/2017/03/tvcontrol.html
https://lists.w3.org/Archives/Public/public-new-work/2017Mar/0010.html
Changes from previous charter:
https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2016%2F0
This suggests that maybe we could just turn it off
On Tue, Apr 25, 2017 at 7:25 AM, Andrew Overholt
wrote:
> On Tue, Apr 25, 2017 at 9:35 AM, Eric Rescorla wrote:
>
>> Going back to Jonathan's (I think) question. Does anyone use this at all
>> in
>> the field?
>>
>
> Chrome's usage metrics say
On 4/25/17 10:50 AM, Alexander Surkov wrote:
I don't want to affirm that this approach suites every Mozilla module, but it
seems be working well in relatively small modules like accessibility one.
Just as a counterpoint... as non-regular contributor to the
accessibility module, I have a _very
On Tuesday, April 18, 2017 at 6:53:14 PM UTC-4, smaug wrote:
> On 04/18/2017 04:24 PM, Ehsan Akhgari wrote:
> > On 2017-04-18 12:30 AM, Mike Hommey wrote:
> >>> I've yet to see that to happen. What is crucial is fast way to browse
> >>> through the blame in time. So commit messages should be short
On Tue, Apr 25, 2017 at 9:35 AM, Eric Rescorla wrote:
> Going back to Jonathan's (I think) question. Does anyone use this at all in
> the field?
>
Chrome's usage metrics say <= 0.0001% of page loads:
https://www.chromestatus.com/metrics/feature/popularity#AmbientLightSensorConstructor.
We are go
On 04/24/2017 06:04 PM, Martin Thomson wrote:
I think that 60Hz is too high a rate for this.
I suggest that we restrict this to top-level, foreground, and secure
contexts. Note that foreground is a necessary precondition for the
attack, so that restriction doesn't really help here. Critically,
Going back to Jonathan's (I think) question. Does anyone use this at all in
the field?
-Ekr
On Tue, Apr 25, 2017 at 6:10 AM, Kurt Roeckx wrote:
> On 2017-04-25 00:04, Martin Thomson wrote:
> > I think that 60Hz is too high a rate for this.
> >
> > I suggest that we restrict this to top-level,
On 2017-04-25 00:04, Martin Thomson wrote:
> I think that 60Hz is too high a rate for this.
>
> I suggest that we restrict this to top-level, foreground, and secure
> contexts. Note that foreground is a necessary precondition for the
> attack, so that restriction doesn't really help here. Critic
On Wed, Apr 19, 2017 at 4:43 AM, Ehsan Akhgari wrote:
> On 2017-04-18 2:38 AM, Henri Sivonen wrote:
>> On Sat, Apr 15, 2017 at 8:06 PM, Ehsan Akhgari
>> wrote:
>>> On 2017-03-27 3:30 AM, Henri Sivonen wrote:
2) We couldn't trigger a libvoikko autoupdate on Windows/Mac if there
was a c
24 matches
Mail list logo
