Apple could have a similar situation. Via the iOS SDK, developers can ask for access for a phone’s address book. These contact connections could be harvested by bad developers. They could also be sold by those developers. This is merely one example. All companies with data and APIs are vectors of attack.
The difference is that the data is on your phone, not Apple's servers (unless you back up with iCloud, but even then I believe it's encrypted). You can decide which apps to run on your device; you have no control over what Facebook does on its servers.
Definitely a difference but there is a similarity in vectors of attack: The contact address book can be taken off the phone using the Apple SDK. Then, that data can be anywhere the developer wants to store it.
This is non-issue. Do you really want a mobile OS where third party apps can literally do nothing? No contacts, photos, camera, accelerometer, gps, microphone.
Each one of those explicitly requests the users permission. Facebook would track you across the internet just using Share buttons on webpages.
Facebook's issues stem from historical overly-permissive API access that could effectively harvest your graph via a single node's acceptance. Some small facsimile of that is represented by your example but not to the scope it was with Facebook. It's a one-to-many but not a graph. I think this is important natural constraint and a noteworthy distinction. It makes connecting data more of a crapshoot.
Apple is equipped with far more resources at present to deal with app review than Facebook has. They've traditionally been far more draconian about their own rules than has Facebook. This means something like what you describe is less likely to fall through the cracks or propagate the way abuse did with FB in the pre-2014 days.
You're 100% right that any access is effectively a vector, but that's needless reductivism. In 2018 society seems to accept some level of visibility but not unfettered visibility. This is the balance that social media and data gatekeepers will have to contend with.
That said, it doesn't take much to tip the scales these days. People tend to have a healthier skepticism toward the giants of tech these days, and if you burn a little bad PR it can have some terrible consequences. Which is why Facebook has pulled some plugs in a panic on the developer side of things in response.
As has been mentioned countless times in the wake of this kerfuffle, MySpace was the defacto social media company until one day they weren't. It's eas(ier) to introduce competition to Facebook over, say, Apple or Microsoft.
Finally, Facebook's product is, well, data. One could argue that it's a platform and data, but the former is a loss leader for the latter.
So for a number of reasons I find it unlikely that even were Apple to have a PR misstep like this that they'd face the same existential crisis.
They could have, but that's why Apple has an app review process. It's been criticised (by me, for one) for being heavy handed and slow, but recent events have shown that there's a wisdom to it.
No one really knows. But I wouldn't be surprised if there's a mix - I'm sure there's some automated investigation of how much data is sent, when and what that data is.
Seems to me the biggest takeaway from the article was that it was Lego's partnerships that saved the company. Without those deals with Star Wars (for example), the company would have not needed to meet demands in the first place. This seems like a big lesson to learn from.
Where is native support for iOS and Android? Why do we bother generating the same assets for different screen densities? Am I the only one who wants SVGs on mobile?
One of the things I like about hybrid apps (Cordova, Ionic, etc) is that this is a solved problem since you basically develop on top of Chromium (Android) and WKWebView (iOS). I already do heavy use of SVGs on mobile apps for everything, including animations, and I'm quite happy with the results and the workflow. No more asset-hell, everything's a vector.
Design once in Illustrator (export SVGs) -> Code once -> Run everywhere
Android supports a sub-set of SVG in its VectorDrawable and AnimatedVectorDrawable classes. There is also tooling to convert SVG into VectorDrawables.
It is definitely a partial subset and creating VectorDrawables from any sort of design program is a giant PITA. The best strategy is making an SVG and then going through the XML by hand and turning it into a drawable (ugly I know).
Clearly this is the future direction of Android, but as of today it is still only half implemented.
As for why we didn't have SVG from day 1 on Android, I'm going to guess that is all a performance optimization. It's hard to overstate just how slow & weak early smart phones (iPhone & Android) were relative to today. We've expanded the scope of the apps to fill the available resources (as software engineers always do), but now there is enough head room to handle it all.
Apple & Xcode support the same concept, but with PDFs. You can add a PDF to an "imageset", and at build time it will be rasterized into different resolutions for different devices.
Because you have to basically implement half a browser for SVG. You need to parse the XML into a DOM and apply CSS that you also need to parse (also javascript in case of animated SVGs that use JS)
SVG specification distinguishes two types of conforming SVG viewers: static and dynamic [1]. The static viewer does not have to support scripting, animations and user interaction.
A good example of a relatively small static SVG viewer/renderer is libRSVG which is used by GNOME project to render icons.
The main size is dealing with libxml, but that's readily handled by smaller xml libraries [http://pugixml.org]. I mean, maybe you don't want to do SVG on an arduino.
Directly comparing SVG and PNG libraries purely based on library size is misleading. PNG's aren't layered, don't contain semantic information, etc. For me librsvg is lightweight since its way better than installing phantomjs as I have been doing to generate embedable PNGs for documents.
As a user, having to file a form using EchoSign, I would to cringe. It requires flash and has some really bad usability. An example of that is requiring at least two non-standardized date formats. UX is important for forms because humans make errors when information is not clear.
This is obviously very cool. My one thought is that it would be very hard for children to use. It's important to consider adoption from a wide audience.
This is perhaps one of my favorite Bittman quotes. I can't remember it verbatim, but it was essentially lamenting how we have devalued working in your own home. In his case, he was referring to cooking, but I feel the overall point is rather relevant.
This just shows that the current state of Javascript is a confusing mess. Where do new developers start now when they are been fed ES6 transpilers and ReactJS.
I think Google (as usual) is getting ahead of this problem. But they shouldn't be alone in the fight for clarity.
Having a solution pushed forward by arguably the most influential implementation team is what pushes it forward, not the fact that it's "just another option". Regardless of what Chrome implements (whether it's this, or raw TypeScript, or CofeeScript), the fact that it works directly in V8 is what pushes that solution to the top of the stack.
It depends on where you're coming from, but for lots of people who want to make something, there's probably some kind of tutorial or library with examples that puts it in reach. Pair that with the fact that JavaScript as a language has a small number of fundamental concepts and a great free REPL and user interface environment (the DOM), and you get lots of people making lots of things that would otherwise be more expensive or less accessible.
> But they shouldn't be alone in the fight for clarity.
They're starting with TypeScript which was Hejlsberg's project at Microsoft. Microsoft wants people to develop web apps for Microsoft server platforms, and you can use TypeScript with intellisense in Visual Studio. We'll see if Microsoft puts it in the browser but it seems like they already have a stake in the success, at least.
Perhaps new developers shouldn't transpile at all, or may use a single transpiler. It certainly could get confusing working with multiple transpilation layers.
