XScreenSaver is available on Android. Google requires a privacy policy(chaos.social)
chaos.social
XScreenSaver is available on Android. Google requires a privacy policy
https://chaos.social/@scy/112591102162587559
66 comments
turns out. the testicle cup referrer is still active.
> Maybe just link to the actual source (https://www.jwz.org/xscreensaver/google.html) rather than some random social media post?
I did submit that and it was DOA, and I saw that there was another post of the original which was also DOA, so I submitted the post where I saw the reference.
I did submit that and it was DOA, and I saw that there was another post of the original which was also DOA, so I submitted the post where I saw the reference.
I had to rewrite my Google privacy policy at least 4 times before they accepted it.
This is the current accepted one: https://victorribeiro.com/privacy_policy.html (i copied from somewhere else and changed it).
This is the one they rejected: https://victorribeiro.com/privacy_policy.txt
This is the current accepted one: https://victorribeiro.com/privacy_policy.html (i copied from somewhere else and changed it).
This is the one they rejected: https://victorribeiro.com/privacy_policy.txt
I appreciate that the version they indirectly encouraged you to use by rejecting the other one is much more clear about how you not only don't store anything, but don't collect anything. For the pedanticists here which might argue you can't collect anything without storing it, I suspect there's a lot of wiggle room there (even if only in the developers mind and not legally), and the additional information is useful to guard against that.
For example, getting paid to receive and forward data, or to send it directly to a third party may be something a developer could do and thing they are complying with "we don't store your data". Technically correct, probably not legally correct, but unlikely to matter legally unless noticed and they are sued.
Much better to be explicit about things as long as it's still easily readable.
For example, getting paid to receive and forward data, or to send it directly to a third party may be something a developer could do and thing they are complying with "we don't store your data". Technically correct, probably not legally correct, but unlikely to matter legally unless noticed and they are sued.
Much better to be explicit about things as long as it's still easily readable.
It's cute, but: it's a lie.
Data is stored.
We (privacy advocates) won, there's legislation now, this stuff is real, The Man cares.
You can't handwave, saying you don't "store" or "collect", or whatever verb you like that, to you, means "we don't do anything bad" -- when you're in that territory, ex. Google's privacy policy becomes "we don't sell your data" --- can you imagine?
There's precious few applications that don't "store", "collect", etc. The other move I see is people going with "we don't store/collect data": I assume they're trying to claim they don't store data server-side, but very frequently in my experience, they are are storing data server-side, just what they perceived as trivial (ex. cloud sync when the product is cloud only, that's not "we" storing "your data", it's us syncing because you asked!)
If you feel good & witty writing your privacy policy, and end up with a single sentence one, something went wrong. If you're sufficiently small you'll probably get away with it, but...ugh.
This also presents a significant opportunity: it's hard to find a good privacy policy, that actually handles all the regulatory obligations you now have as a developer, and isn't just legalese amounting to "We take it, keep it, let us know if we should get rid of it"
Data is stored.
We (privacy advocates) won, there's legislation now, this stuff is real, The Man cares.
You can't handwave, saying you don't "store" or "collect", or whatever verb you like that, to you, means "we don't do anything bad" -- when you're in that territory, ex. Google's privacy policy becomes "we don't sell your data" --- can you imagine?
There's precious few applications that don't "store", "collect", etc. The other move I see is people going with "we don't store/collect data": I assume they're trying to claim they don't store data server-side, but very frequently in my experience, they are are storing data server-side, just what they perceived as trivial (ex. cloud sync when the product is cloud only, that's not "we" storing "your data", it's us syncing because you asked!)
If you feel good & witty writing your privacy policy, and end up with a single sentence one, something went wrong. If you're sufficiently small you'll probably get away with it, but...ugh.
This also presents a significant opportunity: it's hard to find a good privacy policy, that actually handles all the regulatory obligations you now have as a developer, and isn't just legalese amounting to "We take it, keep it, let us know if we should get rid of it"
I honestly packed all the code inside of a APK and distribute it via Google app store. I make no request to get out send any data. How am I collecting or storing any data?
> no request to get out send any data
Correct: that means you are not relaying data to a network, or retrieving data from a network.
Your claim was "We don't store your data, period."
I can't know for sure, but for the vast majority of applications, data is stored somewhere, be it on the device, or on the server. High scores? Game state? Levels completed? You sure you're not storing data?
That's why it was rejected.
Don't get me wrong, I don't think you're doing anything shady, I don't think you're doing it in the general terms people worry about, I very much doubt anyone will find out, or care if they did.
It's just a useful example of something that plays well in the HN comments section but not in the real world, I didn't even realize until a few months back.
These are de facto legal statements now. Every store requires them, and they're not paying a lawyer to double check them for you. You can get away with it on side project games, but it's not something you can get away with at a business.
Correct: that means you are not relaying data to a network, or retrieving data from a network.
Your claim was "We don't store your data, period."
I can't know for sure, but for the vast majority of applications, data is stored somewhere, be it on the device, or on the server. High scores? Game state? Levels completed? You sure you're not storing data?
That's why it was rejected.
Don't get me wrong, I don't think you're doing anything shady, I don't think you're doing it in the general terms people worry about, I very much doubt anyone will find out, or care if they did.
It's just a useful example of something that plays well in the HN comments section but not in the real world, I didn't even realize until a few months back.
These are de facto legal statements now. Every store requires them, and they're not paying a lawyer to double check them for you. You can get away with it on side project games, but it's not something you can get away with at a business.
> It's just a useful example of something that plays well in the HN comments section but not in the real world
I take it you're referring to the earlier, short one, of "We don't store your data, period." If that's the case, I think you're saying the same thing I did in a slightly different way and emphasizing different points? I agree, there's a prevalence of people that see simple and direct and make the mistake of equating simple with useful. Something being simple can be good, but not at the expense of greatly increasing the ambiguity of what it applies to.
I take it you're referring to the earlier, short one, of "We don't store your data, period." If that's the case, I think you're saying the same thing I did in a slightly different way and emphasizing different points? I agree, there's a prevalence of people that see simple and direct and make the mistake of equating simple with useful. Something being simple can be good, but not at the expense of greatly increasing the ambiguity of what it applies to.
Not on my device or my server. On yours? Sure, you've downloaded the app, it stores both code and assets, also highscores.
The rejected one makes me expect data is still being processed, or stored by third parties. The new one has a lot of fluff but at least it is clear that it doesn't collect anything and doesn't retain anything.
I would also reject the "We don't store your data, period".
That's like a pharmacist telling customers "we didn't add poison to this medicine".
That's like a pharmacist telling customers "we didn't add poison to this medicine".
I don't get this complaint. Of course I expect to find a privacy policy. And of course you can choose to write it in an unconventional way. Saying no data sent out of your device is a privacy policy. Saying it in a fancy way that contrasts between this app and something else is also a privacy policy.
> Of course I expect to find a privacy policy.
If the app store allowed you to specific in app metadata that no data leaves the device, and that was enforced by device policy, I wouldn't expect a privacy policy.
If the app store allowed you to specific in app metadata that no data leaves the device, and that was enforced by device policy, I wouldn't expect a privacy policy.
Device policies are actually harder than it may seem (to enforce that no data leaves the device). Here is a comment by a Google employee. It is about the internet access permission, but this part illustrates that side channels exist.
> Requests to be able to remove internet access are almost always really requests to “make sure this app can’t get any data off the device.” However, just removing this permission does not actually give that guarantee; there are numerous side-channels apps can use to still get data off the device. An obvious one is to launch the web browser with a URL for their web site, which has stashed in it a bunch of data they want to exfiltrate. And there are many others. It is really hard to actually give a guarantee that no data can be exfiltrated, while still giving enough capability for most apps to be functional.
Source: https://old.reddit.com/r/androiddev/comments/ci4tdq/were_on_...
> Requests to be able to remove internet access are almost always really requests to “make sure this app can’t get any data off the device.” However, just removing this permission does not actually give that guarantee; there are numerous side-channels apps can use to still get data off the device. An obvious one is to launch the web browser with a URL for their web site, which has stashed in it a bunch of data they want to exfiltrate. And there are many others. It is really hard to actually give a guarantee that no data can be exfiltrated, while still giving enough capability for most apps to be functional.
Source: https://old.reddit.com/r/androiddev/comments/ci4tdq/were_on_...
Right, but if an app agrees not to exfiltrate data via the app submission process, and then proceeds to do so, it's basically the same as the app having a privacy policy and then not adhering to it.
If an explicit "privacy policy" is required (for legal reasons or w/e), when an app submits "no data to be exfiltrated", the app store could say "here is the privacy policy you're agreeing to follow, no further action required".
If an explicit "privacy policy" is required (for legal reasons or w/e), when an app submits "no data to be exfiltrated", the app store could say "here is the privacy policy you're agreeing to follow, no further action required".
I don't know the Play Store app submission process, but if it isn't the case, it would be nice to have a bunch of pre-written privacy policies for common cases. Ideally hosted by Google, vetted by lawyers and explained in simple terms to both users and developers. And "we don't store any data" would be an obvious one, as well as those that use Google services exclusively (ads, ...).
That would make it easier for everyone.
That would make it easier for everyone.
Agreed, that would be good. Someone at Apple/Google should take a note.
> An obvious one is to launch the web browser with a URL for their web site, which has stashed in it a bunch of data they want to exfiltrate.
I mean ... just don't allow that, except for a finite whitelisted set of URLs that require explicit user intervention to access (to prevent exfiltration via timing/ordering)?
It's not difficult to make a rule that apps can easily follow, it's just that none of the parties involved actually care about the user.
I mean ... just don't allow that, except for a finite whitelisted set of URLs that require explicit user intervention to access (to prevent exfiltration via timing/ordering)?
It's not difficult to make a rule that apps can easily follow, it's just that none of the parties involved actually care about the user.
"No data leaves the device" is such a vague policy that it means nothing.
At a minimum, your app displays some UI containing its data. Bravo, information from the app now leaves the device through the photons emitted by the screen. Same for speakers.
Now consider the clipboard. The user copies some text from your app and pastes it into an online forum. Bravo, information from the app now leaves the device through the clipboard.
At a minimum, your app displays some UI containing its data. Bravo, information from the app now leaves the device through the photons emitted by the screen. Same for speakers.
Now consider the clipboard. The user copies some text from your app and pastes it into an online forum. Bravo, information from the app now leaves the device through the clipboard.
It really sucks that these privacy policies Google requires everyone to have also have to be hosted on a normal website. This means the privacy policy can change on a whim, and it means you can't read them until after you have already sent your IP address to the developer (as part of connecting to their website).
What is the value of the developer potentially knowing your IP address? They receive (1) a signal you were potentially interested and (2) can use GeoIP to learn your approximate location. This doesn't seem particularly valuable or egregious, what am I missing?
Until after you read the privacy policy, you can't know what they intend to do with that information. As a trivial example, they might be handing IP address information to third-parties--hell: the website itself might be hosted by a third-party (or might be behind a CDN provided by a third-party) or use frameworks/fonts hosted by third-parties, even if it isn't as ostentatious as "the website this policy is hosted on has a tracking pixel / login button / ad on it from a third-party"--who can then correlate that IP address with accesses to other websites. Really, depending on your Internet provider, your IP address should be thought of as a direct personal identifier; in my case, I use a residential cable service, so my IP address only changes about once a year, making it trivial to correlate what I do across sites.
Anything that connect internet that means you send IP addresses over to make request
You think only website do this ???
You think only website do this ???
you could send it to someone who you already trust, like google, instead of someone you are trying to decide on whether to trust or not
Do we really trust google? Why? Lol, as an entity it's proven it only cares about itself and making moar $$$$$$.
the context of this discussion is people installing apps from the google play store (something i do not do myself), so, yes, those people do trust google and indeed have already informed it in a personally identifiable way that they are pondering installing the app. having google provide them with the privacy policy for the app would be a pure improvement
[deleted]
In the security space, there are often modes that you can't think of ahead of time that become accessible through chaining a series of seemingly benign access modes. But here are some ideas:
GeoIP location is a real threat, sometimes you can get very precise. Cross-referencing with other services is another threat. It can also help with other targeted attacks, like phishing and exploit attempts. It can aid ISP and other types of surveillance.
GeoIP location is a real threat, sometimes you can get very precise. Cross-referencing with other services is another threat. It can also help with other targeted attacks, like phishing and exploit attempts. It can aid ISP and other types of surveillance.
They may be using google analytics, for example.
They don't use a content-hash (or some other means) to detect changes?
I used to have a privacy policy in a tweet. That worked for many years, but updating my offline apps (no backend, no analytics) always took multiple times. Until it just didn't pass. I had probably around 20 mails back and forth, where I pointed out that the tweet was according to all the requirements for the policy, but they kept rejecting.
Finally a human responded and said they just couldn't use social posts because of the comments or something like that. That there was zero risk for the end-user did not make a difference.
Since I suspected to be talking to an AI, I asked to mention 'cow' in the next response as a way to make clear I was talking to the human. The response was either by an AI, or a human who was able to express any humor:
> We appreciate you getting back to us and we apologize for any inconvenience this is causing you.
> Yes, you are communicating to a human being and per your request, please see the word "cow".
Finally a human responded and said they just couldn't use social posts because of the comments or something like that. That there was zero risk for the end-user did not make a difference.
Since I suspected to be talking to an AI, I asked to mention 'cow' in the next response as a way to make clear I was talking to the human. The response was either by an AI, or a human who was able to express any humor:
> We appreciate you getting back to us and we apologize for any inconvenience this is causing you.
> Yes, you are communicating to a human being and per your request, please see the word "cow".
I had a small role in helping Jamie port XScreenSaver to Android. It was fun working with someone whose writings I have been reading for thirty years or so, and I learned a lot from him (like the difference between HAVE and USE in C, or how to architect and run a project).
Patches are always welcome! Jamie (and/or other helpers) ported things like X11/Xlib to OpenGL, and then OpenGL to OpenGLES for iOS and Android. Jamie and so forth ported some of X11/Xlib's XFillPolygon to OpenGL - like for Convex shapes, and I did the Nonconvex shapes part, but we still didn't do Complex shapes yet. Lots of stuff like that outstanding (also it is still using GCC and make for the NDK, although Android has moved more towards LLVM/Clang and CMake).
Lots of interesting stuff and the code is open/free. As I said, patches always welcome, especially on the Android (and iOS) front.
Patches are always welcome! Jamie (and/or other helpers) ported things like X11/Xlib to OpenGL, and then OpenGL to OpenGLES for iOS and Android. Jamie and so forth ported some of X11/Xlib's XFillPolygon to OpenGL - like for Convex shapes, and I did the Nonconvex shapes part, but we still didn't do Complex shapes yet. Lots of stuff like that outstanding (also it is still using GCC and make for the NDK, although Android has moved more towards LLVM/Clang and CMake).
Lots of interesting stuff and the code is open/free. As I said, patches always welcome, especially on the Android (and iOS) front.
C doesn’t have things called HAVE and USE. Sounds to me like something to do with Xscreensaver’s build system?
I mean the conventions of HAVE and USE prefixed macros in C, as opposed to the C found in K&R or
C17-ISO/IEC 9899:2018.
Like this (they use HAS, not HAVE)
https://perl5.git.perl.org/perl5.git/blob/HEAD:/pp.c#l1259
or this
https://github.com/ruby/ruby/blob/master/st.c#L115
Like this (they use HAS, not HAVE)
https://perl5.git.perl.org/perl5.git/blob/HEAD:/pp.c#l1259
or this
https://github.com/ruby/ruby/blob/master/st.c#L115
Remember when "just a flashlight" apps outright stole user data? That's why.
I had the chance to develop on BlackBerry in the early 00's, and they prompted their user if the app wants to access things like the user's calendar or address book. If the user denied it, an exception would be thrown and a good app would be able to deal with it...
And then iPhone came along and Apple said "Trust us, our store review policy will save you.". And Android did the same. And Zuck said "Your data is safe, a Facebok app can't steal your data, because it'll get into trouble with us!". And then Cambridge Analytica data-mined FB users and used targetted ads on the gullible to deliver the election to Trump...
And then iPhone came along and Apple said "Trust us, our store review policy will save you.". And Android did the same. And Zuck said "Your data is safe, a Facebok app can't steal your data, because it'll get into trouble with us!". And then Cambridge Analytica data-mined FB users and used targetted ads on the gullible to deliver the election to Trump...
Part of the problem is that many users will be just click "Yes" without thinking.
The other part of the problem is that the apps receive an exception or equivalent at all. IMO, they should receive fake access that returns either no items or garbage data as applicable.
The other part of the problem is that the apps receive an exception or equivalent at all. IMO, they should receive fake access that returns either no items or garbage data as applicable.
This always seemed the right answer.
Prompt the user "App Foo wants to use calendar/pictures/location" and then you have options like "Allow", "Deny", "Allow with filtered data" (i. e. select just a few photos out of the gallery), or "Allow with bogus data" (generated gibberish that goes away after use)
Prompt the user "App Foo wants to use calendar/pictures/location" and then you have options like "Allow", "Deny", "Allow with filtered data" (i. e. select just a few photos out of the gallery), or "Allow with bogus data" (generated gibberish that goes away after use)
Dozens of innocuous-seeming apps collect private data. I wish the world wasn't filled with bad actors, but it is. So having a basic privacy policy even for this is annoying, but the answer to "It's a screen saver, why in the world do I need this?" is "because bad actors do bad stuff so everyone suffers."
I wonder if this couldn't be solved at the OS level. Maybe there could be some kind of a flag that, if the OS sees it, the app is not allowed to store/save/communicate/whatever. Then, any app that has this flag doesn't need a privacy policy because it is OS restricted from doing anything that might require such a policy?
I suggest this as someone who has no experience whatsoever in making apps or mobile operating systems (beyond being a user of one), so I don't know how practical it is.
I suggest this as someone who has no experience whatsoever in making apps or mobile operating systems (beyond being a user of one), so I don't know how practical it is.
Android has a permission for internet access. It's still there, but enabled for everybody by default. This was an intentional decision on the part of Google.
Back in the day, you could install Android apps that explicitly did not use the internet permission. You could make your installation decisions based on whether apps requested that permission and whether it made sense for them to do so. Some AOSP mods even let you disable that permission for apps (though YMMV as to how well that actually worked in practice).
Back in the day, you could install Android apps that explicitly did not use the internet permission. You could make your installation decisions based on whether apps requested that permission and whether it made sense for them to do so. Some AOSP mods even let you disable that permission for apps (though YMMV as to how well that actually worked in practice).
It's probably an absolute minority of apps which doesn't do any network stuff at all. And even if they don't reach for the network themselves they might have a link to open a support website, prefilling some data based on the device/user, in the default browser.
> Dozens of innocuous-seeming apps collect private data
Like Google Play, Google Chrome, Google Photos, Google Phone, Google Contacts and so on and so forth.
This is a very perverse thing from Google.
Like Google Play, Google Chrome, Google Photos, Google Phone, Google Contacts and so on and so forth.
This is a very perverse thing from Google.
My problem with privacy policies. is that they are not enforceable, or, at least I don't think they are enforceable.
It is not a contract with the end user. it also is not a machine(program) that has to operate a specific way. what happens when it is violated. who figures out what was violated, who the damaged party is and what and where the fines are to be paid. Nobody.
They would be better off called "statement of intent" rather than this theater of pretending there is a policy in play.
It is not a contract with the end user. it also is not a machine(program) that has to operate a specific way. what happens when it is violated. who figures out what was violated, who the damaged party is and what and where the fines are to be paid. Nobody.
They would be better off called "statement of intent" rather than this theater of pretending there is a policy in play.
What I find ironic is that his privacy policy probably stores more data than the app. (there must be logs, or at least ephemeral connection tables on the webserver)
related, I think privacy policies should be local, on-device. Not a pointer to possibly changing data. Not requiring a network connection (and possible identification).
related, I think privacy policies should be local, on-device. Not a pointer to possibly changing data. Not requiring a network connection (and possible identification).
JWZ's headline perhaps should have been: "due to intentionally defective design android is unable to guarantee apps cannot steal your data and so google requires app makers to make unenforceable promises about which data they will and won't steal"
> For a screen saver. A privacy policy. For a screen saver.
The point is that it is obvious to you. It's not obvious to your users. That's what the privacy policy helps with. An app of any kind can be doing more than you may think.
There are many things to complain about with Google. This isn't one of them.
The point is that it is obvious to you. It's not obvious to your users. That's what the privacy policy helps with. An app of any kind can be doing more than you may think.
There are many things to complain about with Google. This isn't one of them.
You know how we always hear about basic flashlight apps that get used to run advertising click farms in the background, or Flappy Bird knockoffs that collect detailed location data and have access to your photo gallery?
I'm with you on this one. In a perfect world it would be evident that a simple little app isn't doing anything nefarious, but... clearly even a screensaver app can be a front for some nasty shit. Making your good intentions explicit can only help!
I'm with you on this one. In a perfect world it would be evident that a simple little app isn't doing anything nefarious, but... clearly even a screensaver app can be a front for some nasty shit. Making your good intentions explicit can only help!
> You know how we always hear about basic flashlight apps that get used to run advertising click farms in the background, or Flappy Bird knockoffs that collect detailed location data and have access to your photo gallery?
But they would sure not be lying in their privacy policy, right?
But they would sure not be lying in their privacy policy, right?
Ha, good point. I'd actually be curious whether those apps had (bogus) privacy policies or just went without altogether.
[deleted]
Many, many pieces of malware were distributed as windows .scr files. Some were just viruses abusing the extension. A ton were bonzi-buddy-esque data-harvesters where users were encouraged by advertising to install "Free cute and funny screensavers!" (many were literally just oneko+malware).
Oh, and the part about location data is blatantly untrue, because one of the options on mapscroller is "Current City".
Oh, and the part about location data is blatantly untrue, because one of the options on mapscroller is "Current City".
Where do you see that option?
I don't see "Current City" in the source, and the documentation only says:
> "Random‐city" means to select from a built‐in list of several hundred major cities. This is the default.
> Otherwise, this must be a latitude/longitude pair, as floats.
Furthermore, hacks/glx/mapscroller.c says:
I don't see "Current City" in the source, and the documentation only says:
> "Random‐city" means to select from a built‐in list of several hundred major cities. This is the default.
> Otherwise, this must be a latitude/longitude pair, as floats.
Furthermore, hacks/glx/mapscroller.c says:
* Network access and management of the image file cache happens in the
* mapscroller.pl helper program, since doing https from C code is untenable.
* Sadly, this division of labor means that this program won't work on iOS or
* Android.I love this. This type of behaviour should be ubiquitous. Fuck all those FAANG corps imo.
(IIRC jwz's "testicle cup" image HN referrer redirect is no longer active/functional.)
Anyway, I get that jwz loves to be inflammatory toward everyone because that's who he is, but if Google didn't require privacy policies for every listed app, I'm sure a bunch of people would be crying foul.
I could easily imagine a shitty ad-supported screensaver that was somehow using your data to target/sell ads. Remember that we live in a world where flashlight apps have been used to exfiltrate data from phones. Or perhaps a more innocuous use of user data: maybe the app tracks which screensavers are used and sends that data to the developer.
And, regardless, I see no problem with a company not wanting to have to do manual review to determine what apps do and don't require privacy policies, and just blanket-requiring them of everyone.