| *** ChanServ sets mode: +o sailbot | 06:59 | |
| sledges | #startmeeting Sailfish OS, open source, collaboration -- 8th April 2021 | 07:00 |
|---|---|---|
| sailbot | Meeting started Thu Apr 8 07:00:02 2021 UTC. The chair is sledges. Information about MeetBot at http://wiki.debian.org/MeetBot. | 07:00 |
| sailbot | Useful Commands: #action #agreed #help #info #idea #link #topic. | 07:00 |
| *** sailbot changes topic to " (Meeting topic: Sailfish OS, open source, collaboration -- 8th April 2021)" | 07:00 | |
| sledges | #link https://forum.sailfishos.org/t/community-meeting-on-irc-8th-apr-2021/5653 | 07:00 |
| sledges | I am the meeting's chairperson today, and will be doing my best to keep time and order. Please respect the timings and beerhave. | 07:00 |
| sledges | #topic Brief introduction (5 min). Please prefix your name/handle with #info | 07:00 |
| *** sailbot changes topic to "Brief introduction (5 min). Please prefix your name/handle with #info (Meeting topic: Sailfish OS, open source, collaboration -- 8th April 2021)" | 07:00 | |
| ViGe | #info Ville Nummela - Sailor @ Jolla | 07:00 |
| Setok | #info Kristoffer Lawson - CEO & Founder, Attractive.ai | 07:01 |
| jpetrell_ | #info Joona Petrell - Sailor @ Jolla | 07:01 |
| sledges | #info Simonas Leleiva -- privateer for Jolla | 07:01 |
| rubdos[ma] | #info Ruben De Smet - Whisperfish developer @ community | 07:01 |
| Thaodan | #info Björn Bidar - Sailor @ Jolla | 07:02 |
| jojo94 | #info jojo94 - SFOS user | 07:02 |
| abranson | #info Andrew Branson - sailor @ Jolla | 07:02 |
| karry | #info Lukas Karas - community developer | 07:02 |
| flypig | #info David Llewellyn-Jones - sailor @ jolla | 07:03 |
| GabrielMargiani[ | #info Gabriel Margiani - community | 07:03 |
| Tomin | #info Tomi Leppänen - sailor @ Jolla | 07:03 |
| lbt | #info David Greaves - sailor @ Jolla | 07:04 |
| sledges | nice, both heroes to the two today's questions have checked in:) | 07:05 |
| sledges | #topic Sharing plug-ins and Sailjail (10 min -- asked by rubdos) | 07:05 |
| *** sailbot changes topic to "Sharing plug-ins and Sailjail (10 min -- asked by rubdos) (Meeting topic: Sailfish OS, open source, collaboration -- 8th April 2021)" | 07:05 | |
| sledges | #info <rubdos> For an application to be able to share pictures/videos with another application, it sends DBus commands. Sailjail’d applications need specific dbus channels whitelisted. | 07:05 |
| sledges | #info <rubdos> 1. Having sharing from gallery to Whisperfish would be desirable. Some way to implement this, even unofficial/non-harbour/unstable/changing-in-every-release would be very nice. | 07:05 |
| sledges | #info <rubdos> 2. We propose a Sharing permission, which allows an application to share with another application. This Sharing permission includes all permissions from e.g. /etc/sailjail/permissions/sharing.d, in which other applications can dump their dbus-permissions. Cfr. PR and specifically this comment: | 07:05 |
| sledges | #link https://gitlab.com/rubdos/whisperfish/-/merge_requests/127#note_544317678 | 07:06 |
| sledges | #info <rubdos> 3. Sailjail is not a stable API. We are not asking to stabilize; we merely want to join the experiment. | 07:06 |
| sledges | #info <rubdos> 4. If Jolla would agree to have an experimental sharing.d directory-approach, me or @gamag would be happy to contribute this patch. | 07:06 |
| ExTechOp | Sorry, a bit late: #info Otto Mäkelä, community | 07:06 |
| sledges | #info <rubdos> So, I would like to hear/discuss two things: | 07:06 |
| sledges | #info <rubdos> 1. Whether Jolla would accept such a patch. | 07:06 |
| sledges | #info <rubdos> 2. Whether Jolla would agree with the above approach, and if not, I’d like to discuss what other approaches you have in mind. | 07:06 |
| sledges | #info <Jolla> Sharing is currently implemented as in-process pages and not considered a public 3rd party API. Loading sensitive accounts in 3rd party process is not a secure solution, for proper 3rd party API the sharing flows need to be implemented as a separate process. | 07:07 |
| sledges | #info <Jolla> We are actively discussing how to enable sharing flows for 3rd party, but don't have schedule to share at this point. | 07:07 |
| rubdos[ma] | Hmm. Not sure how to respond to that. | 07:08 |
| rubdos[ma] | Gabriel Margiani, you've got anything to add? | 07:08 |
| GabrielMargiani[ | well - handling the sharing within a 3rd party app is what we try to implement ... | 07:09 |
| rubdos[ma] | Maybe we could have you noted that if Jolla wants feedback on what they are discussing in-house, we are open to giving feedback :-) | 07:11 |
| sledges | do you agree with the mentioned security aspects? | 07:11 |
| flypig | If I understand correctly, the problem here is that the Gallery would be running Whisperfish code, which would essentially grant Whisperfish all of Gallery's permissions. | 07:11 |
| GabrielMargiani[ | Ah, no, we try to do everything in whisperfish, just call it from the gallery via dbus | 07:11 |
| GabrielMargiani[ | yes, otherwise there would be a security problem | 07:12 |
| rubdos[ma] | AFAIK, the implementation that Gabriel Margiani proposed just required the Gallery to have an additional "sharing" permission, where it would be allowed to call `be.rubdos.whisperfish.share` or the like. | 07:12 |
| jpetrell_ | there are two use cases: app wanting to share, and app wanting to be a share option | 07:12 |
| rubdos[ma] | Our case is "being a share option" | 07:13 |
| rubdos[ma] | (the other way around makes sense too) | 07:13 |
| GabrielMargiani[ | the other way is much easier, since we are not in sailjail | 07:13 |
| rubdos[ma] | (and if we were, we could grant the permissions to us ourselves...) | 07:14 |
| pvuorela | in a way that d-bus api is also a wider thing: apps wanting to offer public methods that should be available for sailjailed apps. | 07:14 |
| rubdos[ma] | I suppose it doesn't solely apply to sharing then indeed. | 07:14 |
| abranson | yeah, that sounds like the logical way for apps to define a permission so that other apps can use their services/data | 07:14 |
| pvuorela | for the sharing api itself, i'm having some hopes we could have more secure out-of-process way in not too far future. been even discussing that. | 07:15 |
| abranson | but the sharing thing will have to be done through some broker. it'll get a bit messy if every app can add a dbus service to a 'sharing' permission. | 07:15 |
| rubdos[ma] | Hmm, might make sense indeed. | 07:16 |
| diegoc | Sorry I'm late! | 07:17 |
| sledges | better late than never:) | 07:17 |
| rubdos[ma] | It doesn't need to be a very complex broken though, I imagine. | 07:17 |
| rubdos[ma] | broker, that is | 07:18 |
| GabrielMargiani[ | it still needs permission to call other apps, though, right? | 07:18 |
| jpetrell_ | moving the sharing pages out-of-process does not sound like a too much of an effort. the bad thing UX-wise is the navigation between separate windows being a bit cumbersome, ideally we would implement similar back-stepping gestures for such chained out-of-process flows as we have for the internal app pages | 07:18 |
| abranson | but enforcing permissions has really highlighted the lack of separation between apps when sharing is involved. every app needs every other app's permissions if it's all in-process | 07:18 |
| dcaliste | #info Damien Caliste, community (sorry to be late) | 07:18 |
| sledges | abranson: messy like in Android? E.g. every single app that can accept image is listed in a sharing page (sometimes includes frequent contacts in addition:) | 07:19 |
| Thaodan | On Android it is different because of intents | 07:19 |
| abranson | so even though the old sharing api's been there for ages, it's demise is now quite urgent :) | 07:19 |
| sledges | define "messy" then:) | 07:19 |
| rubdos[ma] | If you're going to expose a sharing API, maybe it's a good idea to think about the "frequently used contacts" part too, because we definitely could expose such a thing ;-) | 07:20 |
| Thaodan | You can call on page of the other app without having it "in you" | 07:20 |
| flypig | The proposed approach, what would stop a rogue app from adding full permissions to some other app (e.g. an app with a vulnerability that could then be exploited)? | 07:20 |
| flypig | You could hide all sorts of sins behind a permission called "Whisperfish sharing". | 07:21 |
| rubdos[ma] | Only Jolla's app store screening would stop that. | 07:21 |
| ViGe | jpetrell_: "sharing pages" means the UI? | 07:21 |
| GabrielMargiani[ | Anyway, what would stop a rogue app from installing a rootkit? | 07:21 |
| Thaodan | Nothing, I would think having a mediator is better. | 07:21 |
| Thaodan | Loading a qml module in the context of the mediator would be better | 07:22 |
| rubdos[ma] | But indeed, installing from OpenRepos can do that either way, having a script run regularly to update the Gallery's permission file either way | 07:22 |
| abranson | if the choice of which app to share to is made inside the client app, then it has to have access to the sharing entrypoints of every app that it could possibly share with. it could call them without user permission, and unless those apps define more than one service then they would be able to call everything. with a broker, the app just has permission to call 'shareThis' on the broker. it wouldn't know which apps can | 07:22 |
| abranson | accept the data at all, let alone call them itself. | 07:22 |
| rubdos[ma] | (which is basically what we would need to do as a workaround now) | 07:22 |
| Thaodan | e.g. org.sailfish.shareplugin that runs as the context of the dbus service in relation to the app | 07:22 |
| rubdos[ma] | Yeh, that's a legitimate concern abranson :-) | 07:22 |
| abranson | that was a definition of 'messy' for sledges sorry. ran on a bit :) | 07:23 |
| GabrielMargiani[ | I think you can limit the available methods via firejail ... | 07:23 |
| jpetrell_ | ViGe: yeah. once you tap sharing option currently it constructs respective a sharing page/view and pushes it to page stack | 07:23 |
| sledges | abranson: roger. misunderstood earlier; messy != cluttered in this case ;) | 07:23 |
| rubdos[ma] | We currently have that "open this with which app?" thingy popping up; I imagine that a share button could fire an alike pop-up, which is shown by your broker? | 07:23 |
| ViGe | jpetrell_: I'm just thinking why the UI has to be out of process, isn't it enough that the actual sharing is done out of process? | 07:24 |
| abranson | sledges: whatever we do will look cleaner that Android. as usual ;) | 07:24 |
| jpetrell_ | ViGe: the sharing views are different, e.g. email sharing has email composer view | 07:24 |
| jpetrell_ | and there is no way to load safely contained QML UI in-process | 07:25 |
| ViGe | jpetrell_: So that email composer view is currently done in the context of the app which is sharing and not the email app? | 07:26 |
| abranson | yeah, that's why the permissions are all over the place :) | 07:26 |
| rubdos[ma] | (yikes) | 07:26 |
| abranson | and why sailjail means we need new sharing ;) | 07:27 |
| jpetrell_ | ViGe: yes. most UI flows in platform apps happen in-process. UX-wise it is better than leaving a trail of windows on home | 07:27 |
| sledges | #info (discussing safety aspects, sharing framework via broker/mediator, UI containment) | 07:28 |
| jpetrell_ | it can be long chain app -> share list -> add account -> browser sign-in -> return to sharing -> share page -> submit | 07:29 |
| sledges | gave extra time for this as only 2 questions today, but let's start wrapping up | 07:29 |
| GabrielMargiani[ | One could hide the inactive windows from the homescreen by closing them, but that's quite some logic overhead ... | 07:30 |
| abranson | yeah, these things should happen in separate processes, but there needs to be a way to make the UI flow act like it isn't | 07:30 |
| rubdos[ma] | Wrap up: Ok, so some work from Jolla is needed in here. I think Jolla should still consider our dbus listing approach, as the main problem is the one that abranson summed up nicely (calling sharing methods randomly without user input). I think that *may* be a risk worth taking, but that's obviously Jolla's call. Would be nice to have a solution here soonish, as the longer you wait, the more hacks we will come | 07:30 |
| rubdos[ma] | up with to implement it 😀. Feel free to ping me in DM or #whisperfish for more discussion aside from the weekly meeting. | 07:30 |
| sledges | #info <rubdos> Wrap up: Ok, so some work from Jolla is needed in here. I think Jolla should still consider our dbus listing approach, as the main problem is the one that abranson summed up nicely (calling sharing methods randomly without user input). | 07:31 |
| sledges | #info <rubdos> I think that *may* be a risk worth taking, but that's obviously Jolla's call. Would be nice to have a solution here soonish, as the longer you wait, the more hacks we will come | 07:31 |
| Thaodan | abranson: Is there a way to have a private connection with the mediator or embed on a view from the mediator? | 07:31 |
| sledges | #info <rubdos> up with to implement it 😀. Feel free to ping me in DM or #whisperfish for more discussion aside from the weekly meeting. | 07:31 |
| rubdos[ma] | (Or in #sailfishos for that matter!) | 07:33 |
| abranson | Thaodan: I understand there's some dark magic in progress that would make that sort of thing possible ;) | 07:33 |
| sledges | alrighty, let's move to the next one | 07:33 |
| sledges | #topic Community help (20 min -- asked by jojo94) | 07:33 |
| *** sailbot changes topic to "Community help (20 min -- asked by jojo94) (Meeting topic: Sailfish OS, open source, collaboration -- 8th April 2021)" | 07:33 | |
| sledges | #info <jojo94> I’ve recently searched for strategies 1 for how the community could help the development and propagation of SFOS out here. | 07:33 |
| Thaodan | abranson: You are a wizard Andrew? | 07:33 |
| sledges | #link https://forum.sailfishos.org/t/strategies-bringing-more-sailors-to-sfos/5600 | 07:33 |
| sledges | #info <jojo94> Many suggestions hatched: | 07:33 |
| abranson | Thaodan: not me, but I know a couple ;) | 07:33 |
| sledges | #info <jojo94> 1. How can we help/what can Jolla do to have a partnership with Fairphone ? Would Jolla agree on such a topic ? | 07:34 |
| sledges | #info <jojo94> 2. Is there a more professional way for the community to peach SFOS for companies ? (for them to port their apps). We want more companies coming to Sailfish, but as users, we have little legitimacy when reaching for them. | 07:34 |
| sledges | #info <jojo94> 3. And we know that you are working hard to improve SFOS but could we have a timeline (maybe not in months but semesters) of future developments ? | 07:34 |
| sledges | #info <jojo94> 4. One more thing, how can the (non technical) community help ? | 07:34 |
| sledges | #info <Jolla> 1. We are considering if we could do more to support the community ports, but at the same time we need to carefully consider where to put our available resources. The challenge with a commerical project would to be finding a way to make it profitable for the companies involved. | 07:34 |
| sledges | #info <Jolla> 2. Companies need a solid business case to consider porting their app to a new platform. We recently updated sailfishos.org website and are actively working on improving documentation and other material to highlight the possibilities and opportunities Sailfish OS brings to the market. | 07:34 |
| sledges | #info <Jolla> When approaching companies it is good to highlight Sailfish OS being the only or (depending how you look at it) one of the few independent, European, privacy-respecting alternatives in the market. | 07:34 |
| sledges | #info <Jolla> 3. Publishing a roadmap is challenging for us as details of customer plans and projects during development are usually confidential. | 07:35 |
| sledges | #info <Jolla> On the other hand there are other projects e.g. internal developments, which we could talk about more freely, but also there we need to be careful as resources available for internal development may change and therefore the plans keep evolving. | 07:35 |
| sledges | #info <Jolla> We are now discussing internally how we could share more about what is ahead for Sailfish. | 07:35 |
| sledges | #info <Jolla> 4. Localising (translating) the OS is one area where not-tech members can definitely help: | 07:35 |
| sledges | #link https://sailfishos.org/wiki/Translate_the_OS | 07:35 |
| sledges | #info <Jolla> Also we are working on opening up documentation platform for 3rd party to freely add and edit content. Joining the discussion, reporting experiences, improvement ideas and bugs in Sailfish OS forum is naturally a great way to participate. Further if you have other ideas how to help Sailfish ecosystem grow we are all ears. :) | 07:35 |
| * sledges whew `,:) | 07:36 | |
| jojo94 | ahahah well thank you very much for the replies ! | 07:36 |
| jojo94 | did jolla engage in any discussion with fairphone ? (or tohers) | 07:36 |
| rubdos[ma] | Oh, us helping in the dev documentation would be nice indeed. | 07:36 |
| flypig | Great question btw jojo94. | 07:37 |
| maier | It would help to have a choice of devices | 07:37 |
| Setok | On a sidenote I emailed Fairphone about getting Sailfish there officially. Got a mostly generic response pointing to the openness of the phone and that I could install Sailfish that way, The person ignored the point made in my original message about not getting Android support unless it's an official installation | 07:38 |
| rubdos[ma] | (As usual in the Fairphone topic: I think a lot of people would prefer a FP over a Sony.) | 07:38 |
| Thaodan | rubdos[ma]: IMHO not really since they are not that open as they present themselves and the hardware is half backed but thats that ot. | 07:39 |
| Setok | Perhaps marginally, but I'm most interested in the phone being functional and nicely packaged. For broader market acceptance should have SF pre-installed | 07:39 |
| jojo94 | the FP has a plus side over Sony is that, and I'm thinking about orangecat's topic on using SFOS in universities, you can buy a new one as a company whereas buying used phones/refurbished is usually more complicated | 07:39 |
| Thaodan | There is some work going on to make porting easier and reduce the amount of maintenance need per port. | 07:40 |
| jojo94 | thank you flypig and I was not aware of that Thaodan | 07:40 |
| Thaodan | If there are suggestions or ideas feel welcome to tell us or make a PR> | 07:41 |
| diegoc | Is there no way of working more officially with Sony? | 07:41 |
| diegoc | As in, getting device info before the phone comes out to work on device adaptation faster | 07:42 |
| jojo94 | I also remember Samy (i think) last year saying that a major European company was going to adopt Sailfish internally, any news on that ? | 07:42 |
| maier | Isn't it possible to have a comfortable way to choose a phone of your choice and go to a website to install your phone directly with SFOS on your USB-Port?? | 07:42 |
| Setok | Or even having a official pre-installation model where Jolla (or someone) does the work and sells the phone? | 07:43 |
| Thaodan | Setok: I don't think so but community can help each other to install it. | 07:43 |
| Thaodan | I remember that some came to the office to ask if we install them sfos on their phone | 07:44 |
| Setok | Thaodan: on the forums we discussed having days/locations where people could come in with their phone and get SF installed, with the help of other community members | 07:44 |
| Setok | maier: unfortunately many phones don't allow installing new OSes freely, and the devices are so different that it wouldn't be trivial. They're not standardised in the way PCs are | 07:45 |
| jojo94 | for the challenge with a commercial project where companies involved need to find it profitable, I can already image people saying "well FP can just charge more for preinstalled Sailfish that they send to Jolla" | 07:45 |
| sledges | diegoc: given that we are collaborating with Sony on their AOSP availability, we try to publish instructions for community to help us with the adaptation, but haven't received too many contribs via that effort (which would otherwise accelerate the port to public) | 07:45 |
| maier | Setok: if it is my phone I decide wht's on it ... even if I loose garanty. | 07:46 |
| Setok | maier: yeah. In an ideal world :-> | 07:47 |
| maier | And where is the problem? | 07:47 |
| Thaodan | I dream of a world without blobs :D | 07:47 |
| Setok | maier: that it's not possible... you simply can't do that with many phones | 07:47 |
| diegoc | sledges: Thanks for the answer! Sadly I'm not too good with tech so I can't contribute much, but hopefully Sony pays attention and helps out SFOS | 07:47 |
| maier | But that's only a technical problem or not? | 07:48 |
| rubdos[ma] | As an aside, I know the people that do the depth sensor... Maybe Sailfish could make a killer application around that and draw Sony's attention? 😛 | 07:48 |
| jojo94 | the depth sensor ? | 07:49 |
| abranson | an app to tell you that it's raining: :D | 07:49 |
| Setok | maier: technical/political. Perhaps even regulatory. Many phones are kind of locked so you can't just install any OS on them, or even if you could, a lot of the hardware wouldn't work so it would be kind of useless | 07:49 |
| rubdos[ma] | The secondary cam on basically all the Sony's is a depth sensing camera. | 07:49 |
| abranson | I wonder if you can tap it like the old wall mounted ones | 07:49 |
| abranson | oh I thought you meant the barometer :D | 07:49 |
| maier | so it's time to get open mobiles like in China! | 07:50 |
| diegoc | how's the Japanese SFOS community, btw? slightly off topic | 07:51 |
| diegoc | given that Sony phones are mainly used there | 07:51 |
| flypig | rubdos[ma], the secondary cam on the back? Or the selfie camera? | 07:52 |
| rubdos[ma] | on the back of the X10 I'm quite sure it's a ToF depth sensing chip | 07:52 |
| rubdos[ma] | The guy that lead the R&D of that tech pays my bills, so I know them quite well. | 07:53 |
| jojo94 | rubdos got connexions | 07:53 |
| flypig | Ah nice. But also too bad as I was hoping it was the selfie camera so we could have 3D gestures. | 07:53 |
| abranson | that's used for the bokeh effect thing? | 07:54 |
| rubdos[ma] | There's rumor that Sony will soon merge RGB with depth in a single chip, so selfie cams will have that too. | 07:54 |
| sledges | diegoc: since Jolla sells Sailfish X in EU, Japanese community is not the largest, but could definitely do with a language coordinator to accept all those nice suggestions https://translate.sailfishos.org/ja/ :) | 07:54 |
| flypig | It would makes sense (it must be useful for facial recognition too). | 07:54 |
| maier | A other point is ... as long as basic functions are not working like using online banking because of lack to login ... there will come no new users. | 07:55 |
| rubdos[ma] | Yeh, makes sense, also on a technological level. | 07:55 |
| diegoc | sledges: Thanks for the answer! :D I'm still with 'Minna no nihongo' so sadly I'm not the one for that job '=D but I'll try to get some of my Japanese friends involved | 07:55 |
| sledges | great! | 07:55 |
| jojo94 | is there are a wish from Jolla to try using the many plans on "European digital sovereignty" and national plans to leverage Sailfish as a public solution ? | 07:55 |
| Setok | With a bit of effort Sailfish could actually be quite interesting in Japan. They generally are very fond of anything Nordic. Finnish saunas have become a major thing there recently, and they also recently opened up the Moominland. | 07:56 |
| Setok | It was kind of bizarre walking around there with all the signs in Finnish :D | 07:56 |
| rubdos[ma] | <jojo94 "is there are a wish from Jolla t"> Jolla could probably get H2020 funding for such things... | 07:56 |
| sledges | diegoc: japanese keyboard also exists, but struggles to be integrated into sfos due to input method engine: https://openrepos.net/content/sfosja/japanese-keyboard-anthy | 07:56 |
| Setok | Oh and lonkero for sale. So promoting Sailfish there could go down very well | 07:56 |
| sledges | as soon as that's done, Japanese language could then be integrated into flashable images | 07:56 |
| Thaodan | Setok: year ago I heard clothes with random German words that sound cool were in in Japan. | 07:57 |
| jojo94 | rubdos[ma] yes h2020 and nextgeneu and all are one of the points i was thinking about but also all the countries that ask for "sovereign phones" on their calls for tender | 07:57 |
| flypig | Setok, I was quite surprising visiting the Moomin museum in Tampere for the first time and noticing the signs were all Finnish, English and Japanese. | 07:58 |
| sledges | aand we've exhausted the time for this topic too, let's move to generic discussion | 07:58 |
| sledges | (can nicely transpire some conversations there too:) | 07:58 |
| sledges | #topic General discussion (15 min) | 07:58 |
| *** sailbot changes topic to "General discussion (15 min) (Meeting topic: Sailfish OS, open source, collaboration -- 8th April 2021)" | 07:58 | |
| ExTechOp | Is there any information at this time on new SFOS ports, like the Sony Xperia 10 ii ? | 07:58 |
| Setok | I would like to ask if Jolla is aware of the discussion about the apparent security problem with APKPure opening spammy websites in the background? | 07:58 |
| Thaodan | jojo94: nextgeneu is more a PR think, they invited to work palantir to work in the new EU cloud.. | 07:59 |
| rubdos[ma] | <Thaodan "jojo94: nextgeneu is more a PR t"> yikes lol | 07:59 |
| Thaodan | ExTechOp: Watch github.com/mer-hybris ;) | 07:59 |
| sledges | ExTechOp: keep watching the adaptation repos activity - all open source :) | 07:59 |
| diegoc | can't wait for the Xperia 10 ii port!! So excited! :D | 08:00 |
| rubdos[ma] | There's also the SkyECC thing Jolla could capitalize on, but maybe we don't want to go shady :-D | 08:00 |
| flypig | Setok, thanks for flagging that up. We're aware, but only recently. | 08:00 |
| Thaodan | rubdos[ma]: https://www.theguardian.com/world/2021/apr/02/seeing-stones-pandemic-reveals-palantirs-troubling-reach-in-europe | 08:00 |
| Setok | flypig: OK, good to hear. It sounded quite concerning that an Android app could do that | 08:01 |
| maier | I use Jolla 1 till now ... I have to by a new on. I doesn't matter what company. Does any one have a suggestion for a phone with new hardware and a size not bitter than the Jolla 1? | 08:01 |
| Thaodan | maier: I heard there is a nice community port made by rinigus | 08:02 |
| flypig | Setok, it's unclear whether it's ApkPure being malicious, or an unexpected side-effect of something else. | 08:02 |
| Thaodan | ZX2 compact comes to my mind | 08:02 |
| maier | sorry mean ... not bigger than | 08:02 |
| sledges | but it's troubling that ApkPure is launched as background service regardless of it's setting in sailfish app page | 08:02 |
| flypig | sledges, yeah, there seem to be two issues here. Background servers (which I understand from the discussion is not new) and opening websites without interaction. | 08:03 |
| Setok | flypig: I would argue that even if it was being malicious, it's a bit concerning. I mean I would assume it shouldn't be possible for it to act that way, opening websites in the background with no user interaction | 08:03 |
| flypig | s/servers/services/ | 08:03 |
| maier | Thaodan: yes but 1st it's not supported and has no new HW | 08:03 |
| flypig | Setok, sure, agreed. | 08:04 |
| Thaodan | maier: Well it is close as it gets to supported and having that size | 08:04 |
| maier | Thaodan: It is close ... I remember this in the relation to VoIP :( | 08:05 |
| ViGe | Is it really so that ApkPure opens those websites without user interaction, even if the user has *not* selected "Always" in the dialog about which app to use for opening the web page? | 08:05 |
| jojo94 | Thaodan PR or not, in a 1 trillion + investments for SME, ETI and research towards the EU, Jolla could find its spot there | 08:06 |
| sledges | #info amongst other things, discussing ApkPure being out of order: | 08:06 |
| flypig | ViGe, I'm not 100% certain, but I believe the user would have had to do that at some point in the past. | 08:06 |
| sledges | #link https://forum.sailfishos.org/t/native-browser-malware-virus/5752/24 | 08:06 |
| Thaodan | jojo94: Sure that would be awesome. | 08:07 |
| ExTechOp | What I'd love to see in the long run is some kind of a less intensive "just enough" porting procedure for Sailfish to phones (a bit like LibreELEC is for Kodi distributions, where you just bring in the device tree for different hardwares). | 08:07 |
| flypig | There's this related thread as well: https://forum.sailfishos.org/t/android-do-not-start-background-services-does-not-work/5804 | 08:08 |
| ViGe | flypig: Yeah, I'm just thinking that if the user has selected "Always" in that dialog, then the expected behaviour is that the web page is opened without asking from user. It's quite likely the user selected "Always" exactly because he does not want to be bothered with the dialog again. So showing a dialog would be against the expectation and someone would be writing a bug report about it... | 08:08 |
| sledges | ExTechOp: that's our ultimate aim too: https://github.com/mer-hybris/droid-hal-configs/pull/215 https://github.com/mer-hybris/droid-hal-configs/pull/222 | 08:08 |
| ExTechOp | sledges Nice to hear :-D | 08:09 |
| diegoc | that's great news! :D | 08:09 |
| flypig | ViGe, yes it's a good point. But it's also mixed up with the fact it's hard to reverse that decision, and with the background process issue (ApkPure opening them even when the app isn't running). So a bit complex, I guess. | 08:10 |
| Setok | ViGe: I think the bigger problem is allowing that to happen in the background, when the app isn't even in the front. This would certainly go against my expectation that an app could open stuff willy nilly. In this case it is apparently happening even with background services turned off | 08:10 |
| jojo94 | thank you all for the questions, I have to leave, have a nice day ! | 08:11 |
| flypig | You too jojo94. | 08:12 |
| sledges | we all got 1 minute left on this topic, too:) | 08:12 |
| diegoc | I have to leave as well. Thanks everyone. I had never been to one of these (just read the transcripts on the website) and I plan on coming to the next one!:D Have a nice day | 08:12 |
| ViGe | Setok: I agree with that. It definitely should not be able to start itself in the background when it doesn't have the permission to do so. It's probably doing something quite nasty in order to do that :/ | 08:13 |
| flypig | See you next time then diegoc :) | 08:13 |
| sledges | ViGe: looks like there are more ways to circumvent services' autostart settings in Android App on sfos: https://together.jolla.com/question/130623/android-apps-background-processes-start-unallowed/?answer=130666#post-id-130666 | 08:13 |
| sledges | most likely applies to android too (and bloats the OS.. :/) | 08:13 |
| Setok | ViGe: and I would argue that even if it had that permission, it should still not be able to open webpages (or anything else for that matter) without being in the foreground, or while the device is locked. That might be a more delicate thing to balance (what apps are allowed to do in the background) | 08:14 |
| abranson | When the background running is disabled, then that package isn't allowed to receive broadcast intents (such as boot_completed), and when its window is closed then the app is force stopped. that stops the 'normal' ways for apps to start, but a lot of them put a lot of effort into launching themselves any way they can. | 08:14 |
| abranson | certainly an app or its services can be launched from another app, or via some background push notif service if you have one of those running | 08:15 |
| abranson | the trouble with hacking around with that stuff too much is if we deviate too much from how android normally works, then innocent apps will stop working. | 08:15 |
| ViGe | abranson: Well, if their main source of revenue is displaying unwanted ads on users, then certainly you do whatever you can in order to be able to do that | 08:16 |
| abranson | exactly | 08:16 |
| sledges | and on that bombshell, it's time to time next meeting's time | 08:16 |
| sledges | #topic Next meeting time and date (5 min) | 08:16 |
| *** sailbot changes topic to "Next meeting time and date (5 min) (Meeting topic: Sailfish OS, open source, collaboration -- 8th April 2021)" | 08:16 | |
| sledges | Proposing Thursday 22nd April at 7am UTC | 08:16 |
| rubdos[ma] | Just quoting nthn from the forum here: | 08:17 |
| rubdos[ma] | > If I may ask, would it be possible to exceptionally host one of the next community meetings on a Friday morning instead of a Thursday? I have a topic I’d like to be discussed 21, but I can never make it on Thursdays. | 08:17 |
| sledges | nthn asked for a Friday's meeting, but we have a strict tradition in Jolla -- no meetings on a Friday (oh, and it also clashes with another bi-weekly friday meeting :DDD) | 08:17 |
| ExTechOp | we could ask if nthn could do a Wednesday? | 08:17 |
| sledges | yep | 08:17 |
| Thaodan | Also no meeting after lunch time :D | 08:17 |
| sledges | or during | 08:17 |
| sledges | :D | 08:18 |
| rubdos[ma] | Meeting hygiene, we could do with that too. | 08:18 |
| sledges | I'll contact nthn via forum, but sailors might have other meetings on wednesday too so, it's tricky. | 08:18 |
| Thaodan | rubdos[ma]: Well there is IRC for SFOS but I want to eat without reading IRC | 08:19 |
| rubdos[ma] | Ah; "we" referred to my day job, not to SailfishOS :'-) | 08:19 |
| rubdos[ma] | like, no meetings during/after lunch, that's really a good one. | 08:20 |
| sledges | finding substitute and not being able to chat on a sore topic themselves can be disappointing, but not end of the world:) | 08:20 |
| sledges | let's keep the timing for the time being | 08:21 |
| * sledges (cringes) | 08:21 | |
| sledges | #info Next meeting will be held on Thursday 22nd April 2021 at 7:00am UTC: 2021-04-22T07Z | 08:21 |
| rubdos[ma] | I've volunteered to take substitute for nthn, but I'd just be nodding probably :'-) | 08:21 |
| sledges | thanks all, hope everyone's back on full steam after Eastery break! | 08:21 |
| sledges | #endmeeting | 08:21 |
| sailbot | Meeting ended Thu Apr 8 08:21:52 2021 UTC. | 08:21 |
| sailbot | Minutes: https://irclogs.sailfishos.org/meetings/sailfishos-meeting/2021/sailfishos-meeting.2021-04-08-07.00.html | 08:21 |
| sailbot | Minutes (text): https://irclogs.sailfishos.org/meetings/sailfishos-meeting/2021/sailfishos-meeting.2021-04-08-07.00.txt | 08:21 |
| sailbot | Log: https://irclogs.sailfishos.org/meetings/sailfishos-meeting/2021/sailfishos-meeting.2021-04-08-07.00.log.html | 08:21 |
| *** sailbot changes topic to "Next meeting will be held on Thursday 8th April 2021 at 7:00am UTC. Topics can be made/read here: https://forum.sailfishos.org/t/community-meeting-on-irc-8th-apr-2021/5653" | 08:21 | |
| rubdos[ma] | You folks take breaks? Nice :-D | 08:22 |
| Thaodan | Get some Mämmi :D | 08:22 |
| rubdos[ma] | Have a nice eastern break, then, see you next time. | 08:22 |
| flypig | Cheerio everyone. | 08:22 |
| ExTechOp | bye | 08:22 |
| * sledges goes to have Cheerios for -break-fast | 08:23 | |
| Thaodan | Oh good day | 08:23 |
| Thaodan | Flypig being very brittish. | 08:23 |
| flypig | :D | 08:23 |
| sledges | isn't he just :D | 08:24 |
| *** ChanServ changes topic to "Next meeting will be held on Thursday 22nd April 2021 at 7:00am UTC. Topics can be made/read here: https://forum.sailfishos.org/t/community-meeting-on-irc-22nd-apr-2021/5818" | 08:25 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!