Re: [webkit-dev] Proposal: add Privacy to WebKit Project Goals

2020-02-16 Thread Maciej Stachowiak 


> On Feb 16, 2020, at 8:43 PM, Brent Fulgham  wrote:
> 
> 
> 
>> On Feb 16, 2020, at 12:39 PM, Maciej Stachowiak > > wrote:
>> 
>> 
>> There hasn’t been any feedback on this, so below is a proposed change (in 
>> PrettyPatch HTML format) to > >.
>> 
>> In addition to adding Privacy as a goal, I also added Battery Life, and 
>> tweaked a few of the existing goals.
>> 
>> Thoughts?
>> 
>> 
>> project-new.html
>> 
>>  32Privacy
>>  33Users want their privacy respected. We avoid directly violating the 
>> user's privacy, and strive to prevent websites and other parties from doing 
>> so.
> 
> The term “directly violating” sounds a little soft. Do we not care about 
> indirect privacy violations?

My intent was to express that the browser engine itself will not spy on you, in 
addition to our measures to prevent websites from doing so. I’m not sure what 
you think would count as indirectly violating the users privacy which would not 
be websites or other parties violating the user’s privacy, but I’ll try to 
reword it.

> 
> I don’t know the right wording to use, but I would like to say something 
> along the lines of:
> 
> “Users want their privacy respected. We avoid violating the user’s privacy, 
> and strive to prevent websites and other parties form doing so, too. We view 
> the UserAgent’s primary responsibility to be protecting the interests of the 
> user. We therefore do not support or intend to implement web standards that 
> are at odds with these goals, or that create mechanisms to fingerprint or 
> otherwise monitor user behavior.”

This seems unnecessarily combative. Also perhaps not entirely true. There’s 
lots of fingerprinting surface in the web platform, and we have not removed all 
of it.

I’ll make an attempt to write this more clearly.

 - Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Clearing old reviews from the queue

2020-02-16 Thread Dean Jackson 


> On 16 Feb 2020, at 17:46, Alexey Proskuryakov  wrote:
> 
> 
> 
>> 16 февр. 2020 г., в 7:52, Dean Jackson  написал(а):
>> 
>> Does anyone oppose clearing all review requests that are older than 6 
>> months? (or 1 year?)
> 
> Looking at ancient patches in the review queue, quite a few look like they 
> should still work (e.g. adding new tests). So said that we are not keeping up 
> with reviews, even for simple patches.

It is very sad.

> 
>> I tried to use the bugzilla API to do this, but I couldn't work out how to 
>> detect the attachment state properly. I looked at the source code for the 
>> queue page and it uses custom SQL :)
> 
> What were you trying to do, and how far did you get?

I started explaining to you where I failed, which caused me to read the 
documentation again, and I think I've now got it. I thought that the review 
status was kept in a side table, but it's not.

Basically I now have a script that:

- for each open bug
  - for each attachment
- if !is_patch, continue
- if is_obsolete, continue
- for each flag
  - if name is "r" and status is "?"
- if creation_time is older than 1 year
  - Set flag to r- and leave a "sorry we missed you" message
- if creator is "a...@webkit.org "
  - Set flag to r+

So, if we're happy with the 1 year timeout, I'll run this.

Dean

> 
> - Alexey
> 
>> (It's easy to do with the GitHub API)
>> 
>> Dean
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> 



smime.p7s
Description: S/MIME cryptographic signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Proposal: add Privacy to WebKit Project Goals

2020-02-16 Thread Brent Fulgham 


> On Feb 16, 2020, at 12:39 PM, Maciej Stachowiak  wrote:
> 
> 
> There hasn’t been any feedback on this, so below is a proposed change (in 
> PrettyPatch HTML format) to  >.
> 
> In addition to adding Privacy as a goal, I also added Battery Life, and 
> tweaked a few of the existing goals.
> 
> Thoughts?
> 
> 
> project-new.html
> 
>  32Privacy
>  33Users want their privacy respected. We avoid directly violating the 
> user's privacy, and strive to prevent websites and other parties from doing 
> so.

The term “directly violating” sounds a little soft. Do we not care about 
indirect privacy violations?

I don’t know the right wording to use, but I would like to say something along 
the lines of:

“Users want their privacy respected. We avoid violating the user’s privacy, and 
strive to prevent websites and other parties form doing so, too. We view the 
UserAgent’s primary responsibility to be protecting the interests of the user. 
We therefore do not support or intend to implement web standards that are at 
odds with these goals, or that create mechanisms to fingerprint or otherwise 
monitor user behavior.”

Thanks,

-Brent


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Clearing old reviews from the queue

2020-02-16 Thread Alexey Proskuryakov 


> 16 февр. 2020 г., в 7:52, Dean Jackson  написал(а):
> 
> Does anyone oppose clearing all review requests that are older than 6 months? 
> (or 1 year?)

Looking at ancient patches in the review queue, quite a few look like they 
should still work (e.g. adding new tests). So said that we are not keeping up 
with reviews, even for simple patches.

> I tried to use the bugzilla API to do this, but I couldn't work out how to 
> detect the attachment state properly. I looked at the source code for the 
> queue page and it uses custom SQL :)

What were you trying to do, and how far did you get?

- Alexey

> (It's easy to do with the GitHub API)
> 
> Dean
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Proposal: add Privacy to WebKit Project Goals

2020-02-16 Thread Maciej Stachowiak 

There hasn’t been any feedback on this, so below is a proposed change (in 
PrettyPatch HTML format) to .

In addition to adding Privacy as a goal, I also added Battery Life, and tweaked 
a few of the existing goals.

Thoughts?


project-new.html
  WebKit is an open source Web content engine for browsers and other 
applications.
1212
1313
14 We value real-world web compatibility, standards compliance, stability, 
performance, security, portability, usability, and relative ease of 
understanding and modifying the code (hackability).
 14We value real-world web compatibility, standards compliance, stability, 
performance, battery life, security, privacy, portability, usability, and 
relative ease of understanding and modifying the code (hackability).
1515Project Goals
1616Web Content Engine
17 The project’s primary focus is content deployed on the World Wide Web, 
using standards-based technologies such as HTML, CSS, JavaScript and the DOM. 
However, we also want to make it possible to embed WebKit in other 
applications, and to use it as a general-purpose display and interaction 
engine.
 17The project’s primary focus is content deployed on the World Wide Web, 
using standards-based technologies such as HTML, CSS, JavaScript and DOM. 
However, we also want to make it possible to embed WebKit in other 
applications, and to use it as a general-purpose display and interaction 
engine.
1818Open Source
1919WebKit should remain freely usable for both open source and proprietary 
applications. To that end, we use BSD-style and LGPL licenses. Specifically, we 
aim for licensing compatible with LGPL 2.1+. We do not currently plan to move 
to LGPL 3. In addition, we strive to create a courteous, welcoming environment 
that feels approachable to newcomers. WebKit maintains a public IRC chat room 
and a public mailing list where the ideas of contributors both new and old are 
heard and discussed with equal weight.
2020Compatibility

2424Stability
2525The main WebKit code base should always maintain a high degree of 
stability. This means that crashes, hangs and regressions should be dealt with 
promptly, rather than letting them pile up.
2626Performance
27 Maintaining and improving speed and memory use is an important goal. We 
never consider performance “good enough”, but strive to constantly improve. As 
web content becomes richer and more complex, and as web browsers run on more 
limited devices, performance gains continue to have value even if normal 
browsing seems fast enough.
 27Maintaining and improving speed and memory use is an important goal. We 
never consider performance “good enough”, but strive to constantly improve. As 
web content becomes richer and more complex, and as web browsers run on more 
limited devices, performance gains continue to have value even if normal 
browsing seems fast enough. We consider speed, memory use, responsiveness and 
frame rate to be important aspects of performance.
 28Battery Life
 29In addition to traditional performance metrics, we aim to minimize power 
consumption to maximize browsing battery life for portable devices.
2830Security
2931Protecting users from security violations is critical. We fix security 
issues promptly to protect users and maintain their trust.
 32Privacy
 33Users want their privacy respected. We avoid directly violating the 
user's privacy, and strive to prevent websites and other parties from doing 
so.
3034Portability
3135The WebKit project seeks to address a variety of needs. We want to make 
it reasonable to port WebKit to a variety of desktop, mobile, embedded and 
other platforms. We will provide the infrastructure to do this with tight 
platform integration, reusing native platform services where appropriate and 
providing friendly embedding APIs.
3236Usability___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Clearing old reviews from the queue

2020-02-16 Thread Ryosuke Niwa 
Sounds reasonable to me although I’d suggest older than 1 year instead of 6
months since I don’t think 6 months is long enough to render a patch
completely obsolete in many cases.

- R. Niwa

On Sun, Feb 16, 2020 at 07:53 Dean Jackson  wrote:

> Does anyone oppose clearing all review requests that are older than 6
> months? (or 1 year?)
>
> I tried to use the bugzilla API to do this, but I couldn't work out how to
> detect the attachment state properly. I looked at the source code for the
> queue page and it uses custom SQL :)
>
> (It's easy to do with the GitHub API)
>
> Dean
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
-- 
- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Request for position on Badging API

2020-02-16 Thread Ryosuke Niwa 
For the record, we have two concerns raised internally at Apple:
 * The integration of this API with push service worker would require
running scripts in order to update the badge. This will pose a serious
power consumption issue.
 * We don’t want every website to start using this API to increase
“engagement”.

- R. Niwa

On Sun, Jan 19, 2020 at 16:27 Matt Giuca  wrote:

> Hi WebKit team,
>
> I have previously proposed the Badging API (
> https://github.com/WICG/badging) to provide websites with a mechanism to
> set a badge (a small dot or number) on the current document's tab, or for
> installed applications, on the app icon in the system shelf or home screen.
>
> Would WebKit / Safari be interested in implementing the API now or in the
> future?
>
> We are planning to ship in Chromium soon:
>
> https://groups.google.com/a/chromium.org/g/blink-dev/c/fHc49JNFTAU/m/bJD25Yr7CAAJ
>
> Regards
>
>
> Matt Giuca
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
-- 
- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Request for position on Badging API

2020-02-16 Thread Dean Jackson 
Not speaking for all of WebKit, and definitely not all of Apple, but I think 
this seems like a good idea.

I'm not sure I get the distinction between app badges and document badges 
though. I'd also like to see some specification text describing how the browser 
should ignore multiple set/clear operations executed in rapid succession (e.g. 
to create a blinking badge) - maybe the limit is one badge operation per minute 
or something?

Also, given that the main use case for this would be alerting the user to a 
notification, it seems like it should be able to link it directly to that. This 
would provide the ability for a push notification to trigger the badge without 
ever firing up the page context.

Dean

> On 19 Jan 2020, at 4:26 pm, Matt Giuca  wrote:
> 
> Hi WebKit team,
> 
> I have previously proposed the Badging API (https://github.com/WICG/badging 
> ) to provide websites with a mechanism to 
> set a badge (a small dot or number) on the current document's tab, or for 
> installed applications, on the app icon in the system shelf or home screen.
> 
> Would WebKit / Safari be interested in implementing the API now or in the 
> future?
> 
> We are planning to ship in Chromium soon:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/fHc49JNFTAU/m/bJD25Yr7CAAJ
>  
> 
> 
> Regards
> 
> Matt Giuca
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev



smime.p7s
Description: S/MIME cryptographic signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Clearing old reviews from the queue

2020-02-16 Thread Dean Jackson 
Does anyone oppose clearing all review requests that are older than 6 months? 
(or 1 year?)

I tried to use the bugzilla API to do this, but I couldn't work out how to 
detect the attachment state properly. I looked at the source code for the queue 
page and it uses custom SQL :)

(It's easy to do with the GitHub API)

Dean



smime.p7s
Description: S/MIME cryptographic signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev