Hi,
What about the WebKit SIG that Jaroslav Reznik wants to setup?
http://lists.fedoraproject.org/pipermail/devel/2010-August/140497.html
-Ilyes Gouta
On Sat, Aug 21, 2010 at 1:28 PM, Ilyes Gouta wrote:
> Matej,
>
>>> and WebKit2 (http://trac.webkit.org/wiki/WebKit2), as a
>>
>> well-maintaine
Matej,
>> and WebKit2 (http://trac.webkit.org/wiki/WebKit2), as a
>
> well-maintained piece of pre-Alpha unreleased code.
I brought this one because of the architecture redesign, that tries to
address some security and performance points, not for the code quality
per se., which is still being wor
Ilyes Gouta, Thu, 19 Aug 2010 21:43:45 +0100:
> How about a very well maintained open source piece of software, such as
> WebKit
which of the two forks of KHTML is well maintained in your opinion?
Google one? (http://spot.livejournal.com/312320.html)
> and WebKit2 (http://trac.webkit.org/wiki/We
On Thu 19 August 2010 15:01:17 Michael Cronenworth wrote:
> Kevin Kofler wrote:
> > Sorry, but I don't think exposing our users to remote arbitrary code
> > execution (!) vulnerabilities just to make web apps a bit faster is a
> > reasonable tradeoff.
>
> Kevin, if you took off your FSF blindfold
On 08/20/2010 12:43 PM, Jon Masters wrote:
> On Fri, 2010-08-20 at 16:55 +0100, Matthew Garrett wrote:
>> On Fri, Aug 20, 2010 at 03:46:11AM +0200, Kevin Kofler wrote:
>
>>> The "lesser of 2 evils" is no solution. Only NO evil at all will keep the
>>> user's freedom. Users should NEVER use propri
On Fri, 2010-08-20 at 16:55 +0100, Matthew Garrett wrote:
> On Fri, Aug 20, 2010 at 03:46:11AM +0200, Kevin Kofler wrote:
> > The "lesser of 2 evils" is no solution. Only NO evil at all will keep the
> > user's freedom. Users should NEVER use proprietary software, be it as
> > JavaScript or usin
On Fri, Aug 20, 2010 at 03:46:11AM +0200, Kevin Kofler wrote:
> Michael Cronenworth wrote:
> > Kevin, if you took off your FSF blindfold you would see that it's better
> > for web sites to use JavaScript. If they complied to /your/ wishes we
> > would have a thousand proprietary protocols, probably
On Fri, Aug 20, 2010 at 1:48 AM, Léon Keijser wrote:
> On Fri, 2010-08-20 at 03:46 +0200, Kevin Kofler wrote:
> > The "lesser of 2 evils" is no solution. Only NO evil at all will keep the
> > user's freedom. Users should NEVER use proprietary software, be it as
> > JavaScript or using a proprieta
On Fri, 2010-08-20 at 03:46 +0200, Kevin Kofler wrote:
> The "lesser of 2 evils" is no solution. Only NO evil at all will keep the
> user's freedom. Users should NEVER use proprietary software, be it as
> JavaScript or using a proprietary protocol.
Shouldn't users be free to make that decision
Michael Cronenworth wrote:
> Kevin, if you took off your FSF blindfold you would see that it's better
> for web sites to use JavaScript. If they complied to /your/ wishes we
> would have a thousand proprietary protocols, probably all /closed/
> source, to communicate in between /closed/ source appl
>> world, is that everything is being done at the application layer
>> (level 4) of the OSI model, a fact which gives a rather unique
Should actually read:
at the application layer
(level 4) of the TCP/IP model, a fact which gives a rather unique
-Ilyes Gouta
On Thu, Aug 19, 2010 at 11:25 PM, J
On 08/19/2010 02:07 PM, Ilyes Gouta wrote:
> Hi,
>
>> As always Kevin I agree with you. These people don't understand basic OSI
>> network layers; rather obvious textbook stuff.
>
> The cool thing about JS and all what's happening today in the browser
> world, is that everything is being done at
Kevin Kofler wrote:
> Sorry, but I don't think exposing our users to remote arbitrary code
> execution (!) vulnerabilities just to make web apps a bit faster is a
> reasonable tradeoff.
Kevin, if you took off your FSF blindfold you would see that it's better
for web sites to use JavaScript. If th
Ilyes Gouta wrote:
> How about a very well maintained open source piece of software, such
> as Firefox, WebKit and WebKit2 (http://trac.webkit.org/wiki/WebKit2),
> as a source of that generated native code at runtime? This would
> immensely help verifying the emitter of such a code and take the
> a
drago01 wrote:
> The same specification can be implemented in 2 perfectly compliant
> ways, one being slow and one being fast.
> An interpreter is inherently slow ;)
Sorry, but I don't think exposing our users to remote arbitrary code
execution (!) vulnerabilities just to make web apps a bit fast
Hi,
>> Still, it's can be correctly designed to really lower the risk (or
>> even eliminate it).
>
> I don't believe the risk can be eliminated entirely. There will always be
> unacceptable risk if you execute native code generated at runtime from an
> untrusted source.
How about a very well main
Hi,
>> Well, that's not what HTML, nor the underlying HTTP, was designed for. I
>> don't see it as being an appropriate platform for software at all. (And I
>> don't see plugins such as Flash as being the solution either. I believe
>> this
>> needs a completely different protocol, e.g. NX is somet
On Thu, Aug 19, 2010 at 8:54 PM, Kevin Kofler wrote:
>> That's what I meant by a (correct) specification and a compliant
>> implementation.
>
> And here too, I'm afraid you're missing the point. The same specification
> can be implemented in 2 perfectly compliant ways, one being secure and one
>
On Thu, Aug 19, 2010 at 2:54 PM, Kevin Kofler wrote:
> Well, that's not what HTML, nor the underlying HTTP, was designed for. I
> don't see it as being an appropriate platform for software at all. (And I
Like it or not, the web browser has become a runtime environment,
capable of executing both F
On Thu, 2010-08-19 at 15:01 -0400, Brandon Lozza wrote:
> If we tolerate any non free software then what's the point? Why not
> just run Windows or OSX?
Received: from mail-fx0-f45.google.com (mail-fx0-f45.google.com
[209.85.161.45]) by smtp-mm1.fedoraproject.org (Postfix) with ESMTP id
B7DB887
>
>
> Well, that's not what HTML, nor the underlying HTTP, was designed for. I
> don't see it as being an appropriate platform for software at all. (And I
> don't see plugins such as Flash as being the solution either. I believe
> this
> needs a completely different protocol, e.g. NX is something g
Ilyes Gouta wrote:
> It's just that, we all being able to pull JS code in plain text from a
> given server, from any place on the world, doesn't really help classifying
> that code as a closed source.
Sorry, but you're arguing against a strawman: I didn't claim that the code
was "closed source",
On Fri, 1994-08-19 at 16:22 +0200, Kevin Kofler wrote:
> I want none of that useless crap, thank you very much! Applications should
> be written as applications, delivered through our package repository, in a
> compiled language. Web sites should just be web sites and have as little
> code as p
Kevin,
> Free Software is not just about availability of source code. (That's exactly
> why the term "Open Source" is misleading!) It's no use having the source
> code if you aren't allowed to legally do anything with it.
I did't claim that JS code is open source. It's just that, we all
being abl
Ilyes Gouta wrote:
> Since JavaScript has a client-side execution model and since the all
> the JS scripts are downloaded in plain text format (even if sometimes
> obfuscated) along with the html code, then can't we assume that JS
> code is available in source format and hence can't be classified a
Hi,
Since JavaScript has a client-side execution model and since the all
the JS scripts are downloaded in plain text format (even if sometimes
obfuscated) along with the html code, then can't we assume that JS
code is available in source format and hence can't be classified as
closed source progra
On Tue, 2010-08-17 at 21:31 +0200, Kevin Kofler wrote:
> Adam Williamson wrote:
> > Shipping a Firefox with no ability to use Javascript would be more or
> > less equal to not shipping it, frankly. No-one would use the thing.
>
> What I suggest is just to use the same old JavaScript interpreter w
Adam Williamson wrote:
> Shipping a Firefox with no ability to use Javascript would be more or
> less equal to not shipping it, frankly. No-one would use the thing.
What I suggest is just to use the same old JavaScript interpreter we have
used before the JIT was introduced, which they undoubtedly
On Mon, 2010-08-16 at 18:35 -0500, Bruno Wolff III wrote:
> While I think Firefox could do several things to increase it's real
> security instead of it's apparent security, I was actually complaining
> about the server side. Sites that use javascript encourage people to
Then why were you doing i
On 08/17/2010 03:22 AM, Gregory Maxwell wrote:
> On Mon, Aug 16, 2010 at 8:01 PM, Manuel Wolfshant
> wrote:
>
>>Do you REALLY believe that in a world where 90% of the desktops are
>> Windows, where 2 thirds of the browser market is shared by IE and safari
>> and where making governments to
On 08/17/2010 03:15 AM, Orcan Ogetbil wrote:
> On Mon, Aug 16, 2010 at 8:01 PM, Manuel Wolfshant wrote:
>
>>Do you REALLY believe that in a world where 90% of the desktops are
>> Windows, where 2 thirds of the browser market is shared by IE and safari
>>
>
> Where did you got these stat
On Mon, Aug 16, 2010 at 8:01 PM, Manuel Wolfshant
wrote:
> Do you REALLY believe that in a world where 90% of the desktops are
> Windows, where 2 thirds of the browser market is shared by IE and safari
> and where making governments to share public documents in a public
> format rather than .do
On Mon, Aug 16, 2010 at 17:08:27 -0700,
"J. Randall Owens" wrote:
>
> Maybe you should file a bug against Javascript in Firefox? Oh, wait,
> bugzilla uses Javascript, doesn't it? Scratch that, no bugzilla for the
> purists.
I don't use it with javascript enabled. Unfortunately the javascript
On Mon, Aug 16, 2010 at 8:01 PM, Manuel Wolfshant wrote:
> Do you REALLY believe that in a world where 90% of the desktops are
> Windows, where 2 thirds of the browser market is shared by IE and safari
Where did you got these statistics from? Any references? w3schools [1]
say it is otherwise, i
On 16/08/10 08:10 AM, Brandon Lozza wrote:
>
> By your logic we should ban gcc, java, mono, python, perl, bash ... as
> one can use them to create and/or run non free software.
>
> Also you may be aware that javascript has its uses *outside* of the
> web too (just like you can wri
On 08/16/2010 16:35 -0700, Bruno Wolff III wrote:
> On Mon, Aug 16, 2010 at 15:48:14 -0700,
> Adam Williamson wrote:
>>
>> Meanwhile, back in the real world, it is effectively impossible to use
>> all sorts of useful websites without Javascript enabled. Even for
>
> Then don't use them. If site
On 08/17/2010 02:35 AM, Bruno Wolff III wrote:
> On Mon, Aug 16, 2010 at 15:48:14 -0700,
> Adam Williamson wrote:
>
>> Meanwhile, back in the real world, it is effectively impossible to use
>> all sorts of useful websites without Javascript enabled. Even for
>>
>
> Then don't use them. I
On Mon, 2010-08-16 at 18:35 -0500, Bruno Wolff III wrote:
> On Mon, Aug 16, 2010 at 15:48:14 -0700,
> Adam Williamson wrote:
> >
> > Meanwhile, back in the real world, it is effectively impossible to use
> > all sorts of useful websites without Javascript enabled. Even for
>
> Then don't use t
On Mon, Aug 16, 2010 at 15:48:14 -0700,
Adam Williamson wrote:
>
> Meanwhile, back in the real world, it is effectively impossible to use
> all sorts of useful websites without Javascript enabled. Even for
Then don't use them. If sites don't get used they may stop requiring
people to significa
On Sun, 2010-08-15 at 19:31 -0500, Bruno Wolff III wrote:
> I think using javascript for pages meant to be used by the general public
> is a bad idea. It encourages people who don't know better to enable
> javascript for general browsing, which signifcantly increases the risks
> to them for having
>
>
> By your logic we should ban gcc, java, mono, python, perl, bash ... as
> one can use them to create and/or run non free software.
>
> Also you may be aware that javascript has its uses *outside* of the
> web too (just like you can write apps in python you can do it in JS;
> and having a JIT t
I've already seen websites exploit firefox tabs and they made use of my
gmail account to send spam.
Why should we make firefox easier to exploit?
On Mon, Aug 16, 2010 at 5:07 AM, drago01 wrote:
> On Mon, Aug 16, 2010 at 1:15 AM, Kevin Kofler
> wrote:
> > drago01 wrote:
> >> The times where jav
On Mon, Aug 16, 2010 at 1:15 AM, Kevin Kofler wrote:
> drago01 wrote:
>> The times where javascript is only used for some fancy effects are
>> long over ... welcome to 2010 ;)
>
> Some web sites are indeed abusing JavaScript. Why should we promote this
> behavior? It is a vehicle for proprietary s
On Sun, Aug 15, 2010 at 8:31 PM, Bruno Wolff III wrote:
> On Sun, Aug 15, 2010 at 16:44:29 -0700,
> Matt McCutchen wrote:
>> On Mon, 2010-08-16 at 01:15 +0200, Kevin Kofler wrote:
>> > Some web sites are indeed abusing JavaScript.
>>
>> > A web site is
>> > not and should not be an application,
On Sun, Aug 15, 2010 at 16:44:29 -0700,
Matt McCutchen wrote:
> On Mon, 2010-08-16 at 01:15 +0200, Kevin Kofler wrote:
> > Some web sites are indeed abusing JavaScript.
>
> > A web site is
> > not and should not be an application, an application is not and should not
> > be a web site.
>
> J
Matt McCutchen wrote:
> If you use a non-free web site, you have already lost the freedom to
> read, distribute, and modify the code you are relying on
> (http://www.gnu.org/philosophy/who-does-that-server-really-serve.html).
> I fail to see how running the site's non-free JavaScript for the sole
>
On Mon, 2010-08-16 at 01:15 +0200, Kevin Kofler wrote:
> Some web sites are indeed abusing JavaScript.
> A web site is
> not and should not be an application, an application is not and should not
> be a web site.
Just because you said so? Web applications bring enormous practical
benefits to t
drago01 wrote:
> The times where javascript is only used for some fancy effects are
> long over ... welcome to 2010 ;)
Some web sites are indeed abusing JavaScript. Why should we promote this
behavior? It is a vehicle for proprietary software, where people often
aren't even aware they're using n
On Sun, Aug 15, 2010 at 10:49 PM, Matt McCutchen wrote:
> On Sun, 2010-08-15 at 22:41 +0200, drago01 wrote:
>> On Sun, Aug 15, 2010 at 9:45 PM, Matt McCutchen
>> wrote:
>> > On Sun, 2010-08-15 at 18:26 +0200, Kevin Kofler wrote:
>> >> But the end effect is, we're allowing a web browser to disabl
On Sun, 2010-08-15 at 22:41 +0200, drago01 wrote:
> On Sun, Aug 15, 2010 at 9:45 PM, Matt McCutchen
> wrote:
> > On Sun, 2010-08-15 at 18:26 +0200, Kevin Kofler wrote:
> >> But the end effect is, we're allowing a web browser to disable memory
> >> protection, exposing all users to a severe securi
On Sun, Aug 15, 2010 at 9:45 PM, Matt McCutchen wrote:
> On Sun, 2010-08-15 at 18:26 +0200, Kevin Kofler wrote:
>> But the end effect is, we're allowing a web browser to disable memory
>> protection, exposing all users to a severe security risk from merely
>> browsing web sites. IMHO, the performa
On Sun, 2010-08-15 at 18:26 +0200, Kevin Kofler wrote:
> But the end effect is, we're allowing a web browser to disable memory
> protection, exposing all users to a severe security risk from merely
> browsing web sites. IMHO, the performance improvements in JavaScript aren't
> worth that risk.
52 matches
Mail list logo
