ALOT of apps are starting to do this. I believe Snapchat initially was the company that began doing it. When a site like Facebook uses your number to identify you, this feature actually makes sense.
I wonder if more fine-grained permissions would make more sense for this sort of feature. Perhaps it would be better if Android had support for "This app may read text messages from 1-800-XXX-XXXX" or something similar instead.
With it, I have extremely fine-grained access control to a wide variety of "system calls", including access to contacts, text messages and to the device phone number.
In this case, I can permit access temporarily during the 2FA, and then return garbage values the rest of the time. Easy. (Though obviously if they harvest my text messages for other purposes during 2FA, that is a problem - but one can that can be technically solved within XPrivacy imo.)
In other cases, such as running Skype, I deny access to everything always (phone number, my location, contacts, Google accounts are the things Skype makes system calls for) and Skype continue to works fine, so I think this is a viable strategy.
since first being introduced to XPrivacy, I absolutely can not use an android phone without it. It really opened my eyes to how invasive some apps are when running in the background or just inappropriately accessing info in general (especially location information!)
It sucks that you have to have a rooted device to use this. While I think Android in general is fantastic, I'm torn but the fact that I am forced to choose between having control of my privacy or being able to use online banking, get regular updates etc.
I agree! I found this version to be much easier for some reason. Possibly the brain is quicker to recognize and match the colours than when I'm forcing myself to look for numbers?
I don't totally see the point to these arguments. The inherent nature of the technology we have means that if they can view it once, they can view it as long and as many times as they want. Anything trying to restrict that is just futile -- look at DRM.
Snapchat has never given that particular illusion of privacy. As the most common and basic example, it has absolutely no way of stopping people from simply taking a screenshot of your image. Snapchat is meant to be used to share throwaway photos without the social expectation that comes from putting it on somewhere like Facebook. Anyone who uses the application learns quickly that someone can potentially store the photo they sent -- in a vast variety of ways.
What the people who don't use Snapchat don't realize, is that you still have to trust someone if you're sending compromising photos. The benefit to Snapchat is that you don't have to worry about the recipients future negligence exposing them.
Actually it does attempt to do that - it requires you keep your finger on the screen while viewing so you can't perform whatever the screenshot command is. Which is lame but that's not the point - their selling point is that they do claim the images are transient. I'll wager 90% of their traffic is images people would not want made public, and some of it will be technically illegal.
The benefit to the user is that it establishes a social convention. You are unambiguously asking your friend not to share something around. It provides enough technical protection to prevent people sharing in the heat of the moment. In that sense it is like a changing room curtain.
I would take that wager. It's far less focused on nudes and illegal stuff than you would think. Most of it is just silly dumb photos or those that don't warrant being shared forever.
It used to be that taking a screenshot briefly stopped the touch event, so it could notify the sender when you took a screenshot.
iOS 7 fixed that bug, but added an official way for apps to detect screenshots. I would guess snapchat has just hung on to their old interface out of tradition, since it still works. It just doesn't have anything to do with screenshots anymore.
> I don't totally see the point to these arguments.
Yes and no. The encryption key is fixed? Why not use a session key that is (nominally) ephemeral to the running snapchat process at least?
> if they can view it once
I have a camera and a phone. I can record anything displayed on my phone forever regardless of technology, and so can a three year old. Especially for "sensitive" snapchats, the "analog hole" (aka: a human has to be able to view it for it to be visual communication) renders all these ideas moot. It has absolutely nothing to do with "clever" drm-like hacks.
I agree, I just hope the average snapchat user realizes that there's no guarantee the pictures they're sending can be archived forever (especially the younger users).
I never used the app though, and I just tried to go to their website to see how they communicate on this issue just to discover that snapchat.com doesn't contain a single description of the service. There's just a silly video on the frontpage (turtle fights? I'm not sure about the ethics of that) and links to download the app. It's crazy that something so new is already popular enough that they don't even need to explain what it is anymore.
That being said on both apple's and google's app stores the description of the app mentions that the user can make a screenshot and save the picture, so at least they don't try to hide this limitation.
In app purchases are fine, but be HONEST about it.
Not being upfront about the costs of your game directly misleads the customer and, in my opinion, is a terrible and abusive way to earn revenue.
This is great. Proper cryptography is the solution to so many of the problems the modern internet is facing right now, but the key problem with cryptography is that it is never user friendly enough and never distributed enough.
This looks like a great step in the right direction.
The term "disc scrub" makes little to no sense in terms of SSDs, which makes this issue even more complicated. People who work in the disc recovery field have been dealing with this since SSDs became popular.
An SSD is limited by its number of writes. To compensate for this, the SSD has very complicated on board logic that abstracts the actual SSD away from what it tells the OS system. This allows it to do certain tricks to save writes. However, when you are "scrubbing" an SSD, internally the SSD might be writing somewhere else entirely. Scrubbing is not considered an effective way of wiping SSDs, from what I believe.
There is a vast difference between writing out zeroes to the SSD but still having some of the original data potentially persist on the SSD but unreachable without special techniques, and not zeroing out the SSD and giving the device to a new VM and letting it trivially access everything that was previously there.
If I can provision a new VM and cat /dev/vda and see data from the VM that previously occupied that spot, then you are doing it horribly, horribly, horribly wrong.
That zeroing out the data leaves open a different and vastly more difficult attack path doesn't make that any less true.
Ok, so the data isn't necessarily destroyed immediately after a scrub. But how does that play out at the level of VM users? Is there a normal usage scenario where the portion of the SSD containing my deleted data is made readable to someone else's VM, or will it be inaccessible to normal VM users until it's overwritten?
I'm not an expert on this, but I believe that at the VM user level they would see wiped data because of the internal mapping. I think physical analysis of the drive would be required.
I imagine it assumes a header like X-Requested-By has not been manipulated. You can safely assume that the referrer, or other headers, have not been manipulated. There is no way for malicious Javascript running in the users browser to edit headers.
Of course, anyone can code their own browser to lie about headers. It doesn't make much sense to specifically open yourself to vulnerabilities though.
I think it's important to note that this is a bug that effects older browsers only. Modern IE, Chrome, and Firefox have security measures that do not allow scripts to capture values passed to constructors of a literal. That way, this hack is only needed for older browsers and will hopefully not be needed at all in the future. For more info: http://stackoverflow.com/a/16880162/372767
Also note that this attack, JSON Hijacking, is different than a CSRF (Cross Site Request Forgery) and has little to do with CSRF tokens.
> Modern [browsers] have security measures that do not allow scripts to capture values passed to constructors of a literal.
Actually, it's not security measures so much as implementing ECMAScript 5, which explicitly says that array literals must use the built-in constructor, not any override. See 11.1.4 [1], which reads:
> Let array be the result of creating a new object as if by the expression new Array() where Array is the standard built-in constructor with that name.
Object works similarly, and is in 11.1.5. I'm not certain what earlier standards said here, but I suspect they didn't say anything.
Actually, ie is still vulnerable to a very similar attack in some cases, specifically you can leak responses containing small json array by inlining the json as a script[src=vbscript] tag. Disclosed here: http://en.wooyun.org/bugs/wooyun-2013-023
with the status "unable to contact the vendor or actively neglected by the vendor" :-/
Edit: I meant "injecting" not inlining. Thanks chc for pointing that out.
If it has to be inlined, how is that the same vulnerability? I thought the vulnerability was that script tags can fetch external scripts and a local script intercept the results. If you have to inline both scripts, you can only attack yourself.
Wow, I was just having this discussion on an issue for a CSRF protection gem[0]. From what I can tell, IE wasn't even susceptible to this (perhaps accidentally) as far back as 6, and it's been fixed in Firefox since 3.1, and Chrome around the same time. I've been wanting to run a test case against a bunch of browsers to prove it to myself, but this seems to be a complete non-issue nowadays.
Well, one thing to do with the tokens might be that if the token were required for the GET request in question, then stealing the content via script tag may be harder. OTOH, putting one-time tokens on every request might be a bit too much for many apps, while(1) hack may be more efficient.
Unfortunately, this is what happens to online communities. Particularly those run by teenagers. I've been a member of a number of communities that have suffered deaths in very similar ways -- choked by the people who own the rights at the expense of the volunteers and the community.
It's unfortunate, because I find that often volunteer teenagers are the ones that truly have a passion for doing what they are doing, but they get held up by corporations or by people who want to monetize. When that doesn't work, the people in charge ignore the community until it dies.
> * have a passion for doing what they are doing, but they get held up by corporations or by people who want to monetize. *
Could those "passionate teenagers" have kept it running instead of selling the site in 2004 (why didn't they?), or would it have died much earlier if some "greedy" corporation hadn't picked it up and paid the bills all these years? It's great to have the passion to build something cool, but it's a little cooler if it's sustainable.
I don't know the history of this site, but it seems unlikely that most of the 'passionate teenagers' volunteers of the site throughout it's history didn't see any of the money that exchanged hands in 2004. It's usually got nothing to do with whether it was sustainable without a sale or not, it's just minority that owns 'the rights' deciding they can cash in, right?
Incorrect - the 3 founders that received money actually did spread the money around a bit to those who were working on the site for a while and/or had contributed in some major way. They had a lot of volunteers, so the percentage that got money I heard was small but it was that small group that did the large percentage of contributions.
I wonder if more fine-grained permissions would make more sense for this sort of feature. Perhaps it would be better if Android had support for "This app may read text messages from 1-800-XXX-XXXX" or something similar instead.