Re: Proper way to return nsresult from Rust before Stylo is mandatory?

[Michael Layzell]

There are patches up for nserror bindings in bug 1320179 (
https://bugzilla.mozilla.org/show_bug.cgi?id=1320179).

If people have API design opinions, you can let me know on the bug.

On Mon, Mar 27, 2017 at 10:22 PM, Ehsan Akhgari 
wrote:

> On 2017-03-27 5:10 PM, Michael Layzell wrote:
> > I don't think it would be too hard. At one point I had a WIP patch which
> > implemented it, but I would have to dig it up again.
> >
> > I'll see if I can get a patch up for the crate in my spare time.
>
> Thank you!
>
> > On Sun, Mar 26, 2017 at 11:26 PM, Ehsan Akhgari  > > wrote:
> >
> > On 2017-03-17 10:08 AM, Michael Layzell wrote:
> > > I don't think we have any particularity good tools for this right
> now. A
> > > while ago I filed https://bugzilla.mozilla.org/
> show_bug.cgi?id=1320179
> >  to
> > > add a separate crate like the nsstring crate which provides the
> nsresult
> > > bindings. If we are starting to get more use cases for it we
> probably want
> > > to implement something like it which moves the error code
> definition code
> > > into python or similar, and then generates both rust and C++
> bindings in
> > > the outdir.
> >
> > I think the right way to do it is to have an nsresult crate as you
> > suggest.  How much work would that be?
> >
> > As far as code parsing goes, we already have nsError.h, so why can't
> we
> > just use rustbindgen?  But I guess moving the definitions elsewhere
> and
> > generating the headers out of them is easy as well.  The build
> system's
> > support for generated files is pretty good as far as I know.
> Whichever
> > way is easier is better, I guess!
> >
> >
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: CSS property `line-height-step`

[Tantek Çelik]

On Fri, Mar 31, 2017 at 1:16 PM, fantasai  wrote:
> On 03/31/2017 07:55 AM, L. David Baron wrote:
>>
>> On Friday 2017-03-31 12:11 +0800, Tommy Kuo wrote:
>>>
>>> **Summary**
>>>
>>> I am intent to implement the property `line-height-step`. And it would be
>>> disabled behind the pref `layout.css.line-height-step.enabled` by default.
>>> It is a property to make authors create the content with vertical rhythm
>>> easier.
>>>
>>> **Link to standard**
>>>
>>> CSS Rhythmic Sizing
>>> 
>>
>>
>> So in the discussions in the working group, I've been somewhat
>> skeptical that this feature does a good job of addressing the design
>> use cases that it's intended to address.
>
>
> As the co-editor of the spec, I agree with David Baron's concerns.
>
> Also, based on my discussions with Dave Cramer (CSSWG member who works
> in the publishing industry), my understanding is that the the most
> common problems are situations that need to be solved with block height
> stepping, not line height stepping. An author can fairly easily ensure
> that, within a paragraph, the line height follows a strict vertical
> rhythm: as long as the text is not interrupted by atomic inline content
> or text that has a larger font size / different vertical alignment (and
> this covers the majority of text), it will maintain rhythm. But when the
> paragraph text is interrupted by different content such as illustrations
> and headings, then the rhythm can be thrown off. These are block-level
> intrusions into the rhythm, and won't be solved (without hacks like
> turning them into inline-blocks) by line height stepping. But they are
> solved by block height stepping (which is also outlined in that draft).
>
> I think we should endeavor to avoid “solutions” that require hacks, so
> my advice would be to implement block height stepping first, since it
> will more directly solve most of the use cases. I'm less convinced that
> line height stepping is necessary; and also there are many issues with
> inline layout that need to be addressed before it can be an effective
> solution to the problems it addresses.
>
> * Note that even for headings, which are text, it is the margin-box of
> the heading as a whole which needs to fit into the rhythm, not necessarily
> each line of it; headings usually have large margins, but the text is set
> closely between lines. Similar concerns apply to blockquotes with smaller
> text, figures with captions, and other block-level interruptions to prose.

Completely agreed re: the prioritization of block height stepping
before line height stepping and the respective design use-cases.

The issues noted here, and the summaries of use-cases are worthy of
explicitly including in the spec. Perhaps even a coarser change like
noting/listing block height stepping *before* line height stepping
both in the introduction and structure of the overall document.

I'll file spec issues accordingly to discuss separately from this
intent to implement thread.

Thanks fantasai.

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

Re: Intent to implement: CSS property `line-height-step`

[fantasai]

On 03/31/2017 07:55 AM, L. David Baron wrote:

On Friday 2017-03-31 12:11 +0800, Tommy Kuo wrote:

**Summary**

I am intent to implement the property `line-height-step`. And it would be 
disabled behind the pref `layout.css.line-height-step.enabled` by default. It 
is a property to make authors create the content with vertical rhythm easier.

**Link to standard**

CSS Rhythmic Sizing



So in the discussions in the working group, I've been somewhat
skeptical that this feature does a good job of addressing the design
use cases that it's intended to address.


As the co-editor of the spec, I agree with David Baron's concerns.

Also, based on my discussions with Dave Cramer (CSSWG member who works
in the publishing industry), my understanding is that the the most
common problems are situations that need to be solved with block height
stepping, not line height stepping. An author can fairly easily ensure
that, within a paragraph, the line height follows a strict vertical
rhythm: as long as the text is not interrupted by atomic inline content
or text that has a larger font size / different vertical alignment (and
this covers the majority of text), it will maintain rhythm. But when the
paragraph text is interrupted by different content such as illustrations
and headings, then the rhythm can be thrown off. These are block-level
intrusions into the rhythm, and won't be solved (without hacks like
turning them into inline-blocks) by line height stepping. But they are
solved by block height stepping (which is also outlined in that draft).

I think we should endeavor to avoid “solutions” that require hacks, so
my advice would be to implement block height stepping first, since it
will more directly solve most of the use cases. I'm less convinced that
line height stepping is necessary; and also there are many issues with
inline layout that need to be addressed before it can be an effective
solution to the problems it addresses.

* Note that even for headings, which are text, it is the margin-box of
the heading as a whole which needs to fit into the rhythm, not necessarily
each line of it; headings usually have large margins, but the text is set
closely between lines. Similar concerns apply to blockquotes with smaller
text, figures with captions, and other block-level interruptions to prose.

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

Re: Revocation protocol idea

[Salvador de la Puente]

Hi Johann

On Thu, Mar 23, 2017 at 6:37 PM, Johann Hofmann 
wrote:

> Hey,
>
> concerns about the viability of such a decentralized systems aside, I
> still don't understand the advantage of blocking on an API level vs. simply
> showing the SafeBrowsing error page that we currently have in place.
>

I think I explained my self badly. It is not on an API level, it on origin
level but it should be a P2P protocol where not  one actor only has full
control of that list. Entries on that list would be agreed on a network
scale, so the peers agree that a domain is harmful.


>
> Why would we continue to allow a user to visit a clearly harmful page?
>

Well, it depends. I remember a couple of occasions where Pirate Bay was
blocked. It was one of the mirrors that appeared after closing the original
site. The SafeBrowsing UI was not informing me about the potential damage I
could suffer. It only talked about phishing. I wanted to contiue browsing.

In my opinion, the final decision should come from the user. That said, it
does not mean the UI could encourage to not doing it.


>
> You're saying that a user should be allowed to shoot their own feet. How
> would that be different from the existing permission prompts? This sounds
> like it could be easily maneuvered with some social engineering from the
> website.
>

Several times you propose new functionallity to the Web, spec editors must
to remove some features because of potential danger. It means that the
legit usage is useful but if abused, it would be bad for the user. The
protocol would allow to decrease the risk of shipping powerful APIs.


>
> Your proposal says " what happens from here is up to the browser". This
> doesn't really make a good impression to me as a browser developer since it
> appears like important UI questions are just hand-waved away in your
> concept.
>

Then the explanation is badly worded. Sorry. What I wanted to mean is that
once, a Web property is declared harmful, it is not part of the protocol to
decide what happens next. Firefox could decide to let the user decide while
SuperSafeBrowser woud decide to not do it.

The protocol can give recommendations of what to be shown and I see this as
an opportunity to research on "important UI questions" as you said.


>
> Cheers,
>
> Johann


Thank you for your comments.


>
>
> On 23/03/2017 02:09, Jonathan Kingston wrote:
>
>> This seems a little like the idea WOT(https://www.mywot.com/) had,
>> Showing
>> the user that they might be looking at a website that isn't considered
>> great but isn't perhaps bad enough to be blocked.
>>
>> I agree that one web actor owning this power isn't a great place to be in
>> and that in itself might be enough justification in at least looking
>> further into this direction.
>>
>> If there was enough evidence to suggest we should revoke an advert
>> providers ability to track someone without breaking the web that might be
>> interesting.
>> There is also some research (which I am not sure I can share publicly) to
>> suggest we should limit API usage to avoid security flaws within browsers
>> based upon a strong correlation of Lines of Code, CVE's and the low number
>> of sites that use those APIs. Perhaps there is a rationale to make
>> websites
>> earn enough trust for new features that have a high risk. For example
>> would
>> Reddits sub resources really need WebVR or WebGL?
>> But we would also have to counter the cost of building this over just
>> making the APIs secure in the first place and also understand we would
>> hurt
>> web innovation with that too.
>>
>> On Tue, Mar 21, 2017 at 10:11 PM, Eric Rescorla  wrote:
>>
>> There seem to be three basic ideas here:
>>>
>>> 0. Blacklisting at the level of API rather than site.
>>> 1. Some centralized but democratic  mechanism for building a list of
>>> misbehaving sites.
>>> 2. A mechanism for distributing the list of misbehaving sites to clients.
>>>
>>> As Jonathan notes, Firefox already has a mechanism for doing #2, which is
>>> to say
>>> "Safe Browsing". Now, Safe Browsing is binary, either a site is good or
>>> bad, but
>>> specific APIs aren't disabled, but it's easy to see how you would extend
>>> it to that
>>> if you actually wanted to provide that function. I'm not sure that's
>>> actually
>>> very attractive--it's hard enough for users to understand safe browsing.
>>> Safe
>>> Browsing is of course centralized, but that comes with a number of
>>> advantages
>>> and it's not clear what the advantage of decentralized blacklist
>>> dissemination
>>> is, given the networking realities.
>>>
>>> You posit a mechanism for forming the list of misbehaving sites, but
>>> distributed
>>> reputation is really hard, and it's not clear that Google is actually
>>> doing a bad
>>> job of running Safe Browsing, so given that this is a fairly major
>>> unsolved problem,
>>> I'd be reluctant to set out to build a mechanism like this without a
>>> pretty clear
>>> design.
>>>

Re: Rationalising Linux audio backend support

[Chris Coulson]

On 31/03/17 05:52, burmar...@gmail.com wrote:
> Ubuntu just re-enabled ALSA on their latest Firefox 52.0.2 release. Go Ubuntu!
It's enabled, but please see the small-print in the changelog
description at
https://launchpad.net/ubuntu/+source/firefox/52.0.2+build1-0ubuntu0.16.04.1.
The Firefox package in Ubuntu is maintained by 1 contributor in his
spare time and myself who is only able to do the minimum in order to
provide updates, so Ubuntu flavors that don't ship Pulseaudio need to
step up to maintain this code if they want it to continue working and
don't want it to be disabled again in a future update.

Regards
- Chris
> So thankfully I and many others can now forget about this sorry business.
>
> Martin Burke
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform




signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Revocation protocol idea

[Salvador de la Puente]

Hi Jonathan

On Thu, Mar 23, 2017 at 9:09 AM, Jonathan Kingston 
wrote:

> This seems a little like the idea WOT(https://www.mywot.com/) had,
> Showing the user that they might be looking at a website that isn't
> considered great but isn't perhaps bad enough to be blocked.
>

Yes. I talk about it in
https://salvadelapuente.com/posts/2016/07/29/towards-the-web-of-trust/


>
> I agree that one web actor owning this power isn't a great place to be in
> and that in itself might be enough justification in at least looking
> further into this direction.
>
> If there was enough evidence to suggest we should revoke an advert
> providers ability to track someone without breaking the web that might be
> interesting.
> There is also some research (which I am not sure I can share publicly) to
> suggest we should limit API usage to avoid security flaws within browsers
> based upon a strong correlation of Lines of Code, CVE's and the low number
> of sites that use those APIs. Perhaps there is a rationale to make websites
> earn enough trust for new features that have a high risk. For example would
> Reddits sub resources really need WebVR or WebGL?
>

That's very interesting. Could you share those correlations with me
privately? Of course, the tools needed to perform the software reviews
could be supported by automatic tools. Here is a value proposition coming
from browser vendors or anyone who want to adhere to the protocol.


> But we would also have to counter the cost of building this over just
> making the APIs secure in the first place and also understand we would hurt
> web innovation with that too.
>

Ideally, the protocol is intended to worry "not too much" about misusing
powerful APIs and so, to boost Web innovation and experimentation.


>
> On Tue, Mar 21, 2017 at 10:11 PM, Eric Rescorla  wrote:
>
>> There seem to be three basic ideas here:
>>
>> 0. Blacklisting at the level of API rather than site.
>> 1. Some centralized but democratic  mechanism for building a list of
>> misbehaving sites.
>> 2. A mechanism for distributing the list of misbehaving sites to clients.
>>
>> As Jonathan notes, Firefox already has a mechanism for doing #2, which is
>> to say
>> "Safe Browsing". Now, Safe Browsing is binary, either a site is good or
>> bad, but
>> specific APIs aren't disabled, but it's easy to see how you would extend
>> it to that
>> if you actually wanted to provide that function. I'm not sure that's
>> actually
>> very attractive--it's hard enough for users to understand safe browsing.
>> Safe
>> Browsing is of course centralized, but that comes with a number of
>> advantages
>> and it's not clear what the advantage of decentralized blacklist
>> dissemination
>> is, given the networking realities.
>>
>> You posit a mechanism for forming the list of misbehaving sites, but
>> distributed
>> reputation is really hard, and it's not clear that Google is actually
>> doing a bad
>> job of running Safe Browsing, so given that this is a fairly major
>> unsolved problem,
>> I'd be reluctant to set out to build a mechanism like this without a
>> pretty clear
>> design.
>>
>> -Ekr
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Mar 21, 2017 at 2:40 PM, Salvador de la Puente <
>> sdelapue...@mozilla.com> wrote:
>>
>>> Hi Jonathan
>>>
>>> In the short and medium terms, it scales better than a white list and
>>
>> distributes the effort of finding APIs misuses. Mozilla and other vendor
>>> browser could still review the code of the site and add its vote in
>>> favour
>>> or against the Web property.
>>>
>>> In the long term, the system would help finding new security threats
>>> such a
>>> tracking or fingerprinting algorithms by encouraging the honest report of
>>> evidences, somehow.
>>>
>>> With this system, the threat is considered the result of both potential
>>> risk and chances of actual misuse. The revocation protocol reduces
>>> threatening situations by minimising the number of Web properties abusing
>>> the APIs.
>>>
>>> As a side effect, it provides the infrastructure for a real distributed
>>> and
>>> cross browser database which can be of utility for other unforeseen uses.
>>>
>>> What do you think?
>>>
>>>
>>> El 8 mar. 2017 10:54 p. m., "Jonathan Kingston" 
>>> escribió:
>>>
>>> Hey,
>>> What would be the advantage of using this over the safesite list?
>>> Obviously
>>> there would be less broken sites on the web as we would be permitting the
>>> site to still be viewed by the user rather than just revoking the
>>> permission but are there other advantages?
>>>
>>> On Sun, Mar 5, 2017 at 4:23 PM, Salvador de la Puente <
>>> sdelapue...@mozilla.com> wrote:
>>>
>>> > Hi, folks.
>>> >
>>> > Some time ago, I've started to think about an idea to experiment with
>>> new
>>> > powerful Web APIs: a sort of "deceptive site" database for harmful
>>> uses of
>>> > browsers APIs. I've been curating that idea and come up with the
>>> concept of
>>> > a "revocation protocol" 

Re: realtime audio on linux

[milasudril]

Den lördag 16 juli 2016 kl. 00:47:00 UTC+2 skrev Robert O'Callahan:
> On Sat, Jul 16, 2016 at 5:09 AM, Steve Fink  wrote:
> 
> > I know it's kind of crazy given our garbage-collected, single content
> > process world, but reading this thread makes me wonder what it would take
> > to use the browser to implement a real linux-hosted audio workstation-type
> > app. As in, something that requires truly low-latency audio with mixing. My
> > (years stale) understanding is that pulseaudio is kind of the wrong model,
> > and can't really offer the right guarantees at an architectural level. ALSA
> > is, as ever, a mess, and just because you can play sound through ALSA on
> > one hardware configuration doesn't really mean much for other drivers.
> >
> > Last I knew, JACK was the only way to get basically no dropouts and still
> > be able to do nontrivial audio processing. But a JACK backend for the
> > browser just seems kind of silly; it's too much of a niche "market" to try
> > for anytime soon.
> >
> 
> A JACK backend for cubeb, hence Firefox, exists but isn't compiled into
> Mozilla builds.
> 
> The Web Audio API lets audio processing run on its own real-time thread,
> and that's what Gecko does, although on Linux unprivileged users running
> Firefox can't give that thread real-time priority.
> 
> Rob
> -- 
> lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
> toD
> selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
> rdsme,aoreseoouoto
> o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
> lurpr
> .a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
> esn

Unless root has desired that they can. On ubuntu: 
/etc/security/limits.d/audio.conf. And users that uses JACK is member in the 
audio group.

# Provided by the jackd package.
#
# Changes to this file will be preserved.
#

@audio   -  rtprio 95
@audio   -  memlockunlimited
#@audio   -  nice  -19
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: CSS property `line-height-step`

[L. David Baron]

On Friday 2017-03-31 12:11 +0800, Tommy Kuo wrote:
> **Summary**
> 
> I am intent to implement the property `line-height-step`. And it would be 
> disabled behind the pref `layout.css.line-height-step.enabled` by default. It 
> is a property to make authors create the content with vertical rhythm easier.
> 
> **Link to standard**
> 
> CSS Rhythmic Sizing
> 

So in the discussions in the working group, I've been somewhat
skeptical that this feature does a good job of addressing the design
use cases that it's intended to address.

I think there are two issues with it:

First, in many cases, the goal of setting up vertical rhythm is to
ensure that different (adjacent) pieces of text have the same
rhythm, where by different pieces of text I mean things like text on
opposite pages, text in different columns, text in a float and in
the normal flow, or similar things.  'line-height-step' only
addresses this use case if the developer is *extremely* disciplined
to ensure that nothing other than line-height (e.g., border,
padding, margin) causes vertical spacing.  My sense was that the
line grid proposals were significantly better at addressing this use
case (since they established an overall grid), although they were
harder to implement (because they complicate things like sliding an
element's position in the block axis).

Second, I think the rhythm that line-height-step sets up probably
isn't the most desirable one.  I'd expect that it is preferable to
have the baseline of each line match the rhythm, but
line-height-step does not ensure this.  For example, if most lines
have a line box height that matches the step, but there is something
tall on a line (say, an image protruding upwards) that makes its
line box height initially (without the adjustment from the step) 2.1
times the step height, then the line with the tall thing on it gets
an additional 0.45 multiple of the step height on each side, which
means the baseline of the text is 0.45 times the step height above
the rhythm, so instead of having an appearance of skipping two lines
and then having a baseline at the correct position, you get
(ignoring the thing that protrudes above) the appearance of skipping
1.55 lines, having a misaligned baseline (0.45 above the rhythm
poisition), and then skipping the remaining 0.45.  I'd have thought
it would be preferable to put all the extra space above in this case
in order to keep the baseline matching the rhythm.  (In some cases
this would require an additional multiple of the step height.)  I
might be wrong about this, though; it's worth consulting designers
about what behavior is actually desirable.

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: PGP signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Revocation protocol idea

[Eric Rescorla]

On Fri, Mar 31, 2017 at 4:20 AM, Salvador de la Puente <
sdelapue...@mozilla.com> wrote:

> Hi Eric
>
> On Wed, Mar 22, 2017 at 6:11 AM, Eric Rescorla  wrote:
>
>> There seem to be three basic ideas here:
>>
>> 0. Blacklisting at the level of API rather than site.
>> 1. Some centralized but democratic  mechanism for building a list of
>> misbehaving sites.
>> 2. A mechanism for distributing the list of misbehaving sites to clients.
>>
>
> I think I did not explain it well. It would be a black list on site level
> and it would not be centralised but distributed.
>

I had understood your point that it would be centrally organized but
democratically decided and then
distributed to users.


The idea is that is a site is harmful for the user, all their permissions
> should be revoked and we shuold communicate the user why this site is
> harmful. The list of misbehaving sites, the reasons of why them are
> dangerous and the evidence supporting misbehaving should be in a
> cross-browser distrubuted DB.
>

Yes, I understood that.


As Jonathan notes, Firefox already has a mechanism for doing #2, which is
>> to say
>> "Safe Browsing". Now, Safe Browsing is binary, either a site is good or
>> bad, but
>> specific APIs aren't disabled, but it's easy to see how you would extend
>> it to that
>> if you actually wanted to provide that function. I'm not sure that's
>> actually
>> very attractive--it's hard enough for users to understand safe browsing.
>> Safe
>> Browsing is of course centralized, but that comes with a number of
>> advantages
>> and it's not clear what the advantage of decentralized blacklist
>> dissemination
>> is, given the networking realities.
>>
>> You posit a mechanism for forming the list of misbehaving sites, but
>> distributed
>> reputation is really hard, and it's not clear that Google is actually
>> doing a bad
>> job of running Safe Browsing, so given that this is a fairly major
>> unsolved problem,
>> I'd be reluctant to set out to build a mechanism like this without a
>> pretty clear
>> design.
>>
>
> I've been looking at this paper on prediction markets based on BitCoin
> 
> for inspiration. It is true that distributed reputation is a hard problem
> but I think we could adapt the concepts on that paper to this scenario if
> reviewers "bet" on site reputation and there is some incentive. Of course,
> further research is needed to mitigate the chance for a reviewer to lie in
> its report and prevent forms of Sybil attack but it seems to be some
> solutions out there.
>

As I said, we have mechanisms that seem to me to be doing a fairly adequate
job at this general class of problem, with the major drawback being that
they are centralized. I'm not saying that that couldn't be addressed, but
it doesn't seem like such a solution is ready to hand. As such, this seems
like it is fairly far outside the realm of anything Firefox would do in in
the short to medium term.

-Ekr


>
>>
>> -Ekr
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Mar 21, 2017 at 2:40 PM, Salvador de la Puente <
>> sdelapue...@mozilla.com> wrote:
>>
>>> Hi Jonathan
>>>
>>> In the short and medium terms, it scales better than a white list and
>>
>> distributes the effort of finding APIs misuses. Mozilla and other vendor
>>> browser could still review the code of the site and add its vote in
>>> favour
>>> or against the Web property.
>>>
>>> In the long term, the system would help finding new security threats
>>> such a
>>> tracking or fingerprinting algorithms by encouraging the honest report of
>>> evidences, somehow.
>>>
>>> With this system, the threat is considered the result of both potential
>>> risk and chances of actual misuse. The revocation protocol reduces
>>> threatening situations by minimising the number of Web properties abusing
>>> the APIs.
>>>
>>> As a side effect, it provides the infrastructure for a real distributed
>>> and
>>> cross browser database which can be of utility for other unforeseen uses.
>>>
>>> What do you think?
>>>
>>>
>>> El 8 mar. 2017 10:54 p. m., "Jonathan Kingston" 
>>> escribió:
>>>
>>> Hey,
>>> What would be the advantage of using this over the safesite list?
>>> Obviously
>>> there would be less broken sites on the web as we would be permitting the
>>> site to still be viewed by the user rather than just revoking the
>>> permission but are there other advantages?
>>>
>>> On Sun, Mar 5, 2017 at 4:23 PM, Salvador de la Puente <
>>> sdelapue...@mozilla.com> wrote:
>>>
>>> > Hi, folks.
>>> >
>>> > Some time ago, I've started to think about an idea to experiment with
>>> new
>>> > powerful Web APIs: a sort of "deceptive site" database for harmful
>>> uses of
>>> > browsers APIs. I've been curating that idea and come up with the
>>> concept of
>>> > a "revocation protocol" to revoke user granted permissions for origins
>>> > abusing those APIs.
>>> >
>>> > 

Re: Revocation protocol idea

[Salvador de la Puente]

Hi Eric

On Wed, Mar 22, 2017 at 6:11 AM, Eric Rescorla  wrote:

> There seem to be three basic ideas here:
>
> 0. Blacklisting at the level of API rather than site.
> 1. Some centralized but democratic  mechanism for building a list of
> misbehaving sites.
> 2. A mechanism for distributing the list of misbehaving sites to clients.
>

I think I did not explain it well. It would be a black list on site level
and it would not be centralised but distributed.
The idea is that is a site is harmful for the user, all their permissions
should be revoked and we shuold communicate the user why this site is
harmful. The list of misbehaving sites, the reasons of why them are
dangerous and the evidence supporting misbehaving should be in a
cross-browser distrubuted DB.


>
> As Jonathan notes, Firefox already has a mechanism for doing #2, which is
> to say
> "Safe Browsing". Now, Safe Browsing is binary, either a site is good or
> bad, but
> specific APIs aren't disabled, but it's easy to see how you would extend
> it to that
> if you actually wanted to provide that function. I'm not sure that's
> actually
> very attractive--it's hard enough for users to understand safe browsing.
> Safe
> Browsing is of course centralized, but that comes with a number of
> advantages
> and it's not clear what the advantage of decentralized blacklist
> dissemination
> is, given the networking realities.
>
> You posit a mechanism for forming the list of misbehaving sites, but
> distributed
> reputation is really hard, and it's not clear that Google is actually
> doing a bad
> job of running Safe Browsing, so given that this is a fairly major
> unsolved problem,
> I'd be reluctant to set out to build a mechanism like this without a
> pretty clear
> design.
>

I've been looking at this paper on prediction markets based on BitCoin

for inspiration. It is true that distributed reputation is a hard problem
but I think we could adapt the concepts on that paper to this scenario if
reviewers "bet" on site reputation and there is some incentive. Of course,
further research is needed to mitigate the chance for a reviewer to lie in
its report and prevent forms of Sybil attack but it seems to be some
solutions out there.


>
> -Ekr
>
>
>
>
>
>
>
> On Tue, Mar 21, 2017 at 2:40 PM, Salvador de la Puente <
> sdelapue...@mozilla.com> wrote:
>
>> Hi Jonathan
>>
>> In the short and medium terms, it scales better than a white list and
>
> distributes the effort of finding APIs misuses. Mozilla and other vendor
>> browser could still review the code of the site and add its vote in favour
>> or against the Web property.
>>
>> In the long term, the system would help finding new security threats such
>> a
>> tracking or fingerprinting algorithms by encouraging the honest report of
>> evidences, somehow.
>>
>> With this system, the threat is considered the result of both potential
>> risk and chances of actual misuse. The revocation protocol reduces
>> threatening situations by minimising the number of Web properties abusing
>> the APIs.
>>
>> As a side effect, it provides the infrastructure for a real distributed
>> and
>> cross browser database which can be of utility for other unforeseen uses.
>>
>> What do you think?
>>
>>
>> El 8 mar. 2017 10:54 p. m., "Jonathan Kingston" 
>> escribió:
>>
>> Hey,
>> What would be the advantage of using this over the safesite list?
>> Obviously
>> there would be less broken sites on the web as we would be permitting the
>> site to still be viewed by the user rather than just revoking the
>> permission but are there other advantages?
>>
>> On Sun, Mar 5, 2017 at 4:23 PM, Salvador de la Puente <
>> sdelapue...@mozilla.com> wrote:
>>
>> > Hi, folks.
>> >
>> > Some time ago, I've started to think about an idea to experiment with
>> new
>> > powerful Web APIs: a sort of "deceptive site" database for harmful uses
>> of
>> > browsers APIs. I've been curating that idea and come up with the
>> concept of
>> > a "revocation protocol" to revoke user granted permissions for origins
>> > abusing those APIs.
>> >
>> > I published the idea on GitHub [1] and I was wondering about the utility
>> > and feasibility of such a system so I would thank any feedback you want
>> to
>> > provide.
>> >
>> > I hope it will be of interest for you.
>> >
>> > [1] https://github.com/delapuente/revocation-protocol
>> >
>> > --
>> > 
>> > ___
>> > dev-platform mailing list
>> > dev-platform@lists.mozilla.org
>> > https://lists.mozilla.org/listinfo/dev-platform
>> >
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>


-- 

___
dev-platform mailing list
dev-platform@lists.mozilla.org

Re: Rationalising Linux audio backend support

[Robert O'Callahan]

On Fri, Mar 31, 2017 at 7:45 PM,   wrote:
> Good choice from Ubuntu. In the meantime, I have run PA->aloop->JACK. Now I 
> am back with aloop->JACK. PA is removed from the system (and hopefully, I 
> will never need it again). I turned on telemetry for now, but will turn it 
> off when #1345661 has been resolved. As I said, the true solution for Firefox 
> is to use PortAudio. No need for libcubeb.

We looked at PortAudio a long time ago and it had major problems.
Apparently it still did as of 2014:
http://camlorn.net/posts/december2014/horror-of-audio-output.html

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr  esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Rationalising Linux audio backend support

[milasudril]

Den fredag 31 mars 2017 kl. 06:52:18 UTC+2 skrev burm...@gmail.com:
> Ubuntu just re-enabled ALSA on their latest Firefox 52.0.2 release. Go Ubuntu!
> 
> So thankfully I and many others can now forget about this sorry business.
> 
> Martin Burke

Good choice from Ubuntu. In the meantime, I have run PA->aloop->JACK. Now I am 
back with aloop->JACK. PA is removed from the system (and hopefully, I will 
never need it again). I turned on telemetry for now, but will turn it off when 
#1345661 has been resolved. As I said, the true solution for Firefox is to use 
PortAudio. No need for libcubeb.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform