Notifications: Out of the comfort zone?
-
@ernest I dont know, maybe you can find out?
BR -
@garro Can you explain? You mean you run a separate software on your Desktop which will create the notifications and send them to the phone?
BR
-
Could we just store the notifications locally? There's no real advantage to not doing it.
-
If we're talking about Sailorgram, the app is launched at startup, running as a daemon invoked by systemd. When the user taps its icon in the apps launcher, a message is sent to the app via DBus, requiring to show the GUI. When the user close that GUI, the main process keeps running in background.
This might be a solution, but it involves a revision of the confinement policies and the whole app life-cycle story.
EDIT: I'd like to make it clear, daemons are something shouldn't be implemented in the current platform, IMHO, since they might be a bit dangerous...
-
We can't live without any background services forever, so would it maybe be possible to have a background daemon where applications can register micro-services that the user can allow or block? That way applications could have stripped-down background options (to poll for notifications, for example) and the user could decide between functionality or battery life and you don't need a notification server and everything can be done on the client-side. I understand that it would be a lot of work and it's probably only feasible for the non-legacy, but might that be an option?
-
@NeoTheThird
If I try to understand the strategy Canonical used for writing the current platform limitations, I see that running daemons - without any particular limitation - might turn to be too risky.There's already some way someone could potentially write an app that "soft-bricks" the device, but the only thing that prevents it is the absence of daemons - yep, it's something very stupid I've tried some time ago. XD
This is clearly one of the bad scenarios I can think of right now, but it's still something to consider if you want to change the current strong confinement policies, IMO.We actually need to think at a solution - that's true - which could be something similar to BlackBerryOS 10, or just running a daemon like in SailfishOS (BTW, apps with daemons are not allowed to be released in the SFOS store).
In any case, if we want to allow applications to be run as daemons, then, I would suggest that those apps needs to be open source, in order to be manually examined before they get released on the Open Store. -
@sverzegnassi Ok, i did not express myself clearly there: My point was to not let every app break the confinement rules and create their own background services, my point was to create a unified master-service that applications can then can ask to register their own service on (with the user moderating it). This is not only useful for notification services, but also for other background services like music playback with the screen switched off, which is a really nice feature.
I totally agree with you, we can't have every app going around being a cowboy, but practicality beats purity. We should definitely restrict closed-source apps from breaking confinement, but of course this is no guarantee for safety either. You can easily hide malicious functionality in a block of obscure code... We should not panic too much about this, though.
Tangent:
Some points of confinement will have to be over-thought, like the content-hub for example. Of course it makes sense to have rules in place, but practicality beats purity. A calculator app does not need to have write access to the home folder, for example, but a text editor does. And creating local copies for everything seems a little weird... -
@NeoTheThird said in Notifications: Out of the comfort zone?:
ack with the screen switched off, which is a really nice fea
I think it's an essential feature
-
@Flohack Exactly, when the phone connects to it asking for them
-
-
@NeoTheThird Sorry, I misunderstood your words - it's not your fault - I just thought micro-services -> daemons.
That's something that would allow us to effectively keep control of what's running in background.
However, some of my observations are still valid; I suggest you to give a look at the "Headless apps" for BBOS10, it's worth a read.Headless apps - BlackBerry Native
We'd need to limit CPU and memory usage for background services, a network bandwidth limitation would be desirable too. Also, services should be forced to complete their tasks within 20 seconds, in order to preserve battery life.
See Resource Management for Headless apps.
However that wouldn't solve some security concerns - we'd still need to provide a certain amount of isolation between the micro-service/headless-app and the main GUI. This would require a change in the Click package specifications, and we come back to the (infamous) question we still have to answer: Click, Snap or what else?
If there's something I like of the Maemo/Meego/SailfishOS implementation, that is its simplicity. It's pretty straightfoward to implement "local" notifications that way.
I still prefer a BBOS-like solution, but I think that we should initially focus on how to get dekko and telegram-app notifications working, understand their requirements, and then see which solution fits better.-- About ContentHub,
I've been using it in almost all of my projects, from the DocumentViewer to InstantFX, with the authorization from the Canonical Security Team to use the "extra" permissions granted to Core Apps, or even fighting for sorting out a good user experience for an application (InstantFX) that requires a persistent access to user's Pictures folder.There's for sure some problem with ContentHub: although it has seen an increase of its capabilities (e.g. print and clipboard support), its model has never changed since 2013. I recall that a mime type filtering (instead of those "well-known" content types) has been promised some years ago, but never landed.
I believe that user's public data (in "~/<xdg_user_directories>") should be consumed by any app or device that requires it. Otherwise there wouldn't be any need for data to be saved there, but we'd use apps private folders instead.
However I still think that ContentHub might be useful for those applications that doesn't require a persistent access to user's folder.
In any case, we might also want to change the ContentHub experience a bit:
- We may want to keep the current "peers model" for accessing private data owned by a single application. This is how it works now, and it's perfect for such scenario.
- We may want to add a file picker UI directly in the ContentHub - like in Android. That'd be useful with public data, once we have mime type support.
Canonical wanted to enhance security. That came at a cost: applications can only access to their local copy of a file.
I think the keyword here should be "privacy": applications can access user's data, but we explicitly inform the user of any change or access to her folder.I think we should get in touch with previous ContentHub maintainer: if there's a way to change AppArmor restriction during the app executions, adding some temporary read permission, that would be great.
Generally speaking: major issues are:
- Content export: the app loses focus, therefore the user flow is interrupted.
- Content peer UI: e.g. gallery-app, it's not much usable, IMHO
- Well-known content types: not something really flexible.
Content import is annoying - that's true - and I'd like things to be handle differently. However receiving a copy of the original file is not so traumatic yet, if well handled.
-
@sverzegnassi What about using links instead of local copies? This would solve the space issue while still keeping almost the same granularity that UT currently ships and that I really appreciate a lot.
-
@garro That's how ContentHub already works, when it's possible. However there are apps that performs a local copy. The first example I can think of is DocViewer: if an app requires to export a document in ~/Documents, it needs to copy the file, since it has to be publicly available even if the other app is uninstalled, or its private data are deleted.
-
I think that everyone would be happy with a notification server, if we were 100% sure that it was secure and that no one would have access to our notifications. Unfortunately, in real life this is very different to achieve.
Here's my brainstorming on the subject:
-
the notifications will be sent in encrypted form from then originating service (e.g., telegram) to the notification server. Only the ID of the destination user account will be left in clear (or encrypted with a key provided by the notification server), so that the notification server can read it and push the notification to the proper device. But the notification server should not have access to the contents of the notification, which will be encrypted in a way that only the destination device can decrypt.
-
if the option above is too difficult to implement, then I propose that the messages sent to the notification server should only contain the ID of the destination user: so, Telegram (for example) will inform the notification server that user X has something new, without specifying any further information. Then, the notification server will send a push notification to user X's device, telling it that there's something new in Telegram. The Telegram app will have to implement a push notification client consisting of a UI-less binary which will connect to the telegram servers, check what's new, and generate the JSON notification messages. If we plan this right, it should be possible to use the same binaries for this goal and for account-polld, which would make developers' life easier when switching between account-polld and the push notifications.
-
-
Could we not have notifications locally stored in RAM? If an app wants to generate a notification, it simply needs to instantiate it and add it to some array. Simply regulate that array, limit the amount of notifications an app can have at one time, and there you go.
-
@Leppa Its already made like this, basically, you got a local notifications API that you can call. The text messaging is made like this, SD card status etc. But what all people seem to forget, it´s not about how to display the notifications locall but how to send them to the device in case they come from a remote service.
So how in your case you deal with pending notifications on the telegram server? Or other services like that? Imagine a trading App that monitors your stocks, and gives you alerts every lets say 10mins?
By not having a push server infrastructure we need to let all Apps run in foreground so that they are able to see smth has changed.
-
@sverzegnassi regarding the headless app... Can´t we work with DBus to communicate between all these things? The Apps should have access there?
BR
-
@Flohack I know that any DBus call - except for some - is by default denied by AppArmor, therefore we should for sure update the confinement AA templates.
I think we'd probably need to define a new AppArmor profile for headless apps, in order to prevent e.g. usage of the UriHandler service
