The Intel® HTML5 App Porter Tool - BETA is an application
that helps mobile application developers to port native iOS* code into
HTML5, by automatically translating portions of the original code into
HTML5. This tool is not a complete solution to automatically port 100%
of iOS* applications, but instead it speeds up the porting process by
translating as much code and artifacts as possible.
It helps in the translation of the following artifacts:
Objective-C* (and a subset of C) source code into JavaScript
iOS* API types and calls into JavaScript/HTML5 objects and calls
Layouts of views inside Xcode* Interface Builder (XIB) files into HTML + CSS files
Xcode* project files into Microsoft* Visual Studio* 2012 projects
This document provides a high-level explanation about how the
tool works and some details about supported features. This overview will
help you determine how to process the different parts of your project
and take the best advantage from the current capabilities.
How does it work?
The Intel® HTML5 App Porter Tool - BETA is essentially a
source-to-source translator that can handle a number of conversions from
Objective-C* into JavaScript/HTML5 including the translation of APIs
calls. A number of open source projects are used as foundation for the
conversion including a modified version of Clang front-end, LayerD framework and jQuery Mobile for widgets rendering in the translated source code.
Translation of Objective-C into JavaScript
At a high level, the transformation pipeline looks like this:
This pipeline follows the following stages:
Parsing of Objective-C* files into an intermediate AST (Abstract Syntax Tree).
Mapping of supported iOS* API calls into equivalent JavaScript calls.
Generation of placeholder definitions for unsupported API calls.
Final generation of JavaScript and HTML5 files.
About coverage of API mappings
Mapping APIs from iOS* SDK into JavaScript is a task that involves a
good deal of effort. The iOS* APIs have thousands of methods and
hundreds of types. Fortunately, a rather small amount of those APIs are
in fact heavily used by most applications. The graph below conceptually
shows how many APIs need to be mapped in order to have certain level of
translation for API calls .
Currently, the Intel® HTML5 App Porter Tool - BETA supports the most used types and methods from:
UIKit framework
Foundation framework
Additionally, it supports a few classes of other frameworks such
as CoreGraphics. For further information on supported APIs refer to the
list of supported APIs.
Generation of placeholder definitions and TODO JavaScript files
For the APIs that the Intel® HTML5 App Porter Tool - BETA
cannot translate, the tool generates placeholder functions in "TODO"
files. In the translated application, you will find one TODO file for
each type that is used in the original application and which has API
methods not supported by the current version. For example, in the
following portion of code:
If property setter for showsTouchWhenHighligthed is not supported by the tool, it will generate the following placeholder for you to provide its implementation:
These placeholders are created for methods, constants, and types that
the tool does not support. Additionally, these placeholders may be
generated for APIs other than the iOS* SDK APIs. If some files from the
original application (containing class or function definitions) are not
included in the translation process, the tool may also generate
placeholders for the definitions in those missing files.
In each TODO file, you will find details about where those types,
methods, or constants are used in the original code. Moreover, for each
function or method the TODO file includes information about the type of
the arguments that were inferred by the tool. Using these TODO files,
you can complete the translation process by the providing the
placeholders with your own implementation for that API.
Translation of XIB files into HTML/CSS code
The Intel® HTML5 App Porter Tool - BETA translates most of the definitions in the Xcode* Interface Builder files (i.e.,
XIB files) into equivalent HTML/CSS code. These HTML files use JQuery*
markup to define layouts equivalent to the views in the original XIB
files. That markup is defined based on the translated version of the
view classes and can be accessed programmatically. Moreover, most
of the events that are linked with handlers in the original application
code are also linked with their respective handles in the translated
version. All the view controller objects, connection logic between
objects and event handlers from all translated XIB files are included in
the XibBoilerplateCode.js. Only one XibBoilerplateCode.js file is created per application.
The figure below shows how the different components of each XIB file are translated.
This is a summary of the artifacts generated from XIB files:
For each view inside an XIB file, a pair of HTML+CSS files is generated.
Objects inside XIB files, such as Controllers and Delegates, and instantiation code are generated in the XibBoilerplateCode.js file.
Connections between objects and events handlers for views described
inside XIB files are also implemented by generated code in the XibBoilerplateCode.js file.
The translated application keeps the very same high level structure
as the original one. Constructs such as Objective-C* interfaces,
categories, C structs, functions, variables, and statements are kept
without significant changes in the translated code but expressed in
JavaScript.
The execution of the Intel® HTML5 App Porter Tool – BETA produces a set of files that can be divided in four groups:
The translated app code: These are the JavaScript files that were created as a translation from the original app Objective-C* files.
For each translated module (i.e. each .m file) there should be a .js file with a matching name.
The default.html file is the entry point for the HTML5 app, where all the other .js files are included.
Additionally, there are some JavaScript files included in the \lib folder that corresponds to some 3rd party libraries and Intel® HTML5 App Porter Tool – BETA library which implements most of the functionality that is not available in HTML5.
Translated .xib files (if any): For each translated .xib file there should be .html and .css files with matching names. These files correspond to their HTML5 version.
“ToDo” JavaScript files: As the translation of some of the
APIs in the original app may not be supported by the current version,
empty definitions as placeholders for those not-mapped APIs are
generated in the translated HTML5 app. This “ToDo” files contain those
placeholders and are named after the class of the not-mapped APIs. For
instance, the placeholders for not-mapped methods of the NSData class, would be located in a file named something like todo_api_js_apt_data.js or todo_js_nsdata.js.
Resources: All the resources from the original iOS* project will be copied to the root folder of the translated HTML5 app.
The generated JavaScript files have names which are practically the
same as the original ones. For example, if you have a file called AppDelegate.m in the original application, you will end up with a file called AppDelegate.js
in the translated output. Likewise, the names of interfaces, functions,
fields, or variables are not changed, unless the differences between
Objective-C* and JavaScript require the tool to do so.
In short, the high level structure of the translated application is
practically the same as the original one. Therefore, the design and
structure of the original application will remain the same in the
translated version.
About target HTML5 APIs and libraries
The Intel® HTML5 App Porter Tool - BETA both translates the
syntax and semantics of the source language (Objective-C*) into
JavaScript and maps the iOS* SDK API calls into an equivalent
functionality in HTML5. In order to map iOS* API types and calls into
HTML5, we use the following libraries and APIs:
The standard HTML5 API: The tool maps iOS*
types and calls into plain standard objects and functions of HTML5 API
as its main target. Most notably, considerable portions of supported
Foundation framework APIs are mapped directly into standard HTML5. When
that is not possible, the tool provides a small adaptation layer as part
of its library.
The jQuery Mobile library: Most of the UIKit
widgets are mapped jQuery Mobile widgets or a composite of them and
standard HTML5 markup. Layouts from XIB files are also mapped to jQuery
Mobile widgets or other standard HTML5 markup.
The Intel® HTML5 App Porter Tool - BETA library:
This is a 'thin-layer' library build on top of jQuery Mobile and HTML5
APIs and implements functionality that is no directly available in those
libraries, including Controller objects, Delegates, and logic to
encapsulate jQuery Mobile widgets. The library provides a facade very
similar to the original APIs that should be familiar to iOS* developers.
This library is distributed with the tool and included as part of the
translated code in the lib folder.
You should expect that future versions of the tool will incrementally
add more support for API mapping, based on further statistical analysis
and user feedback.
Translated identifier names
In Objective-C*, methods names can be composed by several parts
separated with colons (:) and the methods calls interleaved these parts
with the actual arguments. Since that peculiar syntactic construct is
not available in JavaScript, those methods names are translated by
combining all the methods parts replacing the colons (:) with
underscores (_). For example, a function called initWithColor:AndBackground: is translated to use the name initWithColor_AndBackground
Identifier names, in general, may also be changed in the translation
if there are any conflicts in JavaScript scope. For example, if you have
duplicated names for interfaces and protocol, or one instance method
and one class method that share the same name in the same interface.
Because identifier scoping rules are different in JavaScript, you cannot
share names between fields, methods, and interfaces. In any of those
cases, the tool renames one of the clashing identifiers by prepending an
underscore (_) to the original name.
Additional tips to get the most out of the Intel® HTML5 App Porter Tool – BETA
Here is a list of recommendations to make the most of the tool.
Keep your code modular Having a
well-designed and architected source code may help you to take the most
advantage of the translation performed by tool. If the modules of the
original source code can be easily decoupled, tested, and refactored the
same will be true for the translated code. Having loosely coupled
modules in your original application allows you to isolate the modules
that are not translated well into JavaScript. In this way, you should be
able to simply skip those modules and only select the ones suitable for
translation.
Avoid translating third party libraries source code with equivalents in JavaScript
For some iOS* libraries you can find replacement libraries or APIs in
JavaScript. Common examples are libraries to parse JSON, libraries to
interact with social networks, or utilities libraries such as Box2D* for
games development. If your project originally uses the source code of
third party library which has a replacement version in JavaScript, try
to use the replacement version instead of translated code, whenever it
is possible.
Isolate low level C or any C++ code behind Objective-C* interfaces:
The tool currently supports translating from Objective-C*, only. It
covers the translation of most of C language constructs, but it does not
support some low level features such as unions, pointers, or bit
fields. Moreover, the current version does not support C++ or
Objective-C++ code. Because of this limitation, it is advisable to
encapsulate that code behind Objective-C interfaces to facilitate any
additional editing, after running the tool.
In conclusion, having a well-designed application in the first place
will make your life a lot easier when porting your code, even in a
completely manual process.
Further technical information
This section provides additional information for developers and it is not required to effectively use Intel® HTML5 App Porter Tool - BETA. You can skip this section if you are not interested in implementation details of the tool.
Implementation of the translation steps
Here, you can find some high level details of how the different processing steps of the Intel® HTML5 App Porter Tool - BETA are implemented.
Objective-C* and C files parsing
To parse Objective-C* files, the tool uses a modified version of clang parser. A custom version of the parser is needed because:
iOS* SDK header files are not available.
clang is only used to parse the source files (not to compile them) and dump the AST to disk.
The following picture shows the actual detailed process for parsing .m and .c files:
Missing iOS* SDK headers are inferred as part of the parsing process.
The header inference process is heuristic, so you may get parsing
errors, in some cases. Thus, you can help the front-end of the tool by
providing forward declaration of types or other definitions in header
files that are accessible to the tool.
Also, you can try the "Header Generator" module in individual files
by using the command line. In the binary folder of the tool, you will
find an executable headergenerator.exe that rubs that process.
Objective-C* language transformation into JavaScript
The translation of Objective-C* language into JavaScript involves a
number of steps. We can divide the process in what happens in the
front-end and what is in the back-end.
Steps in the front-end:
Parsing .m and .c into an XML AST.
Parsing comments from .m, .c and .h files and dumping comments to disk.
Translating Clang AST into Zoe AST and re-appending the comments.
The output of the front-end is a Zoe program. Zoe is an
intermediate abstract language used by LayerD framework; the engine that
is used to apply most of the transformations.
The back-end is fully implemented in LayerD by using compile time
classes of Zoe language that apply a number of transformations in the
AST.
Steps in the back-end:
Handling some Objective-C* features such as properties getter/setter injection and merging of categories into Zoe classes.
Supported iOS* API conversion into target JavaScript API.
Injection of not supported API types, or types that were left outside of the translation by the user.
Injection of dummy methods for missing API transformations or any other code left outside of the translation by the user.
JavaScript code generation.
iOS* API mapping into JavaScript/HTML5
The tool supports a limited subset of iOS* API. That subset is
developed following statistical information about usage of each API.
Each release of the tool will include support for more APIs. If you miss
a particular kind of API your feedback about it will be very valuable
in our assessment of API support.
For some APIs such as Arrays and Strings the tool provides direct
mappings into native HTML5 objects and methods. The following table
shows a summary of the approach followed for each kind of currently
supported APIs.
Framework
Mapping design guideline
Foundation
Direct mapping to JavaScript when possible. If direct mapping is not possible, use a new class built over standard JavaScript.
Core Graphics
Direct mapping to Canvas and related HTML5 APIs when possible. If
direct mapping is not possible, use a new class built over standard
JavaScript.
UIKit Views
Provide a similar class in package APT, such as APT.View for UIView,
APT.Label for UILabel, etc. All views are implemented using jQuery
Mobile markup and library. When there are not equivalent jQuery widgets
we build new ones in the APT library.
UIKit Controllers and Delegates
Because HTML5 does not provide natively controllers or delegate
objects the tool provides an implementation of base classes for
controllers and delegates inside the APT package.
Direct mapping implies that the original code
will be transformed into plain JavaScript without any type of additional
layer. For example,
The entire API mapping happens in the back-end of the tool. This
process is implemented using compile time classes and other
infrastructure provided by the LayerD framework.
XIB files conversion into HTML/CSS
XIB files are converted in two steps:
XIB parsing and generation of intermediate XML files.
Intermediate XML files are converted into final HTML, CSS and JavaScript boilerplate code.
The first step generates one XML file - with extension .gld -
for each view inside the XIB file and one additional XML file with
information about other objects inside XIB files and connections between
objects and views such as outlets and event handling.
The second stage runs inside the Zoe compiler of LayerD to convert
intermediate XML files into final HTML/CSS and JavaScript boilerplate
code to duplicate all the functionality that XIB files provides in the
original project.
Generated HTML code is as similar as possible to static markup used
by jQuery Mobile library or standard HTML5 markup. For widgets that do
not have an equivalent in jQuery Mobile, HTML5, or behaves differently,
simple markup is generated and handled by classes in APT library.
Supported iOS SDK APIs for Translation
The following table details the APIs supported by the current version of the tool.
Notes:
Types refers to Interfaces, Protocols, Structs, Typedefs or Enums
Type 'C global' mean that it is not a type, but it is a supported global C function or constant
Colons in Objective-C names are replaced by underscores
Objective-C properties are detailed as a pair of getter/setter method names such as 'title' and 'setTitle'
Objective-C static members appear with a prefixed underscore like in '_dictionaryWithObjectsAndKeys'
Inherited members are not listed, but are supported. For example,
NSArray supports the 'count' method. The method 'count' is not listed in
NSMutableArray, but it is supported because it inherits from NSArray
How anonymous are you when browsing online? If you're not sure, head
to StayInvisible, where you'll get an immediate online privacy test
revealing what identifiable information is being collected in your
browser.
The site displays the location (via IP address) and
language collected, possible tracking cookies, and other browser
features that could create a unique fingerprint of your browser and session.
If you'd prefer your browsing to be private and anonymous, we have lotsof guidesfor that. Although StayInvisible no longer has the list of proxy tools we mentioned previously, the site is also still useful if you want to test your proxy or VPN server's effectiveness. (Could've come in handy too for a certain CIA director and his biographer.)
A screenshot of a system containing a
malicious backdoor that was snuck into the open-source phpMyAdmin
package. Researchers said the file date may be fraudulent.
Developers of phpMyAdmin warned users they may be running a
malicious version of the open-source software package after discovering
backdoor code was snuck into a package being distributed over the widely
used SourceForge repository.
The backdoor contains code that allows remote attackers to take
control of the underlying server running the modified phpMyAdmin, which
is a Web-based tool for managing MySQL databases. The PHP script is
found in a file named server_sync.php, and it reads PHP code embedded in
standard POST Web requests and then executes it. That allows anyone who
knows the backdoor is present to execute code of his choice. HD Moore,
CSO of Rapid7 and chief architect of the Metasploit exploit package for
penetration testers and hackers, told Ars a module has already been added that tests for the vulnerability.
The backdoor is concerning because it was distributed on one of the official mirrors for SourceForge,
which hosts more than 324,000 open-source projects, serves more than 46
million consumers, and handles more than four million downloads each
day. SourceForge officials are still investigating the breach, so
crucial questions remain unanswered. It's still unclear, for instance,
if the compromised server hosted other maliciously modified software
packages, if other official SourceForge mirror sites were also affected,
and if the central repository that feeds these mirror sites might also
have been attacked.
"If that one mirror was compromised, nearly every SourceForge package
on that mirror could have been backdoored, too," Moore said. "So you're
looking at not just phpMyAdmin, but 12,000 other projects. If that one
mirror was compromised and other projects were modified this isn't just
1,000 people. This is up to a couple hundred thousand."
An advisory posted Tuesday
on phpMyAdmin said: "One of the SourceForge.net mirrors, namely
cdnetworks-kr-1, was being used to distribute a modified archive of
phpMyAdmin, which includes a backdoor. This backdoor is located in file
server_sync.php and allows an attacker to remotely execute PHP code.
Another file, js/cross_framing_protection.js, has also been modified."
phpMyAdmin officials didn't respond to e-mails seeking to learn how long
the backdoored version had been available and how many people have
downloaded it.
Update: In a blog post,
SourceForge officials said they believe only the affected
phpMyAdmin-3.5.2.2-all-languages.zip package was the only modified file
on the cdnetworks mirror site, but they are continuing to investigate to
make sure. Logs indicate that about 400 people downloaded the malicious
package. The provider of the Korea-based mirror has confirmed the
breach, which is believe to have happened around September 22, and
indicated it was limited to that single mirror site. The machine has
been taken out of rotation.
"Downloaders are at risk only if a corrupt copy of this software was
obtained, installed on a server, and serving was enabled," the
SourceForge post said. "Examination of web logs and other server data
should help confirm whether this backdoor was accessed."
It's not the first time a widely used open-source project has been
hit by a breach affecting the security of its many downstream users. In
June of last year, WordPress required all account holders on
WordPress.org to change their passwords following the discovery that hackers contaminated it with malicious software.
Three months earlier, maintainers of the PHP programming language spent
several days scouring their source code for malicious modifications
after discovering the security of one of their servers had been breached.
A three-day security breach in 2010 on ProFTP
caused users who downloaded the package during that time to be infected
with a malicious backdoor. The main source-code repository for the Free
Software Foundation was briefly shuttered that same year following the
discovery of an attack that compromised some of the website's account passwords
and may have allowed unfettered administrative access. And last August,
multiple servers used to maintain and distribute the Linux operating
system were infected with malware that gained root system access, although maintainers said the repository was unaffected.
At today’s hearing
of the Subcommittee on Intellectual Property, Competition and the
Internet of the House Judiciary Committee, I referred to an attempt to
“sabotage” the forthcoming Do Not Track standard. My written testimony
discussed a number of other issues as well, but Do Not Track was
clearly on the Representatives’ minds: I received multiple questions on
the subject. Because of the time constraints, oral answers at a
Congressional hearing are not the place for detail, so in this blog
post, I will expand on my answers this morning, and explain why I think
that word is appropriate to describe the current state of play.
Background
For years, advertising networks have offered the option to opt out
from their behavioral profiling. By visiting a special webpage provided
by the network, users can set a browser cookie saying, in effect, “This
user should not be tracked.” This system, while theoretically offering
consumers choice about tracking, suffers from a series of problems that
make it frequently ineffective in practice. For one thing, it relies
on repetitive opt-out: the user needs to visit multiple opt-out pages, a
daunting task given the large and constantly shifting list of
advertising companies, not all of which belong to industry groups with
coordinated opt-out pages. For another, because it relies on
cookies—the same vector used to track users in the first place—it is
surprisingly fragile. A user who deletes cookies to protect her privacy
will also delete the no-tracking cookie, thereby turning tracking back
on. The resulting system is a monkey’s paw: unless you ask for what you want in exactly the right way, you get nothing.
The idea of a Do Not Track header gradually emerged
in 2009 and 2010 as a simpler alternative. Every HTTP request by which
a user’s browser asks a server for a webpage contains a series of headers
with information about the webpage requested and the browser. Do Not
Track would be one more. Thus, the user’s browser would send, as part
of its request, the header:
DNT: 1
The presence of such a header would signal to the website that the
user requests not to be tracked. Privacy advocates and technologists
worked to flesh out the header; privacy officials in the United States
and Europe endorsed it. The World Wide Web Consortium (W3C) formed a
public Tracking Protection Working Group with a charter to design a technical standard for Do Not Track.
Significantly, a W3C standard is not law. The legal effect of Do Not
Track will come from somewhere else. In Europe, it may be enforced directly on websites under existing data protection law. In the United States, legislation has been introduced in the House and Senate
that would have the Federal Trade Commission promulgate Do Not Track
regulations. Without legislative authority, the FTC could not require
use of Do Not Track, but would be able to treat a website’s false claims
to honor Do Not Track as a deceptive trade practice. Since most online
advertising companies find it important from a public relations point
of view to be able to say that they support consumer choice, this last
option may be significant in practice. And finally, in an important recent paper,
Joshua Fairfield argues that use of the Do Not Track header itself
creates an enforceable contract prohibiting tracking under United States
law.
In all of these cases, the details of the Do Not Track standard will
be highly significant. Websites’ legal duties are likely to depend on
the technical duties specified in the standard, or at least be strongly
influenced by them. For example, a company that promises to be Do Not
Track compliant thereby promises to do what is required to comply with
the standard. If the standard ultimately allows for limited forms of
tracking for click-fraud prevention, the company can engage in those
forms of tracking even if the user sets the header. If not, it cannot.
Thus, there is a lot at stake in the Working Group’s discussions.
Internet Explorer and Defaults
On May 31, Microsoft announced that Do Not Track would be on by default
in Internet Explorer 10. This is a valuable feature, regardless of how
you feel about behavioral ad targeting itself. A recurring theme of
the online privacy wars is that unusably complicated privacy interfaces
confuse users in ways that cause them to make mistakes and undercut
their privacy. A default is the ultimate easy-to-use privacy control.
Users who care about what websites know about them do not need to
understand the details to take a simple step to protect themselves.
Using Internet Explorer would suffice by itself to prevent tracking from
a significant number of websites.
This is an important principle. Technology can empower users to
protect their privacy. It is impractical, indeed impossible, for users
to make detailed privacy choices about every last detail of their online
activities. The task of getting your privacy right is profoundly
easier if you have access to good tools to manage the details.
Antivirus companies compete vigorously to manage the details of malware
prevention for users. So too with privacy: we need thriving markets in
tools under the control of users to manage the details.
There is immense value if users can delegate some of their privacy
decisions to software agents. These delegation decisions should be dead
simple wherever possible. I use Ghostery
to block cookies. As tools go, it is incredibly easy to use—but it
still is not easy enough. The choice of browser is a simple choice, one
that every user makes. That choice alone should be enough to count as
an indication of a desire for privacy. Setting Do Not Track by default
is Microsoft’s offer to users. If they dislike the setting, they can
change it, or use a different browser.
The Pushback
Microsoft’s move intersected with a long-simmering discussion on the
Tracking Protection Working Group’s mailing list. The question of Do
Not Track defaults had been one of the first issues the Working Group raised when it launched in September 2011. The draft text that emerged by the spring remains painfully ambiguous on the issue. Indeed, the group’s May 30 teleconference—the
day before Microsoft’s announcement—showed substantial disagreement
about defaults and what a server could do if it believed it was seeing a
default Do Not Track header, rather than one explicitly set by the
user. Antivirus software AVG includes a cookie-blocking tool
that sets the Do Not Track header, which sparked extensive discussion
about plugins, conflicting settings, and explicit consent. And the last
few weeks following Microsoft’s announcement have seen a renewed debate
over defaults.
Many industry participants object to Do Not Track by default.
Technology companies with advertising networks have pushed for a crucial
pair of positions:
User agents (i.e. browsers and apps) that turned on Do Not Track by default would be deemed non-compliant with the standard.
Websites that received a request from a noncompliant user agent would be free to disregard a DNT: 1 header.
This position has been endorsed by representatives the three
companies I mentioned in my testimony today: Yahoo!, Google, and Adobe.
Thus, here is an excerpt from an email to the list by Shane Wiley from Yahoo!:
If you know that an UA is non-compliant, it should be fair to NOT
honor the DNT signal from that non-compliant UA and message this back to
the user in the well-known URI or Response Header.
Here is an excerpt from an email to the list by Ian Fette from Google:
There’s other people in the working group, myself included, who feel that
since you are under no obligation to honor DNT in the first place (it is
voluntary and nothing is binding until you tell the user “Yes, I am
honoring your DNT request”) that you already have an option to reject a
DNT:1 request (for instance, by sending no DNT response headers). The
question in my mind is whether we should provide websites with a mechanism
to provide more information as to why they are rejecting your request, e.g.
“You’re using a user agent that sets a DNT setting by default and thus I
have no idea if this is actually your preference or merely another large
corporation’s preference being presented on your behalf.”
And here is an excerpt from an email to the list by Roy Fielding from Adobe:
The server would say that the non-compliant browser is broken and
thus incapable of transmitting a true signal of the user’s preferences.
Hence, it will ignore DNT from that browser, though it may provide
other means to control its own tracking. The user’s actions are
irrelevant until they choose a browser capable of communicating
correctly or make use of some means other than DNT.
Pause here to understand the practical implications of writing this
position into the standard. If Yahoo! decides that Internet Explorer 10
is noncompliant because it defaults on, then users who picked Internet
Explorer 10 to avoid being tracked … will be tracked. Yahoo! will claim
that it is in compliance with the standard and Internet Explorer 10 is
not. Indeed, there is very little that an Internet Explorer 10 user
could do to avoid being tracked. Because her user agent is now flagged
by Yahoo! as noncompliant, even if she manually sets the header herself,
it will still be ignored.
The Problem
A cynic might observe how effectively this tactic neutralizes the
most serious threat that Do Not Track poses to advertisers: that people
might actually use it. Manual opt-out cookies are tolerable
because almost no one uses them. Even Do Not Track headers that are off
by default are tolerable because very few people will use them.
Microsoft’s and AVG’s decisions raise the possibility that significant
numbers of web users would be removed from tracking. Pleasing user
agent noncompliance is a bit of jujitsu, a way of meeting the threat
where it is strongest. The very thing that would make Internet Explorer
10’s Do Not Track setting widely used would be the very thing to
“justify” ignoring it.
But once websites have an excuse to look beyond the header they
receive, Do Not Track is dead as a practical matter. A DNT:1 header is
binary: it is present or it is not. But second-guessing interface
decisions is a completely open-ended question. Was the check box to
enable Do Not Track worded clearly? Was it bundled with some other user
preference? Might the header have been set by a corporate network
rather than the user? These are the kind of process questions that can
be lawyered to death. Being able to question whether a user really meant her Do Not Track header is a license to ignore what she does mean.
Return to my point above about tools. I run a browser with multiple
plugins. At the end of the day, these pieces of software collaborate to
set a Do Not Track header, or not. This setting is under my control: I
can install or uninstall any of the software that was responsible for
it. The choice of header is strictly between me and my user agent. As far as the Do Not Track specification is concerned,
websites should adhere to a presumption of user competence: whatever
value the header has, it has with the tacit or explicit consent of the
user.
Websites are not helpless against misconfigured software. If they
really think the user has lost control over her own computer, they have a
straightforward, simple way of finding out. A website can display a
popup window or an overlay, asking the user whether she really wants to
enable Do Not Track, and explaining the benefits disabling it would
offer. Websites have every opportunity to press their case for
tracking; if that case is as persuasive as they claim, they should have
no fear of making it one-on-one to users.
This brings me to the bitterest irony of Do Not Track defaults. For
more than a decade, the online advertising industry has insisted that
notice and an opportunity to opt out is sufficient choice for consumers.
It has fought long and hard against any kind of heightened consent
requirement for any of its practices. Opt-out, in short, is good
enough. But for Do Not Track, there and there alone, consumers
allegedly do not understand the issues, so consent must be explicit—and opt-in only.
Now What?
It is time for the participants in the Tracking Protection Working
Group to take a long, hard look at where the process is going. It is
time for the rest of us to tell them, loudly, that the process is going
awry. It is true that Do Not Track, at least in the present regulatory
environment, is voluntary. But it does not follow that the standard
should allow “compliant” websites to pick and choose which pieces to
comply with. The job of the standard is to spell out how a user agent
states a Do Not Track request, and what behavior is required of websites
that choose to implement the standard when they receive such a request.
That is, the standard must be based around a simple principle:
A Do Not Track header expresses a meaning, not a process.
The meaning of “DNT: 1” is that the receiving website should not
track the user, as spelled out in the rest of the standard. It is not
the website’s concern how the header came to be set.
Microsoft has let it be known that their final release of the Internet Explorer 10
web browser software will have “Do Not Track” activated right out of
the box. This information has upset advertisers across the board as web
ad targeting – based on your online activities – is one of the current
mainstays of big-time advertiser profits. What Do Not Track, or DNT does
is to send out signal from your web browser, Internet Explorer 10 in
this case, to websites letting them know that the user refuses to be
seen in such a way.
A very similar Do Not Track feature currently exists on Mozilla’s Firefox browser
and is swiftly becoming ubiquitous around the web as a must-have
feature for web privacy. This will very likely bring about a large
change in the world of online advertising specifically as, again,
advertisers rely on invisible tracking methods so heavily. Tracking in
place today also exists on sites such as Google where your search
history will inform Google on what you’d like to see for search results, News posts, and advertisement content.
The Digital Advertising Aliance, or DAA, has countered Microsoft’s
announcement saying that the IE10 browser release would oppose
Microsoft’s agreement with the White House earlier this year. This
agreement had the DAA agreeing to recognize and obey the Do Not Track
signals from IE10 just so long as the option to have DNT activated was
not turned on by default. Microsoft Chief Privacy Officer Brendan Lynch
spoke up this week on the situation this week as well.
“In a world where consumers live a large part of their
lives online, it is critical that we build trust that their personal
information will be treated with respect, and that they will be given a
choice to have their information used for unexpected purposes.
While there is still work to do in agreeing on an industry-wide
definition of DNT, we believe turning on Do Not Track by default in IE10
on Windows 8 is an important step in this process of establishing
privacy by default, putting consumers in control and building trust
online.” – Lynch
The Internet is about (if it is not already a terminated task!) to become a pretty classical media. Country's boundaries were raised up on the net, making unavailable some contents depending on the world region you are browsing from (pretty weird, middle-age based concept of what the Internet must be)... We are now heavily targeted by many advertisements all around contents we are trying to access from the Web, pop-up blockers are now totally useless as advertisements took fairly advantage of HTML evolution. It is more and more difficult to ignore these advertisements, and even by closing them, one already produces/gives an information to Big Brother. There is less and less ways to escape, and by reading the following article, it looks like we are not supposed to escape... by the way.
The opportunity to set up an alternative network (satellite based?) may be the only way to get a new [commercially virgin] web... Let's call it The Veb... underlying the need of a step back from where we are nowadays.
Don’t you just hate it when you often need to
solve a captcha whenever you want to log in to select websites? You
know, those irritating slanted and jumbled group of letters and numbers,
where sometimes, you cannot even tell whether it is the letter ‘o’ or
the number ’0?, or if the particular letter is in the uppercase or not.
Captchas have been employed for some years already in order to verify
that the person behind the computer is made out of flesh and bone, and
is not an automated robot or program of any kind. Detroit-based tech
company Are You A Human
(interesting name) has come up with a different way of verifying the
authenticity of a user – not through captchas, but rather, the idea of a
simple game known as PlayThru.
PlayThru claims to prevent bots from spamming sites, as the game can
only be completed by an actual human being. Definitely sounds far more
fun in theory to “solve”, and if your less than informed boss walks by
your desk to see you play the latest game, just tell him or her that you
are solving a captcha replacement before you are able to start work.
To get a better idea on how PlayThru works, here is an example of
just one of the games. You will be presented with your fair share of
items, including a shoe, a football jersey, an olive and a piece of
bacon, where all of them will float right beside a pizza. Should you
drag the right ingredients over the pizza, then you would have “won”,
and so far, I do not think that anyone would like a topping of shoes on
their pizza.
Develop looks at the platform with ambitions to challenge Adobe's ubiquitous Flash web player
Initially heralded as the future of
browser gaming and the next step beyond the monopolised world of Flash,
HTML5 has since faced criticism for being tough to code with and
possessing a string of broken features.
The coding platform, the fifth iteration of the HTML standard, was
supposed to be a one stop shop for developers looking to create and
distribute their game to a multitude of platforms and browsers, but
things haven’t been plain sailing.
Not just including the new HTML mark-up language, but also
incorporating other features and APIs such as CSS3, SVG and JavaScript,
the platform was supposed to allow for the easy insertion of features
for the modern browser such as video and audio, and provide them without
the need for users to install numerous plug-ins.
And whilst this has worked to a certain degree, and a number of
companies such as Microsoft, Apple, Google and Mozilla under the W3C
have collaborated to bring together a single open standard, the problems
it possesses cannot be ignored.
That’s what Mozilla’s Director of Research Andreas Gal thinks of
Google’s purportedly ‘open source’ mobile operating system. In Gal’s
view Google’s platform is no different from Apple’s iOS. The entire
platform – including its design, development, and direction – is
‘dominated by Google.’
According to Gal, ‘Google makes all of the technological decisions
behind closed doors and pushes them outwards. You may or may not get a
look at the source after the device comes out. But it’s certainly not
open. And in this sense it’s no different from Apple’s platform, except
that maybe sometimes you get access to the source.’
And this is where Mozilla comes into the equation. Boot 2 Gecko is
based solely on HTML5, JavaScript and CSS and is completely open source.
Mozilla doesn’t even keep a ‘physical’ copy of the source code in its
offices – everything to do with the platform is available online for all
to see.
Brendan Eich, Mozilla’s co-founder (and the inventor of JavaScript),
told Know Your Mobile that the days of native shells (iOS/Android) and
proprietary software (Objective-C) could soon be over as Mozilla
continues to standardise and implement Open Web APIs that will one day
eradicate the need for separate platforms, allowing users to find and
use apps on their mobiles without having to opt into a privately owned
platform.
‘Separate platforms are no longer necessary once you have the correct standardisation and inter-operation,’ said Eich.
Apple’s iOS, Microsoft’s Windows Phone, RIM’s BlackBerry OS 10 and
Google’s Android operating systems are all ‘walled gardens,’ according
to Gal, meaning that all of the above are in it for one reason: to make
money.
‘Google builds Android not for your benefit but for Google’s benefit,
and the shareholders it has to satisfy. This is the same with Apple,’
said Gal. He added: ‘Mozilla is very different – we are a non-profit
organisation. In the past Mozilla was all about making the web better.
But now people are going to mobile, so we’re following them there.’
‘What we’ve developed [with B2G] is a completely open stack that is
100 per cent free. We have a publicly visible repository and all the
development happens in the open. We use completely open standards and
there’s no propriety software or technology involved.’
So what is Mozilla getting at here? Simple: dump the standard
smartphone operating system, forget Apple and Google, and embrace the
freedom of pure HTML5.
Gal tells us that because the B2G stack is based on HTML5 there are
literally millions of developers out there that know how to create
content for the platform. There will also be plenty of opportunities for
developers to make money from their creations as well, according to
Gal.
Google and Mozilla have developed technology that lets web developers
manifest their entire site, including payment methods, into an icon
that can be placed on a B2G device’s homescreen.
But all this, Gal tells us, is still work in progress. Boot 2 Gecko
is still in its embryonic stages at present – but the ball has certainly
begun rolling.
‘We’re working with operators to create an easy way for customers to
pay for content,’ said Gal. ‘Mobile users want to go to a store,
discover content and pay for it easily. We’re working on making this a
reality inside B2G via personal identity systems.’
Persona, featuring BrowserID, is one such personal identity system.
Persona lets users use their email address and a single password to sign
in or buy materials and media. Mozilla demoed Persona at MWC 2012.
‘You own your applications. You own your data and you have the power
to take them wherever you like,’ said Eich. ‘And this will be dependent
on things like Persona, which is the most secure and safe password free
sign-on and the identity providers don’t see all of your details like
they would with Facebook Connect, for instance.’
He added: ‘the end result is an “unwalled garden” where you’re free
to move around without being forced into opting fully into one
platform.’
But what’s most impressive about B2G is how well it runs on low-end
hardware. During our meeting with Gal and Eich, we got a demo of B2G
running incredibly smoothly on a $60 handset with a 600Mhz CPU and just
128MB of RAM. Gaming, web browsing, video and typing were all seamless.
Gal also confirmed that Qualcomm is partnering with Mozilla on its B2G project.
B2G is based on the same web-rendering engine as Mozilla’s Firefox
browser, meaning that it is extremely lightweight when compared to
Android and iOS. For this reason getting smartphone-level performance
out of a budget mobile handset suddenly becomes a reality.
‘There are so many opportunities for technology like this [B2G] in
emerging countries. What people are looking for there is a solid
smartphone experience – browsing, web browsing and applications – at a
decent price point. Users’ in India, for instance, cannot afford
Google’s quad-core devices but they could afford a $60 HTML5-powered B2G
handset.’
‘Google’s Android platform is too hardware dependent,’ says Gal.
‘Android 4.0 demands 512MB of RAM as a minimum for instance. Mozilla’s
web stack allows OEMs to produce $60 handsets with smartphone-like
performance,’ said Gal.
He added: ‘But of course if you add in extra hardware for higher tier phones, the performance will only get better.’
It's no secret that there's big money to be made in violating your
privacy. Companies will pay big bucks to learn more about you, and
service providers on the web are eager to get their hands on as much
information about you as possible.
So what do you do? How do you keep your information out of everyone
else's hands? Here's a guide to surfing the web while keeping your
privacy intact.
The adage goes, "If you're not paying for a service, you're the
product, not the customer," and it's never been more true. Every day
more news breaks about a new company that uploads your address book to their servers, skirts in-browser privacy protection, and tracks your every move on the web
to learn as much about your browsing habits and activities as possible.
In this post, we'll explain why you should care, and help you lock down
your surfing so you can browse in peace.
Why You Should Care
Your personal information is valuable. More valuable than you might think. When we originally published our guide to stop Facebook from tracking you around the web,
some people cried "So what if they track me? I'm not that important/I
have nothing to hide/they just want to target ads to me and I'd rather
have targeted ads over useless ones!" To help explain why this is
short-sighted and a bit naive, let me share a personal story.
Before I joined the Lifehacker team, I worked at a company that
traded in information. Our clients were huge companies and one of the
services we offered was to collect information about people, their
demographics, income, and habits, and then roll it up so they could get a
complete picture about who you are and how to convince you to buy their
products. In some cases, we designed web sites and campaigns to
convince you to provide even more information in exchange for a coupon,
discount, or the simple promise of other of those. It works very, very
well.
The real money is in taking your data and shacking up with third parties to help them
come up with new ways to convince you to spend money, sign up for
services, and give up more information. Relevant ads are nice, but the
real value in your data exists where you won't see it until you're too
tempted by the offer to know where it came from, whether it's a coupon
in your mailbox or a new daily deal site with incredible bargains
tailored to your desires. It all sounds good until you realize the only
thing you have to trade for such "exciting" bargains is everything
personal about you: your age, income, family's ages and income, medical
history, dietary habits, favorite web sites, your birthday...the list
goes on. It would be fine if you decided to give up this information for
a tangible benefit, but you may never see a benefit aside from an ad,
and no one's including you in the decision. Here's how to take back that
control.
Click for instructions for your browser of choice:
How to Stop Trackers from Following Where You're Browsing with Chrome
If you're a Chrome user, there are tons of great add-ons and tools
designed to help you uncover which sites transmit data to third parties
without your knowledge, which third parties are talking about you, and
which third parties are tracking your activity across sites. This list
isn't targeted to a specific social network or company—instead, these
extensions can help you with multiple offenders.
Adblock Plus
- We've discussed AdBlock plus several times, but there's never been a
better time to install it than now. For extra protection, one-click
installs the Antisocial
subscription for AdBlock. With it, you can banish social networks like
Facebook, Twitter, and Google+ from transmitting data about you after
you leave those sites, even if the page you visit has a social plugin on
it.
Ghostery -
Ghostery does an excellent job at blocking the invisible tracking
cookies and plug-ins on many web sites, showing it all to you, and then
giving you the choice whether you want to block them one-by-one, or all
together so you'll never worry about them again. The best part about
Ghostery is that it's not just limited to social networks, but will also
catch and show you ad-networks and web publishers as well.
ScriptNo for Chrome
- ScriptNo is much like Ghostery in that any scripts running on any
site you visit will sound its alarms. The difference is that while
Ghostery is a bit more exclusive about the types of information it
alerts you to, ScriptNo will sound the alarm at just about everything,
which will break a ton of websites. You'll visit the site, half
of it won't load or work, and you'll have to selectively enable scripts
until it's usable. Still, its intuitive interface will help you choose
which scripts on a page you'd like to allow and which you'd like to
block without sacrificing the actual content on the page you'd like to
read.
Do Not Track Plus - The "Do Not Track" feature that most browsers have is useful, but if you want to beef them up, the previously mentioned
Do Not Track Plus extension puts a stop to third-party data exchanges,
like when you visit a site like ours that has Facebook and Google+
buttons on it. By default, your browser will tell the network that
you're on a site with those buttons—with the extension installed, no
information is sent until you choose to click one. Think of it as opt-in
social sharing, instead of all-in.
Ghostery, AdBlock Plus, and Do Not Track are the ones you'll need the
most. ScriptNo is a bit more advanced, and may take some getting used
to. In addition to installing extensions, make sure you practice basic
browser maintenance that keeps your browser running smoothly and
protects your privacy at the same time. Head into Chrome's Advanced
Content Settings, and make sure you have third-party cookies blocked and
all cookies set to clear after browsing sessions. Log out of social
networks and web services when you're finished using them instead of
just leaving them perpetually logged in, and use Chrome's "Incognito
Mode" whenever you're concerned about privacy.
Mobile Browsing
Mobile browsing is a new frontier. There are dozens of mobile
browsers, and even though most people use the one included on their
device, there are few tools to protect your privacy by comparison to the
desktop. Check to see if your preferred browser has a "privacy mode"
that you can use while browsing, or when you're logged in to social
networks and other web services. Try to keep your social network use
inside the apps developed for it, and—as always—make sure to clear your
private data regularly.
If none of these extensions make you feel any better, or you want to
take protecting your privacy and personal data to the next level, it's
time to break out the big guns. One tip that came up during our last
discussion about Facebook was to use a completely separate web browser
just for logged-in social networks and web services, and another browser
for potentially sensitive browsing, like your internet shopping,
banking, and other personal activities. If you have some time to put
into it, check out our guide to browsing without leaving a trace, which was written for Firefox, but can easily be adapted to any browser you use.
If you're really tired of companies tracking you and trading in your
personal information, you always have the option to just provide false
information. The same way you might give a fake phone number or address
to a supermarket card sign-up sheet, you can scrub or change personal
details about yourself from your social network profiles, Google
accounts, Windows Live account, and others.
Change your birthdate, or your first name. Set your phone number a
digit off, or omit your apartment number when asked for your street
address. We've talked about how to disappear before,
and carefully examine the privacy and account settings for the web
services you use. Keep in mind that some of this goes against the terms
of service for those companies and services—they have a vested interest
in knowing the real you, after all, so tread carefully and tread lightly
if you want to go the "make yourself anonymous" route. Worst case,
start closing accounts with offending services, and migrate to other,
more privacy-friendly options.
These are just a few tips that won't significantly change your
browsing experience, but can go a long way toward protecting your
privacy. This issue isn't going anywhere, and as your personal
information becomes more valuable and there are more ways to keep it
away from prying eyes, you'll see more news of companies finding ways to
eke out every bit of data from you and the sites you use. Some of these
methods are more intrusive than others, and some of them may turn you
off entirely, but the important thing is that they all give you
control over how you experience the web. When you embrace your privacy,
you become engaged with the services you use. With a little effort and
the right tools, you can make the web more opt-in than it is opt-out.
