Re: Re: KDE and Google Summer of Code 2018
On Jan 19, 2018 6:11 PM, "pointedstick" wrote: > > While we're at it, let's not only re-work existing KCMs, but try to take the opportunity to simplify and consolidate where possible. For example, the Launch Feedback KCM consists only of two checkboxes that could easily be moved elsewhere (the cursor part into the Cursors KCM, and the Task Manager part into individual Task Manager widgets' settings, perhaps?) Good points. The Fx Speed in the compositing kcm could also fit in the Effects kcm. Greetings, Clemens. > On Fri, 19 Jan 2018 09:06:52 -0800 David Edmundson wrote > > > > > >On Fri, Jan 19, 2018 at 4:41 PM, Marco Martin wrote: > >On venerdì 19 gennaio 2018 13:42:25 CET David Edmundson wrote: > > > Note that they'll be finishing GSOC around the same time as 5.14, so that > > > potentially means GSOC work released in 5.15. > > > We shouldn't pick high priority ones that we want done before then. > > > > basing on the priorities recorded in https://phabricator.kde.org/project/view/ > > 254/ > > > > a possible list, among the "medium": > > * removable devices > > * printers > > * spell check > > * formats > > > > among the "high", but we can live if gets delayed a bit: > > * mouse (can of worms?) > > * date/time > > * user manager > > > > other suggestions? > > > > > > > >Mouse is maybe covered by Roman's existing task? > >Printers isn't part of Plasma, we need to check with the author. > > > > > > > >But I think all of them are good options. > > > > > > > > > >They're not the same size, I don't think working on date and time would take up 3 months. > >Maybe we can group a few of the simpler ones together? > > > > > >Go for it. > >You can put me down in the list of mentors. > > > > > >David > > > > > > > > > > > > -- > > Marco Martin > > > > > > > > > > > > > > > >
Re: Input on privacy goal
Am Freitag, 19. Januar 2018, 15:30:25 CET schrieb Volker Krause: Hi, > Here are some thoughts on threat models for this, as a possible way to > better capture what we want to achieve. that's a good start! I'd like to add 6) Rogue local software Assume you run any kind of software not coming from a trusted source (your distribution). E.g. you clone a github repo and run the code. That code may pull in further untrusted dependencies (maven, node, ...). It should be easy to protect your personal data, kwallets, browser history, etc. and local network from that code. Possible counter-measures: easy and configurable sandboxing Thanks Carsten
Re: Re: KDE and Google Summer of Code 2018
While we're at it, let's not only re-work existing KCMs, but try to take the opportunity to simplify and consolidate where possible. For example, the Launch Feedback KCM consists only of two checkboxes that could easily be moved elsewhere (the cursor part into the Cursors KCM, and the Task Manager part into individual Task Manager widgets' settings, perhaps?) Nate On Fri, 19 Jan 2018 09:06:52 -0800 David Edmundson wrote > > >On Fri, Jan 19, 2018 at 4:41 PM, Marco Martin wrote: >On venerdì 19 gennaio 2018 13:42:25 CET David Edmundson wrote: > > Note that they'll be finishing GSOC around the same time as 5.14, so that > > potentially means GSOC work released in 5.15. > > We shouldn't pick high priority ones that we want done before then. > > basing on the priorities recorded in https://phabricator.kde.org/project/view/ > 254/ > > a possible list, among the "medium": > * removable devices > * printers > * spell check > * formats > > among the "high", but we can live if gets delayed a bit: > * mouse (can of worms?) > * date/time > * user manager > > other suggestions? > > > >Mouse is maybe covered by Roman's existing task? >Printers isn't part of Plasma, we need to check with the author. > > > >But I think all of them are good options. > > > > >They're not the same size, I don't think working on date and time would take >up 3 months. >Maybe we can group a few of the simpler ones together? > > >Go for it. >You can put me down in the list of mentors. > > >David > > > > > > -- > Marco Martin > > > > > > >
Re: KDE and Google Summer of Code 2018
On Fri, Jan 19, 2018 at 4:41 PM, Marco Martin wrote: > On venerdì 19 gennaio 2018 13:42:25 CET David Edmundson wrote: > > Note that they'll be finishing GSOC around the same time as 5.14, so that > > potentially means GSOC work released in 5.15. > > We shouldn't pick high priority ones that we want done before then. > > basing on the priorities recorded in https://phabricator.kde.org/ > project/view/ > 254/ > > a possible list, among the "medium": > * removable devices > * printers > * spell check > * formats > > among the "high", but we can live if gets delayed a bit: > * mouse (can of worms?) > * date/time > * user manager > > other suggestions? > Mouse is maybe covered by Roman's existing task? Printers isn't part of Plasma, we need to check with the author. But I think all of them are good options. They're not the same size, I don't think working on date and time would take up 3 months. Maybe we can group a few of the simpler ones together? Go for it. You can put me down in the list of mentors. David > > -- > Marco Martin >
Re: KDE and Google Summer of Code 2018
On venerdì 19 gennaio 2018 13:42:25 CET David Edmundson wrote: > Note that they'll be finishing GSOC around the same time as 5.14, so that > potentially means GSOC work released in 5.15. > We shouldn't pick high priority ones that we want done before then. basing on the priorities recorded in https://phabricator.kde.org/project/view/ 254/ a possible list, among the "medium": * removable devices * printers * spell check * formats among the "high", but we can live if gets delayed a bit: * mouse (can of worms?) * date/time * user manager other suggestions? -- Marco Martin
Re: Input on privacy goal
> On 19 Jan 2018, at 11:30, Volker Krause wrote:
>
>> On Friday, 19 January 2018 14:49:58 CET Sebastian Kügler wrote:
>> I'd like to collect some more input from the wider KDE community about our
>> privacy goal for the next years. If you're unsure what I'm talking about,
>> please have a look at https://vizzzion.org/blog/2017/11/kdes-goal-privacy/
>
> Here are some thoughts on threat models for this, as a possible way to better
> capture what we want to achieve.
>
> (1) Public Wifi
>
> Assume anyone can see your Wifi network traffic (e.g. via recent
> vulnerabilities in WPA2). Using your device in such an environment should be
> safe and not compromise your privacy any more compared to using a wired
> network at home.
>
> Possible counter-measures: Encrypted communication, VPN.
Since (I think) iOS 10, the Wi-Fi configuration gives pretty loud warnings if
you connect to an unsecured Wi-Fi network. Perhaps the Plasma NetworkManager
applet needs similar UI improvements in that area.
> (2) Stolen Device
> (3) Mega Corporations ("Google")
> (4) Global Surveillance ("NSA")
> (5) Targeted Surveillance ("Snowden")
>
> What else? Which of those do we want to address? Do you think that's a useful
> approach to guide/validate our work?
We may need more stuff related to our own services. Do we have a privacy policy
in all websites that need one? What can we use logs for?
And maybe we should have a proper internal policy of what info KDE sysadmins
are allowed to peek into, and for what purposes.
--
Nicolás
Re: Input on privacy goal
On Friday, 19 January 2018 14:49:58 CET Sebastian Kügler wrote:
> I'd like to collect some more input from the wider KDE community about our
> privacy goal for the next years. If you're unsure what I'm talking about,
> please have a look at https://vizzzion.org/blog/2017/11/kdes-goal-privacy/
Here are some thoughts on threat models for this, as a possible way to better
capture what we want to achieve.
(1) Public Wifi
Assume anyone can see your Wifi network traffic (e.g. via recent
vulnerabilities in WPA2). Using your device in such an environment should be
safe and not compromise your privacy any more compared to using a wired
network at home.
Possible counter-measures: Encrypted communication, VPN.
(2) Stolen Device
Assume your device gets stolen in a switched off or locked screen state. This
should not result in a disclosure of personal data.
Possible counter-measures: Local encryption.
(3) Mega Corporations ("Google")
It should be possible to enjoy the benefits of state-of-the-art consumer
electronics, communication and content without individual companies creating
detailed user profiles.
Possible counter-measures: Free alternatives for proprietary services.
(4) Global Surveillance ("NSA")
Assume the entire Internet traffic being recorded, as well as deliberate
attempts to break or weaken encryption.
Possible counter-measures: State of the art encryption, minimize network
communication, Tor.
(5) Targeted Surveillance ("Snowden")
Could be politically motivated or industrial espionage, by an actor with
significant skill and resources.
Possible counter-measures: ???
What else? Which of those do we want to address? Do you think that's a useful
approach to guide/validate our work?
Regards,
Volker
signature.asc
Description: This is a digitally signed message part.
Input on privacy goal
Hi all, I'd like to collect some more input from the wider KDE community about our privacy goal for the next years. If you're unsure what I'm talking about, please have a look at https://vizzzion.org/blog/2017/11/kdes-goal-privacy/ Specifically, I'm collecting input on the following questions / topics: * What are your plans, plans within your subproject regarding privacy? * What are, in your opinions the greatest challenges for KDE, within your subproject or in general? * How do you think we can get closer to our goal? * Where do you think we stand currently? * Anything else? I know, I'm vague and this is a rather open question. I'm after a bigger picture and overview of what's going on in the community, knowing what's going on and what should be, and more buy-in from community members towards specific actions. Thanks for your input already! -- sebas http://www.kde.org | http://vizZzion.org
Re: KDE and Google Summer of Code 2018
On Fri, Jan 19, 2018 at 9:42 AM, Marco Martin wrote: > On Mon, Jan 15, 2018 at 8:15 PM, Nate Graham > wrote: > > I've submitted an idea for System Settings: Improve handling for > touchpads > > and mice with Libinput > > Speaking of systemsettings, would be a good fit porting to qml some > medium-to-big kcm? > It's perfect. Though I'd like us to emphasise that it's not just about doing a simple 1:1 switch of the UI layer but building on Andy's mockups with a UI redesign, doing a code tidy up, and fixing any relevant open bugs in that module at the same time. Note that they'll be finishing GSOC around the same time as 5.14, so that potentially means GSOC work released in 5.15. We shouldn't pick high priority ones that we want done before then. David
